rcf-lite 0.19.0 → 0.21.0

package/CHANGELOG.md

@@ -6,6 +6,44 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.21.0] - 2026-09-05
+
+rcf-lite 0.21.0 adds five visual-feature blueprints to the shelf (data table, charts, dashboard with packaged design guidance, in-app notifications, admin console) and the mechanism that proves them: a blueprint can now ship a Playwright probe pack that rcf verify runs against your running app in a real browser, and the ship gate refuses while a surface check fails. The admin console only offers the surfaces your applied auth blueprint can support. Blueprints can now ask you questions at apply time. The schema floor moves to rcf-schemas 0.6.1.
+
+
+### Added
+
+- **Visual round T-5: capability-declaration mechanism and application-admin-console v1.0.0 blueprint on the shelf (spec 2026-09-04 sections 5.5, 5.5.1, 5.5.2, w-2026-09-04-dave-015).** Introduces the capability-declaration mechanism as three additive optional top-level fields on `blueprint.json`: `capabilities[]` (a non-empty array of lower camelCase strings on `^[a-z][a-zA-Z0-9]*$`, matching the section 6a role naming convention; an identity blueprint declares what it provides), `elicits[]` (each entry `{id (kebab), prompt (no em-dash, no emoji), kind (enum|string|boolean), default?, options? (for kind=enum), when? (predicate on applied capabilities)}` for apply-time answers), and `requiresAppliedCapabilities` (`{capabilities (non-empty camelCase array), allowSkipFlag (kebab CLI flag name), refusalMessageId (string mapping to a bundled message template)}`). Loader validates shape only; the vocabulary lives in `packages/rcf-lite/docs/blueprint-authoring.md` section 6a as a chunk-zero-style table (`principalDirectory`, `roleModel`, `tenancy`, `auditLog`), extended alongside the roles registry. The apply verb discovers applied capabilities via source read-back on `manifest.blueprints[].source` (the applied-blueprint-record schema in rcf-schemas is closed under `additionalProperties:false`; the T-2 core-companions gate's source-read-back precedent applies here); the discovered union is persisted, together with `appliedElicitations` and (when overridden) `allowNoAuthYet` plus a `notes` string, into a per-project sidecar file at `rcf/blueprints/${slug}.applied.json`. The refusal gate returns a new `requiresAppliedCapabilities` rcfError kind; the CLI translates it to exit 3 with the spec 5.5.1 verbatim message printed on stderr (no `[error]` prefix), naming `security-auth-*` explicitly. New CLI flags: `--allow-no-auth-yet` (boolean override for the refusal), `--answer <id>=<value>` (repeatable), `--answers <file>` (JSON object bag). The pack runner extension threads `projectRoot` through the check context so a shipped pack check may declare its own `appliesTo({ projectRoot })` predicate that reads the sidecar; an absent required capability records `applicable: false` on the check record and the aggregate verdict treats it as neither pass nor fail (T-5 refinement of the section 3.3 residual cure). The four shelf auth blueprints adopt `capabilities[]` in v1.1.0/v1.2.0 minor bumps landing in the same PR per spec Q2 default: `security-auth-magic-link` 1.0.0 -> 1.1.0 `[principalDirectory]` (no `roleModel`; that is Baz's explicit example, so a bare-magic-link project gets no roles surface), `security-auth-clerk` 1.1.0 -> 1.2.0 `[principalDirectory, roleModel]`, `security-auth-oauth2` 1.0.0 -> 1.1.0 `[principalDirectory, roleModel]`, `security-auth-keycloak` 1.0.0 -> 1.1.0 `[principalDirectory, roleModel]`. Each ships a fresh `CHANGELOG.md` entry naming the capabilities and citing spec section 5.5.2. Ships `blueprints/application-admin-console/` v1.0.0 with 23 contributions (six REQs on the console shell with no dead links to unapplied capabilities, users conditional on `principalDirectory`, roles conditional on `roleModel` with the Owner + Admin + Member + Viewer baseline, orgs conditional on `tenancy`, audit-log conditional on `auditLog`, and the access-denied and request-access states per WCAG; nine USs 21101-21109 binding sixteen runtime-observable ACs plus the conditional-refusal apply-time behaviour; four TACs 2201-2204 on the console shell, the apply-time capability discovery, the permission matrix as an ARIA APG grid, and the audit view consuming `application-datatable`; four ADRs 2201-2204 on the capability vocabulary, Owner + Admin + Member + Viewer baseline with elicited additions, invite transport with email default delegated to the email sibling and elicited, and audit-log retention window elicited). The blueprint declares `requiresAppliedCapabilities: {capabilities: ["principalDirectory"], allowSkipFlag: "allow-no-auth-yet", refusalMessageId: "application-admin-console-bare-spa"}`, four elicits (`baseline-roles` when `roleModel`, `tenancy-shape` when `tenancy`, `invite-transport` always, `audit-retention-days` when `auditLog`), and `suggestedCompanions` `logging` and `errorHandling` with the ratified spec's reasons; `providesRoles` is absent per spec 5.5.3 (the console is a consumer of `principalDirectory`, never a provider). Ships `probe-packs/application-admin-console.pack.mjs` with four capability-gated checks anchored to blueprint AC ids, every check carrying its own `appliesTo({ projectRoot })` predicate reading the applied sidecar so an absent capability records `applicable: false`: `AC-21102-1` users directory when `principalDirectory` is applied (verifies the `[data-surface="users"]` region enumerates users by `data-user-id`, the role column suppresses when `roleModel` is not applied, and the access-denied route renders a `[data-action="request-access"]` control), `AC-21103-1` permission matrix when `roleModel` is applied (verifies the outer element carries `role="grid"`, ranks carry `role="row"`, permission columns carry `role="columnheader"`, role rank leftmost cells carry `role="rowheader"`, inner cells carry `role="gridcell"`, and every cell announces the exact permission string via `aria-label` on focus per WCAG 4.1.3), `AC-21104-1` org switcher when `tenancy` is applied (verifies the `[data-role="org-switcher"]` control on the shell header), `AC-21105-1` audit-log when `auditLog` is applied (verifies every audit row is enumerable by `data-audit-id` and carries `actor / target / before / after / timestamp / correlationId` columns). Pack-level `appliesTo` names BOTH `tacIds` AND `route` (the two legal source-scan seams). Fifth blueprint on the shelf that ships a Playwright probe pack under the T-0 runner extension; consumes `application-datatable` (T-1) for the users and audit surfaces. Ships a dependency-free sample-app fixture at `packages/rcf-lite/test/fixtures/probe-pack-application-admin-console/` with `PORT` env (default 3000), `ADMIN_CONSOLE_CAPS` env or `?caps=` query switch selecting which surfaces exist, `?asAdmin=false` to simulate a non-admin principal on the access-denied route, break switches for the negative runs (`?break=matrix-grid` drops `role="grid"` on the matrix, `?break=denied` drops the request-access control, `?break=audit-fields` drops the `correlationId` column), and `window.__adminFetches` plus `/__requests` mirroring every request. The fixture ships its own `README.md` naming PORT, `ADMIN_CONSOLE_CAPS`, every `?caps=` combination, every break switch, and the two-line manual boot for the gate reviewer per the T-1 gate discipline. Every runtime-observable AC that is not bound to a pack check appears in the blueprint README's "Known mechanism-reach gaps" section individually per the T-1 gate discipline (`blueprint-authoring-checklist.md` section 6.g): AC-21101-2 primary nav landmark shape, AC-21102-2 per-row invite / deactivate control shape, AC-21103-2 elicited additional roles rank order, AC-21105-2 datatable shell consumption on the audit view, AC-21106-1 wider WCAG structure on the access-denied region, AC-21107-1 client-side sidecar fetch, AC-21108-1 `providesRoles` absent (chain-scope, probed by anatomy tests), AC-21109-1 and AC-21109-2 apply-time refusal and override (CLI-scope, probed by mechanism unit tests). Blueprint-authoring section 6a's capability vocabulary table extends the roles registry chunk-zero-style; the shelf band table gains an `application-admin-console` row (21101-21899 / 22xx / none) in `packages/rcf-lite/docs/blueprint-authoring.md` section 5 and every applying blueprint's `docs/topics.md`. Pins `@stravica-ai/rcf-schemas` 0.6.0 -> 0.6.1 in `packages/rcf-lite/package.json` in its own commit (the 0.6.1 minor adds the additive optional `browserVerificationRecord.probePacks[]` field that lets a non-dry-run `rcf verify browser --probe-pack <slug>` persist the pack results into the manifest, per visual round spec section 3.4 and the T-4 gate P1 hand-off). Repo chain extended with REQ-022 (mechanism) / REQ-023 (admin-console shelf ship) / US-2201 / US-2301 / TS-051 / TS-052 / FBS-041 / FBS-042 / CN-128..133, covered by `test/blueprint/capabilities-loader.test.js`, `test/blueprint/capabilities-apply.test.js`, `test/blueprint/capabilities-auth-minors.test.js` and `test/blueprint/application-admin-console-anatomy.test.js` (16 new tests, all passing on Node 24.14.0). Trace: `projects/blueprint-library/specs/visual-round-spec-2026-09-04.md` sections 5.5, 5.5.1, 5.5.2, 5.5.3, section 6.1, section 9 (T-5 rows).
+
+- **Visual round T-4: application-notifications-in-app v1.0.0 blueprint on the shelf with its Playwright probe pack, sample-app fixture and the family-prefix reservation for sibling channels (spec 2026-09-04 section 5.4, w-2026-09-04-dave-014).** The rcf-lite shelf ships `blueprints/application-notifications-in-app/` with 19 contributions (five REQs covering live-region preseeding on every declared route, transient toast contract with priority-to-role mapping and one-shot announcement, notification centre inbox with retention and acknowledge round-trip, per-user preferences UI with category silence and sibling delegation, and delivery-attempt log with operator-readable rows; eight USs binding runtime-observable ACs plus three cross-cutting cases (page load with backlog, background event, disjoint-content contract); three TACs on the live-region wrappers with the toast factory, the centre inbox with retention and acknowledge round-trip, and the preferences UI with sibling delegation; three ADRs on the priority-to-role mapping polite/status vs assertive/alert per WCAG 4.1.3 and the ARIA APG alert pattern, the six-second toast timeout floor per WCAG 2.2.1 Timing Adjustable with elicited overrides above the floor, and the thirty-day centre retention window with elicited overrides). The blueprint suggests the `logging` (delivery-log write path, acknowledge round-trip record) and `errorHandling` (assertive-slot alert internal error record) companions with the ratified spec's reasons; `providesRoles` is absent (leaf blueprint per spec; the loader refuses an empty `providesRoles` array when set, so the leaf-blueprint intent is expressed by omitting the field). No new global topics are claimed. Reserves the `application-notifications-` family prefix as a name-only doc reservation (per spec Q3 default) for the sibling in-app-adjacent channels the shelf will grow into (`-email`, `-push`, `-webhook`); the reservation is documented as a paragraph in the blueprint README and as reserved rows in the blueprint's own `docs/topics.md` registry (bands claimed at ship, not predicted). The shipped `probe-packs/application-notifications-in-app.pack.mjs` ships three browser-verify checks anchored to blueprint AC ids, every check carrying a `description` field per spec section 9: `AC-20101-1` live-region preseeded on every declared route (both `[data-live-region="polite"]` with `aria-live="polite"` and `[data-live-region="assertive"]` with `role="alert"` present AND empty in the DOM at page load, enumerated by the per-element `[data-live-region]` attribute per the T-3 gate discipline); the AC-20101-1 description carries the word `preseeded` per spec section 9 T-4 row. `AC-20102-1` transient toast contract with priority-to-role mapping (info to polite/status, error to assertive/alert per ADR-2101), one-shot announcement (disjoint-content across the two wrappers), and timeout measured against the ADR-2102 six-second floor via `data-shown-at`/`data-dismissed-at` timestamps on the toast element (bounded polling, no six-second sleep in the pack). `AC-20103-1` centre acknowledge round-trip enumerated by `data-notification-id` (per-element attribute per T-3 gate discipline, never by `role="listitem"` on the container alone); a Tab-reachable acknowledge control POSTs `POST /api/notifications/acknowledge`, the server responds 2xx, and the item's `data-acknowledged` flips to `true` on the response; reconciled through both `window.__notificationFetches` (client-side) and `GET /__requests` (server-side). The pack's `appliesTo` predicate scopes to any FBS binding `TAC-2101-application-notifications-in-app-live-region` or whose nav model routes name a notifications-centre path, referencing BOTH `tacIds` AND `route` as the two legal source-scan seams. Fourth blueprint on the shelf that ships a Playwright probe pack under the T-0 runner extension; consumes the T-3 pack-browser `resize(width, height)` seam only for future minor bumps (v1.0.0 does not exercise breakpoint reflow in the pack). Ships a dependency-free sample-app fixture at `packages/rcf-lite/test/fixtures/probe-pack-application-notifications-in-app/` (one Node HTTP server rendering the main application shell, the notification centre inbox with a seeded backlog of three notifications inside the retention window, and the preferences UI with per-category silence toggles and disabled sibling-channel digest sections). PORT env var (default 3000). Four break switches for the negative runs: `?break=preseed` (wrappers inserted lazily after the first event, fails AC-20101-1); `?break=role` (error toast rendered as status in polite wrapper, info toast rendered as alert in assertive wrapper, fails AC-20102-1); `?break=timeout` (toast dismissed after two seconds and shell root advertises `data-toast-timeout-floor-seconds="2"`, fails AC-20102-1); `?break=ack` (acknowledge click handler is a no-op, no POST and no DOM update, fails AC-20103-1). The fixture ships its own `README.md` naming PORT, every query switch and break switch, and the two-line manual boot for the gate reviewer per the T-1 gate discipline. The shelf band registry row for `application-notifications-in-app` (20101-20899 / 21xx / none) is appended to every existing blueprint's `docs/topics.md` at ship and to the central `packages/rcf-lite/docs/blueprint-authoring.md` shelf-wide band registry; the T-5 `application-admin-console` slot at 21101-21899 / 22xx sits next above per the ratified spec. Every runtime-observable AC that is not bound to a pack check appears in the blueprint README's "Known mechanism-reach gaps" section individually per the T-1 gate discipline (`blueprint-authoring-checklist.md` section 6.g): AC-20101-2 factory identity across route changes; AC-20102-2 toast factory library shape; AC-20103-2 centre factory library shape; AC-20104-1 preferences category silence round-trip; AC-20104-2 sibling-channel disabled state lift when a sibling ships; AC-20105-1 delivery-log endpoint shape; AC-20105-2 delivery-log companion-boundary; AC-20106-1 page-load-with-backlog polite-queue count; AC-20107-1 background-vs-operator toast indistinguishable; AC-20108-1 continuous disjoint-content assertion. Repo chain extended with REQ-021 / US-2101 / AC-2101-1..6 / TS-050 / FBS-040 / CN-124..127, covered by `test/blueprint/application-notifications-in-app-anatomy.test.js`. Trace: `projects/blueprint-library/specs/visual-round-spec-2026-09-04.md` section 5.4, section 6.1, section 9 (T-4 rows). Independent track (T-4 does not depend on the earlier tracks beyond T-0); admin-console T-5 depends on datatable but not on this track.
+
+- **Visual round T-3: application-dashboard v1.0.0 blueprint on the shelf with its packaged design-guidance asset, Playwright probe pack, and pack-browser resize seam extension (spec 2026-09-04 section 5.3, w-2026-09-04-dave-012).** The rcf-lite shelf ships `blueprints/application-dashboard/` with 18 contributions (five REQs covering shell composition, primary-KPI visual hierarchy on the F-scan, per-tile four-state contract, timeframe and filter chrome refetch fan-out, and export handle with format delegation to charts; seven USs binding runtime-observable ACs plus one on packaged-guidance adherence; three TACs on the tile grid with CSS Grid position semantics and breakpoint reflow, the timeframe picker and filter chrome with the refetch fan-out contract, and the export handle with delegation to the charts render shell; three ADRs on the primary-KPI kinds enum with elicited overrides, timeframe presets with recommendedDefault and auto-refresh off by default, and export formats with recommendedDefault and PNG delegation to the charts render shell). The blueprint suggests the `logging` and `errorHandling` companions with the ratified spec's reasons; `providesRoles` is absent (leaf blueprint per spec; the loader refuses an empty `providesRoles` array when set, so the leaf-blueprint intent is expressed by omitting the field). No new global topics are claimed. Ships `assets/guidance/dashboard-design.md`: eight sections (primary KPI placement; tile density and count limits; timeframe and filter chrome; loading, empty and error states; colour and contrast; when a table beats a chart, delegating to application-datatable; refresh cadence and staleness; anti-patterns) with five `https://` citations from the five named source families (NN/g dashboard design, Few, Tufte, GOV.UK Design System patterns, WCAG 2.2 Understanding docs). Each section names whether the rule hardens into an AC on this blueprint or stays operator guidance. The shipped `probe-packs/application-dashboard.pack.mjs` ships three browser-verify checks anchored to blueprint AC ids, every check carrying a `description` field per spec section 9: `AC-19102-1` primary-KPI position by DOM order and CSS Grid position at 1440, 1024 and 360 (drives the new pack-browser `resize(width, height)` seam to each width); `AC-19104-1` timeframe refetch fan-out (every fetch carries the same `from`/`to`/`preset` trio; every tile's `data-as-of` matches the shell root in ISO-8601 form; request log read from `window.__dashboardFetches` and reconciled against `GET /__requests`); `AC-19103-1` per-tile four-state contract (`role="region"`, `aria-live="polite"`, `data-tile-state`, non-colour distinction across loading / empty / error / populated). The pack's `appliesTo` predicate scopes to any FBS binding `TAC-2001-application-dashboard-tile-grid` or whose nav model routes name a dashboard path. Third blueprint on the shelf that ships a Playwright probe pack under T-0's runner extension. Consumes application-charts through the shared render shell (the dashboard's chart region reuses the charts sample-app markup shape); references application-datatable in the packaged guidance's when-a-table-beats-a-chart section. Ships a dependency-free sample-app fixture at `packages/rcf-lite/test/fixtures/probe-pack-application-dashboard/` (one Node HTTP server rendering the five shell regions, a primary-KPI-top-left tile grid with three supporting tiles, a paired chart region, filter chrome, timeframe preset buttons and an export handle listbox). PORT env var (default 3000). Break switches: `?break=kpi-position` (moves the primary tile off top-left, fails AC-19102-1), `?break=fanout` (drifts every second refetch's boundary, fails AC-19104-1), `?break=state-aria` (drops `role="region"` and `aria-live` from tile wrappers, fails AC-19103-1). State pinning through `?tile=<id>&state=<state>`. Request log on `window.__dashboardFetches` and at `GET /__requests`. The fixture ships its own `README.md` naming PORT, every query switch and break switch, and the two-line manual boot for the gate reviewer. Extends the pack-browser seam (`packages/rcf-lite/src/browser-verify/pack-browser.js`) with a `resize(width, height)` method exposed to probe pack authors on both routes: on the MCP route the method calls the pinned Playwright MCP's `browser_resize` tool; on the project route it calls `page.setViewportSize({ width, height })`. Zero new npm dependencies. Both routes coerce arguments through a shared `normaliseDim` helper covered by paired unit tests. The extension is in its own commit; the T-4 notifications-in-app and T-5 admin-console blueprints reuse the seam. Also fixes a T-2 gate follow-up in the charts pack: the three `browser.goto` call sites in `blueprints/application-charts/probe-packs/application-charts.pack.mjs` now navigate with `new URL('', runtimeUrl).toString()` instead of `runtimeUrl + '/'`, so a reviewer CLI `--url` that carries `?break=<mode>` verbatim survives the navigation (charts stays at v1.0.0 with a patch-note entry in its own CHANGELOG). The shelf band registry row for `application-dashboard` (19101-19899 / 20xx / none) is appended to every existing blueprint's `docs/topics.md` at ship and to the central `packages/rcf-lite/docs/blueprint-authoring.md` shelf-wide band registry. Repo chain extended with REQ-020 / US-2001 / AC-2001-1..7 / TS-049 / FBS-039 / CN-119..123, covered by `test/blueprint/application-dashboard-anatomy.test.js` and `test/browser-verify/pack-browser-resize.test.js`. Trace: `projects/blueprint-library/specs/visual-round-spec-2026-09-04.md` section 5.3, section 5.3.1 (packaged guidance shape), section 6.1, section 9 (T-3 rows). Unblocks tracks T-4 (notifications-in-app) and T-5 (admin-console, which composes on datatable, on the dashboard's tile-grid pattern and on the resize seam for its own breakpoint-scoped visual ACs).
+
+- **Visual round T-2: application-charts v1.0.0 blueprint on the shelf with its Playwright probe pack (spec 2026-09-04 section 5.2, w-2026-09-04-dave-013).** The rcf-lite shelf ships `blueprints/application-charts/` with 15 contributions (four REQs covering the chart form set, non-colour distinction, text-alternative table, and keyboard traversal for interactive charts; six USs binding runtime-observable ACs; two TACs for the render shell and the keyboard traversal contract; three ADRs for the elicited chart engine with the canvas-only-no-text-alternative refusal rule, the accessible-defaults categorical palette light and dark, and reduced-motion respect via the application-spa motion tokens). The blueprint suggests the `logging` and `errorHandling` companions with the ratified spec's reasons; `providesRoles` is absent (leaf blueprint per spec). No new global topics are claimed. The shipped `probe-packs/application-charts.pack.mjs` ships three browser-verify checks anchored to blueprint AC ids, every check carrying a `description` field per spec section 9: `AC-18102-1` non-colour distinction (every series carries a non-colour cue such as `data-pattern`, `stroke-dasharray`, hatched fill or marker shape PLUS a direct label at the series), `AC-18103-1` text-alternative table (a `<table>` in the same landmark as the chart, cell-per-value, focus-reachable through a labelled control), `AC-18104-1` keyboard traversal (every data point tab-focusable with the announced string `<seriesName>, <xValue>, <yValue> <unit>` on focus, and `prefers-reduced-motion: reduce` suppresses transitions). The pack's `appliesTo` predicate scopes to any FBS binding `TAC-1901-application-charts-render-shell` or whose nav model routes name a chart or dashboard path. Second blueprint on the shelf that ships a Playwright probe pack under T-0's runner extension; leaf blueprint the T-3 application-dashboard build consumes. Ships a dependency-free sample-app fixture at `packages/rcf-lite/test/fixtures/probe-pack-application-charts/` (one Node HTTP server rendering a two-series bar chart and a two-series line chart with paired text-alternative tables, focus-reachable data points announcing the format, and a reduced-motion media rule), driven by the shipped `start` script on `PORT` (default 3000). Three `?break=<mode>` query switches drive the negative runs: `?break=table` drops the text-alternative table (fails AC-18103-1), `?break=pattern` drops the data-pattern attributes (fails AC-18102-1), `?break=keyboard` drops tabindex and aria-label on data points (fails AC-18104-1). The fixture ships its own `README.md` naming PORT, every query switch and break switch, and the two-line manual boot for the gate reviewer (visual round T-2 discipline carried from the T-1 gate). The shelf band registry row for `application-charts` (18101-18899 / 19xx / none) is appended to every existing blueprint's `docs/topics.md` at ship and to the central `packages/rcf-lite/docs/blueprint-authoring.md` shelf-wide band registry. Vision-deficiency emulation is a runner-seam gap today (`emulateVisionDeficiency` is not on the pack browser API); AC-18102-1 is proven at the DOM level per the T-1 gate discipline, and the blueprint's `README.md` names it and the other mechanism-reach gaps individually (checklist 6.g). Repo chain extended with REQ-019 / US-1901 / AC-1901-1..5 / TS-048 / FBS-038 / CN-116..118, covered by `test/blueprint/application-charts-anatomy.test.js`. Trace: `projects/blueprint-library/specs/visual-round-spec-2026-09-04.md` section 5.2, section 6.1, section 9 (T-2 rows). Unblocks track T-3 (application-dashboard, which composes on charts for the chart region).
+
+- **Visual round T-1: application-datatable v1.0.0 blueprint on the shelf with its Playwright probe pack (spec 2026-09-04 section 5.1, w-2026-09-04-dave-011).** The rcf-lite shelf ships `blueprints/application-datatable/` with 22 contributions (six REQs covering the table shell, sort semantics, filter chrome, selection and bulk actions, four-state region contract, and the non-drag keyboard column-visibility / reorder / resize path; nine USs binding 27 runtime-observable ACs; three TACs for the shell, the query adapter, and the selection model; four ADRs for the ARIA APG pattern choice, URL-state serialisation, page size, and selection persistence). The blueprint suggests the `logging` and `errorHandling` companions with the ratified spec's reasons; no new global topics are claimed. The shipped `probe-packs/application-datatable.pack.mjs` ships six browser-verify checks anchored to blueprint AC ids: `AC-17101-1` sort click reorders rows, `AC-17102-1` filter chrome text-search issues `q=<value>`, `AC-17103-2` pagination announcement in an `aria-live="polite"` region reading `Page N of M`, `AC-17104-3` bulk-action confirmation dialog returns focus to the originating row on close, `AC-17105-1` four state regions each render inside `role="region"` with `aria-live="polite"`, `AC-17106-1` column reorder has a non-drag keyboard alternative (WCAG 2.5.7). The pack's `appliesTo` predicate scopes to any FBS binding `TAC-1801-application-datatable-shell` or whose nav model routes name a datatable path. First blueprint on the shelf that ships a Playwright probe pack under T-0's runner extension. Ships a dependency-free sample-app fixture at `packages/rcf-lite/test/fixtures/probe-pack-application-datatable/` (one Node HTTP server realising every surface the six checks probe honestly enough for the pack to run green, driven by the shipped `start` script on `PORT`). The shelf band registry row for `application-datatable` (17101-17899 / 18xx / none) is appended to every existing blueprint's `docs/topics.md` at ship. Repo chain extended with REQ-018 / US-1801 / AC-1801-1..5 / TS-047 / FBS-037 / CN-113..115, covered by `test/blueprint/application-datatable-anatomy.test.js`. Also fixes a T-0 defect (tracked under w-2026-09-04-dave-020): `pack-loader.readContributedAcIds` now resolves contribution paths relative to the blueprint's `contributions/` subdirectory (the loader.js convention for real shelf blueprints), with a legacy fall-back to the blueprint root for the T-0 pack-loader tests. Trace: `projects/blueprint-library/specs/visual-round-spec-2026-09-04.md` section 5.1, section 6.1, section 9 (T-1 rows). Unblocks tracks T-2 (charts), T-3 (dashboard, which composes on datatable's recent-items strip), T-4 (notifications-in-app) and T-5 (admin-console, which composes on datatable for users and audit views).
+
+- **Visual round T-0: blueprint-shipped browser-verify probe packs and the applicability predicate (spec 2026-09-04, w-2026-09-04-dave-016).** `rcf verify browser` gains a probe-pack pass that runs after invariants and after auth-smoke. A blueprint SHIPS a Playwright probe pack at `blueprints/<slug>/probe-packs/<pack-name>.pack.{js,mjs}` exporting a default object with `packName`, semver `version`, `blueprintSlug`, an `appliesTo({ fbs, uiBaseline, manifest })` predicate, and a non-empty `checks[]` array. The loader (`src/browser-verify/pack-loader.js`) discovers packs on every applied blueprint (`manifest.blueprints[]`), imports each module dynamically, validates against the pack schema (`src/browser-verify/pack-schema.js`), and cross-checks every `checks[].id` against the AC ids the blueprint contributes through its US contribution files. Load-time refusals (exit 2, one diagnostic per fault) fire on: an `appliesTo` predicate whose source references none of `route` / `navModel` / `path`, `tacIds`, or the `blueprint:` US-tag prefix (the default `() => true` is caught); a packName that does not start with the blueprint's slug; a check id the blueprint does not contribute; non-semver version; duplicate check or pre-check ids; a broken pack module. The runner (`src/browser-verify/pack-runner.js`) invokes each check's `run({ browser, fetch, runtimeUrl, route, theme })`, folds results into `browserVerification.probePacks[]` on the composed record, and skips checks whose `dependsOn` names a failing pre-check with verdict `skipped` and detail `skipped-by-pre-check:<preCheckId>`. `aggregateVerdict` extends to block on any severity=block pack fail or pre-check fail; warn on any severity=warn fail with no block. A pack whose `appliesTo` returns false for an FBS is recorded with `applicable: false` and contributes no verdict, curing the run-4 "auth-smoke fires on all UI-bearing FBS" residual. `rcf verify browser <fbs-id> --probe-pack <name>` restricts one run to one pack; an unknown name exits 2 with a diagnostic naming the discovered packs. Docs: `packages/rcf-lite/docs/blueprint-authoring.md` section 8c ("Visual-surface probe packs"), a paired row on `packages/rcf-lite/docs/blueprint-authoring-checklist.md` section 6, and a `rcf verify browser` reference on `packages/rcf-lite/docs/verify-reference.md`. Zero new npm dependencies; the runner-provisioned Playwright MCP (`PLAYWRIGHT_MCP_VERSION` in `src/verify/engine/launcher.js`) is the browser access seam.
+
+Trace: `projects/blueprint-library/specs/visual-round-spec-2026-09-04.md` sections 2.1, 3, 6.1, 9 (T-0 rows). Unblocks tracks T-1..T-5 (datatable, charts, dashboard, notifications-in-app, admin-console).
+
+- **Visual round T-0 follow-up: real headless browser for probe packs, boot fallback for the runtime URL, layout goldens regenerated for the extended chain (spec 2026-09-04 sections 3.3 to 3.5, w-2026-09-04-dave-016 follow-up).** The `packBrowser` seam is now a real headless Playwright browser rather than a stub. Provisioning goes through the pinned Playwright MCP server (`PLAYWRIGHT_MCP_VERSION` in `src/verify/engine/launcher.js`, spawned as `npx -y @playwright/mcp@<pin>`) via a new thin in-package JSON-RPC 2.0 stdio client (`src/browser-verify/pack-browser.js`); when the consuming project already resolves `playwright` from its own `node_modules`, the CLI takes that cheaper direct route and exposes the identical small API to packs: `goto`, `snapshot` (accessibility-tree text), `evaluate`, `click`, `type`, `press`, `screenshot`, `close`. Zero new npm dependencies, no LLM call, no ambient MCP config leaked. The CLI provisions the browser only when at least one applicable pack is loaded; `--no-browser` disables provisioning entirely. Packs may declare `boot: { bootCommand, waitForUrl, waitForSelector }` (`src/browser-verify/boot.js`): when the runtime URL is unreachable the CLI spawns `bootCommand` from the project root (cwd = project root, no shell), polls `waitForUrl` (default cap 60s), optionally polls the browser snapshot for `waitForSelector` (default cap 10s, soft-failure), runs the packs, then stops the process it started (SIGTERM, SIGKILL fallback after 3s). When the runtime is already answering, the boot block is skipped and the running server is used unchanged (Baz ruling 2026-09-04: the dev server is the normal path). `--no-boot` disables the fallback. The layout-regression Phase 3.6 baseline (`test/view/fixtures/phase-3-6-static.html`) was regenerated on Node 24.14.0 for the REQ-017 chain addition. Chain: US-1701 extended with AC-1701-7 (real browser seam) and AC-1701-8 (boot fallback); TS-046 with paired TCs; CN-111 anchors `pack-browser.js#createPackBrowser` and CN-112 anchors `boot.js#bootIfNeeded`; FBS-036 bindings extended.
+
+## [0.20.0] - 2026-09-04
+
+Optional evaluation node in the RCF chain. An acceptance criterion whose outcome cannot be checked deterministically is marked at define time, an evaluation is attached with its own pass threshold, and audit, verify and finalise refuse to ship while it is missing. An explicit opt-out records its reason on the manifest. The schema floor moves to rcf-schemas 0.6.0.
+
+### Added
+
+- **rcf-eval-node train: optional EVAL node in the RCF chain and the audit / verdict / finalise wiring around it (spec 2026-09-04).** rcf-schemas is pinned to 0.6.0, which lands the EVAL document type and an AC-level `determinism: "deterministic" | "nonDeterministic"` marker. rcf-lite consumes both. The story, one line per level:
+  - **L1 `rcf audit eval coverage [scope-id]`.** New sibling of `rcf audit coverage`. Reports which nonDeterministic ACs carry a resolving EVAL (a non-superseded EVAL whose most recent `runRecord[]` entry is not `pending`). `--strict` exits 4 on any gap; a subtree with zero nonDeterministic ACs passes trivially. `--format table | json | mermaid`; `--require-approved` extra gate. Deterministic ACs are never gated. `mermaid` colours: green deterministic, amber covered, red missing.
+  - **L2 EVAL-MISSING and EVAL-BELOW-THRESHOLD per-AC verdicts.** Two new entries on `PER_AC_VERDICTS` in the verify verdict layer. Both ride `report.perAcVerdicts[]` alongside the 0.7.0 classes; the top-level `VERDICTS` set is unchanged (backward compatibility on `validateReportShape`). The chain reader carries `determinism`, `evalStatus` (`resolving` | `pending` | `superseded` | `absent`) and `evalRunVerdict` (`pass` | `fail` | `pending` | `null`) on every flattened AC. `report.run.runStats.evalCoverage = { nonDeterministic, covered, missing }` rolls up the counts, and `rcf verify run` prints the preflight-style line `EVAL coverage: nonDeterministic=<n>, covered=<k>, missing=<n-k>` (or `EVAL coverage: no nonDeterministic ACs on this chain`).
+  - **L3 finalise refusal and `--ship-without-eval "<reason>"`.** `rcf finalise` reads the two new per-AC verdicts and refuses promotion to `verified` with the spec-verbatim message shape (`finalise refused: EVAL missing on AC(s) <ids>; author an EVAL or --ship-without-eval "reason"` / `finalise refused: EVAL below threshold on AC(s) <ids>; investigate the run record or --ship-without-eval "reason"`), exit 4. `--ship-without-eval "<reason>"` is the sister opt-out of `--ship-without-verified`: reason string is mandatory (exit 2 without one; a value that looks like a flag is refused). Acknowledgements land on the manifest under a new optional `shipWithoutEval[]` array with monotonic ids `swe-<fbsId>-<n>`, the operator reason, the declared per-AC verdicts, and the report path. Manifest write is atomic (tmp + rename).
+  - **L4 `--determinism` on `rcf define create ac`; LLM-as-judge invocation.** `rcf define create ac --determinism deterministic | nonDeterministic` writes the marker onto the inline AC. Enum guard fires the spec-verbatim message (`--determinism expects 'deterministic' or 'nonDeterministic', got '<value>'`), exit 2. Absence writes no field, so existing chains stay byte-stable and consumers resolve to `deterministic` at every layer. The LLM-as-judge invocation lives at `src/eval/judge.js`: `runOneCase()` spawns the invoker (`claude` or `codex`; enum-guarded) with `-p <system-prompt>`, sends the per-case payload on stdin, captures stdout, validates against `judge.harness.responseSchemaPath`, and returns the graded envelope. `composeRunRecord()` rolls per-case scores into a runRecord entry (aggregate, criticalFailures, verdict); `appendRunRecord()` returns a new EVAL doc for the caller to write atomically. No API keys, no HTTP APIs, no fetches enter rcf-lite (estate rule: subscription-only via the `claude`/`codex` CLI, same shape the verify launcher already uses).
+- **Core store learns the EVAL doc kind.** `src/core/store/{validator,ids,loader,walker,init,writer}.js` register the 12th document kind. `rcf init` scaffolds `rcf/evals/`. The walker adds a fresh inversion map `tree.evalByAcId` (keyed on `acId`, value = EVAL ids naming that AC) and cross-link integrity (`EVAL.usId` -> a known US; every `EVAL.acIds[]` -> a known AC on the parent US; cross-US EVAL bindings refuse). `PREFIX_FAMILIES` gains `EVAL`; families of ids resolve to `rcf/evals/<id>.json` on disk.
+
+Trace: `projects/rcf-lite-wsd/specs/rcf-eval-node-spec-2026-09-04.md` (ratified 2026-09-04T10:38:08Z, amendment A1 under the envelope). Origin: AI-SDLC paper action 2, optional-eval-node form. Work item: `w-2026-09-03-dave-005`; also closes `w-2026-09-04-dave-002` (the blueprint-authoring checklist section 6 US tag rule is schema-accepted from rcf-schemas 0.6.0 forward).
+
 ## [0.19.0] - 2026-09-04
 
 Core companions train. Two new general-enterprise-practice blueprints land on the shipped core shelf, an additive companion-suggestion mechanism baked into the manifest, and the standards-derived-blueprint discipline written into the authoring standard as section 8a.

