opencode-thrum-pro 0.1.2 → 0.1.4

package/assets/skills/brainstorm-steward/SKILL.md

@@ -27,8 +27,9 @@ to that coordinator). Everything below is additive — the brainstorm-specific
 duties layered on top of that base.
 
 Your roster is entirely remote (other boxes), so the base skill's remote
-modal-unblock note applies to every roster member by default — never reach
-for `thrum tmux key`, which is local-socket-only.
+modal-unblock note applies to every roster member by default — use
+`thrum tmux send` (peer-routed, works fleet-wide); the local-only
+tmux-key primitive it replaces is retired.
 
 ## Roster = brainstormers
 

package/assets/skills/brainstormer-dashboard-needs/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: brainstormer-dashboard-needs
+description: "Use when running as a brainstormer or researcher whose steward/coordinator publishes NEEDs to the human via a dashboard board — author NEEDs as answerable action-picks, consume routed ANSWERS from dashboard results, and keep the board's view of your question in sync with reality."
+---
+
+# Brainstormer/researcher: NEEDs on the dashboard
+
+When your steward or coordinator runs a dashboard board for the human (the
+steward-console pattern), your NEED travels as an **action-pick widget** the
+human answers by clicking. This is a thin overlay on `using-the-dashboard`
+(invoke it first for the CLI contract and the honesty table) and on the
+queue-aware pattern you already run — same discipline, new surface: the
+question leaves your hands as a structured pick, and the answer comes back as
+a routed ANSWER message, exactly as before.
+
+## Authoring a NEED for the board
+
+Send your steward the NEED in board-ready shape — question, 2-3 discrete
+options with one-line consequences, and what nuance the human might add:
+
+```text
+NEED [topic]: Does X count deleted agents' messages?
+  A) Live-only — deleted history can't manufacture recency (no migration)
+  B) Include deleted — needs a new (agent_id, created_at) index
+  allow_text: yes (owner usually adds "but weigh X")
+  context: blocks gap-analysis step 3
+```
+
+Rules with teeth:
+
+- **Discrete options or no board.** If the NEED is genuinely open-form, say so
+  — the pick is for choices, not for open essays.
+- **One NEED, one pick.** Split multi-part rulings.
+- **Say what it blocks.** The human triages by consequence.
+
+## Consuming the ANSWER
+
+The routed ANSWER arrives as a message (steward-relayed, owner's words — pick
+plus typed nuance) and the board flips your question to ANSWERED. Your job:
+
+1. Fold the answer into the design exactly as you would a terminal relay.
+2. If the ANSWER changes the board's framing (follow-up question), author the
+   follow-up as a NEW pick — don't mutate the answered one's meaning.
+3. Never re-ask an ANSWERED question; `thrum dashboard show` marks it
+   ANSWERED, and the durable record is the answer MESSAGE.
+
+Note: if nothing has been posted for you yet, `dashboard show`/`get` return
+`found: false` with an empty envelope, not an error — don't read that as a
+failure.
+
+## Honesty (same table as the commons)
+
+While E4 (answer round-trip) is NOT landed, board picks cannot be answered in
+the UI — your NEED still routes via the steward/message channel exactly as
+`brainstorm-queue-aware` prescribes. The board-shaped authoring above is the
+format to keep using so the transition is seamless when E4 lands. Until then,
+a board is rehearsal surface only: never assume the human saw a widget.
+
+## Refs to other skills
+
+- `using-the-dashboard` — surface + CLI contract + honesty table (invoke first)
+- `brainstorm-queue-aware` — the steward NEED/ANSWER loop this overlays

package/assets/skills/conversation-only-context/SKILL.md

@@ -141,15 +141,18 @@ Write to the pane only when the human asked, or when the decision is one only th
 human can make. Everything else goes through `thrum send` / `thrum reply`.
 Surface an owner-only decision crisply, with a recommendation attached.
 
-## VM work
+## Remote and VM work
 
-Use a named persistent driver (`vmdriver_<slug>`) per
-`dev-docs/daemon-wedge-sync-audit/execution-pattern-driver-subagents-in-vm.md`:
-reach the VM only through the repo's tmux-ssh script, state the three-clause GO
-(execute now · drive to completion yourself · then stop and report), require the
-isolation proof and the 3-section report. VM specifics — profiles, first-boot
-re-key, isolation legs — are in `dev-docs/vm-dev-patterns/`. Never do VM work
-yourself.
+Use a named persistent driver (`vmdriver_<slug>`), continued by `SendMessage`
+across rounds. Reach the remote environment only through the persistent-session
+command your project sanctions, never a one-shot remote exec. State the
+three-clause GO (execute now · drive to completion yourself · then stop and
+report), require the isolation proof before anything touches a shared service,
+and require the 3-section report. Never do the remote work yourself.
+
+The full pattern is `resources/driver-subagent-pattern.md`; five worked shapes,
+including the restart handoff of a live driver, are in
+`resources/remote-environment-scenarios.md`.
 
 ## Restart handoff
 
@@ -170,6 +173,11 @@ Restart on a number read from the pane footer, never on a felt sense.
   disk, consolidate, for N>6 items. This skill sets the session's posture; that one
   runs a single pass.
 - `choosing-subagent-models` — the tier policy and source of the CONSTRAINTS block.
+- [driver-subagent-pattern.md](resources/driver-subagent-pattern.md) — the full
+  remote-work pattern: the named driver, the three-clause GO, the isolation
+  proof, the report contract, the parent's duties, the anti-patterns.
+- [remote-environment-scenarios.md](resources/remote-environment-scenarios.md) —
+  five worked shapes, from a long lab run to a restart handoff of a live driver.
 
 ## Failure modes
 

package/assets/skills/conversation-only-context/resources/driver-subagent-pattern.md

@@ -0,0 +1,138 @@
+# The driver subagent pattern — running remote work without spending your context
+
+Use this when the work lives somewhere your session should never go directly: a
+remote host, a virtual machine, a lab box, a container, a sandboxed service. You
+stay two steps removed.
+
+```
+you (parent)          holds: the question, the yes/no, a short evidence summary
+  └─ named driver subagent      holds: commands, logs, retries, waiting, troubleshooting
+       └─ remote environment    holds: the real system under test
+```
+
+Your context never receives build logs, file dumps, or command transcripts. The
+driver holds those and answers questions about them.
+
+## 1. One driver, named, continued by message
+
+Create the driver once with an explicit `name` and an explicit `model`, then
+continue it in rounds: GO, report, next GO. It keeps its remote session, its
+findings, and its troubleshooting state across rounds.
+
+Do this:
+
+1. `Agent(name: "vmdriver_<slug>", model: "sonnet", prompt: <round-1 GO>)`.
+2. Wait for its report.
+3. `SendMessage(to: "vmdriver_<slug>", message: <round-2 GO>)`.
+
+Do not dispatch a fresh subagent per step, and do not dispatch one told to
+"monitor until done". A subagent whose turn ends is not waiting, it is gone, and
+a monitor it armed in that turn never reports. Run one driver per investigation
+thread and parallelize across threads, not across the steps of one thread.
+
+## 2. Every GO carries the three clauses
+
+State all three, every round:
+
+1. This is the GO. Execute the sequence now. It is not another round of
+   questions.
+2. Drive it to completion yourself. Poll, retry, troubleshoot. Do not arm a
+   monitor and end your turn.
+3. Then stop and report. Nothing pending.
+
+Clause 2 is the one that decides whether the round produces work or silence.
+
+## 3. What a GO must contain
+
+1. Goal, then ordered steps, each naming the exact fields to capture before and
+   after.
+2. The one sanctioned way to reach the environment, named explicitly, with the
+   alternatives ruled out. A one-shot remote exec is usually a different shell
+   with a different path and a different caller identity, so it silently tests a
+   different thing than an interactive session does.
+3. The exact host or target, the working directories, and the revision under
+   test. A stale host alias that resolves elsewhere will pass every check while
+   measuring the wrong machine, so have the driver print the resolved hostname.
+4. An isolation gate, written as a numbered step, not as a caveat. See section 4.
+5. Fences that bind the driver and anything it dispatches: read-only version
+   control outside its own workspace, no installs that touch shared binaries, no
+   restart of a shared service, and no recursive delete flags.
+6. The report shape from section 6, including what you do not want back.
+
+## 4. Isolation proof before acting on a shared service
+
+If the environment also runs a shared instance of the service, every restart,
+stop, or reconfigure must target the sandboxed instance. Make the driver print
+the identity of the instance it is about to touch, and confirm it is the
+sandboxed one, before each such action.
+
+Verify isolation by effect rather than by intent. The sandboxed instance and the
+shared one should report different identifiers, and the test participants should
+be visible to the sandboxed instance and absent from the shared one.
+
+Sandboxing is rarely total. Check what your isolation mechanism does not cover,
+and have the driver clean up by hand at teardown whatever the sandbox reaper
+cannot reach.
+
+## 5. Long-running work in the remote environment
+
+1. Prefer a persistent interactive session. Working directory, environment, and
+   background jobs then survive between calls.
+2. Anything longer than a couple of minutes runs detached, writing its exit code
+   to its own file. A chained command hides the exit code. The driver polls that
+   file. The parent never polls.
+3. Run tests in the foreground with a bounded timeout and send output to a file.
+   Piping through a pager or a line filter masks the real exit status and drops
+   the lines that carry the stack dump.
+4. When anything looks crossed or stale, tear the session down and reconnect
+   rather than reasoning about which host you are on.
+
+## 6. The report contract, driver to parent
+
+Three sections, in this order, and nothing else:
+
+1. Isolation proof. Which instance was touched, and evidence it was the
+   sandboxed one.
+2. Measured results, per step, with the exact fields captured before and after,
+   and verbatim error text wherever a command failed. "It worked" without the
+   fields is not a result.
+3. Explicit close. Either "stopping here as instructed, nothing pending", or the
+   precise point it is blocked and why.
+
+No logs, no transcripts, no command dumps. Those stay with the driver. Ask a
+follow-up round for any specific one.
+
+## 7. Your duties as the parent
+
+1. Verify, do not trust. An idle notification means a turn ended, not that the
+   work finished. Check the agent's state before acting on it.
+2. Spot-check one or two load-bearing claims from each report, such as a
+   revision, an instance identifier, or a single field value. Decide which ones
+   before you send the GO.
+3. If a round produces no report and no progress, stop that driver and
+   re-dispatch with clause 2 stated more forcefully. Do not queue another GO
+   behind a dead one.
+4. Never do the remote work yourself to just check quickly. That is exactly the
+   context this pattern protects. Ask the driver a smaller question instead.
+
+## 8. Anti-patterns
+
+| Anti-pattern | What it produces | Replacement |
+|---|---|---|
+| Fire-and-forget subagent told to monitor | Long runs, large token spend, no output | Named driver, message rounds, clause 2 |
+| One-shot remote exec instead of a session | Wrong path, wrong caller identity, wrong test | The one sanctioned access path, stated in the GO |
+| A stale host alias | Results from the wrong machine, all checks green | Print the resolved hostname in the isolation proof |
+| Driving behavior from a raw shell | Tests the unbound caller path, not the real one | Send the command into the participant's own pane |
+| Parent reading logs to help | Spends the context the pattern exists to protect | Ask the driver for the one field you need |
+| Work committed on a stale base | Invisible to everyone, diverges quietly | Cut the workspace from current trunk, check the base revision |
+
+## 9. Checklist before sending a GO
+
+1. The driver is named, and I will continue it by message rather than
+   re-dispatch.
+2. The GO has ordered steps with captures, the sanctioned access path, the host
+   and paths and revision, the isolation gate as a step, the fences, the report
+   shape, and the three clauses.
+3. `model` is passed explicitly.
+4. I know which one or two claims I will spot-check.
+5. Nothing in the GO can reach a shared service or install a shared binary.

