zara-coding: Prolog-RLM coding harness for Zara #1

Open
opened 2026-08-31 18:41:28 +00:00 by lost-rob0t · 4 comments
lost-rob0t commented 2026-08-31 18:41:28 +00:00 (Migrated from github.com)

Plugin

zara-coding

Goal

Build a Zara-focused coding harness on top of lost-rob0t/prolog-rlm, rather than a thin Git/GitHub wrapper.

Zara should be able to take coding intent such as “fix this test”, “work issue 83”, “make a worktree”, “review this diff”, or “what is blocking this repo?” and drive a bounded symbolic coding loop with repository-aware tools.

Architecture

Use Prolog-RLM as the planning/state/verification substrate for the coding harness:

INTENT -> SPEC -> PLAN -> BUILD/EXECUTE -> VERIFY

The harness should expose direct operations for simple requests while allowing symbolic/recursive execution for tasks that benefit from planning.

The Prolog state should be able to represent at minimum:

  • repositories, branches, commits, worktrees, dirty state;
  • issues, pull requests, reviews, CI/check state;
  • files, tests, build commands, failures and verification evidence;
  • task goals, constraints, dependencies and completion criteria;
  • spawned coding workers/agents and their ownership of work;
  • user/project workflow rules supplied by Zara memory or plugin configuration.

Initial tool surface

  • repo.list
  • repo.status
  • repo.inspect
  • git.diff
  • git.log
  • git.branch.*
  • git.worktree.*
  • git.commit
  • issue.search/get/create/update
  • pr.list/get/diff/review
  • ci.status
  • test.run
  • build.run
  • agent.spawn/status/stop

Prefer structured tool results that can be asserted into Prolog over prose-only output.

Context integration

Integrate with zara-context when available so commands like “fix this”, “commit that”, or “check this repo” can resolve the active repo/file/selection without hard-coding desktop context into this plugin.

Integrate with zara-memory when available for project-scoped coding rules and remembered workflow constraints.

Safety / execution boundaries

  • no unrestricted arbitrary shell as the default coding interface;
  • explicit working-directory/repository boundaries;
  • bounded command runtime and output;
  • destructive Git operations require explicit policy/authorization;
  • spawned workers must have explicit task/repo/worktree ownership;
  • verification evidence must be retained in the Prolog-RLM task state;
  • never report success only because a command exited or an agent claimed completion.

Plugin shape

Start as a Zara service plugin because the harness owns state and a long-running Prolog-RLM session. It may also register tool/skill surfaces for Zara.

Expected self-contained layout under plugins/zara-coding/, README, deterministic tests, registry entry and Nix packaging per repository policy.

Acceptance criteria

  • plugin can bind a Zara coding request to a repository/worktree context
  • Prolog-RLM owns symbolic task state and completion criteria
  • direct and symbolic execution paths are both supported
  • structured Git/test/build/issue/PR adapters exist behind bounded interfaces
  • a failing test can be represented, acted on, rerun and verified through the harness
  • worker ownership prevents two spawned coding tasks from silently sharing one worktree
  • completion requires verification evidence, not model assertion
  • tests are deterministic and network-free by default
  • README documents architecture, permissions and Prolog-RLM dependency
  • plugins.json is updated and registry validation passes
  • plugin tests pass
  • nix flake check passes

Follow-up direction

Design this so the coding harness can later host domain expert systems for language/build ecosystems without putting language-specific workflow logic into Zara core.