package/bin/rcf.js

@@ -49,6 +49,7 @@ import { main as viewMain } from '../src/cli/view.js';
 import { main as reqClassifyMain } from '../src/cli/req-classify.js';
 import { main as reqBaselineMain } from '../src/cli/req-baseline.js';
 import { main as intakeMain } from '../src/cli/intake.js';
+import { main as evalMain } from '../src/cli/eval.js';
 
 // Verify group members are handled by the verify-suite dispatch tree.
 import { main as verifyRunMain } from '../src/verify/cli/run.js';
@@ -118,6 +119,10 @@ export const GROUPS = {
     coverage: coverageMain,
     trace: traceMain,
     impact: impactMain,
+    // rcf-eval-node spec section 4: `rcf audit eval coverage`. `eval`
+    // is a compound sub-dispatcher; today it exposes just `coverage`,
+    // future EVAL-shaped audits (trace, run history) plug in here.
+    eval: evalMain,
   },
 };
 

package/blueprints/application-admin-console/CHANGELOG.md

@@ -0,0 +1,11 @@
+# application-admin-console CHANGELOG
+
+## 1.0.0 (visual round T-5, spec 2026-09-04)
+
+- First ratified version of the shelf's admin-console blueprint. Six REQs (console shell with no dead links, conditional users, conditional roles with Owner + Admin + Member + Viewer baseline, conditional orgs, conditional audit-log, access-denied plus request-access), nine USs 21101-21109 binding 16 runtime-observable ACs, four TACs 2201-2204 (shell, capability discovery, permission matrix, audit view consuming datatable), four ADRs 2201-2204 (capability vocabulary, baseline roles, invite transport, audit retention). No new global topics.
+- Introduces the capability-declaration mechanism: `capabilities[]` on identity blueprints (v1.1.0 minor bumps on magic-link, clerk, oauth2, keycloak land in the same PR per spec Q2 default), `requiresAppliedCapabilities` and `elicits[]` on consumer blueprints, apply-time discovery via source read-back on `manifest.blueprints[]`, exit-3 refusal with the spec 5.5.1 verbatim message on bare-SPA applies, and a `--allow-no-auth-yet` operator override.
+- Persists per-project apply-time state in a sidecar `rcf/blueprints/application-admin-console.applied.json` (the applied-blueprint-record schema in rcf-schemas 0.6.0 is closed under additionalProperties:false; the source-manifest read-back precedent from the T-2 core-companions train applies here). The sidecar carries `appliedCapabilities`, `appliedElicitations`, `allowNoAuthYet?` and `notes?`.
+- Ships `probe-packs/application-admin-console.pack.mjs`: four capability-gated browser-verify checks anchored to AC-21102-1 (users), AC-21103-1 (permission matrix), AC-21104-1 (org switcher), AC-21105-1 (audit-log surface). Each check reads the applied capability sidecar and records `applicable: false` where its required capability is absent (T-5 residual cure). Fifth shipped consumer of T-0's probe-pack runner extension.
+- Ships a dependency-free sample-app fixture at `packages/rcf-lite/test/fixtures/probe-pack-application-admin-console/` with `CAPS` env or `?caps=` query switch selecting which surfaces exist, break switches for the negative runs (matrix-grid, denied, audit-fields), and the mandatory README for the gate reviewer.
+- Consumes `application-datatable` (T-1) for the users and audit surfaces; declares `suggestedCompanions` logging and errorHandling.
+- Does NOT declare `providesRoles` per spec 5.5.3 (the console is a consumer of `principalDirectory`, never a provider).

