opencode-thrum-pro 0.1.5 → 0.1.6

package/assets/skills/coordinator-merging-code/SKILL.md

@@ -90,9 +90,11 @@ merge target before merging.
 
 ## 3. PASS-3 GATES — DISPATCH BOTH TO THE GATE RUNNER
 
-**Resolve the Gate Runner from `thrum team` by its `gate` ROLE — never by a
-remembered agent name.** A name in a skill goes stale exactly like a copied model
-tier.
+1. Select from your team of established long-running gate agents.
+2. Choose an available pair for hot-path and philosophy.
+3. Tell those agents where sensitive tests must execute.
+4. Launch a new gate agent only if the persistent set is genuinely unavailable —
+   never merely because an old candidate-specific session is stale.
 
 Record the dispatch on your own queue (`thrum queue assign <bundle>
 <gate-runner>`) per `coordinator-dispatching-work`'s queue step before
@@ -157,7 +159,9 @@ worktree; its sub-agents get READ-ONLY git. `checkout`/`reset`/`restore`/`stash`
 `clean`/`rebase` forbidden in **every** directory for both. Give an escape hatch
 for instrument-and-undo (a `cp` copy, or edit-then-revert) or the careful agent
 breaches the fence doing good work. **Use `rm -r`, NEVER `rm -rf`.**
-**Pasting a fence is not enforcing it.**
+**Pasting a fence is not enforcing it.** This same fenced commit capability is
+what the sanctioned `GATE-AUTHORED` mechanical-bookkeeping-fix commit uses — it
+is not a new permission grant.
 
 ## 4. THE EXECUTED VERIFY — SCOPED TO THE CHANGE
 
@@ -175,7 +179,13 @@ executed half is **scoped to the change**:
 - The `merge-base --is-ancestor` fast-forward check (§6).
 - Any `*_tripwire_test.go` the change touches must stay green or the diff must
   state why its premise changed; a tripwire edited to accommodate the change is a
-  finding, not a fix.
+  finding, not a fix — **except** a mechanical follow-up (updating a stale
+  expectation to merely track an already-landed, already-reviewed change: a
+  renumbered line, a regenerated census key, and the like), which the gate may
+  fix itself as a `GATE-AUTHORED` commit and re-run. A tripwire edit that changes
+  what the tripwire actually *enforces* — any design or behavior judgment call —
+  stays a finding, never a self-administered fix. Keep this distinction sharp;
+  it is the highest-risk edit in this whole sequence.
 - 🔴 **The CLASS-firing governance gates, on the merged tree — they are BLIND to
   changed-package scoping, exactly like the `//go:embed` asset in §5.**
   `TestFixtureDriftGuard_NoUnlistedSchemaMirrors` (`internal/schema`) and
@@ -186,18 +196,18 @@ executed half is **scoped to the change**:
   it every merge: `git diff <base> <tip> | grep -iE 'CREATE TABLE|ALTER TABLE|durablelane|MirrorWriter|sanctionedMirrorWriters'`
   — ANY hit ⇒ also run `go test ./internal/schema/ -run TestFixtureDriftGuard` and
   `go test ./tests/gate/ -run TestEveryMirrorWriterIsSanctioned` on the MERGED tree.
-  Measured 2026-08-28: kgi7t (`TestEveryMirrorWriterIsSanctioned`) and xo58f
+  Measured previously: kgi7t (`TestEveryMirrorWriterIsSanctioned`) and xo58f
   (`TestFixtureDriftGuard`) BOTH escaped per-merge Pass-3 this way and surfaced only
   in the daily gate as trunk-reds. The changed-package rule below is necessary, not
   sufficient — a class gate is a property of the TREE, not the neighbourhood.
   🔴 **Also always-run, same class-gate reasoning:**
   `TestNoMainStateDBWriteOwnerBypasses` (`internal/testgate`; corpus 5.1
   owner-bypass-check) — a scanner ratchet over every raw main-State-DB write
-  site, blind to changed-package scoping the same way. Measured 2026-09-04:
-  thrum-mjmu3 Part a introduced a raw `r.db.ExecContext` outside
+  site, blind to changed-package scoping the same way. Measured previously:
+  a merged branch introduced a raw `r.db.ExecContext` outside
   `safedb.WriteCoordinator` in a durable-lane cold-boot restore step; the
   ratchet went 213→214 and gate_thrum's Pass-3 on that merge was CLEAN because
