rcf-lite 0.20.0 → 0.22.0

package/blueprints/application-notifications-in-app/contributions/adrs/adr-2103-application-notifications-in-app-retention-window.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-2103-application-notifications-in-app-retention-window",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Ship a thirty-day notification-centre retention window by default, elicited overrides",
+  "context": "The notification centre inbox needs a retention boundary: a shelf that keeps every notification forever grows unbounded and a shelf that keeps only the last few days loses the operator's audit trail on a slow-cadence surface. Different applying projects have different memories: a payments platform retains six months; a status-page dashboard retains one week; a consumer product retains thirty days. The problem is picking a shipped default that is honest for the typical case and letting the operator elicit their own.",
+  "decision": "The shipped retention window is thirty days: `manifest.blueprints[application-notifications-in-app].appliedParameters.retentionDays` defaults to thirty. The centre reads the delivery log filtered to `deliveredAt >= now - retentionDays`; rows older than the window remain in the log (write-side truncation is the applied `logging` companion's concern) but do not surface in the centre. Operators elicit a longer or shorter window at apply; the elicited value lands on the manifest and the centre uses it. A window below one day is refused at apply (an inbox that clears every day is not an inbox).",
+  "consequences": "Applying projects get a mid-cycle default that matches the most common operational tempo; long-retention projects and short-retention projects elicit their own. The write-side truncation staying on the `logging` companion keeps this blueprint's concern at the surface, not the store; the applying project picks a log store per its `logging` companion pin and the notifications blueprint stays store-agnostic.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship one week by default",
+      "summary": "Default retention is seven days.",
+      "reasonNotChosen": "Seven days is honest for a high-cadence surface but clears too fast for a project with a weekly reporting cycle; the operator opens the centre on Monday and finds nothing from the prior week."
+    },
+    {
+      "name": "Ship six months by default",
+      "summary": "Default retention is one hundred and eighty days.",
+      "reasonNotChosen": "Six months at typical notification volume produces an inbox the operator cannot skim; the retention becomes a browse problem, not a review problem. A project that really needs six months elicits it."
+    }
+  ],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/requirements/application-notifications-in-app-req-001.json