package/blueprints/application-admin-console/README.md

@@ -0,0 +1,98 @@
+# Admin console blueprint (v1.0.0)
+
+Vendor-neutral admin-console shell for an rcf-lite application. Surfaces are CONDITIONAL on what the applied identity blueprint declares. Ships the console shell with navigation across the applied surfaces (no dead links to unapplied capabilities), a users directory with invite and deactivate controls, a permission matrix rendered as an ARIA APG grid with the Owner + Admin + Member + Viewer baseline, an org switcher for multi-tenant projects, an audit-log surface reading a delivered event stream, and an access-denied and request-access state per WCAG. Introduces the capability-declaration mechanism (`capabilities[]` on identity blueprints) and the apply-time discovery, refusal and custom-auth elicitation the spec section 5.5 ratifies. Ships a Playwright probe pack under `probe-packs/application-admin-console.pack.mjs` whose four checks are capability-gated: an absent capability records `applicable: false` and the aggregate verdict treats it as neither pass nor fail (spec section 3.3).
+
+## Apply
+
+```
+rcf define blueprint add <path-to>/blueprints/application-admin-console
+```
+
+Refuses with exit 3 and the spec 5.5.1 verbatim message on a project with no applied blueprint declaring `principalDirectory` unless `--allow-no-auth-yet` is passed for a scaffolding pass. Prompts the elicitation phase for parameters whose `when` predicate resolves true against the discovered applied-capability set. Writes a sidecar `rcf/blueprints/application-admin-console.applied.json` capturing the discovered `appliedCapabilities`, the elicit answers, and (when overridden) the scaffolding-note. Consumes the `logging` and `errorHandling` companions when they resolve to an applied provider or a registered library; falls back to the shelf providers otherwise.
+
+## Anatomy
+
+| Piece | Where | What |
+|---|---|---|
+| Metadata | `blueprint.json` | Slug, version 1.0.0, category `application`, `requiresAppliedCapabilities: [principalDirectory]`, `elicits[]` (baseline-roles, tenancy-shape, invite-transport, audit-retention-days), `suggestedCompanions: [logging, errorHandling]`, 23 contributions in the 22xx / 21xxx band |
+| Doc set | `contributions/` | 6 REQs, 9 USs (16 runtime-observable ACs), 4 TACs, 4 ADRs |
+| Probe pack | `probe-packs/application-admin-console.pack.mjs` | Four capability-gated browser-verify checks anchored to AC-21102-1, AC-21103-1, AC-21104-1, AC-21105-1 |
+| Guide | `guide/application-admin-console.md` | Operator-facing: when to reach, when not, mechanism-reach gaps |
+| Coordination vocabulary | `docs/topics.md` | Shelf id band registry update; no new global topics claimed |
+| Sample-app fixture | `packages/rcf-lite/test/fixtures/probe-pack-application-admin-console/` | Dependency-free Node HTTP server the pack is probed against on the shelf gate |
+
+## Conditionality: what surfaces render when
+
+| Applied capability | Surface | Rendered by |
+|---|---|---|
+| `principalDirectory` | Users directory (`/admin/users`) | Any applied auth blueprint (magic-link, clerk, oauth2, keycloak). |
+| `roleModel` | Permission matrix (`/admin/roles`) | Clerk, OAuth2, Keycloak. Magic-link does NOT declare it, so a bare-magic-link project gets NO roles surface (Baz's example, spec section 5.5). |
+| `tenancy` | Org switcher (`/admin/orgs`), org-scoped invites | Reserved for a future `application-tenancy-orgs` blueprint (spec section 11). No shelf provider today. |
+| `auditLog` | Audit-log surface (`/admin/audit`) | Via the applied `observability-logging` companion (implicit), or a future dedicated audit-log blueprint. |
+| (none) | Access-denied + request-access | Always renders for a non-admin principal reaching `/admin/*`. |
+
+## Bare-SPA refusal
+
+On a project with only `application-spa` applied (no auth), the apply exits 3 with:
+
+```
+application-admin-console requires at least one applied security-auth-* blueprint,
+or an operator override with --allow-no-auth-yet.
+
+Applied blueprints on this project:
+  application-spa v1.5.0
+
+Suggested next steps:
+  1. Apply an auth blueprint first:
+       rcf define blueprint add security-auth-magic-link
+     (or security-auth-clerk, security-auth-oauth2, security-auth-keycloak)
+  2. Override for a scaffolding pass (surfaces will refuse at apply until an
+     auth blueprint is applied):
+       rcf define blueprint add application-admin-console --allow-no-auth-yet
+```
+
+The override records a note on the sidecar's `notes` field so `rcf define validate` reads back and flags surfaces that never activated.
+
+## Custom-auth projects (auth outside the shelf)
+
+A project that ships its own auth surface (no shelf `security-auth-*` blueprint applied) supplies capability answers via the elicitation phase:
+
+```
+rcf define blueprint add ./blueprints/application-admin-console \
+  --answer baseline-roles="Owner, Admin, Member, Viewer, SupportAgent" \
+  --answer tenancy-shape=per-user \
+  --answer invite-transport=email
+```
+
+Answers land on `rcf/blueprints/application-admin-console.applied.json`'s `appliedElicitations{}` map. The `when` predicate on each elicit gates whether the prompt fires: `baseline-roles` only fires when `roleModel` is applied, `tenancy-shape` only when `tenancy` is applied, and so on.
+
+## The one runtime gate
+
+`probe-packs/application-admin-console.pack.mjs` ships four checks the `rcf verify browser` runner invokes on any FBS whose surface matches the pack's `appliesTo` predicate (an FBS that binds `TAC-2201-application-admin-console-shell` or whose nav model routes name an admin path). Each check ALSO carries its own `appliesTo` predicate that reads the applied capability sidecar and returns false when the required capability is absent; the check records `applicable: false` and the aggregate verdict treats it as neither pass nor fail (spec section 3.3, T-5 residual cure). This is exactly the residual pattern the spec named: the surface does not exist, so the pack does not fire.
+
+Each check drives the real Playwright browser the runner provisions (through the pinned Playwright MCP or the consuming project's own `playwright` installation), reads the accessibility tree and the DOM, and returns a verdict.
+
+## Quality bar
+
+ARIA APG grid pattern on the permission matrix (ADR-2201, TAC-2203); role="row", role="rowheader", role="columnheader", role="gridcell" and per-cell aria-label announcing the permission string on focus (WCAG 4.1.3). Every access-denied state renders under WCAG 2.4.6 Headings and Labels and 3.3.4 Error Prevention with a keyboard-reachable request-access control and a polite live region announcing state changes. Every table surface enumerates rows by `data-<entity>-id` (users by `data-user-id`, audit entries by `data-audit-id`) inside the `data-surface` region. The Owner + Admin + Member + Viewer baseline is drawn from SaaS UI research 2026 (ADR-2202); the retention window on the audit view is elicited per project (ADR-2204).
+
+## Known mechanism-reach gaps
+
+Runtime-observable ACs the pack does NOT bind directly (checklist section 6.g), listed individually:
+
+- **AC-21101-2 (single primary nav landmark with accessible name).** Present on the fixture as `<nav data-role="primary-nav" aria-label="Admin console">`; the pack asserts the fixture renders the four surfaces but does not additionally probe the landmark's accessible name. A v1.1.0 minor bump can add a landmark-shape check driven by the accessibility tree.
+- **AC-21102-2 (per-row invite / deactivate control shape).** Present on the fixture as `[data-action="invite"]` and `[data-action="deactivate"]` buttons; the pack's AC-21102-1 check confirms the users directory renders row ids but does not additionally exercise the invite / deactivate click paths. A v1.1.0 minor bump can extend AC-21102-1 with a click-round-trip.
+- **AC-21103-2 (elicited additional roles rendered after the baseline four).** Present on the fixture as the Owner + Admin + Member + Viewer rank order; the pack's AC-21103-1 confirms the grid roles and per-cell announcements but does not additionally probe elicited-role position. A v1.1.0 minor bump can read the sidecar's `appliedElicitations.baseline-roles` and compare rank order.
+- **AC-21105-2 (audit view consumes the datatable shell TAC).** Realised on the fixture by rendering the audit table with the same column contract; the pack's AC-21105-1 confirms the correlation-id column but does not additionally probe the datatable shell's four state regions on the audit view. Datatable's own pack (T-1) still covers those on projects that render the audit view through the datatable factory.
+- **AC-21106-1 (access-denied region accessibility structure beyond the request-access control).** The pack's AC-21102-1 check probes the request-access control on the denied branch; the wider WCAG structure (heading, explanation, polite live region wiring) is present on the fixture but not additionally asserted. A v1.1.0 minor bump can add an axe-core sweep on the denied region.
+- **AC-21107-1 (sidecar file served under a stable path).** The pack reads the sidecar from `projectRoot`; the CLIENT-side read (over the network at load time) is a runtime-observable surface the pack does not additionally probe. A v1.1.0 minor bump can add a probe that reads `/admin/caps.json` on the fixture and diffs against the applied sidecar.
+- **AC-21108-1 (providesRoles absent on the blueprint).** A chain-scope AC probed by the anatomy tests, not by the browser pack.
+- **AC-21109-1 and AC-21109-2 (apply-time refusal and override).** Probed by the mechanism unit tests, not by the browser pack. The gate reviewer runs the CLI directly.
+
+## Companions
+
+`suggestedCompanions` declares `logging` (the audit-log surface reads the event stream the applied logger emits) and `errorHandling` (invite failures and role-change refusals construct internal error records). Neither is required to apply the blueprint; the audit surface simply suppresses when `logging` is not applied.
+
+## Consumers
+
+The audit view consumes `application-datatable` (T-1) for its table shell contract. Every project applying `application-admin-console` should also apply `application-datatable` if they want the ARIA APG table pattern, filter chrome, four state regions and pagination on the audit view.

package/blueprints/application-admin-console/blueprint.json

@@ -0,0 +1,226 @@
+{
+  "slug": "application-admin-console",
+  "version": "1.0.0",
+  "category": "application",
+  "requiresAppliedCapabilities": {
+    "capabilities": [
+      "principalDirectory"
+    ],
+    "allowSkipFlag": "allow-no-auth-yet",
+    "refusalMessageId": "application-admin-console-bare-spa"
+  },
+  "elicits": [
+    {
+      "id": "custom-auth-provides-principal-directory",
+      "prompt": "Custom auth: does your project's own auth blueprint expose a principal directory (identity records the users surface can list)?",
+      "kind": "boolean",
+      "default": false,
+      "providesCapability": "principalDirectory"
+    },
+    {
+      "id": "custom-auth-provides-role-model",
+      "prompt": "Custom auth: does your project's own auth declare operator-visible role labels a permission matrix can render?",
+      "kind": "boolean",
+      "default": false,
+      "providesCapability": "roleModel"
+    },
+    {
+      "id": "custom-auth-provides-tenancy",
+      "prompt": "Custom auth: does your project's own auth (or a paired tenancy blueprint) declare an organisation abstraction the console can switch across?",
+      "kind": "boolean",
+      "default": false,
+      "providesCapability": "tenancy"
+    },
+    {
+      "id": "custom-auth-provides-audit-log",
+      "prompt": "Custom auth: does your project emit an audit event stream the console's audit view can read?",
+      "kind": "boolean",
+      "default": false,
+      "providesCapability": "auditLog"
+    },
+    {
+      "id": "baseline-roles",
+      "prompt": "Baseline role labels for the permission matrix (comma-separated). Owner, Admin, Member, Viewer is the ratified default; extend with per-project labels here.",
+      "kind": "string",
+      "default": "Owner, Admin, Member, Viewer",
+      "when": {
+        "requiresCapability": [
+          "roleModel"
+        ]
+      }
+    },
+    {
+      "id": "tenancy-shape",
+      "prompt": "Tenancy shape for the org switcher: per-user (users belong to one org), per-org (all users belong to every org they can see) or both.",
+      "kind": "enum",
+      "options": [
+        "per-user",
+        "per-org",
+        "both"
+      ],
+      "default": "per-user",
+      "when": {
+        "requiresCapability": [
+          "tenancy"
+        ]
+      }
+    },
+    {
+      "id": "invite-transport",
+      "prompt": "Invite transport: email delegates to the email sibling when present; in-app-only records the invite as a notification; custom hands the delivery to your own transport at surface time.",
+      "kind": "enum",
+      "options": [
+        "email",
+        "in-app-only",
+        "custom"
+      ],
+      "default": "email"
+    },
+    {
+      "id": "audit-retention-days",
+      "prompt": "Audit-log retention window in days. The applied logger enforces retention at the write layer; the console reads the same window.",
+      "kind": "string",
+      "default": "90",
+      "when": {
+        "requiresCapability": [
+          "auditLog"
+        ]
+      }
+    }
+  ],
+  "suggestedCompanions": [
+    {
+      "role": "logging",
+      "reason": "The audit-log surface reads the event stream the applied logger emits; without a logging companion, the audit surface has no source and is suppressed at apply."
+    },
+    {
+      "role": "errorHandling",
+      "reason": "Invite failures and role-change refusals construct internal error records; an error-handling companion supplies the record factory and the boundary."
+    }
+  ],
+  "contributions": [
+    {
+      "id": "application-admin-console-REQ-001",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-001.json"
+    },
+    {
+      "id": "application-admin-console-REQ-002",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-002.json"
+    },
+    {
+      "id": "application-admin-console-REQ-003",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-003.json"
+    },
+    {
+      "id": "application-admin-console-REQ-004",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-004.json"
+    },
+    {
+      "id": "application-admin-console-REQ-005",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-005.json"
+    },
+    {
+      "id": "application-admin-console-REQ-006",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-006.json"
+    },
+    {
+      "id": "application-admin-console-US-21101",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21101.json"
+    },
+    {
+      "id": "application-admin-console-US-21102",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21102.json"
+    },
+    {
+      "id": "application-admin-console-US-21103",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21103.json"
+    },
+    {
+      "id": "application-admin-console-US-21104",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21104.json"
+    },
+    {
+      "id": "application-admin-console-US-21105",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21105.json"
+    },
+    {
+      "id": "application-admin-console-US-21106",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21106.json"
+    },
+    {
+      "id": "application-admin-console-US-21107",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21107.json"
+    },
+    {
+      "id": "application-admin-console-US-21108",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21108.json"
+    },
+    {
+      "id": "application-admin-console-US-21109",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21109.json"
+    },
+    {
+      "id": "TAC-2201-application-admin-console-shell",
+      "kind": "tac",
+      "path": "tacs/tac-2201-application-admin-console-shell.json"
+    },
+    {
+      "id": "TAC-2202-application-admin-console-capability-discovery",
+      "kind": "tac",
+      "path": "tacs/tac-2202-application-admin-console-capability-discovery.json"
+    },
+    {
+      "id": "TAC-2203-application-admin-console-permission-matrix",
+      "kind": "tac",
+      "path": "tacs/tac-2203-application-admin-console-permission-matrix.json"
+    },
+    {
+      "id": "TAC-2204-application-admin-console-audit-view",
+      "kind": "tac",
+      "path": "tacs/tac-2204-application-admin-console-audit-view.json"
+    },
+    {
+      "id": "ADR-2201-application-admin-console-capability-vocabulary",
+      "kind": "adr",
+      "path": "adrs/adr-2201-application-admin-console-capability-vocabulary.json",
+      "standardsTraceClause": "generic enterprise practice"
+    },
+    {
+      "id": "ADR-2202-application-admin-console-baseline-roles",
+      "kind": "adr",
+      "path": "adrs/adr-2202-application-admin-console-baseline-roles.json",
+      "elicited": true,
+      "standardsTraceClause": "SaaS UI research 2026"
+    },
+    {
+      "id": "ADR-2203-application-admin-console-invite-transport",
+      "kind": "adr",
+      "path": "adrs/adr-2203-application-admin-console-invite-transport.json",
+      "recommendedDefault": true,
+      "elicited": true,
+      "standardsTraceClause": "generic enterprise practice"
+    },
+    {
+      "id": "ADR-2204-application-admin-console-audit-retention",
+      "kind": "adr",
+      "path": "adrs/adr-2204-application-admin-console-audit-retention.json",
+      "elicited": true,
+      "standardsTraceClause": "generic enterprise practice"
+    }
+  ]
+}

package/blueprints/application-admin-console/contributions/adrs/adr-2201-application-admin-console-capability-vocabulary.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-2201-application-admin-console-capability-vocabulary",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Capability vocabulary: principalDirectory, roleModel, tenancy, auditLog as the v1 capability set",
+  "context": "Admin-console surfaces are conditional on what the applied identity blueprint provides. The vocabulary must be small (four strings today), extensible (the section 6a table is chunk-zero, so a future capability lands with a docs edit and no code change), and grounded in industry practice (SaaS UI research, IAM literature). Baz decision 5 (2026-09-04) is that the initial four capabilities are principalDirectory, roleModel, tenancy and auditLog.",
+  "decision": "v1.0.0 declares four capability strings the applied identity blueprints can declare in their capabilities[] field: principalDirectory (identifies principals for a users surface); roleModel (declares operator-visible role labels for a permission matrix); tenancy (declares an organisation abstraction the console can switch across); auditLog (emits an event stream the audit view can read). The vocabulary lives in packages/rcf-lite/docs/blueprint-authoring.md section 6a as a table extending the roles registry; the loader validates capability SHAPE (lower camelCase on ^[a-z][a-zA-Z0-9]*$), not the vocabulary. A future capability lands by adding a table row and adopting it on an identity blueprints minor bump.",
+  "consequences": "The console renders only surfaces the applied capabilities enable, so a bare magic-link project gets a users surface but no roles surface (per Bazs verbatim example). A future dedicated audit-log blueprint declaring auditLog directly (rather than through observability-logging) composes cleanly. A new capability lands additively.",
+  "alternativesConsidered": [
+    {
+      "name": "Encode the vocabulary in code as an enum",
+      "summary": "Refuse any capability string outside the initial four at the loader.",
+      "reasonNotChosen": "Constrains a future capability behind a rcf-lite release; the section 6a chunk-zero pattern is the ratified convention for vocabulary in prose."
+    },
+    {
+      "name": "Use providesRoles[] for capabilities",
+      "summary": "Overload the existing providesRoles[] field to carry capabilities.",
+      "reasonNotChosen": "providesRoles paired with a scope:global ADR by design; a capability is a projection of the applied blueprints own state, not a role it offers to a second consumer. Overloading blurs the mechanism (spec 5.5.3)."
+    }
+  ],
+  "createdAt": "2026-09-05T01:30:00Z",
+  "updatedAt": "2026-09-05T01:30:00Z"
+}

package/blueprints/application-admin-console/contributions/adrs/adr-2202-application-admin-console-baseline-roles.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-2202-application-admin-console-baseline-roles",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Owner + Admin + Member + Viewer baseline; elicited additions per project",
+  "context": "A permission matrix needs a starting role set. SaaS UI research 2026 (industry sources including Auth0, Okta, Clerk internal role catalogues; NN/g admin-console pattern research) converges on the four-role Owner + Admin + Member + Viewer baseline as the modal starter posture. Every project has its own domain-specific additions (SupportAgent, Auditor, Reviewer), so the baseline is the floor, not the ceiling.",
+  "decision": "v1.0.0 declares Owner, Admin, Member, Viewer as the baseline four role labels the console renders in the matrix. The project elicits additional labels at apply time via the baselineRoles elicit (when the roleModel capability is applied); the baseline four render first, additions after. The four labels are prose, not code: a projects auth blueprint may map them to internal role ids at surface time.",
+  "consequences": "A fresh project applying admin-console with clerk (declares roleModel) gets a working matrix at Owner + Admin + Member + Viewer immediately; a project with domain-specific roles adds them via the elicit answer without a code change. The mapping between baseline label and internal role id is the applying projects concern (industry practice: label vs id decoupling).",
+  "alternativesConsidered": [
+    {
+      "name": "Elicit the entire role set",
+      "summary": "No baseline; every project elicits their own four-plus roles.",
+      "reasonNotChosen": "Adds friction for the modal case (the Owner/Admin/Member/Viewer baseline covers most greenfield projects) and pushes cognitive load onto the operator every apply."
+    },
+    {
+      "name": "Ship only two roles (Admin + User)",
+      "summary": "A tighter baseline.",
+      "reasonNotChosen": "The Admin/User binary loses the distinction between an operator (Admin), a paying customer (Member) and a shared read-only stakeholder (Viewer) that SaaS UI research treats as a load-bearing shape."
+    }
+  ],
+  "createdAt": "2026-09-05T01:30:00Z",
+  "updatedAt": "2026-09-05T01:30:00Z"
+}

