needs_action is wired but nothing populates it — proposal: client-side attention projection over existing events (+ WF-08 completion)

[VenusOne-Lee]

What we found

The feed's needs_action category is wired end-to-end but nothing can ever populate it:

• crates/buzz-db/src/feed.rs:167 defines needs_action as kinds 46010/40007 p-tagging the user.
• Nothing in the tree emits either kind. The WF-08 TODO at crates/buzz-workflow/src/executor.rs:663 suspends workflow approvals without emitting 46010.
• 46010 is absent from required_scope_for_kind() in crates/buzz-relay/src/handlers/ingest.rs, so a client cannot submit one even deliberately.

Net effect: needs_action returns an empty list on every surface (relay SQL, desktop Tauri mapping, mobile). The slot exists and waits; no producer exists. (File references are against 28ae6cd2.)

The user problem behind it

Operators running several agents get a feed that answers "what happened" but not "what is stuck on me". Asks for a decision, an approval, or a manual step drown in ambient activity, so agents block on a human who cannot see that they are the blocker. VISION_ACTIVITY's own framing applies: waiting should be a rendered state, and a polished view should be a zoom level on the same truth, not a different feed.

Proposal (for discussion before any feature PR)

A client-side attention projection over events the relay already stores, rather than a new pipeline:

• Projects only mention and actionable-ask items from the existing feed (layered on buildInboxItems); ambient activity excluded by construction.
• Deterministic, pure-function ask extraction (no model calls, unit- and regression-testable).
• Every resolution posts an ordinary threaded kind-9 reply p-tagging the asker, so the asking agent wakes through today's trigger path. Nothing is resolved silently.
• Zero new event kinds, zero relay changes — consistent with VISION_PROJECTS ("custom kinds only where genuinely novel").
• Ships behind a preview-features.json flag, off by default.
• Packaging lean: an Inbox mode/section rather than a fourth sibling surface, per the precedent in feat(desktop): handle project work from Inbox #3117.

Separately and complementarily: completing WF-08 so workflow approvals emit 46010 would give the reserved category its first real producer. We are happy to take that on as its own thread of work.

Evidence this is buildable small

We built this in our fork (VenusOne-Lee/buzz, branch buzz-one) and have been using it daily against a live community relay: projection library, deterministic extractor with regression tests reproducing real field misclassifications, five posting actions with a client-side undo before publish, all behind a preview flag. Current suite: 3832 unit tests plus Playwright coverage of the full card lifecycle.

If the direction is agreeable we would split it into small, independently mergeable PRs:

1. Pure projection library + full unit/regression suite (no UI, no routes).
2. The rendering consuming the library, unreachable without the flag.
3. Nav entry + the flag definition, off by default, with screenshots.

None of these touch the relay or add kinds. Is this a direction you'd merge, and do you have a preference on the Inbox-integrated packaging versus a separate gated screen?

Acceptance criteria (adopted 2026-08-18)

Adopted from the field audit in this comment; mapping and design resolutions in our reply.

1. Signed per-thread work state (active / needs-human / complete) without editing the root — signed 46010/40007 events are the explicit state layer; the client-side projection is the reading layer over them plus ordinary replies.
2. State is updatable by the accountable agent or an authorized steward even on a root they did not author; anyone may set state on their own behalf (same trust model as issue assignment; enforced in projection validation).
3. State visible on collapsed channel roots and thread headers.
4. Cross-channel "Needs me" view with a count, deep-linking to the unresolved ask.
5. Each needs-human item carries the requested person, accountable owner, concrete ask, and timestamp; resolving clears it.
6. Atomic, auditable state transitions: conflicts resolve deterministically (latest valid signed state per thread by created_at, event-id tie-break); counts are computed from the projection, never stored.
7. Desktop/mobile parity, phased: desktop rendering first, mobile renders the same shared projection.

Revised PR sequence: (1) WF-08 completion + relay required_scope_for_kind() fix, (2) projection library, (3) rendering (collapsed roots, thread headers, Needs-me), (4) navigation. Existing unit and Playwright coverage will be adapted to assert each criterion explicitly.

[mhyatt18]

