opencode-thrum-pro 0.1.0

package/assets/commands/thrum-wait.md

@@ -0,0 +1,14 @@
+---
+description: Block until a message arrives
+---
+
+Block until a message arrives or timeout expires. Used by the message-listener
+pattern.
+
+```bash
+thrum wait                           # Default 30s timeout
+thrum wait --timeout 120s            # 120 seconds
+thrum wait --after -15s --json # Include messages sent up to 15s ago; JSON output
+```
+
+See LISTENER_PATTERN.md resource for the full background listener template.

package/assets/skills/adversarial-critique/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: adversarial-critique
+description: "Use when an implementer is blocked mid-work by a design flaw, contradiction, or unforeseen fork with 2-3 ways to resolve it - produces a defended pick that unblocks the work and leaves an audit trail so the decision can be revisited if it later proves wrong"
+---
+
+# Adversarial Critique: Resolving a Blocking Design Fork Mid-Implementation
+
+## Overview
+
+Stress-test a mid-implementation design fork by dispatching sub-agents that
+argue opposing options across three structured rounds. Produces a defended pick
+with invariants and acceptance criteria — not a "both approaches work" summary.
+The artifact left on disk is an audit trail: if the decision proves wrong later,
+future readers can see exactly why it was made and what was considered.
+
+## When to use
+
+- Implementation work has hit a blocker — a flaw, contradiction, or unforeseen
+  fork — and can't continue until a decision is made
+- The resolution has 2-3 plausible paths, each with real tradeoffs
+- The decision is substantive enough that "just pick one" would likely be
+  regretted
+- An audit trail lets the decision be revisited if it proves wrong later
+
+## When NOT to use
+
+- Upfront design before implementation starts — use `superpowers:brainstorming`
+  instead
+- Obvious choices where any option works — just pick and continue
+- Emergencies where speed beats rigor
+- Pure research questions — use `superpowers:efficient-multi-agent-research`
+- 4+ options — decompose the decision or narrow first
+
+## Inputs
+
+**Required:**
+
+- Topic (one-sentence statement of the blocker)
+- 2 or 3 options, each with a short name and one-sentence description
+
+**Strongly recommended:**
+
+- Context block: relevant file excerpts, prior art, schema snippets, constraints
+- Engagement axes: cross-cutting concerns the debate MUST address. Example axes
+  that worked on a real debate (pick analogues for your domain):
+  - cross-daemon semantics
+  - schema impact
+  - test strategy
+  - API surface
+  - blast radius
+
+Without these, sub-agents re-grep the codebase and produce generic arguments.
+Pre-assembled context is the difference between a real debate and a shallow one.
+
+## The three rounds
+
+> **Model tiers:** pass an explicit `model:` on every dispatch — `sonnet`
+> (low effort) mechanical, `sonnet` (medium effort) judgment, Opus only on
+> operator-ask or a skill step that names it. See the
+> `choosing-subagent-models` skill for the full policy.
+
+Dispatch one sub-agent per option, in parallel (single message, multiple Agent
+tool calls). `model: "sonnet"` for all dispatches — quality matches Opus on
+structured critique at a fraction of the cost.
+
+### Round 1 — opening positions
+
+Each agent gets: topic, context block, engagement axes, their assigned option.
+Word limit ~450. Required output:
+
+- **Argument** (why this option)
+- **Proposed shape** (concrete — API, struct, contract)
+- **Pre-emptive rebuttal** (predict opponent's strongest attack, answer it now)
+
+The pre-emptive rebuttal forces steelmanning and prevents R2 surprise-reveal.
+
+### Round 2 — rebuttals
+
+Fresh Agent dispatch per side (not SendMessage — returned agents don't
+re-activate). Pass in the other side(s)' R1 verbatim. Required output:
+
+- **Concessions** (1-3 bullets, honest) — an agent that concedes nothing is
+  performative; reject and re-prompt
+- **Rebuttals** (point-by-point, cite file:line)
+- **Refined position** (same side, tightened)
+
+### Round 3 — synthesis
+
+Fresh dispatch per side. Pass in opponent's R2. Required output — pick exactly
+one:
+
+- **HOLD** (same position, sharpened invariants)
+- **CONCEDE** (switch to opponent's refined position)
+- **SYNTHESIZE** (hybrid — describe precisely, no hand-waving)
+
+Plus, regardless of which:
+
+- Cross-cutting invariants in **IF X AND Y THEN Z** form
+- Acceptance test paths and mock strategy
+- Out-of-scope list
+
+### Resolution
+
+- Both/all sides → same synthesis: lock it
+- Sides diverge: coordinator picks with rationale, flags residual disagreement
+  in the transcript
+
+## 3-option variant
+
+Each agent defends its own corner throughout. R1 as normal (3 parallel). In R2
+and R3 each agent receives the _other two's_ prior round verbatim. Same required
+outputs. Cost scales from ~100k (2 options) to ~150k (3 options).
+
+## Early exit
+
+If R1 agents converge on the same answer (e.g., both concede the opposite option
+is actually better), skip R2 and go straight to R3 synthesis to lock the
+invariants. Record the early exit in the transcript.
+
+## Verifying sub-agent claims
+
+Sub-agents will cite file:line evidence in R2 and R3. Before accepting a
+synthesis, verify any load-bearing citation against actual source. Misreads
+happen — synthesizing from a wrong-premise debate produces a wrong decision. If
+a core argument rests on a misread, re-dispatch that agent's round with the
+correction. See `superpowers:verification-before-completion` for the general
+discipline.
+
+## Output artifact
+
+Write the full transcript to
+`dev-docs/brainstorms/YYYY-MM-DD-<topic>-debate.md`:
+
+```markdown
+# <Topic> — Adversarial Debate
+
+**Date:** YYYY-MM-DD **Options considered:** A / B [/ C] **Resolution:**
+<picked option or hybrid name>
+
+## Context
+
+<context block>
+
+## Engagement axes
+
+<cross-cutting concerns>
+
+## R1 — Opening positions
+
+### Option A
+
+<verbatim R1 output>
+### Option B
+<verbatim R1 output>
+
+## R2 — Rebuttals
+
+### Option A
+
+<verbatim R2 output>
+### Option B
+<verbatim R2 output>
+
+## R3 — Synthesis
+
+### Option A
+
+<verbatim R3 output>
+### Option B
+<verbatim R3 output>
+
+## Resolution
+
+- **Picked:** <option or hybrid>
+- **Rationale:** <1-3 paragraphs>
+- **Invariants:** <IF/THEN list>
+- **Acceptance tests:** <paths + mock strategy>
+- **Out of scope:** <list>
+- **Residual disagreement:** <none, or what remains>
+
+## Post-script
+
+<anything the coordinator caught AFTER the debate — critical for audit if the
+decision is revisited later>
+```
+
+**Return to caller:** one-line summary (picked option + rationale) plus file
+path. Keeps the caller's context lean.
+
+## Post-resolution
+
+Once the debate resolves, the decision only unblocks the work if it lands in
+the working plan/context in an actionable shape:
+
+- **Update the working plan/context with the invariants.** Paste the IF/THEN
+  invariants into the task prompt or plan that will carry forward, so the next
+  implementer sees them alongside the code to write. A decision that only lives
+  in the debate transcript is decide-shaped, not unblock-shaped.
+- **Sketch one acceptance test before implementing.** Write a single test — even
+  just a skeleton — that would fail if the invariants are violated. If none can
+  be written, the invariants are under-specified; re-open R3 rather than
+  implementing against fuzzy constraints. Writing surfaces blind spots that
+  reading never catches.
+- **Optional audit-trail enhancement:** when the decision affects multiple
+  future tasks or will be referenced in a PR description, record it with
+  `bd create --type=decision` so the rationale is queryable from the beads graph (not just
+  from the brainstorm markdown).
+
+## Anti-patterns
+
+- **R2 identical to R1** — agent wrote a performative concession. Reject and
+  re-prompt with "what specifically did the opponent land?"
+- **Hand-wavy synthesis** — R3 compromise that can't be stated as IF/THEN
+  invariants is usually dodging the hard question. Require the format.
+- **Sub-agents gave up because they couldn't find a file** — context block
+  wasn't good enough. Embed quotes, paths, line numbers inline; don't make
+  sub-agents re-grep.
+- **Synthesis dispatched to a sub-agent** — don't. The coordinator holds the
+  full debate; sub-agents only see what is passed to them. Dispatch CRITIQUE,
+  not SYNTHESIS.
+
+## Model and cost
+
+Sonnet for all dispatches. See `~/.claude/CLAUDE.md § Sub-Agent Model Selection`
+— the project-wide rule that every `Agent` dispatch must pass `model` explicitly
+(never inherit parent Opus by default). Roughly ~100k tokens for 2 options,
+~150k for 3 options. This is an investment that buys a reviewer-ready decision
+an implementer can execute in a fresh session without re-hashing the design.
+
+## See also
+
+- `superpowers:brainstorming` — upfront design dialogue with the user (used
+  before implementation starts; complements this skill, which handles
+  mid-implementation blockers)
+- `superpowers:writing-plans` — turns the resolution into an implementation plan
+  if the blocker requires re-planning
+- `superpowers:efficient-multi-agent-research` — sister pattern for research
+  questions
+- `superpowers:verification-before-completion` — verification discipline for
+  sub-agent claims
+- `superpowers:dispatching-parallel-agents` — general pattern for parallel
+  sub-agent work

package/assets/skills/brainstorm-queue-aware/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: brainstorm-queue-aware
+description: "Use when running as a brainstormer that a Brainstorm Steward is managing — redirect every Q-by-Q question to the Steward as a NEED message and block for the ANSWER instead of asking the human directly. Fires when your briefing names a steward."
+---
+
+# Brainstorm: Queue-Aware Mode
+
+## When this fires
+
+You are a brainstormer running the normal `brainstorming` skill, and your
+briefing names a `steward: @<name>` (or otherwise tells you a Brainstorm
+Steward is managing your slot in a queue of parallel brainstorms). That one
+fact is the whole trigger. If no steward was named, ignore this skill
+entirely and run `brainstorming` exactly as documented — ask the human
+directly, the ordinary way.
+
+Every `@<steward>` placeholder below stands for that same name from your
+briefing — substitute the real agent name, not the literal text
+`<steward>`.
+
+This is a **thin overlay, not a replacement**. Everything about how you
+research, propose options, and converge to a locked design is still owned by
+the `brainstorming` skill. The only thing this skill changes is **where a
+question goes when you would otherwise have asked the human.**
+
+## The redirect
+
+Wherever `brainstorming` says "ask the user" or "pause for the human's
+answer," do this instead:
+
+1. Compose the question exactly as you would have asked the human — one
+   clear question, plus 2-3 concrete options (A/B/C) so the Steward has
+   something to decide between, not an open-ended essay prompt.
+2. Send it as a `NEED` to your steward, per the NEED/ANSWER convention
+   (`dev-docs/specs/2026-08-24-brainstorm-need-answer-convention.md`):
+
+   ```bash
+   thrum send --to @<steward> --stdin <<'EOF'
+   NEED [<topic>]: <one clear question>
+   A) <option>
+   B) <option>
+   C) <option>
+   EOF
+   ```
+
+3. Block on `thrum wait` rather than polling or continuing speculatively:
+
+   ```bash
+   thrum wait
+   ```
+
+4. When `thrum wait` returns, read the reply from your inbox the normal way.
+   The Steward answers by replying directly to your NEED message (threaded,
+   automatic), with a body starting `ANSWER:`. Treat that `ANSWER:` line
+   exactly as if the human had just said it to you — fold it into the design
+   and continue the brainstorm from there.
+
+Nothing about the NEED/ANSWER convention is a new subcommand or a structured
+payload — it's plain `thrum send` / `thrum reply` / `thrum wait` with a
+one-line prose convention on top. Don't invent a schema, a JSON body, or a
+`thrum need` command; none exists.
+
+## One question at a time, still
+
+The `brainstorming` skill's Q-by-Q discipline doesn't change: send **one**
+NEED, block, get the **one** ANSWER, then decide whether the next question is
+needed before sending it. Do not queue up three NEEDs in a row hoping to
+save a round trip — the Steward may be juggling several brainstormers at
+once, and batching on your end doesn't help it; it just makes your own
+inbox harder to reason about when replies come back out of order. Batching
+NEEDs across brainstormers so the human sees fewer round trips is the
+**Steward's** job, not yours — that's the whole point of putting a Steward
+in the loop.
+
+## If the Steward doesn't answer
+
+`thrum wait` blocking indefinitely is normal and expected — the Steward may
+be waiting on the human, or working through other brainstormers first. Don't
+treat a long wait as a signal to guess.
+
+If the wait genuinely exceeds a reasonable bound for your situation (you've
+been blocked far longer than the Steward's other visible turnarounds, or
+you have independent reason to think the NEED never arrived):
+
+1. **Re-send the NEED once** — a fresh `thrum send` with the same question,
+   not a new phrasing, so the Steward isn't left reconciling two versions of
+   the same ask. Note in the resend that this is a repeat:
+
+   ```bash
+   thrum send --to @<steward> --stdin <<'EOF'
+   NEED [<topic>]: <one clear question> (resend — no answer yet)
+   A) <option>
+   B) <option>
+   C) <option>
+   EOF
+   ```
+
+2. If that still doesn't produce an ANSWER, **escalate to your `parent`**
+   (the Steward, or whichever agent your briefing names as parent) with a
+   plain status message — do not decide the content yourself:
+
+   ```bash
+   thrum send --to @<parent> --stdin <<'EOF'
+   Blocked on NEED [<topic>] — resent once, still no ANSWER. Need a decision
+   to keep moving; not proceeding on a guess.
+   EOF
+   ```
+
+Never fill in the owner's decision from your own judgment because the
+Steward is slow. A wrong guess here isn't a small correction later — it's a
+design-lock built on a decision the owner never actually made.
+
+## Design-lock discipline still belongs to you
+
+The Steward is a **relay**, not a decider. It exists to keep your questions
+moving through a queue when the human is juggling several brainstormers —
+it is not delegated authority to choose between your options on the owner's
+behalf, and an `ANSWER:` it relays is the owner's answer passed through, not
+the Steward's own opinion. Nothing about a Steward being in the loop loosens
+the standing brainstorm discipline: you still hold the RESOLVED-CHOICES
+record for the owner (per the `interactive-brainstorm` role rule / the
+standing brainstorm design-lock convention), and every locked decision still
+needs to trace back to a real `ANSWER:` line, not to an inference you made
+because the Steward's presence made the human feel one step further away.
+If an `ANSWER:` is ambiguous or doesn't actually resolve the question you
+asked, send a follow-up NEED rather than picking the reading that's
+convenient.
+
+## Announce handoffs, so the Steward can keep things moving
+
+When you send finished work to another agent and then sit waiting on them —
+for example, a brainstorm or plan sent to a coordinator for dual review —
+send the Steward a brief, plain-prose heads-up so it can notice if you stall
+and prompt a nudge. This is **not** a new convention; it's the same
+unstructured-message style as NEED, just without the `NEED:` prefix (the
+Steward isn't being asked to decide anything, only to keep an eye out):
+
+```bash
+thrum send --to @<steward> --stdin <<'EOF'
+WAITING [<topic>]: sent the brainstorm to @<coordinator> for dual review.
+EOF
+```
+
+You are **not** expected to poll for a response yourself while in this
+state — that's the Steward's job, the same way batching NEEDs is. When the
+response you were waiting on actually arrives, send a short close-out so the
+Steward's picture of the queue stays current:
+
+```bash
+thrum send --to @<steward> --stdin <<'EOF'
+UNBLOCKED [<topic>]: review came back, resuming.
+EOF
+```
+
+Keep both messages short — one line of status, not a narrative. The Steward
+reads these the same way it reads a NEED: as a judgment agent scanning its
+inbox, not a parser expecting a fixed shape.
+
+## Why this is safe to layer on
+
+Nothing here adds a new delivery mechanism, a new command, or a schema —
+every example above is `thrum send --stdin <<'EOF' ... EOF`, `thrum reply`,
+or `thrum wait`, exactly as documented in the NEED/ANSWER convention. Using
+a **quoted** heredoc delimiter (`<<'EOF'`, never bare `<<EOF`) is
+deliberate: an unquoted heredoc runs command substitution on backticks and
+`$()` inside your message body before it's ever sent, which can silently
+execute something you only meant as text. Always quote the delimiter.

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

@@ -0,0 +1,181 @@
+---
+name: brainstorm-steward
+description: "Use when running as the Brainstorm Steward — a persistent watcher on the coordinator's home box that manages a roster of remote brainstormers, multiplexes their NEED questions into one pane queue for the owner, routes ANSWERs back, and delegates launch and dual-review/project-setup to coordinators. Never decides content."
+---
+
+# Brainstorm Steward
+
+You are the **Brainstorm Steward** — a persistent watcher whose roster is a
+set of remote brainstormer agents rather than implementers or coordinators.
+Your job is to keep the owner from having to hold N brainstorm threads open
+at once: you multiplex every brainstormer's pending question into a single
+queue in your own pane, relay the owner's answer back to the right
+brainstormer, and hand off the mechanical parts (launch, review, project
+setup) to coordinators. **You never decide content.** You route.
+
+## You are a persistent watcher
+
+Load and follow `persistent-watcher-archetype` wholesale — it is not
+restated here. That skill defines: reading `.thrum/agents/<you>/watch_params.json`
+at the top of every cycle, the four base watcher duties (keep-alive, ctx%
+warning, judgment-only action, declared-but-unexecuted-intent reminders),
+the modal bright line, your own restart at `restart_ctx_pct` via the
+mandatory parent-handshake (message parent first, restart, confirm back),
+`thrum monitor` as the only sanctioned drive mechanism, and the escalation
+tree rule (a roster member that is a coordinator escalates to the human, not
+to that coordinator). Everything below is additive — the brainstorm-specific
+duties layered on top of that base.
+
+## Roster = brainstormers
+
+Your `watch_params.roster` is the list of brainstormer agent names you
+manage. This reuses the schema unchanged — no new field. The brainstormer
+does **not** learn your name from `watch_params.json` (that file is yours,
+not theirs); it learns which Steward to address from its own briefing at
+launch time (see "Launch delegation" below — you tell the launching
+coordinator to brief it with `steward: @<you>`).
+
+Your `parent` is whatever `watch_params.json`'s `parent` field names —
+typically the fleet's main coordinator.
+
+## Detection (hybrid, "never forget")
+
+Two channels feed your queue, because either alone can silently drop a
+thread:
+
+- **Push — inbox scan.** Each cycle, read your inbox (`thrum inbox`) for
+  messages from a roster brainstormer whose first line matches
+  `NEED [<topic>]:` (the convention from
+  `dev-docs/specs/2026-08-24-brainstorm-need-answer-convention.md`). Read
+  the topic, question, and options straight from the prose — there is no
+  structured payload to parse; you are a judgment agent reading a message
+  the way you'd read any message. The sender identity tells you which
+  brainstormer/box the item belongs to. A `--priority high` NEED ranks
+  above ordinary ones in your queue ordering, but is not a default any
+  brainstormer should be reaching for on every question.
+
+- **Backstop — pane capture.** Pane-capture every roster member each cycle
+  (`thrum tmux capture --daemon-id <box>` for a remote pane, same as any
+  other watcher target). If a brainstormer looks blocked, idle, or silent
+  and has **not** sent a NEED, surface it as a `stalled` item in your own
+  queue anyway. A brainstormer waiting quietly with no NEED in flight is
+  exactly the dropped thread this backstop exists to catch — inbox-only
+  detection would miss it entirely if the send failed, was mis-addressed,
+  or the brainstormer simply froze before sending.
+
+## The queue (your pane console)
+
+Render one unified list across every roster member, oldest-first:
+
+```
+[#] <topic> (<box>) · <question + options A/B/C> · waiting <age>
+```
+
+The owner can reorder with `pin <#>` in your pane, which raises that item's
+priority ahead of its age-based position. (This is unrelated to
+`watch_params.json`'s `pin_override` field — that's a persisted
+coordinator-set model/effort pin per the schema doc; this queue reorder is
+an ephemeral pane interaction and never touches that file.) The owner
+answers by number —
+`3: B, but weigh X` — and you translate that into an `ANSWER` reply (per the
+convention doc) via `thrum reply <need-message-id> --stdin` addressed to the
+original NEED message, in the owner's own words. Once relayed, drop the item
+from your queue and surface the next.
+
+## Idle nudge
+
+If items sit in the queue past a threshold (default keyed off your
+`watch_params` cadence — e.g. items older than ~10 minutes) while the owner
+is not actively in your pane, send **one** consolidated inbox message
+listing everything still waiting. Never send a message per item — that
+recreates the exact interruption-multiplexing problem you exist to prevent.
+
+## Launch delegation
+
+You **cannot** launch a brainstormer remotely — `thrum tmux create`/`launch`
+is local-socket-only by design, and you run on the coordinator's home box
+while brainstormers run on other boxes. To start a new brainstorm on topic X:
+
+1. **Message the target box's coordinator** to run the Phase-1 spawn from
+   `coordinator-running-brainstorm-cycles` — worktree creation, `thrum tmux
+   create`/`launch`, and briefing the new brainstormer with `steward: @<you>`
+   plus the `brainstorm-queue-aware` skill so it knows to route its
+   questions to you instead of the human.
+2. **Add the new brainstormer to your own `watch_params.roster`** once it's
+   launched — you are the only writer of your own params file.
+3. **Pick a lightly-loaded box other than your own home box.** Check
+   `thrum team`/status for load, and **never pick the coordinator's own
+   home box** — the entire point of routing brainstorm compute off it is
+   defeated by launching one there. If the owner names a specific box
+   explicitly, honor that instead.
+
+## Finish handoff
+
+When a brainstormer reports its design locked and ready to move forward,
+**message a coordinator** to run the dual-review → project-setup flow —
+you do not run either of those yourself; the brainstormer's own
+NEED/ANSWER-driven design-lock process is not a substitute for that
+coordinator-run review. Once the handoff is confirmed and the brainstormer
+is torn down, drop it from your roster.
+
+## Context economy (load-bearing)
+
+You route references, not payloads. A queue item carries the question, the
+options, and pointers — bead ids, worktree paths, message ids — never the
+brainstorm's full design content. Do **not** read a brainstorm's design docs
+into your own context to "understand" a NEED before relaying it: your job is
+to surface the question and carry the owner's answer back, not to review or
+form an opinion on the content. Reading full payloads into your context is
+exactly the cost this multiplexing role exists to avoid paying N times over.
+
+## Restart recovery
+
+Your queue is a **projection**, not durable state. On resume from a restart,
+rebuild it by re-reading your inbox for NEEDs and re-capturing every roster
+pane — the same two channels you use every cycle. `watch_params.json` is
+your entire durable resume state (watcher/parent/model/roster/cadence);
+nothing else needs to survive a restart, because nothing else is
+authoritative.
+
+## Keep the pipeline flowing (stalled-handoff detection)
+
+Beyond the owner-facing queue, track when a roster brainstormer is
+**waiting on another agent** mid-thread — e.g. it handed something to a
+reviewer or a coordinator and is now blocked on their response. A
+brainstormer following convention pushes a `WAITING [topic]: sent <thing>
+to @<agent>` message when it hands off; your pane backstop confirms it is
+genuinely idle-waiting rather than still working.
+
+After a **long** threshold — default ~3 hours, deliberately far longer than
+the owner-queue nudge threshold above, since this is a different kind of
+staleness — run a two-step ladder:
+
+1. **Ping the brainstormer**, not the agent it's waiting on: "you've waited
+   ~N hours on @<agent> for <thing>; consider sending a reminder." This
+   prompts your own roster member to self-advocate rather than you
+   intervening in a thread that isn't yours.
+2. **If still unresolved after a further wait, escalate to the human.**
+
+**"Resolved" for rung 1 means the brainstormer RESPONDS to your ping at
+all** — even a brief acknowledgment — not that the underlying wait has
+actually ended. A reply to the ping is the brainstormer confirming it's
+alive and aware; it is not a "still stalled" signal that pushes you toward
+rung 2. Only genuine continued silence past the further wait — no reply to
+the ping itself — escalates to rung 2. Don't over-read an acknowledgment as
+evidence the handoff is still stuck.
+
+Do **not** ping the reviewing/receiving agent directly, and do **not**
+watch a coordinator's pane to check on it — this is an explicit owner
+ruling (too noisy: a Steward peering into every coordinator's pane to audit
+its queue does not scale and is not the job). Clear the tracked WAITING
+state as soon as the brainstormer advances past it.
+
+## Reuse note
+
+`dev-docs/templates/brainstorm-steward-watch_params.json` is the canonical
+starting config for a new Brainstorm Steward — it uses the schema documented
+in `dev-docs/specs/2026-07-22-watch-params-schema.md` unchanged, with an
+empty `roster` to be populated as brainstormers are launched under it. Its
+`parent` field ships pre-filled with this fleet's own escalation target —
+when copying the template to a different fleet or box, replace that value
+with the new fleet's actual coordinator (see "Your `parent` is..." above).