rcf-lite 0.20.0 → 0.22.0

package/blueprints/persistence-data-postgres/guide/persistence-data-postgres.md

@@ -0,0 +1,172 @@
+# persistence-data-postgres guide
+
+## What this blueprint gets you
+
+Postgres as your project's primary durable relational store on any server-tier deployment (a long-lived Node process, a container platform, a non-Workers serverless target). The store facade is the sole reader of the `pg` (node-postgres) client in your source tree; consumer code calls named domain verbs on the facade and never touches `pg` directly. Schema evolution is numbered forward-only `.sql` files applied one file per transaction; a `schema_version` bookkeeping table is the single source of truth on what has been applied. Multi-statement writes with atomicity go through a transaction helper that wraps `BEGIN` and `COMMIT` around a callback and rolls back on any error. Recovery is two-path: a scheduled `pg_dump` artefact plus the deploy target's own point-in-time recovery. The v1.0.0 facade holds the driver reference opaque at the ADR-2801 boundary so the round-6 Hyperdrive v1.1.0 adapter slots in as an additive minor without a facade re-shape.
+
+## Apply this blueprint
+
+```sh
+rcf define blueprint add persistence-data-postgres
+```
+
+On a fresh project this applies cleanly. On a project that already applied `persistence-data-sqlite` or `persistence-data-d1`, `rcf define blueprint add persistence-data-postgres` surfaces a DELIBERATE conflict on the `persistenceStore` and `migrationDiscipline` global-ADR topics. Resolve with one project-level ADR per topic; the operator picks the engine end to end.
+
+## Facade shape
+
+```js
+import { createStore } from './store.mjs';
+
+const store = createStore({
+  connectionUrl: process.env.DATABASE_URL,
+  onEvent: (evt) => logger.info(evt),
+  poolConfig: { max: 10 },
+});
+
+await store.ready();
+const id = await store.createUser('alice', 'alice@example.com');
+const row = await store.getUserById(id);
+```
+
+The facade opens a `pg.Pool` against the elicited connection URL and emits `facadeReady` exactly once on the first successful ready-check. Every `.query` call passes a static string literal as its first argument with parameters as `$1, $2, ... $N` per the node-postgres parameterised-queries contract at https://node-postgres.com/features/queries. Consumers destructure the verbs they need at their top level and hold the facade reference for the process lifetime (or, on a request-scoped container platform, for the request lifetime).
+
+## Migrations
+
+Numbered forward-only `.sql` files under an elicited `migrations/` directory. Each filename begins with a monotonic integer (`001_...`, `002_...`, `003_...`); the file body is engine-native SQL. The in-tree runner (TAC-2802) applies each file inside its own transaction and records the applied filename in `schema_version`.
+
+```sh
+node src/migrate.mjs
+```
+
+Which runner tool the project reaches for is elicited on ADR-2802 (bespoke Node runner is the shipped default; `node-pg-migrate`, `sqitch`, and `flyway` are named alternatives). Every runner honours the same discipline: numbered forward-only files, one file one transaction, a `schema_version` bookkeeping row per applied file.
+
+Runner mode is elicited on ADR-2803:
+
+- `atBoot` (default for long-lived Node): the facade invokes the runner on process start before opening the first query.
+- `ciStep` (default for Workers-adjacent or request-scoped container targets): the CI pipeline invokes the runner as a deploy step against the target's own connection before the artefact promotes.
+
+## Transactions
+
+```js
+await store.withTransaction(async (tx) => {
+  await tx.query('INSERT INTO orders(user_id, total) VALUES ($1, $2)', [userId, total]);
+  await tx.query('INSERT INTO order_lines(order_id, sku, qty) VALUES ($1, $2, $3)', [orderId, sku, qty]);
+});
+```
+
+The helper wraps `BEGIN` and `COMMIT` around the callback. If any statement throws, the helper issues `ROLLBACK`, fires `transactionRolledBack` with the failing statement's zero-based index and the pg error code, and re-throws the underlying error. No partial commit lands on the shipped database.
+
+## Recovery
+
+Two paths, both required:
+
+```js
+import { exportDatabase, recoveryDrill } from './recovery.mjs';
+
+const { artefactPath, completedAt } = await exportDatabase({
+  connectionUrl: process.env.DATABASE_URL,
+  destination: process.env.BACKUP_DESTINATION,
+  onEvent: (evt) => logger.info(evt),
+});
+```
+
+Scheduled `pg_dump` runs on your project's cadence (an elicited cron string, a systemd timer spec, or off for CI-only invocation); the runner writes the artefact via `child_process.execFile` and emits `backupExported` on completion. The deploy target's own point-in-time recovery is enabled with an elicited retention window; on a managed cluster, the window is the cluster's PITR setting; on a self-managed cluster, the WAL-archive retention.
+
+Run a periodic recovery drill (US-27110):
+
+```js
+const { count, checksum } = await recoveryDrill({
+  sourceUrl: process.env.DATABASE_URL,
+  destination: process.env.BACKUP_DESTINATION,
+  onEvent: (evt) => logger.info(evt),
+});
+```
+
+The drill primes a fresh Postgres from the artefact and compares row-count and checksum on a fixture table on both databases; a mismatch signals artefact-shape drift before an incident forces a live restore.
+
+## Pool posture per deploy target
+
+Elicited on ADR-2805:
+
+- `longLivedNode` (default): long-lived `pg.Pool` for the process lifetime; shipped defaults pool size 10, `idleTimeoutMillis 30000`, `connectionTimeoutMillis 5000`.
+- `requestScopedContainer`: a pool sized to the request budget, disposed at request end; shipped defaults pool size 2, `idleTimeoutMillis 5000`, `connectionTimeoutMillis 3000`.
+- `hyperdriveManaged` (reserved for the round-6 v1.1.0 adapter): inherits Hyperdrive's own pool settings and holds no Node-side pool.
+
+Every default is overridable by the operator via elicited pool-config fields at apply time.
+
+## Advisory-lock helper (optional)
+
+Elicited on REQ-007 default `off`. When enabled to `session` or `transaction`, the facade exposes `withAdvisoryLock(key, callback)` that acquires and releases a session-level (via `pg_advisory_lock` / `pg_advisory_unlock`) or transaction-level (via `pg_advisory_xact_lock`; released automatically at COMMIT or ROLLBACK) lock per https://www.postgresql.org/docs/current/explicit-locking.html.
+
+Session-level locks survive rolled-back transactions; use `transaction` for the common case and pick `session` only when cross-transaction locking is the intent.
+
+## CI seam (GitHub Actions service containers)
+
+Add a `services:` block declaring `postgres:17-alpine` to your workflow. Per https://docs.github.com/en/actions/using-containerized-services/about-service-containers, the runner exposes the service either at the label hostname (for container-hosted jobs) or at the mapped port (for host-runner jobs); both patterns are supported.
+
+Container-hosted job (hostname exposure):
+
+```yaml
+jobs:
+  postgres-integration:
+    runs-on: ubuntu-latest
+    container: node:24
+    services:
+      postgres:
+        image: postgres:17-alpine
+        env:
+          POSTGRES_USER: rcf
+          POSTGRES_PASSWORD: rcf-dev-only
+          POSTGRES_DB: rcf_test
+        options: >-
+          --health-cmd "pg_isready -U rcf -d rcf_test"
+          --health-interval 2s
+          --health-timeout 3s
+          --health-retries 20
+    steps:
+      - uses: actions/checkout@v4
+      - run: pnpm install --frozen-lockfile
+      - run: node src/migrate.mjs
+        env:
+          DATABASE_URL: postgres://rcf:rcf-dev-only@postgres:5432/rcf_test
+```
+
+Host-runner job (port mapping):
+
+```yaml
+jobs:
+  postgres-integration:
+    runs-on: ubuntu-latest
+    services:
+      postgres:
+        image: postgres:17-alpine
+        env:
+          POSTGRES_USER: rcf
+          POSTGRES_PASSWORD: rcf-dev-only
+          POSTGRES_DB: rcf_test
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd "pg_isready -U rcf -d rcf_test"
+          --health-interval 2s
+          --health-timeout 3s
+          --health-retries 20
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 24
+      - run: pnpm install --frozen-lockfile
+      - run: node src/migrate.mjs
+        env:
+          DATABASE_URL: postgres://rcf:rcf-dev-only@localhost:5432/rcf_test
+```
+
+Adding this seam is the applying project's concern per `delivery-ci-workflows` v2.2.0. The `delivery-ci-workflows` blueprint's alternate-provider four-point mapping (job trigger, Node setup, entry-point invocation, artefact upload) covers non-GHA CI targets against the same `postgres:17-alpine` image.
+
+## What this blueprint does not do
+
+- It does not choose an ORM. Kysely, Drizzle, Prisma, or your team's own module sits inside the facade at operator choice; the outward interface stays orm-neutral.
+- It does not build the Hyperdrive adapter. That is a round-6 v1.1.0 additive minor; the v1.0.0 facade holds the driver reference opaque at ADR-2801 so the minor slots in without a facade re-shape.
+- It does not schedule the recovery runner. Cadence is elicited (a project-side cron string, a systemd timer, or off for CI-only); a project-side scheduler invokes `exportDatabase`.
+- It does not choose a migration tool. Numbered forward-only `.sql` files with one file one transaction is the discipline; the tool is elicited.

