opencode-thrum-pro 0.1.3 → 0.1.5

package/assets/skills/agent-messaging-protocol/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: agent-messaging-protocol
+description: "Use when forwarding or relaying information between parties, routing an owner answer, carrying a decision or request through an intermediary, summarizing another author's message, or adding interpretation to someone else's words."
+---
+
+# Agent Messaging Protocol for Forwarding and Relaying
+
+- Communicate directly with the intended party whenever possible.
+- Treat the original message as the authoritative source.
+- Forward a pointer to the original message instead of retyping or paraphrasing its body.
+- Include the original author, original message ID, intended recipient, and requested action.
+- Attach `message:<original-message-id>` as a message reference when supported.
+- Read the original message before acting: `thrum message get <message-id> --json`.
+- Reply against the original message: `thrum reply <message-id> ...`.
+- Do not route the response back through the intermediary.
+- Add commentary or interpretation only when requested or necessary.
+- Label added reasoning as `INTERPRETATION - @agent`.
+- Never present an interpretation, summary, or recommendation as words or authority from the original author.
+- Label a requested summary as `SUMMARY - @agent` and retain the original message ID.
+- Preserve the original scope, urgency, constraints, and requested action.
+- Do not introduce new requirements, decisions, risks, or authorization while routing.
+- Ask the original author directly when clarification is required.
+- Continue referencing the original message rather than an intermediary's summary.
+- Identify corrections by the exact message they supersede.
+- Distinguish delivery, acknowledgement, execution, and verification.
+- Preserve the original thread audience when replying unless a deliberately narrower audience is required.
+
+## Routing Envelope
+
+```text
+ROUTE POINTER
+From: @original-author
+Message: msg_...
+Action: Read and reply to the original message.
+```

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/brainstormer-staying-current/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: brainstormer-staying-current
+description: "Use when a long-lived brainstormer worktree may be behind its configured merge target, before review or handoff, or when asked to merge-forward and leave the worktree clean. Resolves the target and merge owner from Thrum config, preserves local work, and verifies freshness after the merge."
+---
+
+# Brainstormer: Stay Current with the Merge Target
+
+Keep a long-lived brainstorm branch current without landing it into the merge
+target. Every git write in this skill (commit, merge, revert, push) stays with
+you — never delegate a git write to a subagent. Every `fetch` also stays with
+you, the acting agent, per Preserve and Bind freshness below. If you delegate
+the read-only merge-base/status analysis, load `choosing-subagent-models`
+first and fence the subagent to `show`, `log`, `diff`, `grep`, `rev-parse`,
+`merge-base`, `status` — the same read-only git surface CLAUDE.md requires for
+every sub-agent — never `stash`, `reset`, `rebase`, `restore`, `clean`,
+`commit`, `push`, or `checkout`.
+
+## Resolve authority from config
+
+Locate the canonical config from the current worktree:
+
+```bash
+CONFIG=.thrum/config.json
+if [ ! -f "$CONFIG" ]; then
+  COMMON_DIR=$(git rev-parse --path-format=absolute --git-common-dir)
+  CONFIG="${COMMON_DIR%/.git}/.thrum/config.json"
+fi
+test -f "$CONFIG"
+TARGET=$(jq -er '.orchestration.merge_target | select(type == "string" and length > 0)' "$CONFIG")
+MERGE_KING=$(jq -r --arg target "$TARGET" '.orchestration.merge_kings[$target] // "unset"' "$CONFIG")
+```
+
+Treat an absent config or target as a blocker — merge-forward has nowhere to
+target without them. A merge-forward only brings `origin/$TARGET` into the
+brainstorm branch; it never grants permission to merge the brainstorm branch
+into `$TARGET`, so it needs no landing authority to run and an `unset`
+`MERGE_KING` never blocks it.
+
+`orchestration.merge_kings` may not be populated for every target yet: `unset`
+does NOT mean "nobody owns landing, proceed however" — it means the map
+hasn't caught up (same gap `coordinator-merging-code/SKILL.md` documents for
+branch-keyed lookups). `MERGE_KING` matters only when a conflict needs routing
+or at final report. With it `unset` at either point, fall back to whichever
+coordinator has actually been the merge authority for `$TARGET` in practice
+(check with your team, or the project's operational convention) and
+route/report to them the same as if the map had named them explicitly.
+
+## Preserve before merging
+
+Record the current branch, HEAD, status, and ahead/behind counts. Require an
+attached non-target feature branch. Fetch the target branch explicitly:
+
+```bash
+git fetch origin "refs/heads/$TARGET:refs/remotes/origin/$TARGET"
+git rev-list --left-right --count HEAD..."origin/$TARGET"
+```
+
+If the worktree is dirty, preserve tracked and untracked changes as a WIP
+commit and record its SHA — never `git stash`. `stash` is a single shared
+stack across every worktree on this box, not scoped to this worktree or to
+you; a stash push or pop here can silently destroy or restore another agent's
+uncommitted work, with no reflog entry and no recoverable blob for unstaged
+content. A commit is yours alone and fully recoverable.
+
+```bash
+git add -A
+git commit -m "wip: preserve <branch> before merge-forward <timestamp>"
+git rev-parse HEAD
+git status --short
+```
+
+Do not squash, drop, or revert the WIP commit when the requested outcome is a
+clean worktree — it is real history now, not something to discard.
+
+Stop if the worktree is still dirty after the WIP commit. Never use `stash`,
+reset, rebase, force checkout, clean, or force push to obtain a clean state —
+`stash` is banned here exactly like the others, with no worktree-scoped
+exception.
+
+## Merge-forward
+
+Merge the remote-tracking target into the brainstorm branch:
+
+```bash
+git merge --no-edit "origin/$TARGET"
+```
+
+Resolve a conflict only when the correct result is supported by current source
+and the branch's intended work. Otherwise stop with the conflict intact and
+send the branch, worktree, target, and conflicted paths to the user or
+`$MERGE_KING` for direction — falling back to the operational-convention
+authority per above if `$MERGE_KING` is `unset`.
+
+After a successful merge, run validation relevant to every resolved file and
+always run `git diff --check origin/$TARGET..HEAD`.
+
+## Bind freshness to handoff
+
+Immediately before reporting success, fetch the target branch explicitly again
+and verify the fetched target is an ancestor of HEAD:
+
+```bash
+git fetch origin "refs/heads/$TARGET:refs/remotes/origin/$TARGET"
+git rev-list --left-right --count HEAD..."origin/$TARGET"
+git merge-base --is-ancestor "origin/$TARGET" HEAD
+git status --short
+```
+
+If the target advanced, repeat the merge-forward and verification, up to three
+merge cycles in one run. After three moving-target results, stop and report the
+new target SHA instead of claiming the branch is current.
+
+Report the branch and target SHAs, ahead/behind counts, `$MERGE_KING` (or the
+fallback authority if `unset`), validation, clean status, and the WIP commit
+SHA if one was made. Do not push, squash, or drop the WIP commit unless the
+user separately asks.

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