Add pluggable coding-agent backends

.github/workflows/contract-tests.yml

@@ -48,3 +48,6 @@ jobs:
         run: cargo test --locked
       - name: Run shell CLI and lifecycle contracts
         run: tests/run.sh
+      - name: Run malicious orchestrator boundary contracts
+        if: runner.os == 'Linux'
+        run: sudo -E tests/malicious-orchestrator.sh

README.md

@@ -1,9 +1,10 @@
 # Multiagent
 
 Multiagent is the reference implementation of an orchestration layer for
-coding agents. It is not another coding agent: it composes existing Codex and
-Claude CLIs into parallel roles, records their work, independently verifies the
-result, and gates acceptance on evidence bound to the exact Git diff.
+coding agents. It is not another coding agent: it composes existing Codex,
+Claude Code, and Qwen Code agents into parallel roles, records their work,
+independently verifies the result, and gates acceptance on evidence bound to the
+exact Git diff.
 
 The project prioritizes orchestration, evaluation, and runtime rigor over a
 custom UI or model implementation.
@@ -13,8 +14,8 @@ custom UI or model implementation.
 Building from source requires Rust 1.75 or newer, Cargo, Bash, and Git. Rust owns
 the production control plane. Python 3.8 or newer is required only for evaluation
 and evidence-analysis commands; those modules have no third-party Python package
-dependency. Live agent sessions also require `tmux` plus the configured Codex or
-Claude CLI.
+dependency. Live agent sessions also require `tmux` plus the configured coding-agent
+executables.
 
 ## Try It Locally
 
@@ -75,8 +76,8 @@ official scorer; it does not implement a second solver or acceptance gate. See
 
 ## Run With Agents
 
-Live orchestration additionally requires `tmux` and at least one configured
-Codex or Claude CLI:
+Live orchestration additionally requires `tmux` and the coding-agent executables
+selected for its roles:
 
 ```bash
 ./launch.sh --session multiagent --root /absolute/path/to/target-repo
@@ -126,8 +127,9 @@ technical findings and repair TODOs remain authoritative. Running
 `multiagent subagent gate-check`.
 
 The default roles use Codex for orchestration and verification and Claude for
-workers. `WORKER_CLI`: worker CLI for manual worker windows, default `claude`.
-`VERIFIER_CLI`: verifier CLI, default `codex`. CLI choices, recovery, ownership
+workers. `WORKER_CLI`: worker coding-agent backend for manual worker windows,
+default `claude`; supported values are `codex`, `claude`, and `qwen`.
+`VERIFIER_CLI`: verifier backend, default `codex`. Backend choices, recovery, ownership
 policy, role prompts, DAG workflows, and all control-plane commands are in the
 [getting-started and operations guide](docs/getting-started.md).
 
@@ -184,16 +186,17 @@ an advanced path.
 tests/run.sh
 ```
 
-## Enforcement Caveat
+## Enforcement Boundary
 
-Decision-authority review, approved-context handoff, lifecycle TODO convergence,
-and completion are enforced by the orchestrator prompt plus normal-path checks
-in `multiagent workflow`, `multiagent subagent`, and `multiagent orchestrator`. This makes
-ordinary violations fail visibly, but it is not a security or capability
-boundary: an orchestrator with direct shell and state-file access can bypass or
-disable these checks.
+Production Linux launches separate the orchestrator, writer, reader, and
+authority supervisor into distinct Unix identities. The supervisor exclusively
+owns workflow state, one-time role launch authorizations, and sealed reviewer
+evidence. The orchestrator can request transitions and spawn named roles, but it
+cannot write the target repository or authority state directly. A writer gets
+temporary ownership only of its predeclared paths, and only one writer may be
+active at a time. Read-only roles cannot acquire those writes.
 
-Revisit this limitation before treating the workflow as strict enforcement.
-The stronger design is a trusted supervisor that exclusively owns writable
-worker launch and independently validates TODO state, decision ownership, user
-approval, context revision, and assignment scope before starting a worker.
+This is a capability boundary for filesystem writes and typed state changes,
+not proof that an agent's semantic judgment is correct. Reviewer evidence proves
+which isolated process produced a verdict and which workflow/diff it covered;
+task correctness still depends on the reviewer, tests, and final human review.

docs/architecture.md

@@ -4,15 +4,20 @@ Multiagent is an orchestration and evidence layer around existing coding-agent
 CLIs. It is not a replacement model or a claim that every task benefits from
 parallelism.
 
+The proposed provider-neutral coding-agent boundary is described in the
+[backend PRD](coding-agent-backends-prd.md) and
+[refactoring design](coding-agent-backends-design.md).
+
 ```mermaid
 flowchart LR
     U["Real issue + immutable base commit"] --> P["Pilot manifest"]
     P --> R["Pilot runner"]
     R --> B["Baseline: one coding-agent CLI"]
     R --> O["Orchestrated: commander in tmux"]
-    O --> C["Contract / scope scouts"]
-    O --> W["Path-owned workers"]
-    O --> V["Read-only verifier"]
+    O --> A["UID-isolated authority supervisor"]
+    A --> C["Contract / scope scouts"]
+    A --> W["One path-owned writer"]
+    A --> V["Read-only verifier"]
     C --> S["Structured runtime state"]
     W --> S
     V --> S
@@ -35,9 +40,15 @@ persisted under `MULTIAGENT_STATE_DIR`. Python under `evaluation/` provides
 benchmark execution, status reading, and provenance; it does not implement a
 second control plane or participate in normal launches.
 
-Workers own disjoint writable paths. Scouts and verifiers are read-only. The
-orchestrator alone accepts follow-up work and decides whether the final gate can
-close. Hash-bound verifier evidence becomes stale when the final diff changes.
+On production Linux the orchestrator, writer, readers, and authority supervisor
+run as different Unix users. The orchestrator decomposes work and requests typed
+transitions over a Unix socket; it does not own protected state or repository
+writes. The supervisor issues one-time role launches, permits only one writer,
+temporarily grants that writer its predeclared existing paths, and seals reviewer
+output before exposing it to the orchestrator. Scouts and verifiers are
+read-only. The orchestrator can request follow-up or closure, while fixed rules
+and sealed evidence decide whether the protected transition succeeds.
+Hash-bound verifier evidence becomes stale when the final diff changes.
 
 ## Evaluation Boundary