rcf-lite 0.26.0 → 0.28.0

package/blueprints/application-account-settings/contributions/user-stories/application-account-settings-us-25112.json

@@ -0,0 +1,77 @@
+{
+  "usId": "application-account-settings-US-25112",
+  "prdId": "PRD-001",
+  "reqId": "application-account-settings-REQ-009",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Custom-auth provides-* boolean elicits each bind one applied-capabilities token on the sidecar",
+  "asA": "operator applying the account-settings on a project running its own auth (no shipped security-auth-* blueprint)",
+  "iWant": "each of the four custom-auth-provides-* boolean elicits to bind its capability token onto the sidecar's appliedCapabilities union with a per-token clause (true adds; false omits)",
+  "soThat": "the shell reads the exact capability union the elicited answers produce and no downstream surface guesses at what a custom auth has declared",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-25112-1",
+      "description": "When the manifest elicit `blueprint.json.elicits[id=custom-auth-provides-principal-directory]` is answered `true`, the sidecar written by the elicitation phase records `principalDirectory` as a member of `appliedCapabilities`; when the same elicit is answered `false`, the sidecar records no `principalDirectory` entry in `appliedCapabilities`, per REQ-009. Applying agent sets: the boolean answer to `custom-auth-provides-principal-directory`.",
+      "given": "a project running its own auth with the elicit `custom-auth-provides-principal-directory` presented at apply",
+      "when": "the elicitation phase runs and writes the sidecar",
+      "then": "the sidecar the shell reads records `principalDirectory` in `appliedCapabilities` when the answer is `true` and omits it when the answer is `false`",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-2602-application-account-settings-capability-discovery",
+        "field": "responsibilities.runElicitationPhase"
+      }
+    },
+    {
+      "id": "AC-25112-2",
+      "description": "When the manifest elicit `blueprint.json.elicits[id=custom-auth-provides-credential-self-service]` is answered `true`, the sidecar written by the elicitation phase records `credentialSelfService` as a member of `appliedCapabilities`; when the same elicit is answered `false`, the sidecar records no `credentialSelfService` entry in `appliedCapabilities`, per REQ-009. Applying agent sets: the boolean answer to `custom-auth-provides-credential-self-service`.",
+      "given": "a project running its own auth with the elicit `custom-auth-provides-credential-self-service` presented at apply",
+      "when": "the elicitation phase runs and writes the sidecar",
+      "then": "the sidecar the shell reads records `credentialSelfService` in `appliedCapabilities` when the answer is `true` and omits it when the answer is `false`",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-2602-application-account-settings-capability-discovery",
+        "field": "responsibilities.runElicitationPhase"
+      }
+    },
+    {
+      "id": "AC-25112-3",
+      "description": "When the manifest elicit `blueprint.json.elicits[id=custom-auth-provides-session-inventory]` is answered `true`, the sidecar written by the elicitation phase records `sessionInventory` as a member of `appliedCapabilities`; when the same elicit is answered `false`, the sidecar records no `sessionInventory` entry in `appliedCapabilities`, per REQ-009. Applying agent sets: the boolean answer to `custom-auth-provides-session-inventory`.",
+      "given": "a project running its own auth with the elicit `custom-auth-provides-session-inventory` presented at apply",
+      "when": "the elicitation phase runs and writes the sidecar",
+      "then": "the sidecar the shell reads records `sessionInventory` in `appliedCapabilities` when the answer is `true` and omits it when the answer is `false`",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-2602-application-account-settings-capability-discovery",
+        "field": "responsibilities.runElicitationPhase"
+      }
+    },
+    {
+      "id": "AC-25112-4",
+      "description": "When the manifest elicit `blueprint.json.elicits[id=custom-auth-provides-hosted-identity-ui]` is answered `true`, the sidecar written by the elicitation phase records `hostedIdentityUi` as a member of `appliedCapabilities`; when the same elicit is answered `false`, the sidecar records no `hostedIdentityUi` entry in `appliedCapabilities`, per REQ-009. Applying agent sets: the boolean answer to `custom-auth-provides-hosted-identity-ui`.",
+      "given": "a project running its own auth with the elicit `custom-auth-provides-hosted-identity-ui` presented at apply",
+      "when": "the elicitation phase runs and writes the sidecar",
+      "then": "the sidecar the shell reads records `hostedIdentityUi` in `appliedCapabilities` when the answer is `true` and omits it when the answer is `false`",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-2602-application-account-settings-capability-discovery",
+        "field": "responsibilities.runElicitationPhase"
+      }
+    }
+  ],
+  "tacIds": [
+    "TAC-2602-application-account-settings-capability-discovery"
+  ],
+  "tags": [
+    "blueprint:application-account-settings"
+  ],
+  "createdAt": "2026-09-10T00:00:00Z",
+  "updatedAt": "2026-09-10T00:00:00Z"
+}

package/blueprints/application-account-settings/docs/topics.md

@@ -2,12 +2,12 @@
 
 ## Global topics
 
