Surface recorded failures in a notification bell (Review Flow PR 4)

[EthanHealy01]

Review Flow PR 4 of 5. Stacked on #7477. Recorded failures appear in a notification bell, showing each reader the failures they are allowed to see and the actions they can actually take.

Scope is deliberately viewing and triage only. Resolving a failure — retry, decrypt-and-retry — is #7479.

What's added

A notification bell in the editor and the processor shell. Polls GET /api/v1/notifications every 30 seconds, shows an unread badge, and lists open failures newest first. Each row shows the failure's title, its message with Copy error and Show full message chips, an occurrence count, and its available actions.

A notification API (stirling.software.proprietary.notification), derived from failures on read rather than stored in its own table:

Route	Purpose
GET /api/v1/notifications	the caller's open failures, newest first
POST /api/v1/notifications/{id}/actions/{actionId}	apply an offered action
POST /api/v1/notifications/{id}/resolved	record that a client-side retry worked

Every id is prefixed (failure:<uuid>); none of these routes accepts a raw failure id.

Per-reader actions. A FailureKind declares each action with an audience (OWNER, TEAM_REVIEWER, ANYONE_WHO_SEES). The server resolves that against the reader and derives Ownership (MINE / THEIRS / UNOWNED) from the row's actor, so an admin reviewing someone else's failure is not offered a document their browser does not hold. Adding a failure kind requires no frontend change.

Server-run and client-run actions are distinguished. FailureActionId carries an Execution facet; the registry requires a bean only for server actions, and dispatching a client action returns 400.

Actions available on this PR: View file (opens the document in the editor), View in processor (dev builds only), Dismiss. The server also declares Retry and Decrypt and retry on the password-protected kind; this build wires no handler for them, so the bell skips them rather than rendering a dead button. #7479 adds the handlers.

Attended policy runs record their document. POST /api/v1/policies/{id}/run accepts an optional opaque fileId, recorded when the run carries exactly one primary document. This is what lets a repeat fold onto one incident instead of opening a new one per upload, lets deleting the file clear its failure, and lets the owner open the document from the row.

A RESOLVED status transition, system-set when a client-side retry succeeds.

Behaviour changes

• The bell re-reads as soon as a failure you caused is recorded, rather than leaving you to wait out a poll interval for news of your own upload. Applies to a failed tool run and to a policy run reaching FAILED. Other people's failures still arrive on the poll, which is what it is for.
• An action the reader cannot use is not rendered. Where the server gave a reason for withholding it, that reason appears as the row's one-line note. An action that was never offered to that reader produces no note.
• The failures list in /processor/documents stays behind import.meta.env.DEV, and View in processor is gated to match so it cannot navigate to a section that is not mounted. Both lift when failures get their own review screen.
• One poll for all bells. The bell is mounted in three places; the list, document lookups and read marker are shared, so mounting more than one does not multiply requests.
• ACKNOWLEDGE is no longer offered by any kind. The id, bean and status remain so existing rows stay readable.

Known limits

• The poll does not pause when the tab is hidden.
• No retention or per-team cap on file_run_events.

How to test

Needs a proprietary or SaaS build with login enabled. task dev:all, then sign in.

1. Create a failure. Add a password-protected PDF to the editor and choose Skip for now when it asks to unlock. The upload starts a policy run that fails on it.
2. Watch the bell. The badge should appear within a second or two, not after 30 — this is the refresh-on-failure path. Open it: a row titled "Password-protected document" with the error message and the two chips.
3. The buttons should be View file, View in processor and Dismiss. Decrypt and retry is absent by design: the server offers it, this build has no handler, so it is skipped rather than shown dead.
4. View file closes the panel and selects that document in the editor.
5. Dismiss removes the row. In DevTools the request is POST /api/v1/notifications/failure%3A<uuid>/actions/DISMISS — note the prefixed id.
6. Confirm the local-document probe. Create a second failure, then delete that file from the editor and reload. That row now reads "This document is not on this device..." and loses View file, while a row whose document is still present keeps it.
7. Confirm attribution end to end. Sign in as a plain member, run a shared policy on your own upload so it fails. The member sees their own row in the bell. Sign in as the team leader: they see it too, but without View file, because the document is not in their browser.
8. Confirm folding. Add the same locked PDF again and skip again. The existing row's occurrence count increases rather than a second row appearing.
9. Confirm one poll for many bells. Open the editor and the processor in two tabs. Each tab issues its own poll, but within a tab the several mounted bells share one — the Network tab should show one GET /api/v1/notifications per 30s per tab, not three.

Migration

None. No new column and no new value in any CHECK-constrained enum; CheckConstrainedEnumsTest fails if that changes.

[aikido-pr-checks]

noteFor returns "not on this device" when isResolvableHere(notification) is true, which inverts the condition and can show the opposite reason to users.

Suggested change

	return isResolvableHere(notification)
	return !isResolvableHere(notification)

Details

✨ AI Reasoning
​The function builds explanatory notes for why actions are unavailable. After ruling out non-owned rows, local-file-present rows, and missing file ids, it decides whether to show a "not on this device" message. That message is currently returned when the predicate indicates resolvability in the current environment, which contradicts the meaning of the text being shown. This creates a path where users receive the opposite explanation from the actual condition.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}

[github-actions]

🚀 V2 Auto-Deployment Complete!

🔗 Direct Test URL (non-SSL) http://54.175.155.236:7478

🧩 Admin portal included - try it at http://54.175.155.236:7478/portal.

This deployment will be automatically cleaned up when the PR is closed.

🔄 Auto-deployed for approved V2 contributors.