package/blueprints/persistence-data-sqlite/docs/topics.md

@@ -31,13 +31,25 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | delivery-ci-workflows | 6101-6899 | 7xx | shipped v2.0.0 (renamed from ci-pipeline) | `ciGates`, `strictCoverageGate`, `releaseArtefacts` |
 | observability-essentials | 7101-7899 | 8xx | shipped v2.0.0 | `statusPageContract` |
-| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `secretsSource` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.1 | `secretsSource` |
 | security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
 | security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
 | security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
 | deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.0.0 | `deploymentTarget` |
 | persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
+| application-datatable | 17101-17899 | 18xx | shipped v1.0.0 | none |
+| application-charts | 18101-18899 | 19xx | shipped v1.0.0 | none |
+| application-dashboard | 19101-19899 | 20xx | shipped v1.0.0 | none |
+| application-notifications-in-app | 20101-20899 | 21xx | shipped v1.0.0 | none |
+| application-admin-console | 21101-21899 | 22xx | shipped v1.0.0 | none |
+| application-empty-error-states | 22101-22899 | 23xx | shipped v1.0.0 | none |
+| application-file-upload | 23101-23899 | 24xx | shipped v1.0.0 | none |
+| application-forms-wizard | 24101-24899 | 25xx | shipped v1.0.0 | none |
+| application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
+| application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
+| persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
 
 US 5101-5111 sit at the LOW end of the 5101-5899 band on purpose. A project-side story that mechanically derives from `persistence-data-sqlite-REQ-011` into the number `5111` would collide against persistence-data-sqlite-US-5111 in this package; the band leaves headroom at the HIGH end (US 5181-5899) so a project's own stories anchored to persistence-data-sqlite REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-clerk/CHANGELOG.md