package/blueprints/application-admin-console/contributions/adrs/adr-2203-application-admin-console-invite-transport.json

@@ -0,0 +1,20 @@
+{
+  "adrId": "ADR-2203-application-admin-console-invite-transport",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Invite transport: email default (delegated to the email sibling), elicited",
+  "context": "A users surface invite action needs a delivery transport. The shelf ships an email sibling under the application-notifications family (application-notifications-email, reserved as a family-prefix); a projects transport preference varies (email is the modal case; a Slack- or Teams-first workplace prefers a chat transport; an in-app-only demo needs no external transport).",
+  "decision": "v1.0.0 declares email as the recommended default invite transport; the console delegates delivery to the applied application-notifications-email sibling when present, otherwise records the invite as a pending event on the notification centre for a later transport to pick up. The transport is elicited at apply time via the inviteTransport elicit (enum: email, in-app-only, custom), so the console does not hardcode the delivery path.",
+  "consequences": "A project on the modal SaaS shape (email invite) gets a working invite path once application-notifications-email lands (currently reserved). A project that wants in-app-only invites picks that at apply. A future custom transport declares its own capability and the console delegates via the same elicit.",
+  "alternativesConsidered": [
+    {
+      "name": "Hard-code email as the transport",
+      "summary": "The invite always writes to the email sibling.",
+      "reasonNotChosen": "Refuses in-app-only demos and projects that want a chat-first workplace, and couples the console tightly to one shelf sibling."
+    }
+  ],
+  "createdAt": "2026-09-05T01:30:00Z",
+  "updatedAt": "2026-09-05T01:30:00Z"
+}

