rcf-lite 0.21.0 → 0.22.0

package/blueprints/object-storage-s3/guide/object-storage-s3.md

@@ -0,0 +1,207 @@
+# object-storage-s3 guide
+
+## What this blueprint gets you
+
+S3-shape object storage on any S3-compatible endpoint: Cloudflare R2 (the shipped first adapter target), AWS S3, MinIO (for local dev), Backblaze B2 in S3-compat mode, Wasabi, or self-hosted MinIO in production. The store facade is the sole reader of the S3 client (`@aws-sdk/client-s3` on Node targets or `aws4fetch` on Workers targets, elicited under ADR-2901). Consumer code calls named domain verbs on the facade and never touches the raw S3 client. Multipart-upload is invisible to consumer code: a payload above the elicited threshold (default 8 MiB per ADR-2903) switches transparently, with `AbortMultipartUpload` on failure so no orphan in-flight uploads remain. Presigned GET URLs come with a bounded TTL (floor 1 minute, default 15 minutes per ADR-2902). Four lifecycle events (`facadeReady`, `objectPut`, `objectDeleted`, `presignedIssued`) fire on the injected event sink with a metadata-only whitelist so consumer logging cannot leak object body bytes, user ids, or PII from the object.
+
+## Apply this blueprint
+
+`security-secrets-management` v1.0.1+ MUST be applied first per REQ-006 (Baz decision 6). The blueprint declares `requiresAppliedCapabilities: {capabilities: ["secretsProvider"], allowSkipFlag: "allow-no-secrets-yet", refusalMessageId: "object-storage-s3-no-secrets"}` and the T-5 capability mechanism (visual round spec 5.5.1) enforces the refusal at apply time. On a project that has not applied secrets-management:
+
+```sh
+rcf define blueprint add object-storage-s3
+```
+
+exits 3 with `[object-storage-s3-no-secrets]` on stderr as the first-line tag; the message names the required capability (`secretsProvider`), the shipped predecessor (`security-secrets-management` v1.0.1+), and `--allow-no-secrets-yet` as the override for a scaffolding pass. The override applies the blueprint cleanly and records a `notes` line on `rcf/blueprints/object-storage-s3.applied.json` naming the missing predecessor so a later `rcf define validate` pass can flag the surface as not-yet-activated. Apply secrets-management first, then:
+
+```sh
+rcf define blueprint add security-secrets-management
+rcf define blueprint add object-storage-s3
+```
+
+On a project that already applied `object-storage-s3` and later needs a different wire-shape (a native-GCS or native-Azure sibling), `rcf define blueprint add object-storage-native-gcs` (once minted) surfaces a DELIBERATE conflict on the `objectStorageContract` global-ADR topic; resolve with one project-level ADR.
+
+## Facade shape
+
+```js
+import { createObjectStore } from './object-store.mjs';
+import { secretsShim } from './secrets.mjs';
+
+const credentials = await secretsShim.getSecret('objectStorageCredentials');
+const store = createObjectStore({
+  endpointUrl: process.env.S3_ENDPOINT_URL, // https://<account-id>.r2.cloudflarestorage.com on R2
+  bucket: process.env.S3_BUCKET,            // rcf-test on the fixture
+  credentialsRef: credentials,              // { accessKeyId, secretAccessKey } via security-secrets-management
+  region: 'auto',                           // 'auto' for R2; 'eu-west-2' etc. for AWS S3
+  forcePathStyle: false,                    // true for MinIO; false for R2 and AWS with virtual-hosted style
+  onEvent: (record) => logger.log('object-storage', record),
+});
+
+await store.ready();
+
+// put a 1 KiB payload
+await store.putObject('uploads/report.pdf', 'application/pdf', pdfBuffer);
+
+// get and stream to a caller
+const { body, contentType } = await store.getObject('uploads/report.pdf');
+
+// presign a GET URL with a bounded TTL
+const url = await store.presignGetUrl('uploads/report.pdf', 300); // 5 minutes
+
+// delete
+await store.deleteObject('uploads/report.pdf');
+
+// list under a prefix
+const { keys, isTruncated } = await store.listObjects('uploads/');
+```
+
+The facade is the sole importer of `@aws-sdk/client-s3` in your source tree per REQ-001. A project-side call site that reaches into the SDK directly is refused at author-side review.
+
+## Adapter choice per deploy target
+
+ADR-2901 elicits the adapter per deploy target:
+
+- **Node process** (server, container, non-Workers serverless): `@aws-sdk/client-s3` (AWS SDK v3, modular client-s3 package). Ships every op the v1.0.0 surface needs.
+- **Cloudflare Workers**: `aws4fetch` (lightweight fetch-native S3 client). Sits within the Workers CPU-time budget where the AWS SDK's Node polyfills do not.
+
+The facade's outward interface is unchanged across adapters; only the import at the top of the facade module changes. A future adapter (a GCS shim, an Azure Blob shim under a sibling blueprint) slots in at the same boundary.
+
+## Presigned URL discipline
+
+ADR-2902 sets the default TTL to 15 minutes and the floor to 1 minute. The facade refuses a presign below 60 seconds; the ceiling is elicited (no shipped default). Every `presignedIssued` event carries `{event, ts, key, ttl}` so downstream logging can flag long-lived URLs. The URL is signed at the client edge with the applied credentials; the browser or downstream caller fetches from the storage endpoint directly.
+
+## Multipart upload
+
+ADR-2903 sets the default multipart threshold to 8 MiB (matches AWS SDK convention). Below the threshold, `putObject` goes single-part; above, it delegates to the multipart uploader (TAC-2902):
+
+1. `CreateMultipartUpload` returns an `UploadId`.
+2. `UploadPart` per fixed-size chunk (default 8 MiB per part) with a stable `PartNumber` and captured `ETag`.
+3. `CompleteMultipartUpload` with the ordered part list.
+
+On any part-upload failure, `AbortMultipartUpload` runs before the error propagates so no orphan multipart upload remains on the bucket. `ListMultipartUploads(prefix=key)` after a successful completion returns zero uploads.
+
+**R2 multipart re-upload gotcha** (per https://developers.cloudflare.com/r2/api/s3/api/): re-uploading to the same part number replaces the previous part with loss-on-fail semantics. If a re-upload fails, the original part is gone. The facade avoids the case in its shipped path (parts are single-attempt; abort-on-failure covers the mid-multipart error), but a consumer that layers its own retry on top of `putObject` should retry the whole put, not a partial multipart.
+
+## Lifecycle events and PII discipline
+
+The facade emits four events on the injected sink with a fixed metadata-only field discipline (TAC-2903):
+
+| Event | Fields |
+|---|---|
+| `facadeReady` | `event`, `ts`, `endpointHost`, `bucketName` |
+| `objectPut` | `event`, `ts`, `key`, `size`, `contentType` |
+| `objectDeleted` | `event`, `ts`, `key` |
+| `presignedIssued` | `event`, `ts`, `key`, `ttl` |
+
+No record carries object body bytes, no body checksum, no user id field, no PII drawn from the object body. The `event-secrecy` probe (AC-28105-1) drives put/get/presign/delete against a PII fixture (key `users/1234/passport.jpg`, body containing `PII-FIXTURE-DO-NOT-LOG`) and asserts the whitelist compliance at ship time.
+
+## R2 deviations from full S3
+
+Cloudflare R2 is S3-compatible per https://developers.cloudflare.com/r2/api/s3/api/ but explicitly does not implement:
+
+- **ACLs**: no per-object or per-bucket ACLs; use Cloudflare account roles and bucket-level API tokens.
+- **Bucket policies**: no S3-style JSON bucket policies.
+- **Object Lock**: no WORM or retention hold surface.
+- **Versioning**: no object versioning; a put replaces the object.
+- **Lifecycle policies**: R2 marks lifecycle configuration as "feature implementation is currently in progress"; do not depend on time-based expiration or class transitions on R2 at v1.0.0.
+
+An operator relying on any of the four either picks a different endpoint (AWS S3 covers all four) or handles the equivalent semantics application-side.
+
+## CI seam
+
+The `object-storage-s3` facade needs an S3-compatible endpoint reachable from the CI runner. On GitHub Actions the standard shape is a `services:` block with MinIO as a service container. 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). The blueprint's applying project realises this block in its own `.github/workflows/pull-request-checks.yml`:
+
+**Container-hosted job (hostname exposure):**
+
+```yaml
+jobs:
+  gate:
+    runs-on: ubuntu-latest
+    container: node:24
+    services:
+      minio:
+        image: minio/minio:latest
+        env:
+          MINIO_ROOT_USER: rcf-dev
+          MINIO_ROOT_PASSWORD: rcf-dev-only
+        ports:
+          - 9000:9000
+          - 9001:9001
+        options: >-
+          --entrypoint sh -c "minio server /data --console-address ':9001'"
+          --health-cmd "curl -f http://localhost:9000/minio/health/live"
+          --health-interval 3s --health-timeout 3s --health-retries 20
+    env:
+      S3_ENDPOINT_URL: http://minio:9000
+      S3_BUCKET: rcf-test
+      S3_ACCESS_KEY_ID: rcf-dev
+      S3_SECRET_ACCESS_KEY: rcf-dev-only
+      S3_FORCE_PATH_STYLE: 'true'
+    steps:
+      - uses: actions/checkout@v4
+      - run: pnpm install
+      - run: node packages/rcf-lite/test/fixtures/infra-s3-and-queue/src/create-bucket.mjs
+      - run: node blueprints/object-storage-s3/contributions/probes/run-facade-round-trip.mjs
+```
+
+**Host-runner job (mapped port exposure):**
+
+```yaml
+jobs:
+  gate:
+    runs-on: ubuntu-latest
+    services:
+      minio:
+        image: minio/minio:latest
+        env:
+          MINIO_ROOT_USER: rcf-dev
+          MINIO_ROOT_PASSWORD: rcf-dev-only
+        ports:
+          - 9000:9000
+    env:
+      S3_ENDPOINT_URL: http://localhost:9000
+      S3_BUCKET: rcf-test
+      S3_ACCESS_KEY_ID: rcf-dev
+      S3_SECRET_ACCESS_KEY: rcf-dev-only
+      S3_FORCE_PATH_STYLE: 'true'
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with: { node-version: '24' }
+      - run: pnpm install
+      - run: sleep 4 && node packages/rcf-lite/test/fixtures/infra-s3-and-queue/src/create-bucket.mjs
+      - run: node blueprints/object-storage-s3/contributions/probes/run-facade-round-trip.mjs
+      # ... plus the other four MinIO probes and the R2 smoke
+```
+
+Alternate providers (GitLab CI, CircleCI, Buildkite) map through the same four-point contract per `blueprints/delivery-ci-workflows/assets/ci-provider-examples/notes.md`: job trigger, Node setup, entry-point invocation, artefact upload. The MinIO service container is the extension point.
+
+## R2 real-account smoke
+
+`node blueprints/object-storage-s3/contributions/probes/run-r2-real-account-smoke.mjs` behaves per spec section 3.5:
+
+- Without `CI_HAS_CLOUDFLARE_ACCOUNT`: exits 0, writes a report with `verdict: pass, detail: "accountBound: skipped (no CI_HAS_CLOUDFLARE_ACCOUNT)", accountBoundSkipped: true`. Aggregate verdict pass.
+- With `CI_HAS_CLOUDFLARE_ACCOUNT` set alongside `R2_ACCOUNT_ID`, `R2_BUCKET`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` on the runner env (or `.rcf/secrets/dev.env` locally): opens the facade against the R2 endpoint, puts a 1 KiB payload, gets it back byte-equal, deletes the temporary object on exit. Aggregate verdict pass.
+
+The `accountBound` flag on the probe module surface flips the delivery-ci-workflows aggregate to pass on the skipped path per section 3.5.
+
+## Elicited parameters
+
+| Parameter | Default | Notes |
+|---|---|---|
+| endpointUrl | none | R2: `https://<account-id>.r2.cloudflarestorage.com`; AWS S3: `https://s3.<region>.amazonaws.com`; MinIO: `http://localhost:9000`. |
+| bucket | none | The elicited bucket name. |
+| credentialsRef | via `security-secrets-management` | `secretRef` opaque-string agreed with security-secrets-management. |
+| adapter | `awsSdk` (Node) / `aws4fetch` (Workers) | ADR-2901. |
+| defaultPresignTtlSeconds | 900 (15 minutes) | ADR-2902; floor 60 s enforced by facade. |
+| multipartThresholdBytes | 8388608 (8 MiB) | ADR-2903. |
+| forcePathStyle | `false` | `true` for MinIO. |
+| region | `auto` | `auto` for R2; standard AWS region for AWS S3. |
+| serverSideEncryption | none shipped | R2 is SSE-C only; AWS S3 supports `sseS3`; elicited per deploy target. |
+
+## Standards trace
+
+- Cloudflare R2 S3-compatibility surface: https://developers.cloudflare.com/r2/api/s3/api/ (supported ops, four deviations).
+- Cloudflare R2 overview and presigned URLs: https://developers.cloudflare.com/r2/.
+- MinIO S3 compatibility: https://docs.min.io/community/minio-object-store/administration/object-management/object-lifecycle-management.html.
+- GitHub Actions service containers: https://docs.github.com/en/actions/using-containerized-services/about-service-containers.

