feat(web): one cross-session "Needs you" queue

[saucam]

P5.3 (conductor-frontends-design.md §8). Every blocking event across every agent in one ranked list, with the count always visible in the status bar and the queue one click away.

The problem it removes

Today you find the agent that stopped by opening sessions until you hit it. Three unrelated things block — a session wedged on a tool approval, a provider dialog waiting on an answer, a dispatch task that hit the anti-spin limit — and none of them announces itself anywhere shared.

Ranking — §8's (blocking-cost × staleness)

A question or approval has stopped a live agent mid-turn, so it outranks a blocked task, which is stopped but burning nothing. failed ranks lowest — it's the one kind that can still resolve without you, since it retries with backoff (§6).

Staleness then overtakes kind as things sit, which is what makes §8's worked example true: "an agent stuck 8 minutes on a yes/no floats to the top."

An age floor is what makes that work at both ends. Without it every fresh item scores zero regardless of kind, so the queue would rank purely by age exactly when a live wedged agent most needs to be first.

Three correctness details

One stoppage is one row. A session showing a provider dialog is usually also waiting_approval. Counting both would tell you two things need you when one does — in a queue whose entire job is that count.

An unknown age reads as brand new, never ancient, so something with no usable timestamp can't jump the queue. Future timestamps clamp to zero age too: clock skew between daemon and browser is normal and mustn't bury a real interruption.

Ties break totally and stably (since, then key). A queue that reshuffles equal rows between renders is one you can't click accurately.

An honest approximation

Neither a ui_request nor a FleetTaskWire carries the moment it began waiting. A session falls back to lastActivityAt (a wedged session stops producing activity the instant it wedges); a task falls back to its creation time. Both err toward looking older than reality, which biases toward surfacing rather than hiding — the right direction for this list. The code says so where it matters.

One small UX call

The badge shows zero rather than disappearing. A badge that vanishes can't be trusted as an at-a-glance "nothing is stuck" signal, because you can't tell clear from broken.

Verified against a real board

Not just fixtures — running the queue over a captured board plus a simulated 3-minute-old wedged agent:

queue length: 3

  [blocked ] spawn c0234348    reclaimed: stale claim
  [blocked ] spawn cff8e6c5    reclaimed: stale claim
  [approval] api               waiting for tool approval

The two tasks blocked by the old daemon-collision bug (#319) outrank the fresher wedged agent — staleness overtaking kind weight, exactly as specified — and the finished tasks stay out.

Verification: 14 attention tests, 243 web tests total, typecheck / lint / build clean.

Next

§8's remaining pieces are the four-action approval grammar (Approve · Edit args · Respond · Reject) and approval mirroring with escalate-to-parent — both of which extend ApprovalBar rather than this queue.

🤖 Generated with Claude Code