@pilotspace/add 1.8.0 → 1.10.0

package/skill/add/soul.md

@@ -1,37 +1,26 @@
 # Self-improving the voice — how SOUL.md converges to the human
 
-`SOUL.md` is the AI's voice (tone · communication style · trust). It ships as a **proposed starter**
-and is **human-owned**; this doc is how it stops being write-once and starts converging to *this*
-human. It mirrors `deltas.md` (emit) + `fold.md` (confirm → rewrite), but a confirmed voice delta is
-consolidated into **SOUL.md**, not the foundation — because voice is not one of the five competencies.
+`SOUL.md` is the AI's voice (Tone · Communication style · Trust). It ships as a **proposed starter** and is **human-owned**; this doc is how it starts converging to *this* human. It mirrors `deltas.md` (emit) + `fold.md` (confirm → rewrite), but a confirmed voice delta consolidates into **SOUL.md**, not the foundation — voice is not one of the five competencies.
 
-You (the AI) **emit** voice deltas as `open`. Only the **human** confirms one, and only a confirmed
-delta rewrites SOUL.md. **The human's confirm is the only writer** — you never self-approve a voice
-rewrite (rewriting someone's voice is theirs to approve, like a foundation consolidation).
+You **emit** voice deltas as `open`. Only the **human** confirms one; **the human's confirm is the only writer** — you never self-approve a voice rewrite.
 
 ## What a voice delta is drawn from
 
-A voice delta is grounded in how the human actually shows up **in session**:
-- their **wordings** — the words they reach for, and the words they correct you on (they cross out a
-  bit of jargon and write the plain word over it);
-- their **flow** — what they skip, what they double-check, where they want the summary before the detail.
+A voice delta is grounded in how the human shows up **in session**:
+- their **wordings** — the words they reach for, and the words they correct you on;
+- their **flow** — what they skip, what they double-check, where they want summary before detail.
 
-NOT from their private **memory** files or anything outside the working session — SOUL learns from what
-you observed together, never from reading a personal store.
+NOT from their private **memory** files or anything outside the working session — SOUL learns only from what you observed together.
 
 ## The grammar (mirrors deltas.md)
 
-Each voice delta begins on its own tag line; the observation may wrap, and a required `(evidence: …)`
-clause closes it:
-
 ```
 - [VOICE · <status>] <observation about the voice> (evidence: <in-session pointer>)
 ```
 
-- `<status>` — `open` | `confirmed` | `declined`. A newly emitted delta is **`open`**.
 - `<observation>` — what the voice should become ("lead with the decision, not the preamble").
-- `(evidence: …)` — **required**, non-empty: a moment in the session (a correction, a re-ask, a
-  visible preference). No evidence → it is a guess about the human, not a delta. Drop it.
+- `<status>` — `open` | `confirmed` | `declined`. A newly emitted delta is **`open`**.
+- `(evidence: …)` — **required**, non-empty: a moment in the session (a correction, a re-ask, a visible preference). No evidence → drop it.
 
 ```
 - [VOICE · open] the human strips hedging from my drafts — cut "I think / it seems" and state it plainly
@@ -40,12 +29,9 @@ clause closes it:
 
 ## The loop — observe → confirm → rewrite
 
-1. **Emit** (OBSERVE) — at a task's observe phase (or on demand), propose 0–N voice deltas as `open`
-   from the session's wordings + flow. Surface them in the report; show-before-ask.
+1. **Emit** (OBSERVE) — propose 0–N voice deltas as `open` from wordings + flow. Surface in the report; show-before-ask.
 2. **Confirm** — the human accepts or declines each. **No SOUL.md write happens without this.**
-3. **Rewrite** — on a confirmed delta, edit the routed SOUL.md section, then record the delta line
-   (status `confirmed`) at the **top** of the "Voice deltas" ledger (**newest-first**, append-only — a
-   declined delta flips to `declined` and stays in place, so "considered, chose not to" is auditable).
+3. **Rewrite** — on a confirmed delta, edit the routed SOUL.md section, record the delta line (`confirmed`) at the **top** of "Voice deltas" (**newest-first**, append-only — declined stays in place).
 
 ## Routing — every voice delta has a SOUL.md home
 
@@ -55,23 +41,18 @@ clause closes it:
 | how I *structure* what I say (summary-first, show-before-ask, length) | **## Communication style** |
 | what keeps the human's *trust* (gates, honesty, what I never do) | **## Trust** |
 
-The rewrite is surgical: refine or append the bullet the delta names; never silently rewrite the rest
-of the voice. Every confirmed delta also gets its line in **## Voice deltas** (newest-first).
+The rewrite is surgical: refine or append the bullet the delta names; never silently rewrite the rest of the voice. Every confirmed delta also gets its line in **## Voice deltas** (newest-first).
 
-## Reject codes (the AI is first check, the human the backstop)
+## Reject codes
 
 <reject_codes>
-- `unconfirmed_voice_rewrite` — a SOUL.md write was attempted without a recorded human confirm. The AI
-  proposes; it never self-approves. Stop and get the confirm. (The identity-owned floor.)
+- `unconfirmed_voice_rewrite` — a SOUL.md write was attempted without a recorded human confirm. The AI proposes; it never self-approves. Stop and get the confirm.
 - `no_open_voice_deltas` — nothing is `open`. The loop is a no-op; do not touch SOUL.md.
-- `unroutable_voice_delta` — the observation maps to no SOUL.md section (not tone/style/trust). Fix the
-  delta or widen the routing before writing.
+- `unroutable_voice_delta` — the observation maps to no SOUL.md section (not tone/style/trust). Fix the delta or widen the routing before writing.
 </reject_codes>
 
 ## Where it plugs in
 
-- **Emit**: `phases/7-observe.md` proposes voice deltas beside its competency/spec deltas.
-- **Target**: `SOUL.md` (scaffolded by setup) — its "## Voice deltas" ledger holds the confirmed history.
-- **Kin**: `deltas.md` (competency learnings → foundation) and `fold.md` (the same propose→confirm→write
-  discipline). This is the voice's version of that discipline; the engine stays judgment-free (no
-  `add.py` command writes the voice).
+- **Emit**: `phases/7-observe.md` proposes voice deltas beside competency/spec deltas.
+- **Target**: `SOUL.md` — "## Voice deltas" ledger holds confirmed history.
+- **Kin**: `deltas.md` + `fold.md` (same propose→confirm→write discipline). No `add.py` command writes the voice.

package/skill/add/streams.md

@@ -3,48 +3,41 @@
 Load this when a milestone has more than one task and you want to run them concurrently.
 **Default:** when a project confirms `parallel + auto` as its run mode at setup
 (`phases/0-setup.md` "Run mode"), parallel streaming is the project default — an **opt-out**, not
-the opt-in it once was; downgrade in one step (`add.py autonomy set conservative --project`, or just
-run tasks one at a time). A project that kept the conservative run mode still treats this rubric as
-the opt-in escape hatch. Either way it changes nothing below.
+the opt-in it once was; downgrade in one step (`add.py autonomy set conservative --project`, or
+just run tasks one at a time). A project that kept the conservative run mode still treats this
+rubric as the opt-in escape hatch.
 
-It changes **no `add.py` code and no phase semantics**. It is a way *you, the
-orchestrator*, drive several tasks at once by reading the dependency DAG that
-`add.py status` already prints, and spawning one worker per ready task.
+It changes **no `add.py` code and no phase semantics**. It is a way *you, the orchestrator*,
+drive several tasks at once by reading the dependency DAG `add.py status` already prints and
+spawning one worker per ready task.
 
 ## The honest frame — this is pipelining, not N× speed
 
-With **one human reviewer** you cannot beat `review_time × N_tasks` (the human-led
-decision points are serial — `docs/10-setup-and-stages.md:91`). So the win is **not throughput**:
-it is that the reviewer is **never blocked waiting on a build**. While the human reviews
-task A's frozen bundle, the builds for B·C·D run behind *their* frozen contracts. You hide
-build latency under human latency. Do not promise more than that.
+With **one human reviewer** you cannot beat `review_time × N_tasks` (decision points are serial).
+The win is that the reviewer is **never blocked waiting on a build**: builds for B·C·D run behind
+*their* frozen contracts while the human reviews A. You hide build latency under human latency.
 
 ## The two queues
 
 Compute both from one `python3 .add/tooling/add.py status` — no new state:
 
-- **READY-QUEUE** — tasks in the active milestone where `phase ≠ done` **and** every
-  `deps=` task already shows `gate=PASS`. These are the only tasks a worker may pick up.
-  A task with unmet deps stays queued; a task finishing PASS unblocks its dependents on
-  the next `status`.
-- **REVIEW-QUEUE** — the irreducibly serial part: the **bundle approval** (contract
-  freeze) and any **Verify escalation**. One human, one queue. Present these one at a
-  time, never in a batch the human will approve without reading.
+- **READY-QUEUE** — tasks where `phase ≠ done` **and** every `deps=` task shows `gate=PASS`.
+  A task with unmet deps stays queued; a task finishing PASS unblocks its dependents.
+- **REVIEW-QUEUE** — the irreducibly serial part: the **bundle approval** (contract freeze) and
+  any **Verify escalation**. One human, one queue. Present these one at a time, never in a batch.
 
 ```
   add.py status ─► READY-QUEUE ──spawn workers──► builds run ──► REVIEW-QUEUE ──► done
-  (deps=PASS?)     (machine span)                 (concurrent)   (decision points,
-       ▲                                                          strictly serial)
-       └──────────────── a task gating PASS unblocks its dependents ──────────────┘
+  (deps=PASS?)     (machine span)                 (concurrent)   (decision points, serial)
+       ▲
+       └──────── a task gating PASS unblocks its dependents ──────────────────────────┘
 ```
 
 ## The DAG strategy — let the engine schedule the waves (`add.py waves`)
 
-Do **not** eyeball the READY-QUEUE by hand once a milestone has more than a couple of
-tasks — the engine computes the whole schedule from the dependency DAG `status` already
-holds. `add.py waves` (read-only, writes nothing) groups the active milestone's not-done
-tasks into **topological waves**, names the **critical path**, and emits an advisory
-**tier hint** — exactly the inputs you need to fan out effectively:
+Do **not** eyeball the READY-QUEUE by hand once a milestone has more than a couple of tasks.
+`add.py waves` (read-only) groups not-done tasks into **topological waves**, names the **critical
+path**, and emits an advisory **tier hint**:
 
 ```
 $ add.py waves
@@ -55,94 +48,67 @@ critical path: dag-scheduler → setup-run-mode  (2 tasks)
 tier hint: top → dag-scheduler, setup-run-mode; mid → the rest
 ```
 
-Read the schedule as a strategy, not a command:
-
-- **Wave = a fan-out batch.** Every task in a wave has all its in-milestone deps already
-  PASS, so the whole wave is spawnable at once (one worker per task, `isolation="worktree"`).
-  Finish a wave, gate its tasks PASS, then `add.py waves` again — the next wave is unblocked.
-- **Run the widest wave first.** It hides the most build latency under the human's review
-  latency (the honest frame above): more concurrent builds while the reviewer reads one bundle.
-- **Spend your strongest model on the critical path.** The critical-path tasks gate the most
-  downstream work, so a wrong-but-plausible result there is the costliest — give them the
-  **top** tier (`run.md` tiers); off-path tasks take **mid**. The tier hint is exactly this rule,
-  applied to the graph. It is **advisory** — graph position is a proxy for scope difficulty, not a
-  gate; override it when you know a task is harder than its position suggests.
-- **`--json`** (`{ milestone, waves, critical_path, critical_path_len, tiers, blocked }`) feeds a
-  runner that spawns the wave programmatically. `blocked` lists any task whose dep can never be
-  satisfied within this milestone (a cross-milestone dep) — surfaced, never silently dropped; a
-  `dependency_cycle` is refused with the offending members named (no schedule exists).
-
-What `waves` does **not** change: the irreducible floor below still holds — one human approval
-per contract, builds overlap but the review queue stays serial. `waves` decides *order and model*,
-never *whether the human gate fires*.
+- **Wave = a fan-out batch.** Every task in a wave has all in-milestone deps PASS, so the whole
+  wave is spawnable at once (`isolation="worktree"`). Finish a wave, gate tasks PASS, then
+  `add.py waves` again — the next wave is unblocked.
+- **Run the widest wave first** to hide the most build latency under human review latency.
+- **Spend your strongest model on the critical path.** Critical-path tasks gate the most
+  downstream work; off-path tasks take **mid**. The tier hint is advisory — override when you
+  know a task is harder than its position suggests.
+- **`--json`** (`{ milestone, waves, critical_path, critical_path_len, tiers, blocked }`) feeds
+  a runner that spawns programmatically. `blocked` lists tasks whose dep cannot be satisfied
+  within this milestone; a `dependency_cycle` is refused with the offending members named.
 
-## The autonomy level is the throttle (not a new flag)
+The irreducible floor holds — `waves` decides *order and model*, never *whether the human gate fires*.
 
-How much concurrency you actually get is set by each task's `autonomy:` header
-(`run.md`), not by this rubric:
+## The autonomy level is the throttle (not a new flag)
 
 | `autonomy` (TASK.md) | What serializes on the human | Concurrency |
 |----------------------|------------------------------|-------------|
-| `conservative` / `manual` | bundle approval **+** every Verify | pure pipelining — builds overlap, both gates queue (`manual` is the strict floor; same streams behaviour) |
+| `conservative` / `manual` | bundle approval **+** every Verify | pure pipelining — builds overlap, both gates queue |
 | `auto` (default) | bundle approval **only**; Verify auto-PASSes on evidence | real concurrency — only the decision point + residue escalations queue |
-| `auto` but **high-risk** | refused → must lower to `conservative` / `manual` (`unguarded_high_risk_auto`) | back to pipelining, by design |
+| `auto` but **high-risk** | refused → must lower (`unguarded_high_risk_auto`) | back to pipelining, by design |
 
-The irreducible floor is **one human approval per task at the contract decision point** — the decision point
-never drops to zero (`run.md:22`). That floor is correct; do not engineer around it.
+The irreducible floor is **one human approval per task at the contract decision point** — that
+floor never drops to zero (`run.md:22`). Do not engineer around it.
 
 ## Who writes what — the hard boundary
 
 <constraints>
-- **You (orchestrator)** own all shared writes: `MILESTONE.md`, and every
-  `add.py advance <slug>` / `add.py gate <outcome> <slug>` call. **Always pass the explicit
-  `<slug>`** — `advance`/`gate`/`phase` all take an optional task slug and act on it
-  (`add.py` `_resolve_task`); omitting it falls back to the single `active_task`, which
-  races once more than one stream is live. Name the task every time. Workers never run these.
-- **A worker** owns only its own `.add/tasks/<slug>/` — it builds `src/`, drives the
-  tests green, gathers evidence, and writes `SUMMARY.md` + OBSERVE deltas. It touches
-  **no sibling stream and no shared file**.
-- **Isolation**: spawn each worker with `isolation="worktree"` so concurrent builds
-  cannot collide. The worktree is discarded on failure; the task resets to its last-good
-  phase.
+- **You (orchestrator)** own all shared writes: `MILESTONE.md`, and every `add.py advance <slug>` /
+  `add.py gate <outcome> <slug>` call. Always pass the explicit `<slug>` — **name the task every time** —
+  omitting it falls back to the single `active_task`, which races once more than one stream is live.
+  Workers never run these.
+- **A worker** owns only its own `.add/tasks/<slug>/` — it builds `src/`, drives tests green,
+  gathers evidence, and writes `SUMMARY.md` + OBSERVE deltas. It touches **no sibling stream and
+  no shared file** — never write shared state (state.json, MILESTONE.md, a sibling's files).
+- **Isolation**: spawn each worker with `isolation="worktree"` so concurrent builds cannot
+  collide. The worktree is discarded on failure; the task resets to its last-good phase.
 </constraints>
 
 ## Design for failure (required)
 
 - **Fresh worktree base (verify base == HEAD)** — create each worker's worktree from current
-  `HEAD` **after** you commit the task's frozen specification bundle (spec · scenarios · contract · tests). A
-  worktree forked from a stale base forces the worker to recreate the frozen artifacts by hand
-  (the v10 dogfood hit exactly this). Before the worker starts, confirm `git -C <worktree>
-  rev-parse HEAD` equals the orchestrator's `HEAD`; if it drifted, `git merge` the base in first.
-  On a runner that creates each worktree **at spawn** from a pool (e.g. Claude Code), that pool can hand
-  out a STALE base, so the pre-spawn `rev-parse` evidence cell is unsatisfiable. The `unverified_fork_base`
-  check then **shifts** — it never skips: the worker's **step-0** syncs to base (`git merge` the orchestrator's
-  `HEAD`) and re-echoes `rev-parse HEAD`, which the orchestrator verifies at **merge-time**, before merge-back.
-  The pre-spawn check stays the DEFAULT for fresh-`HEAD`-worktree runners; the merge-time path is the additive
-  ALTERNATIVE for spawn-time runners — never a replacement of the pre-spawn rule.
-  **The engine executes this gate** (engine-merge-base-enforcement): run
-  `python3 .add/tooling/add.py wave-verify` before the first merge-back — it refuses a mismatched or
-  pending echo (`unverified_fork_base`) and an off-template ledger (`wave_ledger_malformed`, fail-closed);
-  `add.py check` is the standing monitor (red at `status: merging`, `fork_base_pending` WARN at `live`).
-- **Lease + timeout** — record which worker holds which task (in the wave ledger, below);
-  if a worker dies, release the claim back to READY (re-spawn, do not assume partial work is sound).
-- **Failure isolates** — a worker that hits a STOP-and-escalate (below) blocks only its
-  own task. Siblings keep running; the escalation joins the REVIEW-QUEUE.
+  `HEAD` **after** committing the task's frozen specification bundle. Confirm `git -C <worktree>
+  rev-parse HEAD` equals the orchestrator's `HEAD`; if drifted, `git merge` the base first.
+  On a pool-based runner (e.g. Claude Code) the pre-spawn check **shifts** to the worker's
+  **step-0**: sync to base and re-echo `rev-parse HEAD`, which the orchestrator verifies at
+  **merge-time**. The engine executes this gate (`engine-merge-base-enforcement`): run
+  `python3 .add/tooling/add.py wave-verify` before the first merge-back — it refuses a
+  mismatched or pending echo (`unverified_fork_base`) and an off-template ledger
+  (`wave_ledger_malformed`, fail-closed); `add.py check` is the standing monitor.
+- **Lease + timeout** — record which worker holds which task (in the wave ledger); if a worker
+  dies, release the claim back to READY.
+- **Failure isolates** — a worker that hits a STOP-and-escalate blocks only its own task;
+  siblings keep running and the escalation joins the REVIEW-QUEUE.
 - **Circuit-breaker** — if N workers fail in a wave, stop fanning out and fall back to
   sequential. Repeated failure means the scope was wrong, not the parallelism.
 
 ## Wave ledger — the wave's resume point
 
-A single task resumes from `state.json`; a wave used to resume from nothing — the
-task ↔ lease ↔ fork-base ↔ autonomy ↔ merge-order mapping lived only in the orchestrator's
-chat context, and the v12-1 recurrence proved that discipline without an artifact fails
-(the base check existed in prose and never ran). The ledger fixes both: it is the file you
-re-orient from, and its evidence cells cannot be filled without executing the checks.
-
-**The file** — `.add/milestones/<m>/WAVE.md`, orchestrator-owned like `MILESTONE.md` and
-`state.json`. ONE live wave per milestone at a time; opening a second while one is live is
-refused (`wave_already_live`). **Workers never read WAVE.md** — the orchestrator copies the
-relevant mid-wave decisions into each worker's PROMPT.md at spawn/respawn, so the worker
-contract below stays unchanged and no worker widens into sibling state.
+**The file** — `.add/milestones/<m>/WAVE.md`, orchestrator-owned. ONE live wave per milestone;
+opening a second while one is live is refused (`wave_already_live`). **Workers never read
+WAVE.md** — the orchestrator copies relevant decisions into each worker's PROMPT.md at spawn.
 
 ```markdown
 # WAVE.md — transient wave ledger (orchestrator-owned · one live wave per milestone)
@@ -162,48 +128,34 @@ base: <orchestrator HEAD at spawn — the sha every fork must equal>
 ```
 
 **Evidence cells, not ticks.** The fork-base cell holds the PASTED output of
-`git -C <worktree> rev-parse HEAD`, and it must equal `base:`. A tick is not evidence; a row
-you can only fill by running the command is the fresh-worktree-base check EXECUTING — the
-v12-1 lesson (words-exist ≠ method-works) closed structurally. Spawning a worker whose roster
-row lacks that evidence is refused (`unverified_fork_base`). On a spawn-time pool runner this
-PRE-spawn paste is unsatisfiable (the pooled base is stale until the worker syncs), so the cell
-instead holds the worker's **step-0** post-sync echo (still `== base:`) and the `unverified_fork_base`
-refusal **shifts to merge-time**, before merge-back — it shifts, it never lifts.
-
-**Lifecycle — open → consume → digest → delete.** Open the ledger when the first worker
-spawns. The serial integration Verify consumes it (the merge order is read from it, one
-worktree at a time). At wave close, absorb the evidence digest — wave base · roster→fork-base
-evidence · merge order · integration-Verify outcome — into `MILESTONE.md` as an append-only
-`## Wave log` block (this is the integration-Verify *record*, previously homeless), and only
-then remove the file. Removing WAVE.md before the digest is absorbed is refused
-(`digest_not_absorbed`) — the proof the checks ran must outlive the file.
-
-**Resume rule.** On session start, a live WAVE.md is the wave's resume point: re-orient from
-the file — roster, bases, decisions, merge order — never from conversational memory.
+`git -C <worktree> rev-parse HEAD` and must equal `base:`. Filling the row requires running the
+command — words-exist ≠ method-works. Spawning a worker whose roster row lacks that evidence is
+refused (`unverified_fork_base`). On a pool runner the cell holds the worker's **step-0**
+post-sync echo (still `== base:`) and the refusal **shifts to merge-time**.
+
+**Lifecycle — open → consume → digest → delete.** Open when the first worker spawns. At wave
+close, absorb the evidence digest — base · roster fork-base · merge order · integration-Verify
+outcome — into `MILESTONE.md` as an append-only `## Wave log` block, then remove the file.
+Removing WAVE.md before the digest is absorbed is refused (`digest_not_absorbed`).
+
+**Resume rule.** On session start, a live WAVE.md is the wave's resume point: re-orient from the
+file — roster, bases, decisions, merge order — never from conversational memory.
 
 ## Merge is serial — integration Verify
 
-Parallel build, **serial integration**. After workers return, you merge the worktrees
-one at a time and run the **integration** Verify — the concurrency / architecture / layering
-checks that `run.md:102` says automation cannot judge. Two green tasks in isolation can
-still conflict when merged; this step is where that surfaces. Never auto-pass it.
+Parallel build, **serial integration**. After workers return, merge worktrees one at a time and
+run the **integration** Verify — the concurrency / architecture / layering checks automation
+cannot judge. Two green tasks in isolation can still conflict when merged. Never auto-pass it.
 
 Each worktree carries a full copy of `.add/`. Merge back **only** `src/`, `tests/`, and the
 worker's own `.add/tasks/<slug>/` (TASK.md · SUMMARY.md) — `.add/state.json`, `MILESTONE.md`,
-and the live `WAVE.md` stay orchestrator-owned, or a parallel merge will drag stale state back.
+and the live `WAVE.md` stay orchestrator-owned.
 
 ## The worker contract — portable across coding agents
 
-A worker **is** the dynamic run (`run.md`) for one task. Keep two things separate:
-
-- **The contract** (below) — the prompt. It is **agent-agnostic**: it names no vendor tool,
-  no model, no spawn API. It is a durable ADD artifact, like the spec and the tests.
-- **The adapter** (next sections) — the thin, swappable mapping that tells *one* runner
-  (Claude Code · Codex · opencode · pi-mono · any CLI agent) how to launch the contract.
-
-This split is the whole point: the same frozen contract runs on any agent; only the adapter
-changes. Fill every `{{...}}` per stream. The ADD-specific value is `<touch_boundary>` + the
-"return a verdict, never write shared state" rule — they are identical on every runner.
+A worker **is** the dynamic run (`run.md`) for one task. The contract below is **agent-agnostic**:
+no vendor tool, no model, no spawn API — a durable ADD artifact. The adapter (next sections) is
+the thin, swappable mapping for one runner. Fill every `{{...}}` per stream.
 
 ```xml
 <!-- PROMPT.md — dropped into the worker's worktree, or passed inline. No runner-specific tokens. -->
@@ -227,7 +179,7 @@ Score confidence (0-1) on Completeness · Clarity · Practicality · Optimizatio
 Self-Eval; if any < 0.9, refine before returning.
 </persona>
 
-<touch_boundary>   <!-- from run.md:56-73; the worker's contract, identical on every runner -->
+<touch_boundary>   <!-- from run.md; the worker's contract, identical on every runner -->
 MAY:  rewrite code in src/ · drive tests green WITHOUT weakening them · gather verify evidence.
 MUST NOT: edit the frozen CONTRACT or locked scope · weaken/delete/skip any test ·
           touch §1–§3 bundle artifacts · write MILESTONE.md / state.json / any sibling stream.
@@ -235,7 +187,7 @@ STOP-and-escalate (return your findings; do not decide):
   • a discovered scope/contract gap  → backward-correction, reopen Specify (principle 4)
   • any SECURITY finding              → HARD-STOP, always
   • a concurrency/timing OR architecture/layering risk the tests cannot exercise
-  • [include this bullet when autonomy is conservative OR manual — any lowered rung] the verify gate itself — STOP for the human
+  • [include this bullet when autonomy is conservative OR manual] the verify gate itself — STOP for the human
 Auto-PASS only if autonomy=auto AND: all tests green · coverage not decreased · no test weakened ·
   no contract edited · loops dry · completeness-critic clean · no residue above. Log it as
   auto-resolved, naming this run as owner — never forge a human signature.
@@ -247,9 +199,8 @@ Auto-PASS only if autonomy=auto AND: all tests green · coverage not decreased
 </context_files>
 
 <expertise>
-Adopt the persona above. If your runner supports specialist injection — a Claude Code skill,
-a Codex/opencode system-prompt preamble, an agent profile — load the one matching {{DOMAIN}}.
-If it does not, the persona IS your expertise.
+If your runner supports specialist injection (a Claude Code skill, a system-prompt preamble, an
+agent profile), load the one matching {{DOMAIN}}. Otherwise the persona above IS your expertise.
 </expertise>
 
 <tools>
@@ -259,8 +210,8 @@ ripgrep otherwise. Design every IO path for failure — timeouts, retries, rollb
 
 <return>   <!-- the worker PROPOSES; the orchestrator RECORDS. A worker never runs add.py. -->
 End with a structured verdict AND write the same into SUMMARY.md in the task dir, then
-**commit SUMMARY.md + deltas.md** in the worktree (uncommitted worktree files survive only by
-harness courtesy — commit them so the serial-integration merge-back carries your report):
+**commit SUMMARY.md + deltas.md** in the worktree (uncommitted files survive only by harness
+courtesy — commit them so the serial-integration merge-back carries your report):
 { task, outcome: PASS|RISK-ACCEPTED|HARD-STOP|ESCALATE, evidence: <tests+coverage>,
   residue: [security|concurrency|architecture findings], deltas: [open lessons learned] }.
 Do NOT touch add.py or any shared file — the orchestrator gates on your verdict.
@@ -270,23 +221,20 @@ Do NOT touch add.py or any shared file — the orchestrator gates on your verdic
 ## Choosing the model — vendor-neutral tiers
 
 ADD picks a **tier** from the scope's nature; the adapter maps the tier to the runner's model id.
-The contract is identical whichever model runs it (the model is disposable, like the code):
 
 | Tier | When | Claude Code | Any other runner |
 |------|------|-------------|------------------|
 | **mid** | ordinary, well-tested scope; clear contract | `sonnet` | the runner's balanced model |
 | **top** | complex / ambiguous / cross-cutting / broad scope of impact | `opus` | the runner's strongest reasoning model |
 
-Two rules sit **above** model choice and never bend:
-- **High-risk ⇒ a lowered rung (`conservative` or `manual`), regardless of model** (`run.md` high-risk guard). A
-  stronger model does not buy back the human gate.
-- **Security residue always escalates** — no tier and no model auto-passes it.
+Two rules sit **above** model choice: **high-risk ⇒ a lowered rung (`conservative` or `manual`),
+regardless of model** — a stronger model does not buy back the human gate. And **security residue
+always escalates** — no tier auto-passes it.
 
 ## The spawn adapter — one thin mapping per runner
 
 ADD needs six capabilities from any runner. **Isolation is the one ADD owns itself** (a git
-worktree), so streams stay portable even on a runner with no native sandbox — ADD makes the
-worktree, then points the agent at that directory.
+worktree), so streams stay portable even on a runner with no native sandbox.
 
 | ADD needs | Abstract | Claude Code (verified reference) | Any CLI agent — Codex · opencode · pi-mono · … |
 |-----------|----------|----------------------------------|-----------------------------------------------|
@@ -297,16 +245,9 @@ worktree, then points the agent at that directory.
 | domain expertise | skill / preamble | a Claude skill in `<expertise>` | a system-prompt / profile preamble |
 | return a verdict | structured | final message (optionally a schema) | stdout JSON the orchestrator parses |
 
-The **hint of `Task` spawn** is the Claude Code column — the worked reference. For any other
-agent the recipe is the same shape: `git worktree add` → point the agent CLI at that dir with
-the chosen model → it reads `PROMPT.md` → you parse its verdict.
-
 > **Honesty:** only the Claude Code column is verified. The CLI forms for Codex/opencode/pi-mono
-> are *illustrative shapes*, not confirmed flags — exact syntax differs per runner and version;
-> confirm with the `find-docs` skill. The portable, durable parts are the **contract** and the
-> **six-capability mapping**, never any one runner's flags.
+> are *illustrative shapes* — confirm exact syntax with the `find-docs` skill.
 
 When workers return, **you** record each outcome with the explicit slug — `add.py advance <slug>`
 as evidence lands, `add.py gate PASS|RISK-ACCEPTED|HARD-STOP <slug>` at verify — then re-read
-`status` to refill the READY-QUEUE. The worker proposes a verdict; the orchestrator records it.
-That split is exactly what lets a non-Claude worker take part without ever touching shared state.
+`status` to refill the READY-QUEUE. The worker proposes; the orchestrator records.