After a hold release on resume, batch-state keeps the task 'held' and marks the not-yet-started lane successor 'running' (dashboard mis-attributes telemetry)

[HenryLach]

Report

penster batch 20260911T234647 (0.30.6 + Stage 2 build), field report on #627, item A. After a post-hold-timeout orch_resume(force=true) released TP-2104's hold and relaunched its worker:

• batch-state.json: TP-2104 status=held, exitReason="Hold timeout … the hold remains open"; TP-2105 status=running, exitReason="Lane held — awaiting ruling on an earlier task".
• Lane snapshot .pi/runtime/<batch>/lanes/lane-1.json: taskId / worker.status=running, tool calls advancing — correct.
• Dashboard: TP-2104 shows held with no activity; TP-2105 shows running with the relaunched TP-2104 worker's telemetry (53 tool calls, 17 %, $5.30) while its description says "Not Started", progress 0/25. Screenshot on Cap-ruling hold: runtime must block .DONE and merge while an operator ruling is pending (.PENDING-RULING) #627.

Analysis (to verify)

Two separate defects:

1. Status projection after release. The held task's persisted status is only re-projected at the next task-transition persist; hold-released (a strict hold-store write) does not flip the task record from held → running. Expected: the hold-store update() for a release should also project the bound task (and segment) status to running/pending in the same strict write, or resume's re-execution should upsert the outcome as running before spawning.
2. Successor mis-attribution. The successor on the same serial lane was persisted as running on resume. Suspects: the laneHeld pending outcome (execution.ts lane loop: status: (pauseSignal.paused || laneHeld) && !shouldSkipRemaining ? "pending" : "skipped" with exitReason "Lane held — awaiting ruling on an earlier task") being re-mapped to running by resume reconciliation (reconcileTaskStates precedence 2 "session alive → reconnect/running" matches the lane's shared sessionName), and the dashboard keying telemetry on the lane's currentTaskId while the badge keys on batch-state.json. Expected: a not-yet-started successor stays pending; the lane's telemetry attaches to the task named in the lane snapshot.

Acceptance

• Behavioural test: held task → ruling → resume → after relaunch, persisted statuses are TP-A running, TP-B pending; dashboard /api/state (or the projection helper it uses) attributes lane-1 telemetry to TP-A.
• hold-released strict write projects the task/segment status in the same persist.

[HenryLach]

Mechanism, from the penster supervisor (verifiable from state files, not the UI):

1. Badge source vs telemetry source disagree. batch-state.json still carries TP-2104 status=held (stale exitReason: "Hold timeout … the hold remains open") and TP-2105 status=running (exitReason: "Lane held — awaiting ruling on an earlier task"), while .pi/runtime/<batch>/lanes/lane-1.json correctly says taskId=TP-2104, worker.status=running. The dashboard renders the badge from the former and tool-call/cost telemetry from the latter.
2. hold-released never triggers a task-transition persist. The engine log shows hold-released:<id> ×3 with no task-transition for TP-2104 afterwards; batch-state is only rewritten at the next step/task boundary, so the stale labels persist for the whole task.
3. Checkbox progress (from STATUS.md) was accurate — only the badge and telemetry attribution are wrong.

Deterministic repro: hold → hold-timeout → queue a ruling → orch_resume(force=true) → diff batch-state.json tasks vs lanes/lane-N.json.

Fix shape (two writers, not one):

• Release projection: the hold-store update() that persists released is a strict whole-state write — project the bound task's record (status: running, clear the hold-timeout exitReason) in that same write (hold-state.ts createHoldStore persist callback → serializeBatchState reads task statuses from allTaskOutcomes, so the runner must upsert the outcome before holdStore.update(), or the engine's persist callback must do it).
• Successor status: TP-2105 status=running is a different defect — the laneHeld outcome is emitted as pending (execution.ts lane loop), so something on the resume path promoted it. Prime suspect: reconcileTaskStates precedence 2 (sessionAlive → running) because both tasks share the lane's sessionName, or the resume pre-wave outcome synthesis. Must stay pending until the lane actually starts it.
• Dashboard: attribute lane telemetry to the lane snapshot's taskId, never to the batch-state task whose status=running happens to sit on that lane.

Regression: the behavioural test in the acceptance section above, plus an assertion that the successor's persisted status is pending immediately after resume.

[HenryLach]

Confirmed with a second screenshot (lane 1, 20260911T234647): TP-2104 held 61 % 17/28 "Step 3"; TP-2105 running 0/25 "Not Started" yet carrying 271 tool calls, 44 % context, $46.31 and bash: … go test ./internal/gateway/ — TP-2104's Step-3 work.

Dashboard attribution site: dashboard/public/app.js:875-876 resolves the lane snapshot (ls) and telemetry (tel) once per lane, then the per-task loop attaches them to whichever task has status === "running" (app.js:993, :1007) with no ls.taskId === task.taskId check. The reviewer sub-row already does this correctly (isReviewerActiveForTask, :106, checks ls.taskId); the worker stats block does not. So any stale running in batch-state borrows the lane's live numbers.

Dashboard fix (independent of the two writer fixes above): gate the worker-stats/telemetry block on (!ls.taskId || ls.taskId === task.taskId) exactly like the reviewer row, and render the held task's row with the lane telemetry when ls.taskId names it even though its badge says held — the badge is the stale part, the snapshot is authoritative. Three fixes total: release projection (runner/engine), successor pending (resume), telemetry-by-snapshot-taskId (dashboard).