package/blueprints/application-admin-console/contributions/adrs/adr-2204-application-admin-console-audit-retention.json

@@ -0,0 +1,20 @@
+{
+  "adrId": "ADR-2204-application-admin-console-audit-retention",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Audit-log retention window: elicited (default 90 days when auditLog is applied)",
+  "context": "The audit view reads the applied logging companions event stream. Retention windows are domain-specific (finance and healthcare regulations push retention to years; consumer SaaS often trims to 90 days for storage cost and privacy hygiene). The console does not own the retention decision; the applying project does.",
+  "decision": "v1.0.0 declares audit-log retention as an elicited parameter (auditRetentionDays elicit, kind:string default \"90\", when: auditLog is applied). The console renders the audit view with the elicited window; the applied logging companion is responsible for actually enforcing the retention at the write layer. The console suppresses the audit view when the auditLog capability is not applied.",
+  "consequences": "A projects audit view honours the elicited window; the write-side retention is the loggers job (the console does not delete rows from the log). A project on a heavily-regulated domain elicits a longer window at apply; a consumer SaaS defaults to 90 days.",
+  "alternativesConsidered": [
+    {
+      "name": "Hard-code a 90-day retention",
+      "summary": "The console reads the last 90 days only.",
+      "reasonNotChosen": "Refuses regulated-domain projects that need to render older entries in the surface; the retention question is authentically the projects, not the shelfs."
+    }
+  ],
+  "createdAt": "2026-09-05T01:30:00Z",
+  "updatedAt": "2026-09-05T01:30:00Z"
+}