package/assets/skills/conversation-only-context/resources/remote-environment-scenarios.md

@@ -0,0 +1,97 @@
+# Worked scenarios — driving remote work through a driver subagent
+
+Five shapes you will meet. Each names what the parent keeps, what the driver
+owns, and the trap specific to that shape. The pattern itself is in
+`driver-subagent-pattern.md`. Placeholders: `<remote-host>` is the machine,
+`<your-ssh-wrapper>` is whatever persistent-session command your project
+sanctions for reaching it.
+
+## Scenario 1 — a long lab run on a remote box
+
+You want a multi-hour load or soak run and a verdict, not a log.
+
+1. Spawn `vmdriver_<slug>` with `model: "sonnet"`. The GO names the run, the
+   revision under test, and the exact metrics to report.
+2. The driver opens a persistent session with `<your-ssh-wrapper> <remote-host>`,
+   starts the run detached, and writes the exit code to its own file.
+3. The driver polls that file. You do not. You go on talking to the operator.
+4. The driver reports the three sections and stops.
+
+Trap: a run started inside a one-shot remote exec dies with the connection, and
+the failure reads as a crash in the thing under test. Start it detached from a
+persistent session.
+
+## Scenario 2 — a reproduction that needs a sandboxed service
+
+The bug only appears in a running system, so a source read cannot settle it.
+
+1. The GO orders: build the revision under test, bring up a sandboxed instance
+   of the service, print that instance's identity, and confirm it differs from
+   the shared instance before touching anything.
+2. Only then does the driver run the reproduction steps, capturing the named
+   fields before and after.
+3. The report leads with the isolation proof.
+
+Trap: sandboxing usually covers the service and its data but not every process
+the service spawns. Ask the driver, in the GO, to state what its sandbox does
+not cover, and to hand-clean those at teardown.
+
+## Scenario 3 — a multi-round measurement with a parked driver
+
+You need a baseline, a change, and a comparison, with your own judgment between
+rounds.
+
+1. Round 1 GO: take the baseline, report the fields, stop.
+2. You read a short report, decide, and send round 2 by message. The driver
+   still holds its session, its build, and its earlier numbers, so round 2 costs
+   almost nothing to set up.
+3. Round 3 asks for the comparison in the driver's own words plus the raw fields.
+
+Trap: re-dispatching a fresh subagent between rounds throws away the warm
+environment and the earlier context, then pays to rebuild both. Continue the
+named driver instead.
+
+## Scenario 4 — driving real agents inside the remote environment
+
+You are testing behavior that only exists for a properly bound, running agent.
+
+1. The driver brings up participants in the sandboxed environment and starts
+   their runtimes.
+2. It exercises behavior by sending commands into each participant's own pane,
+   not from the raw shell. A raw shell is an unbound caller and tests a
+   different, usually always-failing, path.
+3. It reads results by capturing the pane and by inspecting the participant's
+   own state files before and after.
+4. It can ask a participant an investigative question and get reasoned findings
+   back. These are full agents, so delegate cognition, not just keystrokes.
+
+Trap: a pane reported alive may still be parked at a first-run trust prompt with
+no runtime behind it. Verify by pane content, never by a status field.
+
+## Scenario 5 — restart handoff of a live driver
+
+Your context is near its limit and a driver is mid-investigation.
+
+1. Message the driver: finish the current step, write your file, report, and
+   stop.
+2. Record in your restart snapshot, for that driver: its name, what it owns, its
+   result file path, its model, the round it was on, and any state it left
+   behind in the remote environment such as a running job, a live session, or a
+   sandbox that has not been torn down.
+3. State plainly which drivers have already exited.
+4. Your successor respawns the driver with the result file as seed and resumes
+   at the next round.
+
+Trap: a driver left mid-flight across a restart leaves an orphaned sandbox and a
+detached job nobody owns. The snapshot line about leftover state is the part
+that gets skipped and the part that costs the most.
+
+## Choosing between shapes
+
+| Signal | Shape |
+|---|---|
+| One question, one long run | Scenario 1 |
+| Behavior only reproduces in a live system | Scenario 2 |
+| You must judge between rounds | Scenario 3 |
+| The bound-caller path is what is under test | Scenario 4 |
+| Your context is the binding constraint | Scenario 5 |

package/assets/skills/coordinator-assessing-agent-completion/SKILL.md