-  this test was not yet in the always-run set (thrum-wdt97). Run it on the
+  this test was not yet in the always-run set. Run it on the
   MERGED tree every merge: `go test ./internal/testgate/... -run
   TestNoMainStateDBWriteOwnerBypasses`.
 
@@ -272,12 +282,16 @@ agreeing (`rev-parse origin/<branch>` and `ls-remote`). **Assert the branch TIP*
 1. **The verdict artifact.** The runner saves verdicts to
    `dev-docs/gate-reports/<ISO-week>/<date>/<gate-slug>/` and **commits them
    BEFORE removing any worktree.** Save → commit → then destroy. A verdict that
-   exists only in a message cannot be audited later.
+   exists only in a message cannot be audited later. The artifact must be able to
+   carry a `CLEAN-WITH-GATE-FIXES` outcome, and when one applies it cites the
+   `GATE-AUTHORED` commit SHA.
 2. **The efficacy row**, in `dev-docs/hotpath-gate-efficacy.md` — required for
    **every** trigger-dir merge, including `SKIPPED_WITH_EVIDENCE` rows and
    orchestrator-run merges. The log measures gate **coverage**, not just outcomes.
    Record `FALSE_POSITIVE=0` explicitly on a clean run so the zero is a
-   measurement rather than an absence.
+   measurement rather than an absence. Same rule applies here: an
+   `outcome=CLEAN-WITH-GATE-FIXES` row cites the `GATE-AUTHORED` commit SHA when
+   one exists.
 3. **Commit accumulated agent state** under `.thrum/agents/` along with the merge.
    Uncommitted agent state exists in exactly one working tree, and it IS the
    agent's memory across restarts. **Never `git add -f`.**

package/assets/skills/coordinator-philosophy-merge-gate/SKILL.md

@@ -90,6 +90,14 @@ dispatch time — hand this list verbatim:
    carrying dupes instead of the real content.
 6. Run full-package `-race`, not targeted `-run` — a targeted race run
    misses cross-test races that only a full-package run surfaces.
+   **Exception: `internal/daemon/rpc` must NEVER be run monolithically** — a
+   bare `go test [-race] ./internal/daemon/rpc` cannot finish inside any
+   gate-length timeout. Run it through the sharded runner (`race-shard`,
+   `scripts/test-run.sh race ./internal/daemon/rpc`, or `make gate`) and confirm
+   the gate's output shows it executed. A bound-timeout with ZERO test failures
+   is a false red: classify it with `go run ./cmd/testgate classify-timeout
+   --log <file> --shard-config <file> --shard <name>` (only BOUND-TIMEOUT exits
+   0) before reporting a regression. See item 7 of `coordinator-hotpath-merge-gate`.
 7. Build+test the MERGED-tree result as a SEPARATE condition — neither gate
    currently runs a build of the actual post-merge tree; a clean pre-merge
    build/test does not prove the merged result compiles or passes.
@@ -414,13 +422,26 @@ Two cautions, so this rule does not cause its own incident:
 
 ## If it fails
 
-Send it back as a normal review finding — same channel as dual-review output,
-folded into the same numbered list if dual review is still open, or as its own
-short reply if dual review already passed. Cite the offending function/file and
-which anti-pattern (`ph<N>`), meta-check, or Lens 10 sub-probe it failed. Do
-NOT block on Lens 10d findings that are
-genuinely disclaimed substrate issues (see Lens 10 scope discipline above); DO
-block on any Lens 10b or 10d finding on NEW work.
+For a genuine anti-pattern, Lens 10 finding, production-behaviour issue, or
+design judgment call: send it back as a normal review finding — same channel as
+dual-review output, folded into the same numbered list if dual review is still
+open, or as its own short reply if dual review already passed. Cite the
+offending function/file and which anti-pattern (`ph<N>`), meta-check, or Lens
+10 sub-probe it failed. Do NOT block on Lens 10d findings that are genuinely
+disclaimed substrate issues (see Lens 10 scope discipline above); DO block on
+any Lens 10b or 10d finding on NEW work.
+
+For mechanical bookkeeping only (census/shard regen via the tool, line-number
+or key refreshes, ledger totals/ceilings where the arithmetic is derivable, a
+per-entry waiver or citation comment recording a classification already
+established elsewhere (never a new safety judgment of your own), a nosec
+baseline hash for an already-reviewed pattern, comment wording, stale test
+expectations that merely follow a landed change): fix it yourself as a
+`GATE-AUTHORED` commit on your
+`gate/` branch, re-run ONLY the check(s) the fix affects, and report
+`CLEAN-WITH-GATE-FIXES` listing each fix instead of bouncing it to the owner.
+When unsure which bucket a finding falls in, ask the coordinator with the exact
+diff — don't bounce reflexively.
 
 ## See also
 

