An attention inbox: refusals and stalls, surfaced instead of waited on

[anygivenfriday]

What this changes

A boundary refusal or a stalled run is recorded and then waits for a person to happen to look — at
the right channel, or at the audit page only an administrator has. The trail knows; nobody is told.

Attention, in the sidebar for everybody, lists the refusals (computer.action_refused,
mcp.call_rejected) and stalls (agent.stream_stalled) nobody has handled yet, scoped per item to
the Bots this person may use via the same canUseBot the roster and the computer use — an
administrator sees everything the way they see every Bot. A count badge draws only when nonzero.
Marking an item handled clears it for everyone and records who did.

It is a view over the trail, not a second record of it. Those rows are already written
transactionally by the gateway and the stall guard, so the inbox cannot miss one: no dual write to
drift, nothing new on the action path, and the append-only trail untouched. The only state it owns
is the resolution — one table (attention_resolutions), ids by value with no foreign keys, for the
trail's own documented reason (core.ts, actorUserId).

Deliberately not under /api/admin: the audit page is the administrator looking back; the inbox is
the working person being told now.

One subtlety worth review attention: which Bot a row is about is not where it looks. A tool
rejection's target is the tool — targetType: "mcp_tool", targetId the ref — and its Bot
travels only in the payload. Reading targetId unconditionally called a refusal's Bot
google-drive/search_files, which canUseBot correctly denies, which hid every tool rejection from
exactly the person it was for. botOf reads targetId only for computer and agent rows, and a
row that cannot name its Bot is dropped rather than shown to everybody.

Where it runs

• New state that outlives a request? One table, attention_resolutions
  (audit_event_id unique, resolved_by, resolved_at), migration 0016. Nothing held in
  process; the view is computed per request.
• What happens on the second replica? The same answer: both compose the same trail and the
  same resolutions from Postgres. A resolution written on one replica is subtracted by the
  other's next read.
• Anything serialised? Resolving. By unique index + onConflictDoNothing, not
  check-then-write: the second writer's insert conflicts and it reads back who won —
  alreadyResolved: true with the standing attribution.
• Anything fanned out to a browser? No. The app polls at 15s with refetch-on-focus, the
  same shape as the existing grant polls. A push upgrade over the channel socket is a natural
  follow-up and deliberately not in this PR.
• New listener, port, or schedule? None.

Boundary and audit

• Every acting call still goes through the gateway — nothing here acts.
• New refusals and new failures each write a row — none are created; the inbox reads the rows
  the gateway and stall guard already write. Resolution attribution (who, when) is recorded in
  its own table.
• Nothing new is trusted from the client — the only client input is an event id, answered from
  the server's own trail; a made-up id and a row of another kind answer the same 404, so the
  endpoint cannot probe what the trail holds.

Changelog

• One entry under Unreleased.

Proof

Unit (attention-view.test.ts, 7 cases): the gateway's own refusal reason used whole; the tool
rejection's Bot read from the payload, never the ref; a Bot-less row dropped rather than shown to
everybody; resolved rows subtracted; foreign event types ignored. Integration
(attention-store.integration.test.ts): the resolve race — first writer wins, second told who —
and resolvedAmong answering exactly the resolved subset.

Suites: server 1088 pass / 0 fail; app 158 pass, tsc clean, production build clean.

Live, against a deployment whose trail held real mcp.call_rejected rows:

GET /api/attention                 → 8 items, each naming its Bot and the decision's own sentence
POST .../resolve                   → {resolvedBy: "dev-local-user", alreadyResolved: false}
POST .../resolve (again)           → {resolvedBy: "dev-local-user", alreadyResolved: true}
GET /api/attention                 → 7 items; the resolved id absent
POST .../<random uuid>/resolve     → 404

In the browser: sidebar shows "Attention · 8"; pressing Resolve on a row drops the list to 7 and
the badge follows through invalidation.

[anygivenfriday]

Re-landing the attention inbox?

Thanks for merging this — and for the cleanup in #278 that I made necessary. Two things there were mine to own: eight files landed unformatted against the pinned biome (I formatted with defaults, not the repo's version — my later PRs will run bun x biome check against the lockfile version before pushing), and the positional attentionStore argument was exactly the kind of slot-shift fragility that then bit your endpoint test on the routines branch. Fair cost, cleanly handled on your side.

Reading the revert commit, it looks procedural — keeping the migration chain honest while routines landed — rather than a verdict on the feature itself. If a re-land is welcome, I'd bring it back as a fresh PR with: the migration regenerated at the current head of the chain (after 0023), the whole tree formatted with the pinned biome, and the createApp wiring done so a hand-built argument tuple can't mis-slot it — happy to take direction on whether you'd rather see that as an options object or just the test updated.

If the revert was a design objection instead, I'd rather hear it before writing code. Either answer is useful.