greprag 5.60.4 → 5.60.6

package/skill/greprag/docs/setup.md

@@ -56,21 +56,17 @@ but turns are not saving, the most likely cause is untrusted hooks or an old
 session that started before trust. Tell the user to open Codex Desktop Settings
 -> Settings -> Hooks, trust the GrepRAG commands, and restart Codex.
 
-Codex live inbox delivery requires the sidecar. Public installs should use the
-startup helper above. For foreground/manual testing:
+Codex live inbox delivery uses the startup watcher. Public installs should use
+the startup helper above. For foreground/manual testing:
 
 ```bash
 greprag codex watch --session <8hex-or-full-codex-session-id>
 ```
 
 If `--session` is omitted, it uses the latest Codex session recorded in
-`~/.codex/session_index.jsonl`. The sidecar stays attached to GrepRAG inbox SSE
-and routes agent-visible control through the nonce-bound BREAKTHROUGH protocol.
-Private app-server continuation may create the target turn, but success requires
-visible `BREAKTHROUGH_ACK:<nonce>` output; persisted history or an empty turn is
-not delivery. `codex exec resume <session> -` can append to Codex's thread store,
-but it is not a reliable visible wake in the active Desktop pane and must be
-treated as fallback/diagnostic only.
+`~/.codex/session_index.jsonl`. `greprag send` persists messages; the startup
+watcher drains unread messages + SSE and performs target-local task delivery.
+Turn hooks surface stored unread messages at Codex turn/tool/session boundaries.
 Use `greprag codex startup status` to inspect the login entry and
 `greprag codex startup remove` to uninstall it.
 
@@ -83,18 +79,16 @@ On Windows, the watcher should run hidden. If the user sees a persistent
 `greprag codex startup install` to replace it with the hidden launcher. Logs
 live at `~/.greprag/logs/codex-watch.log`.
 
-`codex-notify` and `codex-inbox` remain fallback steering. If the sidecar is not
-running, messages are stored and can surface on the next user prompt or after a
-later tool call, but they do not wake idle Codex.
-
-Visible wake and live action are different checks. The sidecar may deliver a
-visible delegated turn to Codex, while that turn still fails to run commands if
-the local Codex sandbox is unhealthy. On native Windows, this can appear as
-`windows sandbox: spawn setup refresh`. If `greprag codex doctor --wake-test`
-reports only CLI-resume fallback or wake action as unsupported, describe live
-push as unconfirmed/non-visible and rely on turn-bound inbox steering until the
-app-layer path is available. Do not enable unsafe sandbox bypass as a public
-default.
+`codex-notify` and `codex-inbox` remain turn-boundary steering. `greprag send`
+always stores the ordinary message first. If the recipient task is live, use
+native Codex task messaging to wake it and have that peer read/reply; if it is
+not live, the row remains available for the next prompt. Only the recipient's
+actual peer response proves delivery.
+
+Target-local task delivery and command execution are separate checks. The
+watcher can deliver stored work while the local Codex sandbox is unhealthy. On
+native Windows, this can appear as `windows sandbox: spawn setup refresh`. Do
+not enable unsafe sandbox bypass as a public default.
 
 ## claude-code
 

package/skill/mechanic/SKILL.md

@@ -61,6 +61,30 @@ Same gate the hourly compactor applies at write-time — Mechanic and compactor
 - **Cross-project carve-out.** Default to the current project (resolved via `greprag fix list`). The Phase 0 census MAY read sibling queues to show where fixes piled up; *draining* one requires the operator to name it, and every `add`/`delete` against it MUST carry `--project <that-project>`. Never touch a sibling silently.
 - **Harness scope is mandatory.** Friction carries its source harness (`claude-code`, `codex`, `opencode`). Repairs to hooks/skills/watchers must target that harness with `greprag mechanic install ... --harness <name>`. In a Codex session, default to `--harness codex`; use `--harness all` only for deliberately portable mechanisms.
 