-The blueprint claims no new global topics at v1.0.0. Account-settings is a consumer of the identity capability set the applied auth blueprints (and the observability-logging companion) declare through `capabilities[]`; every ADR (capability-vocabulary extension, security-surface-shape, theme-persistence, reauth-window) is non-global.
+The blueprint claims no new global topics at v1.0.0. Account-settings is a consumer of the identity capability set the applied auth blueprints declare through `capabilities[]`; every ADR (capability-vocabulary extension, security-surface-shape, theme-persistence, reauth-window) is non-global.
 
 ## Deliberately unclaimed topics
 
 - `themePersistence` (the shape of theme persistence). Reserved for the applied `application-spa` blueprint's own ADR set; the account-settings blueprint offers the operator surface for choosing the theme and hands the persistence to the SPA blueprint via the elicited `theme-persistence` answer.
-- `sessionInventory` (the shape of a session-inventory record). Reserved for the applied provider's ADR set (an auth blueprint, or observability-logging as the logging-projection provider). The account-settings blueprint reads the inventory through the applied provider's interface.
+- `sessionInventory` (the shape of a session-inventory record). Owner: security-auth-clerk TAC-1003-security-auth-clerk-session-verifier field interfaces.sessionInventory (the shape any auth blueprint declaring the capability agrees to). observability-logging 1.3.0 no longer provides it; the account-settings blueprint reads the inventory through the applied auth provider only.
 - `credentialSelfService` (the shape of a credential surface). Reserved for the applied auth blueprint's ADR set for the same reason.
 - `hostedIdentityUi` (the shape of a hosted identity portal). Reserved for the applied auth blueprint's ADR set for the same reason.
 
