[switchyard] Surface tracks needing a decision or review in an attention inbox

[jhgaylor]

Outcome

A user returning to Switchyard can see which tracks need them and resolve the next item without inspecting every transcript. Example: one agent awaits a tool decision, another has a failed queued prompt, and a third finished a turn worth reviewing.

Proposed priority: next after previews. Audience: implementing coding agent. This is a backlog proposal, not an instruction to start implementation or change runtime permission policy.

First useful version

• Add a cross-project attention inbox filtered to tracks the viewer can access.
• Separate actionable states (live permission request, failed/unconfirmed delivery) from completed turns awaiting review. A completed turn does not mean the task is complete.
• Show the reason, age, project/track, and a direct action or deep link to the relevant evidence.
• For permission requests, show the actual tool details and offered options. Submit only an option supplied by Fountain; reconcile expired or already-answered requests.
• Persist per-user read/dismiss state and reconstruct upstream state after reconnect/restart. Dismissing a row must not answer a request or retry work.
• Handle two people answering simultaneously. Recheck membership when acting and remove inaccessible items.

Implementation starting points

Read apps/switchyard/server/{context,tracks,prompt-queue,fountain,db}.ts, shared/api.ts, and src/components/{Yard,TrackView}.tsx. Inspect apps/fountain-workbench/server/watch.ts for prior held-request handling; confirm its assumptions against the current Fountain API before reuse. Fountain source exposes POST /api/conversations/:id/requests/:request_id; Switchyard needs a typed, authorized wrapper, never a general account proxy.

Do not infer a blocking question from question marks in assistant prose. Use authoritative request state; any new structured question protocol is a separate dependency. Collect/reconcile attention on the server so closed track tabs do not lose events.

Completion checks

• Three tracks with different attention reasons appear accurately after all tabs close and the server restarts.
• Responding resumes the correct request; duplicate, expired, and revoked-access actions do not affect another request.
• Queue failures keep existing retry/uncertain-delivery semantics.
• Reading on one device updates the user's inbox on another.
• Tests cover ordering, reconstruction, authorization, and concurrent answers; Switchyard tests/build pass.

External notifications and Web Push are follow-up scope. The first version must not promise alerts while every browser is closed.