@@ -0,0 +1,9 @@
+# security-auth-clerk CHANGELOG
+
+## 1.3.0 (visual round T-4, spec 2026-09-06 section 5.4.2, Baz Q2 default)
+
+- Declares `capabilities: [principalDirectory, roleModel, sessionInventory, hostedIdentityUi]` on `blueprint.json`. Additive per section 6 of `blueprint-authoring.md` (an additive optional field with no global-topic change is a minor bump). Consumed at apply time by the visual round T-4 `application-account-settings` blueprint to gate the sessions surface (probe pack check `AC-25106-1`) and the security surface hosted-UI branch (`AC-25105-1`). Clerk exposes an inventory of active sessions with device labels and a terminate action, and hosts identity screens (sign-in, sign-up, account, security) that a link-out or embed can consume.
+
+## 1.2.0 (visual round T-5, spec 2026-09-04 section 5.5.2, Baz Q2 default)
+
+- Declares `capabilities: [principalDirectory, roleModel]` on `blueprint.json`. No other change. The new field is additive per section 6 of `blueprint-authoring.md` (an additive optional field with no global-topic change is a minor bump), and it is consumed by the visual round T-5 `application-admin-console` blueprint at apply time to gate surfaces on what the applied identity blueprint actually provides.

package/blueprints/security-auth-clerk/README.md