+## Codex Mechanic chip handoff
+
+When this method is loaded inside a Codex task whose visible title is
+`MECHANIC: <Mission>`, the harness is **Codex** and the task is already a
+visible, ordinary writable Mechanic chip. Its scope is root-cause repair in the
+Codex-provided checkout: inspect the live hooks/CLI, implement the reusable
+repair, test it, commit it, and report DONE or BLOCKED to the parent. Do not
+create another child or use an internal subagent unless the parent explicitly
+changes that assignment.
+
+The Codex control points are: native task/thread identity; the Codex-provided
+worktree and cwd; the initial UserPromptSubmit binding; SessionStart/PostToolUse
+context; and native parent-child completion. Preserve those boundaries while
+repairing them--never silently turn the chip into a same-session subagent.
+
+ABOUT TO dispatch or replace a visible Codex chip? STOP — load
+`codex-chip-spawn` first and create the child with Codex Desktop's native
+`codex_app__create_thread` project worktree target. For 1–2 children the current
+task is the implicit LEAD; for more than two children or shared seams, load
+`chip-leader` and create a separate `LEAD: <Mission>` that dispatches exact
+`Chip A/B/C: <Specific Purview>` tasks.
+`multi_agent_v1__spawn_agent` is only an ephemeral same-session subagent and
+never satisfies a visible-chip requirement.
+
 ## Phase 0 — Fix digestion
 
 A fix is a raw, undigested signal. Auto-detected friction fixes carry a type; hand-dropped ones are freeform. Digestion does two jobs per fix — **repair** the mechanism and/or **record** the durable gotcha — and runs FIRST.

package/skill/templates/chip-bootloader.md

@@ -2,27 +2,32 @@
 
 No `spawn_task`? Use OpenCode Desktop HTTP spawn (preferred) or manual paste.
 
-## Preferred: machine spawn
+## Preferred: quick chip (path A)
+
+Initiator is LEAD — no separate LEAD session:
 
 ```bash
+greprag opencode chip goal create \
+  --objective "…" --final-state "…" \
+  --criterion ship:… \
+  --owner-session <this-8hex> --owner-role leader
+
 greprag opencode chip spawn \
   --title "Purview Name" --role worker --label A \
-  --goal-id <id> --covers <criterion> \
+  --goal-id <id> --covers ship \
   --task "…" \
   --parent-session <ses_…> --parent-greprag <8hex> \
   --model deepseek/deepseek-chat \
   --opencode-url http://127.0.0.1:<port> \
   --dispatch
-# → "Chip A: Purview Name"  (multi: --label B, C…)
-# close: greprag opencode chip close <id|ses_> --summary "…"
+# → "Chip A: Purview Name"
+# close: report → goal accept → greprag opencode chip close <id|ses_>
 ```
 
-Full multi-chip roles: `greprag load chip-leader-opencode`.  
-Fallback paste body + isolation notes: [docs/chip-bootloader-opencode.md](../../../docs/chip-bootloader-opencode.md)
-
-## Multi-chip?
+## Multi-chip mission (path B)?
 
-≥2 chips at one objective → STOP → `greprag load chip-leader-opencode` first.
+≥2 chips at one objective → STOP → `greprag load chip-leader-opencode`  
+(PLANNER → LEAD → nested goal → Chip A/B).
 
 ## Manual paste (API down only)
 
