bug(runtime): a refusal that names the violation but not the exit left a completed task pending forever #2310

In a real session on a packaged build, a task that the model had actually completed was left pending in the ledger forever — because the refusal that blocked it named the rule it broke and not the one call that would have satisfied it. The model read the refusal, could not derive the exit, and abandoned the task.

This is the same shape as #2234, one layer up. #2234 was about a refusal never reaching the model at all. This is about a refusal reaching the model and being useless when it arrives.

What happened

Session a34d6343, run 86204787 (packaged macOS arm64 build, DeepSeek V4 Pro). The model created an 8-task plan and worked it. Task T7 = 第5步：五清扫sweep.

It did the work — ran the sweep script, got a clean result — and then:

seq 223  function_call     task_update {"id":"T7","status":"completed",
                                        "completionEvidence":"五清扫通过，零残留"}
seq 225  function_response task_update  isError: true
                           "Invalid task status transition from pending to completed"
seq 228  function_call     task_update {"id":"T8","status":"in_progress"}

That is the entire refusal text the model received. Not a truncation — the full result.text.

T7 was never started, so pending → completed is genuinely not allowed. The fix is one call: task_update {id: "T7", status: "in_progress"} first. The message does not say that. It does not name in_progress, does not name the tool, does not say a transition exists that would work.

The model's response was to skip T7 and move on. Replaying workflow_task_ledger_events to final state:

第0步：标的定性与中立数据包   in_progress
第1步：三框架盲测             completed
第2步：crux定向核实           completed
第3步：裁决与定价             completed
第3.5步：红队自攻             completed
第4步：撰写并生成.docx        completed
第5步：五清扫sweep            pending      ← the work was done
第6步：交付与台账登记         completed

The ledger now asserts step 5 never happened. It did happen; the evidence string the model tried to attach describes it. The ledger's single job is to hold the plan's true state across a volatile context, and a refusal message caused it to hold a false one.

This model was not confused about the protocol in general — it used in_progress → completed correctly for T1, T2, T3, T4, T5, T6 and T8. It slipped once on T7 and the refusal gave it nothing to recover with.

The same session, the same shape, one turn earlier

seq 149  function_call     task_update {"id":"T4","status":"completed"}
seq 150  function_response "Tool \"task_update\" arguments failed validation: [
                             { \"code\": \"custom\",
                               \"message\": \"completionEvidence is required when status is completed.\",
                               \"path\": [\"completionEvidence\"] } ]
                            task_update takes `id`, `status`, `subject`, `blockedReason`,
                            `failureReason`, `completionEvidence`, `explicitReopen`."
seq 153  function_call     task_update {"id":"T4","status":"completed",
                                        "completionEvidence":"裁决完成：…"}

This one the model recovered from immediately — because the message names the field. That contrast is the whole point: same tool, same session, same model. The recoverable refusal named a thing to do; the unrecoverable one named only a thing that was wrong.

Note also that neither message mentions the other rule. The model learned "completion needs evidence" at seq 150, applied it correctly at seq 223, and walked straight into the second rule it had no way to know about.

Still-unfixed instance of the message #2240 replaces

packages/runtime/src/subagent-tools.ts:142 — agent_spawn carries verbatim the message that #2240 replaces in agent_swarm:

if (Boolean(input.profile) === Boolean(input.subagent_id)) {
  ctx.addIssue({
    code: z.ZodIssueCode.custom,
    message: 'Provide exactly one of subagent_id or legacy profile.',
  });

Three separate dead ends in one sentence: it does not distinguish "you set neither" from "you set both", it does not list the legal profile values, and it does not say where a subagent_id comes from (agent_list). #2240 fixed exactly this in agent-swarm-tools.ts and deliberately scoped agent_spawn out; this is that follow-up. It is a small, self-contained change and the agent_swarm version can be lifted directly.

Suggested rule

A refusal the model is expected to recover from should name a next action, not only a violated constraint. Concretely, for these three:

The transition message is the one that cost a task, so it is the one worth fixing first.

Interaction with #2290

#2290 proposes cutting the transition whitelist and completionEvidence outright ("Transition whitelist + explicitReopen + evidence rules — cut, validate enum membership only"). If that lands as specified, the task-ledger.ts:460 message disappears rather than improves, and this issue's first row becomes moot.

I am not proposing to pre-empt that decision. Two things are worth saying either way:

1. This is a data point for RFC: Radically slim the Session Task Ledger #2290's open question 4, not against it. A rule the authority enforces and cannot explain is a rule that costs real state. That is an argument for cutting or for explaining — but not for leaving it as is.
2. agent_spawn is outside RFC: Radically slim the Session Task Ledger #2290 entirely and can be fixed today regardless of how the RFC resolves.

If #2290's P1 is close, fixing only subagent-tools.ts and letting the transition message die with the whitelist is the cheaper path. If P1 is not close, the transition message is a one-line change that stops a live loss.

What I verified

• Everything above is read from a packaged build's runtime.sqlite: runtime_events for the exact sequence numbers quoted, workflow_task_ledger_events replayed for the final state table.
• The refusal texts are the complete result.text values the model received, not summaries.
• I did not reproduce this deliberately — it surfaced while verifying fix(runtime): decide the tool call event's ledger lane at push time #2240 against a packaged build. n=1 for the abandonment behaviour specifically; a different model might have recovered.
• The agent_spawn message is a static read of current main, not an observed failure.

seq 223  task_update {"id":"T7","status":"completed","completionEvidence":"五清扫通过，零残留"}
seq 225  → isError: "Invalid task status transition from pending to completed"
seq 228  task_update {"id":"T8","status":"in_progress"}