package/blueprints/observability-essentials/docs/topics.md

@@ -43,7 +43,7 @@ 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` |
@@ -55,6 +55,13 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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 7101-7110 sit at the LOW end of the 7101-7899 band on purpose. A project-side story that mechanically derives from an observability-essentials REQs id into the number `7110` would collide against observability-essentials-US-7110 in this package; the band leaves headroom at the HIGH end (US 7181-7899) so a project's own stories anchored to observability-essentials REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/observability-logging/CHANGELOG.md

@@ -1,5 +1,9 @@
 # observability-logging CHANGELOG
 
+## 1.2.0 (visual round T-4, spec 2026-09-06 section 5.4.2, Baz Q2 default)
+
+- Declares `capabilities: [auditLog, sessionInventory]` on `blueprint.json`. The `sessionInventory` addition ships the logging-as-session-inventory projection: a project may configure the logger session-emission channel as the source the account-settings sessions surface reads (device labels from the User-Agent header, last-active from the last event emitted per session, terminate as an operator write into the same channel). Additive per section 6 of `blueprint-authoring.md`. Consumed at apply time by the visual round T-4 `application-account-settings` blueprint. A project that does not run the logger as a session store leaves the surface capability supplied by the applied auth blueprint alone; the account-settings blueprint reads the union.
+
 ## 1.1.0 (visual round T-5, spec 2026-09-04 section 5.5.2, Baz Q2 default)
 
 - Declares `capabilities: [auditLog]` 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). Keeps a single grammar for capability declaration: consumer blueprints read the union of declared `capabilities[]` on applied blueprints, never the `providesRoles[]` -> capability inference. This is the ratified rule (one grammar, no role-to-capability inference); the section 6a table previously noted `auditLog` as "implicit through the `logging` role" and now names `observability-logging` as the explicit shelf provider. Consumed at apply time by the visual round T-5 `application-admin-console` blueprint to gate the audit-log surface (probe pack check `AC-21105-1`).

package/blueprints/observability-logging/README.md

@@ -2,6 +2,9 @@
 
 Structured single-line JSON emission for a rcf-lite project. General enterprise practice, no vendor lock-in. Ships the shelf-canonical `logging` global topic on `ADR-1601-observability-logging-line-shape` (transferred from `application-api-rest-ADR-304`, retained there as superseded history). Provides the `logging` role for the companion-suggestion mechanism. From 1.1.0, declares `capabilities: [auditLog]` on `blueprint.json` so the application-admin-console probe pack activates the audit-log surface check `AC-21105-1` when this blueprint is applied on the project (one grammar; consumer blueprints read declared capabilities, never a role-to-capability inference).
 
+
+> Latest: **v1.2.0** (visual round T-4, 2026-09-06). `capabilities: [auditLog, sessionInventory]`. See [CHANGELOG.md](CHANGELOG.md).
+
 ## Apply
 
 ```