@@ -2,6 +2,9 @@
 
 The tenth content blueprint on the rcf-build-lite blueprint mechanism, category `security`. A Clerk-committed sibling to `security-auth-magic-link` on the `authModel` global topic: Clerk hosts the identity surface (users, sessions, sign-in UX, credential storage, MFA, account recovery); the project owns a framework-agnostic middleware boundary, a session verifier confined to one module, a Clerk-claim-to-project-verb authorisation adapter, and a reduced principal shape the rest of the codebase reasons against. Targeted at small greenfield rcf-lite projects that want hosted identity without building the user-and-session surface themselves; larger deployments supersede the vendor by superseding ADR-1001 with a project-level ADR and swapping the middleware and verifier adapters.
 
+
+> Latest: **v1.3.0** (visual round T-4, 2026-09-06). `capabilities: [principalDirectory, roleModel, sessionInventory, hostedIdentityUi]`. See [CHANGELOG.md](CHANGELOG.md).
+
 ## Apply
 
 ```

package/blueprints/security-auth-clerk/blueprint.json

@@ -1,32 +1,134 @@
 {
   "slug": "security-auth-clerk",
-  "version": "1.1.0",
+  "version": "1.3.0",
   "category": "security",
+  "capabilities": [
+    "principalDirectory",
+    "roleModel",
+    "sessionInventory",
+    "hostedIdentityUi"
+  ],
   "contributions": [
-    { "id": "security-auth-clerk-REQ-001", "kind": "req", "path": "requirements/security-auth-clerk-req-001.json" },
-    { "id": "security-auth-clerk-REQ-002", "kind": "req", "path": "requirements/security-auth-clerk-req-002.json" },
-    { "id": "security-auth-clerk-REQ-003", "kind": "req", "path": "requirements/security-auth-clerk-req-003.json" },
-    { "id": "security-auth-clerk-REQ-004", "kind": "req", "path": "requirements/security-auth-clerk-req-004.json" },
-    { "id": "security-auth-clerk-REQ-005", "kind": "req", "path": "requirements/security-auth-clerk-req-005.json" },
-    { "id": "security-auth-clerk-REQ-006", "kind": "req", "path": "requirements/security-auth-clerk-req-006.json" },
-    { "id": "security-auth-clerk-REQ-007", "kind": "req", "path": "requirements/security-auth-clerk-req-007.json" },
-    { "id": "security-auth-clerk-REQ-008", "kind": "req", "path": "requirements/security-auth-clerk-req-008.json" },
-    { "id": "security-auth-clerk-REQ-009", "kind": "req", "path": "requirements/security-auth-clerk-req-009.json" },
-    { "id": "security-auth-clerk-US-9101", "kind": "us", "path": "user-stories/security-auth-clerk-us-9101.json" },
-    { "id": "security-auth-clerk-US-9102", "kind": "us", "path": "user-stories/security-auth-clerk-us-9102.json" },
-    { "id": "security-auth-clerk-US-9103", "kind": "us", "path": "user-stories/security-auth-clerk-us-9103.json" },
-    { "id": "security-auth-clerk-US-9104", "kind": "us", "path": "user-stories/security-auth-clerk-us-9104.json" },
-    { "id": "security-auth-clerk-US-9105", "kind": "us", "path": "user-stories/security-auth-clerk-us-9105.json" },
-    { "id": "security-auth-clerk-US-9106", "kind": "us", "path": "user-stories/security-auth-clerk-us-9106.json" },
-    { "id": "security-auth-clerk-US-9107", "kind": "us", "path": "user-stories/security-auth-clerk-us-9107.json" },
-    { "id": "security-auth-clerk-US-9108", "kind": "us", "path": "user-stories/security-auth-clerk-us-9108.json" },
-    { "id": "security-auth-clerk-US-9109", "kind": "us", "path": "user-stories/security-auth-clerk-us-9109.json" },
-    { "id": "security-auth-clerk-US-9110", "kind": "us", "path": "user-stories/security-auth-clerk-us-9110.json" },
-    { "id": "security-auth-clerk-US-9111", "kind": "us", "path": "user-stories/security-auth-clerk-us-9111.json" },
-    { "id": "TAC-1001-security-auth-clerk-middleware", "kind": "tac", "path": "tacs/tac-1001-security-auth-clerk-middleware.json" },
-    { "id": "TAC-1002-security-auth-clerk-authorisation-adapter", "kind": "tac", "path": "tacs/tac-1002-security-auth-clerk-authorisation-adapter.json" },
-    { "id": "TAC-1003-security-auth-clerk-session-verifier", "kind": "tac", "path": "tacs/tac-1003-security-auth-clerk-session-verifier.json" },
-    { "id": "TAC-1004-security-auth-clerk-claims-mapper", "kind": "tac", "path": "tacs/tac-1004-security-auth-clerk-claims-mapper.json" },
+    {
+      "id": "security-auth-clerk-REQ-001",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-001.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-002",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-002.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-003",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-003.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-004",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-004.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-005",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-005.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-006",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-006.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-007",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-007.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-008",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-008.json"
+    },
+    {
+      "id": "security-auth-clerk-REQ-009",
+      "kind": "req",
+      "path": "requirements/security-auth-clerk-req-009.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9101",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9101.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9102",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9102.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9103",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9103.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9104",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9104.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9105",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9105.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9106",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9106.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9107",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9107.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9108",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9108.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9109",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9109.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9110",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9110.json"
+    },
+    {
+      "id": "security-auth-clerk-US-9111",
+      "kind": "us",
+      "path": "user-stories/security-auth-clerk-us-9111.json"
+    },
+    {
+      "id": "TAC-1001-security-auth-clerk-middleware",
+      "kind": "tac",
+      "path": "tacs/tac-1001-security-auth-clerk-middleware.json"
+    },
+    {
+      "id": "TAC-1002-security-auth-clerk-authorisation-adapter",
+      "kind": "tac",
+      "path": "tacs/tac-1002-security-auth-clerk-authorisation-adapter.json"
+    },
+    {
+      "id": "TAC-1003-security-auth-clerk-session-verifier",
+      "kind": "tac",
+      "path": "tacs/tac-1003-security-auth-clerk-session-verifier.json"
+    },
+    {
+      "id": "TAC-1004-security-auth-clerk-claims-mapper",
+      "kind": "tac",
+      "path": "tacs/tac-1004-security-auth-clerk-claims-mapper.json"
+    },
     {
       "id": "ADR-1001-security-auth-clerk-auth-model",
       "kind": "adr",
@@ -34,9 +136,25 @@
       "scope": "global",
       "topic": "authModel"
     },
-    { "id": "ADR-1002-security-auth-clerk-middleware-boundary", "kind": "adr", "path": "adrs/adr-1002-security-auth-clerk-middleware-boundary.json" },
-    { "id": "ADR-1003-security-auth-clerk-authorisation-adapter-contract", "kind": "adr", "path": "adrs/adr-1003-security-auth-clerk-authorisation-adapter-contract.json" },
-    { "id": "ADR-1004-security-auth-clerk-claims-mapping-discipline", "kind": "adr", "path": "adrs/adr-1004-security-auth-clerk-claims-mapping-discipline.json" },
-    { "id": "ADR-1005-security-auth-clerk-session-lifecycle", "kind": "adr", "path": "adrs/adr-1005-security-auth-clerk-session-lifecycle.json" }
+    {
+      "id": "ADR-1002-security-auth-clerk-middleware-boundary",
+      "kind": "adr",
+      "path": "adrs/adr-1002-security-auth-clerk-middleware-boundary.json"
+    },
+    {
+      "id": "ADR-1003-security-auth-clerk-authorisation-adapter-contract",
+      "kind": "adr",
+      "path": "adrs/adr-1003-security-auth-clerk-authorisation-adapter-contract.json"
+    },
+    {
+      "id": "ADR-1004-security-auth-clerk-claims-mapping-discipline",
+      "kind": "adr",
+      "path": "adrs/adr-1004-security-auth-clerk-claims-mapping-discipline.json"
+    },
+    {
+      "id": "ADR-1005-security-auth-clerk-session-lifecycle",
+      "kind": "adr",
+      "path": "adrs/adr-1005-security-auth-clerk-session-lifecycle.json"
+    }
   ]
 }

package/blueprints/security-auth-clerk/docs/topics.md

@@ -28,13 +28,25 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | delivery-ci-workflows | 6101-6899 | 7xx | shipped v2.0.0 (renamed from ci-pipeline) | `ciGates`, `strictCoverageGate`, `releaseArtefacts` |
 | observability-essentials | 7101-7899 | 8xx | shipped v2.0.0 | `statusPageContract` |
-| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `secretsSource` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.1 | `secretsSource` |
 | security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
 | security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
 | security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
 | deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.0.0 | `deploymentTarget` |
 | persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
+| application-datatable | 17101-17899 | 18xx | shipped v1.0.0 | none |
+| application-charts | 18101-18899 | 19xx | shipped v1.0.0 | none |
+| application-dashboard | 19101-19899 | 20xx | shipped v1.0.0 | none |
+| application-notifications-in-app | 20101-20899 | 21xx | shipped v1.0.0 | none |
+| application-admin-console | 21101-21899 | 22xx | shipped v1.0.0 | none |
+| application-empty-error-states | 22101-22899 | 23xx | shipped v1.0.0 | none |
+| application-file-upload | 23101-23899 | 24xx | shipped v1.0.0 | none |
+| application-forms-wizard | 24101-24899 | 25xx | shipped v1.0.0 | none |
+| application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
+| application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
+| persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
 
 US 9101-9110 sit at the LOW end of the 9101-9899 band on purpose. A project-side story that mechanically derives from a security-auth-clerk REQ id into the number `9110` would collide against security-auth-clerk-US-9110 in this package; the band leaves headroom at the HIGH end (US 9181-9899) so a project's own stories anchored to security-auth-clerk REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-keycloak/CHANGELOG.md

@@ -0,0 +1,9 @@
+# security-auth-keycloak CHANGELOG
+
+## 1.2.0 (visual round T-4, spec 2026-09-06 section 5.4.2, Baz Q2 default)
+
+- Declares `capabilities: [principalDirectory, roleModel, credentialSelfService, sessionInventory]` on `blueprint.json`. Additive per section 6 of `blueprint-authoring.md`. Consumed at apply time by the visual round T-4 `application-account-settings` blueprint to gate the security surface self-service branch (probe pack check `AC-25105-1`) and the sessions surface (`AC-25106-1`). Keycloak ships a credential self-service surface (password change, MFA management, email change) that a project can bring in-place and it exposes an active-session inventory a terminate action can act on. Keycloak does NOT declare `hostedIdentityUi` because its hosted-UI is realm-scoped and Keycloak deployments typically brand it in place, so the account-settings blueprint does not treat Keycloak as a hosted-UI provider.
+
+## 1.1.0 (visual round T-5, spec 2026-09-04 section 5.5.2, Baz Q2 default)
+
+- Declares `capabilities: [principalDirectory, roleModel]` on `blueprint.json`. No other change. The new field is additive per section 6 of `blueprint-authoring.md` (an additive optional field with no global-topic change is a minor bump), and it is consumed by the visual round T-5 `application-admin-console` blueprint at apply time to gate surfaces on what the applied identity blueprint actually provides.

package/blueprints/security-auth-keycloak/README.md

@@ -2,6 +2,9 @@
 
 The twelfth content blueprint on the rcf-build-lite blueprint mechanism, category `security`. A Keycloak-committed sibling to `security-auth-magic-link`, `security-auth-clerk`, and `security-auth-oauth2` on the `authModel` global topic. Identity is delegated to a Keycloak realm the operator runs; the project owns the discovery client, the token verifier (JWKS or introspection per realm), the role adapter, the provider-routing seam, and the optional application session on top. Targeted at rcf-lite projects that have committed to a self-hosted Keycloak realm (or are running one already) and want the Keycloak-shaped decisions the vendor-neutral `security-auth-oauth2` sibling deliberately does not fix.
 
+
+> Latest: **v1.2.0** (visual round T-4, 2026-09-06). `capabilities: [principalDirectory, roleModel, credentialSelfService, sessionInventory]`. See [CHANGELOG.md](CHANGELOG.md).
+
 ## Apply
 
 ```