Read run records, and make a Start leave a mark on the task

[TadMSTR]

Phase 3 of agent-workflow-interop-2026-08, plugin half. Tracker: vikunja#559. Pairs with TadMSTR/task-dispatcher#5.

A Start left no trace on the task

It made no queue mutation at all, so a plugin-started task stayed at approved until its agent got as far as claiming it — and a session that died before that left nothing behind anywhere. That is why one completed steward run was invisible for four days (vikunja#534).

A Start now appends a history entry through the control API. The status is deliberately unchanged — the call re-asserts the status the task is already in, which the handler accepts with allow_override plus a note.

Advancing approved → in-progress here is the obvious-looking alternative and it breaks every plugin-started session: the agent's own first action is update_task(in-progress), which task-queue-mcp permits only from approved. Doing it for the agent means its claim is rejected as an invalid transition.

A failure to record is logged and does not fail the Start — the session is already running by then, and reporting the launch as failed would be the bigger lie.

Run records

This plugin now writes <agent>-<task8>.json beside its log, the same shape the dispatcher writes, and reads both. FORGE_RUN_ID/FORGE_TASK_ID go into the session's environment.

It records a real exit code, and the dispatcher cannot. This is a long-lived process, so the child handle outlives the spawn and 'exit' still fires after unref(). A dispatcher tick spawns a detached child and exits, so its runs can only ever be reaped as pid-gone with a null code. That asymmetry is the design, not an inconsistency. A signalled child records the signal rather than a coerced number.

If CloudCLI restarts before a child ends, the handler never fires and the record stays open — not a leak: the dispatcher's reaper closes it on the next tick, honestly. The two mechanisms are complementary and neither invents an outcome.

The list is now a union

Keyed on the shared <agent>-<task8> stem:

• A log with no record is one of the 29 runs that predate them. Times still come from the file's mtime; the outcome column reads no run record.
• A record with no readable log is the security-audit launcher, whose output goes to ~/.pm2/logs/security-audit-<build>.log. That prefix stays outside PREVIEW_ALLOWED_PREFIXES deliberately — it covers every PM2 service log on this host, and adding it would make this endpoint a reader of all of them. So the row renders and the detail view says where the log is. Dropping it would have omitted the commonest kind of headless session here; widening the allowlist to read it would have been a real security regression to fix a display problem.

The outcome column keeps three states apart

Rendered	Means
no run record	Predates run records; nothing is known
running	A record with no ended
exit 0 / exit 137	A real observed code — only this plugin's own launches get one
ended, exit code unknown	The run ended and the code is unrecoverable
slot released — still running	Past the dispatcher's max runtime; slot freed, process untouched

ended, exit code unknown is not a gap to fill later. Collapsing it into success is the counter-reporting-success failure this whole build exists to expose.

Unchanged, deliberately

• Status comes from the queue and only from the queue. A record saying a run exited 0 does not promote its task's status. A finished run whose task is still approved is the disagreement this panel exists to show.
• The <agent>-<task8>.log filename. Two other consumers key on it.

Also

• Duration for a still-open run is unknown, not a growing number — it would otherwise tick upward on every poll for a session that died an hour ago and has not been reaped.
• Open runs sort above finished ones. A descending compare on ended put them at the bottom, under three months of finished runs.

Verification

• 139 tests pass (12 new files' worth of assertions added), tsc clean, vocabulary gate in sync.
• 14 mutants planted, 14 caught. Two initially escaped and both were weak tests, not weak code — the array-rejection test passed with Array.isArray deleted because the task_id check already excluded arrays (now labelled as intent rather than validation, so nobody later "proves" it load-bearing), and the status test used an open record so a record.ended → completed inference survived it.
• Run against the real corpus, not just fixtures: 29 files → 27 rows, matching the pre-change behaviour exactly, with the 2 known bare-UUID orphans still skipped.
• Booted dist/server.js and curled the real endpoints with record fixtures planted in the live launch directory and removed afterwards: the record-only row returned log_readable: false, outcome: "ended, exit code unknown", and its detail route returned 200 with the log's path rather than the pre-change 404.

Deploy

./deploy.sh && pm2 restart cloudcli. dist/ is gitignored and built at deploy time — merged is not deployed, and the panel stays at v0.8.0 until that runs.

🤖 Generated with Claude Code