client: a later successful run of the same task never retires its failed card in the Inbox #2534

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 206d0c6e74864db1bbfd88ec46ebfb4a
Branch: dev/3-inbox-stale-failed-card
Base: 90a5944
At: 2026-11-05T13:24:10Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What happens

A workflow task that failed once and then finished green on a later run keeps its red "Failed" card in the Inbox for the full seven-day window, and the sidebar Needs-you count never falls back to zero.

Today core/src/client/inbox.js:311-343 walks history and keeps every run whose status === 'failed' inside KEEP_MS, taking the newest one; the successful run of the same task is in the very same payload (plugins/workflow/src/service.js:2150 records status: 'done' there too) and is simply not looked at. The card then has no way out: visibleNeeds (:381-383) filters only on answered, answered is written only by inboxAnswer for approval / question / task cards, and a workflow card's single control is Open (:583), which only navigates. useWorkflows re-reads every 30s, so the card comes back by itself until KEEP_MS expires. needsCount (:370) reads the same list, so the red dot stays with it.

Reproduction (red first)

Clean 90a59447, only the test file touched, TZ=UTC node --test test/inbox-workflow-failure.test.js → exit 1:

not ok 9 - P-599: a later successful run of the same task retires its failed card
  the run that finished green answers the failure
  + actual   ['run-failed']
  - expected []
# tests 9
# pass 8
# fail 1

The fixture is one graph whose history holds two runs of the same task.id: failed two hours ago (failure.code: 'step-failed') and done thirty minutes ago. Assertions: no workflow card in needs, progress or done; a control failure of a different task.id in the same graph is still listed; needsCount === needs.length.

Expected

A failure that a later run of the same task has superseded leaves Needs you, and the count drops with it. A failure with no later success keeps the current seven-day window (#1706's behaviour is unchanged) — that is the control.

Scope

• core/src/client/inbox.js — after choosing the newest failed run, skip it when the same graph reports a status: 'done' run with the same task.id and a later endedAt. Four added lines, no new abstraction:

  const { taskId, endedAt } = failure
  const superseded = runs.some((r) => r.taskId === taskId && r.status === 'done' && r.endedAt > endedAt)
  if (superseded) continue

• core/test/inbox-workflow-failure.test.js — the ninth case above plus its control.
• Generated, once the bundle lane is free: core/client.js, patches/ds-bot/0008-client-bundle.patch, patches/ds-bot/0001-core-fixes.patch (src/client/inbox.js mirror), one line in docs/subsystems/core-client.md, one changelog.d/ fragment.

Tier: T1 (core/src/client/**, core/test/**, changelog.d/**). Read-only window behaviour is untouched: this only removes a stale card, it adds no write.

Duplicate check

Searched live main plus issues before filing: inbox failed in:title (7, none this), "failed card" in:body (56, nearest #968 closed — Retry on two core cards), inbox stale (28, none this). Nearest neighbours and why they differ: #1717 and #1706 (closed) made a failed run arrive; #2515 (closed) fixed where workflow Open lands; #1566 / #1567 (closed) are a hidden Bot's failed turn; #471 is the umbrella. None of them covers a later success retiring the card.

Open PRs checked for overlap on core/src/client/inbox.js (nine at the time of filing): none touches it; the only client-side work in flight is #2523 (kanban / new-chat / project-board) and #2531 (host test).

Done when

The ninth case passes on the clean base plus the fix, core/test/inbox.test.js stays green (32/32), the two inbox suites together are 50/50, npm run build-client --check and the patch check are clean, and the read-only window still writes nothing.