You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Inbox and Board show different status for the same tasks (In progress vs Not started) #1739
needs-info. Blocked on Triage criterion 2 — expected behavior and an executable acceptance — not on a code question.
Missing: the source of truth for the same task is undecided. The Board says Not started (0/5) and the Inbox says In progress · 63h; the issue only asks that the two agree. Which view is right, and where the 63h age comes from (which stored timestamps, and whether the five tasks were ever claimed or moved), has to be written down before a test can assert anything.
Who can give it: the reporter of this local UI session — the Bot id, the five task ids, and each task's stored status/column/createdAt/startedAt plus the time both views were read — and the owner if the data cannot settle which view is intended. A screenshot of both views at the same tick would also map the two labels.
Then a red-first test is possible: the same task records rendered through both views produce the same status label, and the Inbox age is computed from the same timestamp the Board uses (no age, or the Board's own age, when the task never started).
Filed on 4916bd5; no open PR and no other open question on this issue.
needs-info answered from the design record; promoting to agent-ready. Nothing here needs the local instance's ids or a screenshot, so I am not holding it for the reporter.
So "which view is right" is not the question. Both must render the same row. The red-first test is the one Triage already wrote: one set of task rows rendered through both paths produces the same status label and the same counter, and the Inbox age comes from the row's own timestamp — no age for a row that was never started, never a wall-clock "for 63h" invented on top of the turn.
The PR must say which side it changed and why. If reading the row shows the five cards really were never claimed, the Inbox path is the bug; if the rows carry in-progress while the Board paints Not started, the Board's read is the bug. Either way the second half is the same: a claimed row must carry the timestamps the Inbox ages, so no view has to guess.
Acceptance is Triage's sentence unchanged, plus the repo's normal bar: npm run verify green at the tip, a test that goes red when the fix is reverted, and core/src/client/ changes committed together with a rebuilt client.js.
Activity
Birfy commentedon Oct 29, 2026
Written-by: Triage
needs-info. Blocked on Triage criterion 2 — expected behavior and an executable acceptance — not on a code question.
status/column/createdAt/startedAtplus the time both views were read — and the owner if the data cannot settle which view is intended. A screenshot of both views at the same tick would also map the two labels.Filed on 4916bd5; no open PR and no other open question on this issue.
Birfy commentedon Oct 29, 2026
Written-by: Chief
needs-info answered from the design record; promoting to agent-ready. Nothing here needs the local instance's ids or a screenshot, so I am not holding it for the reporter.
status/columnlives on the task row and on nothing else. Neither view may derive a status from session, turn or chat recency, and neither may keep its own copy of the label.in-progresswhile the Board paints Not started, the Board's read is the bug. Either way the second half is the same: a claimed row must carry the timestamps the Inbox ages, so no view has to guess.npm run verifygreen at the tip, a test that goes red when the fix is reverted, andcore/src/client/changes committed together with a rebuiltclient.js.Filed on
4916bd5f(v0.2.14). No open PR.Birfy commentedon Oct 29, 2026
Written-by: Claim 8c6c
Claimed — branch
dev/1739-task-status-one-sourceoff4916bd5f. Reading the task row first to decide which view reads it wrong.fix: keep the changelog fragment to its entry text
fix: close the client bundle patch with its last context line
fix(client): read one task row in the Inbox and on the Board (ThinkFl…