rcf-lite 0.11.0 → 0.13.0

package/blueprints/observability-probe-endpoints/contributions/user-stories/observability-probe-endpoints-us-14105.json

@@ -0,0 +1,46 @@
+{
+  "usId": "observability-probe-endpoints-US-14105",
+  "prdId": "PRD-001",
+  "reqId": "observability-probe-endpoints-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Each profile's response contract is exactly what its supervisor reads and nothing more",
+  "asA": "operator whose service is probed by a supervisor with a fixed idea of what a probe response looks like",
+  "iWant": "the response contract to match the supervisor's shape and stay minimal",
+  "soThat": "the supervisor's parsing never sees an unexpected field and the surface never carries operational detail the supervisor does not read",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-14105-1",
+      "description": "The `loadBalancer` profile answers with an empty response body and the resolved status code (200 pass, 503 fail).",
+      "given": "a process on the `loadBalancer` profile whose readiness predicate is pass, then fail",
+      "when": "an HTTP GET is issued against the resolved health path in each state",
+      "then": "the pass response has status 200 with content-length 0 and no body; the fail response has status 503 with content-length 0 and no body",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14105-2",
+      "description": "The `kubernetes` profile answers with a JSON body of exactly `{\"status\":\"pass\"}` or `{\"status\":\"fail\"}` and no additional keys.",
+      "given": "a process on the `kubernetes` profile with liveness pass and readiness pass, then readiness fail",
+      "when": "an HTTP GET is issued against `/live` and `/ready` in each state and the parsed JSON body key set is inspected",
+      "then": "the parsed body is exactly a one-key object whose only key is `status` and whose value is `pass` or `fail` matching the resolved answer",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14105-3",
+      "description": "The `dockerHealthcheck` profile exits with code 0 on pass and a non-zero code on fail; the profile emits no HTTP surface.",
+      "given": "a process configured with `probeInterface.profile: dockerHealthcheck` and the profile's readiness predicate pass, then fail",
+      "when": "the profile's healthcheck command entry point is invoked in each state",
+      "then": "the pass invocation exits with code 0; the fail invocation exits with a non-zero code; the process opens no HTTP probe listener when this profile is selected",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1502-observability-probe-endpoints-handler-set",
+    "TAC-1504-observability-probe-endpoints-non-http-adapters"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/observability-probe-endpoints/contributions/user-stories/observability-probe-endpoints-us-14106.json

@@ -0,0 +1,45 @@
+{
+  "usId": "observability-probe-endpoints-US-14106",
+  "prdId": "PRD-001",
+  "reqId": "observability-probe-endpoints-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "External-visible probe responses expose no internal identifier or operational value",
+  "asA": "operator whose probe surface is reachable by anyone who resolves the traffic host",
+  "iWant": "the probe response to carry no dependency name, environment, hostname, replica id, build hash, or metric",
+  "soThat": "the surface never fingerprints the service to a reader who was not meant to inspect the internal shape",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-14106-1",
+      "description": "The Kubernetes profile's `/live` and `/ready` responses contain no substring matching a declared dependency name, environment name, hostname, replica identifier, build hash, or commit sha.",
+      "given": "a process on the Kubernetes profile with declared dependencies `paymentsProvider` and `primaryStore`, environment `live`, hostname `svc-abc-123`, build hash `deadbeef`, commit sha `abcd1234abcd1234abcd1234abcd12341234abcd`",
+      "when": "an HTTP GET is issued against `/live` and against `/ready` and each response body is scanned for the tokens above",
+      "then": "no scan finds any of the tokens on either response body",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14106-2",
+      "description": "The profile validator refuses a profile override that adds a field beyond the enumerated response contract at boot.",
+      "given": "a profile configuration that adds a `dependencies` array to the Kubernetes profile's response body",
+      "when": "the profile validator runs at boot",
+      "then": "the process exits with a non-zero code and emits a `PROBE_RESPONSE_FIELD_REFUSED` error naming the offending field and the profile name",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14106-3",
+      "description": "The load-balancer and reverse-proxy profile responses contain content-length zero on every request.",
+      "given": "a process on the `loadBalancer` profile and a second process on the `reverseProxy` profile, both booted normally",
+      "when": "HTTP GET requests are issued against the resolved health path on each process for both pass and fail states",
+      "then": "every response carries `Content-Length: 0` and the response body is empty",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1502-observability-probe-endpoints-handler-set"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/observability-probe-endpoints/contributions/user-stories/observability-probe-endpoints-us-14107.json

@@ -0,0 +1,45 @@
+{
+  "usId": "observability-probe-endpoints-US-14107",
+  "prdId": "PRD-001",
+  "reqId": "observability-probe-endpoints-REQ-007",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The probe paths sit on the project's auth-exempt list scoped exactly to the resolved set on the resolved listener",
+  "asA": "operator running the service behind an auth middleware that rejects unauthenticated requests by default",
+  "iWant": "the supervisor's probe requests to bypass auth on exactly the profile-resolved probe paths and only on the listener the profile bound those handlers to",
+  "soThat": "the supervisor gets the answer without a credential it cannot present and no adjacent route falls under the same exemption",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-14107-1",
+      "description": "On the Kubernetes profile with fused topology and an auth middleware that rejects unauthenticated requests, GET on the resolved `/live` and `/ready` paths returns the probe status; GET on any other user-traffic route returns the middleware's unauthenticated response.",
+      "given": "a process on the Kubernetes profile with fused topology, a project auth middleware installed on the user-traffic listener that returns 401 on unauthenticated requests, and a user-authored `/api/orders` route on that listener",
+      "when": "unauthenticated GET requests are issued to `/live`, `/ready`, `/api/orders`, and `/ready/next`",
+      "then": "`/live` and `/ready` return 200 or 503 per the probe answer; `/api/orders` returns 401; `/ready/next` returns the route's normal handler-or-not-found response after the middleware runs (a match on `/ready/next` is not treated as an exempt path)",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14107-2",
+      "description": "On the Kubernetes profile with separate-port topology, the separate probe listener does not install the project auth middleware and answers probes without an auth challenge; the user-traffic listener answers `/live` and `/ready` under normal auth rules.",
+      "given": "a process on the Kubernetes profile with `probeListener.separatePort: 9091` and a project auth middleware installed on the user-traffic listener",
+      "when": "unauthenticated GET requests are issued to `/live` and `/ready` on both port 9091 and on the user-traffic port",
+      "then": "the port-9091 requests return the probe status; the user-traffic-port requests return the auth middleware's unauthenticated response",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14107-3",
+      "description": "The exemption list produced by the profile at boot enumerates exactly the resolved probe path set, scoped by exact-match rules, and is refused if any entry contains a wildcard or prefix syntax.",
+      "given": "the exemption list produced by the profile resolver on the Kubernetes profile default",
+      "when": "the exemption-list emitter runs and the produced entries are inspected",
+      "then": "the list contains exactly the strings `/live` and `/ready` and their exact-match matcher rule; any injected entry containing `*` or a trailing slash to imply a prefix causes the emitter to refuse with a stable-coded error",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1503-observability-probe-endpoints-listener-topology"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/observability-probe-endpoints/contributions/user-stories/observability-probe-endpoints-us-14108.json

@@ -0,0 +1,46 @@
+{
+  "usId": "observability-probe-endpoints-US-14108",
+  "prdId": "PRD-001",
+  "reqId": "observability-probe-endpoints-REQ-008",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Switching the target integration is a configuration change that takes effect on next boot",
+  "asA": "operator moving a service from one supervising system to another",
+  "iWant": "the shift to be a change to the profile name and its options and nothing else",
+  "soThat": "the migration cost is bounded and the source tree stays free of per-supervisor conditionals",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-14108-1",
+      "description": "A running service on the `kubernetes` profile, reconfigured to `probeInterface.profile: loadBalancer` and restarted, binds a single `/health` handler with the `singleHealthSignal` semantic model without changes to the source tree.",
+      "given": "a process booted on `kubernetes` default, and the same source tree with only `probeInterface.profile` changed to `loadBalancer` in configuration",
+      "when": "the process restarts on the new configuration and the topology binds",
+      "then": "a GET against `/health` returns 200 or 503; no probe handler is bound at `/live` or `/ready`; a source-tree diff between the two boots contains no non-configuration changes",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14108-2",
+      "description": "A profile switch that requires a new custom profile is authored against the profile contract and filed under `profiles/custom/<name>` in the project; the switch is then a configuration change to `probeInterface.profile: custom:<name>`.",
+      "given": "a project that authored a `custom:tcpOnly` profile against the profile contract at `profiles/custom/tcpOnly.js` (or equivalent)",
+      "when": "the operator sets `probeInterface.profile: custom:tcpOnly` in configuration and the process restarts",
+      "then": "the resolver loads the custom profile, the topology binds the profile's declared surface, and no additional source-tree change is required to move between the shipped set and the custom profile",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-14108-3",
+      "description": "The profile-resolver call site is a single import point in the process boot path; the source-tree scan finds no per-profile conditional outside the profile modules and the resolver itself.",
+      "given": "the project's boot-path source tree",
+      "when": "a scan searches for `probeInterface.profile` usage and per-profile branching (e.g., `if (profile === 'kubernetes')`) outside the `profiles/` directory and the profile-resolver module",
+      "then": "the scan finds exactly one usage of `probeInterface.profile` (the resolver invocation) and zero per-profile conditionals in the rest of the boot path",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1501-observability-probe-endpoints-profile-resolver",
+    "TAC-1502-observability-probe-endpoints-handler-set"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,51 @@
+# observability-probe-endpoints blueprint coordination vocabulary
+
+This file is the observability-probe-endpoints half of the cross-blueprint contract. The Phase 1 conflict detector matches scope:global ADR topics by EXACT string equality, and AC ids are unnamespaced by the 0.5.0 grammar. Any blueprint intended to compose with this one must reuse these exact strings and respect these bands.
+
+## Global ADR topics this blueprint contributes (exact strings)
+
+| Topic string | observability-probe-endpoints contribution | Origin | Composition note |
+|---|---|---|---|
+| `healthProbes` | ADR-1501-observability-probe-endpoints-health-probes | Reused from the observability-essentials vocabulary (observability-essentials contributes a self-supervised two-endpoint HTTP JSON contract on the request-traffic listener at the same topic string). This blueprint contributes an elicit-from-target-integration-profile model on the same topic string on purpose. | The one project-wide decision on the health probe interface. Composing this blueprint with observability-essentials fires a `globalAdrTopic` conflict by design because the two blueprints answer different questions: essentials commits to a self-supervised HTTP JSON floor; this blueprint commits to an elicit-and-adapt model whose shape follows the external supervisor. Expected resolution: one project-level ADR that either commits to the elicit-and-adapt model (external supervisor drives the shape) or the fused self-supervised model (project owns the shape) or an explicit hybrid with boundaries |
+| `readinessSemantics` | ADR-1502-observability-probe-endpoints-readiness-semantics | Reused from the observability-essentials vocabulary (observability-essentials contributes strict-any-fail-over-declared-deps as the project-wide readiness rule at the same topic string). This blueprint contributes per-profile readiness semantics on the same topic string on purpose. | The one project-wide readiness semantics decision. Composing with observability-essentials fires a `globalAdrTopic` conflict by design. Expected resolution: one project-level ADR that commits to one of the two rules or an explicit hybrid |
+
+The observability-probe-endpoints blueprint claims two global topics. Every other contribution is scope-local (ADR-1503 the Kubernetes default, ADR-1504 the separate-port option, and ADR-1505 the external-response secrecy rule do not contribute global topics; a composing blueprint that holds an opinion on the default profile, on probe-listener topology, or on response secrecy authors its own project-level ADR if it wants to override).
+
+Note on the deliberate conflict with observability-essentials: this blueprint is designed for the EXTERNAL-SYSTEM INTEGRATION case (orchestrators, load balancers, uptime monitors probing the service, with their conventions driving the wire shape). observability-essentials is designed for the SELF-SUPERVISED all-in-one case (probes plus public status page plus notification outcome sink for a project that designs its own observability floor). Both are legitimate; each is the right default for its case. The conflict is the mechanism telling the operator to pick one intentionally. Precedent for the vendor-sibling pattern: security-auth-clerk conflicts with security-auth-magic-link on `authModel` on purpose; persistence-data-d1 conflicts with persistence-data-sqlite on both `persistenceStore` and `migrationDiscipline` on purpose. This blueprint follows the same pattern on `healthProbes` and `readinessSemantics`.
+
+Note on the delineation from observability-essentials's `statusPageContract` topic: this blueprint does not contribute an opinion on the public status page. A project that wants the probe surface from this blueprint AND the public status page and notification outcome sink from observability-essentials resolves the two `healthProbes` and `readinessSemantics` conflicts with project-level ADRs and keeps `statusPageContract` on the essentials-supplied side; the blueprints then compose without further conflict.
+
+Rules for new topics (inherited from the application-spa, application-api-rest, security-auth-magic-link, persistence-data-sqlite, ci-pipeline, observability-essentials, security-secrets-management, security-auth-clerk, email-smtp-resend, and deploy-cloudflare-workers vocabularies, restated as law): lower camel case, one concept per topic, no version suffixes. A topic names the decision area, not the chosen answer. Do not mint variants of existing strings (`probeInterface`, `probeSurface`, `probes`, `livenessReadiness`, `probeTransport` are all wrong when `healthProbes` already exists; `readinessAggregation`, `readyPolicy`, `readinessRule` are all wrong when `readinessSemantics` already exists).
+
+## Id number bands (registry bootstrap)
+
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.5.0 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (v1.1 candidate).
+
+This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| application-spa | 1101-1899 | 2xx | shipped v1.3.0 | `clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel` |
+| application-api-rest | 2101-2899 | 3xx | shipped v1.0.0 | `errorEnvelope`, `authModel`, `apiVersioning`, `logging` |
+| security-auth-magic-link | 3101-3899 | 5xx | shipped v1.0.0 | `authModel` |
+| email-smtp-resend | 4101-4899 | 4xx | shipped v1.0.0 | none |
+| hello-panel (walkthrough exemplar) | 4101-4899 | 4xx | doc-reserved; teaching exemplar in `packages/rcf-lite/docs/blueprint-authoring-walkthrough.md`, not shipped as a blueprint directory | `operatorPanel` |
+| persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| ci-pipeline | 6101-6899 | 7xx | shipped v1.0.0 | `ciGates`, `strictCoverageGate` |
+| observability-essentials | 7101-7899 | 8xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics`, `statusPageContract` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `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.0.0 | `healthProbes`, `readinessSemantics` |
+
+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.
+
+## Shared expectations for future composing blueprints
+
+- Reuse `healthProbes` exactly as spelled here when your blueprint holds an opinion on the health probe interface; contribute your own scope:global ADR on that string and let composition surface the pairing. A future blueprint that ships a metrics-probe hybrid or a health-check protocol variant (an OpenTelemetry-agent-scrape probe, a JMX health surface) will conflict here by design and expect a project-level ADR resolution.
+- Reuse `readinessSemantics` exactly as spelled here when your blueprint holds an opinion on readiness aggregation or its evaluator cadence.
+- The Kubernetes default (ADR-1503), the separate-port option (ADR-1504), and the external-response secrecy rule (ADR-1505) are scope-local. A composing blueprint that holds a different opinion on the default profile, the listener topology, or the response surface authors its own project-level ADR; none of them are minted as globals because the space of legitimate variations is smaller than the space of legitimate `healthProbes` variations.
+- Global topics that plausibly belong to a future blueprint and are NOT claimed by any shipped blueprint: `messageSerialisation` and `deliverySemantics` (a message-consumer blueprint's natural globals), `caching` (unclaimed by every shipped blueprint), `metricsExport` and `tracingProtocol` (natural globals for a metrics or tracing blueprint that would compose alongside this one), `deploymentPackaging` (unclaimed; a natural global for a container-image or artefact-bundling blueprint that composes above the deploy target). Define any of these in your own package's topics doc, in this file's format, and consider whether the band-registry table above needs your slug added.

package/blueprints/observability-probe-endpoints/guide/observability-probe-endpoints.md

@@ -0,0 +1,83 @@
+# Observability probe endpoints blueprint guide
+
+## What it is
+
+A default probe-surface blueprint for rcf-lite projects that must integrate with an EXTERNAL supervising system whose conventions drive the probe wire shape. The blueprint contributes the WHAT of a probe pattern: how the operator declares which external supervisor the service runs under (`kubernetes`, `loadBalancer`, `uptimeMonitor`, `systemd`, `dockerHealthcheck`, `reverseProxy`, or a project-authored `custom:<name>`), how each profile fixes the probe transport, path or command surface, response contract, and semantic distinction between liveness and readiness for that supervisor, how a fused-listener default coexists with a `probeListener.separatePort` opt-in for probe-traffic isolation, how the auth-exempt list stays scoped to the resolved probe path set exactly, and how switching supervising systems is a configuration change rather than a source-tree reshape.
+
+Concretely, the blueprint ships eight requirements, eight user stories (twenty-four acceptance criteria), four architecture components, and five architecture decision records. Two ADRs are `scope: global` on the topics `healthProbes` (the profile-elicited probe interface) and `readinessSemantics` (per-profile readiness aggregation); the other three are scope-local (Kubernetes default profile, separate-port option, external-response secrecy rule). The two global ADRs conflict with the observability-essentials sibling by design; see 'Boundary with observability-essentials' below.
+
+## What it is not
+
+Not an all-in-one observability floor. There is no public status page here, no notification outcome sink, no metrics-export surface, no distributed-tracing surface, no authenticated operator dashboard. observability-essentials is the blueprint for the self-supervised all-in-one case; this one exists for the case where the external supervising system's conventions come first.
+
+Not a readiness-check implementation. The blueprint fixes the SHAPE of the readiness predicate boundary (a synchronous function returning pass or fail, reading state a project-supplied evaluator maintains on its own cadence) and each profile's default aggregation rule. The per-dependency check code and the evaluator implementation are project-authored.
+
+Not a supervisor-specific SDK. The blueprint holds no SDK dependency on Kubernetes, no client library for a specific cloud load balancer, no wrapper around a specific uptime-monitor API. The profile contract shapes the wire surface; the project brings whichever integration bits it needs on the outside of the boundary.
+
+Not an auth middleware. The blueprint emits an exact-match exempt-path list the project's own auth middleware installer consumes. The middleware installer, the auth model itself, and the check code stay project-side; the exemption is a boundary contract, not a middleware implementation.
+
+Not a listener library. The topology component (TAC-1503) accepts a project-supplied `userTrafficListener` and a project-supplied `listenerFactory` for the separate-port case. The blueprint holds no opinion on the HTTP server library (Node HTTP, Express, Hono, Fastify, or the Worker-style edge platform's own router).
+
+## Boundary with observability-essentials
+
+observability-essentials and observability-probe-endpoints are BOTH `observability` category blueprints. They answer different questions:
+
+- **observability-essentials** targets the self-supervised, all-in-one case: the project owns its observability surface end to end, wires two HTTP JSON probes (`/healthz`, `/readyz`) on the request-traffic listener with a stable body shape, ships a public status page for external readers, and ships a notification outcome sink for durable notification records. The audience of the probe body is the operator inspecting the deployed service in triage. The identity is 'a default observability floor'.
+
+- **observability-probe-endpoints** targets the external-integration case: the service runs under a specific external supervising system (a Kubernetes kubelet, an application load balancer, an uptime monitor, a systemd unit, a Docker HEALTHCHECK invocation, a reverse-proxy upstream health check), and the wire shape of the probes follows that supervisor's conventions. The audience of the probe response IS the external supervisor; the response is minimal by construction so the surface never carries reconnaissance value to unintended readers. The identity is 'make your service correctly probeable by whatever external system supervises it'.
+
+Composing the two on one project fires two `globalAdrTopic` conflicts (on `healthProbes` and on `readinessSemantics`) on purpose. The four documented resolution paths per topic apply: adopt the incoming blueprint (remove the existing), keep the existing (do not add the incoming), author a project-level ADR that supersedes both, or declare the resolution on the add itself with `--resolve`. The right resolution is usually one of two shapes:
+
+- **Shape A (external supervisor wins):** the project runs under a supervisor whose conventions drive the wire shape; a project-level ADR fixes both topics against the probe-endpoints model and observability-essentials contributes the public status page and notification outcome sink through the compose while keeping its `statusPageContract` topic untouched.
+- **Shape B (self-supervised wins):** the project designs its own observability floor without a specific external supervisor's conventions in view; a project-level ADR fixes both topics against the essentials model and this blueprint is not applied.
+
+Explicit hybrids exist (an internal essentials-shaped surface for one audience and a profile-shaped external surface for the supervising system) and are legitimate; the project-level ADR names both surfaces with explicit boundaries and both blueprints compose.
+
+Composing with the `deploy-cloudflare-workers` blueprint is a separate concern: that blueprint mandates its own build-provenance probe (`/healthz` by convention) whose response body carries `{ versionSha, builtAt, ciRunUrl }` for the deploy verifier's reconciliation, which is incompatible with every profile's minimal response contract; the two surfaces coexist on distinct paths (this blueprint's profile-owned path stays minimal, the deploy blueprint's provenance path lives on a separate string), and the boundary is documented on the deploy side in `assets/verification/served-surface-probes.md`.
+
+## When to reach for it
+
+Reach for the observability-probe-endpoints blueprint when:
+
+- The service runs under a specific external supervising system (Kubernetes, cloud load balancer, uptime monitor, systemd unit under `Type=notify`, Docker HEALTHCHECK invocation, reverse-proxy upstream health check) whose conventions drive what a probe looks like and what the answer means.
+- The probe surface is reachable by parties beyond the intended supervisor (a fused-topology deployment where the public host resolves to the same port that answers probes), and the response contract must be minimal to keep reconnaissance value low.
+- Multi-environment deployments switch supervising systems across environments (a `dev` environment on Docker Compose with a load-balancer-shaped health check, a `live` environment on Kubernetes with liveness and readiness); a configuration change per environment is the intended migration path.
+- The probes are one integration surface among several the service exposes; other observability concerns (public status page, notification outcomes, metrics export, tracing) belong to other blueprints and stay out of scope here.
+
+## When it does not fit
+
+Do not reach for the observability-probe-endpoints blueprint when:
+
+- The project is a self-supervised all-in-one deployment where a single opinionated observability floor is the intended shape; observability-essentials is the right pick.
+- The service is not probed by an external supervisor at all (a batch job with no supervising loop, a one-shot script, an internal-only tool without a health-check consumer). The blueprint's elicitation surface has nothing to fix in that case.
+- The probes need to expose richer per-dependency state on the wire for a specific supervising system that reads it (an OpenTelemetry-agent-scrape shape, a gRPC-health-with-service-name shape). The blueprint's default profile set does not cover those; a `custom:<name>` profile is the mechanism escape, or a project-level ADR supersedes ADR-1501 and the project authors the richer surface directly.
+- The project already has a project-level `healthProbes` ADR the operator wants to keep; applying this blueprint would fire a conflict the operator does not want to resolve. Not applying the blueprint is a legitimate outcome.
+
+The round-2 shelf brief originally scoped this blueprint as a `kubernetes-service` deployment-shape blueprint, then reshaped it during review into `observability-probe-endpoints` (a probe-surface blueprint for any external supervising system, with Kubernetes as the shipped default). The reshape moves the identity from 'ship on Kubernetes' to 'be probeable by whichever supervisor probes you'; the boundary with observability-essentials (self-supervised all-in-one) came out of that reshape too. A future `deploy-kubernetes` blueprint in the `deploy` category may take on the deployment-manifest side of the original candidate; this one is the probe-surface side.
+
+## What a good outcome looks like
+
+A project applies the observability-probe-endpoints blueprint on a fresh tree, declares its `probeInterface.profile` value for each environment, wires the readiness predicate against its declared dependency evaluator, chooses fused topology or `probeListener.separatePort` per environment, realises TAC-1501 through TAC-1504 in project-authored FBSes, and lands on a deployed service where:
+
+- A Kubernetes-supervised pod on the shipped default answers HTTPGet `/live` and `/ready` on the container's request-traffic port; the standard `livenessProbe: { httpGet: { path: /live, port: <containerPort> } }` and `readinessProbe: { httpGet: { path: /ready, port: <containerPort> } }` on the podspec work without further wiring.
+- A load-balancer-supervised container on the `loadBalancer` profile answers one HTTP GET at the resolved `/health` path with the status code alone and an empty body; the LB target-group health check sees the status flip within its own health-check interval budget and pulls the target from rotation without ambiguity from a body it never read.
+- A systemd-supervised process on the `systemd` profile emits `sd_notify(READY=1)` after boot and `sd_notify(WATCHDOG=1)` on the configured watchdog cadence; the unit under `Type=notify` starts cleanly and stays healthy under the watchdog timeout.
+- A Docker HEALTHCHECK on the `dockerHealthcheck` profile exits 0 on pass and non-zero on fail from the exec entry point the profile exposes; the container's HEALTHCHECK status flips as `docker inspect` reports.
+- A separate-port Kubernetes deployment on `probeListener.separatePort: 9091` exposes only the traffic port on the Service; probes reach the pod on port 9091 from the kubelet on the pod network and never appear on the public interface.
+- An unauthenticated GET against `/live` or `/ready` on the auth-installed listener answers without a credential challenge; an unauthenticated GET against `/ready/next` (a path adjacent to the exempt entry but not exempt itself) returns the middleware's normal unauthenticated response; the exemption never expanded beyond the resolved probe path set.
+- A response body scan against every profile's response finds no dependency name, no environment identifier, no hostname, no replica id, no build hash, no commit sha; the pass or fail answer is the whole response surface.
+- Switching a service from Kubernetes to a Docker Compose deployment behind a load balancer is a change to `probeInterface.profile` in configuration; a source-tree diff between the two boots contains no non-configuration changes and no per-profile conditional appears outside the profile modules and the resolver call site.
+
+## Operator decisions that remain open after apply
+
+- Target integration profile (`kubernetes` default; `loadBalancer`, `uptimeMonitor`, `systemd`, `dockerHealthcheck`, `reverseProxy` supplied; `custom:<name>` slot for project-authored profiles). Blueprint owns the profile contract shape; project owns the per-environment selection.
+- Probe path defaults (`/live` and `/ready` for Kubernetes, `/health` for load balancer, per-profile defaults elsewhere). Blueprint owns the defaults; project overrides at boot for compliance with a particular supervisor convention or platform mandate.
+- Listener topology (fused user-traffic listener default, `probeListener.separatePort: <N>` opt-in). Blueprint owns the two shapes; project owns the per-environment choice.
+- Readiness predicate implementation (the per-dependency check code, the evaluator cadence, the timeout budgets). Blueprint owns the predicate boundary and each profile's default aggregation rule; project owns the checks and the cadence values.
+- Custom profile authoring (a project that authors `custom:<name>` supplies the profile object against the shipped contract). Blueprint owns the contract; project owns the profile.
+- Auth middleware installer (the project supplies the installer that consumes the exempt-path list the topology component emits). Blueprint owns the exempt-list shape; project owns the middleware and the installer.
+- systemd watchdog cadence, Docker HEALTHCHECK interval, TCP probe port. Blueprint owns the transport shape; project owns the cadence and interval values.
+
+## Cost-honesty paragraph
+
+Shipping this doc set costs the project the following. Every process pays the profile-resolver step at boot and one indirection through the frozen profile object at each probe binding site; the cost is small but real. A project that wants hot-reload of the profile selection restarts the process gracefully; the blueprint declines to support live rebinding. The separate-port topology opens a second HTTP listener when in effect; the extra port is a small memory cost and one more thing to think about in the deployment substrate. The profile-swap-is-config invariant costs the project a small amount of author discipline: per-profile branching in the boot path outside the resolver call site would defeat the invariant, and the AC scan catches the drift only if the project wires it into its own CI. The response-minimalism-by-construction rule costs the project any richer probe body it may have wanted for its own consumption (that surface belongs to observability-essentials, to an authenticated dashboard, or to a project-side triage endpoint outside the probe path set). The blueprint says nothing about the public status page, the notification outcome sink, metrics export, distributed tracing, or the auth model itself; a project that needs any of those spends its own build cycles on them and this blueprint does not save it any work there.

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

@@ -0,0 +1,50 @@
+# Persistence data D1 blueprint (v1.0.0)
+
+The ninth content blueprint on the rcf-build-lite blueprint mechanism. Scope: Cloudflare D1 as the project's primary durable store for Workers-deployed applications, accessed request-scoped through a Worker-side facade module that is the sole reader of the D1 binding, with numbered forward-only migrations owned by the wrangler CLI, a deploy pipeline gate ordering the migrations apply strictly before the Worker deploy, prepared-statement discipline that closes the SQL-injection surface by construction, batch atomicity for multi-statement writes, and a two-path recovery model (Time Travel plus a scheduled portable export). Targeted at small greenfield rcf-lite projects deployed on Workers; other engines behind the same facade contract on supersede.
+
+## Apply
+
+```
+rcf define blueprint add <path-to>/blueprints/persistence-data-d1
+```
+
+Phase 1 resolves local path sources only; registry and git-ref resolution is a mechanism follow-up. Apply is idempotent; `rcf define blueprint list` shows the applied entry grouped under the `persistence` category; `rcf define blueprint remove persistence-data-d1` cleanly removes an unreferenced application.
+
+## Anatomy
+
+| Piece | Where | What |
+|---|---|---|
+| Metadata | `blueprint.json` | Slug, version, category `persistence`, and the 23 contributions with scope/topic on the two global ADRs |
+| Doc set | `contributions/` | 7 REQs, 7 USs (20 ACs), 4 TACs, 5 ADRs, all schema-valid and namespaced (`persistence-data-d1-REQ-001` prefix family; `ADR-1401-persistence-data-d1-store-model` suffix family) |
+| Wrangler D1 binding sample | `assets/wrangler-config/d1-binding-shape.md` | The exact shape of a `d1_databases[]` entry with `binding`, `database_name`, `database_id`, `migrations_dir`, `migrations_table`, and `migrations_pattern`, worked as one committable example with placeholders only |
+| Migration file shape sample | `assets/migration-shape/migration-file-shape.md` | The exact shape of a numbered migration file under the wrangler-configured directory, with a worked four-migration example |
+| Facade module shape sample | `assets/facade-shape/facade-module-shape.md` | The exact shape of the D1 store facade module (`createStore({ env, bindingName, onEvent })` factory, named verbs, prepared-statement discipline, batch atomicity) with a worked domain example |
+| Batch usage sample | `assets/batch-usage/batch-atomicity-example.md` | The exact shape of a multi-statement atomic write through `db.batch([...])`, with the mid-batch-failure rollback semantics called out |
+| Guide | `guide/persistence-data-d1.md` | Operator-facing: when to use it, when not, what stays your call, and the promotion signals for the sibling single-file SQLite blueprint and future Postgres or replication blueprints |
+| Coordination vocabulary | `docs/topics.md` | The two global-topic strings this blueprint contributes and the shared id band registry (application-spa, application-api-rest, security-auth-magic-link, email-smtp-resend, persistence-data-sqlite, ci-pipeline, observability-essentials, security-secrets-management, security-auth-clerk, persistence-data-d1) |
+
+The doc set is contributions (copied into the project tree by `rcf define blueprint add`); the guide, assets, and docs are package-resident references. Guide rendering into `rcf/knowledge/docs/blueprint-guides/` and asset ingestion are mechanism follow-ups; until they land, the working agent reads them from the applied blueprint's source path recorded in `manifest.blueprints[].source`.
+
+## What it contributes, and what it deliberately does not
+
+Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (ratified decision 5) and no code.
+
+No FBS contributions, as a matter of principle (ratified policy 2026-08-19): FBSs are the work of the implementing agent, not the blueprint; project constraints have to be applied at the time of creation. The blueprint contributes the WHAT (the store facade contract, the wrangler-owned migration discipline, the deploy-pipeline gate contract, the prepared-statement and batch atomicity boundaries, the two-path recovery model, the metadata-only event log discipline); the implementing agent derives the HOW-tasks (FBS) in the host project, where the ACs contributed here get picked up by the project's own build sequencing.
+
+Deliberately not contributed: the domain schema (the tables the project's own entities live in are project-authored, on top of the migration directory the project maintains; the blueprint governs the facade contract and the migration discipline, not the domain shape); an ORM or query builder above the D1 prepared-statement surface (the facade is a project-authored surface; how it internally implements its verbs above the vendor binding is not blueprint-owned, but the boundary discipline refuses raw-SQL passthrough on the public surface); a Worker deploy blueprint (a companion `deploy-cloudflare-workers` blueprint is the natural pair for the Worker deploy step the deploy-gate TAC assumes; until it ships, projects wire their own deploy step); a secrets management surface for the CI credential that runs `wrangler d1 migrations apply` and `wrangler deploy` (the credential storage and rotation posture are the concern of the `security-secrets-management` blueprint, not this one); a CI pipeline template (CI shape is the concern of the `ci-pipeline` blueprint, not this one; this blueprint contributes the requirement that the migrations-apply step orders strictly before the deploy step, not the file that implements it); a replication or failover surface (D1's read-replica surface is a read-scaling primitive, not a failover primitive; a project needing failover supersedes ADR-1401 with an alternate engine); a logical schema-agnostic dump beyond the vendor's `wrangler d1 export` (out of scope; see ADR-1405's alternatives).
+
+## The two global decisions
+
+ADR-1401-persistence-data-d1-store-model ships `scope: global` on topic `persistenceStore`. This is the project's primary durable store engine choice: one Cloudflare D1 database bound into the Worker under a named binding, one entry point through the facade. A composing blueprint that holds a different engine opinion (the single-file SQLite blueprint on the same topic, a future Postgres blueprint, a KV-store blueprint) conflicts here by design and expects a project-level ADR resolution.
+
+ADR-1402-persistence-data-d1-migration-discipline ships `scope: global` on topic `migrationDiscipline`. This is the project's schema-evolution posture: numbered forward-only `.sql` files under the wrangler-configured directory, applied by the vendor CLI, gated in the deploy pipeline. A composing blueprint that holds an opinion on migration discipline (the SQLite blueprint's boot-time runner-at-open discipline on the same topic, a future event-sourced projection blueprint) conflicts here by design.
+
+See `docs/topics.md` for the exact strings, the expected resolutions, the delineation from the application-api-rest blueprint's `logging` topic (which governs the wire-log shape, not the store-event log shape), the deliberate-conflict statement against the persistence-data-sqlite blueprint (both blueprints ship the same two global topics with different vendor answers on purpose, mirroring the application-spa plus application-api-rest pairing on `errorEnvelope` and `authModel`), and the AC id band allocation (persistence-data-d1 owns 13101-13899, ADR/TAC suffix block 1401-1499).
+
+## Quality bar
+
+Single D1 database bound into the Worker under one named binding read by exactly one facade module; every read and write through the facade issued as `db.prepare(<static SQL literal>).bind(...)` with no consumer-supplied SQL and no `db.exec(<consumer string>)` on any path; multi-statement writes requiring atomicity through `db.batch([...])` with no partial-batch results surfaced; numbered forward-only `.sql` migration files under the wrangler-configured directory with the vendor CLI as the sole applier and the vendor bookkeeping table as the sole applied-state ledger; deploy pipeline that orders `wrangler d1 migrations apply` strictly before `wrangler deploy` per environment and refuses the deploy on any apply failure; two-path recovery (Time Travel point-in-time restore within the plan window and a scheduled `wrangler d1 export` to a portable off-vendor artifact) exercisable from the ops or CI surface without a Worker code change; structured event log at five defined moments (facadeReady, migrationsApplied, backupExported, timeTravelRestored, queryFailed) with metadata-only fields carrying no domain-row values. Every bar is carried by ACs in the doc set, not by this README.
+
+## Known mechanism-reach gaps
+
+None at v1.0.0. Every AC on every story is bound to at least one TAC that the host project must realise, and every AC's `then` clause is runtime-observable in the deployed application (source-tree import-graph scans for the boundary properties, wrangler CLI exit-code checks for the migration and deploy-gate properties, D1 read round-trips for the row-preservation properties on export and restore, event-sink accumulation for the log-shape properties, targeted grep for the SQL-string discipline). The mechanism-reach principle from the authoring standard section 7 is satisfied at ship: a project that applies this blueprint and does not realise a TAC leaves an unresolved `tacIds` reference on the story that `rcf define validate` and `rcf audit coverage` refuse. The one operational surface a project must own on its own is the CI pipeline that wires the deploy gate (TAC-1403); that responsibility is stated as a TAC interface (`ciStep.migrationsApply`, `ciStep.deploy`) with an explicit ordering contract, not as a smuggled runtime probe. The recovery runner (TAC-1404) is similarly a project-owned ops surface; the blueprint contributes the shape and the event contract, not the ops file that invokes it.

package/blueprints/persistence-data-d1/assets/batch-usage/batch-atomicity-example.md

@@ -0,0 +1,72 @@
+# Batch atomicity in the D1 facade
+
+D1 does not expose explicit BEGIN / COMMIT to the Worker binding. `db.batch([...])` is the vendor's atomicity primitive for multi-statement writes: the vendor's contract states that a mid-batch failure aborts and rolls back the entire sequence. This asset shows the shape a facade verb takes when its domain contract requires two or more statements to land as one unit (AC-13105-1, AC-13105-2).
+
+## Verb shape
+
+```javascript
+// src/store/entityBVerbs.js
+// A verb whose domain contract requires insertA + insertB + auditEntry
+// to land as one unit, or none.
+
+export function entityBVerbs(db, onEvent) {
+  return {
+    async createEntityBWithAudit({
+      entityAId,
+      entityBId,
+      payload,
+      auditActor,
+      now,
+    }) {
+      const batch = [
+        db
+          .prepare(
+            'INSERT INTO entityB (id, entityAId, payload, createdAt) VALUES (?, ?, ?, ?)'
+          )
+          .bind(entityBId, entityAId, payload, now),
+        db
+          .prepare(
+            'UPDATE entityA SET updatedAt = ? WHERE id = ?'
+          )
+          .bind(now, entityAId),
+        db
+          .prepare(
+            'INSERT INTO auditEntry (id, actor, action, targetId, at) VALUES (?, ?, ?, ?, ?)'
+          )
+          .bind(crypto.randomUUID(), auditActor, 'entityBCreated', entityBId, now),
+      ];
+
+      try {
+        const results = await db.batch(batch);
+        return { entityBId };
+      } catch (err) {
+        onEvent({
+          event: 'queryFailed',
+          ts: new Date().toISOString(),
+          verb: 'createEntityBWithAudit',
+          code: err.cause?.code ?? 'unknown',
+        });
+        throw err;
+      }
+    },
+  };
+}
+```
+
+Notes:
+
+- Every statement in the batch is a prepared statement authored inside the verb. The static SQL literals live in the verb body; values reach D1 only through `bind`. The prepared-statement discipline holds inside the batch as it does for single-statement verbs.
+- The verb does not chain sequential `db.prepare(...).run()` calls under an application-side try-catch to fake atomicity. The vendor's batch primitive is the only shape that gives the atomicity guarantee. AC-13105-1 verifies this by inspection.
+- On any statement in the batch failing, D1 rolls the sequence back (the vendor's contract); the verb rethrows without surfacing any partial state to the caller. AC-13105-2 exercises this against a local D1 primed to violate a UNIQUE constraint on the second statement.
+
+## What batch is not
+
+Not a cross-verb transaction. `batch()` is atomic across the statements in one call. Two independent facade verbs called sequentially by a consumer are NOT one transaction; the facade does not expose a begin/commit primitive because D1 does not support one on the Worker binding. AC-13105-3 verifies this by inspection.
+
+Not a way to fake atomicity around a computed decision. A workflow that reads with `first()`, computes something, then writes-if-condition is not atomic; a concurrent Worker request can change the read's result between the read and the write. Push the condition into the SQL (an `INSERT ... WHERE NOT EXISTS`, an `UPDATE ... WHERE version = ?`, an optimistic-lock pattern) so the whole decision lands in one batched statement.
+
+Not the only shape for a single-statement write. Single-statement writes commit as their own transaction naturally (SQLite's default autocommit); use `db.prepare(...).run()` directly for those verbs. Batch is reserved for the multi-statement-atomic case; using batch for a one-statement write is harmless but adds a wrapper the verb does not need.
+
+## Query-count budget
+
+D1's queries-per-Worker-invocation limit (currently 1000 on Paid, 50 on Free per the vendor's currently published limits) counts statements inside batches as individual queries. A verb whose batch grows past a few dozen statements is a design smell; break the domain contract into smaller atomic units, or reconsider whether the contract truly needs cross-statement atomicity.

package/blueprints/persistence-data-d1/assets/facade-shape/facade-module-shape.md

@@ -0,0 +1,115 @@
+# D1 store facade module shape
+
+The facade (TAC-1401) is one module that reads the D1 binding from the Worker `env`, exposes named domain verbs, issues every statement as a parameterised prepared statement, uses `db.batch([...])` for multi-statement atomicity, and emits structured lifecycle events on the injected sink. This asset shows the exact shape with a worked domain example.
+
+## Module layout
+
+```
+src/store/
+  facade.js          // this file: createStore + named verbs
+  entityAVerbs.js    // named verbs partitioned by domain slice (optional)
+  entityBVerbs.js
+  sessionVerbs.js
+  auditVerbs.js
+```
+
+The `facade.js` module is the ONLY file in the source tree that reads `env[BINDING_NAME]`. Every domain slice imports helpers from `facade.js` (the request-scoped `db` handle, the event emitter) and exports its named verbs; `facade.js` re-exports them into the store's public surface. A grep of the source tree for `env.<BINDING_NAME>` (or `env["<BINDING_NAME>"]`) returns exactly one match, and it is inside `facade.js`. AC-13101-1 is verified by that grep.
+
+## `createStore` factory
+
+```javascript
+// src/store/facade.js
+// The ONE module that reads the D1 binding.
+
+let isolateFirstInvocation = true;
+
+export function createStore({ env, bindingName, onEvent }) {
+  const db = env[bindingName]; // The ONE binding read in the tree.
+  if (!db) {
+    throw new Error(`D1 binding '${bindingName}' not present on env`);
+  }
+
+  if (isolateFirstInvocation) {
+    isolateFirstInvocation = false;
+    onEvent({
+      event: 'facadeReady',
+      ts: new Date().toISOString(),
+      bindingName,
+      environment: env.ENVIRONMENT ?? 'unknown',
+    });
+  }
+
+  return {
+    // Named domain verbs (per AC-13101-2, no raw-query passthrough).
+    ...entityAVerbs(db, onEvent),
+    ...entityBVerbs(db, onEvent),
+    ...sessionVerbs(db, onEvent),
+    ...auditVerbs(db, onEvent),
+  };
+}
+```
+
+## Named domain verb (single-statement)
+
+```javascript
+// src/store/entityAVerbs.js
+// Every SQL literal is static and authored here.
+
+export function entityAVerbs(db, onEvent) {
+  return {
+    async findEntityAByName({ name }) {
+      try {
+        return await db
+          .prepare('SELECT id, name, createdAt, updatedAt FROM entityA WHERE name = ?')
+          .bind(name)
+          .first();
+      } catch (err) {
+        onEvent({
+          event: 'queryFailed',
+          ts: new Date().toISOString(),
+          verb: 'findEntityAByName',
+          code: err.cause?.code ?? 'unknown',
+        });
+        throw err;
+      }
+    },
+
+    async insertEntityA({ id, name, createdAt, updatedAt }) {
+      try {
+        return await db
+          .prepare(
+            'INSERT INTO entityA (id, name, createdAt, updatedAt) VALUES (?, ?, ?, ?)'
+          )
+          .bind(id, name, createdAt, updatedAt)
+          .run();
+      } catch (err) {
+        onEvent({
+          event: 'queryFailed',
+          ts: new Date().toISOString(),
+          verb: 'insertEntityA',
+          code: err.cause?.code ?? 'unknown',
+        });
+        throw err;
+      }
+    },
+  };
+}
+```
+
+Notes:
+
+- The SQL literal is a static string authored inside the verb. It does not embed values from consumer arguments; the values reach D1 only through `bind`. AC-13104-1 verifies this by grep.
+- The verb's typed parameter list names the fields the SQL literal binds. It does not accept a `sql` or `query` string parameter. AC-13104-2 verifies this by inspection of the exported surface.
+- The verb catches D1 errors, emits a `queryFailed` event carrying only metadata (the verb name, the D1 error code), and rethrows. The event payload never includes `name` or any bound value. ADR-1403's discipline is enforced at emit time.
+
+## Named domain verb (multi-statement atomic write via batch)
+
+See `assets/batch-usage/batch-atomicity-example.md` for the worked shape.
+
+## What this asset is not
+
+Not a runnable facade. The snippets above are the SHAPE; a project's own domain verbs are authored per the domain's actual tables. Types, error wrappers, and observability adapters are project decisions on top of the shape.
+
+Not an ORM. Projects that reach for Drizzle or Kysely wire it inside the verb bodies and preserve the outward verb surface. The prepared-statement discipline (static SQL literals inside the verb, values only through `bind`) survives an ORM: most ORMs emit static SQL from typed queries at build time, and the AC-13104-1 grep still lands on static literals.
+
+Not the ci-pipeline gate. TAC-1403's deploy-gate is a CI file, not a facade responsibility; the two surfaces meet only through the shared event-record shape.