client: a Project board — in flight, waiting on you, delivered today (read-only projection over the task store) #1701

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: 97b1b5e7492a403bb2ed0a1c7ade5205
Branch: dev/3-project-board-v1
Base: d534703
At: 2026-10-29T14:08:18Z

The moment this fixes

Owner, any time they want to know how the project is going — today they cannot see it in one place: the task board opens one Bot or one group at a time (core/src/client/kanban.js:83 boardRail lists only my own Bots and the groups I administer; :166 useBoardTasks filters own.filter(task => task.ownerBotId === scope.botId)), and every switch re-polls (:12 POLL_MS = 15_000). Answering "what is in flight, what is waiting on me, what shipped" means walking the rail across five Bots and then asking the Lead in chat — which is exactly how today's status summary was written by hand.

core/src/client/inbox.js:1-10 already answers "what needs me / in progress / done across my own Bots" as a feed; this issue is the missing project view over the same data, not a second inbox.

What to build (read-only projection)

One Project entry at the top of the board rail, with three columns taken from the real task lifecycle (core/src/host/tasks.js:23-33, :58 WALK):

• In flight — status in open|claimed|working; the card shows claimedBy and queueRole when set.
• Waiting on you — blocked with waitingFor: 'input', and result-ready; this column reuses the inbox's existing sources and its existing answer path (an approval or ask_user is answered there, inbox.js:1-10).
• Delivered today — accepted with updatedAt inside 24h; the card names the Bot / group / run it came from.

Workflow runs are shown as their own read-only group in this view (not merged into task identity), from the records the workflow service already returns (plugins/workflow/src/service.js:300-326 gives runs, history, queue; publicRun at :89-107 is the shape).

Explicitly not doing

• No second board, no second store, no second scheduler: this is a projection over core/src/host/tasks.js.
• No new answer/approval entry: inbox.js is reused, never duplicated.
• No write operations in this version: no column drag, no reassignment, no "take it myself".
• No merge of workflow run cards into task identity — that waits for the Stage 3 typed Task/Handoff contract; until then runs are their own group.
• core/src/host/task-drive.js, core/src/shared/workflow-run.js, core/src/host/workflow-store.js, plugins/workflow/src/* untouched.
• No Project State injection, no knowledge graph, no vector memory.

Temporary project boundary (owner ruling 2026-10-29)

Until the Project record lands (#1691, PR #1695), "the project" in this slice means my own Bots plus the groups I administer — the same set boardRail already derives. Constraints:

• the boundary is resolved in exactly one place in the client, and that place is marked TEMPORARY in the code comment and named "temporary project boundary" in the issue/PR body;
• when #1691 lands, that one place switches to the Project record in a single follow-up commit — no second Project concept anywhere, no double identity (a task must never render under two project identities).

Slices (one PR each, each with the usual four items)

1. rail + project scope: a Project entry at the top of the rail and scope.kind === 'project' in useBoardTasks, showing the three columns over the existing unfiltered own list (no host change).
2. "Waiting on you" reuses the inbox: the column's cards come from the same sources and answer in place through the existing inbox path; assert there is exactly one answer entry in the DOM.
3. Delivered today + workflow run group: accepted within 24h with provenance, and the run group read from the workflow service's existing read.

Acceptance

(a) With five Bots and one group, the Project board lists every active task the rail would show one Bot at a time, in the three columns, with no task counted twice.
(b) A task blocked/waitingFor:'input' appears in "Waiting on you" and can be answered from there; the DOM has exactly one answer control per card (no second path).
(c) accepted tasks updated within 24h appear in "Delivered today" with their Bot/group/run provenance; older ones do not.
(d) Workflow runs appear as their own group, read-only, and no run card is treated as a task record.
(e) A read Bots/group set that the actor may not see stays invisible (the existing host filtering is relied on, not re-implemented).
(f) The temporary boundary is one function, marked TEMPORARY, and a test pins that it is the only place deriving the project set.
(g) Proxy metric for "it worked": the owner no longer needs the hand-written status summary — each 30-minute check-in that asks for that summary becomes evidence; record it in the PR body as "no longer needed since " once true.

Where it lands

core/src/client/kanban.js (project scope, board columns, rail), core/src/client/inbox.js (reuse only), core/src/client/i18n.js (2–3 strings), and a read of plugins/workflow/src/service.js through the existing client call. No host write paths, no new endpoint unless the existing tasks read needs a scope flag (core/src/host/tasks.js:891 taskEndpoint, :893 case 'tasks' — prefer the client-side filter already used by useBoardTasks).