package/assets/skills/coordinator-plan-reconcile-gate/SKILL.md

@@ -67,11 +67,11 @@ Spawn **one** top-level agent, `model: "fable"`.
 
 This is not a self-granted exception; it is the single deliberate use of
 Fable anywhere in the system, kept as an independent check-and-balance
-against everything else, which runs on the sonnet ceiling.
+against everything else, which runs on the standard tier ceiling (see `choosing-subagent-models`).
 Fable — a distinct, more-capable model — is the right instrument specifically
 because a holistic cross-plan reconcile (does seam X mean the same thing in
-plan ① as in plan ②?) benefits from a different model than the sonnet-run
-per-plan reviews, a form of cross-document judgment a sonnet-tier pass has
+plan ① as in plan ②?) benefits from a different model than the standard-tier
+per-plan reviews, a form of cross-document judgment a standard-tier pass has
 been shown to miss.
 
 This is the **one named, cited exception** to the standing "never SELECT

package/assets/skills/coordinator-rolling-out-to-nodes/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: coordinator-rolling-out-to-nodes
+description: "Use when rolling a build across all nodes — fleet deploy, rolling the nodes, deploy everywhere, ship to every node, canary then the rest, promote the canary, staged rollout, deploying after a merge batch. Orchestrates the staged order and the promotion gate between stages, and delegates each node to the coordinator-deploying-a-node runbook. Load this BEFORE dispatching any node."
+---
+
+# Coordinator: Rolling Out a Build Across All Nodes — staged order, canary, promotion gate
+
+> This skill is the ORCHESTRATION layer. It does not replace
+> `coordinator-deploying-a-node` — it calls it, once per node.
+
+## 0. Universal invariants (read first — these outrank everything below)
+
+These hold for every deployment regardless of project or topology. The adapter supplies *how*, these define *what must be true*.
+
+1. **Build once; distribute identical bytes.** One pinned immutable artifact (SHA/version/checksum triple) is built once at one SHA on the build host; every node installs from that same artifact. No node re-derives it. Pin exact SHA, never tip. Adapter: `fleet.deployment.thrum.artifact` or `fleet.deployment.products.<id>.artifact`.
+2. **Target-local mutation.** The node-local coordinator performs the mutation (install/migrate/restart) locally on its own host. Never drive a node's build/install/restart from another host. The orchestrator dispatches and gates; the node executes.
+3. **Immutable identifier + checksum.** Artifact is identified by SHA + version + checksum; verify BEFORE install that the delivered bundle is the one the orchestrator built. Adapter: `artifact.checksum`, `artifact.version_file`, `artifact.commit_file`.
+4. **Canary evidence does not transfer.** A canary pass proves the *build* is sound; it does not prove any other node's *state* is sound. Every node takes its own BEFORE readings.
+5. **Verify by observed effect, never exit code.** Install/restart success is proven by post-mutation observation (version equals pin, NEW PID, service status reports pin, migration moved), not by installer exit 0. Adapter: `install.verify_by_effect`, `health.probes`.
+6. **Capture before/after.** For every node, capture BEFORE state (current version/state, health counters) before mutation and AFTER state after; compare.
+7. **Account for every target.** Roster completeness: enumerate topology from config, disposition each node (rolled on pin / deferred with owner sign-off + notify local coordinator), and never normalize unmeasured rows.
+
+Additional parameterized invariants (skill-owned, adapter-valued):
+
+- Pull-current first (ff-only) before reasoning about state. Adapter: `preflight.pull_command`.
+- Backup before touching anything; sizing via adapter formula. Adapter: `backup.command`, `backup.sizing_formula`.
+- Never bypass the storage engine's file ownership. Adapter: `storage_access.via`, `storage_access.forbidden`.
+- Install-before-restart ordering; re-render between install and restart. Adapter: `templates.order`.
+- Convergence wait from mechanism, not impatience. Adapter: `health.convergence_wait`.
+
+## 1. Enumerate topology (from adapter — never hard-code)
+
+Read the project's deployment adapter inside `.thrum/config.json` (`fleet.deployment`; human-readable reference at the deployment-adapter reference). Never hard-code topology or commands in the dispatch or in this skill — read them from that single source.
+
+- For Thrum fleet plus connected daemons: `fleet.deployment.thrum.topology` (`canary`, `waves`, `excluded`, `connected_daemons`, `identity_resolution`).
+- For a customer product `<id>`: `fleet.deployment.products.<id>.topology` (same shape, per-product `canary`/`nodes`/`waves`).
+
+Resolve each node's `daemon_id` / `ssh_alias` / `coordinator` via the adapter's `identity_resolution` method (daemon_id join, not name). If topology is empty, STOP — do not invent nodes.
+
+**Why every node carries an `ssh_alias`:** so the rolling coordinator can reach the node directly when the messaging or pane-mirror path fails. The main case is an agent stuck on a permission prompt or dialog. Read the pane with `ssh <alias> tmux capture-pane -p -t <session>`, then answer a prompt you recognise as safe with `tmux send-keys`. Never approve blindly, and never pick a "don't ask again" option. Re-capture afterwards to confirm the pane moved on. A node flagged `blocked-on-human` gets unblocked this way in the same turn; don't wait on it or reorder the roll around it. The alias is for pane interaction and artifact distribution only. The node still builds, installs and restarts itself, through its own coordinator.
+
+> Example — Thrum project: topology canary and waves are defined in `topology.canary` / `topology.waves` (seven boxes, one excluded), connected daemons per `topology.connected_daemons`. Build host and build command are adapter values, not skill literals.
+
+## 2. Pin the artifact (build once at SHA/version/checksum)
+
+Derive the immutable pin on the build host (adapter `artifact.build_host`): current `HEAD` SHA, version, and checksum. When multiple related artifacts (e.g., core plus connected-repo bundles) are involved, pin each immutably and distribute the same set to every relevant node. Announce the pin in the dispatch so every node can verify it.
+
+Artifact identity lives in `artifact.output`, `artifact.version_file`, `artifact.commit_file`, `artifact.checksum`. Never use a floating tag like tip; always the pinned SHA.
+
+## 3. Preflight (control-plane current, forward-only, backup sizing via adapter)
+
+- Verify control-plane checkout is current: `preflight.pull_command` (must be ff-only; if not fast-forwardable, STOP and surface).
+- Forward-only check per node: `preflight.forward_only_check` — prove the pin is an ancestor of the node's current SHA (plus a control that must FAIL, e.g., an invented SHA, to prove the check discriminates).
+- Backup sizing via adapter: `backup.sizing_formula` — compute `free_at_completion` per the formula before running `backup.command`; if the projected peak exceeds the safe threshold, STOP and escalate.
+
+## 4. Build once → distribute identical artifact (mechanism via adapter)
+
+Build once per artifact on its `artifact.build_host` via `artifact.build_command` → verify the produced bundle's version/checksum/commit sidecar → distribute the identical bytes to every node's inbound drop path (`artifact.distribution.drop_path`) via the adapter's `artifact.distribution.mechanisms` (e.g., drop-folder or copy). No node re-derives or rebuilds. Verify BEFORE unpack that the delivered bundle matches the pin.
+
+> Example — Thrum project: build once via the adapter's `artifact.build_command` on the adapter's `artifact.build_host`, distribute via the adapter's `artifact.distribution.mechanisms` to `artifact.distribution.drop_path`, bundle carries sidecars verified per adapter.
+
+## 5. The staged order — canary, waves, prepare-and-hold, promotion gate
+
+- **Canary first, alone.** One node (adapter `topology.canary`) rolls first. Its health must be observed green before any wave proceeds.
+- **Waves with coordinated dependency/order/rollback.** Subsequent waves follow `topology.waves`. When related daemons share ordering (e.g., connected-repo daemons that must restart together), respect the adapter-defined dependency and restart order; a failure in one dependent daemon triggers coordinated rollback per adapter `rollback` / `backup.restore_command`.
+- **Prepare-and-hold + release BY NAME.** If the mechanism supports it, prepare all nodes in a wave (acquire + verify artifact, take BEFORE snapshot, but do not restart) then release by explicit node name, not by broadcast.
+- **Promotion gate.** After each stage, verify by observed effect on that node (see node skill) before promoting. On no-go, halt the rollout and roll back the affected node(s) per adapter.
+
+## 6. Dispatching a node — what the message must carry
+
+Dispatch each node to its own local coordinator (resolved via `identity_resolution`), never via remote shell for the mutation itself. The dispatch message must carry:
+
+- Pinned artifact identifier (SHA/version/checksum) and drop-path location.
+- Which adapter section to use (`fleet.deployment.thrum` vs `fleet.deployment.products.<id>`).
+- Expected pin for verification and the BEFORE-snapshot request.
+- Hold/release semantics if using prepare-and-hold.
+
+The node's local runbook is `coordinator-deploying-a-node` — reference that skill by name in the dispatch.
+
+## 7. After the last node — roster completeness, phase reconciliation, test gate
+
+- Enumerate the topology again from the same adapter source and disposition every entry (rolled on pin / deferred with owner sign-off + notify local coordinator). Missing or unmeasured rows are not normalized.
+- Reconcile registry/phase: verify every daemon reports the pin (adapter `health.probes` + `install.verify_by_effect`), and that agent phases have converged.
+- Run the project's gate that is appropriate for the change (e.g., `make gate` or equivalent) before declaring success.
+
+## 8. Holds and red flags
+
+- If `fleet.deployment` is absent or `fleet.deployment.products` and `fleet.deployment.thrum` are both empty, STOP — no topology is defined.
+- If the control-plane pull is not fast-forwardable, STOP.
+- If `fleet.deployment.thrum.products` exists (vestigial), STOP — products live only at `fleet.deployment.products`.
+- If a node reports success by exit code alone without observed-effect verification, treat as not-verified.
+- Never wrap a service restart in a blind timeout on the node (see node skill `service.never_timeout` and `migration.signal_rules`).