## Plugin `zara-coding` ## Goal Build a Zara-focused coding harness on top of [`lost-rob0t/prolog-rlm`](https://github.com/lost-rob0t/prolog-rlm), rather than a thin Git/GitHub wrapper. Zara should be able to take coding intent such as “fix this test”, “work issue 83”, “make a worktree”, “review this diff”, or “what is blocking this repo?” and drive a bounded symbolic coding loop with repository-aware tools. ## Architecture Use Prolog-RLM as the planning/state/verification substrate for the coding harness: `INTENT -> SPEC -> PLAN -> BUILD/EXECUTE -> VERIFY` The harness should expose direct operations for simple requests while allowing symbolic/recursive execution for tasks that benefit from planning. The Prolog state should be able to represent at minimum: - repositories, branches, commits, worktrees, dirty state; - issues, pull requests, reviews, CI/check state; - files, tests, build commands, failures and verification evidence; - task goals, constraints, dependencies and completion criteria; - spawned coding workers/agents and their ownership of work; - user/project workflow rules supplied by Zara memory or plugin configuration. ## Initial tool surface - `repo.list` - `repo.status` - `repo.inspect` - `git.diff` - `git.log` - `git.branch.*` - `git.worktree.*` - `git.commit` - `issue.search/get/create/update` - `pr.list/get/diff/review` - `ci.status` - `test.run` - `build.run` - `agent.spawn/status/stop` Prefer structured tool results that can be asserted into Prolog over prose-only output. ## Context integration Integrate with `zara-context` when available so commands like “fix this”, “commit that”, or “check this repo” can resolve the active repo/file/selection without hard-coding desktop context into this plugin. Integrate with `zara-memory` when available for project-scoped coding rules and remembered workflow constraints. ## Safety / execution boundaries - no unrestricted arbitrary shell as the default coding interface; - explicit working-directory/repository boundaries; - bounded command runtime and output; - destructive Git operations require explicit policy/authorization; - spawned workers must have explicit task/repo/worktree ownership; - verification evidence must be retained in the Prolog-RLM task state; - never report success only because a command exited or an agent claimed completion. ## Plugin shape Start as a Zara service plugin because the harness owns state and a long-running Prolog-RLM session. It may also register tool/skill surfaces for Zara. Expected self-contained layout under `plugins/zara-coding/`, README, deterministic tests, registry entry and Nix packaging per repository policy. ## Acceptance criteria - [ ] plugin can bind a Zara coding request to a repository/worktree context - [ ] Prolog-RLM owns symbolic task state and completion criteria - [ ] direct and symbolic execution paths are both supported - [ ] structured Git/test/build/issue/PR adapters exist behind bounded interfaces - [ ] a failing test can be represented, acted on, rerun and verified through the harness - [ ] worker ownership prevents two spawned coding tasks from silently sharing one worktree - [ ] completion requires verification evidence, not model assertion - [ ] tests are deterministic and network-free by default - [ ] README documents architecture, permissions and Prolog-RLM dependency - [ ] `plugins.json` is updated and registry validation passes - [ ] plugin tests pass - [ ] `nix flake check` passes ## Follow-up direction Design this so the coding harness can later host domain expert systems for language/build ecosystems without putting language-specific workflow logic into Zara core.
Owner

Auto-RAGE architecture handoff: the local repository evidence/mutation slices can continue inside zara-coding, but cross-plugin coding workflows must not import private plugin packages or duplicate their runtimes. Current Zara PluginRuntime has no canonical authorization-preserving capability/tool lookup seam, so I filed Core lost-rob0t/zara#400 for plugin composition. Until Core supplies that contract, zara-coding will not clone zara-github issue/PR/CI actions, zara-shell execution, zara-memory persistence, or zara-context state. Work continues on dependency-ready local Git/Prolog-RLM slices meanwhile.

Auto-RAGE architecture handoff: the local repository evidence/mutation slices can continue inside `zara-coding`, but cross-plugin coding workflows must not import private plugin packages or duplicate their runtimes. Current Zara `PluginRuntime` has no canonical authorization-preserving capability/tool lookup seam, so I filed Core `lost-rob0t/zara#400` for plugin composition. Until Core supplies that contract, `zara-coding` will not clone `zara-github` issue/PR/CI actions, `zara-shell` execution, `zara-memory` persistence, or `zara-context` state. Work continues on dependency-ready local Git/Prolog-RLM slices meanwhile.
Owner

Auto-RAGE verification slice update: #104–#108 are now merged on canonical main. zara-coding can project current observed repository evidence, compile/freeze a closed trusted SPEC, reconcile exact frozen requirement identities through canonical rlm_verify:spec_verify/4, expose read-only coding.spec.verify-repository, provide one-shot compile→verify via coding.spec.check-repository, and verify exact HEAD / branch / clean-state assertions without filesystem collection from Prolog or granting repair authority. Cross-plugin issue/PR/CI, test/build, context, memory and worker orchestration remain intentionally blocked on Core #400 rather than importing private plugin implementations or creating another runtime. #1 stays open for PLAN/BUILD/EXECUTE, composed adapters, task-state ownership, and worker verification slices.