@@ -123,9 +123,30 @@ salvaged files distinct names and land the salvage somewhere durable (the main r
 **`thrum agent delete --force` is REFUSED by the CAS guard on a stale agent with an empty
 `agent_pid_start_time`** (*"expected-state premise is required … refusing rather than treating
 an empty/never-read premise as a match"*). `--force` does NOT bypass it; the guard is
-correct. So the reap that actually frees load is **`git worktree remove --force <path>`** —
-the delete best-effort-fails and leaves a **benign orphan DB row**, which you LEAVE (filtered
-at query per the fleet ruling; never `agent cleanup --force` to tidy them).
+correct. So the reap that actually frees load is worktree removal — but salvage BEFORE you remove,
+then remove PLAIN (no `--force`):
+
+1. Enumerate untracked+ignored `.thrum` content — BOTH flags, one flag alone misses a class
+   (thrum-j14q3): `git status --untracked-files=all --ignored -- .thrum`
+2. Salvage BOTH kinds to their canonical redirect paths, and `cmp`-verify each copy is
+   byte-identical to its source:
+   - `?? .thrum/agents/<agent>/sessions/*-restart.md` — the restart snapshot.
+   - `!! .thrum/context/<agent>.md` — gitignored, NOT daemon-held, the **only copy**;
+     losing it is permanent. (`_preamble.md` is regenerable — skip it.)
+3. THEN `git worktree remove <path>` — **plain, no `--force`.** ⚠️ This refusal is a REAL
+   backstop only for untracked/modified content (git's own rc=128 refusal) — it is NOT a
+   backstop for the gitignored `.thrum/context/<agent>.md` file: `git worktree remove`
+   silently deletes ignored-only content with exit 0, no refusal, no warning (verified by
+   direct reproduction). **Step 2's salvage is the ONLY protection for that file — there is
+   no git-level safety net behind it.** The rc=128 refusal still matters (it catches a stray
+   untracked restart-snapshot salvage missed, or any other unexpected untracked file), so
+   still read the BARE rc and still treat a refusal as a signal to investigate — just don't
+   mistake it for protecting the ignored-file class. (Not a pipe — a pipe returns the last
+   command's rc, not `git`'s.)
+
+The delete (`thrum agent delete`) best-effort-fails and leaves a **benign orphan DB row**,
+which you LEAVE (filtered at query per the fleet ruling; never `agent cleanup --force` to
+tidy them).
 
 ⚠️ **After a large reap you may see a `DeadAgentSweeper` skip alert + elevated write-RPC
 latency — do NOT assume the reap caused it.** This box carries a standing single-writer

package/assets/skills/coordinator-dashboard-human-loop/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: coordinator-dashboard-human-loop
+description: "Use when the coordinator publishes or maintains a dashboard board FOR the human owner (roster, NEED queue, owner decisions, pipeline) or routes owner answers from a dashboard back to agents. Loads the human-loop mandate - a posted question is a PROMISE — it stays answerable and visible until answered, and nothing on the board disappears silently on your side."
+---
+
+# Coordinator dashboard: the human loop
+
+You own boards the HUMAN reads — the reference shape is the Brainstorm Steward
+console: ① NEED queue (unified, oldest-first, each an action-pick) ② roster
+health ③ owner decisions (pending + recently-resolved) ④ pipeline status.
+Surface basics live in `using-the-dashboard` — invoke it for the CLI shapes
+and the live-vs-coming honesty table. THIS skill carries the loop mandate.
+
+## 🔴 The mandate: posted questions don't disappear until answered
+
+When a board carries a question for the human (an action-pick), that question
+is a PROMISE with four parts:
+
+1. **Visible** — it stays on the board (status PENDING) until answered or
+   explicitly withdrawn by YOU (update its text to withdrawn, don't just
+   delete it).
+2. **Answerable** — while E4 is NOT landed, an action-pick cannot actually be
+   answered in the UI. Until then, pair every board question with its
+   answering channel (the NEED still routes via message/steward as today) and
+   say so on the board — never let the human hit a dead control.
+3. **Tracked** — check `thrum dashboard results` after every relevant nudge;
+   an answer arrives as a message carrying `question_id` + pick + optional
+   text. Unread answers + a PENDING widget = you broke the loop.
+4. **Closed** — on consuming an answer, `thrum dashboard update <widget-id>`
+   to flip that pick's `status` to `resolved` (and log the resolution in your
+   decisions list). An answered question that still shows PENDING is the
+   coordinator-loop failure mode. If something else wrote the board first,
+   your `update` can be rejected as an `expected_rev` mismatch — re-read with
+   `dashboard show` and resubmit against the fresh `rev` (see
+   `using-the-dashboard`).
+
+## Authoring discipline
+
+- **One question, one action-pick.** Don't bundle three rulings into one
+  widget — the human answers picks discretely (that's why pick+optional-text
+  won over free-text).
+- **Options carry the tradeoff.** Each option's label states the choice AND
+  its one-line consequence ("Live-only — no new migration"); the human should
+  not need `get` to understand a vote. Set `allow_text: true` — "B, but weigh
+  X" is how owners actually answer.
+- **Board hygiene is part of the loop.** Stale roster stats and resolved
+  pipelines rot the board's credibility; refresh stat-rows when state moves
+  and prune sections that no longer serve. The user can delete any widget
+  SILENTLY (you are not nudged) — a widget that vanished was seen and
+  dismissed; check `show` before reposting.
+- **`clear` is a reset, not an archive.** Need history? It lives in the
+  answer messages and your memories, not on the board.
+
+## Routing answers
+
+An answer message is routed to the OWNING agent of the question (for steward
+consoles: relay to the originating brainstormer, in the owner's words — the
+pick plus their typed nuance). Relay the TEXT the human wrote; paraphrasing
+away their nuance defeats the optional-text feature.
+
+## Ship gate
+
+The USE-mandate blocks of this skill activate when E3 (web UI tab) + E2 (CLI)
+land. Before that, the board renders nowhere — publishing is a daemon-side
+rehearsal only, and the mandate sections are inert by the honesty table in
+`using-the-dashboard`.
+
+## Refs to other skills
+
+- `using-the-dashboard` — surface + CLI contract + honesty table (invoke first)
+- `coordinator-running-brainstorm-cycles` — where board NEEDs come from
+- `coordinator-managing-state-and-lifecycle` — state ownership the boards reflect

package/assets/skills/coordinator-deploying-the-fleet/SKILL.md

@@ -0,0 +1,396 @@
+---
+name: coordinator-deploying-the-fleet
+description: "Use when rolling a build across ALL boxes - fleet deploy, fleet roll, rolling the fleet, deploy everywhere, ship to every box, canary then the rest, promote the canary, fleet rollout, deploying after a merge batch. Orchestrates the staged multi-box order and the promotion gate between stages, and delegates each individual box to the coordinator-deploying-a-box runbook. Load this BEFORE dispatching any box."
+---
+
+# Coordinator: Deploying a Build Across the WHOLE FLEET — staged order, canary, promotion gate
+
+**This skill is the ORCHESTRATION layer. It does not replace
+`coordinator-deploying-a-box` — it calls it, once per box.**
+
+- **This skill answers:** which box goes first, what must be true before the next
+  one goes, who runs each one, and what is owed after the last one.
+- **`coordinator-deploying-a-box` answers:** how to deploy one box safely.
+
+> # 🔴🔴 LOAD `coordinator-deploying-a-box` FOR EVERY BOX — **INCLUDING THE BUILD BOX, YOUR OWN BOX. NO EXCEPTIONS.**
+>
+> **This is the #1 way this skill fails, and it has failed this way MORE THAN ONCE
+> (Leon, 2026-09-03).** You dispatch the per-box runbook to every REMOTE coordinator —
+> and then you drive your OWN box (the build box) by hand, improvising the install and restart,
+> because *"I'm the coordinator, I'll just do it."* **That improvisation IS the failure.**
+> The per-box runbook carries steps that are invisible until they bite:
+> - 🔴 **On macOS you MUST restart via `scripts/mac-daemon-restart-via-cron.sh`, NEVER a
+>   bare `thrum daemon restart`** — a terminal/VSCode-parented daemon is silently DENIED
+>   Local Network (TCC) permission and cannot dial LAN peers. A new binary is a new cdhash,
+>   so the "Allow devices on the local network" prompt MUST re-fire and the operator MUST
+>   click Allow. **A bare restart on the build box looks successful and leaves every LAN peer
+>   bridge hanging "connecting" forever** (§6b-mac of the per-box runbook).
+> - the backup sizing formula, the SHA-CONTAINS-the-fix ancestry check, the by-effect
+>   verification, the strand-gate, the phase reconcile — none of which you carry in your head.
+>
+> **⇒ THE MOMENT YOU REACH YOUR OWN BOX (or ANY box you drive yourself), STOP AND LOAD
+> `coordinator-deploying-a-box`.** Executing-directly (not dispatching) is the ONLY thing
+> that differs on your own box — you still LOAD IT AND FOLLOW IT, step for step. Reaching for
+> `thrum daemon restart`, `install.sh`, or `thrum backup` on your own box WITHOUT the per-box
+> runbook loaded is the red flag; if you're doing that, you have already skipped this.
+
+**Read both. Skipping the per-box runbook because you read this one — or because the box is
+your OWN and you'll "just do it" — is the failure this split is designed to prevent.**
+
+---
+
+## 0. THE ONE RULE THAT OUTRANKS EVERYTHING HERE
+
+🔴 **NEVER ssh-deploy INTO a box. Each box's OWN coordinator drives its OWN
+deploy, LOCALLY.** (Leon, standing, binding.)
+
+A non-interactive ssh deploy silently drops node/pnpm from PATH, `make build-ui`
+exits 127, **the deploy CONTINUES and reports success**, and lands an UNBUILT
+SHA. The rule exists because the failure reports green.
+
+**So your job in a fleet roll is DISPATCH AND GATE, never execution — except on
+your own box, which you EXECUTE directly (not dispatch) but STILL under
+`coordinator-deploying-a-box`, loaded and followed step for step (see the 🔴🔴 block
+above).** "Except on your own box" means you run the commands yourself instead of
+dispatching them — it does NOT mean you improvise them from memory. If you find
+yourself typing `ssh` and `make install` in the same command, stop — and if you find
+yourself running `thrum daemon restart` / `install.sh` / `thrum backup` on your own box
+without having loaded the per-box runbook, stop there too.
+
+⚠️ **CLARIFICATION — an `scp` of the signed pro-bundle zip into a box's
+`~/.thrum/update/` is DISTRIBUTION OF AN ARTIFACT, not a remote build or
+install, and does NOT violate this rule.** The rule forbids driving a box's
+build/install/restart FROM another machine. Copying an already-built,
+already-signed bundle to where that box's own coordinator will unzip and
+install it FROM is the sanctioned distribution mechanism (see §4) — the box
+still does its own unzip + `install.sh` + `thrum daemon restart`, locally, on
+its own account. Never conflate "the bytes moved over the network" with "the
+box was remote-driven."
+
+---
+
+## 1. THE ORDER — ONE fixed point, the rest composed per roll
+
+🔴 **ONLY ONE THING IS A STANDING RULE: the designated canary (per
+`.fleet.deploy_roster`) goes FIRST, ALONE.**
+
+**EVERYTHING ELSE IS COMPOSED FRESH EACH TIME.** Recorded rolls disagree, and
+they disagree deliberately.
+
+🔴 **"COMPOSED FRESH" IS THE ORDER, NOT THE MEMBERSHIP.** Every box in the roster
+MUST be rolled — the roster is the fleet. Compose the order per roll, never the
+set. Deferring a box requires the owner's explicit sign-off for that roll and a
+message to that box's coordinator that it is deferred.
+
+⚠️ **DO NOT WRITE "THE BUILD BOX GOES LAST" INTO YOUR PLAN AS A RULE. IT IS A
+DEFAULT, AND IT HAS BEEN DELIBERATELY OVERRIDDEN** — on 2026-07-28 the build box
+went SECOND, because the owner needed the changes demonstrable at a meetup.
+**The owner sets the order; this skill sequences whatever order is set.**
+
+**Sensible default when nobody says otherwise:** the canary → the remaining
+boxes (parallel where they share no state) → the build box last.
+**Reason to keep the build box late:** it hosts the most agents and is the
+coordinator's own box, so a bad build there costs you the ability to drive the
+recovery. **That is a reason, not a law.**
+
+Each box's coordinator and deploy target are defined in `.thrum/config.json`
+under `.fleet.deploy_roster` — read them there; **never hardcode box
+identities in this skill.**
+
+🔑 **This skill runs from the fleet orchestrator's own box (the build box); the
+roster lives in that box's config.** Resolve the box list and, for each box,
+its `ssh_alias` / `coordinator` / `daemon_id` from that same
+`.fleet.deploy_roster` entry:
+
+```bash
+jq -r '.fleet.deploy_roster | keys[] | select(startswith("_") | not)' .thrum/config.json
+                                                                  # box list — underscore-prefixed
+                                                                  # keys (e.g. `_note`) are roster
+                                                                  # metadata, not boxes; filter them
+jq '.fleet.deploy_roster["<box>"]' .thrum/config.json            # one box's entry
+                                                                  # (ssh_alias, coordinator, daemon_id)
+```
+
+**Resolve coordinators by `daemon_id` JOIN, NEVER by name** — a name is a
+label somebody chose; an agent named for a box has been found resident on a
+different one. **The public-line box is EXCLUDED** (public 0.10.x line — see below).
+
+⚠️ **At least one box's position in the roll is INCONSISTENT across rolls** —
+sometimes explicitly "in order", sometimes trailing. **Ask; do not assume.** It
+is always driven by its own coordinator, never dispatched around.
+
+### PREP-AND-HOLD — the mechanism that makes a staged roll safe
+Dispatch several boxes at once to do **READ-ONLY prep only**: measure current
+state, take the backup, `git pull`, capture BEFORE readings. Then:
+
+> **"PREPARE AND HOLD. CANCEL NOTHING. DO NOT RESTART until I release you BY
+> NAME."**
+
+**Release one box at a time, by name.** This gets the slow prep done in parallel
+without any box mutating itself before the canary has reported.
+
+⚠️ **The public-line box's coordinator runs the PUBLIC 0.10.x line and is
+EXCLUDED from 0.11 rolls.** Do not dispatch it.
+
+🔴 **RESOLVE EVERY COORDINATOR FROM `thrum team` AT DISPATCH TIME, NOT FROM A
+CACHED NAME.** A name is a label somebody chose; the authoritative method is a
+`daemon_id` join — join the `daemon_id` from `.fleet.deploy_roster` against
+`thrum team`'s live roster, never match on name. An agent's NAME and its
+WORKTREE NAME are not its location — an agent named for a box has been found
+resident on a different one, and obeying that name would have driven the
+forbidden ssh path.
+⚠️ **`thrum agent list --all` returns ZERO for agents that certainly exist** —
+do not use it as your roster instrument, and do not read its empty output as an
+absence.
+
+---
+
+## 2. THE PROMOTION GATE — what the canary must prove before anyone else goes
+
+**Do not release stages 2-5 on "the canary finished." Release them on these,
+each measured BY EFFECT on that box:**
+
+- Installed binary `--version` **equals the pin exactly** — not "close", not
+  "the branch".
+- Daemon restarted with a **NEW PID**, and `daemon status` reports the pin.
+  ⇒ **MERGED == INSTALLED == RUNNING, all three agreeing.**
+- Schema **before AND after** — proves migrating-vs-not by effect rather than
+  from the delta.
+- UI built for real (module count, signed) — **not the exit-127 shape**.
+- Built from a **CLEAN detached worktree at the pin**, `git status --porcelain`
+  empty ⇒ contamination closed BY CONSTRUCTION, not by inspection.
+- 🔑 **`sync_checkpoints` count BEFORE and AFTER, and they match.** A reset is
+  the silent peer-stranding failure that has **no repair command**. **This check
+  is worthless without a BEFORE reading** — take your own; do not skip it
+  because the canary's was clean.
+- `crash-fatal.log` — 0 bytes, or read it before declaring success.
+
+⚠️ **"CANARY GREEN" IS NOT "ALL THREE PASSES PROVEN."** The canary usually
+proves the BINARY pass only. Say which passes you verified, every time.
+
+🔴 **THE CANARY RESULT DOES NOT TRANSFER. EVERY BOX IS MEASURED ON ITS OWN
+NUMBERS.** Measured instance: the canary came back green while another box
+had **207 matured tombstones over live agents**. The canary proves the BUILD is
+sound; it says nothing about any other box's state. **Do not let a green canary
+talk a box out of taking its own BEFORE readings.**
+
+⏱ **GIVE A CONVERGENCE CHECK LONG ENOUGH TO DISCRIMINATE.** A short wait cannot
+tell "the fix works" from "it had already converged before you looked." One roll
+made a full 3-minute wait a hard requirement after a too-short check produced an
+uninterpretable pass. **Pick the interval from what the mechanism needs, not
+from impatience.**
+
+### The go/no-go has never been a fixed number — get it from the owner
+The go/no-go has never been a fixed number. **State YOUR
+bar explicitly before promoting, so it can be challenged.** An unstated bar is
+indistinguishable from no bar.
+
+---
+
+## 3. THE THREE PASSES — a "deploy" silently conflates three independent things
+
+**Every box owes all three. They fail independently and a box can be current on
+one and month-stale on another.**
+
+| Pass | What it updates | Who runs it |
+|---|---|---|
+| 1. install the pre-built, Developer-ID-signed pro-bundle via its own `install.sh`, **then** `thrum daemon restart` | the **binary** | the box's own coordinator |
+| 2. `thrum roles refresh` **then** `thrum roles deploy` | **role preambles** | the box's own coordinator |
+| 3. plugin refresh / reinstall (installs the BUNDLE's plugins — already made correct/complete by the plugin-bundle spine — rather than the box's own checkout) | **skills, commands, hooks** | 🔴 **the OPERATOR (Leon)** — a coordinator CANNOT self-serve this |
+
+🔴 **THE BOX NEVER BUILDS OR SIGNS ITS OWN BINARY. IT INSTALLS A DELIVERED
+ARTIFACT.** `make install` (build-from-local-checkout-and-sign) is retired from
+the Pass-1 fleet/box binary-update path. The box's job is: obtain the pro-bundle
+zip (see §4), unzip it, run its `install.sh`, restart the daemon. Nothing on the
+box compiles Go or codesigns.
+
+🔴 **PASS 2 ORDER IS LOAD-BEARING AND NOT OBVIOUS:** `refresh` FIRST (shipped
+templates → role template), THEN `deploy` (role template → per-agent preamble).
+**Running `deploy` alone re-renders agents from the OLD templates and reports
+success.**
+
+🔴 **RUN PASS 2 BETWEEN THE BUNDLE INSTALL AND THE DAEMON RESTART, ALWAYS:**
+bundle `install.sh` → `thrum roles refresh` → `thrum roles deploy` → daemon
+restart. Do the refresh+deploy the instant `install.sh` finishes and BEFORE
+restarting the daemon, so the current preamble is already in place when any
+agent next runs `thrum prime`, restarts, or checks its preamble.
+
+🔴 **PASS 2 IS MANDATORY WHENEVER THE BUILD CHANGES
+`internal/context/roleconfig/templates/` OR the compiled-in preamble.**
+Preambles are RENDERED, not read live — installing a binary changes the source
+and changes **nothing any agent reads**. There is **no staleness signal**: a box
+serving a month-old render looks identical to a current one.
+
+🔴 **PASS 3 REQUIRES A PLUGIN VERSION BUMP OR IT REACHES NOBODY.** The install
+cache is keyed by version; an unchanged version means the installer skips the
+re-copy and every skill edit stays invisible. Invoke the `plugin-update` skill;
+do not improvise it.
+
+### 🔴 THE BOX'S **REPO CHECKOUT** MUST BE AT THE PIN BEFORE PASS 3 — THE BINARY BEING AT THE PIN IS NOT SUFFICIENT
+
+The plugin source is a **LOCAL PATH**, so pass 3 reads the checkout, not the
+binary — a box whose binary is at the pin can still install a plugin version
+one bump behind if its working tree lags.
+
+⚠️ **AND THE BOX'S OWN VERIFICATION CANNOT SEE IT.** It compared installed
+skills against its own source, byte-for-byte, zero mismatches — and
+**both sides were the stale version.** That proves the box is internally
+consistent WITH ITSELF and is structurally incapable of detecting a stale
+source. Same shape as render-fidelity-vs-doctrine-currency for preambles, except
+**pass 3 has no equivalent of the ancestry check**, so nothing warns you.
+
+🔴 **IT IS SELF-SEALING.** The cache is keyed by version, so at the stale version
+the installer sees a match and **skips the re-copy permanently.** Re-running the
+refresh does NOT fix it. Only bringing the checkout to the pin and re-running
+does.
+
+**⇒ Before handing a box to the operator for pass 3, verify BY EFFECT that all
+FOUR manifests read the pin's version.** A partial bump is worse than none — the
+runtimes then disagree about which build they are. And name the cache directory
+**explicitly** when verifying; never `ls | tail -1`, because version directories
+do not sort the way you expect (`…1.12` sorts BELOW `…1.3` and `…1.5`, and
+several versions coexist).
+
+**When reporting a deploy, name which passes you verified.** "Deployed" that
+silently covers all three is how staleness hides.
+
+---
+
+## 4. PRE-FLIGHT — before dispatching box 1
+
+0. 🔴 **FIRST ACTION, NON-OPTIONAL: `git fetch origin` then fast-forward-only
+   pull the repo root to `origin/<branch>`.** If the pull is not
+   fast-forwardable, STOP and surface it — never blind-merge in a shared tree.
+   Do this before reading any other pre-flight state below; a stale checkout
+   makes every subsequent check (trunk-green, pin, schema) a check against the
+   wrong tree.
+1. **Is trunk green?** Trunk-green is defined as `make gate` passing. A green
+   lane, a green package, or a clean dual review is **not** that claim.
+   ⚠️ **Publishing a green without naming its invocation is the most common
+   error here:** 0-of-6 and 0-of-15 are different claims in identical words.
+2. **PIN AN EXACT SHA. NEVER "tip".** Tip moves under boxes mid-roll — two boxes
+   told to deploy "tip" ship different code and both report success.
+3. **Migrating or not?** Compare `CurrentVersion` at the pin against each box's
+   running schema. A migrating roll pulls in the whole heavy-migration section
+   of the per-box runbook; a non-migrating one does not.
+4. **Forward-only:** each box's current SHA must be an ancestor of the pin.
+   Pair the check with a control that MUST refuse (an invented SHA).
+5. **Backup sizing** — the per-box runbook carries the formula. A percentage
+   rule is not it, and a stale `current/` answers "are we protected?" with a
+   wrong yes.
+6. **Announce the pin and the order** to every coordinator before starting, so
+   nobody deploys a different SHA.
+7. 🔴 **BUILD ONCE, DISTRIBUTE THE SAME ZIP TO EVERY BOX.** The build box
+   produces exactly ONE `make pro-bundle` at the pinned SHA. That
+   single zip — never rebuilt per box — is what every box in the roll installs
+   from. The staged roll therefore orchestrates three phases in order:
+   **build once** (the build box, `make pro-bundle` at the pin) **→ distribute**
+   (hand the same zip to each box's coordinator, via drop-folder or direct
+   hand-off — see below) **→ each box installs from the delivered bundle**
+   (§3 Pass 1). No box re-derives the artifact; every box's binary is
+   byte-identical because it came from the same zip.
+   - **Distribution mechanism 1 — drop-folder:** the built zip is placed where
+     each box's own sync/fetch path picks it up into its local
+     `~/.thrum/update/` for that box's coordinator to find and unzip.
+   - **Distribution mechanism 2 — hand-off:** the coordinator running the roll
+     hands the zip directly to a box's coordinator (e.g. `scp` into
+     `~/.thrum/update/` — see §0's clarification: this is artifact
+     distribution, not remote build/install).
+   - Whichever mechanism is used, confirm the box installed from the SAME
+     bundle (matching version/checksum) that was built at the pin — never a
+     locally-reconstructed one.
+   - 🔴 **NEVER pass `PRO_BUNDLE_VERSION=$(git describe)` when building the pro
+     bundle — trust the Makefile default** (`v0.11.0-rc.1` as of this writing,
+     re-check the current default before citing it). `git describe` falls back
+     to the nearest ancestor tag when the exact commit isn't tagged, which can
+     silently produce a WRONG version string — this is exactly how a stale
+     `v0.10.6-rc.4` string previously shipped in a v0.11 build: the
+     `v0.11.0-rc.1` tag was stranded on an unmerged release branch, so
+     `git describe` fell back to an ancestor v0.10.6 tag.
+
+---
+
+## 5. DISPATCHING A BOX — what the message must carry
+
+🔑 **Resolve the box's `ssh_alias` / `coordinator` / `daemon_id` from
+`.fleet.deploy_roster` in `.thrum/config.json` before dispatching** (see §1) —
+never from a remembered name. Join the coordinator by `daemon_id` against
+`thrum team`'s live roster, NEVER by name.
+
+Give each coordinator, explicitly:
+
+- **The exact pinned SHA** and the instruction to build from a clean detached
+  worktree at it.
+- **An instruction to load `coordinator-deploying-a-box` and follow it** — not a
+  summary of it. ⚠️ **A summary you wrote reads as complete precisely because
+  you wrote it**, and its omissions are silent.
+- **Which passes it owes** (1 and 2; pass 3 is the operator's).
+- **Its own BEFORE readings** — `sync_checkpoints`, schema, PID.
+- **That acceptance is BY EFFECT, never by exit code.**
+- **That it must report which passes it verified**, separately.
+
+---
+
+## 6. AFTER THE LAST BOX
+
+- 🔴 **ROSTER COMPLETENESS GATE — first.** Re-enumerate the roster from config,
+  not from propagated deploy-state (a box with a wedged sync never propagates its
+  row). Confirm every box is rolled on the pin or owner-deferred with its
+  coordinator notified. Name each box and its disposition in the roll-complete
+  report.
+- **Agent phase reconciliation, per box.** A restart leaves recorded `phase`
+  disagreeing with reality — live agents read `stale`, dead ones can read
+  `active`. Phase is local state and does not cross the peer boundary, so every
+  box runs it against its own daemon.
+- **Restart the orchestrators and long-lived agents** so they pick up the new
+  preambles and skills. 🔴 **Agents adopt a new preamble ON THEIR NEXT RESTART,
+  not immediately** — a live agent keeps behaving per the identity it was born
+  with. Track adoption by session birth time, never file mtime.
+- **Pre-release test suite — CHECK WHETHER IT IS OWED; do not assume it is.**
+  It is documented as a gate for cutting an RC/release, and a remote box runs it
+  after fleet deploys by standing arrangement. ⚠️ **A search of past rolls did
+  NOT establish it as a mandatory step for a routine binary/preamble/plugin
+  roll.** Read the run index: if its newest entry predates this deploy, the suite
+  has not run against what is now deployed — then decide, with the owner,
+  whether this roll warrants one. **Stated as a gap rather than invented as a
+  rule.**
+- **Update the deploy-state record** — per box: serving SHA, schema, AS OF, and
+  how established. **Do not normalise every row to one SHA**; an unmeasured row
+  is not a measured negative, and a tidied row is indistinguishable from a fresh
+  measurement.
+- **Sweep for SHA-anchored rules that just went stale.** A superseded SHA has
+  two roles that fail in OPPOSITE directions: as a GUARD it refuses legitimate
+  work and presents as caution; as a TARGET it validates the wrong artifact and
+  produces **a green that means nothing**. The target direction is the dangerous
+  one and it is the one a guard-sweep misses. Prefer re-deriving the live build
+  at run time over re-anchoring, which only re-arms the trap for the next roll.
+
+---
+
+## 7. HOLDS
+
+- **A fleet deploy is the OWNER'S CALL.** A lifted prohibition is not a
+  permission.
+- **Any box may hold its own deploy** and must say why. A box-local blocker that
+  does not touch the deploy path is not a reason to hold — check whether the
+  runbook's acceptance checks actually need the thing that is broken.
+- **If the canary fails, the roll stops.** Do not promote on a partial result.
+- **Deploy often, in small batches.** A large roll bundles unrelated changes, so
+  when a box misbehaves afterwards, attribution across a hundred commits gets
+  expensive fast.
+
+---
+
+## Red flags — STOP
+
+- `ssh` and `make install` in the same command.
+- Dispatching a box by NAME without resolving its coordinator at dispatch time.
+- Promoting past the canary on "it finished" rather than on the §2 checks.
+- Reporting "deployed" without saying WHICH of the three passes was verified.
+- Running `roles deploy` without `roles refresh` first.
+- Expecting skill changes to reach agents without a plugin version bump.
+- Deploying "tip" instead of a pinned SHA.
+- Reading an installer's exit 0 as proof the binary landed.
+- Taking an `after` reading with no `before` — especially `sync_checkpoints`.
+- Summarising the per-box runbook into a dispatch instead of telling the
+  coordinator to load it.

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

@@ -120,8 +120,8 @@ rediscovering these the hard way:
 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.
-8. Use `rm -r`, NEVER `rm -rf`, and use `git worktree remove --force` to drop a
-   worktree. A broad `ask` rule on `rm -rf *` outranks any narrow `/tmp` allow,
+8. Use `rm -r`, NEVER `rm -rf`; use plain `git worktree remove` to drop a worktree, never
+   `--force` as the default (see item 12 below). A broad `ask` rule on `rm -rf *` outranks any narrow `/tmp` allow,
    so `rm -rf` raises a human permission prompt EVERY time regardless of path —
    it stalls gate sub-agents mid-run waiting on a keystroke. `rm -r` runs free. Do NOT widen the ask rule
    to work around this; that entry is the only deletion protection on the box.
@@ -154,7 +154,11 @@ rediscovering these the hard way:
         HEAD is a gate-produced merge reachable from no ref and removal orphans
         it. Usually fine (a gate merge is reproducible by redoing it) but say so
         in your report rather than doing it silently.
-    Then `git worktree remove --force <wt>`.
+    Then `git worktree remove <wt>` — **plain, no `--force`.** Its rc=128 refusal backstops
+    ONLY untracked/modified content (see rule 8 on `rm -r`) — it does NOT cover gitignored
+    content, which git removes silently with no refusal; a clean rc=0 is not proof nothing of
+    value was in there (see coordinator-assessing-agent-completion's reap procedure). `--force`
+    is a justified override only, never the default (see coordinator-merging-code §7a).
 
 ## Trigger-directory skip logic
 

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

@@ -110,8 +110,8 @@ dispatch time — hand this list verbatim:
     (c) only if a pipeline is unavoidable, use `${pipestatus[1]}` on zsh /
         `${PIPESTATUS[0]}` on bash — and STATE WHICH SHELL, because the same
         string means different things in each.
-8. Use `rm -r`, NEVER `rm -rf`, and use `git worktree remove --force` to drop
-   a worktree. A broad `ask` rule on `rm -rf *` outranks any narrow `/tmp`
+8. Use `rm -r`, NEVER `rm -rf`; use plain `git worktree remove` to drop a worktree, never
+   `--force` as the default (see item 12 below). A broad `ask` rule on `rm -rf *` outranks any narrow `/tmp`
    allow, so `rm -rf` raises a human permission prompt EVERY time regardless
    of path and stalls gate sub-agents mid-run waiting on a keystroke. `rm -r`
    runs free. Do NOT widen the ask rule to work around this; that entry is
@@ -149,7 +149,11 @@ dispatch time — hand this list verbatim:
         HEAD is a gate-produced merge reachable from no ref and removal orphans
         it. Usually fine (a gate merge is reproducible by redoing it) but say so
         in your report rather than doing it silently.
-    Then `git worktree remove --force <wt>` (see rule 8 on `rm -r`). Rule 11's
+    Then `git worktree remove <wt>` — **plain, no `--force`.** Its rc=128 refusal backstops
+    ONLY untracked/modified content (see rule 8 on `rm -r`) — it does NOT cover gitignored
+    content, which git removes silently with no refusal; a clean rc=0 is not proof nothing of
+    value was in there (see coordinator-assessing-agent-completion's reap procedure). `--force`
+    is a justified override only, never the default (see coordinator-merging-code §7a). Rule 11's
     hazard notice on its own — teardown can destroy uncommitted state — reads
     as a reason NOT to tear down. A warning without a procedure does not
     produce caution; it produces paralysis plus litter.

package/assets/skills/persistent-watcher-archetype/SKILL.md

@@ -16,8 +16,16 @@ discipline (which handles routine, cost-driven restarts).
 Read `.thrum/agents/<you>/watch_params.json` at the top of every cycle. For
 every agent in your `roster`:
 
-1. **Keep it from stopping.** Capture its pane. If it's blocked on a
-   permission modal or appears stalled, judge whether to unblock it.
+1. **Keep it from stopping.** Capture its pane with the shipped script (see
+   "Driving your cycle" for the `thrum tmux capture` + SSH-fallback method) —
+   never capture ad-hoc or key on fixed prompt phrases. A failed or empty
+   capture is NOT a dead or idle pane: fall back and re-read; never skip a
+   roster member because its capture failed. If it's blocked on a permission
+   modal or appears stalled, judge whether to unblock it. A member that is
+   *persistently* unwatchable (fails every capture path, isolated,
+   unreachable) is escalated to your `parent` every cycle until a coordinator
+   or human removes it from your roster — never dropped, never silently
+   given up on (see Escalation).
 2. **Watch its context% and warn.** Read its ctx% from YOUR OWN tmux
    capture of its status bar — **never from a figure it claims about
    itself** (a message, a memory-footer line, anywhere). If it's getting
@@ -37,15 +45,19 @@ every agent in your `roster`:
 ## The modal bright line (non-negotiable)
 
 - Approve ONLY clearly-safe, recognized, non-`rm`/non-`--force` modals.
-- Anything containing `rm`, `--force`, or anything unrecognized → refuse or
-  escalate to your `parent`. Never approve on the merits — this is a
-  pattern check, not a judgment call.
-- Never approve blind: read the actual command text first.
+- `rm`, `--force`, or an unrecognized command → refuse or escalate to your
+  `parent`. That filter is mechanical.
+- Within the safe set, judge the COMMAND TEXT, not the modal's phrasing: read
+  the command and approve if it is clearly-safe and recognized whatever wording
+  the modal uses, else cancel or escalate. Never key on fixed prompt phrases;
+  never approve blind.
 - Verify by re-capture after acting — never trust exit status alone.
 - To unblock a REMOTE roster member's modal, use `thrum tmux send <agent> " "`
   (proxies by agent name to the owning peer daemon and appends Enter, so a
-  space+Enter confirms the default-focused option) — never `thrum tmux key`,
-  which is local-socket-only and errors on a remote agent. This grants only
+  space+Enter confirms the default-focused option); for a specific selection
+  use `thrum tmux send <agent> --keys <K1,K2,...>`. `thrum tmux send` is
+  peer-routed, so it works identically local or remote (fleet-wide) — this is
+  the replacement for the retired local-only tmux-key primitive. This grants only
   the leftmost/default option; the bright line above still applies. From the
   CLI/peer-router path this send is QUEUED behind the conservative
   monitor-silence wait, not instant — don't re-send while waiting it out.
@@ -109,6 +121,30 @@ is the entire reason the watch exists — and a blocked coordinator cannot
 receive its own escalation. The escalation would arrive at the one inbox
 guaranteed not to be read.
 
+### An unwatchable roster member: escalate every cycle until it is removed
+
+A roster member you **cannot watch at all** — capture fails by every path
+(local proxy *and* SSH fallback), the agent is fully isolated, or its owning
+daemon is unreachable so you cannot even message it — is NOT a member you may
+drop, mark dead, or fall silent on. It stays in your roster and it stays your
+duty.
+
+- **Escalate it to your `parent` every cycle it remains unwatchable —
+  repeatedly, not once.** A single "fully isolated" notice that you then stop
+  repeating is exactly the silent-give-up this archetype exists to prevent:
+  the roster member goes dark with nobody positioned to notice. Re-send the
+  escalation on each tick it is still unwatchable. (This is a standing
+  per-cycle duty, unlike the one-shot declared-intent nudge.)
+- **You never remove it from your own roster.** Roster membership is
+  coordinator-owned config in `watch_params.json`, which you only ever read.
+  Only a **coordinator or the human** may remove an agent from your roster —
+  the signal that it no longer needs watching. Until that removal lands in
+  `watch_params.json`, you keep escalating.
+- **Do not borrow the empty-roster shutdown rule here.** "Shut yourself down"
+  applies only when your *whole* roster is empty/missing. One unwatchable
+  *member* out of several is not that case: keep watching the rest, keep
+  escalating the unwatchable one.
+
 ## Declared-intent reminders (duty #4)
 
 Each cycle, for each roster member, judge whether the last assistant turn

package/assets/skills/persistent-watcher-archetype/resources/thrum-capture-fallback.sh

@@ -63,12 +63,16 @@ ssh_destination() {
 
 run_local() {
   case "$MODE" in
-    # "${EXTRA_ARGS[@]:-}" not "${EXTRA_ARGS[@]}": a DECLARED-EMPTY array
-    # subscripted with [@] is a fatal unbound-variable under `set -u` on
+    # "${EXTRA_ARGS[*]:-}" not "${EXTRA_ARGS[*]}": a DECLARED-EMPTY array
+    # subscripted with [*] is a fatal unbound-variable under `set -u` on
     # bash <4.4 (a real bug, not a style choice -- `key` mode with zero
     # key args crashes on this fleet's /bin/bash 3.2.57 without the ":-").
+    # key mode delivers named tmux keys via `thrum tmux send --keys` (the
+    # peer-routed replacement for the retired local-only tmux-key primitive);
+    # EXTRA_ARGS (one key per element) is comma-joined into a single --keys
+    # value inside a subshell so IFS="," never leaks into the caller.
     capture) thrum tmux capture "$AGENT" 2>&1 ;;
-    key)     thrum tmux key "$AGENT" "${EXTRA_ARGS[@]:-}" 2>&1 ;;
+    key)     thrum tmux send "$AGENT" --keys "$(IFS=,; printf '%s' "${EXTRA_ARGS[*]:-}")" 2>&1 ;;
   esac
 }
 
@@ -77,7 +81,7 @@ run_ssh() {
   dest="$(ssh_destination)"
   case "$MODE" in
     capture) cmd="thrum tmux capture '$AGENT'" ;;
-    key)     cmd="thrum tmux key '$AGENT' ${EXTRA_ARGS[*]:-}" ;;
+    key)     cmd="thrum tmux send '$AGENT' --keys $(IFS=,; printf '%s' "${EXTRA_ARGS[*]:-}")" ;;
   esac
   # Client-side expansion of REPO_PATH/cmd into the remote command string is
   # intentional -- that's how the resolved repo path and thrum invocation