package/assets/skills/coordinator-running-autonomous-feature-development/SKILL.md

@@ -106,8 +106,8 @@ outlive its author and later be enforced as if it were the human's mandate.
 through a standing orchestrator.**
 
 The reason, in one line: orchestrators own the implementer lifecycle and the
-`--model sonnet` pin; standing one up yourself risks the implementer inheriting
-opus. Your lane is dispatch-decision + gate + merge. Full dispatch mechanics
+`--model` pin (from `runtime.role_models`, per `choosing-subagent-models`); standing one up yourself risks the implementer inheriting
+your own model. Your lane is dispatch-decision + gate + merge. Full dispatch mechanics
 live in **`coordinator-dispatching-work`**.
 
 **Recovery:** if an implementer was ever stood up directly, **tear it down
@@ -117,7 +117,7 @@ coordinator-spawned implementer — it may carry the wrong model.
 | Rationalization                                                      | Reality                                                                                                                                                                                                                                                                                                   |
 | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | "I'll just stand up the implementer myself, it's faster."            | **WRONG** — route through a standing orchestrator. |
-| "The orchestrator can just adopt the implementer I already spawned." | **WRONG** — it may carry opus. Tear it down first; let the orchestrator spawn its own with the sonnet pin.                                                                                                                                                                                                |
+| "The orchestrator can just adopt the implementer I already spawned." | **WRONG** — it may carry a costly model. Tear it down first; let the orchestrator spawn its own with the pinned model.                                                                                                                                                                                                |
 
 ## Coordinator-run Q&A vs escalate
 

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

@@ -40,7 +40,7 @@ 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 is the SOLE quality gate on the plan doc — the researcher authors the
@@ -50,16 +50,13 @@ 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.
 
@@ -73,9 +70,9 @@ 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.
 
@@ -158,7 +155,7 @@ 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` (thrum-tsaq4).
+anywhere in this repo's `.claude-plugin/marketplace.json`.
 
 The one genuinely optional external supplement is `requesting-code-review`
 (Review-loop mechanics, "Quality" row) — not resolvable → SKIP the
@@ -226,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                                           |
 
@@ -397,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
@@ -422,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
@@ -440,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                                                                                                                                                                                        |
@@ -609,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
@@ -621,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

@@ -95,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