Auto-RAGE verification slice update: #104–#108 are now merged on canonical `main`. `zara-coding` can project current observed repository evidence, compile/freeze a closed trusted SPEC, reconcile exact frozen requirement identities through canonical `rlm_verify:spec_verify/4`, expose read-only `coding.spec.verify-repository`, provide one-shot compile→verify via `coding.spec.check-repository`, and verify exact HEAD / branch / clean-state assertions without filesystem collection from Prolog or granting repair authority. Cross-plugin issue/PR/CI, test/build, context, memory and worker orchestration remain intentionally blocked on Core #400 rather than importing private plugin implementations or creating another runtime. #1 stays open for PLAN/BUILD/EXECUTE, composed adapters, task-state ownership, and worker verification slices.
Owner

Auto-RAGE update: #111–#115 are now merged exact-head-green. zara-coding can pure-verify an exact coordination-locked worktree, prove worktree cleanup via bounded absence, and verify exact changed-path membership without patch text; add-and-lock now safely attempts non-force rollback if the lock phase fails and refuses cleanup if the created worktree identity drifted. README now matches the six trusted repository/worktree assertions and explicitly treats Git lock reasons as coordination metadata, not identity/authorization. Every landed head passed compatibility-contract checks, the full generated registry/plugin nix flake check, and package builds before expected-head merge. Current Zara master still exposes the same plugin API v1 file blob as the repo's pinned compatibility source, so there is no justified API-pin churn. Remaining cross-plugin PLAN/BUILD/EXECUTE, GitHub/test/build/context/memory composition and principal-aware worker ownership stay blocked on Zara Core #400; this worker will not bypass that seam.

Auto-RAGE update: #111–#115 are now merged exact-head-green. `zara-coding` can pure-verify an exact coordination-locked worktree, prove worktree cleanup via bounded absence, and verify exact changed-path membership without patch text; add-and-lock now safely attempts non-force rollback if the lock phase fails and refuses cleanup if the created worktree identity drifted. README now matches the six trusted repository/worktree assertions and explicitly treats Git lock reasons as coordination metadata, not identity/authorization. Every landed head passed compatibility-contract checks, the full generated registry/plugin `nix flake check`, and package builds before expected-head merge. Current Zara `master` still exposes the same plugin API v1 file blob as the repo's pinned compatibility source, so there is no justified API-pin churn. Remaining cross-plugin PLAN/BUILD/EXECUTE, GitHub/test/build/context/memory composition and principal-aware worker ownership stay blocked on Zara Core #400; this worker will not bypass that seam.
Owner

Auto-RAGE local #1 advance: #155 is merged exact-head-green. zara-coding now exposes approval-gated coding.git.worktree.remove-detached with exact expected-HEAD fencing, detached/non-primary/registered-worktree checks, locked-worktree refusal, and post-removal absence proof. The recovered stale branch initially failed the canonical exact tool-surface contract; that was corrected without weakening the gate, then the full compatibility + generated nix flake check + package-build CI passed before protected-head merge. Cross-plugin GitHub/test/build/context/memory composition and principal-aware worker orchestration remain intentionally blocked on Zara Core #400.

Auto-RAGE local #1 advance: #155 is merged exact-head-green. `zara-coding` now exposes approval-gated `coding.git.worktree.remove-detached` with exact expected-HEAD fencing, detached/non-primary/registered-worktree checks, locked-worktree refusal, and post-removal absence proof. The recovered stale branch initially failed the canonical exact tool-surface contract; that was corrected without weakening the gate, then the full compatibility + generated `nix flake check` + package-build CI passed before protected-head merge. Cross-plugin GitHub/test/build/context/memory composition and principal-aware worker orchestration remain intentionally blocked on Zara Core #400.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/zara-plugins#1
No description provided.