@@ -41,4 +46,4 @@ greprag send "DONE: … | commit=<sha> | checks=…" --to travis@greprag.com/<pa
 # or BLOCKED: …
 ```
 
-`--model` required. Report-back is greprag inbox, not the parent OpenCode chat transcript.
+Workers always `--label A|B|C…`. `--model` required. Report-back is greprag inbox.

package/skill/templates/chip-leader-opencode.md

@@ -1,32 +1,53 @@
-# Chip Leader — OpenCode multi-chip (PLANNER → LEAD → workers)
+# Chip Leader — OpenCode multi-chip (path B)
 
-> Loaded via `greprag load chip-leader-opencode`. One chip → `greprag load chip-bootloader` or `greprag opencode chip spawn`. ≥2 chips at one objective → plan here first.
+> Loaded via `greprag load chip-leader-opencode` when ≥2 chips share one objective.
+> **One chip (or two independent ones)?** Skip this — use the **quick path** in
+> `chip-bootloader` / `greprag opencode chip --help` (initiator is LEAD).
 
-OpenCode has **no** `spawn_task`. Spawn is:
+## Two paths (both first-class)
 
-```
-POST /session { parentID?, title }     # Desktop HTTP API
-POST /session/{id}/prompt_async        # mission + model
-greprag send → parent inbox            # IN-FLIGHT / DONE / BLOCKED
-```
+| | **A — Quick** | **B — Mission (this doc)** |
+|---|---|---|
+| When | 1 chip, or independent jobs | ≥2 chips, seams, one objective |
+| Who is LEAD | **Initiator** (this session) | Explicit `LEAD:` chip |
+| Goal | `goal create --owner-role leader` owned by this 8-hex | PLANNER goal → nested LEAD goal |
+| Spawn | `worker --label A` (solo = A) | LEAD dispatches Chip A/B… |
+| Close | Parent accept + `close` | LEAD reconciles → accept → close |
 
-Wrapped by: **`greprag opencode chip spawn`** (prepare or `--dispatch`).
+**Hard fire for B:** about to spawn the **2nd chip at one objective** → stop and plan here.
 
-## Role ladder (same contracts as Codex)
+## Path A — Quick (default)
 
-| Title | Role | Job |
-|-------|------|-----|
-| `PLANNER: <Mission>` | planner | Creates mission goal + acceptance criteria; launches one LEAD; read-only |
-| `LEAD: <Mission>` | leader | Decomposition, child dispatch, integration, goal accept, closeout |
-| `Chip A: <Purview>` | worker | **Always** letter-titled (`--label A`); multi-chip uses A,B,C… never bare `Chip:` |
-| `ADVISOR: <Purview>` | advisor | Read-only; fundamental blocker only |
-| `MECHANIC: <Purview>` | mechanic | Live friction; not routine execution |
+```bash
+greprag opencode chip goal create \
+  --objective "…" --final-state "…" \
+  --criterion ship:… \
+  --owner-session <this-greprag-8hex> \
+  --owner-role leader
 
-## Mission flow
+greprag opencode chip spawn \
+  --title "Purview" --role worker --label A \
+  --goal-id <id> --covers ship \
+  --task "…" \
+  --parent-session <this-ses_…> \
+  --parent-greprag <this-8hex> \
+  --model deepseek/deepseek-chat \
+  --opencode-url http://127.0.0.1:<port> \
+  --dispatch
+
+# later:
+greprag opencode chip report <chip> --summary "…" --evidence ship:…
+greprag opencode chip goal accept <id> --owner-session <this-8hex> --summary "…"
+greprag opencode chip close <chip> --summary "…"
+```
+
+No separate LEAD chip. No bind-lead. Initiator owns the goal and closeout.
+
+## Path B — Mission flow
 
 1. **PLANNER** creates the mission goal (`--owner-role planner`).
-2. Spawn **one LEAD** under that goal (`--role leader --covers …`). LEAD is write-capable.
-3. LEAD creates a **nested** goal:
+2. Spawn **one LEAD** under that goal (`--role leader --covers …`).
+3. LEAD creates a **nested** goal + bind:
    ```bash
    greprag opencode chip goal create \
      --objective "…" --final-state "…" \
