[MACHINE-SPIRIT] EPIC — finite symbolic task executive, extraction-ready for Prolog-RLM #333

New issue

Open

opened 2026-09-08 02:03:34 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 02:03:34 +00:00

Owner

Project MACHINE-SPIRIT

Build MACHINE-SPIRIT inside Zara as a finite symbolic task executive: Prolog owns task reasoning, validated planning, graph/state transitions, and selection of typed effects. Zara remains the host for identity, persistence, approval, capability execution, runtime lifecycle, UI/voice, and device integration.

This is not a personality layer and not a thin LLM wrapper. The target is a real symbolic executive that can carry a bounded task from goal -> validated plan -> approved effects -> evidence/checkpoints -> terminal result.

Extraction invariant

Implement the generic Prolog core in an extraction-friendly namespace/path (machine_spirit_*) with this dependency direction:

machine_spirit_* -> prolog-rlm public APIs
zara adapter     -> machine_spirit_* + Zara runtime

Generic MACHINE-SPIRIT modules MUST NOT depend on Zara Python packages, desktop/UI/Android code, Zara database classes, machine-specific paths, or Zara-only protocol types. When v0 closes, the generic Prolog modules and tests should be mechanically movable into lost-rob0t/prolog-rlm as another library with a small host interface.

Initial inspected upstream baseline: lost-rob0t/prolog-rlm@e1ed6c2b5f717d9bb380fcf22d144737299197f8. Re-pin the exact tested upstream revision when implementation begins; do not copy rlm_* internals into Zara.

Verified upstream primitives to build on:

rlm_plan: closed typed plan AST, whole-plan validation, finite budgets, execution;
rlm_tool: registered tools, argument/schema validation, capability narrowing, authority mediation, async invocation;
rlm_graph: declarative bounded graph execution, checkpoints/history, resume, cancellation;
existing rlm_async, context/artifact/trace primitives where appropriate.

Zara integration invariants

Keep the existing RuntimeHost as execution owner.
Keep the existing principal-scoped TaskStore as the only durable task store.
Add MACHINE-SPIRIT as an executor strategy for the existing TaskRunner; do not create a second task subsystem or second assistant loop.
Legacy task execution remains available during v0 and is the default until MACHINE-SPIRIT acceptance is complete.
Zara's canonical ToolRegistry / approval / identity / cancellation boundaries remain final host authority.
Prolog-RLM capabilities may only narrow Zara authority, never widen it.
Model output is untrusted data until parsed and validated.
No unrestricted model-generated call/1, arbitrary Prolog goal execution, or generic shell execution.
Long-running effects must converge on the canonical cancellation work tracked by #388; do not invent a MACHINE-SPIRIT-specific cancellation control plane.
Plugin capability composition should consume #400 once canonical rather than importing plugin internals.

Finite v0 — fixed eight-slice sequence

Implementation is intentionally finite and ordered. A later slice does not absorb unfinished work from an earlier slice.

#637 — Extraction boundary + pinned Prolog-RLM runtime
#638 — Pure symbolic task state machine + finite step protocol
#639 — Validated planning/graph executive on rlm_plan + rlm_graph
#640 — Zara capability bridge: Prolog executes task effects through canonical tools
#641 — TaskRunner executor strategy + one-store persistence/resume
#642 — Symbolic context/evidence workspace (the bounded brain)
#643 — Adversarial, property, and chaos acceptance harness
#644 — Finite v0 acceptance, benchmark, and extraction proof

Dependency chain:

#637 -> #638 -> #639 -> #640 -> #641 -> #642 -> #643 -> #644 -> close #636

What "Prolog executes tasks" means

MACHINE-SPIRIT is not limited to recommending a plan to Python. Prolog owns the task executive and can choose/sequence task effects. Actual host side effects cross a typed capability bridge:

validated Prolog plan / graph
  -> Prolog-RLM rlm_tool capability check
  -> typed effect request
  -> exact Zara principal/tool registry
  -> canonical approval/policy
  -> canonical tool execution
  -> bounded typed observation back to Prolog

That gives Prolog real executive control without granting unrestricted host execution. Model/plan data never becomes call/1, an arbitrary Prolog goal, Python callable, or free-form shell command.

Mandatory adversarial gate

#643 is a blocker for #644 and attacks at least:

callable/plan injection;
capability widening/forgery/staleness;
cross-principal execution;
approval replay/bypass;
graph/recursion/retry/budget exhaustion;
cancellation races;
worker/daemon crash and stale checkpoint replay;
concurrent task isolation;
prompt injection inside evidence;
oversized/malformed IPC/plan/evidence values;
secret leakage in traces/persistence.

Every discovered failure gets a deterministic regression test before repair. No skip/xfail/swallowed-error false-green acceptance.

Hard non-goals for v0

personality simulation as architecture;
recursive self-modifying code;
arbitrary call/1 or model-provided Prolog clauses becoming trusted code;
arbitrary shell access;
a second task DB/store;
a second agent/runtime loop;
distributed swarms;
autonomous privilege escalation;
silent auto-resume after crash;
Android-specific implementation;
infinite/open-ended implementation phases.

Definition of DONE

MACHINE-SPIRIT v0 is complete only when #637–#644 are all closed, #643's adversarial report is green, #644's fixed eight-case corpus and extraction-boundary proof are green, and exact-head full Zara/Nix/package compatibility gates pass. Then close this epic. Any further autonomy/self-improvement/swarm work is v1+ and requires new issues.

Planning base observed while creating this epic: Zara master@207e3b689399464de413d3faba7c2ed763168ca3.