package/assets/skills/persistent-watcher-archetype/resources/thrum-watch-pane-capture.sh

@@ -29,7 +29,7 @@
 #
 # DELIBERATE SCOPE LIMIT: this script is MECHANICAL ONLY — capture, detect,
 # emit. It never auto-escalates and never auto-approves/denies a modal
-# (never calls `thrum tmux key`/`thrum send`). The persistent-watcher-
+# (never sends keys or text — never calls `thrum tmux send`). The persistent-watcher-
 # archetype skill is explicit that judgment (approve/cancel/escalate/nudge)
 # happens in the watcher's OWN turn when it reads the wake message this
 # script's summary line triggers, not in a script. A bash script cannot

package/assets/skills/using-the-dashboard/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: using-the-dashboard
+description: "Use when you want to present an interactive board to the human user (status, options, NEEDs with A/B/C picks), or when you see a dashboard mention and wonder what is actually usable today. Carries the CLI surface, the write/read discipline, and the live-vs-coming honesty table."
+---
+
+# Using the Agent Dashboard
+
+The Dashboard is an agent's way to put an **interactive board** in front of the
+human user: typed widgets (status rows, cards, lists), optional HTML regions,
+and **action-picks the user answers by clicking an option and optionally typing
+nuance**. It replaces the "agent runs a TUI" pattern — it is out-of-band from
+the messaging channel, so it never blocks messages and answers never scroll
+away.
+
+This is the COMMONS skill: role-agnostic surface + discipline. Role overlays
+(`coordinator-dashboard-human-loop`, `brainstormer-dashboard-needs`) add the
+role-specific loop on top. When an overlay and this skill conflict, the overlay
+wins for role-specific behavior.
+
+## 🔴 Honesty table — what is usable TODAY
+
+Check this BEFORE you promise the human anything. Stale promises are worse
+than no dashboard.
+
+| Capability | Status |
+|---|---|
+| `dashboard.set/get/show/clear/delete` RPCs (daemon-side) | **LANDED** on trunk (merge `6c7539236f83`); usable only against daemons BUILT after that merge — verify your daemon's build before relying on the RPCs |
+| `thrum dashboard` CLI (set/show/get/update/delete/clear/results) | **LANDED** on trunk (merge `108511a0`); usable only against a `thrum` binary BUILT after that merge — verify your CLI's build before relying on these commands |
+| Web UI Dashboard tab (where the human SEES a board) | **BUILT, NOT YET DEPLOYED** (E3 landed on trunk, merge `49712f87` — visible after the next deploy) |
+| Answer round-trip (user clicks → message + nudge to you) | **BUILT, NOT YET DEPLOYED** (E4 landed on trunk, merge `ea95318a` — visible after the next deploy) |
+
+**Consequence until the next deploy carries E3 and E4:** publishing a board
+is STILL a no-op for the human on any box running a pre-E3/pre-E4 binary —
+it renders NOWHERE there and, even where it renders, an answer cannot
+return to you, even though the UI and answer-round-trip code now both exist
+on trunk. Do NOT substitute a dashboard for a nudge or a direct message
+unless you know the box you're talking to has deployed a build containing
+BOTH E3 and E4. If the human cannot see the board or their answer cannot
+reach you, the question DOES disappear — the exact failure the dashboard
+exists to kill.
+
+**Consequence, now that E2 has landed:** the `thrum dashboard ...` command
+shapes below are runnable — but, per the E2 row above, only against a CLI
+binary built after `108511a0`. Against an older binary, or if you're
+calling the daemon directly, the raw RPCs (`dashboard.set` etc. over the
+daemon socket) remain the fallback surface.
+
+## The board model
+
+A dashboard is ONE structured document per agent: an envelope
+`{v, agent_id, title, updated_at, rev, widgets[]}`. Six widget types:
+`section` (labeled grouping), `stat-row` (label/value pairs),
+`card` (title + markdown body), `list` (ordered rows),
+`action-pick` (question + options + optional text — the interactive control),
+`html` (sanitized rich region, authored from a FILE).
+
+Semantics that matter to you as an author:
+
+- **Append-only + rev'd.** Every change appends a new snapshot; `rev` increments.
+  Your `update` keeps a widget's position; `delete` removes it; `clear` wipes
+  the board. Cleared/deleted content is **GONE** — the board is ephemeral, and
+  the DURABLE record of any decision is the answer MESSAGES, not the board.
+- **Widget cardinality (enforced):** action-pick ≤8, html ≤4, section ≤8,
+  card ≤24, stat-row ≤12, list ≤4, total ≤64. Lists have NO row cap.
+- **Answer path:** when the user answers an action-pick, you get a **nudge**
+  and the answer lands as a thrum MESSAGE (payload type `dashboard.answer`,
+  carrying `question_id`, the option `pick`, optional `text`). You read
+  answers with `thrum dashboard results`, then flip the widget's status via
+  `thrum dashboard update` so the board shows it resolved.
+- **User deletes are SILENT.** If a widget you posted disappears, the user
+  dismissed it — you are NOT nudged. Notice it on your next `show`; do not
+  repost it reflexively (the user saw it and removed it on purpose).
+- **No dashboard yet is not an error.** `dashboard.get`/`dashboard.show`
+  succeed with `found: false` and an empty envelope when nothing has been
+  posted for you yet — do not treat that as a failure to recover from.
+- **Concurrent writes are guarded by `expected_rev`, not merged.** If you pass
+  `expected_rev` and it no longer matches the board's current `rev`, the write
+  is rejected with `dashboard changed (rev %d, you expected %d) — re-read with
+  dashboard show and resubmit`. Fix: re-fetch the current document and
+  resubmit with the fresh `rev`. Omitting `expected_rev` skips the check
+  entirely (last-writer-wins) — fine for your own solo edits, risky if
+  something else writes the same board.
+
+## CLI surface (runnable now, against a `thrum` binary built after `108511a0`)
+
+```bash
+# Publish/replace whole widgets (upsert by widget id — targets update in place)
+cat > /tmp/board.md <<'EOF'
+{"title": "My board", "widgets": [ ... ]}
+EOF
+thrum dashboard set --doc-file /tmp/board.md
+thrum dashboard set --stdin < /tmp/board.md
+
+# HTML regions come from FILES ONLY — never inline (backticks in shell strings EXECUTE)
+thrum dashboard set --html-file /tmp/panel.html --html-id my-panel
+
+# Read
+thrum dashboard show                 # compact outline: what's on the board, what's PENDING/ANSWERED
+thrum dashboard get <widget-id>      # full widget JSON
+thrum dashboard results              # user answers (after your nudge), newest N selected, displayed oldest-first
+thrum dashboard results --unanswered # only questions with no answer yet
+
+# Mutate
+thrum dashboard update <widget-id> --doc-file /tmp/new-widget.json   # in place, keeps position
+thrum dashboard delete <widget-id>
+thrum dashboard clear                # wipe the whole board (content is GONE)
+```
+
+**Validation loop:** `set`/`update` either print `posted OK (rev N)` or fail
+with one of three error shapes: a per-widget schema error naming the exact
+widget id + field; a per-type cardinality error naming the widget TYPE + count
+(e.g. "too many action-pick widgets: 9 (max 8)"); or the aggregate/total-cap
+error, which names a CATEGORY TOKEN + count + max rather than a widget type
+(e.g. "too many widgets (total_widgets): 65 (max 64)" — "total_widgets" is the
+violation category, not a widget type: the per-type limits sum to 60 < 64, so
+a doc breaching 64 always breaches some per-type limit too, and there is no
+single offending widget type to name). On any of these: fix the file and
+resubmit — do not recompute the whole board inside one invocation.
+
+**Authoring rules with teeth:**
+
+- Widget `id`s are load-bearing — stable across updates; `update`/`delete`
+  and the answer join key off them (action-picks also carry `question_id`).
+- Text fields render as MARKDOWN (no raw HTML — that is the `html` widget's
+  job, sanitized). Keep compact fields single-line.
+- HTML files: no script/style/iframe/event-handlers — the render side strips
+  them, but author clean anyway.
+
+## When to reach for the dashboard (vs a nudge vs a message)
+
+- **Dashboard:** state the human will consume VISUALLY and possibly answer
+  interactively — rosters, queues of options, pipelines, NEEDs with discrete
+  choices. Persistent board the human checks on their own rhythm.
+- **Nudge:** something needs attention NOW and is small (one line). The
+  dashboard does not pulse or blink; urgent + tiny = nudge.
+- **Message:** conversation, anything needing prose back-and-forth, or anything
+  the record must keep forever (decisions live in messages).
+
+Anti-pattern: posting a board INSTEAD of answering a direct question. The
+dashboard is a surface you maintain, not a replacement for talking.
+
+## Refs to other skills
+
+- `coordinator-dashboard-human-loop` — coordinator overlay: owning a board for
+  the human, the human-loop mandate
+- `brainstormer-dashboard-needs` — brainstormer/researcher overlay: authoring
+  NEEDs as answerable action-picks
+- `using-the-queue`, `using-thrum-state` — sibling agent-tied local surfaces

