opencode-thrum-pro 0.1.4 → 0.1.6

package/assets/skills/coordinator-running-brainstorm-cycles/SKILL.md

@@ -40,25 +40,23 @@ at every stage:
    the impl prompt** → 8. Hand off to coord for implementer dispatch.
 
 **Three explicit review gates** at stages 3, 6, and 7 — same dual-axis pattern
-each time (`verify-against-source` + a prose-quality reviewer, sonnet sub-agents
+each time (`verify-against-source` + a prose-quality reviewer, sub-agents (model per `choosing-subagent-models`)
 in parallel — see "Review-loop mechanics" below). Skipping any review gate is a
 documented anti-pattern. The brainstorm review catches design issues; the plan
-review catches contract-drift and quality issues `writing-plans`' internal
-reviewer misses; the prompt review catches plan→prompt translation errors before
-the implementer executes against them.
+review is the SOLE quality gate on the plan doc — the researcher authors the
+plan directly (no external tool with its own internal reviewer sits upstream of
+this gate); the prompt review catches plan→prompt translation errors before the
+implementer executes against them.
 
 ## Subagent model selection
 
-> **Model tiers:** pass an explicit `model:` on every dispatch — `sonnet`
-> (low effort) mechanical, `sonnet` (medium effort) judgment, Opus only on
-> operator-ask or a skill step that names it. See the
-> `choosing-subagent-models` skill for the full policy.
+> **Model tiers:** pass an explicit `model:` on every dispatch; choose model and effort per the `choosing-subagent-models` skill (read `runtime.role_models` at the moment of use). Never let a sub-agent inherit your own model.
 
 ### Prefer `efficient-multi-agent-research` for multi-part research
 
 When a research or investigation task has independent parts, reach for the
 `efficient-multi-agent-research` skill FIRST — it partitions the work across
-many cheap parallel subagents (sonnet-low gatherers, sonnet-medium synthesizers) instead of
+many cheap parallel subagents (cheap gatherers, judgment-tier synthesizers) instead of
 one expensive serial subagent. It is the preferred research path: cheaper,
 faster, and it keeps each subagent's context tight.
 
@@ -72,16 +70,16 @@ names only its stage-specific source.
 | Axis            | Reviewer                                                                                                       | Notes                                                                                                                                                                                                                                                                                                                                             |
 | --------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Conformance** | `verify-against-source` (thrum-owned skill)                                                                    | Does the artifact honor its INPUT(s)? Replaces `verify-against-plan` at prose gates — `verify-against-plan` BAILS without a code diff + a File-Structure table, so it cannot run on a brainstorm/plan/prompt. `verify-against-source` accepts a prose artifact + source doc with neither.                                                         |
-| **Quality**     | general-purpose sonnet + prose-quality rubric (PRIMARY) ∥ `superpowers:requesting-code-review` (SUPPLEMENTARY) | The general-purpose prose-quality pass (internal consistency, gaps, contradiction, ambiguity, scope creep) is AUTHORITATIVE. `requesting-code-review` runs on a DIFF, so point it at the artifact's own commit range (`HEAD~1..HEAD`) — gated on the skill being resolvable; skip gracefully if absent. ⚠️ **That is the diff of the `.md` file, NOT a diff against the production code the artifact describes** — this row does NOT cover the code axis. Prose-vs-code is Conformance's job (see `verify-against-source` § "Second comparison unit"). |
+| **Quality**     | general-purpose sub-agent (model per `choosing-subagent-models`) + prose-quality rubric (PRIMARY) ∥ `superpowers:requesting-code-review` (SUPPLEMENTARY) | The general-purpose prose-quality pass (internal consistency, gaps, contradiction, ambiguity, scope creep) is AUTHORITATIVE. `requesting-code-review` runs on a DIFF, so point it at the artifact's own commit range (`HEAD~1..HEAD`) — gated on the skill being resolvable; skip gracefully if absent. ⚠️ **That is the diff of the `.md` file, NOT a diff against the production code the artifact describes** — this row does NOT cover the code axis. Prose-vs-code is Conformance's job (see `verify-against-source` § "Second comparison unit"). |
 
-Both are `general-purpose`, `model: "sonnet"`, `run_in_background: true`. Wait
+Both are `general-purpose`, `model: <per choosing-subagent-models>`, `run_in_background: true`. Wait
 for BOTH before consolidating. Verify each BLOCKING against source before
 forwarding.
 
 ### Footer → commit → stamp (per stage)
 
 1. After the artifact is written, append the gate footer:
-   `<!-- THRUM-GATE: stage=<brainstorm|plan|prompt> next=<dual-review|writing-plans|project-setup|dispatch> -->`
+   `<!-- THRUM-GATE: stage=<brainstorm|plan|prompt> next=<dual-review|plan|project-setup|dispatch> -->`
 2. **Commit the artifact (WIP) including the footer** — this gives the
    supplementary `requesting-code-review` pass a real `HEAD~1..HEAD` range.
 3. Run the dual review against that range; each fix cycle commits its changes
@@ -120,7 +118,7 @@ forwarding.
 
 ### Soft pre-flight greps (the SOFT enforcement tier)
 
-Before invoking `writing-plans` (Phase 6) and before `project-setup` (Phase 7),
+Before writing the plan (Phase 6) and before `project-setup` (Phase 7),
 grep the prior artifact for `THRUM-REVIEW: stage=<S> verdict=Ready:Yes` (or
 `verdict=OVERRIDE`); absent → STOP and run the review first. Anchor the match —
 `grep -E '...verdict=Ready:Yes([[:space:]]|-->|$)'`, never `grep -F` — or an
@@ -150,32 +148,22 @@ structurally-enforceable gate is `project-setup` Phase 0 (it hard-bails).
   `## Deviations from Source` block with attribution `owner decision`, never
   silently absorbed.
 
-### Superpowers dependency (D6)
+### No external plugin drives this pipeline (D6)
 
-The wrapper drives `superpowers:brainstorming` / `writing-plans`. Two distinct
-pre-flight behaviors:
+Neither the brainstorm stage (Phase 2) nor the plan stage (Phase 6) invokes an
+external skill — the researcher writes both artifacts directly, governed by
+this skill's own protocol block (Phase 2) and structure/stamp/deviations
+requirements (Phase 6). There is nothing to pre-flight-check or bail on for
+either stage, and no `/plugin install` path: no such plugin is declared
+anywhere in this repo's `.claude-plugin/marketplace.json`.
 
-- `requesting-code-review` not resolvable → SKIP the supplementary quality pass
-  gracefully (the loop still runs on the general-purpose primary).
-- `brainstorming` / `writing-plans` not present → **BAIL** with an install
-  instruction (`/plugin install superpowers@<marketplace>`).
+The one genuinely optional external supplement is `requesting-code-review`
+(Review-loop mechanics, "Quality" row) — not resolvable → SKIP the
+supplementary quality pass gracefully; the loop still runs on the
+general-purpose primary, which is authoritative regardless.
 
-`verify-against-source` carries no superpowers dependency and always works.
-
-### Countermand the superpowers chain (outcome-based)
-
-`brainstorming` auto-chains to `writing-plans`, and `writing-plans` defaults
-pull toward subagent-driven execution — both bypass thrum's `project-setup`. At
-each invocation, inject (keyed on the concept, so it survives upstream
-rewording):
-
-> Regardless of any execution-handoff, "recommended" sub-skill, or save-location
-> default these skills emit, the ONLY downstream path in thrum is the next thrum
-> stage. After the artifact is written, STOP — do not auto-chain. Save to the
-> thrum path, not the superpowers default. For `writing-plans`: remove/replace
-> the plan-header line matching the stable substring
-> `REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development` and ignore
-> the Execution-Handoff offer — the plan feeds `project-setup`.
+`verify-against-source` and the general-purpose prose-quality pass carry no
+external-plugin dependency and always work.
 
 ## Phase 1 — Set up the worktree, branch, and agent
 
@@ -235,7 +223,7 @@ noise — start fresh.
 
 | Topic shape                                                                          | Base branch                                           |
 | ------------------------------------------------------------------------------------ | ----------------------------------------------------- |
-| Bug fix, hardening, infra cleanup belonging to the current line                       | The configured merge target — `jq -r '.orchestration.merge_target' .thrum/config.json` |
+| Bug fix, hardening, infra cleanup belonging to the current line                       | The configured merge target — `CONFIG=.thrum/config.json; [ -f .thrum/redirect ] && CONFIG="$(cat .thrum/redirect)/config.json"; jq -r '.orchestration.merge_target' "$CONFIG"` (a worktree's `.thrum/` holds only a `redirect` file, not its own `config.json`) |
 | Work belonging to a multi-epic version program                                       | The version's long-lived branch                       |
 | Work tied to an existing feature epic with its own long-lived branch                 | That branch                                           |
 
@@ -353,12 +341,10 @@ distinction in the inbox display):
 8. **Go-deep-then-ready instruction** — one sentence telling them to confirm
    readiness, research aggressively, and have meaty material ready when the user
    joins (not to sit idle waiting).
-9. **Countermand callout** — `superpowers:brainstorming`'s terminal state is
-   "invoke writing-plans". Tell the researcher explicitly: when brainstorming
-   reaches that terminal state, STOP at the design doc — do NOT auto-chain to
-   `writing-plans`. The brainstorm goes through the Phase 3 review gate first,
-   then Phase 6 runs `writing-plans` deliberately (with its own countermand).
-   See "Review-loop mechanics → Countermand the superpowers chain."
+9. **Stop-at-the-artifact instruction** — tell the researcher explicitly: once
+   the brainstorm design doc is drafted, STOP there. It goes through the
+   Phase 3 review gate before anything else happens; the plan doc is a
+   separate, deliberate Phase 6 step after the brainstorm is LOCKED.
 
 Send the whole thing as one `thrum send` call. The recipient's runtime will
 display it as a single inbox message; structure beats brevity here.
@@ -408,7 +394,7 @@ When the researcher reports the brainstorm is ready for review, run the
   SUPPLEMENTARY (internal consistency, technical soundness, anti-patterns,
   gaps).
 
-Both `general-purpose`, `model: "sonnet"`, `run_in_background: true`. **Have the
+Both `general-purpose`, `model: <per choosing-subagent-models>`, `run_in_background: true`. **Have the
 researcher append the gate footer and commit (in their own worktree) BEFORE you
 spawn the dual-review sub-agents** — the brainstorm lives in the researcher's
 branch, and the supplementary `requesting-code-review` pass needs a real
@@ -433,7 +419,7 @@ confidence about what's already correct and prevents over-editing.
 
 When the researcher reports their fixes are done:
 
-- Run a **targeted verification sub-agent** (one sub-agent, sonnet) that reads
+- Run a **targeted verification sub-agent** (one sub-agent, model per `choosing-subagent-models`) that reads
   the updated doc and confirms each prescribed fix landed correctly. Do NOT
   re-derive the original findings — that's done.
 - For tiny cosmetic fixes (one-line format updates, missing citations), ask
@@ -451,10 +437,10 @@ to merge" with stand-down instructions.
 ## Phase 5 — Overarching coherence pass (when sibling brainstorms close)
 
 If the topic is part of a larger program with multiple parallel brainstorms,
-once **all sibling brainstorms reach ready-to-merge**, fire an opus-tier
-coherence + implementability pass over the corpus before specs are written.
+once **all sibling brainstorms reach ready-to-merge**, fire a deep-review
+(model per `choosing-subagent-models`) coherence + implementability pass over the corpus before specs are written.
 
-Two parallel passes (background, opus model — escalate from sonnet because this
+Two parallel passes (background, a deeper tier per `choosing-subagent-models` — escalate because this
 is genuinely cross-cutting reasoning over a large corpus):
 
 | Pass                             | Focus                                                                                                                                                                                        |
@@ -475,23 +461,21 @@ expensive footguns hide.
 ## Phase 6 — Researcher writes the plan (with dual-review gate)
 
 Once the brainstorm is LOCKED (and any companion design spec is LOCKED), the
-researcher runs `superpowers:writing-plans` to convert brainstorm + spec into
-the implementation plan doc. (First, the soft pre-flight grep: `grep -F` the
-brainstorm for its `THRUM-REVIEW: stage=brainstorm verdict=Ready:Yes` (or
-`OVERRIDE`) stamp — absent → STOP and finish the brainstorm review.) **Inject
-the outcome-based countermand** (see Review-loop mechanics) at the
-`writing-plans` invocation: stop when the plan is written, save to the thrum
-path, and strip the `subagent-driven-development` plan-header line — the plan
-feeds `project-setup`, not superpowers execution.
+researcher writes the implementation plan doc directly, converting the
+brainstorm + spec into concrete steps. (First, the soft pre-flight grep:
+`grep -F` the brainstorm for its `THRUM-REVIEW: stage=brainstorm
+verdict=Ready:Yes` (or `OVERRIDE`) stamp — absent → STOP and finish the
+brainstorm review.) The plan feeds `project-setup` — there is no other
+downstream path.
 
 **The plan doc gets the SAME dual-review treatment as the brainstorm.** This
-review step is mandatory — `writing-plans` has an internal reviewer, but real-
-world experience shows that's not sufficient. Independent review catches
-contract-drift and quality issues the internal reviewer misses.
+review step is mandatory: there is no internal reviewer upstream of it, so
+this gate is the plan's only quality check. Independent review catches
+contract-drift and quality issues a single author would miss.
 
 **The researcher (not coord) dispatches the dual-review** in their own worktree:
 
-1. Researcher writes plan v1 via `writing-plans` skill (countermand applied).
+1. Researcher writes plan v1 directly.
 2. Researcher authors the `## Deviations from Source` block per
    `claude-plugin/commands/_deviations-protocol.md`, diffing plan v1 against
    the brainstorm + design spec — BEFORE dual-review, so
@@ -573,9 +557,8 @@ review catches translation errors (plan → prompt) plus prompt-specific quality
 4. Researcher signals "project-setup complete + post-setup dual-review applied"
    back to coord, citing both review passes + final artifact paths.
 
-Reaffirmation (countermand at the prompt stage): `project-setup` is the only
-downstream path — do not adopt `subagent-driven-development` execution even if a
-superpowers skill suggests it.
+Reaffirmation (at the prompt stage): `project-setup` is the only downstream
+path for the implementer prompt.
 
 If the researcher signals "project-setup complete" WITHOUT mentioning the
 post-setup reviews, ASK explicitly: "did the post-setup dual-review run on the
@@ -607,9 +590,9 @@ encodes this; include the verbatim protocol block in every briefing.
 ❌ **Half-batched findings.** Sending review findings before BOTH dual reviews
 complete. Researcher fixes batch 1 and never sees batch 2.
 
-❌ **Skipping the post-plan dual-review.** Treating `writing-plans` skill's
-internal reviewer as sufficient and proceeding directly to `project-setup`
-without an independent review of the plan doc. The plan and the impl
+❌ **Skipping the post-plan dual-review.** Proceeding directly to
+`project-setup` without an independent review of the plan doc — there is no
+internal reviewer upstream of it to lean on. The plan and the impl
 prompt MUST get the same dual-axis review treatment the brainstorm gets — Phase
 6 + Phase 7 explicit.
 
@@ -623,10 +606,14 @@ review it before dispatch.
 misread cited code or stretch citations. Spot-verify any BLOCKING that names a
 specific file/line/symbol before forwarding.
 
-❌ **`thrum message read --all` mid-brainstorm.** Classic timing bomb: read
-message A → message B arrives during the read → `--all` silently marks B read →
-B is never seen. Use `thrum message read <id> [<id>...]` with specific IDs
-instead, especially when juggling multiple researchers.
+❌ **`thrum message read --all --force` mid-brainstorm without checking the
+report.** `--all` alone is a dry run (marks nothing); `--force` only drains
+what THAT dry-run listing named, and reports any later arrival as excluded
+rather than silently sweeping it in — so the old "B arrives
+mid-read and gets silently marked" timing bomb no longer applies. Still
+prefer `thrum message read <id> [<id>...]` with specific IDs when juggling
+multiple researchers — it's simpler to reason about than tracking a listing's
+10-minute validity window.
 
 ❌ **Sub-agents into the researcher's worktree.**
 For code research in the brainstorm worktree, ask the researcher; for broader
@@ -635,7 +622,7 @@ the worktree path.
 
 ❌ **Skipping the coherence pass.** When ≥ 3 sibling brainstorms close in the
 same program, integration-layer issues that no single review can see are
-virtually guaranteed. Fire the opus pass; it's worth the cost.
+virtually guaranteed. Fire the deep-review pass; it's worth the cost.
 
 ❌ **Renaming brainstorm researchers between topics.** Identity is bound to the
 worktree. If a topic is done, kill the tmux session and tear down the worktree;

package/assets/skills/coordinator-running-review-cycles/SKILL.md

@@ -17,10 +17,7 @@ they're independent reads of the same diff.
 reviewers as parallel sub-agents in the same message. Pass each a clear scope
 ("review the diff at <BASE>...<HEAD> for <criteria>").
 
-> **Model tiers:** pass an explicit `model:` on every dispatch — `sonnet`
-> (low effort) mechanical, `sonnet` (medium effort) judgment, Opus only on
-> operator-ask or a skill step that names it. See the
-> `choosing-subagent-models` skill for the full policy.
+> **Model tiers:** pass an explicit `model:` on every dispatch; choose model and effort per the `choosing-subagent-models` skill (read `runtime.role_models` at the moment of use). Never let a sub-agent inherit your own model.
 
 ## Wait for both reviewers before sending anything to the implementer
 
@@ -48,6 +45,20 @@ one.
    when re-reviewing fixes, refer to "finding #4" and the implementer can locate
    it instantly.
 
+**Route mechanical bookkeeping findings to the gate, not the implementer.** If a
+consolidated finding is itself mechanical bookkeeping of the kind the gate is
+authorized to self-fix (see `coordinator-merging-code`: census/shard regen, line-
+number or key refreshes, ledger totals/ceilings, per-entry waivers or citations
+recording a classification already established elsewhere — never a new safety
+judgment of your own — nosec baseline hashes, comment wording, stale test
+expectations that merely follow a landed change), do not route it to the
+implementer as a normal finding. Dual review runs BEFORE the Pass-3 gate, so at
+this point there is no gate run yet to fix it: tag the finding as
+gate-deferred-bookkeeping in the consolidated list and carry it forward — the
+gate self-fixes it (a `GATE-AUTHORED` commit plus a narrow re-run of only the
+affected checks) when it runs Pass-3 on this branch. Reserve immediate
+implementer round-trips for real defects and design judgment calls.
+
 ## Verify reviewer claims against actual code before forwarding
 
 **Why:** Reviewers reading a large diff sometimes cite wrong line numbers or

package/assets/skills/diagnosing-fleet-and-daemon/SKILL.md

@@ -195,8 +195,6 @@ hypothesis confirmed.**
 | Line | Meaning |
 |---|---|
 | `sync.apply: M1 relay loop detected … dropped` | Working as designed — loop suppression. |
-| `storagegw: gossip: peer … not connected` | Peer offline. Routine. |
-| `storagegw: gossip: peer call failed … caller-peer lacks required capability` | **NOT routine** — a live capability gap. Worth a bead if sustained. |
 | `dead_agent_sweeper: marked dead agent offline` | Routine sweeper work. |
 
 ---

package/assets/skills/efficient-multi-agent-research/SKILL.md

@@ -15,10 +15,9 @@ single report.
 **Core principle:** The coordinator decides, sub-agents investigate. Keep
 investigation results out of the main context until consolidated.
 
-**REQUIRED BACKGROUND:** Read superpowers:dispatching-parallel-agents before
-using this skill. That skill
-covers general parallel dispatch. This skill extends it with a specific research
-workflow: partition, investigate to disk, consolidate, then decide.
+This skill is self-contained: partition, investigate to disk, consolidate,
+then decide — the full dispatch mechanics (Agent tool syntax, background mode,
+read-only scoping) are in "Core Pattern" below.
 
 ## When to Use
 
@@ -96,13 +95,13 @@ See the `choosing-subagent-models` skill for the full policy. Applied to this
 skill's fan-out:
 
 - **Level 1 — researchers / gatherers:** scope each one DOWN to a narrow slice
-  so you can run MANY in parallel. Use `model: "sonnet"` (low effort) —
+  so you can run MANY in parallel. Use `model: <per choosing-subagent-models>` (cheapest tier) —
   bounded gather-and-report. Smaller scope = cheaper, concurrent (faster),
   tighter per-agent context.
-- **Level 2 / Level 3 — summarizers / synthesizers:** use `model: "sonnet"` —
+- **Level 2 / Level 3 — summarizers / synthesizers:** use `model: <per choosing-subagent-models>` —
   aggregating and reconciling Level-1 outputs is judgment work.
 
-Prefer many narrow sonnet-low gatherers over one broad subagent. This is the cheap,
+Prefer many narrow cheap gatherers over one broad subagent. This is the cheap,
 fast default — equivalent parallelism at a fraction of the token cost.
 
 ## Common Mistakes

package/assets/skills/implementer-orchestrating-execution/SKILL.md

@@ -6,7 +6,7 @@ description: "Use when starting execution of a scoped implementation task — ab
 # Implementer: Orchestrating Execution
 
 You implement by **orchestrating sub-agents**, not by doing research, edits, and
-verification yourself. Your Opus context is for judgment — synthesizing
+verification yourself. Your own context is for judgment — synthesizing
 research, targeting edits, judging verification against the plan. The legwork
 goes to cheaper sub-agents. This skill is the procedure; invoke it at the start
 of executing any scoped task.
@@ -27,10 +27,7 @@ The size bound (~15 lines / 2 files) is the project default; a project-local
 
 ## Subagent model selection
 
-> **Model tiers:** pass an explicit `model:` on every dispatch — `sonnet`
-> (low effort) mechanical, `sonnet` (medium effort) judgment, Opus only on
-> operator-ask or a skill step that names it. See the
-> `choosing-subagent-models` skill for the full policy.
+> **Model tiers:** pass an explicit `model:` on every dispatch; choose model and effort per the `choosing-subagent-models` skill (read `runtime.role_models` at the moment of use). Never let a sub-agent inherit your own model.
 
 ## Step 1 — Dispatch research
 
@@ -44,13 +41,13 @@ you do not read the code into your own context. Label the dispatch
 From the report, decide exactly what changes where, then dispatch
 general-purpose sub-agent(s) to make the edits. Give each the bd task ID, the
 exact files, the acceptance criteria, and the relevant slice of the report.
-Model: `sonnet`; use `sonnet` (low effort) for purely mechanical edits
+Model: per `choosing-subagent-models`; use the cheapest tier for purely mechanical edits
 (find/replace, rename). Label `description="implement: <what>"`. Parallelize independent
 edit-targets; serialize edits to shared files.
 
 ## Step 3 — Dispatch verification
 
-Spawn a `sonnet` verifier against **the plan the implementation sub-agent was
+Spawn a verifier sub-agent (model per `choosing-subagent-models`) against **the plan the implementation sub-agent was
 given** — does the diff satisfy the acceptance criteria and honor the plan?
 Label `description="verify: <what>"`. (For the full code-quality +
 spec-compliance review at DONE, `implementer-tdd-and-quality` and the
@@ -89,12 +86,12 @@ hard size bound.
 
 | Dispatch           | Model                                              |
 | ------------------ | -------------------------------------------------- |
-| research / explore | `sonnet` (or the `Explore` agent type)             |
-| implementation     | `sonnet`; `sonnet` (low effort) for purely mechanical edits |
-| verification       | `sonnet`                                           |
+| research / explore | per `choosing-subagent-models` (or the `Explore` agent type) |
+| implementation     | per `choosing-subagent-models`; cheapest tier for purely mechanical edits |
+| verification       | per `choosing-subagent-models`                     |
 
-Use the bare `sonnet` alias (resolves to the current Sonnet); do not hard-pin a
-version id. Never let a sub-agent inherit the parent (Opus) model.
+Use the bare alias from `runtime.role_models`; do not hard-pin a version id.
+Never let a sub-agent inherit the parent model.
 
 ## Sub-agent label convention (required)
 
@@ -105,8 +102,8 @@ delegation shape from these labels.
 ## Anti-patterns
 
 ❌ **Inline Worker** — does the research and edits itself instead of
-dispatching. Your Opus context is for orchestration judgment, not hand-typing
-edits a Sonnet sub-agent should make.
+dispatching. Your own context is for orchestration judgment, not hand-typing
+edits a sub-agent should make.
 
 ❌ **Over-orchestrator** — dispatches a sub-agent for a known one-line change,
 paying more in prompt-composition than the edit costs. The Step-0 scoping gate

package/assets/skills/orchestrate/SKILL.md

@@ -53,8 +53,11 @@ grep "## Review Gate:" <prompt-file-path>
 # 4. Dependencies configured
 bd dep tree <epic-id>
 
-# 5. Merge target in config
-cat .thrum/config.json | grep merge_target
+# 5. Merge target in config (resolve through .thrum/redirect when present --
+#    a worktree's .thrum/ holds only a `redirect` file, not its own config.json)
+CONFIG=.thrum/config.json
+[ -f .thrum/redirect ] && CONFIG="$(cat .thrum/redirect)/config.json"
+cat "$CONFIG" | grep merge_target
 ```
 
 ### Step 2b: Triage CANDIDATE beads (if the dispatch carries any)
@@ -79,8 +82,8 @@ by the result:
 > `choosing-subagent-models` skill's job, not this one — see it for the tiers. What
 > matters here is that you pass one at all: the `roleDefault()` backstop in the
 > daemon covers `thrum tmux launch` of thrum agents, **not** Agent-tool sub-agents,
-> which inherit the PARENT model when unspecified. An orchestrator on Opus that
-> omits `model:` gets Opus-priced triage.
+> which inherit the PARENT model when unspecified. An orchestrator whose own tier is
+> costly that omits `model:` gets costly-priced triage.
 
 | Result | Action |
 |---|---|
@@ -181,13 +184,13 @@ thrum worktree create <name>
 # Pin --model on BOTH create AND launch — create's persist to runtime_config.json
 # is asynchronous and can lose the race to launch's resolution if launch omits
 # the flag (see CLAUDE.md "Launching an Agent"). There is no create-only shortcut.
-# Always launch implementers at --model sonnet. sonnet-medium is the floor;
-# no lower tier exists.
+# Always launch implementers pinned to the tier from runtime.role_models, per
+# choosing-subagent-models; that tier is the floor, no lower tier exists.
 thrum tmux create <name> --cwd <worktree-path> \
   --name <agent_name> --role implementer --module <module> \
   --mode ephemeral --identity ephemeral \
-  --model sonnet
-thrum tmux launch <name> --runtime <runtime> --model sonnet
+  --model <from runtime.role_models, per choosing-subagent-models>
+thrum tmux launch <name> --runtime <runtime> --model <from runtime.role_models, per choosing-subagent-models>
 ```
 
 > **Implementer lifecycle:** All implementers are ephemeral+stateless (no agent
@@ -215,7 +218,7 @@ it fails again, escalate to the human.
 ### Step 3b: Verify the model pin took
 
 If `--model` is dropped anywhere in the create/launch sequence, the implementer
-launches UNPINNED and the runtime defaults to Opus — the exact expensive
+launches UNPINNED and the runtime defaults to its own (costly) model — the exact expensive
 failure this tier exists to prevent. Confirm the pin landed before assigning
 work, using `thrum tmux capture --format=annotated` (see CLAUDE.md "Launching
 an Agent — Verify the Model by Pane, Never by `runtime-config get`" for the
@@ -226,12 +229,12 @@ NBSP fallback trap, and the by-position read):
 thrum tmux capture <agent-name> --format=annotated --lines 12
 ```
 
-That prints the runtime's own footer line, e.g. `Model: Sonnet 5`. **Read the
+That prints the runtime's own footer line, e.g. `Model: <resolved model>`. **Read the
 intended tier from `.thrum/config.json` → `runtime.role_models`, not from memory.**
-If the footer shows a different tier (see the BLOCKED note under Step 2 — there is
-no valid `haiku` pin), the pin failed silently — re-pin with
-`thrum tmux create ... --model sonnet` (or
-`thrum agent runtime-config set <agent_name> --model sonnet`) and relaunch BEFORE
+If the footer shows a different tier (see the BLOCKED note under Step 2 — the model ban
+list lives in `choosing-subagent-models`), the pin failed silently — re-pin with
+`thrum tmux create ... --model <from runtime.role_models, per choosing-subagent-models>` (or
+`thrum agent runtime-config set <agent_name> --model <from runtime.role_models, per choosing-subagent-models>`) and relaunch BEFORE
 assigning work. **Do not dispatch an unpinned implementer** — the daemon's
 role-default backstop (`jq -r '.runtime.role_models' .thrum/config.json`) is a
 net for a forgotten pin, not a substitute for this check.
@@ -329,9 +332,9 @@ Handle each message type:
 2. Dispatch BOTH reviewers IN PARALLEL (one Agent call per reviewer in the same
    response). Block until BOTH return:
    - Code-quality: `superpowers:code-reviewer` (or `feature-dev:code-reviewer`
-     if the project provides one) — `model: "sonnet"`
+     if the project provides one) — `model: <per choosing-subagent-models>`
    - Spec-compliance: `general-purpose` reviewer cross-referencing the plan/
-     spec — `model: "sonnet"`
+     spec — `model: <per choosing-subagent-models>`
 3. **Verify** every cited `file:line` claim against the actual source before
    forwarding. Reviewers can misread files; forwarding unverified findings
    wastes the implementer's time.
@@ -389,10 +392,7 @@ Handle each message type:
 **Sub-agent model discipline (applies to ALL Agent tool calls in this phase and
 Phase 5):**
 
-> **Model tiers:** pass an explicit `model:` on every dispatch — `sonnet`
-> (low effort) mechanical, `sonnet` (medium effort) judgment, Opus only on
-> operator-ask or a skill step that names it. See the
-> `choosing-subagent-models` skill for the full policy.
+> **Model tiers:** pass an explicit `model:` on every dispatch; choose model and effort per the `choosing-subagent-models` skill (read `runtime.role_models` at the moment of use). Never let a sub-agent inherit your own model.
 
 **Blocker:**
 
@@ -508,7 +508,7 @@ in Scope Boundaries). Analyze the conflict using your plan/intent context to
 determine the correct resolution. Then spawn a targeted edit sub-agent:
 
 ```text
-Agent(subagent_type="general-purpose", model="sonnet",
+Agent(subagent_type="general-purpose", model="<per choosing-subagent-models>",
   prompt="Resolve this specific merge conflict.
   File: <file-path>
   Conflicted section: <paste the <<<< ==== >>>> block>
@@ -618,18 +618,30 @@ can act on, which is how a guard gets disabled. Classify every hit — only a
 classifier failure is a real only-copy:
 
 ```bash
-# STAGE 2 — CLASSIFY every hit from stage 1 against ALL HISTORY, not the tip
-# tree (a tip-only check like `git cat-file -e origin/<ref>:<path>` flags
-# every file the 19-session sliding window has legitimately trimmed as
-# unrecoverable — over-reporting, not under-reporting, but still an alarm
-# nobody can act on):
-git log --all --oneline -- ".thrum/agents/<path>" | head -1
-#   NON-EMPTY -> RECOVERABLE (in git history)
-#   EMPTY     -> ONLY-COPY — SALVAGE BEFORE REMOVAL
-
-# CONTROLS — the classifier must be able to both affirm and refuse:
-git log --all --oneline -- ".thrum/agents/<a-real-trimmed-path>"   # must be NON-EMPTY
-git log --all --oneline -- ".thrum/agents/__nope__/x"              # must be EMPTY
+# STAGE 2 — classify every stage-1 hit. Test that a BLOB IS RETRIEVABLE,
+# never that the path merely appears in the log: `git log -- <path>` also
+# matches the commit that DELETED the file, and `| head -1` returns exactly
+# that for a trimmed file.
+git log --all --oneline --name-status -- ".thrum/agents/<path>"   # read the A/M/D column; do NOT head -1
+git cat-file -e "<add-or-modify-sha>:.thrum/agents/<path>"        # rc=0 proves the BLOB EXISTS
+git show "<that-sha>:.thrum/agents/<path>" > /tmp/x && cmp /tmp/x "<worktree-copy>"
+#   blob retrievable AND byte-identical -> RECOVERABLE
+#   otherwise                           -> ONLY-COPY — SALVAGE BEFORE REMOVAL
+# Always check rc explicitly on git show/cat-file; never infer from output size.
+# Form the cmp control from two files KNOWN to differ — comparing an
+# accidentally-empty extraction against /dev/null reports "identical" and
+# reads as a passing control.
+
+# CONTROLS — the classifier must be able to both affirm and refuse.
+# Exercise BOTH halves of the decision: existence (cat-file -e) AND
+# byte-identity (cmp). Controlling only existence leaves the cmp step
+# unguarded — and cmp is where an accidentally-empty extraction reads
+# as "identical" and passes.
+git cat-file -e "<add-or-modify-sha>:.thrum/agents/<path>";      echo "rc=$? (must be 0)"
+git cat-file -e "<add-or-modify-sha>:.thrum/agents/__nope__/x";  echo "rc=$? (must be NON-ZERO)"
+printf 'x' > /tmp/ctl-differs
+cmp -s /tmp/x /tmp/ctl-differs; echo "rc=$? (must be NON-ZERO — proves cmp CAN detect a difference)"
+cmp -s /tmp/x /tmp/x;           echo "rc=$? (must be 0 — proves cmp CAN affirm)"
 ```
 
 ```bash
@@ -719,7 +731,7 @@ Run review rounds; converge to zero BLOCKING:
 **Round N:**
 
 1. Dispatch BOTH reviewers IN PARALLEL — code-quality (`feature-dev:code-reviewer`,
-   `model: "sonnet"`) + spec-compliance (`general-purpose`, `model: "sonnet"`).
+   `model: <per choosing-subagent-models>`) + spec-compliance (`general-purpose`, `model: <per choosing-subagent-models>`).
    **In each reviewer dispatch prompt, mandate structured severity:**
    > "Label every finding BLOCKING / IMPORTANT / MINOR. At least one label per
    > finding, prefix each finding line."
@@ -775,7 +787,7 @@ them, forward to coordinator at merge-approval.
 **Hard cap — 2 rounds max:**
 If BLOCKING findings remain after round 2:
 
-- Step A: REMOVED. sonnet-medium is the implementer floor, so there is no
+- Step A: REMOVED. The implementer tier is the floor, so there is no
   lower tier to escalate from. A round-2 BLOCKING failure goes straight to
   Step B.
 - Step B (escalate up): if the implementer fails to converge, escalate to coordinator