The board shows attempts:1 for a job that ran 9 times, asks for help with no reason or timestamp, and offers takeover of ended sessions

[serge-ivo]

The board under-reports attempts by up to 9×, points "Needs you" at ended sessions, and carries neither reason nor timestamp

Measured live 2026-08-15 across 83 cards on 5 boards.

1. attempts is 1 on all 83 cards, contradicting the board's own note

The board states: "retries of the same job collapse into one; attempts = run count". Counter-evidence from check_instance_loop on the same instances:

instance	card	runs carrying that sessionId	card
f8ddc272	csess-csess_c960d431…	9 (9f3cf5ab, 026d4255, f19d0654, 0dce25fb, 2ab928b6, 86a7ad7f, ea27fbfb, 0cba259e, c7a03659)	attempts:1, completed
bd43f4de	csess_c306e923	3 (one needs_human, one completed, one failed)	attempts:1
e4d2d031	csess_9228b52f	2	attempts:1

One of the nine (9f3cf5ab) failed. The board shows a single clean success where nine runs happened, one of them a failure.

2. Four of five "Needs you" cards point at sessions that ended

instance	card	card status	session	ended
e4d2d031	csess-csess_88a4de4b…	needs_human	ended	09:29:44
f8ddc272	csess-csess_f7a6fcec…	needs_human	ended	09:27:41
e26f69d0	csess-csess_f6266368…	needs_human	ended	09:29:01
5219a03a	csess-csess_e94eb26a…	needs_human	ended	09:28:22
bd43f4de	csess-csess_c306e923…	needs_human	active (capture-verified)	—

Both halves are true in isolation — the run needs a human, the session is over — but the card is keyed on the session (jobKey: csess-<id>) and its affordance is "take over" something closed. board.ts:334 is write-through with no read-time join; closeCodingSessionCards' openOnly:true guard is correct for failed/completed and leaves needs_human pointing at a dead session.

3. The card that asks for help carries no reason and no timestamp

All 5 needs_human cards have detail: "" while the run carries the full explanation ("the limit does not reset until 2026-08-17 16:00 +10:00 … beyond the 6 hours a run may wait"). No card on any of the 5 boards carries a timestamp.

Concrete cost: e4d2d031's "Waiting"/queued card task_fbf2744e… is undated on the board; instance_task_events dates it 2026-08-15T08:55:25.916Z — queued 1h13m before the audit and, given the engine limit, unable to run until Aug 17. Neither fact appears where the owner looks.

Why this misleads into a wrong action

The board is the "does anything want me?" surface (#553). It currently asks for attention without saying why, offers to take over something that no longer exists, and hides that a job was retried nine times with a failure among them.

Acceptance criteria

1. attempts reflects the run count, or the note stops claiming it does. Verify against a card with a known multi-run session — csess_c960d431 has nine.
2. A needs_human card whose session has ended either resolves, or states that the session is over and offers the action that is actually available.
3. A card asking for human attention carries the run's reason and a timestamp.
4. A guard asserts board card state agrees with the run/session it is keyed on, denominator stated per ADR 0002 over all cards on a fixture board — not one card.
5. Red demonstrated on the nine-run case.

Verified vs inferred

• Verified: all counts and card values read live; board.ts:334; the nine run ids; the task-event timestamp.
• Inferred: that attempts is never incremented anywhere. It reads 1 on 83/83 and the note says otherwise, but the writer was not traced — that is the first thing to establish.

[serge-ivo]

Shipped in 37bb2ea (on main, CI + API/MCP/Host deploys all green).

The traced answer to the attempts question

The issue labelled "attempts is never incremented" as inferred and asked for the writer to be
traced first. There is no writer, and nothing was ever incremented — attempts is not a counter.

buildInstanceBoard groups the instance's instance_runtime_tasks by jobKeyForTask and reports
arr.length (board.ts:335), so attempts counts card rows sharing a job key, not runs.

• For an apply card those are the same number: each attempt inserts its own task row and they
  collapse on the normalized URL. board-config.test.ts:295 already pinned that at 2, so the note
  was true for that family all along.
• For a coding card it is pinned at 1 by construction, and correctly so at the layer that does
  it: codingCardId is csess-<sessionId> (coding-board.ts:52) and upsertWorkCard is
  ON CONFLICT(id) DO UPDATE (work-card.ts:22) — one session is one row forever. That dedup is
  the feature ("so every transition upserts the SAME row rather than piling up").

A coding session's attempts are its agent_loop_runs, in a different table, which the board never
read. So the fix is not a write — it is the read-time join board.ts:334 never had, which is also
the only form that can be correct: a session leaves active in five places (enumerated in
coding-board.ts) and a write-through would have to be added to all five and kept there.

What changed

lib/board-runs.ts (new) joins each coding card to its runs and its session at read time, per
coding-board.ts's own rule that the run is the authority (#553).

1. AC1 — attempts is the runs on that session, newest first. A hand-driven session with no
   loop run keeps its single row-derived attempt ("one session, no automated runs" is the truth
   there). The MCP note now says attempts = the runs behind it, which is finally accurate for
   both card families.
2. AC2 — a needs_human card whose session is over stops asking. Where the run has since
   reached a verdict, the card adopts it. Where the run is also still parked, nobody ever
   answered, and the card becomes failed — never completed, which is the exact overwrite
   closeCodingSessionCards' openOnly guard exists to prevent. The fifth card (csess_c306e923,
   capture-verified active) is untouched, as is a card whose session row is missing: an absence is
   not a death. Cards also carry sessionEnded: true so a reader can say the takeover is gone
   without inferring it from a status. No console change was needed — leaving needs_human is what
   withdraws the takeover affordance.
