@mu-crew/mu 3.6.2 → 3.8.0

package/skills/mu/recipes/drift-audit.md

@@ -0,0 +1,72 @@
+# Drift audit
+
+Use during a long run to catch a crew drifting from what you decided:
+an instruction that never reached its worker, a batch run on stale
+inputs, work continuing on a closed task. One read-only
+[delegate call](tasks-or-calls.md#delegate-call); it edits nothing.
+
+## When
+
+- every few hours of a long run;
+- after each batch report of a chained task (sweep, campaign, soak);
+- after a context compaction or a resume;
+- before you declare a stop rule met.
+
+## Run
+
+Issue one delegate call with `record: { task: "<ws>/<umbrella>" }` and
+this brief, with `<ws>` filled in:
+
+```text
+Read-only drift audit of mu workstream <ws>. Change nothing. Sources:
+mu state -w <ws>; mu task list -w <ws> --json; mu task notes <id> -w <ws>;
+mu sql (ops, tasks, task_notes, agents); git log in the repo and in each
+owner's workspace. Never judge by a capped mu log -n window: the claim
+or close you compare against is often older than it.
+1. Unsent notes: notes on IN_PROGRESS tasks, by someone other than the
+   owner, after the owner's last task.claim or agent.send op:
+   mu sql "select t.local_id task, a.name owner, n.created_at, substr(n.content,1,80) note from tasks t join workstreams w on w.id=t.workstream_id join agents a on a.id=t.owner_id join task_notes n on n.task_id=t.id where w.name='<ws>' and t.status='IN_PROGRESS' and coalesce(n.author,'')<>a.name and n.created_at > max(coalesce((select max(o.created_at) from ops o where o.intent='task.claim' and o.key='<ws>/'||t.local_id),''), coalesce((select max(o.created_at) from ops o where o.intent='agent.send' and o.key='<ws>' and o.payload like 'agent send '||a.name||' (%'),'')) order by n.created_at"
+   Quote each task's last claim (seq, time). For each instruction it
+   lists: did the owner act on it (later commits, notes, pane)? Also read
+   mu sql "select seq, created_at, payload from ops where intent='agent.send' and key='<ws>'"
+   and flag mode=plain or mode=steer with state=busy since=<t> long
+   before the send: it queued behind a long turn and may not have landed.
+2. Stale pins: for each build/binary sha or oracle commit named in an
+   IN_PROGRESS note, and each merged fix its task's findings depend on:
+   git merge-base --is-ancestor <fix> <pinned>. Exit 1 = pin is stale.
+3. Closed-task notes: notes added after the task's last task.close op.
+   Report each of the top 5 by count as its own finding with its count,
+   even when the notes look routine. A late note that reports the
+   closed bug again usually ran on a build without the closing fix:
+   check its sha with git merge-base --is-ancestor <fix> <sha>.
+   mu sql "select t.local_id name, count(*) late from tasks t join workstreams w on w.id=t.workstream_id join task_notes n on n.task_id=t.id where w.name='<ws>' and t.status='CLOSED' and n.created_at > (select max(o.created_at) from ops o where o.intent='task.close' and o.key='<ws>/'||t.local_id) group by t.local_id order by late desc"
+4. Thin decisions: an ACCEPT/REJECTED/CLOSE/SUPERSEDED note under 40
+   chars; a refuter tally with no REFUTER or VERDICT note; a review the
+   orchestrator closed with no FILES/COMMANDS note and no commit.
+5. Silent tasks: IN_PROGRESS with no note or commit for longer than
+   the cadence its notes state (default 2h).
+6. Missing work: a task or finding a note or log line says will be
+   filed that does not exist.
+7. Unrefuted briefs: IN_PROGRESS tasks with no note line starting
+   REFUTER , VERDICT: or REFUTE-EXEMPT:.
+End with exactly this, one EVIDENCE line per finding (none when clean):
+VERDICT: <ws> DRIFT-AUDIT CLEAN | FINDINGS <n>
+EVIDENCE: FINDING <high|med|low> <file:line|task> <what> (check <1-7>)
+```
+
+`record` keeps only the VERDICT line and the `EVIDENCE:` lines after
+it, so each finding must be an `EVIDENCE: FINDING` line. The note
+lands headed `REFUTER`, which the refute nudge and decision warnings
+read as a recorded verdict; on an umbrella that is harmless.
+
+## Act
+
+Each finding becomes one of:
+
+- an `OPEN/triage` task blocking the umbrella ([findings § Record](findings.md#record));
+- a send to the worker it names, per
+  [orchestrator-loop § Sending](orchestrator-loop.md#sending)
+  (`--interrupt` when its current work is wasted, as with a stale pin).
+
+Done when the verdict is recorded on the umbrella and every finding
+is a task or a delivered send.

package/skills/mu/recipes/findings.md

@@ -69,24 +69,33 @@ across reviewers and creates one task per real problem.
    or several reviewers on one change: a `triage_<umbrella>` task, run
    by a fresh agent, so the orchestrator reads only its result.
 2. **Refute** each finding before accepting it with a
-   [delegate call](tasks-or-calls.md#delegate-call): a fresh agent tries
-   to prove it false and ends with
-   `VERDICT: <id> CONFIRMED | REFUTED | UNVERIFIED <evidence>`. Skip this
-   for low-severity style findings. High severity: three refuters,
-   accept only if at least two say CONFIRMED.
-3. **Decide** each one; the decision is the task's state:
-
-   | Decision | Command |
-   | --- | --- |
-   | real work | `mu task accept <id> --evidence '<what confirmed it>'` |
-   | false | `mu task close <id> --as rejected --why '<evidence>'` |
-   | same as another | `mu task close <id> --as duplicate --why 'same as <id>'` |
-   | valid, not worth it | `mu task close <id> --as wontfix --why '<reason>'` |
-   | could not check | stays in triage, with an `UNVERIFIED: <why>` note |
+   [delegate call](tasks-or-calls.md#delegate-call) that passes
+   `record: { task: "<ws>/<id>" }`: a fresh agent tries to prove it
+   false, and its VERDICT block lands on the finding as a
+   `REFUTER <label> (<delegate>, <elapsed>):` note (VERDICT line, 3-6
+   EVIDENCE lines), or `REFUTER <label>: no verdict (<outcome>)` when
+   it times out or dies. Without `mu_delegate`, write that note yourself
+   before deciding
+   ([tasks-or-calls § Delegate call](tasks-or-calls.md#delegate-call)).
+   Skip this for low-severity style findings. High severity: three
+   refuters, accept only if at least two say CONFIRMED.
+3. **Decide** each one; the decision is the task's state. The reason
+   names the deciding evidence, not a tally or a judgement. mu warns
+   when a reason is under 40 chars and no note holds a `VERDICT:` line
+   or `REFUTER` note. Prose reasons go through a heredoc variable
+   ([brief § Quoting](brief.md#quoting)).
+
+   | Decision | Command | Bad reason |
+   | --- | --- | --- |
+   | real work | `mu task accept <id> --evidence "2/3 CONFIRMED: refuters 1 and 3 show the checklist:3 vs :33 cycle"` | `valid`, `orchestrator: valid`, `2/3 CONFIRMED` |
+   | false | `mu task close <id> --as rejected --why "<the guard or command that disproves it>"` | `refuter REFUTED` |
+   | same as another | `mu task close <id> --as duplicate --why "same as <id>"` | |
+   | valid, not worth it | `mu task close <id> --as wontfix --why "<cost vs impact>"` | `not worth it` |
+   | could not check | stays in triage, with an `UNVERIFIED: <why>` note | |
 
 4. **Group** accepted findings that touch the same files into one fix
    task when separate workers would collide; close the grouped findings
-   `--as superseded --why 'fixed in <fix-task>'`.
+   `--as superseded --why "fixed in <fix-task>"`.
 
 Done when `mu task list --substate triage -w <ws>` lists only findings
 with an `UNVERIFIED` note, and each of those is reported to the human.

package/skills/mu/recipes/hypothesis-panel.md

@@ -23,9 +23,11 @@ form independent theories; separate agents then try to kill them.
 3. **Test each hypothesis.** An experiment that changes code (force the
    race, revert the commit) needs a workspace: `mu task accept` the
    hypothesis and dispatch it as a task. One that only reads (feed the
-   data, grep the logs) is a delegate call. A killed hypothesis closes
-   `--as rejected --why '<evidence>'`; a survivor gets a
-   `SURVIVED: <evidence>` note.
+   data, grep the logs) is a delegate call with `record` on the
+   hypothesis ([tasks-or-calls § Delegate call](tasks-or-calls.md#delegate-call)).
+   A killed hypothesis closes `--as rejected --why "<the observation
+   that contradicts PREDICTS>"`; a survivor gets a `SURVIVED: <evidence>`
+   note. Prose reasons: [brief § Quoting](brief.md#quoting).
 4. **If one survives**, add a fix task for it, then a review task
    ([adversarial-review](adversarial-review.md)). The fix is accepted
    only if the step 1 repro stops reproducing.

package/skills/mu/recipes/long-run.md

@@ -6,15 +6,25 @@ or may hit flakes.
 1. **Define done first.** Before dispatch, write the completion criterion
    into the task note: the checks, how many runs must agree, the
    allowed variance. A worker that finds the bar in the note stops at
-   the bar, not at the first green.
+   the bar, not at the first green. For chained batches (sweeps,
+   campaigns, soaks) it also names the **inputs** each batch runs on
+   (build sha, oracle commit, config) and when to refresh them
+   ("rebuild from main before each batch"); each batch report states
+   the inputs it used, and the stop rule counts only batches on
+   current inputs.
 2. **Split into independent units** ([fan-out](fan-out.md)). Shard a long proof into tasks
    that run in parallel, so one flake restarts only its unit. Each unit
    carries its own criterion.
 3. **Keep state in the DB.** Progress lives in task notes, not in the
    orchestrator's context. After a compaction, `mu state` and
    `mu task notes <id>` are the whole picture.
-4. **Accept evidence, not close notes**
-   ([orchestrator-loop § Merging](orchestrator-loop.md#merging)).
+4. **Bound each tool call** to minutes: batches of ≤10 minutes,
+   `mu task wait --timeout` re-issued, no open-ended `sleep` loops.
+   A `--steer` lands only when the running tool returns.
+5. **Accept evidence, not close notes**
+   ([orchestrator-loop § Merging](orchestrator-loop.md#merging)), and
+   run a [drift-audit](drift-audit.md) after each batch report and
+   every few hours.
 
 Done when every unit is `CLOSED/done` and the criterion from step 1
 holds on the merged tree.

package/skills/mu/recipes/loop-until-done.md

@@ -25,11 +25,12 @@ written down first does neither.
    `MEASURE: 14 errors (was 31)`, or `NEW: 0 flaky tests`.
 4. **After each round, check the rule** yourself, from the measurement
    command, not from the worker's note.
-   - Rule met: `mu task close <umbrella> --if-ready --evidence '<stop
-     command + result>'` (each round blocks the umbrella).
+   - Rule met: `mu task close <umbrella> --if-ready --evidence "<stop
+     command + result>"` (each round blocks the umbrella).
    - No progress: stop the loop and decide. Change the approach, split
      the work, or park the umbrella with
-     `mu task park <umbrella> --why '<what is stuck>'` and tell the human.
+     `mu task park <umbrella> --why "<what is stuck>"` and tell the human.
+     Prose reasons: [brief § Quoting](brief.md#quoting).
    - Otherwise: add the next round and dispatch it.
 
 Done when the stop rule holds on the merged tree, run by you.

package/skills/mu/recipes/orchestrator-loop.md

@@ -39,8 +39,8 @@ keeps it.
 - **Answers arrive when you stop**, as pi follow-up messages, never
   mid-turn. pi's `followUpMode: "all"` delivers every waiting answer in
   one turn instead of one turn each; each answer names its delegate and
-  ends with its `VERDICT: <id>` line, so a batch still maps back. Record
-  every verdict in the batch before acting on any.
+  ends with its `VERDICT: <id>` block, so a batch still maps back. Read
+  every verdict in the batch before deciding any.
 - **Workers with workspaces** build and test: about one per CPU core,
   fewer when each runs the full suite. A remote host has its own
   session cap ([remote-workers](remote-workers.md)).
@@ -54,12 +54,16 @@ keeps it.
 Use `--first --on-stall exit`: `--first` populates `.firing`, and
 `--on-stall exit` stops an unattended wait when a worker needs attention.
 Exit 6: the owner's pane died and the reaper reopened the task; exit 7:
-the owner sat in `needs_input`. Read that
-pane (`mu agent read <owner>`) and answer: the worker may be waiting on
-you.
-
-For an idle worker, read the pane, then answer, retry, or release its
-task. `MU_IDLE_THRESHOLD_MS` defaults to 5m. A remote owner: poll once
+the owner sat in `needs_input`. Run the exit's `Next:` and answer: the
+worker may be waiting on you. For a pi owner it leads with
+`mu agent wait <owner> --after-runs <runs-1> --json`, which returns the
+last answer at once. The pane read follows because dialogs and crashes
+show only in the pane.
+
+For an idle worker, read its last answer (the same `--after-runs`
+wait for pi, else the pane), then answer, retry, or release its task.
+`MU_IDLE_THRESHOLD_MS` defaults to 5m. A remote owner: for pi,
+`mu agent wait --after-runs` first, then poll once; otherwise poll once
 per turn ([remote-workers](remote-workers.md#step-5-poll-once-per-turn)).
 
 ## Merging
@@ -75,7 +79,8 @@ per turn ([remote-workers](remote-workers.md#step-5-poll-once-per-turn)).
   test once passed with zero cases.
 - **Accept evidence, not close notes.** Re-run the key measurement from
   a clean checkout; close notes have claimed unpushed commits. A
-  worker's "done" counts only once the diff shows the change.
+  worker's "done" counts only once the diff shows the change. Your own
+  accept and close notes name the check run and the commit.
 - **Ask whether the check could have failed.** A gate that cannot say
   no is not evidence: a test filtered to zero cases, a script you wrote
   agreeing with itself, a fixture you tuned on. A nonzero diff is a
@@ -83,16 +88,24 @@ per turn ([remote-workers](remote-workers.md#step-5-poll-once-per-turn)).
 
 ## Sending
 
-- A plain `mu agent send` appends to prior context; use it to steer or
-  answer. Unrelated work to pi: `mu agent send worker-1 --fresh 'Claim
-  task_x...'`.
+A running worker sees what you send, never a new task note: deliver
+an instruction for it with a send (or the next `--fresh` brief), and
+keep the note as the durable copy. pi:
+
+| `mu agent send` | busy pi acts | Use for |
+| --- | --- | --- |
+| plain | after the run ends | answers, same-task additions |
+| `--steer` | after the current tool call | advice that can wait for the tool boundary |
+| `--interrupt` | now: kills the running tool | a correction that wastes the current work (stale input, wrong target, changed stop rule) |
+| `--fresh` | refused (`--force` drops the run) | unrelated work: new session + prompt |
+
 - claude-code/codex: send `/new` (codex: `/clear`), then the prompt; a
-  send it cannot confirm prints a `warning:` on stderr. For pi,
-  `--fresh` does both in one step.
-- Use `mu agent send`, not raw mux input. Single-quote prompts
-  containing shell expansions, or use a quoted heredoc.
+  send it cannot confirm prints a `warning:` on stderr.
+- Use `mu agent send`, not raw mux input. Quote prompts per
+  [brief](brief.md#quoting).
 - Cross-workstream wait and claim use qualified refs; only task
   ownership crosses.
+- A long run drifts unseen: audit it per [drift-audit](drift-audit.md).
 
 ## Stopping a worker
 

package/skills/mu/recipes/plan.md

@@ -40,14 +40,18 @@ human asks for a file.
    consumes what B produces. Plan order is not a dependency: an extra
    edge serialises tracks that could run in parallel. The exception:
    tasks that edit the same files share a track ([waves](waves.md)).
-7. **Self-review before dispatch.** Walk each spec requirement and name
-   the task that implements it. Grep the notes for placeholders. Check
-   that names in INTERFACES match across tasks. Then read the graph back
-   with `mu task tree task_0 -w <ws> --down`, or `mu state -w <ws>` for the tracks.
+7. **Self-review before dispatch.** Map each spec requirement to its
+   task, grep the notes for placeholders, match INTERFACES names across
+   tasks, and read the graph back (`mu task tree task_0 -w <ws> --down`).
+   Then refute each brief that makes claims ([call](tasks-or-calls.md#delegate-call),
+   all in one turn): "What in this brief is false about the code,
+   ambiguous, or would make a correct worker fail review? Cite
+   file:line." Rewrite each AMEND. Five of six briefs refuted in one run had
+   such a defect, e.g. a fallback test old extensions made unpassable.
 
 Done when every spec requirement maps to a task, no note holds a
-placeholder, and `mu state` shows the intended parallel tracks. Then
-dispatch per [orchestrator-loop](orchestrator-loop.md).
+placeholder, every claim-making brief has a verdict, and `mu state`
+shows the intended parallel tracks. Then dispatch per [orchestrator-loop](orchestrator-loop.md).
 
 ## Notes
 

package/skills/mu/recipes/refute.md

@@ -27,8 +27,9 @@ fact-check nobody will track, use delegate mode from
    [delegate call](tasks-or-calls.md#delegate-call), not a task. The
    refuter gets the finding and the code, not the finder's reasoning,
    and tries to prove it false: run it, find the guard, read the caller.
-   Record its verdict on the finding, and apply the skip and
-   three-refuter rules, as in [findings § Triage](findings.md#triage).
+   Pass `record` so its verdict lands on the finding, and apply the
+   skip and three-refuter rules, as in
+   [findings § Triage](findings.md#triage).
    Many findings: issue the calls in batches under the cap ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)); to
    get the verdicts back as one table, see
    [codemode-driver § Delegate calls](codemode-driver.md#delegate-calls).

package/skills/mu/recipes/remote-workers.md

@@ -44,7 +44,8 @@ mu agent spawn worker-1 -w big --command \
 mu task claim t1 -w big --for worker-1 --evidence 'remote on dev'
 mu agent send worker-1 -w big --fresh '...'
 
-# 5. WAIT: run the claim's one-shot Next: command once per turn
+# 5. WAIT: pi: mu agent wait worker-1 -w big --after-runs <send's runs> --json,
+#    then the claim's Next: once. non-pi: run the claim's Next: once per turn
 
 # 6. COLLECT: fetch straight from the remote worktree
 git fetch "ssh://dev/~/ws/worker-1" HEAD && git cherry-pick FETCH_HEAD
@@ -72,13 +73,13 @@ retry next turn, not progress.
 
 ### Step 3: the control-socket forward
 
-Spawn reports `ctl ok` when all of these hold (`mu doctor` has a ctl
+Spawn reports `ctl: ok` when all of these hold (`mu doctor` has a ctl
 row per agent):
 
 - The host has the mu extension: run `mu link pi` there.
 - The ssh is direct. `$MU_SSH_ARGS` sets `ControlMaster=no
   ControlPath=none`; a multiplexed ssh never binds the forward and spawn
-  reports `ctl missing`.
+  reports `ctl: missing`.
 - sshd allows the forward. A refused forward kills the pane at spawn
   (`ExitOnForwardFailure=yes`). Check `AllowStreamLocalForwarding`.
 
@@ -88,6 +89,16 @@ plus a 10 s cache.
 
 ### Step 5: poll once per turn
 
+The claim's `Next:` mule poll is mandatory. It proves the commit is on
+the host and closes the task. For a pi worker, first block on
+`mu agent wait <name> --after-runs <runs> --json`, with `runs` from
+`mu agent send --json`. It settles exactly over the forwarded socket.
+Without `--after-runs`, a worker that is already idle blocks until
+`--timeout`. If the worker may already be done, pass `<runs-1>`: the
+wait then returns the last answer at once. Then run `Next:` once instead
+of on every turn. On exit 5 (timeout), or on a wait that returns while
+the worker asks a question, run `Next:` anyway.
+
 - Never `sleep` in a tool call. Aborting the loop can leave remote work
   and a capped channel running.
 - Set a deadline before dispatch. At expiry, read the pane, then release
@@ -123,14 +134,20 @@ the final gate before the push that matters.
 
 ## Traps
 
-### A spawn on an auth prompt looks healthy
+### A non-pi spawn on an auth prompt looks healthy
 
 With the channel busy, the attach ssh stopped at `Enter a passcode:`.
 Spawn succeeded, the agent showed `needs_input`, and the prompt went
-into the passcode field. Confirm a remote agent got the work
-(`mu agent read <name> -n 20`) before trusting it. Send nothing
+into the passcode field. This applies to non-pi CLIs and to
+`--via mux`, which paste into the pane. Confirm such an agent got the
+work (`mu agent read <name> -n 20`) before trusting it. Send nothing
 sensitive to an unconfirmed pane.
 
+A pi agent does not paste. Spawn reports `ctl: ok` only when pi
+answers on the socket; otherwise it warns `ctl: missing` or
+`ctl: refused`, and `mu agent send` fails instead of typing into the
+pane.
+
 ### Use the host's real CLI command
 
 If your local `$MU_PI_COMMAND` is a wrapper such as `pi-meta

package/skills/mu/recipes/review-panel.md

@@ -56,7 +56,7 @@ triage and the umbrella closes with `--if-ready` (workstream mode).
 
 - **Reviewers padding the list.** A panel that always finds ten things
   is guessing.
-- **Use different models across angles** where you can; one model's
-  blind spot repeated five times is still one blind spot.
+- **Vary models across angles** ([Models](../SKILL.md#models-and-thinking-effort)); one model's blind spot
+  repeated five times is still one blind spot.
 - **The panel is not the gate command.** Merge verification still runs on the
   merged tree ([orchestrator-loop](orchestrator-loop.md#merging)).

package/skills/mu/recipes/rules-audit.md

@@ -37,7 +37,10 @@ rules are findings: [findings](findings.md) says where they live.
    line and the rule, and drops false positives (the rule does not
    apply here, the code already complies, the rule has a stated
    exception). In workstream mode, a dropped flag is
-   `close --as rejected --why '<reason>'`; a confirmed one is accepted.
+   `close --as rejected --why "<why the rule does not bite here>"`; a
+   confirmed one is accepted with `--evidence` naming the flagged line
+   ([findings § Triage](findings.md#triage) step 3; quoting:
+   [brief § Quoting](brief.md#quoting)).
 5. **Report or fix** confirmed violations, as in review-panel step 5.
 
 Done when every rule from step 1 has a checker result, and every flag
@@ -62,10 +65,12 @@ is decided.
    corrections from different occasions; a one-off is not a rule.
 3. **One `OPEN/triage` task per candidate rule**, the rule as the
    title and its cluster of corrections in the note.
-4. **Refute each candidate** with a [delegate call](tasks-or-calls.md#delegate-call): would it have
-   prevented the real mistakes in its cluster? Does it contradict an
-   existing rule? Is it already enforced by a linter or test (then it
-   needs no prose)? Dropped candidates close `--as rejected`.
+4. **Refute each candidate** with a
+   [delegate call](tasks-or-calls.md#delegate-call) that passes
+   `record`: would it have prevented the real mistakes in its cluster?
+   Does it contradict an existing rule? Is it already enforced by a
+   linter or test (then it needs no prose)? Dropped candidates close
+   `--as rejected --why` naming the deciding answer.
 5. **Propose, don't commit.** The candidates left in triage are the
    proposal: write them as a diff to the rule file in the umbrella's
    note, worded per [brief](brief.md) (positive, specific, with the

package/skills/mu/recipes/tasks-or-calls.md

@@ -7,30 +7,49 @@ hundreds of tasks and a workstream nobody wanted.
 
 ## Delegate call
 
-A **delegate call** is one `mu_delegate` tool call in pi. Without the
-tool (another harness, a script):
-
-```bash
-mu agent spawn refuter-1 -w scratch
-mu agent send refuter-1 -w scratch --fresh '<brief>'
-mu agent wait refuter-1 -w scratch --json   # answer in lastText
-```
+A **delegate call** is one `mu_delegate` tool call in pi.
 
 - **It starts empty.** The brief carries everything: the finding or
-  claim, file paths, the criteria, and the answer line to end with
-  (`VERDICT: ...`, `WINNER: ...`). See [brief](brief.md).
+  claim, file paths, the criteria, and the answer to end with. See
+  [brief](brief.md). A tournament judge ends with `WINNER: ...`
+  ([tournament](tournament.md)). A refuter or claim checker passes
+  `record: { task: "<ws>/<id>" }` and ends with:
+
+  ```text
+  VERDICT: <id> CONFIRMED|REFUTED|UNVERIFIED <one line>
+  EVIDENCE: <file:line or command + result>   (3-6 lines)
+  ```
+
 - **Fan out in one turn.** Issue every call for a step together; in pi
   the answers arrive later as follow-up messages. Calling one, waiting,
   then the next runs them in series.
-- **It leaves no task.** Its `scratch` pane stays attachable while it
-  runs. `mu_delegate` closes it after a clean finish and keeps it on a
-  crash, timeout, or API error (`keep: true` always keeps it); the bash
-  form needs `mu agent close <name> -w scratch`. You record its verdict
-  on the task it judged.
+- **Its `scratch` pane** stays attachable while it runs; `mu_delegate`
+  closes it after a clean finish and keeps it on a crash, timeout, or
+  API error (or always, with `keep: true`).
 - **An API error is yours to decide.** Re-issue the call, or record the
   check as `UNVERIFIED` on its task, then close the kept pane
   (`mu_delegate_cancel`, or `mu agent close`).
 
+Without the tool, write the note `record` would, before deciding:
+
+```bash
+mu agent spawn refuter-1 -w scratch
+runs=$(mu agent send refuter-1 -w scratch --fresh - --json <<'EOF' | jq .runs
+<brief, ending with the VERDICT block>
+EOF
+)
+mu agent wait refuter-1 -w scratch --after-runs "$runs" --json   # answer in lastText
+mu task note <id> -w <ws> - <<'EOF'
+REFUTER 1 (refuter-1, 4m 05s):
+<the VERDICT line and EVIDENCE lines, verbatim>
+EOF
+mu agent close refuter-1 -w scratch
+```
+
+A wait that times out or dies leaves `REFUTER 1: no verdict (<outcome>)`.
+`--after-runs` counts a run that finished before the wait started; the
+quoted heredocs keep the evidence verbatim ([brief § Quoting](brief.md#quoting)).
+
 ## The rule
 
 **A task is a thing the graph tracks. Checking a thing is a call.**
@@ -43,17 +62,15 @@ mu agent wait refuter-1 -w scratch --json   # answer in lastText
 | the umbrella, and each round of a loop | a skeptic or dedupe pass |
 | anything that needs its own workspace | a reader or scout whose output feeds one step |
 
-A call writes nothing to mu. Its answer lands on the task it judged:
-the orchestrator records the verdict as a note and a state change
-(`mu task accept`, `close --as rejected --why '<evidence>'`). The graph
-keeps the decision and its evidence without a node per check.
+A call adds no node: its note and your decision land on the task it
+judged ([findings § Triage](findings.md#triage)).
 
 ## Examples
 
-- A refuter checks 30 findings: 30 delegate calls, 0 new tasks; each
-  finding task gets the refuter's evidence and is accepted or closed.
-- A tournament over 16 names: 15 judge delegate calls; the winner goes
-  in the umbrella's note.
+- 30 findings to refute: 30 delegate calls, 0 new tasks; each finding
+  gets a `REFUTER` note, then your decision.
+- A tournament over 16 names: 15 judge calls; each round's `WINNER:`
+  lines go on the umbrella.
 - A hypothesis test that reverts commits or forces a race needs a
   workspace: that one is a task.
 

package/skills/mu/recipes/tournament.md

@@ -20,8 +20,9 @@ reliable than scoring one.
    each, so no judge holds the whole field
    ([tasks-or-calls](tasks-or-calls.md)). The judge sees the two
    candidates and the rubric and ends with `WINNER: <a|b> <reason>`.
-   Record each round's results in the umbrella's note; winners meet in
-   the next round. A round wider than the cap runs in batches
+   A judge decides a pair, not a task: no `record`. Record each round
+   (pair, winner, reason) in the umbrella's note; winners meet in the
+   next round. A round wider than the cap runs in batches
    ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)).
 5. **Confirm the winner** with a final check against the rubric, then
    merge it. Free the losing workspaces.
@@ -35,6 +36,6 @@ final check passed.
   calls, judge the pair twice with the order swapped; a split decision
   goes to a third judge.
 - **Same model, same taste.** Vary the attempt models, and judge with a
-  model that made no attempt.
+  model that made no attempt ([Models](../SKILL.md#models-and-thinking-effort)).
 - **Ranking many items** (tickets by severity): bucket them in parallel,
   then run pairwise comparisons only within and across bucket edges.

package/skills/mu/recipes/ultrathink.md

@@ -43,8 +43,8 @@ and check, skip it.
    [brief](brief.md) ([plan](plan.md) for a spec-driven build). Rounds
    of a loop are the one exception: add each when the last closes.
 5. **Review every unit that ships.** Each commit-producing task gets a
-   review task ([adversarial-review](adversarial-review.md)), on a
-   different model where you can. Every finding is a triage task,
+   review task ([adversarial-review](adversarial-review.md)) on a
+   [comparable model](../SKILL.md#models-and-thinking-effort). Every finding is a triage task,
    refuted before it is accepted ([findings](findings.md)).
 6. **Run the loop** ([orchestrator-loop](orchestrator-loop.md)): pipeline
    merges, verify each merge, keep workers busy

package/skills/mu/recipes/worker.md

@@ -17,8 +17,9 @@ mu task note <id> "FILES: ...\nDECISION: ...\nVERIFIED: ..."
 mu task close <id> --evidence "tests pass: ..."  # LAST action
 ```
 
-The note follows the task note contract in SKILL.md. Commit before you
-close: the orchestrator cherry-picks your commits, not your tree. A
+The note follows the task note contract in SKILL.md. Keep each tool
+call to minutes (short batches, waits with a timeout): steering reaches
+you only between tool calls. Commit before you close: the orchestrator cherry-picks your commits, not your tree. A
 review or audit task records each problem per
 [findings § Record](findings.md#record).