## Project MACHINE-SPIRIT Build MACHINE-SPIRIT inside Zara as a **finite symbolic task executive**: Prolog owns task reasoning, validated planning, graph/state transitions, and selection of typed effects. Zara remains the host for identity, persistence, approval, capability execution, runtime lifecycle, UI/voice, and device integration. This is not a personality layer and not a thin LLM wrapper. The target is a real symbolic executive that can carry a bounded task from goal -> validated plan -> approved effects -> evidence/checkpoints -> terminal result. ## Extraction invariant Implement the generic Prolog core in an extraction-friendly namespace/path (`machine_spirit_*`) with this dependency direction: ```text machine_spirit_* -> prolog-rlm public APIs zara adapter -> machine_spirit_* + Zara runtime ``` Generic MACHINE-SPIRIT modules MUST NOT depend on Zara Python packages, desktop/UI/Android code, Zara database classes, machine-specific paths, or Zara-only protocol types. When v0 closes, the generic Prolog modules and tests should be mechanically movable into `lost-rob0t/prolog-rlm` as another library with a small host interface. Initial inspected upstream baseline: `lost-rob0t/prolog-rlm@e1ed6c2b5f717d9bb380fcf22d144737299197f8`. Re-pin the exact tested upstream revision when implementation begins; do not copy `rlm_*` internals into Zara. Verified upstream primitives to build on: - `rlm_plan`: closed typed plan AST, whole-plan validation, finite budgets, execution; - `rlm_tool`: registered tools, argument/schema validation, capability narrowing, authority mediation, async invocation; - `rlm_graph`: declarative bounded graph execution, checkpoints/history, resume, cancellation; - existing `rlm_async`, context/artifact/trace primitives where appropriate. ## Zara integration invariants - Keep the existing `RuntimeHost` as execution owner. - Keep the existing principal-scoped `TaskStore` as the **only** durable task store. - Add MACHINE-SPIRIT as an executor strategy for the existing `TaskRunner`; do not create a second task subsystem or second assistant loop. - Legacy task execution remains available during v0 and is the default until MACHINE-SPIRIT acceptance is complete. - Zara's canonical ToolRegistry / approval / identity / cancellation boundaries remain final host authority. - Prolog-RLM capabilities may only **narrow** Zara authority, never widen it. - Model output is untrusted data until parsed and validated. - No unrestricted model-generated `call/1`, arbitrary Prolog goal execution, or generic shell execution. - Long-running effects must converge on the canonical cancellation work tracked by #388; do not invent a MACHINE-SPIRIT-specific cancellation control plane. - Plugin capability composition should consume #400 once canonical rather than importing plugin internals. ## Finite v0 — fixed eight-slice sequence Implementation is intentionally finite and ordered. A later slice does not absorb unfinished work from an earlier slice. - [ ] #637 — Extraction boundary + pinned Prolog-RLM runtime - [ ] #638 — Pure symbolic task state machine + finite step protocol - [ ] #639 — Validated planning/graph executive on `rlm_plan` + `rlm_graph` - [ ] #640 — Zara capability bridge: **Prolog executes task effects through canonical tools** - [ ] #641 — TaskRunner executor strategy + one-store persistence/resume - [ ] #642 — Symbolic context/evidence workspace (the bounded brain) - [ ] #643 — Adversarial, property, and chaos acceptance harness - [ ] #644 — Finite v0 acceptance, benchmark, and extraction proof Dependency chain: ```text #637 -> #638 -> #639 -> #640 -> #641 -> #642 -> #643 -> #644 -> close #636 ``` ## What "Prolog executes tasks" means MACHINE-SPIRIT is not limited to recommending a plan to Python. Prolog owns the task executive and can choose/sequence task effects. Actual host side effects cross a typed capability bridge: ```text validated Prolog plan / graph -> Prolog-RLM rlm_tool capability check -> typed effect request -> exact Zara principal/tool registry -> canonical approval/policy -> canonical tool execution -> bounded typed observation back to Prolog ``` That gives Prolog real executive control without granting unrestricted host execution. Model/plan data never becomes `call/1`, an arbitrary Prolog goal, Python callable, or free-form shell command. ## Mandatory adversarial gate #643 is a blocker for #644 and attacks at least: - callable/plan injection; - capability widening/forgery/staleness; - cross-principal execution; - approval replay/bypass; - graph/recursion/retry/budget exhaustion; - cancellation races; - worker/daemon crash and stale checkpoint replay; - concurrent task isolation; - prompt injection inside evidence; - oversized/malformed IPC/plan/evidence values; - secret leakage in traces/persistence. Every discovered failure gets a deterministic regression test before repair. No skip/xfail/swallowed-error false-green acceptance. ## Hard non-goals for v0 - personality simulation as architecture; - recursive self-modifying code; - arbitrary `call/1` or model-provided Prolog clauses becoming trusted code; - arbitrary shell access; - a second task DB/store; - a second agent/runtime loop; - distributed swarms; - autonomous privilege escalation; - silent auto-resume after crash; - Android-specific implementation; - infinite/open-ended implementation phases. ## Definition of DONE MACHINE-SPIRIT v0 is complete only when #637–#644 are all closed, #643's adversarial report is green, #644's fixed eight-case corpus and extraction-boundary proof are green, and exact-head full Zara/Nix/package compatibility gates pass. Then close this epic. Any further autonomy/self-improvement/swarm work is v1+ and requires new issues. Planning base observed while creating this epic: Zara `master@207e3b689399464de413d3faba7c2ed763168ca3`.