@@ -43,8 +43,8 @@ The shelf-wide band registry lives in `packages/rcf-lite/docs/blueprint-authorin
 
 ## Cross-references
 
-- `application-empty-error-states` (T-1, shipped v1.0.0): the shell composes on the `forbidden` and `empty-list` states rather than inventing bespoke access-denied UI. Every project applying `application-account-settings` should also apply `application-empty-error-states`.
-- `application-admin-console` (T-5, shipped v1.0.0): shares the capability-declaration mechanism (`capabilities[]` on identity blueprints) and the apply-time discovery, refusal and custom-auth elicitation. The two blueprints are separate consumers (the account-settings surface is per-principal; the admin-console surface is per-operator-with-admin-scope) and never render the same surface.
+- `application-empty-error-states` (shipped v1.0.0): the shell composes on the `forbidden` and `empty-list` states rather than inventing bespoke access-denied UI. Every project applying `application-account-settings` should also apply `application-empty-error-states`.
+- `application-admin-console` (shipped v1.0.0): shares the capability-declaration mechanism (`capabilities[]` on identity blueprints) and the apply-time discovery, refusal and custom-auth elicitation. The two blueprints are separate consumers (the account-settings surface is per-principal; the admin-console surface is per-operator-with-admin-scope) and never render the same surface.
 
 ## Probe pack
 

package/blueprints/application-account-settings/guide/application-account-settings.md

@@ -20,7 +20,7 @@ You want an anonymous product (no principal, no profile). The blueprint refuses
 
 ## Mechanism-reach gaps
 
-The blueprint's README lists the runtime-observable ACs the pack does NOT bind directly. Every gap is a candidate for a v1.1.0 minor bump extending the pack; the shipped v1.0.0 pack anchors the five load-bearing surface checks. Combine with the round-3 T-1 datatable pack to reach the sessions and notification-preferences shells' state-region contract.
+The blueprint's README lists the runtime-observable ACs the pack does NOT bind directly. Every gap is a candidate for a v1.1.0 minor bump extending the pack; the shipped v1.0.0 pack anchors the five load-bearing surface checks. Combine with the round-3 datatable pack to reach the sessions and notification-preferences shells' state-region contract.
 
 ## Promotion signals
 

package/blueprints/application-account-settings/probe-packs/application-account-settings.pack.mjs

@@ -11,12 +11,12 @@
 //   AC-25108-1 theme surface renders the radiogroup and persists per the elicited
 //              theme-persistence (fires when application-spa is applied via caps)
 //
-// Every check drives the real Playwright browser the T-0 runner injects and reads
+// Every check drives the real Playwright browser the runner injects and reads
 // its per-check applicability from the blueprint applied sidecar
 // (rcf/blueprints/application-account-settings.applied.json) written by the apply
 // verb: an absent capability records verdict: skipped and the aggregate treats the
 // check as neither pass nor fail (spec section 3.3, rcf-schemas 0.6.1 has no
-// applicable: false field, per round-3 T-5 precedent).
+// applicable: false field, per round-3 precedent).
 //
 // Sample-app fixture: packages/rcf-lite/test/fixtures/probe-pack-application-account-settings/.
 // The fixture ships CAPS and APPS env / ?caps= / ?apps= switches mirroring the

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

@@ -1,23 +1,85 @@
 # application-admin-console CHANGELOG
 
+## 1.3.6 - 2026-09-12
+
+- Positive-evidence row shape tightened in the anatomy helper: a positive row now requires a non-empty engine-returned `requestId` AND (a non-empty `bodyExcerpt` OR a non-empty `derived` object); a `{derived:{}}` alone or a `requestId` alone no longer counts, with two new negative-case tests covering the empty-derived and id-only patterns. Anatomy negative-variant map extended with `{brk:"local-login-form", probes:["sign-in-access-gated-surface"]}` so the shipped `?break=local-login-form` fixture switch drives the positive AC-21816-1 local-login row to fail (the break drops the `[data-role="local-login-form"]` region on the sign-in surface). No probe or fixture behaviour change on the admin-console family beyond the anatomy shape helper and the negative-variant coverage.
+
+## 1.3.5 - 2026-09-12
+
+- Rule-7d shape fix on every de-claimed conformance row across users-directory (four AC-21102-1 / AC-21102-2 rows), permission-matrix (AC-21103-1), org-switcher (AC-21104-1), audit-log (AC-21105-1) and sign-in-access-gated (AC-21815-2): each row now carries `anchorAcId: null` and names the anchored AC in the `limitation` field per the shipped shape (a `conformanceOnly:true` row must not simultaneously claim an anchor). Positive-observation rows on AC-21815-1, AC-21816-1 and the org-switcher AC-21104-2 no-tenancy branch stay anchored. Fixture README env-var manifest now declares `PROBE_BREAK` (the fixture reads it as an alternate to `ADMIN_CONSOLE_BREAK` / `?break=`) and the probe-utils `DECLARED_ENV` list mirrors the addition. Anatomy shape check tightened to reject an anchored `conformanceOnly` row (a positive evidence field no longer bypasses the null-anchor + limitation contract); a new negative-case test constructs an anchored `conformanceOnly` row and asserts the shape helper throws.
+
+## 1.3.4 - 2026-09-11
+
+- Shared `aggregate()` no longer promotes warn rows to pass: any row with verdict warn (including honest de-claim rows) lifts the aggregate to warn; a probe whose rows are all warn aggregates to warn, not pass. Shared teardown propagates a SIGKILL failure through the returned kill() promise instead of swallowing it. Overclaiming rows across users-directory (AC-21102-1, AC-21102-2), permission-matrix (AC-21103-1), org-switcher (AC-21104-1), audit-log (AC-21105-1) and sign-in-access-gated (AC-21815-2) are de-claimed to `conformanceOnly:true` with `verdict:'warn'` and a `limitation` field naming the anchored AC and the varied-input or browser-only clause that lives outside the Node HTTP probe. Positive-observation rows kept on AC-21815-1 (Access-gated Authorization-bearing surface), AC-21816-1 (local-login fallback) and the org-switcher no-tenancy 404 branch. Anatomy test extended with a negative-variant assertion that the shipped fixture break switches drive the affected probe aggregates to fail.
+
+## 1.3.3 - 2026-09-11
+
+- sign-in-access-gated-surface fixture now returns HTTP 403 with the `[data-surface="access-denied"]` region (and no `[data-role="principal-read"]` element) when `zeroTrustGate` is applied AND no Authorization header is present, wiring the previously-dead `renderSignInAccessDenied` branch to observe AC-21815-2's refusal contract server-side. The probe's AC-21815-2 row is now a positive-evidence row (HTTP 403 + access-denied surface + absence of principal-read) rather than a `notObservableHere` de-claim. Consumers that expected the previous 200-with-default-principal shape (`edge-cloudflare-access` TC-117, TC-118, TC-119 and its admin-console-gate-surface probe) send an Authorization header on the gated caps path; the local-login branch (no `zeroTrustGate`) is unchanged. Anatomy test extended to enumerate the shipped AC/REQ id set and refuse any row whose anchor is not in it, and to accept the conformance-only row shape.
+
+## 1.3.2 - 2026-09-11
+
+- users-directory-surface split into per-AC rows: AC-21102-1 anchors the directory listing observation; AC-21102-2 anchors the invite and deactivate controls (previously conflated on one row). org-switcher-surface fixture now returns HTTP 404 on the no-tenancy path so the probe can observe the AC-21104-2 refusal status (previously the fixture returned 200 with not-found HTML, contradicting the AC). audit-log-surface probe now drives a real write-then-read cycle: POST /api/members/:id/role writes an audit entry and GET /admin/audit reads it back, observing AC-21105-1 rather than a hard-coded table. sign-in-access-gated-surface probe now varies an Authorization principal and observes the derived email on the principal-read element; the local-fallback row is anchored under AC-21816-1. permission-matrix-grid vacuous `.every()` over an empty label array replaced with a check that asserts at least one label exists and every cell carries one per AC-21103-1. Positive-anchor-on-absence broken-variant rows removed. Rule 10 applied to every row detail. Anatomy test extended to accept notObservableHere row shape. Register cleanup.
+
+
+## 1.3.1 - 2026-09-11
+
+- Added a criterion-e probe pack (`contributions/probes/`) covering 5 properties the fixture engine at `packages/rcf-lite/test/fixtures/probe-pack-application-admin-console/server.js` answers: `users-directory-surface`, `permission-matrix-grid`, `org-switcher-surface`, `audit-log-surface`, `sign-in-access-gated-surface`. Every response now carries an `x-fixture-request-id` header; probes record the id, the HTTP status and a body excerpt as positive evidence per rule 7d. Fixture README declares every env var the pack reads. Anatomy test at `packages/rcf-lite/test/blueprint/application-admin-console-anatomy.test.js` pins the new pack files and asserts each result carries one of the four 7d evidence shapes.
+
+
+## 1.3.0 (2026-09-10)
+
+### Added
+
+- REQ-009: custom-auth-provides-* runtime clauses covering the four boolean elicits with a per-token clause on the applied capability union sidecar the shell reads.
+- Vendor citations on AC-21103-1 (ARIA APG grid) and AC-21106-1 (WCAG headings-and-labels), verified 2026-09-10.
+
+### Changed
+
+- ADR-2203.decision names the elicit as `blueprint.json.elicits[id=invite-transport]` (drops the camelCase inviteTransport spelling).
+- ADR-2204.decision names the elicit as `blueprint.json.elicits[id=audit-retention-days]`.
+- AC-21111-2 (and AC-21111-5) use `data-org-membership=*` per REQ-008 with ownerRef into REQ-008.
+- TAC-2214 responsibility named `renderAccessGatedSurface` so REQ-014.deliveredBy resolves.
+- AC-21107-1 and AC-21107-2 reference `TAC-2201.interfaces.capabilitiesSidecar` via ownerRef; TAC-2201 shape declares `skippedSources[]`.
+- US-21108 description carries the single-AC legality note verbatim.
+
+## 1.2.1 (register-sweep patch, 2026-09-10)
+
+- Register: neutral wording in shipped prose (no capability change).
+
+## 1.2.0 (2026-09-10)
+
+### Added
+
+- REQ-007 (invite-transport option coverage) and US-21110: every invite-transport option (email, in-app-only, custom) now carries a runtime clause and a story binding accepted, failed and recorded outcomes with a per-invite audit record.
+- REQ-008 (tenancy-shape option coverage) and US-21111: the elicited tenancy-shape (per-user, per-org, both) now determines directory membership, org switcher entries, invite scope and cross-shape refusal (TENANCY_SHAPE_REFUSAL).
+- Failure-path acceptance criteria on US-21106 (request-access POST failure) and US-21107 (empty union entry for a library-qualified source unavailable locally); failure-path AC on US-21815 for a gated request with no request.auth.
+- Vendor citations on the WCAG 2.4.6 / 3.3.4 / 4.1.3 fixed acceptance criteria and on the ARIA APG grid pattern criteria (verified 2026-09-10).
+
+### Changed
+
+- Every REQ now carries a deliveredBy link into TAC-2201, TAC-2203, TAC-2204 or TAC-2214.
+- Every AC on every user story now carries an explicit disposition (fixed or template); template ACs state the values the applying agent sets.
+- TAC-2201 responsibilities now include deliverInvite (per invite-transport branch), tenancyShapeGate (per tenancy shape), delegateUsersSurface, delegateOrgsSurface, renderAccessDenied and renderShell so the deliveredBy fields resolve.
+- REQ-005 extended with an audit-retention-days runtime clause naming the string elicit and its refusal branch; US-21105 gained a template AC (AC-21105-3) carrying `Applying agent sets: audit-retention-days.`.
+
 ## 1.1.0 (2026-09-07)
 
 ### Added
 
-- Consume the `zeroTrustGate` capability optionally at apply-time via the shipped `readAppliedCapabilities()` helper (the T-5 visual-round mechanism). When `zeroTrustGate` is in the applied capability set, `/admin/sign-in` renders the Access-gated sign-in surface: `[data-surface=access-gated]` with no local login form, plus a `[data-role=principal-read]` element carrying the principal email read from `request.auth`. When `zeroTrustGate` is absent the surface falls back to the local `security-auth-*` surface with `[data-surface=local-login]` and the existing local form. Additive minor: `requiresAppliedCapabilities.capabilities[]` stays `["principalDirectory"]` (Q4 default per Cloudflare round 6 spec section 5.4.1: making Access-gate hard is a v2.0 change).
+- Consume the `zeroTrustGate` capability optionally at apply-time via the shipped `readAppliedCapabilities()` helper (the visual-round mechanism). When `zeroTrustGate` is in the applied capability set, `/admin/sign-in` renders the Access-gated sign-in surface: `[data-surface=access-gated]` with no local login form, plus a `[data-role=principal-read]` element carrying the principal email read from `request.auth`. When `zeroTrustGate` is absent the surface falls back to the local `security-auth-*` surface with `[data-surface=local-login]` and the existing local form. Additive minor: `requiresAppliedCapabilities.capabilities[]` stays `["principalDirectory"]` (Q4 default per Cloudflare round 6 spec section 5.4.1: making Access-gate hard is a v2.0 change).
 - 6 new contributions on the admin-console shelf entry: 1 REQ (`application-admin-console-REQ-014`), 2 USs (`application-admin-console-US-21815` Access-gated sign-in, `application-admin-console-US-21816` fallback branch), 1 TAC (`TAC-2214-application-admin-console-access-gated-signin-surface`), 1 ADR (`ADR-2214-application-admin-console-consume-zero-trust-gate`, scope global on new topic `adminConsoleSignInSurface` with `standardsTraceClause: Cloudflare round 6 spec section 5.4 (admin-console v1.1.0 delta)` and `recommendedDefault: true`) and 1 pack check (`AC-21815-1`) on the existing `application-admin-console.pack.mjs`.
 - Sign-in route extension on the shipped `packages/rcf-lite/test/fixtures/probe-pack-application-admin-console/` fixture: a new `/admin/sign-in` route that renders the Access-gated or local-login surface based on the applied caps (`?caps=zeroTrustGate` picks the gated branch). The existing `?caps=` combinations are preserved; the `AC-21815-1` pack check exercises both branches.
 
 ### Composition
 
-- Rides the T-4 PR alongside `edge-cloudflare-access` v1.0.0 (round-4 T-4 capability-minor pattern). The Access-gated surface reads `request.auth.email`, which the shipped `edge-cloudflare-access` JWT validator sets after JWKS verification.
+- Rides the PR alongside `edge-cloudflare-access` v1.0.0 (round-4 capability-minor pattern). The Access-gated surface reads `request.auth.email`, which the shipped `edge-cloudflare-access` JWT validator sets after JWKS verification.
 
-## 1.0.0 (visual round T-5, spec 2026-09-04)
+## 1.0.0 (visual round, 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.
+- Initial shipped 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.
+- 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 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 (residual cure). Fifth shipped consumer of the earlier release 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.
+- Consumes `application-datatable` 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

@@ -26,7 +26,7 @@ Refuses with exit 3 and the spec 5.5.1 verbatim message on a project with no app
 | 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). |
+| `roleModel` | Permission matrix (`/admin/roles`) | Clerk, OAuth2, Keycloak. Magic-link does NOT declare it, so a bare-magic-link project gets NO roles surface (per the shipped spec section 5.5 worked example). |
 | `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/*`. |
@@ -68,7 +68,7 @@ Answers land on `rcf/blueprints/application-admin-console.applied.json`'s `appli
 
 ## 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.
+`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, 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.
 
@@ -83,7 +83,7 @@ Runtime-observable ACs the pack does NOT bind directly (checklist section 6.g),
 - **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-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 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.
@@ -95,4 +95,4 @@ Runtime-observable ACs the pack does NOT bind directly (checklist section 6.g),
 
 ## 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.
+The audit view consumes `application-datatable` 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

@@ -1,6 +1,6 @@
 {
   "slug": "application-admin-console",
-  "version": "1.1.0",
+  "version": "1.3.6",
   "category": "application",
   "requiresAppliedCapabilities": {
     "capabilities": [
@@ -129,6 +129,21 @@
       "kind": "req",
       "path": "requirements/application-admin-console-req-006.json"
     },
+    {
+      "id": "application-admin-console-REQ-007",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-007.json"
+    },
+    {
+      "id": "application-admin-console-REQ-008",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-008.json"
+    },
+    {
+      "id": "application-admin-console-REQ-009",
+      "kind": "req",
+      "path": "requirements/application-admin-console-req-009.json"
+    },
     {
       "id": "application-admin-console-US-21101",
       "kind": "us",
@@ -174,6 +189,21 @@
       "kind": "us",
       "path": "user-stories/application-admin-console-us-21109.json"
     },
+    {
+      "id": "application-admin-console-US-21110",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21110.json"
+    },
+    {
+      "id": "application-admin-console-US-21111",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21111.json"
+    },
+    {
+      "id": "application-admin-console-US-21112",
+      "kind": "us",
+      "path": "user-stories/application-admin-console-us-21112.json"
+    },
     {
       "id": "TAC-2201-application-admin-console-shell",
       "kind": "tac",
@@ -255,5 +285,7 @@
   ],
   "optionalCapabilities": [
     "zeroTrustGate"
-  ]
+  ],
+  "updatedAt": "2026-09-12T00:45:12Z",
+  "updatedIso": "2026-09-11T22:30:00Z"
 }

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

@@ -5,9 +5,9 @@
   "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.",
+  "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). The ratified 2026-09-04 shelf decision 5 lands the initial four capabilities as 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.",
+  "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 the shipped spec section 5.5 worked 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",

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

@@ -2,11 +2,11 @@
   "adrId": "ADR-2203-application-admin-console-invite-transport",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "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.",
+  "title": "Invite transport: elicited, vocabulary and default owned by the manifest elicit, delegated to the sibling resolved at apply time",
+  "context": "A users surface invite action needs a delivery transport. The shelf ships transport siblings under the application-notifications family; the manifest elicit `blueprint.json.elicits[id=invite-transport]` owns the option set (its `.options`) and the recommended default (its `.default`), and the console resolves the delegated sibling from the elicited value.",
+  "decision": "The transport is elicited at apply time via the manifest elicit `blueprint.json.elicits[id=invite-transport]`; the vocabulary and the default are owned by that elicit's `.options` and `.default` fields. The console delegates delivery to the sibling resolved from the elicited value (an applied `application-notifications-*` transport) when present, otherwise records the invite as a pending event on the notification centre for a later transport to pick up. The console does not hardcode the delivery path or restate the option set.",
   "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": [
     {
@@ -16,5 +16,5 @@
     }
   ],
   "createdAt": "2026-09-05T01:30:00Z",
-  "updatedAt": "2026-09-05T01:30:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

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

@@ -2,19 +2,19 @@
   "adrId": "ADR-2204-application-admin-console-audit-retention",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "accepted",
-  "title": "Audit-log retention window: elicited (default 90 days when auditLog is applied)",
+  "title": "Audit-log retention window: elicited, kind and default owned by the manifest elicit",
   "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.",
+  "decision": "Audit-log retention is an elicited parameter owned by the manifest elicit `blueprint.json.elicits[id=audit-retention-days]`; the elicit's `.kind`, `.default` and gating condition are the sole owner of those values. The console renders the audit view with the elicited window; the applied logging companion enforces 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 (its exact number lives on the manifest elicit); 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 accepts the manifest-owned default.",
   "alternativesConsidered": [
     {
-      "name": "Hard-code a 90-day retention",
-      "summary": "The console reads the last 90 days only.",
+      "name": "Hard-code a retention window",
+      "summary": "The console reads a fixed number of days.",
       "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"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-admin-console/contributions/adrs/adr-2214-application-admin-console-consume-zero-trust-gate.json

@@ -5,8 +5,8 @@
   "version": "1.1.0",
   "status": "accepted",
   "title": "Admin-console reads zeroTrustGate at apply-time and switches sign-in surface (scope global, adminConsoleSignInSurface)",
-  "context": "application-admin-console v1.0.0 shipped with principalDirectory as the sole hard requirement; the sign-in surface was local per whatever security-auth-* was applied. Round-6 T-4 introduces edge-cloudflare-access with the zeroTrustGate capability; a composed deployment needs the admin-console to flip its sign-in surface deterministically so the Access-gated deployment stops rendering the local login form.",
-  "decision": "application-admin-console v1.1.0 reads appliedCapabilities via readAppliedCapabilities at apply-time (the T-5 visual-round mechanism). When zeroTrustGate is present the sign-in surface renders access-gated (no local form, principal reads from request.auth); when absent the surface falls back to whatever security-auth-* is applied. Q4 default per spec 5.4.1: zeroTrustGate is CONSUMED OPTIONALLY; principalDirectory remains the sole hard requirement (making Access-gate hard is a v2.0 change). The adminConsoleSignInSurface topic scope is global on this blueprint at v1.1.0; the topic string is adminConsoleSignInSurface (camelCase, one concept per topic).",
+  "context": "application-admin-console v1.0.0 shipped with principalDirectory as the sole hard requirement; the sign-in surface was local per whatever security-auth-* was applied. round-6 introduces edge-cloudflare-access with the zeroTrustGate capability; a composed deployment needs the admin-console to flip its sign-in surface deterministically so the Access-gated deployment stops rendering the local login form.",
+  "decision": "application-admin-console v1.1.0 reads appliedCapabilities via readAppliedCapabilities at apply-time (the visual-round mechanism). When zeroTrustGate is present the sign-in surface renders access-gated (no local form, principal reads from request.auth); when absent the surface falls back to whatever security-auth-* is applied. Q4 default per spec 5.4.1: zeroTrustGate is CONSUMED OPTIONALLY; principalDirectory remains the sole hard requirement (making Access-gate hard is a v2.0 change). The adminConsoleSignInSurface topic scope is global on this blueprint at v1.1.0; the topic string is adminConsoleSignInSurface (camelCase, one concept per topic).",
   "consequences": "The v1.1.0 admin-console remains backward-compatible with every v1.0.0 deployment. An Access-gated deployment automatically stops rendering the local login form (the shipped pack check AC-21815-1 catches a stray local-login region under zeroTrustGate). The fallback branch (local-login surface) ships in v1.1.0 unchanged; a v2.0.0 that makes Access-gate hard would remove the fallback branch (breaking-change). Standards trace clause: Cloudflare round 6 spec section 5.4 (admin-console v1.1.0 delta).",
   "alternativesConsidered": [
     {
@@ -17,7 +17,7 @@
     {
       "name": "Ship two admin-console blueprints (local-only and access-gated)",
       "summary": "Split the surface across two slugs so the operator picks at apply.",
-      "reasonNotChosen": "Doubles the shelf surface area and duplicates every other contribution. The applied-capability read is the shipped mechanism for exactly this composition (T-5 visual-round)."
+      "reasonNotChosen": "Doubles the shelf surface area and duplicates every other contribution. The applied-capability read is the shipped mechanism for exactly this composition (visual-round)."
     }
   ],
   "createdAt": "2026-09-07T16:00:00.000Z",

package/blueprints/application-admin-console/contributions/probes/audit-log-surface.mjs

@@ -0,0 +1,79 @@
+// application-admin-console probe: audit-log surface (AC-21105-1).
+//
+// AC-21105-1 requires: given a role change AND the auditLog capability
+// applied, an audit-log entry writes with actor, target, before, after,
+// timestamp and correlationId from the logging companion; the entry
+// surfaces on the audit view table where every row is enumerable by
+// data-audit-id and every cell exposes its column via a data-column
+// attribute.
+//
+// The probe drives a real role change: POST /api/members/:id/role,
+// then GET /admin/audit and assert the DOM row for the new audit id
+// carries the changed before/after values. Row detail opens on the
+// first eight words of AC-21105-1 (rule 10).
+
+import { fixtureFetch, startFixture, excerpt } from './probe-utils.mjs';
+
+export const anchorAcId = 'application-admin-console-AC-21105-1';
+export const accountBound = false;
+
+export default async function runProbe() {
+  const fixture = await startFixture({ env: { ADMIN_CONSOLE_CAPS: 'principalDirectory,auditLog' } });
+  const results = [];
+  try {
+    // Drive the role change and capture the emitted audit id.
+    const targetMemberId = 'u3';
+    const nextRole = 'Admin';
+    const postRes = await fixtureFetch(fixture.url, `/api/members/${targetMemberId}/role`, {
+      method: 'POST',
+      headers: { 'content-type': 'application/json' },
+      body: JSON.stringify({ role: nextRole, actor: 'probe@example.test' }),
+    });
+    let postBody = null;
+    try { postBody = JSON.parse(postRes.body); } catch { postBody = null; }
+    const newAuditId = postBody && typeof postBody.auditId === 'string' ? postBody.auditId : null;
+    const postBefore = postBody && typeof postBody.before === 'string' ? postBody.before : null;
+    const postAfter = postBody && typeof postBody.after === 'string' ? postBody.after : null;
+
+    // GET the audit view and assert the new audit row is present with
+    // the changed before/after and every required column carries a
+    // data-column attribute.
+    const r = await fixtureFetch(fixture.url, '/admin/audit');
+    const rowIds = [...new Set([...r.body.matchAll(/data-audit-id="([^"]+)"/g)].map((m) => m[1]))];
+    const requiredColumns = ['actor', 'target', 'before', 'after', 'timestamp', 'correlationId'];
+    const allColumnsPresent = requiredColumns.every((col) => new RegExp(`<th data-column="${col}">`).test(r.body));
+    const newRowRegex = newAuditId
+      ? new RegExp(`<tr data-audit-id="${newAuditId}">[^]*?</tr>`)
+      : null;
+    const newRow = newRowRegex ? (r.body.match(newRowRegex) || [null])[0] : null;
+    const rowHasBefore = !!newRow && !!postBefore && new RegExp(`<td data-column="before">${postBefore}</td>`).test(newRow);
+    const rowHasAfter = !!newRow && !!postAfter && new RegExp(`<td data-column="after">${postAfter}</td>`).test(newRow);
+    const rowHasCorrelation = !!newRow && /<td data-column="correlationId">corr-/.test(newRow);
+    const everyCellHasDataColumn = !!newRow && (newRow.match(/<td data-column="[^"]+">/g) || []).length === requiredColumns.length;
+
+    const pass = postRes.status === 200 && r.status === 200 && !!r.requestId
+      && !!newAuditId && rowIds.includes(newAuditId)
+      && allColumnsPresent
+      && rowHasBefore && rowHasAfter && rowHasCorrelation
+      && everyCellHasDataColumn;
+
+    results.push({
+      anchorAcId: null,
+      conformanceOnly: true,
+      limitation: 'application-admin-console-AC-21105-1: actor / target / timestamp equality and companion-log source provenance (external correlation from the logging companion) are not verified against a shipped log adapter by this Node HTTP probe; the write-then-read cycle (POST role change, GET audit surfaces the new row with correlationId) is a partial observation of AC-21105-1',
+      verdict: pass ? 'warn' : 'fail',
+      detail: pass
+        ? `Given a role change AND the auditLog capability applied: POST /api/members/${targetMemberId}/role returned 200 with auditId=${newAuditId} before=${postBefore} after=${postAfter}; subsequent GET /admin/audit surfaced the new row with data-audit-id=${newAuditId}, before/after cells matching the round-trip and a correlationId cell present; all six required columns (actor/target/before/after/timestamp/correlationId) rendered; x-fixture-request-id=${r.requestId}`
+        : `Given a role change AND the auditLog capability applied round-trip gap: postStatus=${postRes.status} auditStatus=${r.status} rid=${r.requestId} newAuditId=${newAuditId} newRowFound=${rowIds.includes(String(newAuditId))} allCols=${allColumnsPresent} rowHasBefore=${rowHasBefore} rowHasAfter=${rowHasAfter} rowHasCorrelation=${rowHasCorrelation} everyCellHasDataColumn=${everyCellHasDataColumn}`,
+      evidence: {
+        requestId: r.requestId,
+        responseStatus: r.status,
+        bodyExcerpt: excerpt(newRow || (r.body.match(/<tr data-audit-id="[^"]+">[^]{0,200}/) || [''])[0]),
+        derived: { postStatus: postRes.status, newAuditId, postBefore, postAfter, rowCount: rowIds.length, allColumnsPresent, rowHasBefore, rowHasAfter, rowHasCorrelation, everyCellHasDataColumn },
+      },
+    });
+  } finally {
+    await fixture.kill();
+  }
+  return { results };
+}

package/blueprints/application-admin-console/contributions/probes/org-switcher-surface.mjs

@@ -0,0 +1,83 @@
+// application-admin-console probe: org switcher surface across the
+// two shipped ACs for the org-switcher story - the tenancy-applied
+// render contract (AC-21104-1) and the tenancy-absent suppression
+// contract (AC-21104-2). Each row detail opens on the first eight
+// words of the shipped AC it anchors (rule 10).
+//
+// AC-21104-1 requires: with tenancy applied, the shell renders
+// [data-role="org-switcher"] on the console header; when tenancy is
+// not applied, neither the control nor the org-scoped invite path is
+// rendered nor reachable.
+//
+// AC-21104-2 requires: when tenancy is NOT applied, the orgs route is
+// suppressed (not linked in the shell navigation and returning 404 or
+// the shared forbidden state on direct URL); the org switcher control
+// is absent from the DOM on every route.
+
+import { fixtureFetch, startFixture, excerpt } from './probe-utils.mjs';
+
+export const anchorAcId = 'application-admin-console-AC-21104-1';
+export const accountBound = false;
+
+export default async function runProbe() {
+  const results = [];
+  const withTenancy = await startFixture({ env: { ADMIN_CONSOLE_CAPS: 'principalDirectory,tenancy' } });
+  try {
+    // Row 1: AC-21104-1 tenancy-applied render.
+    const r = await fixtureFetch(withTenancy.url, '/admin/orgs');
+    const switcherCount = (r.body.match(/data-role="org-switcher"/g) || []).length;
+    const orgsLinkInNav = /<nav[^>]*data-role="primary-nav"[^]*?<a[^>]*href="\/admin\/orgs">Orgs<\/a>[^]*?<\/nav>/.test(r.body);
+    const pass = r.status === 200 && !!r.requestId && switcherCount >= 1 && orgsLinkInNav;
+    results.push({
+      anchorAcId: null,
+      conformanceOnly: true,
+      limitation: 'application-admin-console-AC-21104-1: the users invite-path organization selector for scoping the invite (the AC clause beyond the general header selector) is not present in this fixture and not observed by this Node HTTP probe; the general header org-selector walk is a partial observation of AC-21104-1',
+      verdict: pass ? 'warn' : 'fail',
+      detail: pass
+        ? `Given an applied blueprint declaring tenancy, the shell rendered [data-role="org-switcher"] count=${switcherCount} on the console header and the Orgs link is present in the primary navigation; GET /admin/orgs returned 200; x-fixture-request-id=${r.requestId}`
+        : `Given an applied blueprint declaring tenancy, the shell tenancy-on gap: status=${r.status} rid=${r.requestId} switcher=${switcherCount} orgsNavLink=${orgsLinkInNav}`,
+      evidence: {
+        requestId: r.requestId,
+        responseStatus: r.status,
+        bodyExcerpt: excerpt((r.body.match(/data-role="org-switcher"[^]{0,140}/) || [''])[0]),
+        derived: { switcherCount, orgsLinkInNav, capsIncludesTenancy: true },
+      },
+    });
+  } finally {
+    await withTenancy.kill();
+  }
+
+  const noTenancy = await startFixture({ env: { ADMIN_CONSOLE_CAPS: 'principalDirectory' } });
+  try {
+    // Row 2: AC-21104-2 tenancy-absent suppression.
+    // The AC mandates 404 or forbidden on direct URL AND no orgs link
+    // in nav AND no switcher control on any route.
+    const directOrgs = await fixtureFetch(noTenancy.url, '/admin/orgs');
+    const home = await fixtureFetch(noTenancy.url, '/admin');
+    const statusIsRefused = directOrgs.status === 404 || directOrgs.status === 403;
+    const orgsLinkInNav = /href="\/admin\/orgs">Orgs</.test(home.body);
+    const switcherOnHome = /data-role="org-switcher"/.test(home.body);
+    const switcherOnOrgs = /data-role="org-switcher"/.test(directOrgs.body);
+    const suppressionPass = !!directOrgs.requestId && !!home.requestId
+      && statusIsRefused
+      && !orgsLinkInNav
+      && !switcherOnHome
+      && !switcherOnOrgs;
+    results.push({
+      anchorAcId: 'application-admin-console-AC-21104-2',
+      verdict: suppressionPass ? 'pass' : 'fail',
+      detail: suppressionPass
+        ? `When tenancy is NOT applied, the orgs route was suppressed: GET /admin/orgs returned ${directOrgs.status} (404 or 403 as the AC requires); no /admin/orgs link in the shell nav; no [data-role="org-switcher"] on /admin or on the refused /admin/orgs response; x-fixture-request-id=${directOrgs.requestId}`
+        : `When tenancy is NOT applied, the orgs route suppression gap: orgs status=${directOrgs.status} orgsRid=${directOrgs.requestId} homeRid=${home.requestId} statusRefused=${statusIsRefused} orgsNavLink=${orgsLinkInNav} switcherOnHome=${switcherOnHome} switcherOnOrgs=${switcherOnOrgs}`,
+      evidence: {
+        requestId: directOrgs.requestId,
+        responseStatus: directOrgs.status,
+        bodyExcerpt: excerpt(directOrgs.body),
+        derived: { statusIsRefused, orgsLinkInNav, switcherOnHome, switcherOnOrgs, capsIncludesTenancy: false },
+      },
+    });
+  } finally {
+    await noTenancy.kill();
+  }
+  return { results };
+}