@@ -40,25 +61,24 @@ Wrapped by: **`greprag opencode chip spawn`** (prepare or `--dispatch`).
    ```
 4. LEAD spawns workers against the **nested** goal:
    `--role worker --label A --title "…" --goal-id <nested> --covers ship --parent-greprag <lead-8hex>`.
-5. Workers: `IN-FLIGHT` → work → `DONE`/`BLOCKED`. Parent records evidence:
-   `greprag opencode chip report <chip> --summary "…" --evidence ship:…`
-6. Accept nested goal, then planner goal:
-   `greprag opencode chip goal accept <id> --owner-session … --summary "…"`
-7. Close chips (accept-gated):
-   `greprag opencode chip close <chip|ses_> --summary "…"`  
-   (`--force` / `--keep-open-goal` escape hatches; `--keep-session` leaves Desktop tab)
+5. Workers: `IN-FLIGHT` → work → `DONE`/`BLOCKED`. Parent: `report --evidence …`.
+6. Accept nested goal, then planner goal; then `close` chips.
+
+## Role titles (exact)
+
+`PLANNER: …` · `LEAD: …` · `Chip A: …` / `Chip B: …` · `ADVISOR: …` · `MECHANIC: …`  
 
-## Mode A vs Mode B (topology — still required)
+Workers **always** `--label A|B|C…` (solo = A). Never bare `Chip:`.
 
-| | **Mode A — Mission** | **Mode B — Orchestrator** |
+## Mode A vs Mode B topology (still for path B)
+
+| | **Mission topology** | **Orchestrator topology** |
 |---|---|---|
 | When | ≥2 chips, one objective | Independent issues |
-| Branch | Integration branch; chips merge into it | Per-chip / per-repo |
+| Branch | Integration branch | Per-chip / per-repo |
 | Gate | One reviewed merge to master | Per-chip verify |
 
-**Hard fire:** about to spawn the 2nd chip → stop and plan.
-
-## Spawn command (canonical)
+## Spawn flags (canonical)
 
 ```bash
 greprag opencode chip spawn \
@@ -69,31 +89,25 @@ greprag opencode chip spawn \
   --parent-session <ses_…> \
   --parent-greprag <8hex> \
   --model deepseek/deepseek-chat \
-  --opencode-url http://127.0.0.1:<desktop-port> \
+  --opencode-url http://127.0.0.1:<port> \
   --dispatch