User evidence from Buzz Desktop 0.5.14 on macOS:

We audited 27 top-level work threads from seven days of a live human-agent command channel. Twenty were complete, three were blocked specifically on the human, and four remained agent-owned or externally blocked. Before manually tagging the roots, the human could not scan the channel and determine where his input was required; he repeatedly reopened threads to reconstruct their state.

We tested a temporary convention using a yellow root reaction for “needs human,” a checkmark for “verified complete,” and no reserved marker for agent-owned or externally waiting work. Root reactions remain visible in the collapsed channel timeline, including on human-authored roots. This reduced the immediate scanning problem, but it is manual, not queryable, easy to let drift, and cannot express an accountable owner or the concrete unresolved ask.

Suggested acceptance criteria for the existing needs_action direction:

1. A signed per-thread work state distinguishes at least active, needs human, and complete without editing the root message.
2. The accountable agent or authorized steward can update the state even when another person authored the root.
3. The state is visible on collapsed channel roots and in the thread header, with clear selected/unread/status styling.
4. A Needs me view and count can filter actionable threads across channels and open directly to the unresolved request.
5. Every needs-human state identifies the requested person, accountable owner, concrete ask, and timestamp; answering or resolving it clears the item consistently.
6. Status changes are atomic, auditable, and protected from conflicting current states or stale counts.
7. Desktop and mobile have equivalent visibility and filtering.

This is compatible with #6067: a thread’s membership in a personal working set and its current attention state are related but separate dimensions.

[VenusOne-Lee]

Thank you for the field evidence — a 27-thread audit from a live channel is exactly the kind of data this proposal was missing, and the failure of the manual reaction convention (unqueryable, drifts, no owner, no concrete ask) matches the problem statement precisely. We accept all seven acceptance criteria. Here is how each maps to the current proposal, and the two places where they change the design.

Covered by the proposal as written:

• (3) Visibility on collapsed roots and thread headers — the rendering PR in the incremental series covers Inbox integration; extending the same projection output to collapsed channel roots and thread headers is additive UI work on the same data, not new architecture.
• (4) Cross-channel "Needs me" view with count and deep-link — this is the Inbox surface the proposal already targets. The projection extracts the unresolved ask with its source event, so deep-linking directly to the request is already available.
• (5) Requested person, accountable owner, concrete ask, timestamp; resolution clears the item — the projection is deterministic extraction over stored events, and resolutions are published as standard threaded replies, so clearing is derived from the same event stream that created the item. No side-channel state to drift.
• (7) Desktop/mobile parity — the library-first PR split keeps the projection logic in shared code. Desktop rendering lands first; we'd accept parity as a criterion with phased delivery, since mobile only needs to render the same projection.

Where the criteria sharpen the design (accepted, with proposed resolutions):

• (1) Signed per-thread state + (6) atomic, auditable transitions. The pure derived-projection approach is auditable by construction (recompute from the event log) but has no explicit signed state to be atomic about. Rather than staying derived-only, we'd complete the loop the issue already identifies: finish WF-08 so kind 46010 is actually emitted, add 46010 to the relay's required_scope_for_kind(), and treat signed 46010/40007 events as the explicit state layer, with the client-side projection as the reading layer over them plus ordinary replies. Conflicting states resolve deterministically (latest valid signed state per thread wins, by created_at with event-id tie-break), which also keeps counts consistent — they're computed from the projection, never stored.
• (2) Steward updates on roots they didn't author. This is an authorization question, and we'd propose the same trust model Buzz already uses for issue assignment: state operations signed by the thread's accountable owner or an authorized steward are trusted for others; anyone may set state on their own behalf. That rule lives in the projection's validation, so it's testable without relay changes.

On #6067: agreed — working-set membership and attention state are separate dimensions, and keeping attention state as signed events + projection means #6067 can compose with it rather than depend on it.

We'll fold criteria 1–7 into the acceptance section of the proposal and sequence the PRs as: WF-08 completion + relay scope fix, projection library, rendering (roots/headers/Needs-me), navigation. The fork's existing unit and Playwright coverage will be adapted to assert each criterion explicitly.