@@ -0,0 +1,15 @@
+{
+  "reqId": "application-notifications-in-app-REQ-001",
+  "prdId": "PRD-001",
+  "title": "The application shell preseeds the polite and assertive live-region wrappers on every declared route before any notification fires",
+  "description": "Every route the applying project declares under its navigation model renders with the two live-region wrappers already present in the DOM at page load: a `[aria-live=\"polite\"]` wrapper for informational messages and a `[role=\"alert\"]` wrapper for assertive alerts. Both wrappers exist and are empty before any notification fires; a wrapper inserted lazily after the first event is a defect that produces a screen-reader miss per the Sara Soueidan normative guidance on ARIA live regions. The wrappers carry stable `data-live-region=\"polite\"` and `data-live-region=\"assertive\"` attributes so the pack can enumerate them by data-id (not by role attribute alone, per the T-3 gate discipline).",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "The WAI-ARIA 1.2 live-regions normative contract requires the container to exist in the DOM before content is inserted; a wrapper inserted at the same tick as the content races the screen-reader announcement pass and the message is silently lost. Preseeding the two wrappers on every route is the runtime discipline that turns the WCAG 4.1.3 status-message clause from a design intent into a runtime-observable check the probe pack can drive.",
+  "tags": ["blueprint:application-notifications-in-app", "category:01-live-region-preseeding"],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/requirements/application-notifications-in-app-req-002.json

@@ -0,0 +1,15 @@
+{
+  "reqId": "application-notifications-in-app-REQ-002",
+  "prdId": "PRD-001",
+  "title": "A transient toast maps its priority to a live-region role, announces exactly once, and dismisses on operator activation or timeout",
+  "description": "A notification surfaced as a transient toast writes into one of the two preseeded live regions based on its priority per ADR-2101: an informational priority renders into the polite wrapper and carries `role=\"status\"`, an error priority renders into the assertive wrapper and carries `role=\"alert\"`. The toast body appears in exactly one wrapper text update (the one whose role reflects the priority) and never in both. Every toast is dismissible in two ways: an operator activation on the toast's dismiss control, and a timeout at or above the ADR-2102 floor (six seconds baseline per WCAG 2.2.1 Timing Adjustable, elicited overrides above the floor). The toast records `data-shown-at` and `data-dismissed-at` timestamps on its DOM element so a probe can measure the actual timeout against the floor without sleeping in the pack.",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "The WCAG 4.1.3 status-message clause and the ARIA APG alert pattern name the priority-to-role mapping as the accessibility discipline that lets a screen reader distinguish a passive confirmation (polite queue) from an assertive interruption (assertive queue). The WCAG 2.2.1 Timing Adjustable clause names six seconds as the floor for a message a reader can dwell on; a timeout below the floor is a comprehension defect. Recording the shown and dismissed timestamps on the DOM element makes both rules observable at runtime without a race-prone sleep in the pack.",
+  "tags": ["blueprint:application-notifications-in-app", "category:02-toast-contract"],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/requirements/application-notifications-in-app-req-003.json

@@ -0,0 +1,15 @@
+{
+  "reqId": "application-notifications-in-app-REQ-003",
+  "prdId": "PRD-001",
+  "title": "The notification centre inbox lists the last N days of notifications and each acknowledge control round-trips to the server",
+  "description": "The applying project renders a notification-centre route (default `/notifications-centre`, operator-elicited) whose inbox surface lists the notifications delivered in the last N days per the ADR-2103 retention window (default thirty days, elicited). Each notification carries a stable `data-notification-id` attribute the pack enumerates by (never by a role attribute alone, per the T-3 gate discipline), and each carries a keyboard-reachable acknowledge control (`[data-action=\"acknowledge\"]`) plus a mark-read control (`[data-action=\"mark-read\"]`); the surface offers one mark-all-read control (`[data-action=\"mark-all-read\"]`) reachable in reading order. Activating the acknowledge control POSTs an acknowledge request to the applying project's server, the server responds, and the DOM updates in response: the notification's `data-acknowledged` reads `true` after the round-trip. Every item is Tab-reachable from the start of the surface without a mouse.",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "A transient toast is not a system of record; the notification centre is. Making the centre the operator's inbox with a retention window and per-item acknowledge round-trip is what turns a fleeting on-screen message into a durable one the operator can return to and confirm. Enumerating items by `data-notification-id` rather than by `role=\"listitem\"` on the container follows the T-3 gate discipline: a role attribute the primary element carries alone does not enumerate multiple children; a per-element data attribute does.",
+  "tags": ["blueprint:application-notifications-in-app", "category:03-centre-inbox"],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/requirements/application-notifications-in-app-req-004.json

@@ -0,0 +1,15 @@
+{
+  "reqId": "application-notifications-in-app-REQ-004",
+  "prdId": "PRD-001",
+  "title": "The preferences UI exposes per-user category silence and delegates digest opt-in to the sibling channels",
+  "description": "The applying project renders a preferences surface (default `/notifications-preferences`, operator-elicited) that carries one section per operator-elicited notification category with a labelled silence toggle (`[data-preference-category=\"<category>\"]` on the toggle's `<input>` or `<button>` control), and one section per sibling channel (`-email`, `-push`, `-webhook`) with a digest opt-in control recording the operator's intent on `data-digest-<channel>`. This blueprint ships no transport: the digest opt-in records the intent on the surface, and the applying project's sibling blueprint (once shipped) reads the intent from the preferences store and drives its own delivery. A preferences surface that promises a digest without a corresponding sibling blueprint applied is a defect the applying project surfaces via a `[data-preference-status]` label reading `\"sibling not applied\"`.",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "Per-user category silence is the operator's primary knob on notification fatigue: a labelled toggle per category gives the reader an accountable choice without overloading the transport. Delegating digest opt-in to the sibling channel keeps this blueprint at the in-app surface it names (per Baz decision 2026-09-04: 'we might support more types of notifications - be clear in the name what these ones are'); a digest is a transport concern the sibling blueprint owns.",
+  "tags": ["blueprint:application-notifications-in-app", "category:04-preferences"],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/requirements/application-notifications-in-app-req-005.json

@@ -0,0 +1,15 @@
+{
+  "reqId": "application-notifications-in-app-REQ-005",
+  "prdId": "PRD-001",
+  "title": "The delivery-attempt log records one row per surfaced notification with the operator-readable fields for later inspection",
+  "description": "Every notification the shell surfaces (as a toast, in the notification centre, or both) appends one row to the delivery-attempt log. Each row carries `notificationId`, `category`, `priority`, `deliveredAt` (ISO-8601 timestamp of the surface event), and the optional acknowledgement trail: `dismissedAt` when the operator dismissed the toast, `acknowledgedAt` when the operator activated the centre's acknowledge control. The log is operator-readable via a `GET /api/delivery-log` endpoint the applying project exposes; the endpoint returns JSON in the shape `{ rows: [...] }`. The log is append-only; a row is never rewritten, only augmented (a `dismissedAt` or `acknowledgedAt` may land on a later request). Records write through the applied `logging` companion's factory so the log's persistence and retention layer is the companion's, not this blueprint's.",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "A delivery-attempt log is the operator's audit trail for what the shell has said and when, alongside a second row per acknowledgement event. Ownership of the row shape lives on this blueprint; ownership of the persistence layer lives on the applied `logging` companion (per REQ-005 factory delegation). Splitting the two lets the applying project pick a log store per its `logging` companion pin without the notifications blueprint dragging in a store of its own.",
+  "tags": ["blueprint:application-notifications-in-app", "category:05-delivery-log"],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/tacs/tac-2101-application-notifications-in-app-live-region.json

@@ -0,0 +1,46 @@
+{
+  "tacId": "TAC-2101-application-notifications-in-app-live-region",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Live-region wrappers, transient toast rendering and the priority-to-role mapping",
+  "purpose": "Owns the shell's live-region contract: the polite and assertive wrappers preseeded on every declared route, the transient-toast factory that writes into one wrapper per ADR-2101's priority-to-role mapping, and the timeout floor per ADR-2102. The wrappers are the substitutable interface every notification announcement flows through; the pack asserts on their presence, their emptiness at load, and the disjoint-content rule (AC-20101-1, AC-20102-1, AC-20108-1).",
+  "responsibilities": [
+    "Emit both live-region wrappers into the DOM at first render and keep them mounted for the app lifetime: a `[aria-live=\"polite\"] [data-live-region=\"polite\"]` wrapper for informational messages and a `[role=\"alert\"] [data-live-region=\"assertive\"]` wrapper for assertive alerts; both empty at load (AC-20101-1).",
+    "Render a toast on `renderToast({ priority, body })` into exactly one wrapper: `info` priority into the polite wrapper with `role=\"status\"`, `error` priority into the assertive wrapper with `role=\"alert\"` (AC-20102-1, AC-20102-2).",
+    "Record `data-shown-at` and `data-dismissed-at` timestamps on the toast's DOM element so the pack measures the actual timeout against the ADR-2102 six-second floor without sleeping (AC-20102-1).",
+    "Dismiss every toast in two ways: an operator activation on the toast's `[data-action=\"dismiss\"]` control, and a scheduled timeout that fires at or above the ADR-2102 floor (AC-20102-1).",
+    "Enforce the disjoint-content rule: no toast body appears in both wrappers simultaneously; a background event and an operator-driven event both flow through the same factory (AC-20107-1, AC-20108-1)."
+  ],
+  "internalStructure": "One live-region factory (`renderLiveRegions`) mounted at first render owning the two wrapper elements. One toast factory (`renderToast`) that resolves the priority-to-role mapping per ADR-2101, mounts the toast DOM inside the correct wrapper, records the two timestamp attributes, and schedules the dismissal timer per ADR-2102. Dismissal on activation and dismissal on timeout share one dismiss code path so the timestamp update is single-sourced.",
+  "interfaces": [
+    {
+      "name": "renderLiveRegions",
+      "kind": "factory",
+      "description": "renderLiveRegions({ rootElement }) -> void. Mounts the two live-region wrappers into `rootElement` at first render if they are not already present. Idempotent across route changes: identity of the two wrappers is stable across the app lifetime (AC-20101-2)."
+    },
+    {
+      "name": "renderToast",
+      "kind": "factory",
+      "description": "renderToast({ priority: 'info' | 'error', body: string, category: string, notificationId: string }) -> void. Mounts the toast DOM inside the wrapper the ADR-2101 mapping resolves to, records `data-shown-at`, schedules the ADR-2102-floored dismissal, and records `data-dismissed-at` on dismissal. Every toast surface event writes a delivery-log row through TAC-2102's `writeDeliveryRow`."
+    },
+    {
+      "name": "priorityToRoleContract",
+      "kind": "shape",
+      "description": "The ADR-2101 mapping: `info` maps to `{ wrapper: 'polite', role: 'status' }`; `error` maps to `{ wrapper: 'assertive', role: 'alert' }`. A priority outside the ADR-2101 enum is refused at project-side review."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Delivery-log write factory",
+      "kind": "tac",
+      "tacId": "TAC-2102-application-notifications-in-app-centre",
+      "description": "Every toast the live-region factory emits records a delivery-log row through TAC-2102's `writeDeliveryRow`; ownership of the row shape lives here through the delegating call, ownership of the persistence layer lives on TAC-2102 and the applied `logging` companion."
+    }
+  ],
+  "tradeoffs": "The two-wrapper contract is opinionated: some designs use one wrapper per notification kind (informational, error, warning, success) with four ARIA politeness levels. This TAC insists on two wrappers because the WCAG 4.1.3 status-message clause and the ARIA APG alert pattern jointly draw the line at polite vs assertive; adding wrapper granularity that assistive technologies do not distinguish trades runtime discipline for false precision. The six-second timeout floor is deliberately not a ceiling: an elicited override raises the floor but never lowers it, so a design that shows a toast for two seconds fails at author-side review.",
+  "notes": "Known mechanism-reach gap: the pack asserts the disjoint-content rule (AC-20108-1) at the moment it inspects the wrappers, not continuously across the toast lifetime. A pathological implementation that briefly writes into both wrappers between two microtasks would not be caught by the pack; project-side review carries the residual. A v1.1 minor bump could add a MutationObserver-based check.",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/tacs/tac-2102-application-notifications-in-app-centre.json

@@ -0,0 +1,52 @@
+{
+  "tacId": "TAC-2102-application-notifications-in-app-centre",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Notification centre inbox, retention window, acknowledge round-trip and delivery-attempt log",
+  "purpose": "Owns the shell's persistent notification-centre inbox: the centre route the applying project mounts (default `/notifications-centre`, elicited), the retention window contract per ADR-2103 (default thirty days, elicited), the per-item acknowledge round-trip that POSTs to the applying project's server and updates the DOM on the response, and the delivery-attempt log write path per REQ-005. The centre is the durable inbox the operator returns to; the toast is the transient surface.",
+  "responsibilities": [
+    "Render one notification wrapper per delivery-log row within the ADR-2103 retention window. Every wrapper carries `data-notification-id` (per-element attribute the pack enumerates by, never `role=\"listitem\"` on the container alone per the T-3 gate discipline) (AC-20103-1, AC-20103-2).",
+    "Render one keyboard-reachable `[data-action=\"acknowledge\"]` control and one `[data-action=\"mark-read\"]` control per item; render exactly one `[data-action=\"mark-all-read\"]` control on the surface, reachable in Tab order after the item list (AC-20103-1).",
+    "On acknowledge activation, POST `POST /api/notifications/acknowledge` with the notification id, wait for the server response, and update `data-acknowledged` on the item to `true` on a 2xx response; a failed response surfaces an error toast via the TAC-2101 factory and the item's `data-acknowledged` remains unchanged (AC-20103-1).",
+    "On a page load with a backlog, render every backlog item on the surface without writing any body text into the polite or assertive live-region wrapper (AC-20106-1).",
+    "Expose the delivery-log write factory `writeDeliveryRow` the TAC-2101 toast factory and this TAC's centre factory both call; every write goes through the applied `logging` companion's record factory (AC-20105-2).",
+    "Expose the delivery-log read endpoint `GET /api/delivery-log` returning `{ rows: [...] }` where every row carries `notificationId`, `category`, `priority`, `deliveredAt`, optionally `dismissedAt`, optionally `acknowledgedAt`; rows are append-only (AC-20105-1)."
+  ],
+  "internalStructure": "One centre-route module reading the delivery-log endpoint filtered to the retention window and rendering one wrapper per row through a shared item factory. One acknowledge-round-trip helper that owns the POST plus the DOM-update code path. One delivery-log write helper (`writeDeliveryRow`) that adapts the shell-side row shape to the applied `logging` companion's record factory.",
+  "interfaces": [
+    {
+      "name": "renderCentre",
+      "kind": "factory",
+      "description": "renderCentre({ rootElement, retentionDays, deliveryLogUrl }) -> Promise<void>. Reads the delivery log filtered to the retention window and mounts one wrapper per row into `rootElement`. Idempotent on the same log state."
+    },
+    {
+      "name": "writeDeliveryRow",
+      "kind": "factory",
+      "description": "writeDeliveryRow({ notificationId, category, priority, deliveredAt, dismissedAt?, acknowledgedAt? }) -> Promise<void>. Writes one row through the applied `logging` companion's record factory. Called from TAC-2101's toast factory on a toast surface event and from this TAC's centre-item activation on an acknowledge event."
+    },
+    {
+      "name": "acknowledgeRoundTrip",
+      "kind": "function",
+      "description": "acknowledgeRoundTrip({ notificationId }) -> Promise<{ ok: boolean }>. POSTs `POST /api/notifications/acknowledge` and returns the parsed server response. A 2xx flips `data-acknowledged` on the item; a non-2xx surfaces an error toast through TAC-2101."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Live-region factory (surface for acknowledge failures)",
+      "kind": "tac",
+      "tacId": "TAC-2101-application-notifications-in-app-live-region",
+      "description": "The centre surfaces acknowledge failures as error toasts through the live-region factory; the wrapper contract per REQ-001 and REQ-002 holds on the centre surface as much as on any other route."
+    },
+    {
+      "name": "Applied logging companion",
+      "kind": "external",
+      "description": "The delivery-attempt log's persistence layer is the applied `logging` companion's; this TAC delegates the write path. A project applying this blueprint without a `logging` companion (neither applied nor registered library nor core shelf) sees the delivery-log endpoint returning an empty rows array, which fails project-side review."
+    }
+  ],
+  "tradeoffs": "The centre reading through the delivery log (rather than a separate inbox store) keeps the shell single-sourced on the applied `logging` companion but couples the surface latency to the log query; a project with a very high notification volume may want to project a materialised inbox view alongside the log. This TAC accepts the coupling because it collapses two writers of the same row into one; a project that needs the materialised view supersedes with a project-authored REQ.",
+  "notes": "Known mechanism-reach gap: the pack asserts one acknowledge round-trip on one item (AC-20103-1); the mark-read control, the mark-all-read control and the retention-window boundary (a row on day 31 must not surface) are runtime-observable ACs the shipped pack does not itself drive. The README names them individually per the T-1 gate discipline; a v1.1 minor bump could add checks for each.",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/tacs/tac-2103-application-notifications-in-app-preferences.json

@@ -0,0 +1,40 @@
+{
+  "tacId": "TAC-2103-application-notifications-in-app-preferences",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Per-user preferences UI, category silence and sibling-channel delegation",
+  "purpose": "Owns the preferences surface where the operator silences notification categories and opts into (or out of) digest delivery on each sibling channel. This blueprint ships no transport: the digest opt-in records the operator's intent on the surface for a sibling blueprint to read. The preferences UI is the operator's single knob on notification fatigue.",
+  "responsibilities": [
+    "Render the preferences route (default `/notifications-preferences`, elicited). Render one section per operator-elicited category with a labelled silence toggle whose control element carries `[data-preference-category=\"<category>\"]` (AC-20104-1).",
+    "On a silence-toggle activation, POST `POST /api/preferences/category` with the category and the new state, wait for the server response, and update `data-silenced` on the toggle to reflect the state (AC-20104-1).",
+    "Render one section per sibling channel (`-email`, `-push`, `-webhook`) with a `[data-preference-section=\"<channel>\"]` wrapper and a digest opt-in control. When no corresponding sibling blueprint is applied to the project, disable the control (`aria-disabled=\"true\"`) and label the section with `[data-preference-status=\"sibling not applied\"]` (AC-20104-2).",
+    "Elicit the notification categories at apply time; the elicited list is the source of truth for the per-category sections. A category rendered without an elicited entry is a defect."
+  ],
+  "internalStructure": "One preferences-route module reading the elicited categories from the applied manifest and rendering one section per category. One sibling-channel section module reading `manifest.blueprints[]` to detect applied siblings and disabling the digest control when the sibling is missing.",
+  "interfaces": [
+    {
+      "name": "renderPreferences",
+      "kind": "factory",
+      "description": "renderPreferences({ rootElement, categories, appliedSiblings }) -> void. Mounts the category-silence sections and the sibling-channel sections. `appliedSiblings` is the list of applied `application-notifications-*` blueprint slugs the applying project passes in from its manifest reader; today the list is empty and every sibling section renders disabled."
+    },
+    {
+      "name": "readPreference",
+      "kind": "function",
+      "description": "readPreference({ category }) -> Promise<{ silenced: boolean }>. Reads the current preference state for a category so the surface can render the initial toggle state. Called at first render; the returned state drives the initial `data-silenced` attribute value."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Live-region factory (surface for preference-update failures)",
+      "kind": "tac",
+      "tacId": "TAC-2101-application-notifications-in-app-live-region",
+      "description": "A preference update that fails at the server surfaces an error toast through TAC-2101."
+    }
+  ],
+  "tradeoffs": "Delegating digest opt-in to sibling blueprints keeps this blueprint's contract at the in-app surface (Baz decision 2026-09-04: 'be clear in the name what these ones are'). The trade-off is that on a project without any sibling channel applied the preferences surface renders disabled sibling sections; a first-time reader might expect the preferences UI to be silent about siblings that do not exist. This TAC ships the disabled section on the argument that the reserved family prefix (`application-notifications-`) is discoverable to the operator and the labelled disabled state names the residual honestly.",
+  "notes": "Known mechanism-reach gap: elicitation of the notification categories is a declarative field on the ADR-2101 elicited-parameters block; the runner has no apply-time elicitation phase today (w-2026-09-04-dave-022, built in T-5), so the applying project gathers the categories by hand at the apply pass. The README names this individually.",
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20101.json

@@ -0,0 +1,35 @@
+{
+  "usId": "application-notifications-in-app-US-20101",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The polite and assertive live-region wrappers are preseeded on every declared route before any notification fires",
+  "asA": "screen-reader user of a shipped rcf-lite application",
+  "iWant": "the polite and assertive live-region wrappers to be present in the DOM at page load on every route so that the first notification fires into a container the accessibility tree already tracks",
+  "soThat": "no informational or assertive message is silently lost by a race between the wrapper insertion and the content insertion, per the WAI-ARIA 1.2 live-regions normative contract",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20101-1",
+      "description": "Given a page load on any declared route, both live-region wrappers are preseeded in the DOM before any notification fires: the polite wrapper carries `aria-live=\"polite\"` and `data-live-region=\"polite\"` and is empty (no descendant text nodes) at page load; the assertive wrapper carries `role=\"alert\"` and `data-live-region=\"assertive\"` and is empty at page load. A wrapper inserted lazily after the first event, or a wrapper that carries content at page load, fails this AC. The pack enumerates wrappers by `[data-live-region]` (per-element attribute), not by `aria-live` or `role` alone.",
+      "given": "a page load on any declared route",
+      "when": "the initial DOM is read",
+      "then": "both preseeded wrappers are present, carry their id attribute, and are empty",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-20101-2",
+      "description": "Given the shell's live-region factory (TAC-2101 `renderLiveRegions`), a call at first render emits exactly two wrapper elements matching the AC-20101-1 shape and never re-creates them on subsequent renders (the wrappers are stable identity across the app lifetime). A factory that recreates the wrappers on a route change fails this AC at project-side review.",
+      "given": "the shell's live-region factory",
+      "when": "the factory is invoked at first render and again on a route change",
+      "then": "the same two wrapper elements are returned; identity is stable",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": ["TAC-2101-application-notifications-in-app-live-region"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20102.json

@@ -0,0 +1,35 @@
+{
+  "usId": "application-notifications-in-app-US-20102",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-002",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "A transient toast maps its priority to the polite or assertive slot, announces once, and dismisses on activation or timeout",
+  "asA": "screen-reader user reading a shipped rcf-lite application",
+  "iWant": "an informational toast to reach me on the polite queue and an error toast to reach me on the assertive queue, each announced exactly once and dismissable on my activation or after a WCAG-compliant timeout",
+  "soThat": "I can tell an interruption from a confirmation and I have time to read the message before it disappears",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20102-1",
+      "description": "Given a toast triggered by a background event with priority `info`, the toast renders inside `[data-live-region=\"polite\"]` and carries `role=\"status\"`; given priority `error`, the toast renders inside `[data-live-region=\"assertive\"]` and carries `role=\"alert\"`; every toast body text appears in exactly one wrapper (the one whose role reflects the priority) and never in both; every toast records `data-shown-at` and `data-dismissed-at` timestamps on its DOM element; the elapsed time between `data-shown-at` and `data-dismissed-at` on a toast that timed out (not clicked away) is at or above the ADR-2102 floor of six seconds. The pack enumerates toasts by `[data-toast-id]` inside the two wrappers (per-element attribute), not by `role` alone.",
+      "given": "a toast triggered by a background event",
+      "when": "the accessibility tree and the toast timestamps are read",
+      "then": "the priority-to-role mapping holds, the announcement is one-shot, and the timeout is at or above the six second floor",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-20102-2",
+      "description": "Given the toast factory (TAC-2101 `renderToast({ priority, body })`), the factory picks the polite wrapper for `info` priority and the assertive wrapper for `error` priority; a factory that writes into both wrappers on one call, or picks the wrong wrapper for a priority, fails at project-side review.",
+      "given": "the toast factory",
+      "when": "the factory is invoked at a given priority",
+      "then": "the correct wrapper receives the toast",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": ["TAC-2101-application-notifications-in-app-live-region"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20103.json

@@ -0,0 +1,35 @@
+{
+  "usId": "application-notifications-in-app-US-20103",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-003",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The notification centre inbox surfaces the last N days of notifications and every acknowledge control round-trips to the server",
+  "asA": "keyboard-only operator using a shipped rcf-lite application",
+  "iWant": "to reach every notification in the centre with Tab, mark items read, mark all read, and acknowledge each item with an activation that round-trips to the server and updates the item on the response",
+  "soThat": "I have a durable record of what the shell has said and my acknowledgement is recorded server-side rather than lost on a page reload",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20103-1",
+      "description": "Given the notification centre route with a seeded backlog of notifications, the surface lists every notification delivered within the ADR-2103 retention window (thirty days by default). Each notification carries `data-notification-id` on its wrapper element (pack enumerates by that per-element attribute, never by `role=\"listitem\"` on the container alone); each carries a Tab-reachable acknowledge control `[data-action=\"acknowledge\"]` and a Tab-reachable mark-read control `[data-action=\"mark-read\"]`; the surface carries exactly one mark-all-read control `[data-action=\"mark-all-read\"]`. Activating a per-item acknowledge control POSTs `POST /api/notifications/acknowledge` (recorded on `window.__notificationFetches` and at `GET /__requests`), the server responds `200 { ok: true }`, and the item's `data-acknowledged` reads `true` after the response.",
+      "given": "the notification centre with a seeded backlog",
+      "when": "an acknowledge control is activated by keyboard",
+      "then": "the acknowledge round-trips to the server and the DOM updates in response",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-20103-2",
+      "description": "Given the centre factory (TAC-2102 `renderCentre`), the factory reads the delivery-attempt log from REQ-005's endpoint and emits one wrapper per row within the retention window; a factory that emits rows older than the retention window, or that skips rows within the window, fails at project-side review.",
+      "given": "the centre factory",
+      "when": "the delivery log is read",
+      "then": "one wrapper is emitted per row within the retention window",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": ["TAC-2102-application-notifications-in-app-centre"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20104.json

@@ -0,0 +1,35 @@
+{
+  "usId": "application-notifications-in-app-US-20104",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-004",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The preferences UI carries one section per operator-elicited category with a labelled silence toggle and one section per sibling channel with a digest opt-in",
+  "asA": "operator of a shipped rcf-lite application",
+  "iWant": "a preferences surface where I can silence notification categories I no longer want and opt into a digest on a sibling channel that is applied",
+  "soThat": "I control my own notification fatigue without asking an admin to turn a category off system-wide",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20104-1",
+      "description": "Given the preferences route, the surface renders one section per operator-elicited category (each section carries a `[data-preference-section=\"category\"]` wrapper) with a labelled silence toggle whose control element carries `[data-preference-category=\"<category>\"]` and whose accessible name reads `\"Silence <category> notifications\"`. Activating a silence toggle records the preference at `POST /api/preferences/category` (visible on `window.__notificationFetches`); the server responds and the toggle's `data-silenced` reads `true`.",
+      "given": "the preferences route",
+      "when": "a silence toggle is activated",
+      "then": "the preference is recorded and reflected on the DOM",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-20104-2",
+      "description": "Given a preferences surface on a project that has NOT applied any `application-notifications-*` sibling channel blueprint, the digest opt-in section for each sibling channel renders with `[data-preference-status=\"sibling not applied\"]` and the digest opt-in control is disabled (`aria-disabled=\"true\"`); a preferences surface that offers a digest without a corresponding sibling applied is a defect. The pack does not itself drive this (no sibling channels exist on the shelf today); the AC is a mechanism-reach gap the README names for a v1.1 minor bump when the first sibling ships.",
+      "given": "a preferences surface on a project without a sibling channel applied",
+      "when": "the digest opt-in section is read",
+      "then": "the section is disabled and labelled as sibling not applied",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": ["TAC-2103-application-notifications-in-app-preferences"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20105.json

@@ -0,0 +1,35 @@
+{
+  "usId": "application-notifications-in-app-US-20105",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The delivery-attempt log records one row per surfaced notification with the operator-readable fields for later inspection",
+  "asA": "operator inspecting the notification behaviour of a shipped rcf-lite application",
+  "iWant": "one row in the delivery-attempt log per notification the shell surfaced, with the priority, the category and the delivery and acknowledgement timestamps",
+  "soThat": "I can reconcile what the shell said with what my operators saw and acknowledged",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20105-1",
+      "description": "Given a shipped surface that has surfaced N notifications, `GET /api/delivery-log` returns HTTP 200 with body `{ rows: [...] }` and `rows.length === N`; each row carries `notificationId` (string), `category` (string), `priority` (`\"info\"` or `\"error\"`), `deliveredAt` (ISO-8601 timestamp); a row for a dismissed toast additionally carries `dismissedAt`; a row for an acknowledged centre item additionally carries `acknowledgedAt`. Rows are append-only; a `notificationId` never appears twice on the same page load. The pack does not itself enumerate every row (the delivery log's persistence is delegated to the applied `logging` companion); the AC is a mechanism-reach gap for a v1.1 minor bump when the pack gains a log-shape probe.",
+      "given": "a shipped surface after N notifications",
+      "when": "the delivery-log endpoint is read",
+      "then": "N rows with the operator-readable fields are returned",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-20105-2",
+      "description": "Given the delivery-log write factory (TAC-2102 `writeDeliveryRow`), a call from the toast factory and a call from the centre factory both write through the applied `logging` companion's record factory (the row shape lives on this blueprint; the persistence layer lives on the companion). A row written outside the companion's factory bypasses the companion's retention and audit path and is refused at project-side review.",
+      "given": "the delivery-log write factory",
+      "when": "a toast or centre event surfaces a notification",
+      "then": "a row lands through the applied logging companion",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": ["TAC-2102-application-notifications-in-app-centre"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20106.json

@@ -0,0 +1,26 @@
+{
+  "usId": "application-notifications-in-app-US-20106",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-003",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "A page load on the notification centre with a backlog renders the backlog at load without re-announcing every notification into the polite queue",
+  "asA": "screen-reader user opening a notification centre with an existing backlog",
+  "iWant": "the backlog to appear on the surface at load without a flood of announcements into the polite live region",
+  "soThat": "opening the centre after a long absence does not saturate the assistive-technology announcement queue",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20106-1",
+      "description": "Given a page load on the notification centre route with a backlog of unacknowledged notifications from the retention window, the DOM contains one wrapper per backlog notification with `data-notification-id` on each; the polite wrapper `[data-live-region=\"polite\"]` remains empty at load (no backlog announcement); the assertive wrapper `[data-live-region=\"assertive\"]` remains empty at load. A centre implementation that pushes every backlog item into the polite queue on load is a defect.",
+      "given": "a page load on the centre route with a backlog",
+      "when": "the initial DOM and the live-region wrappers are read",
+      "then": "the backlog is rendered on the surface and neither live-region wrapper carries a load-time announcement",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": ["TAC-2102-application-notifications-in-app-centre"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20107.json

@@ -0,0 +1,26 @@
+{
+  "usId": "application-notifications-in-app-US-20107",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-002",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "A background event drives the same toast contract as an operator-driven event, with indistinguishable output on the accessibility tree",
+  "asA": "screen-reader user of a shipped rcf-lite application receiving notifications from server-side events",
+  "iWant": "a toast that arrives from a background push to render with the same role mapping, one-shot announcement, and timeout floor as an operator-driven toast",
+  "soThat": "my experience is consistent regardless of where the notification originated",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20107-1",
+      "description": "Given the sample-app fixture's `POST /__emit` endpoint or an in-page background dispatch, a toast surfaced with priority `info` renders in `[data-live-region=\"polite\"]` with `role=\"status\"` and a toast surfaced with priority `error` renders in `[data-live-region=\"assertive\"]` with `role=\"alert\"` (identical output to a toast surfaced through an operator-driven control). Both toasts record `data-shown-at` and `data-dismissed-at`; both dismiss at or above the six-second timeout floor unless clicked away.",
+      "given": "a background event surfacing a toast",
+      "when": "the toast DOM is read",
+      "then": "the priority-to-role mapping and the one-shot announcement match an operator-driven toast",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": ["TAC-2101-application-notifications-in-app-live-region"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20108.json

@@ -0,0 +1,26 @@
+{
+  "usId": "application-notifications-in-app-US-20108",
+  "prdId": "PRD-001",
+  "reqId": "application-notifications-in-app-REQ-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Every notification announcement lands in exactly one live region and the two wrappers never carry the same body simultaneously",
+  "asA": "screen-reader user of a shipped rcf-lite application",
+  "iWant": "each announcement to reach me on exactly one queue (polite for informational, assertive for error), never on both",
+  "soThat": "the assistive-technology announcement contract stays clean and I do not hear the same message twice from two queues",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-20108-1",
+      "description": "Given any surfaced notification (toast or centre), the notification's body text appears inside exactly one of `[data-live-region=\"polite\"]` or `[data-live-region=\"assertive\"]` at any moment; a notification whose body appears in both wrappers, or a notification whose body appears in the wrong wrapper for its priority (informational text in the assertive wrapper, or error text in the polite wrapper), is a defect. The pack asserts this by scanning both wrappers after each emission and confirming disjoint content.",
+      "given": "a surfaced notification",
+      "when": "both live-region wrappers are read simultaneously",
+      "then": "the body text appears in exactly one wrapper",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": ["TAC-2101-application-notifications-in-app-live-region"],
+  "tags": ["blueprint:application-notifications-in-app"],
+  "createdAt": "2026-09-04T23:59:00Z",
+  "updatedAt": "2026-09-04T23:59:00Z"
+}

package/blueprints/application-notifications-in-app/docs/topics.md

@@ -0,0 +1,46 @@
+# application-notifications-in-app: coordination vocabulary
+
+## Global topics
+
+The blueprint claims no new global topics at v1.0.0. The in-app-notifications contract is a composed application shape; every ADR (priority-to-role mapping, toast timeout floor, centre retention window) is non-global.
+
+## Deliberately unclaimed topics
+
+- `notificationsChannel` (the channel this blueprint owns). Not a global topic; the family-prefix reservation is the discoverable coordination mechanism (see below). A future blueprint that composes across all in-app-adjacent channels (a shared preferences store, for instance) would either share TAC-2103 or supersede this blueprint.
+- `livingRegionMapping` (the priority-to-role mapping). Reserved for the applying project as the ADR-2101 decision, not a global topic; a project that supersedes the mapping authors its own ADR.
+
+## Family-prefix reservation
+
+The `application-notifications-` prefix is reserved for the sibling channel blueprints the shelf will grow into: `-email`, `-push`, `-webhook`. This is a doc-only reservation in v1.0.0 (per spec Q3 default). No sibling channel ships in this round. See the family-prefix row in the shelf band registry below and the blueprint README's "Family-prefix reservation" section.
+
+## Shelf id band and suffix block
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| application-datatable | 17101-17899 | 18xx | shipped v1.0.0 | none |
+| application-charts | 18101-18899 | 19xx | shipped v1.0.0 | none |
+| application-dashboard | 19101-19899 | 20xx | shipped v1.0.0 | none |
+| application-notifications-in-app | 20101-20899 | 21xx | shipped v1.0.0 | none |
+| application-admin-console | 21101-21899 | 22xx | shipped v1.0.0 | none |
+| application-empty-error-states | 22101-22899 | 23xx | shipped v1.0.0 | none |
+| application-file-upload | 23101-23899 | 24xx | shipped v1.0.0 | none |
+| application-forms-wizard | 24101-24899 | 25xx | shipped v1.0.0 | none |
+| application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
+| application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
+| persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| application-notifications-email (reserved) | to be claimed at ship | to be claimed at ship | name-only doc reservation (not shipped) | tba |
+| application-notifications-push (reserved) | to be claimed at ship | to be claimed at ship | name-only doc reservation (not shipped) | tba |
+| application-notifications-webhook (reserved) | to be claimed at ship | to be claimed at ship | name-only doc reservation (not shipped) | tba |
+
+The shelf-wide band registry lives in `packages/rcf-lite/docs/blueprint-authoring.md` section 5.
+
+## Probe pack
+
+`probe-packs/application-notifications-in-app.pack.mjs` ships three checks anchored to blueprint AC ids:
+
+- `AC-20101-1` live-region preseeding on every declared route (both wrappers present AND empty at load)
+- `AC-20102-1` transient toast contract with priority-to-role mapping and timeout measured against the six-second WCAG 2.2.1 floor
+- `AC-20103-1` centre acknowledge round-trip enumerated by `data-notification-id`, reconciled through client and server request logs
+
+Every check carries a `description` field per spec section 9. `appliesTo` binds `TAC-2101-application-notifications-in-app-live-region` OR any FBS route matching `notifications-centre`. See `probe-packs/application-notifications-in-app.pack.mjs` for the source; see `packages/rcf-lite/test/fixtures/probe-pack-application-notifications-in-app/README.md` for the sample-app fixture and the four negative-run break switches.