-# title becomes: Chip A: Auth Middleware
-# multi-chip: --multi-chip --label B --title "Other Purview" → Chip B: …
+# → "Chip A: Auth Middleware"
 ```
 
-Close when done (deletes OpenCode session + archives record):
-```bash
-greprag opencode chip close <chipId|ses_…> --summary "merged + verified"
-# --keep-session to leave the Desktop session
-```
+Close: `greprag opencode chip close <chipId|ses_> --summary "…"`  
+(`--keep-session` · `--force` · `--keep-open-goal`)
 
-- **Workers always `--label A|B|C…`** (solo = A). No bare `Chip:` titles.
-- **`--model` is required** (Desktop defaults can 401).
-- **`--top-level`** if you need a session list entry without nesting under parent.
-- Desktop **does not auto-focus** API-created sessions — open session list / cycle children after spawn.
-- Auth: `OPENCODE_SERVER_USERNAME` + `OPENCODE_SERVER_PASSWORD`.
+- **`--model` required** (Desktop defaults can 401).
+- **`--top-level`** if you need a session-list entry without nesting.
+- Desktop **does not auto-focus** API-created sessions.
 
 ## Isolation
 
-Prefer a dedicated `chip/<slug>` branch per chip. Worktrees optional. Leases/manifests for OpenCode live under `~/.greprag/opencode-chips/` (v1 record). Goals share `~/.greprag/chip-goals/`.
+Prefer `chip/<slug>` branch per chip. Records: `~/.greprag/opencode-chips/`. Goals: `~/.greprag/chip-goals/`.
 
 ## Do not
 
-- Paste bootloader by hand when `opencode chip spawn` is available.
-- Dispatch workers from a planner-owned goal (LEAD nested goal required).
+- Force path B for a single chip — use path A.
+- Dispatch workers from a **planner** goal (planner accepts LEAD only).
 - Skip IN-FLIGHT or end without DONE/BLOCKED.
-- Use Codex `create_thread` / Block 1-2 `spawn_task` here — wrong harness.
+- Use Codex `create_thread` / Claude `spawn_task` here — wrong harness.

package/skill/templates/chip-leader.md

@@ -1,223 +1,83 @@
-# Chip Leader — plan a MULTI-CHIP mission before the first spawn
-
-> Loaded via `greprag load chip-leader` — usually from *within* `greprag load
-> chip-spawn` (its "Part of a multi-chip mission?" gate), the moment you realize
-> ≥2 chips aim at one objective, or you're about to spawn a 2nd chip. A single
-> chip → straight to `greprag load chip-spawn`. Two or more → STOP, pick a mode
-> below, and plan first.
-
-`chip-spawn` launches one worker correctly; **chip-leader is the commander** who
-plans the whole mission *before* any worker deploys and reconciles them *after*.
-Topology is a planning decision, not an execution afterthought — draw the map
-before mobilizing the troops.
-
-## Codex Desktop standard
-
-For Codex, the `PLANNER: <Mission>` first creates one durable mission goal with
-objective, observable final state, and criterion IDs, then launches exactly one
-`LEAD: <Mission>` at `gpt-5.6-luna/xhigh`. The LEAD owns decomposition, child
-dispatch, integration, checks, release proof, and immediate child closeout.
-Before dispatch it assigns each workstream a unique letter and human
-purview—`Chip A: <Specific Purview>`, `Chip B: ...`—plus disjoint leases and
-explicit `--covers` criteria. Every worker spawn uses `--multi-chip`, its
-`--label`, and its proper `--title`; workers stay Luna/xhigh. `ADVISOR:` is a
-read-only Sol/high escape hatch only for a documented fundamental blocker.
-
-Dispatch uses the native-v4 `createRequest` exactly once. It contains the real
-mission, the parent-selected model/effort, and native worktree setup; never send
-a bootstrap prompt or a second assignment. The initial hook binds before tool
-use, the leader applies the exact task title as soon as the resolved task ID is
-available, attach emits `IN-FLIGHT`, and the child reports evidence through the
-parent's breakthrough inbox.
-
-Closeout is parent-owned and immediate: review each report and commit, integrate
-it, verify the whole mission, explicitly accept the goal, then follow each
-returned closeout entry (archive the native task first; run its cleanup command).
-A report is not acceptance, cleanup never implies
-acceptance, and an accepted/integrated child should not remain in the active
-task list. These rules supersede any Claude `spawn_task`, Block 1/Block 2, or
-manual worktree instructions later in this shared template when operating in
-Codex.
-
-After an interruption, resume only attached nonterminal chips and require their
-nonce-bound breakthrough acknowledgment. A terminal/invalid launch cannot
-respond: archive/stop it, durably `goal exclude` it with a concrete reason, and
-spawn a replacement under the same goal. Excluded evidence never counts. If the
-mission itself is abandoned, stop every chip and `goal cancel`; cancellation
-permits cleanup but never masquerades as acceptance.
-
-**Hard fire:** the moment you're about to spawn the **2nd chip**, stop and plan.
-Spawn-then-plan is the exact failure this prevents.
-
-## Two modes — pick ONE before planning
-
-Forks on one question: **do the chips share one objective, or are they independent?**
-
-| | **Mode A — Mission** | **Mode B — Orchestrator** |
-|---|---|---|
-| **When** | ≥2 chips at ONE objective, usually ONE repo | N independent issues, often DIFFERENT repos |
-| **Relationship** | chips have seams — shared files, data contracts, ordering | disjoint by construction — no seams |
-| **Branching** | one integration branch `feature/<slug>`; chips base off it, merge into it | each chip self-contained in its OWN repo; no integration branch |
-| **Merge** | leader reconciles all → ONE reviewed merge to master | each chip merges to ITS OWN repo's default, independently |
-| **Gate** | whole feature run end-to-end on the integration worktree | per-chip verification; no cross-chip gate |
-| **Leader's core job** | merge-reconciliation across seams | **dispatch + completion judgment** — chips report back, you adjudicate |
-
-Both modes share decompose, dispatch (via `greprag load chip-spawn`), the label
-discipline, and the single-watcher rule. They diverge on topology and the back
-half (reconcile vs. adjudicate).
-
-## Mode A — Mission
-
-### The invariant that drives everything
-
-`master` is the production trunk — `git push origin master` deploys. So:
-- **Merged = ships on the next deploy.** A flag gates *behavior*, not *startup
-  code*: schema/migration statements and import-time side effects run regardless
-  of any feature flag. "Flag-gated" ≠ "inert on master."
-- **Chips NEVER merge directly to master.** They reconcile on a feature
-  integration branch. Master only ever holds verified, deployable work.
-- One objective → **one integration branch** → **one reviewed merge to master**.
-
-### Phase 1 — Decompose
-
-Break the objective into workstreams (one per chip). For each, name:
-- **Label** — a stable letter (`A`, `B`, `C`…). It becomes the chip's title prefix
-  (`Chip A: <verb>`) and the one handle you *and* the chip use end-to-end (title,
-  report-back self-ID, merge log). Letters, not numbers — workstream IDs, not an
-  execution order.
-- **Parallel or sequential** — can it run independently, or need another's output?
-- **Seams** — every place two workstreams touch: *shared file* (both edit the same
-  module → serialize at merge), *data contract* (one produces what another consumes
-  → producer merges first), *ordering dependency* (B meaningless until A lands).
-- Disjoint workstreams (no shared file, no contract) → merge in any order.
-
-Output the plan explicitly and **confirm it with the user before dispatching.**
-
-### Phase 2 — Topology
-
-Detect the default branch first (`git -C <main> symbolic-ref refs/remotes/origin/HEAD`
-→ strip prefix; fallback `master`), then:
-
-```bash
-git -C <main> worktree add .claude/worktrees/feature-<slug> -b feature/<slug> <default>
+# Leader Mission
+
+Load this method when the work needs a dedicated orchestrator: more than the
+quick 1–2 visible chips, shared files or contracts, ordering, integration, or
+another coordination seam.
+
+## Identity first
+
+Before any child is created, the orchestrating task becomes the dedicated
+leader by renaming itself exactly:
+
+```text
+LEAD: <Mission>
+```
+
+Children use the exact ordinal discoverability schema:
+
+```text
+Chip A: <Specific Purview>
+Chip B: <Specific Purview>
+Chip C: <Specific Purview>
+```
+
+Naming identifies the workstream and makes the task legible. It does not grant
+execution authority; every child remains an ordinary writable chip.
+
+## Quick versus Leader
+
+- **Quick:** the current task renames itself `LEAD: <Mission>` and directly
+  spawns 1–2 children. No separate leader task is created.
+- **Leader:** the initiator creates a separate `LEAD: <Mission>` task. That
+  dedicated task owns decomposition, child dispatch, seam reconciliation,
+  checks, integration, parent messaging, and cleanup.
+
+This template is for the second shape. If the mission fits the quick shape,
+load `greprag load codex-chip-spawn` and keep the initiator as the implicit
+LEAD.
+
+## Mission worksheet
+
+Before dispatch, record:
+
+```text
+Mission: <observable outcome>
+Integration target: <branch/worktree or parent review point>
+Chip A: <Specific Purview> — <dependency/seam>
+Chip B: <Specific Purview> — <dependency/seam>
+Chip C: <Specific Purview> — <dependency/seam>
+Order: <parallel work, then required reconciliation order>
+Checks: <whole-mission verification>
+Closeout: <who integrates and cleans each worktree>
 ```
 
