opencode-thrum-pro 0.1.5 → 0.1.7

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
 
@@ -165,17 +169,28 @@ The §3 lens gates (hotpath + philosophy) are the judgement half. The per-merge
 executed half is **scoped to the change**:
 
 - Build the merged tree (`go build ./...`).
-- Full-*package* `-race` on the **changed packages only** — full-package, never
-  targeted `-run` (a targeted run misses cross-test races), but only what the diff
-  touches.
+- 🔴 **RULING 2026-09-29:** the full sharded race suite —
+  `scripts/test-run.sh race all` (~15-20 min) — on the **merged tree**, every
+  Pass-3 verdict. This replaces the prior "changed packages only (+ rpc shard
+  sweep)" race scoping below the ruling; a targeted `-run` is still never
+  acceptable (a targeted run misses cross-test races). Never on primary (the
+  shared fleet build box) — it is CPU-heavy; run it on the gate box.
 - The fast structural checks on the merged tree — `gate-ban-check`,
   `gate-omitempty-check`, `gate-lockspan-check`, `gate-marker-diff`,
-  `gate-stamp-protocol-check` (seconds each; they catch banned flags, `omitempty`
-  drift, lock-span, marker and stamp drift regardless of the change).
+  `gate-stamp-protocol-check`, `gate-plugin-bundle-leaks` (seconds each; they
+  catch banned flags, `omitempty` drift, lock-span, marker and stamp drift
+  regardless of the change; `gate-plugin-bundle-leaks` self-skips when no plugin
+  path changed).
 - 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,24 +201,25 @@ 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`.
 
-**Establish branch-attributable vs pre-existing from the changed-package `-race`
-result** — a regression adds failures the same packages did not have before. Do
-not classify a scoped change by replaying the whole known-red suite.
+**Establish branch-attributable vs pre-existing from the full-race `-race`
+result** — a regression adds failures the packages touched by the diff did not
+have before. Do not classify a scoped change by replaying the whole known-red
+suite.
 
 🔴 **Do NOT run the full all-lanes `make gate` for a merge.** The full suite —
 every package across lanes A/B/C/D, the integration lane, `gate-ci-mutation-check`,
@@ -211,7 +227,9 @@ the UI lane, the full tripwire/boxstate reconciliation — is the **periodic
 full-gate cadence**, an agent run on the dedicated isolation box, and it is its own
 skill: **`coordinator-full-gate`**. A merge never triggers it, and its merge-base
 replay is not a per-merge step. Running it per merge is ~2h that on a common-mode-
-red trunk fails on the baseline every time.
+red trunk fails on the baseline every time. The RULING 2026-09-29 above
+widens only the **race lane** to full-sharded per merge — it does not pull the
+other lanes (integration, UI, mutation-check) into the per-merge path.
 
 🔴 **Never kill a test run to stop a collision.** Killing skips Go's cleanup, which
 leaks fixed-name tmux fixtures onto the shared socket and breaks that suite box-
@@ -272,12 +290,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`.**
@@ -347,8 +369,7 @@ hides staleness.
 
 ## Project-specific rules (already loaded)
 
-Read the shared partial at the absolute path:
-`claude-plugin/commands/_project-rules-protocol.md`
+Load the /thrum:project-rules-protocol skill and follow it.
 
 If you accumulate a new rule mid-session (the user corrects you), capture it via
 the `coordinator-maintaining-memory` skill — it references the

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
 
@@ -438,8 +459,7 @@ block on any Lens 10b or 10d finding on NEW work.
 
 ## Project-specific rules (already loaded)
 
-Read the shared partial at the absolute path:
-`claude-plugin/commands/_project-rules-protocol.md`
+Load the /thrum:project-rules-protocol skill and follow it.
 
 If you accumulate a new rule mid-session (the user corrects you), capture it via
 the `coordinator-maintaining-memory` skill — it references the

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
@@ -189,8 +189,7 @@ unambiguously so an implementer doesn't re-litigate them.
 
 ## Project-specific rules (already loaded)
 
-Read the shared partial at the absolute path:
-`claude-plugin/commands/_project-rules-protocol.md`
+Load the /thrum:project-rules-protocol skill and follow it.
 
 If you accumulate a new rule mid-session about multi-plan reconciliation,
 capture it via the `coordinator-maintaining-memory` skill — it references the

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.
 
