mu 1.3.2

A worker that stops to ask a question is no longer reported as one that forgot to close its task. The stall warning asserted Worker likely committed but skipped mu task close <id>, but the predicate behind it only knows "owner has been in needs_input for >= N seconds". That covers at least three situations needing opposite responses — a worker that finished without closing, one waiting on an answer, one sitting at an approval prompt — and naming the first sent an operator hunting for a commit to merge while the worker was waiting on a design decision.

The warning now states the observation and points at mu agent read <owner>, which is the next move in all three cases, because the evidence is in the pane rather than the task row:

mu task wait: swayward/m5_titlebars needs attention — owner=worker-13 has been in
needs_input for 10m. It may have finished without closing, be waiting on an
answer, or be sitting at a prompt.
  mu agent read worker-13 -w swayward --lines 60

The age is now the measurement, not the threshold. The old text interpolated --stuck-after, so --stuck-after 1 said "(>= 1000ms since last status change)" about a worker idle for five minutes. StallDetectedDuringWaitError.ageSecs had the same bug, and a test asserting ageSecs === 2 for an agent 600s stale passed.

nextSteps reads the pane for a stuck ref. On timeout every unmet ref got mu task show <id>, which for this case shows a healthy-looking IN_PROGRESS row and none of the reason it stopped. The exit-7 error's steps were reordered for the same reason: they led with "poke the worker", which is right for one of the three causes and actively wrong for a worker waiting on an answer, since a poke with no answer in it just restates the question.

--stuck-after --help no longer hides --on-stall. Its description ended "Wait keeps polling — the warning is observation-only", which was true when --stuck-after was the only flag and has been false since 0.3.0 added --on-stall exit. A careful reader stopped at that sentence and filed a request for a flag that had existed for ten releases. mu agent wait --help likewise now says why it is not the answer here.

The pattern is renamed agent_close_discipline_gap → agent_attention_required, and docs/VOCABULARY.md records that the term stays cause-neutral. Workers asking questions is desirable behaviour: the reported session had one catch a spec example that was not valid KDL, and another refute a task premise with evidence from the reference source.

Patch: no verb, flag, schema or SDK signature changed. The stuck JSON field and exit 7 were deliberately left alone.

Thanks to the reporter, who also filed the correction that led to the real defect.