package/blueprints/application-admin-console/contributions/requirements/application-admin-console-req-001.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "application-admin-console-REQ-001",
+  "prdId": "PRD-001",
+  "title": "The application ships an admin-console shell with navigation across the applied capability set and no dead links",
+  "description": "The application realises an admin-console surface whose navigation, on load, reads the applied blueprints capability declarations (via source read-back on manifest.blueprints[]) and renders links only for the surfaces the applied capabilities enable. A surface whose gating capability is not applied is neither linked nor reachable from the shell. The shell is the base surface REQ-002 to REQ-006 elaborate on.",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "Per visual round spec section 5.5, REQ 1 of the admin-console blueprint.",
+  "tags": [
+    "blueprint:application-admin-console",
+    "category:01-shell"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-05T01:30:00Z",
+  "updatedAt": "2026-09-05T01:30:00Z"
+}

package/blueprints/application-admin-console/contributions/requirements/application-admin-console-req-002.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "application-admin-console-REQ-002",
+  "prdId": "PRD-001",
+  "title": "Users surface conditional on principalDirectory, with directory, invite, deactivate, last-active columns",
+  "description": "When an applied blueprint declares the principalDirectory capability, the console renders a users route: a directory table listing every principal identified by data-user-id, an invite control per row for a principal without an active session, a deactivate control per row for an active principal, and last-active plus status columns. A principal without admin scope reaching /admin renders an access-denied state (REQ-006) with a request-access control routed to a notification. The users table is a datatable (T-1 consumer) with the same ARIA APG contract.",
+  "category": "functional",
+  "domain": "application",
+  "priority": "must",
+  "rationale": "Per visual round spec section 5.5, REQ 2 of the admin-console blueprint.",
+  "tags": [
+    "blueprint:application-admin-console",
+    "category:02-users"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-05T01:30:00Z",
+  "updatedAt": "2026-09-05T01:30:00Z"
+}