-Decide + write down: each chip's **base branch** = `feature/<slug>` (not master);
-each chip's **merge target** = `feature/<slug>` (never master); **merge order**
-(seam-sharers serialize, producer/base first; disjoint chips free); **test gate**
-(the `feature-<slug>` worktree is where the whole feature runs end-to-end).
-
-### Phase 3 — Dispatch
-
-Spawn each chip via `greprag load chip-spawn`, and in each brief include the four
-things the plan decided:
-1. **Its seam** — which files/contracts it shares, and what to leave clean.
-2. **Its base branch** — branch off `feature/<slug>` (adjust chip-spawn's Block 1
-   `git worktree add ... <base>`).
-3. **Its merge target** — `feature/<slug>`, never master. Chips commit to their own
-   branch + report back; the leader does the merges.
-4. **Its label** — three places (spawn title alone does NOT reach FleetView's
-   watcher registry, which is auto-generated):
-   - **Spawn title** — `Chip <Label>: <verb phrase>`.
-   - **Registry retitle (Block 1)** — give the chip a line to run right after
-     worktree setup: `greprag session retitle <its-own-8hex> "Chip <Label> — <workstream>"`.
-   - **Report-back self-ID** — open its report with its label ("Chip B — DONE: …").
-
-Arm ONE inbox watcher for all the chips' reports (never double-arm).
-
-**Spawning is a commitment.** A `spawn_task` is not a draft: launching creates a
-worktree + branch, and even a queued chip occupies its slug. Finalize the brief
-before you spawn; to change/replace a chip, **cancel the old one FIRST** (dismiss
-if queued; for a launched one, stop the session, then `git worktree remove` +
-`git branch -D`), then spawn. Same-slug collision → spawn the replacement under a
-fresh slug rather than fighting an OS file lock.
-
-### Phase 4 — Reconcile + integrate
-
-As chips report `DONE`:
-1. **Merge into `feature/<slug>` in the planned order** (`--no-ff`, from the
-   integration worktree). Seam-sharers: base first, then the dependent.
-2. **On conflict at a seam** — expected; resolve it (you mapped it in Phase 1). On
-   an *unexpected* conflict, stop and re-examine the decomposition.
-3. **Recommend closing the chip out** as soon as its commits are reconciled (or
-   even just committed + reported) — the branch survives the session; you need the
-   branch, not the live session, to merge later. Don't wait to be asked.
-4. **Run the full feature end-to-end on the integration worktree** — the gate.
-5. **One reviewed merge to master, then clean up.** Only after the gate passes:
-   `feature/<slug>` → master, then deploy. Then sweep the worktrees (the cleanup
-   skill keys on "merged into master," so it won't remove chips until then).
-
-**PRUNE AT THE MERGE (HARD RULE).** Each chip's *worktree* dies the moment its
-branch merges into its target — same breath, never batched. The *branch* is the
-safety net and lives until the master merge. Stale worktrees pile up precisely
-because cleanup was deferred.
-
-## Mode B — Orchestrator (independent fan-out, cross-repo)
-
-A list of independent issues, each self-contained in its own repo. Nothing to
-integrate — every chip lives and ships on its own. Your job is **dispatch +
-completion judgment**: each chip reports back because you hold the "done"
-criterion.
-
-### B1 — Decompose AND screen
-
-One chip per issue — but **screen each candidate first; not every issue is a
-chip.** A chip must be a self-contained coding task in a clean git repo. Drop the
-rest and say why: interactive-with-operator (needs his login/judgment), ops/comms
-(submissions, third-party coordination, email), cross-repo config writes (e.g.
-editing a skill under `~/.claude` — not a clean worktree target; do inline),
-operator-owned manual tasks. (Reporting "none of these are chips" is a correct,
-useful result.)
-
-For each survivor record: **Label** (`A`/`B`/`C`…), **Target repo** (its root,
-from `~/.greprag/projects.json` → becomes the chip's `cwd`), **Completion
-criterion** (what "done" means, in YOUR words — you'll judge against it).
-
-Output the screened plan (chips + dropped non-chips with reasons); confirm before
-dispatch.
-
-### B2 — Topology: none shared
-
-No integration branch. Each chip: **cwd** = its own repo root; **base branch** =
-that repo's own default (detect per-repo); **merge target** = that repo's default,
-or hold-for-review (default to hold so you adjudicate before anything ships).
-
-### B3 — Dispatch
-
-Spawn each via `greprag load chip-spawn` with: `cwd` set; Block 1 worktree off the
-repo's default; the label discipline; Block 2 reporting to **your** session; the
-**completion criterion embedded in the brief**. Arm ONE watcher. Re-dispatch
-discipline (cancel-before-respawn) identical to Mode A.
-
-### B4 — Adjudicate (replaces reconcile)
-
-As each chip reports `DONE`: **verify against the criterion** (read the diff, run
-it if needed — don't take "DONE" on faith); **decide per chip** (merge to its own
-repo's default + deploy, or send back with specifics); **surface close-out per
-chip** as it lands. No single end-of-mission master merge — N independent ones.
-
-## Safety rules
-
-- **Never spawn the 2nd chip without picking a mode + planning.** Mode A for one
-  shared objective; Mode B for independent issues.
-- **Mode B: screen before you spawn.** Interactive, ops/comms, cross-repo-config,
-  operator-owned tasks are NOT chips.
-- **Never spawn a chip while a stale one for the same workstream is in flight —
-  CANCEL first.** `spawn_task` is a stateful commitment.
-- **Mode A: never merge a chip branch to master.** Integration branch only.
-- **Never let "it's flag-gated" justify merging untested work to master.**
-  Migrations and startup code ignore feature flags.
-- **Confirm the decomposition with the user before dispatch.** Wrong seams =
-  painful merges.
-- **Surface close-out proactively** as each chip reconciles.
-
-## Execution depth (advanced)
-
-Orthogonal to mode: each workstream also picks a *vehicle* — bare subagent, a
-leader-direct workflow, a simple chip, or an **orchestrator chip** (a lean chip
-running an inner workflow swarm in its own worktree, for mixed-model missions
-needing isolation + a human gate). Mixed-model work cannot be a simple chip
-(`spawn_task` has no model param → chips are session-locked). Don't over-stack: a
-one-file fix gets a subagent, not a three-tier hierarchy. If you need the
-orchestrator-chip brief addendum or the recovery recipe for a chip mistakenly
-merged to master, ask the operator — those live in the chip-leader skill docs.
+Give each child one clear purview. Explain shared files, contracts, and
+ordering in the brief rather than relying on hidden coordination metadata.
+
+## Dispatch and closeout
+
+1. Rename the leader task before the first child spawn.
+2. Spawn each `Chip A/B/C: <Specific Purview>` with its own visible worktree
+   and the mission context it needs.
+   A child titled exactly `MECHANIC: <Mission>` must make `greprag load mechanic`
+   its first Setup action before diagnosis or edits.
+3. Keep children writable and let them investigate, edit, test, and commit
+   within their worktrees.
+4. Require each child to return `DONE` or `BLOCKED` through the native
+   parent-child task result, including the commit, checks, and caveats. Use
+   `greprag send` only for explicit cross-harness or peer messaging:
+
+   ```bash
+     greprag send "Chip A update — <commit> — <checks/caveats>" \
+     --to <handle>@greprag.com/<parent-session> \
+     --from-session <child-session>
+   ```
+
+5. Review reports, reconcile seams in the planned order, run the whole-mission
+   checks, and send the parent a concise closeout.
+6. The parent owns integration and cleanup. Do not silently delete a child
+   worktree or treat a report as acceptance.
+
+Do not introduce a separate read-only, lease, nested-goal, or delivery-proof
+layer just to make the mission look formal. The durable boundaries are the
+visible names, isolated worktrees, reports, `greprag send`, and cleanup.