package/assets/thrum_allowlist.json

@@ -1,16 +1,6 @@
 {
   "version": 1,
   "_supersedes": "the earlier watcher-settings allowlist spec (single-watcher restart-flow scope)",
-  "_comment": [
-    "This is the canonical, code-consumed source for the Thrum ordinary-operation allowlist (allowlist).",
-    "TWO-CAVEAT SPLIT (owner ruling) — read both before editing this file:",
-    "  1. SUPERSEDED: the original spec's 'scoped to one watcher's restart flow, not a general starting point' framing is superseded. This IS the general, code-consumed source every runtime generator draws from.",
-    "  2. STILL BINDING, NOT SUPERSEDED — BUT THE MODEL CHANGED (owner ruling via the fleet coordinator, allowlist consolidated round): command_patterns is no longer an enumerated per-subcommand list. The owner ruled ALL thrum commands are globally allowlisted — 'thrum' itself is the ONE entry, representing the whole command FAMILY (any subcommand). This is still bounded, never a blanket Bash(*): the ONLY thing that admits a candidate is an exact executable-token match (bare 'thrum', or the Part-C canonical-install-path forms) at an executable boundary, and the fail-closed metachar/alt-exec guard (containsForbiddenFragment + the alt-exec check in matchesCommandPattern) is now the PRIMARY scoping boundary, not a secondary one — it alone is what stops sh -c/bash -c, command substitution ($(...)/backticks), compound commands (&&, ;, |, ||), and alternate executable paths (./thrum, /tmp/thrum, arbitrary absolute paths, suffix/prefix lookalikes like thrum-evil). Every generator consuming this file must render the FAMILY grant in its native syntax (Claude/OpenCode: any-subcommand pattern, no shell composition; Codex: native profile only, §5.1, no invented Bash allowlist — command_patterns is not a Codex concept) and prove the negative controls above still hold — see each generator's test file.",
-    "READ-PATH INVARIANT: read_paths below (including the recursive '.thrum/**'-shaped grant every generator renders from '.thrum') MUST NEVER be allowed to carry secrets. .thrum is granted broad READ access across every supported runtime by this file — if any future change adds credentials, tokens, or private keys under .thrum, this allowlist makes them world-readable to every runtime this file feeds. Keep secrets out of .thrum, not out of this file.",
-    "GLOBAL READ PATHS (allowlist round-4, owner P0): global_read_paths grants ABSOLUTE, home-relative directories outside the project root — distinct from read_paths above, which are project-relative. Per-runtime because the underlying installed-plugin-cache layout differs by runtime (no shared portable form exists): claude = ~/.claude/plugins/cache/thrum (the thrum marketplace/plugin's OWN cache subtree, version-hash-stripped — NEVER pin a specific installed <version> segment, and never grant the broader ~/.claude/plugins/cache root, which also holds OTHER installed marketplaces' plugin payload); codex = ~/.codex/skills (Codex's flattened global skill install dir — granted in full because Codex's permission syntax has no glob/prefix-match primitive to scope it to thrum-named skills only; it also exposes non-thrum skill dirs as an accepted, documented trade-off) + ~/.codex/plugins/cache/thrum-marketplace/thrum (the versioned plugin-cache mirror, same version-hash-stripping rule as Claude's). OpenCode needs NO entry here — its own installer (opencode-plugin/src/installer.ts, opencodeGlobalReadPaths) already derives its global skill/command paths dynamically from its own resolved configDir at generation time, so a static path here would be redundant and could drift from the real value.",
-    "OWNER-AUTHORIZED EXCEPTION — /private/tmp (owner ruling, watcher-recovery P0; scope CONFIRMED all-runtimes by the fleet coordinator the same day — owner's wording was 'global configs for all agents', the operational-artifact class is runtime-independent): owner_authorized_exceptions grants EVERY supported runtime broad READ access to /private/tmp/* DESPITE it being a world-writable directory — explicitly ruled acceptable by the owner for coordinator/watcher operational artifacts. This is a DELIBERATE exception, not a template for widening elsewhere: it grants READ/ACCESS ONLY — never execute, never shell-interpolation, never a sibling root like /private or /private/tmpfoo, never write/delete. Codex renders this via its NATIVE filesystem-read profile mechanism, never as an invented Bash-pattern entry (still-binding caveat above). Every generator consuming this list must prove those boundaries by negative-control test AND by-effect (a real read actually succeeds; a real write/exec attempt actually fails), not merely by the shape of the grant string.",
-    "~/.local/bin OWNER CORRECTION (owner ruling, consolidated round): global_read_paths.<runtime> gains '~/.local/bin' for ALL THREE runtimes — the install location of the thrum binary itself, so PATH-resolved 'thrum' can actually execute under each runtime's sandbox. Granted in full (not scoped to just the thrum binary file) for the same reason as Codex's flattened ~/.codex/skills grant above: none of the three permission syntaxes has a single-file-only primitive that stays portable, so the directory is the smallest expressible unit. This is a FILESYSTEM READ/ACCESS/EXEC grant on the install directory — it is a SEPARATE axis from command_patterns matching, and does NOT loosen the alt-exec guard in approved.go beyond the tight, explicitly-scoped canonical-install-path carve-out documented in that file (canonicalInstallPathPrefixes) — a lookalike executable in the same directory (~/.local/bin/thrum-evil) is still rejected by that carve-out's own boundary check even though the DIRECTORY grant here would let a runtime read/access it."
-  ],
   "command_patterns": [
     "thrum"
   ],
@@ -22,13 +12,28 @@
     ".thrum"
   ],
   "global_read_paths": {
-    "claude": ["~/.claude/plugins/cache/thrum", "~/.local/bin"],
-    "codex": ["~/.codex/skills", "~/.codex/plugins/cache/thrum-marketplace/thrum", "~/.local/bin"],
-    "opencode": ["~/.local/bin"]
+    "claude": [
+      "~/.claude/plugins/cache/thrum",
+      "~/.local/bin"
+    ],
+    "codex": [
+      "~/.codex/skills",
+      "~/.codex/plugins/cache/thrum-marketplace/thrum",
+      "~/.local/bin"
+    ],
+    "opencode": [
+      "~/.local/bin"
+    ]
   },
   "owner_authorized_exceptions": {
-    "claude": ["/private/tmp"],
-    "codex": ["/private/tmp"],
-    "opencode": ["/private/tmp"]
+    "claude": [
+      "/private/tmp"
+    ],
+    "codex": [
+      "/private/tmp"
+    ],
+    "opencode": [
+      "/private/tmp"
+    ]
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-thrum-pro",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "description": "Thrum multi-agent coordination plugin for Open Code",
   "type": "module",
   "main": "./dist/index.js",