3. AC3 — the card carries the run's reason (all five had detail: "" because
   setCodingSessionCardStatus patches only $.status); a live progress line (#207B) is never
   overwritten. The missing timestamp was an MCP projection loss, not a board one:
   BoardItemView.updatedAt existed all along and groupBoard's fixed card list dropped it. Added.
4. AC4 — board-runs.test.ts asserts the invariant over a 9-session fixture covering every
   combination observed live, with the denominator asserted and printed per ADR 0002 (G1/G2) and
   unresolvable cards reported rather than skipped (G3).
5. AC5 — red demonstrated (G4) with the join disabled: attempts 1 ≠ 9 runs on
   csess_c960d431, four needs_human on a ended session, and the nine-run card returning one
   attempt.

No MCP_SERVER_VERSION bump: the surface fingerprint excludes descriptions and covers no response
body, and neither tool declares an outputSchema.

Verified / not verified

Verified: full suite green; the new guard red-then-green on the nine-run case; typecheck,
biome, file-size, bare-catch, surface-lock, migrations, test-isolation, design-tokens,
agents-allowlist, qa-config, docs-drift; Playwright 405 passed (chromium + webkit); CI and all
three deploys green; api.proagentstore.online/health and mcp.proagentstore.online/health live.

NOT verified in production: I hold no session token, and both the board API and the MCP surface
are auth-gated, so I could not read csess_c960d431 live to confirm it now reports nine attempts,
nor confirm the four needs_human cards have left the column. Leaving this open for that one
check — it needs an authenticated read (instance_board on f8ddc272, e4d2d031, e26f69d0,
5219a03a, bd43f4de), which the pags-live agent can do.

[serge-ivo]

Verified live — the check 37bb2ea could not make without a session token

Read from production 2026-08-15 on f8ddc272 (Heartfull), 24 cards:

defect	before	after
attempts on csess_c960d431	1	9 — the exact nine runs
attempts on csess_e4775bf7	1	2
cards carrying a timestamp	0 of 83	every card has updatedAt
needs_human on an ended session	offered "take over"	moved to Failed: "The session ended while this was waiting for you — there is nothing left to take over."
detail on the help-asking card	""	full run reason, including the Aug-17 reset instant

sessionEnded: true is now on the card, and the board note documents it. All three defects in this issue are closed on live data.

One residual contradiction the new data exposes

Two cards sit in Done with status: "completed" and a detail that says the run failed:

• csess_c960d431 — status: completed, runStatus: completed, attempts: 9, detail: "outcome: failed — run error: UserAiProviderError: The AI provider stopped sending mid-reply…"
• csess_e4775bf7 — status: completed, runStatus: completed, attempts: 2, detail: "outcome: failed — stuck not resolved in time"

With attempts: 9 this may be correct in substance — eight runs succeeded and the last one failed — but the card presents a column and a status saying success beside prose saying failure, and a reader cannot tell which run the detail describes.

The audit established that one of csess_c960d431's nine (9f3cf5ab) failed. So the open question is narrow and worth answering explicitly rather than by inspection: when a job has N runs with mixed outcomes, which one does detail describe, and should status reflect the last run, the best, or the fact that outcomes were mixed?

This is the same class this issue fixed — a summary that cannot express what actually happened — one level in. Recommend it stays open on that point, or is split out if the answer is a design decision rather than a fix.

Verified vs inferred

• Verified: every value above read from the deployed board; the nine run ids from the earlier audit.
• Inferred: that eight of the nine succeeded. Only 9f3cf5ab was confirmed failed; the other eight outcomes were not individually re-checked, so "mixed" is established but the ratio is not.