package/blueprints/observability-logging/blueprint.json

@@ -1,12 +1,13 @@
 {
   "slug": "observability-logging",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "category": "observability",
   "providesRoles": [
     "logging"
   ],
   "capabilities": [
-    "auditLog"
+    "auditLog",
+    "sessionInventory"
   ],
   "contributions": [
     {

package/blueprints/observability-logging/docs/topics.md

@@ -22,5 +22,12 @@
 | 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` |
 
 The shelf-wide band registry lives in `packages/rcf-lite/docs/blueprint-authoring.md` section 5.

package/blueprints/observability-probe-endpoints/docs/topics.md

@@ -33,7 +33,7 @@ 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` |
@@ -45,6 +45,13 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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 14101-14108 sit at the LOW end of the 14101-14899 band on purpose. A project-side story that mechanically derives from an observability-probe-endpoints REQ id into the number `14108` would collide against observability-probe-endpoints-US-14108 in this package; the band leaves headroom at the HIGH end (US 14181-14899) so a project's own stories anchored to observability-probe-endpoints REQs can allocate without conflict. The watchpost run4 lesson applies here too. Band spacing between the previous HQ-lane row (persistence-data-d1, 13101-13899, 14xx) and this one (14101-14899, 15xx) reflects the four-digit widening pattern opened by security-auth-clerk at 10xx and continued through the round-2 HQ lane.
 

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

@@ -31,7 +31,7 @@ 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` |
@@ -43,6 +43,13 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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 13101-13107 sit at the LOW end of the 13101-13899 band on purpose. A project-side story that mechanically derives from a persistence-data-d1 REQ id into the number `13107` would collide against persistence-data-d1-US-13107 in this package; the band leaves headroom at the HIGH end (US 13181-13899) so a project's own stories anchored to persistence-data-d1 REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

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

@@ -0,0 +1,12 @@
+# persistence-data-postgres changelog
+
+## 1.0.0 - 2026-09-06
+
+Initial release. Contract for Postgres as the project's primary durable relational store on a server-tier deployment (Node process, container, non-Workers serverless), accessed through a store facade module that is the sole reader of the `pg` client. Landed via the infra round 5 spec (ratified 2026-09-06) as track T-1.
+
+- 26 contributions: 7 REQs on facade / migrations / prepared statements / transactions / recovery / pool posture / advisory-lock helper; 10 USs at 27101-27110; 4 TACs (2801 facade, 2802 migration runner, 2803 transaction helper, 2804 recovery runner); 5 ADRs (2801 driver with scope global on `persistenceStore`, 2802 migration shape with scope global on `migrationDiscipline`, 2803 runner mode, 2804 recovery, 2805 connection-pool posture).
+- Six Node-only probes under `contributions/probes/` proven against a live `postgres:17-alpine` container: `facade-round-trip`, `migration-apply`, `prepared-statement-scan`, `transaction-atomicity`, `recovery-restore-round-trip`, `pool-posture-smoke`. None account-bound; Postgres is local-first per Baz decision 8.
+- Sample-app fixture at `packages/rcf-lite/test/fixtures/infra-postgres/` boots `postgres:17-alpine` via docker compose, applies three toy forward-only `.sql` migrations, exposes the facade over `pg`, and hosts `SIMULATE_MIGRATION_FAILURE` and `SIMULATE_CONSTRAINT_VIOLATION` switches for the negative-run probe paths.
+- Declares `capabilities: ["relationalStore"]`, `suggestedCompanions: [{role: "logging"}, {role: "errorHandling"}]`, `providesRoles` absent, `requiresAppliedCapabilities` absent.
+- Reserves the round-6 Hyperdrive v1.1.0 adapter slot at ADR-2801 by keeping the driver reference opaque at the facade boundary.
+- Advisory-lock helper (REQ-007) ships in v1.0.0 as elicited with default `off` per the ratified Q1 answer on infra round 5 spec section 10.

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

@@ -0,0 +1,101 @@
+# persistence-data-postgres
+
+Postgres as the project's primary durable relational store on a server-tier deployment (Node process, container, non-Workers serverless), accessed through a store facade module that is the sole reader of the `pg` client. Numbered forward-only `.sql` migrations, prepared-statement discipline, transactional atomicity, and a two-path recovery model (scheduled `pg_dump` plus vendor point-in-time recovery). ORM-neutral: a project drops Kysely or Drizzle inside the facade without moving any AC.
+
+## What this blueprint gives you
+
+- **A store facade** (TAC-2801) that is the sole importer of `pg` in your source tree, opens a `pg.Pool` on boot, and exposes typed named domain verbs. Emits `facadeReady` on the first successful ready-check.
+- **A migration runner** (TAC-2802) that applies numbered forward-only `.sql` files one file per transaction against a `schema_version` bookkeeping table.
+- **A transaction helper** (TAC-2803) wrapping `BEGIN` and `COMMIT` around a callback with `ROLLBACK` on any error and a `transactionRolledBack` event carrying the failing statement's zero-based index.
+- **A scheduled export runner** (TAC-2804) driving `pg_dump` via `child_process.execFile` and emitting `backupExported` on completion.
+- **Six Node-only probes** proving every runtime observable against a real `postgres:17-alpine` container.
+
+## The seven REQs
+
+| REQ | What it commits |
+|---|---|
+| REQ-001 | Facade module is the sole reader of `pg`; opens on boot; emits `facadeReady`. |
+| REQ-002 | Numbered forward-only `.sql` migrations applied one file one transaction; `schema_version` bookkeeping. |
+| REQ-003 | Prepared-statement discipline: every `pg.query` first argument a static string literal with `$N` parameters. |
+| REQ-004 | Transactional atomicity via a helper wrapping `BEGIN` and `COMMIT`; `ROLLBACK` on error with `transactionRolledBack` event. |
+| REQ-005 | Two-path recovery: scheduled `pg_dump` PLUS vendor point-in-time recovery, both required, both elicited. |
+| REQ-006 | Connection-pool posture per deploy target: long-lived on Node, request-scoped on container. |
+| REQ-007 | Optional advisory-lock helper elicited default `off`; session or transaction level per the Postgres explicit-locking reference. |
+
+## The four TACs
+
+- **TAC-2801 facade**: the Postgres store facade module.
+- **TAC-2802 migration runner**: applies `.sql` files one file one transaction; tracks `schema_version`.
+- **TAC-2803 transaction helper**: `BEGIN` / `COMMIT` wrapper with rollback and statement-index event.
+- **TAC-2804 recovery runner**: scheduled `pg_dump` runner with `backupExported` event.
+
+## The five ADRs
+
+- **ADR-2801 driver** (scope: global, topic `persistenceStore`): pg (node-postgres) as the shipped v1.0.0 driver; opaque driver reference at the facade boundary so the round-6 Hyperdrive v1.1.0 adapter slots in without a facade re-shape. Standards trace clause: node-postgres parameterised-queries contract at https://node-postgres.com/features/queries.
+- **ADR-2802 migration shape** (scope: global, topic `migrationDiscipline`): numbered forward-only `.sql` files; one file one transaction; migration runner tool elicited.
+- **ADR-2803 runner mode**: `atBoot` (long-lived Node default) or `ciStep` (Workers-adjacent default); elicited.
+- **ADR-2804 recovery**: two-path recovery, both required, cadence elicited.
+- **ADR-2805 pool posture**: long-lived on Node, request-scoped on container, delegated to Hyperdrive on Workers-adjacent (v1.1.0). See https://www.postgresql.org/docs/current/explicit-locking.html for the session-vs-transaction advisory-lock semantics REQ-007's optional helper uses.
+
+## Elicited parameters
+
+Connection URL (opaque, from `security-secrets-management` when applied; project-config file otherwise); migrations directory (default `./migrations/`); runner mode (`atBoot` or `ciStep`); scheduled export destination and cadence; PITR window and retention; ORM inside the facade (`none`, `kysely`, `drizzle`, or the project's own module); expose transaction helper (`always`, `neverOutsideFacade`); advisory-lock helper (`off`, `session`, `transaction`); pool posture (`longLivedNode`, `requestScopedContainer`, `hyperdriveManaged` reserved for v1.1.0); pool sizing overrides.
+
+## Companions
+
+- **logging**: every migration apply, every scheduled export completion, and every transaction rollback writes a request-scoped log line; a logging companion supplies the factory.
+- **errorHandling**: a migration failure, a constraint violation, or a pool exhaustion constructs an internal error record; an error-handling companion supplies the record factory and the boundary.
+
+## Composition and conflicts
+
+Composes on `security-secrets-management` for the connection URL when applied. Conflicts by design on `persistenceStore` and `migrationDiscipline` with `persistence-data-sqlite` and `persistence-data-d1`; the operator resolves via one project-level ADR per topic.
+
+## The six probes
+
+Each probe is a Node module under `contributions/probes/` exporting the round-5 spec section 3.2 verdict envelope, with a matching `run-<probe-name>.mjs` shim that drives the probe against the sample-app fixture and writes the per-blueprint report at `.rcf/reports/blueprints/persistence-data-postgres/<probe-name>.json`.
+
+| Probe | Anchor AC | What it proves |
+|---|---|---|
+| `facade-round-trip` | AC-27101-1 | Facade opens, `facadeReady` fires with database name, put and get round-trips |
+| `migration-apply` | AC-27102-1 | Three `.sql` files apply one file one transaction; `migrationsApplied` fires; `schema_version` advances |
+| `prepared-statement-scan` | AC-27103-1 | Source-tree scan asserts every `.query(...)` first argument is a static string |
+| `transaction-atomicity` | AC-27104-1 | Constraint violation rolls back; `transactionRolledBack` fires with statementIndex 1; no row persists |
+| `recovery-restore-round-trip` | AC-27105-1 | `pg_dump` artefact primes a fresh Postgres; row-count and checksum equality |
+| `pool-posture-smoke` | AC-27106-1 | Two facades at pool size 5 handle twenty concurrent queries with no timeout |
+
+None of the six probes carries `accountBound: true`; Postgres is local-first per infra round 5 spec Baz decision 8.
+
+## How to run the probes locally
+
+```sh
+cd packages/rcf-lite/test/fixtures/infra-postgres
+docker compose up -d postgres
+sleep 3
+node ../../../../blueprints/persistence-data-postgres/contributions/probes/run-facade-round-trip.mjs
+node ../../../../blueprints/persistence-data-postgres/contributions/probes/run-migration-apply.mjs
+node ../../../../blueprints/persistence-data-postgres/contributions/probes/run-prepared-statement-scan.mjs
+node ../../../../blueprints/persistence-data-postgres/contributions/probes/run-transaction-atomicity.mjs
+node ../../../../blueprints/persistence-data-postgres/contributions/probes/run-recovery-restore-round-trip.mjs
+node ../../../../blueprints/persistence-data-postgres/contributions/probes/run-pool-posture-smoke.mjs
+docker compose down -v
+```
+
+Each shim exits 0 on aggregate pass and 1 otherwise; every report file carries `aggregateVerdict pass` on the canonical fixture state.
+
+## Reserved round-6 Hyperdrive adapter slot
+
+`persistence-data-postgres` v1.1.0 (round 6) adds a `driver: "hyperdrive"` option under ADR-2801, wrapping the same facade contract with the Cloudflare Hyperdrive connection pool and query cache per https://developers.cloudflare.com/hyperdrive/. The v1.0.0 facade holds the driver reference opaque at the facade boundary (`import pg from 'pg'` lives inside the facade; the round-6 minor swaps that import), so no outward AC moves.
+
+## Known mechanism-reach gaps
+
+- **Prepared-statement discipline (REQ-003)** is enforced by a build-time AST scan; a project author who bypasses the facade for a project-side raw `pg.query` call site outside the facade directory is not caught by this probe. Mitigation: the facade sole-reader AC on REQ-001 pins the discipline at author-side review; the prepared-statement-scan probe walks only the facade directory by design.
+- **Advisory-lock semantics (REQ-007)** is elicited off by default per the ratified Q1 answer. When enabled, session-level locks survive rolled-back transactions per https://www.postgresql.org/docs/current/explicit-locking.html; use `transaction` for the common case and pick `session` only when cross-transaction locking is the intent.
+- **Pool posture per deploy target (REQ-006)** ships defaults matching pg's own; the `pool-posture-smoke` probe drives twenty concurrent queries at pool size 5 and does not impose a sizing formula. Operators sizing for their workload override via the elicited pool-config fields.
+
+## Standards trace
+
+- node-postgres parameterised-queries contract: https://node-postgres.com/features/queries.
+- Postgres advisory locks (for REQ-007's optional helper): https://www.postgresql.org/docs/current/explicit-locking.html.
+- Postgres MVCC transaction semantics: implicit in the transaction-helper probe; ADR-2803's decision cites the Postgres transaction reference without a URL requirement (the vendor doc is stable).
+- CI service container shape: https://docs.github.com/en/actions/using-containerized-services/about-service-containers.
+- Cloudflare Hyperdrive (reserved v1.1.0 adapter slot): https://developers.cloudflare.com/hyperdrive/.

package/blueprints/persistence-data-postgres/blueprint.json

@@ -0,0 +1,80 @@
+{
+  "slug": "persistence-data-postgres",
+  "version": "1.0.0",
+  "category": "persistence",
+  "capabilities": ["relationalStore"],
+  "suggestedCompanions": [
+    {
+      "role": "logging",
+      "reason": "Every migration apply, every scheduled export completion, and every transaction rollback writes a request-scoped log line; a logging companion supplies the factory the pipeline calls."
+    },
+    {
+      "role": "errorHandling",
+      "reason": "A migration failure, a constraint violation, or a pool exhaustion constructs an internal error record; an error-handling companion supplies the record factory and the boundary."
+    }
+  ],
+  "contributions": [
+    { "id": "persistence-data-postgres-REQ-001", "kind": "req", "path": "requirements/persistence-data-postgres-req-001.json" },
+    { "id": "persistence-data-postgres-REQ-002", "kind": "req", "path": "requirements/persistence-data-postgres-req-002.json" },
+    { "id": "persistence-data-postgres-REQ-003", "kind": "req", "path": "requirements/persistence-data-postgres-req-003.json" },
+    { "id": "persistence-data-postgres-REQ-004", "kind": "req", "path": "requirements/persistence-data-postgres-req-004.json" },
+    { "id": "persistence-data-postgres-REQ-005", "kind": "req", "path": "requirements/persistence-data-postgres-req-005.json" },
+    { "id": "persistence-data-postgres-REQ-006", "kind": "req", "path": "requirements/persistence-data-postgres-req-006.json" },
+    { "id": "persistence-data-postgres-REQ-007", "kind": "req", "path": "requirements/persistence-data-postgres-req-007.json" },
+    { "id": "persistence-data-postgres-US-27101", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27101.json" },
+    { "id": "persistence-data-postgres-US-27102", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27102.json" },
+    { "id": "persistence-data-postgres-US-27103", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27103.json" },
+    { "id": "persistence-data-postgres-US-27104", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27104.json" },
+    { "id": "persistence-data-postgres-US-27105", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27105.json" },
+    { "id": "persistence-data-postgres-US-27106", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27106.json" },
+    { "id": "persistence-data-postgres-US-27107", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27107.json" },
+    { "id": "persistence-data-postgres-US-27108", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27108.json" },
+    { "id": "persistence-data-postgres-US-27109", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27109.json" },
+    { "id": "persistence-data-postgres-US-27110", "kind": "us", "path": "user-stories/persistence-data-postgres-us-27110.json" },
+    { "id": "TAC-2801-persistence-data-postgres-facade", "kind": "tac", "path": "tacs/tac-2801-persistence-data-postgres-facade.json" },
+    { "id": "TAC-2802-persistence-data-postgres-migration-runner", "kind": "tac", "path": "tacs/tac-2802-persistence-data-postgres-migration-runner.json" },
+    { "id": "TAC-2803-persistence-data-postgres-transaction-helper", "kind": "tac", "path": "tacs/tac-2803-persistence-data-postgres-transaction-helper.json" },
+    { "id": "TAC-2804-persistence-data-postgres-recovery-runner", "kind": "tac", "path": "tacs/tac-2804-persistence-data-postgres-recovery-runner.json" },
+    {
+      "id": "ADR-2801-persistence-data-postgres-driver",
+      "kind": "adr",
+      "path": "adrs/adr-2801-persistence-data-postgres-driver.json",
+      "scope": "global",
+      "topic": "persistenceStore",
+      "recommendedDefault": true,
+      "elicited": true,
+      "standardsTraceClause": "node-postgres parameterised-queries contract"
+    },
+    {
+      "id": "ADR-2802-persistence-data-postgres-migration-shape",
+      "kind": "adr",
+      "path": "adrs/adr-2802-persistence-data-postgres-migration-shape.json",
+      "scope": "global",
+      "topic": "migrationDiscipline",
+      "recommendedDefault": true,
+      "elicited": true,
+      "standardsTraceClause": "generic enterprise practice"
+    },
+    {
+      "id": "ADR-2803-persistence-data-postgres-runner-mode",
+      "kind": "adr",
+      "path": "adrs/adr-2803-persistence-data-postgres-runner-mode.json",
+      "elicited": true,
+      "standardsTraceClause": "generic enterprise practice"
+    },
+    {
+      "id": "ADR-2804-persistence-data-postgres-recovery",
+      "kind": "adr",
+      "path": "adrs/adr-2804-persistence-data-postgres-recovery.json",
+      "elicited": true,
+      "standardsTraceClause": "generic enterprise practice"
+    },
+    {
+      "id": "ADR-2805-persistence-data-postgres-connection-pool-posture",
+      "kind": "adr",
+      "path": "adrs/adr-2805-persistence-data-postgres-connection-pool-posture.json",
+      "elicited": true,
+      "standardsTraceClause": "generic enterprise practice"
+    }
+  ]
+}

package/blueprints/persistence-data-postgres/contributions/adrs/adr-2801-persistence-data-postgres-driver.json

@@ -0,0 +1,30 @@
+{
+  "adrId": "ADR-2801-persistence-data-postgres-driver",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "The pg client (node-postgres) as the shipped v1.0.0 driver; a round-6 Hyperdrive adapter slots in at v1.1.0 without a facade re-shape",
+  "context": "A project deploying Postgres on a Node target has two mainstream driver choices: pg (node-postgres, the callback-and-pool oriented reference driver on npm) and postgres.js (a promise-first alternative with a compact API surface). Both speak the Postgres wire protocol; both support parameterised queries; both are actively maintained. The round-6 Cloudflare-line proposal reserves a Hyperdrive-in-front adapter that wraps pg with Cloudflare's connection-pool and query-cache surface. The v1.0.0 facade design has to hold the driver reference opaque at the facade boundary so the round-6 adapter slots in as an additive minor without a facade re-shape.",
+  "decision": "The shipped v1.0.0 driver is pg (node-postgres) with a long-lived pg.Pool held inside the facade module (or a request-scoped pool on request-scoped container targets per ADR-2805). Every pg.query call passes a static string literal as its first argument and supplies parameters as an array bound to $1, $2, ... $N per the node-postgres parameterised-queries contract at https://node-postgres.com/features/queries. The driver reference inside the facade is OPAQUE at this ADR: the facade imports pg and any consumer or adapter that wants to swap the driver (postgres.js, a Hyperdrive-wrapped pg via the round-6 v1.1.0 adapter, an ORM sitting inside the facade) replaces the import here without touching the outward interface. Alternative drivers are elicited at apply time under the adapter parameter; the v1.0.0 shipped default is pg with recommendedDefault true.",
+  "consequences": "The project inherits the pg driver's mature parameterised-query surface, its pool implementation with configurable size and idle-timeout, and its clean rejection propagation for constraint violations and connection errors. The Round-6 Hyperdrive adapter (Cloudflare's pg-driver-compatible connection-pool and query-cache surface per https://developers.cloudflare.com/hyperdrive/) slots in as a v1.1.0 minor bump that swaps the import at the facade boundary; no outward-interface change, no AC moves. Projects that want postgres.js instead pass adapter=postgresjs at apply time; the facade's outward interface is preserved. Projects that want an ORM (Kysely, Drizzle, Prisma) sitting inside the facade wire the ORM inside the facade against the same pg.Pool the shipped default holds; the outward interface is preserved. Standards trace clause: node-postgres parameterised-queries contract at https://node-postgres.com/features/queries.",
+  "alternativesConsidered": [
+    {
+      "name": "postgres.js as the shipped default",
+      "summary": "Ship postgres.js as the v1.0.0 default driver, elicit pg as the alternative.",
+      "reasonNotChosen": "postgres.js is a fine driver but has a smaller ecosystem and the round-6 Hyperdrive adapter targets pg specifically per Cloudflare's Hyperdrive docs. Shipping pg first keeps the round-6 slot clean; postgres.js remains available via the elicit."
+    },
+    {
+      "name": "Bless one ORM (Kysely or Drizzle) as the shipped surface",
+      "summary": "Ship Kysely or Drizzle as the v1.0.0 default; the facade wraps the ORM, not pg.",
+      "reasonNotChosen": "ORMs sit above pg and are an operator choice on top of the driver, not a substitute for it. Blessing one ORM as default pushes the shelf into a maintenance stance on a tool it does not build; the facade contract is orm-neutral so a project may drop an ORM inside the facade without moving any AC."
+    },
+    {
+      "name": "Hyperdrive as the shipped v1.0.0 driver",
+      "summary": "Ship Hyperdrive-wrapped pg as the v1.0.0 default.",
+      "reasonNotChosen": "Hyperdrive is a Cloudflare-account-bound service and the round-5 spec ruling 5 (Baz decision 8) places Postgres as the local-first blueprint. Making Hyperdrive the default would force every project to bind to a Cloudflare account before applying the blueprint. Round 6 lands Hyperdrive as a v1.1.0 minor adapter behind an elicit, keeping local-first at v1.0.0."
+    }
+  ],
+  "createdAt": "2026-09-06T15:47:00.000Z",
+  "updatedAt": "2026-09-06T15:47:00.000Z"
+}

package/blueprints/persistence-data-postgres/contributions/adrs/adr-2802-persistence-data-postgres-migration-shape.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-2802-persistence-data-postgres-migration-shape",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Numbered forward-only .sql migration files; one file one transaction; migration runner tool elicited",
+  "context": "The Postgres ecosystem has multiple migration tools (node-pg-migrate, sqitch, flyway, prisma migrate, drizzle-kit, knex migrations). Each imposes a different filename convention, a different bookkeeping strategy, and a different transaction shape. Blessing one blocks projects that already carry another; blessing none diffuses the shape across the shelf.",
+  "decision": "The shipped discipline is numbered forward-only .sql migration files under an elicited migrations directory (default ./migrations/). Each filename begins with a monotonically increasing integer that is unique across the directory (001_..., 002_..., 003_...); the file body is engine-native SQL. The in-tree runner applies each file inside its own transaction (BEGIN, run the file body, COMMIT on success or ROLLBACK on error); the runner records applied filenames in a schema_version bookkeeping table it maintains inside the same database. There are no down migrations; a rollback is a new numbered file inverting the earlier change. Which runner tool the project reaches for is elicited on this ADR (bespoke Node runner shipped in the fixture, node-pg-migrate, sqitch, flyway); recommendedDefault is the bespoke Node runner because it holds the fewest opinions and reads the migrations directory directly.",
+  "consequences": "The project gets a portable migration shape any Postgres client can apply (a plain .sql file with a leading integer). One file one transaction bounds the rollback surface cleanly but forbids atomic schema changes spanning two files; projects combine multi-step changes into one file. Numbered forward-only means the deploy pipeline's rollback story is a new migration, not a down step; the deploy runbook names this. Refusing to bless a runner tool keeps the shelf out of a maintenance stance; the operator picks whichever tool their team already carries and points it at the same directory. Standards trace clause: generic enterprise practice.",
+  "alternativesConsidered": [
+    {
+      "name": "Bless node-pg-migrate as the shipped runner",
+      "summary": "Ship node-pg-migrate as the v1.0.0 default; the applying project inherits its filename convention, its bookkeeping table shape, and its up/down direction.",
+      "reasonNotChosen": "node-pg-migrate is a fine tool but its filename convention differs from sqitch and flyway; blessing it forces a project already on sqitch to migrate their catalogue. The discipline (numbered forward-only, one file one transaction) is what carries between tools; blessing the discipline and eliciting the tool is cheaper for the operator."
+    },
+    {
+      "name": "Allow bidirectional migrations (up and down)",
+      "summary": "Ship the migration shape as pairs of .sql files (001_up.sql, 001_down.sql); the runner applies up in order and down in reverse.",
+      "reasonNotChosen": "Down migrations are a lie in production. Rolling back a shipped schema change with a down migration is safe only when the change did not add data-carrying columns or drop constraints in a way the down cannot invert. Forward-only migrations make the rollback path explicit (a new numbered file); the operator writes what actually inverts the change rather than trusting a mechanical down."
+    }
+  ],
+  "createdAt": "2026-09-06T15:47:00.000Z",
+  "updatedAt": "2026-09-06T15:47:00.000Z"
+}