@@ -116,7 +113,7 @@ forwarding.
 
 5. **Authored-against stamp (required, top of every artifact):** Before writing
    a brainstorm.md or plan.md, derive and emit the stamp per
-   `claude-plugin/commands/_stamp-protocol.md` § "Stamp format" — the canonical
+   the /thrum:stamp-protocol skill § "Stamp format" — the canonical
    format, derivation commands, and never-type rule.
 
 ### Soft pre-flight greps (the SOFT enforcement tier)
@@ -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                                                                                                                                                                                        |
@@ -480,7 +477,7 @@ contract-drift and quality issues a single author would miss.
 
 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 /thrum:deviations-protocol skill, diffing plan v1 against
    the brainstorm + design spec — BEFORE dual-review, so
    `verify-against-source` validates it as part of conformance. Required even
    when empty ("No deviations from source.").
@@ -507,7 +504,7 @@ contract-drift and quality issues a single author would miss.
    coordinator instead of being folded inline.
 6. Researcher repeats only if cycle-1 introduces new design surface (rare for
    bounded mechanical plans); otherwise v2 LOCKED. Before stamping, compute
-   `plan_obj`/`src_lock` per `_stamp-protocol.md` § "Review-object binding"
+   `plan_obj`/`src_lock` per `stamp-protocol.md` § "Review-object binding"
    (strip-then-hash the plan against itself for `plan_obj`; plain-hash the
    LOCKED source for `src_lock`), then stamp
    `<!-- THRUM-REVIEW: stage=plan verdict=Ready:Yes cycle=<N> date=<YYYY-MM-DD> verify=Ready:Yes plan_obj=<blob> src_lock=<blob> -->`.
@@ -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;
@@ -635,8 +636,7 @@ don't rebind the agent name to a different topic in place.
 
 ## Project-specific rules (already loaded)
 
-Read the shared partial at the absolute path:
-`claude-plugin/commands/_project-rules-protocol.md`
+Load the /thrum:project-rules-protocol skill and follow it.
 
 If you accumulate a new rule mid-session about brainstorm orchestration, capture
 it via the `coordinator-maintaining-memory` skill — it references the

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
@@ -145,8 +156,7 @@ AFTER they report DONE. They target different artifacts and both are needed.
 
 ## Project-specific rules (already loaded)
 
-Read the shared partial at the absolute path:
-`claude-plugin/commands/_project-rules-protocol.md`
+Load the /thrum:project-rules-protocol skill and follow it.
 
 If you accumulate a new rule mid-session (the user corrects you), capture it via
 the `coordinator-maintaining-memory` skill — it references the

package/assets/{commands/thrum-_deviations-protocol.md → skills/deviations-protocol/SKILL.md}

@@ -1,19 +1,13 @@
 ---
-description:
-  Shared Deviations-from-Source protocol — canonical block format, the
-  required-even-when-empty rule, and derivation discipline. Not
-  user-invocable directly.
+name: deviations-protocol
+description: "Use when authoring a plan or implementation prompt - Deviations-from-Source block format, required even when empty."
 ---
 
-# Deviations from Source Protocol (shared partial)
 
+# Deviations from Source Protocol
 This file is the canonical source-of-truth for the "Deviations from Source"
-block emitted by planning-loop artifacts (plans, implementation prompts). Do
-NOT invoke this file directly; it has no terminal action.
-
-(To find what currently points here: `grep -rn "_deviations-protocol.md"
-claude-plugin/` — a hand-listed consumer roster in this file would rot the
-moment a new emitter or reader is added, so none is kept here.)
+block emitted by planning-loop artifacts (plans, implementation prompts).
+Invoke this skill to author the block, even when empty.
 
 ## Purpose
 
@@ -33,7 +27,7 @@ FAILS the gate, whether or not it actually dropped anything.
 ## Format (emitted artifact — verbatim)
 
 Every plan and implementation prompt carries this heading, placed immediately
-after its Authored-against stamp block (see `_stamp-protocol.md`):
+after its Authored-against stamp block (see `stamp-protocol.md`):
 
 ```
 ## Deviations from Source

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/generator-idempotency-protocol/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: generator-idempotency-protocol
+description: "Use when generating config or docs from templates - idempotency invariant for generator skills."
+---
+
+
+# Generator Idempotency Protocol
+The modes are idempotent — running the skill repeatedly on a stable project
+should produce no file changes after the first run.