rcf-lite 0.26.0 → 0.27.0

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

@@ -11,39 +11,43 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited target-integration-profile (or its equivalent target-integration elicit); the AC substitutes the project's profile name for the illustrative Kubernetes / loadBalancer / reverseProxy / systemd tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited target-integration-profile (or its equivalent target-integration elicit); the AC substitutes the project's profile name for the illustrative Kubernetes / loadBalancer / reverseProxy / systemd tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited target-integration-profile (or its equivalent target-integration elicit); the AC substitutes the project's profile name for the illustrative Kubernetes / loadBalancer / reverseProxy / systemd tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-14107-4",
-      "description": "When the optional startup path is enabled on the Kubernetes profile, the exemption list produced by the profile at boot enumerates exactly three exact-match entries /live, /ready and /startup on the resolved listener; a wildcard or prefix entry (a trailing slash implying prefix, an entry containing *) causes the emitter to refuse with the same stable-coded error as AC-14107-3.",
+      "description": "When the optional startup path is enabled on the Kubernetes profile, the exemption list produced by the profile at boot enumerates exactly three exact-match entries /live, /ready and /startup on the resolved listener; a wildcard or prefix entry (a trailing slash implying prefix, an entry containing *) causes the emitter to refuse with the same stable-coded error as AC-14107-3. Template values the applying agent sets: The applying agent sets the elicited target-integration-profile (or its equivalent target-integration elicit); the AC substitutes the project's profile name for the illustrative Kubernetes / loadBalancer / reverseProxy / systemd tokens.",
       "given": "the exemption list produced by the profile resolver on the Kubernetes profile with probeInterface.options.kubernetes.startup.enabled set to true",
       "when": "the exemption-list emitter runs and the produced entries are inspected, and separately an injected entry containing */ or * is presented",
       "then": "the list contains exactly the three strings /live, /ready and /startup and their exact-match matcher rule; any wildcard-shaped entry is refused with a stable-coded error",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     }
   ],
   "tacIds": [

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

@@ -16,7 +16,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-14108-2",
@@ -25,7 +26,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-14108-3",
@@ -34,7 +36,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -64,7 +64,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
 | edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
-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.
+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 shelf-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 shelf lane.
 
 ## Shared expectations for future composing blueprints
 

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

@@ -4,7 +4,7 @@
 
 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.
+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). From essentials v2.0.0 onward this blueprint is the sole `scope: global` claimant on both topics; see 'Boundary with observability-essentials' below for the current alignment and the pre-v2 migration note.
 
 ## What it is not
 
@@ -26,12 +26,9 @@ observability-essentials and observability-probe-endpoints are BOTH `observabili
 
 - **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:
+From v2.0.0 of observability-essentials the two blueprints compose cleanly on the current shelf. Essentials v2 dropped its `scope: global` claims on the `healthProbes` and `readinessSemantics` topics and defers probe-path binding to this blueprint; probe-endpoints is now the sole `scope: global` claimant on both topics, so applying either order (essentials then probe-endpoints, or probe-endpoints then essentials) resolves to exactly one global ADR per topic with no `globalAdrTopic` conflict fired. The essentials blueprint continues to own `statusPageContract` and the notification-outcome sink; probe-endpoints continues to own the probe surface. The compose test at `packages/rcf-lite/test/blueprint/probe-path-alignment.test.js` is the ratified truth for this alignment.
 
-- **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.
+Historical migration note (pre-v2 essentials): earlier essentials releases (v1.x, superseded by v2.0.0) claimed `scope: global` on `healthProbes` and `readinessSemantics`. A project that still applies pre-v2 essentials alongside this blueprint fires the two conflicts and resolves them at project level with a project-level ADR (adopt one shape, keep the existing, author a project-level ADR that supersedes both, or declare the resolution on the add itself with `--resolve`). Migrating to essentials v2 removes the resolution burden.
 
 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`.
 

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

@@ -0,0 +1,19 @@
+# Changelog
+
+
+## 1.1.2 - 2026-09-10
+
+Second closure fix on the dimension-d ownership sweep for REQ-004: removed the `prepare().bind()` and `db.exec(<consumer string>)` literals from `ADR-1404.context` (the argument now names the prepared-statement discipline owned on `TAC-1401-persistence-data-d1-facade.responsibilities[2]`); added the one-line owner pointer to the facade-shape asset and the batch-usage asset naming the TAC responsibility indices they demonstrate. ADR-1404 bumped to 1.0.1. Chain-consistency lint zero on pass 1 and pass 2.
+
+## 1.1.1 - 2026-09-10
+
+Dimension-d single-definition-ownership cleanup on REQ-004: REQ description now references the prepared-statement discipline owned on TAC-1401 (facade responsibilities) rather than restating the vendor prepare/bind/exec literals. `deliveredBy` re-pointed at `TAC-1401-persistence-data-d1-facade.responsibilities.prepare` so the pass-2 delivery-carried check resolves against surface text present on the TAC. Chain-consistency lint zero on pass 1 and pass 2.
+
+## 1.1.0 - 2026-09-09
+Adds deliveredBy on REQ-001. Adds ownerRef and disposition to every AC. Closes chain-contradiction specimen F-3 by settling the allowed query surface on ADR-1404 (db.exec refused on the facade's public verbs and on consumer code; permitted only inside the migration runner, out of consumer reach). No new contributions.
+
+
+
+Review-fix (2026-09-09): Version bumped from 1.0.1 to 1.1.0 to reflect the net-added AC contributions on existing stories (migration-D1-binding failure paths added under US-13101; deploy-gate quota-exhausted added under US-13102). Prior 1.0.1 entry reclassified as prose-only; this bump covers the AC additions per section 8.
+
+Adds deliveredBy on REQ-002 through REQ-007 (six of seven mandatory REQs). Sweeps vendorCitation onto fixed ACs resting on vendor facts (AC-13103-1, AC-13104-3, AC-13105-2).

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

@@ -43,7 +43,7 @@ See `docs/topics.md` for the exact strings, the expected resolutions, the deline
 
 ## 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.
+Single D1 database bound into the Worker under one named binding read by exactly one facade module; every read and write through the facade follows the prepared-statement chain owned on TAC-1401-persistence-data-d1-facade.responsibilities[2] (parameterised statement literals, no consumer-supplied SQL and no raw `exec` on any path); multi-statement writes requiring atomicity go through the batch call owned on TAC-1401-persistence-data-d1-facade.responsibilities[3] 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
 

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

@@ -1,5 +1,7 @@
 # Batch atomicity in the D1 facade
 
+> Owner: the batch atomicity primitive the facade uses for multi-statement writes is defined on `TAC-1401-persistence-data-d1-facade.responsibilities[3]` (batch call); the surrounding prepared-statement discipline is defined on `TAC-1401-persistence-data-d1-facade.responsibilities[2]`. This asset demonstrates usage; the definitions live on the TAC.
+
 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

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

@@ -1,5 +1,7 @@
 # D1 store facade module shape
 
+> Owner: the prepared-statement chain the facade issues every read and write through is defined on `TAC-1401-persistence-data-d1-facade.responsibilities[2]`. This asset demonstrates usage; the definition lives on the TAC.
+
 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

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

@@ -1,26 +1,98 @@
 {
   "slug": "persistence-data-d1",
-  "version": "1.0.0",
+  "version": "1.1.2",
   "category": "persistence",
   "contributions": [
-    { "id": "persistence-data-d1-REQ-001", "kind": "req", "path": "requirements/persistence-data-d1-req-001.json" },
-    { "id": "persistence-data-d1-REQ-002", "kind": "req", "path": "requirements/persistence-data-d1-req-002.json" },
-    { "id": "persistence-data-d1-REQ-003", "kind": "req", "path": "requirements/persistence-data-d1-req-003.json" },
-    { "id": "persistence-data-d1-REQ-004", "kind": "req", "path": "requirements/persistence-data-d1-req-004.json" },
-    { "id": "persistence-data-d1-REQ-005", "kind": "req", "path": "requirements/persistence-data-d1-req-005.json" },
-    { "id": "persistence-data-d1-REQ-006", "kind": "req", "path": "requirements/persistence-data-d1-req-006.json" },
-    { "id": "persistence-data-d1-REQ-007", "kind": "req", "path": "requirements/persistence-data-d1-req-007.json" },
-    { "id": "persistence-data-d1-US-13101", "kind": "us", "path": "user-stories/persistence-data-d1-us-13101.json" },
-    { "id": "persistence-data-d1-US-13102", "kind": "us", "path": "user-stories/persistence-data-d1-us-13102.json" },
-    { "id": "persistence-data-d1-US-13103", "kind": "us", "path": "user-stories/persistence-data-d1-us-13103.json" },
-    { "id": "persistence-data-d1-US-13104", "kind": "us", "path": "user-stories/persistence-data-d1-us-13104.json" },
-    { "id": "persistence-data-d1-US-13105", "kind": "us", "path": "user-stories/persistence-data-d1-us-13105.json" },
-    { "id": "persistence-data-d1-US-13106", "kind": "us", "path": "user-stories/persistence-data-d1-us-13106.json" },
-    { "id": "persistence-data-d1-US-13107", "kind": "us", "path": "user-stories/persistence-data-d1-us-13107.json" },
-    { "id": "TAC-1401-persistence-data-d1-facade", "kind": "tac", "path": "tacs/tac-1401-persistence-data-d1-facade.json" },
-    { "id": "TAC-1402-persistence-data-d1-migration-catalog", "kind": "tac", "path": "tacs/tac-1402-persistence-data-d1-migration-catalog.json" },
-    { "id": "TAC-1403-persistence-data-d1-deploy-gate", "kind": "tac", "path": "tacs/tac-1403-persistence-data-d1-deploy-gate.json" },
-    { "id": "TAC-1404-persistence-data-d1-recovery-runner", "kind": "tac", "path": "tacs/tac-1404-persistence-data-d1-recovery-runner.json" },
+    {
+      "id": "persistence-data-d1-REQ-001",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-001.json"
+    },
+    {
+      "id": "persistence-data-d1-REQ-002",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-002.json"
+    },
+    {
+      "id": "persistence-data-d1-REQ-003",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-003.json"
+    },
+    {
+      "id": "persistence-data-d1-REQ-004",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-004.json"
+    },
+    {
+      "id": "persistence-data-d1-REQ-005",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-005.json"
+    },
+    {
+      "id": "persistence-data-d1-REQ-006",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-006.json"
+    },
+    {
+      "id": "persistence-data-d1-REQ-007",
+      "kind": "req",
+      "path": "requirements/persistence-data-d1-req-007.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13101",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13101.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13102",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13102.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13103",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13103.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13104",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13104.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13105",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13105.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13106",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13106.json"
+    },
+    {
+      "id": "persistence-data-d1-US-13107",
+      "kind": "us",
+      "path": "user-stories/persistence-data-d1-us-13107.json"
+    },
+    {
+      "id": "TAC-1401-persistence-data-d1-facade",
+      "kind": "tac",
+      "path": "tacs/tac-1401-persistence-data-d1-facade.json"
+    },
+    {
+      "id": "TAC-1402-persistence-data-d1-migration-catalog",
+      "kind": "tac",
+      "path": "tacs/tac-1402-persistence-data-d1-migration-catalog.json"
+    },
+    {
+      "id": "TAC-1403-persistence-data-d1-deploy-gate",
+      "kind": "tac",
+      "path": "tacs/tac-1403-persistence-data-d1-deploy-gate.json"
+    },
+    {
+      "id": "TAC-1404-persistence-data-d1-recovery-runner",
+      "kind": "tac",
+      "path": "tacs/tac-1404-persistence-data-d1-recovery-runner.json"
+    },
     {
       "id": "ADR-1401-persistence-data-d1-store-model",
       "kind": "adr",
@@ -35,8 +107,20 @@
       "scope": "global",
       "topic": "migrationDiscipline"
     },
-    { "id": "ADR-1403-persistence-data-d1-event-secrecy", "kind": "adr", "path": "adrs/adr-1403-persistence-data-d1-event-secrecy.json" },
-    { "id": "ADR-1404-persistence-data-d1-store-boundary", "kind": "adr", "path": "adrs/adr-1404-persistence-data-d1-store-boundary.json" },
-    { "id": "ADR-1405-persistence-data-d1-recovery-model", "kind": "adr", "path": "adrs/adr-1405-persistence-data-d1-recovery-model.json" }
+    {
+      "id": "ADR-1403-persistence-data-d1-event-secrecy",
+      "kind": "adr",
+      "path": "adrs/adr-1403-persistence-data-d1-event-secrecy.json"
+    },
+    {
+      "id": "ADR-1404-persistence-data-d1-store-boundary",
+      "kind": "adr",
+      "path": "adrs/adr-1404-persistence-data-d1-store-boundary.json"
+    },
+    {
+      "id": "ADR-1405-persistence-data-d1-recovery-model",
+      "kind": "adr",
+      "path": "adrs/adr-1405-persistence-data-d1-recovery-model.json"
+    }
   ]
 }

package/blueprints/persistence-data-d1/contributions/adrs/adr-1404-persistence-data-d1-store-boundary.json

@@ -2,11 +2,11 @@
   "adrId": "ADR-1404-persistence-data-d1-store-boundary",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "accepted",
   "title": "The D1 store facade is the only module that reads the D1 binding; consumers use named domain verbs, and every statement is a parameterised prepared statement",
-  "context": "A persistence boundary that leaks (the domain code reads the D1 binding from `env` directly, or the facade exposes a general-purpose raw-SQL passthrough) is a boundary the swap-out story does not work through, the test-double story does not work through, the reasoning-about-persistence-code-paths story does not work through, and (worse for D1 than for a local-file engine) the SQL-injection story does not work through: consumer-supplied string concatenation into a prepared-statement argument is functionally equivalent to a `db.exec(<consumer string>)` call, and the vendor's `prepare().bind()` chain is only safe when it stays a static SQL literal.",
-  "decision": "One module (the D1 store facade, TAC-1401) reads the D1 binding from the Worker `env`. Every other module in the source tree that touches persistence imports the facade and calls its named verbs. The facade's public surface exposes named domain verbs with typed parameters; it does not export the D1 binding, and it does not expose a general-purpose query method whose parameter is a SQL string or a prepared-statement object supplied by a consumer. Every statement the facade issues is a `db.prepare(<static SQL literal>).bind(<parameters>).first() | .all() | .run() | .raw()` chain; `db.exec(...)` is never called with a non-literal string; SQL is never constructed by string concatenation with consumer arguments. Multi-statement writes that require atomicity go through `db.batch([...])`; the facade never fakes atomicity by chaining sequential independent calls under an application-side try-catch.",
+  "context": "A persistence boundary that leaks (the domain code reads the D1 binding from `env` directly, or the facade exposes a general-purpose raw-SQL passthrough) is a boundary the swap-out story does not work through, the test-double story does not work through, the reasoning-about-persistence-code-paths story does not work through, and (worse for D1 than for a local-file engine) the SQL-injection story does not work through: any consumer-supplied SQL fragment that reaches the vendor surface bypasses the prepared-statement discipline owned on TAC-1401-persistence-data-d1-facade.responsibilities[2], and the discipline is only load-bearing when it holds at every call site the facade exposes.",
+  "decision": "One module (the D1 store facade, TAC-1401-persistence-data-d1-facade) reads the D1 binding from the Worker `env`. Every other module in the source tree that touches persistence imports the facade and calls its named verbs. The facade's public surface exposes named domain verbs with typed parameters; it does not export the D1 binding, and it does not expose a general-purpose query method whose parameter is a SQL string or a prepared-statement object supplied by a consumer. Every statement the facade issues follows the prepared-statement chain owned on TAC-1401-persistence-data-d1-facade.responsibilities[2]; the raw `exec` surface is never invoked with a non-literal string, and SQL is never constructed by string concatenation with consumer arguments. Multi-statement writes that require atomicity go through the batch call owned on TAC-1401-persistence-data-d1-facade.responsibilities[3]; the facade never fakes atomicity by chaining sequential independent calls under an application-side try-catch. Allowed query surface (ratified): only the prepared-statement chain above; no `exec` on consumer-supplied strings; the raw `exec` surface is permitted ONLY inside the migration runner (out of consumer-code reach) for the vendor-required schema-DDL pass, never on the facade's public verbs. Consumer code that calls the raw `exec` surface on the facade's exposed handle is refused by the source-scan probe.",
   "consequences": "The engine choice is swappable because there is exactly one place that reads the binding. Domain tests run against an in-memory double that implements the same verb surface, without any reference to D1 at any point in the test's call path. Every persistence code path is discoverable by grepping for the facade's exports. Consumer arguments never traverse the SQL parser; the vendor's parameter-binding layer is the only place values reach the engine, and SQL injection is closed by construction rather than by discipline-at-call-site. Consumers pay a small cost when they need a new query shape (a facade edit and a consumer edit, in one commit); the size of that cost is the mechanism enforcing the boundary. Composing blueprints that contribute persistence-adjacent components (a cache, an outbox, a projection) contribute their own facade modules on the same discipline; every one of them imports the D1 store facade for its persistence needs, not the D1 binding.",
   "alternativesConsidered": [
     {
@@ -21,5 +21,5 @@
     }
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-001.json

@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-1401-persistence-data-d1-facade",
+    "field": "responsibilities.facade"
+  }
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-002.json

@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-1402-persistence-data-d1-migration-catalog",
+    "field": "responsibilities.migrations"
+  }
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-003.json

@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-1403-persistence-data-d1-deploy-gate",
+    "field": "responsibilities.gate"
+  }
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-004.json

@@ -2,7 +2,7 @@
   "reqId": "persistence-data-d1-REQ-004",
   "prdId": "PRD-001",
   "title": "Every statement the facade issues against D1 is a parameterised prepared statement; no consumer-supplied SQL reaches the binding",
-  "description": "The facade module issues every read or write against D1 through the prepared-statement surface: `db.prepare(<static SQL literal>).bind(<parameters>).first()`, `.all()`, or `.run()`. The static SQL literal is authored inside the facade module and does not embed values from consumer arguments through string concatenation, template interpolation, or any other join that produces a call-site-specific SQL fragment. The facade does not export a general-purpose query method whose parameter is a SQL string supplied by a consumer, and it does not use `db.exec(<consumer string>)` on any path.",
+  "description": "The facade module routes every read and write against D1 through the prepared-statement discipline owned on TAC-1401-persistence-data-d1-facade.responsibilities[2]. Static SQL literals are authored inside the facade module and never embed values from consumer arguments through string concatenation, template interpolation, or any other join that produces a call-site-specific SQL fragment. The facade exports no general-purpose query method whose parameter is a SQL string supplied by a consumer, and it reaches no non-literal statement through the vendor raw execute path on any code path. The allowed query surface is ratified on ADR-1404.",
   "category": "security",
   "domain": "persistence",
   "priority": "must",
@@ -11,8 +11,12 @@
     "blueprint:persistence-data-d1",
     "category:04-prepared-statements"
   ],
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-1401-persistence-data-d1-facade",
+    "field": "responsibilities.prepare"
+  }
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-005.json

@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-1401-persistence-data-d1-facade",
+    "field": "responsibilities.batchAtomicity"
+  }
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-006.json

@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-1404-persistence-data-d1-recovery-runner",
+    "field": "responsibilities.timeTravel"
+  }
 }

package/blueprints/persistence-data-d1/contributions/requirements/persistence-data-d1-req-007.json

@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "adrId": "ADR-1403-persistence-data-d1-event-secrecy",
+    "field": "decision.metadataOnly"
+  }
 }

package/blueprints/persistence-data-d1/contributions/user-stories/persistence-data-d1-us-13101.json

@@ -16,7 +16,8 @@
       "when": "the import graph and source tree are inspected for the D1 binding reference (`env.<BINDING_NAME>` where BINDING_NAME is the value configured on `d1_databases[].binding` in the project's wrangler config)",
       "then": "the reference appears in exactly one file (the facade module) and no other file in the source tree contains the reference, verified by an import-graph query or a targeted grep against the configured binding name",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-13101-2",
@@ -25,7 +26,8 @@
       "when": "the surface is inspected",
       "then": "every exported symbol is either a named domain verb with typed parameters or an event-sink registration; no exported symbol is the D1 binding itself, and no exported function accepts a raw SQL string as a call argument from consumer code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-13101-3",
@@ -34,12 +36,41 @@
       "when": "the domain code runs against the double in place of the facade",
       "then": "the domain code executes to completion with no reference to the D1 binding on its call path, and its behaviour is unchanged from a facade-backed run for the operations under test",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-13101-4",
+      "description": "Dependency not ready: D1 binding absent from the Worker env. Given a Worker whose wrangler manifest omits the configured d1_databases binding name (or whose deployed environment has not provisioned the binding), when the facade opens on isolate boot and reads env[<bindingName>], then the read returns undefined, the facade refuses with a named error kind d1BindingMissing carrying the expected binding name (never carrying the account id or API token), and no facadeReady fires on the sink.",
+      "given": "the Worker env has no property under the configured D1 binding name",
+      "when": "the facade opens on isolate boot",
+      "then": "the facade refuses with d1BindingMissing naming the expected binding; no credentials leak; no facadeReady fires",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-1401-persistence-data-d1-facade",
+        "field": "responsibilities.readBinding"
+      },
+      "disposition": "template"
+    },
+    {
+      "id": "AC-13101-5",
+      "description": "Rate limit from D1: the vendor 429 surfaces as queryFailed with retryAfterMs. Given the D1 vendor returns a 429 rate-limit response on a prepare-and-bind or batch call (simulated in the fixture via SIMULATE_D1_RATE_LIMIT=true), when the facade issues the query, then the facade catches the vendor error, surfaces a queryFailed event on the sink carrying { errorKind: 'rateLimited', retryAfterMs: <parsed from vendor headers or a default>, verb: <domain verb name> } and re-throws a d1RateLimited error the consumer catches; a probe FAILS if the event's errorKind is anything other than rateLimited.",
+      "given": "the D1 vendor returns 429 on a facade query (SIMULATE_D1_RATE_LIMIT=true)",
+      "when": "the facade issues the query",
+      "then": "queryFailed fires with { errorKind: 'rateLimited', retryAfterMs, verb }; the facade re-throws d1RateLimited; the probe FAILS on any other errorKind",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-1401-persistence-data-d1-facade",
+        "field": "responsibilities.queryFailedRateLimit"
+      },
+      "disposition": "template"
     }
   ],
   "tacIds": [
     "TAC-1401-persistence-data-d1-facade"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/persistence-data-d1/contributions/user-stories/persistence-data-d1-us-13102.json

@@ -16,7 +16,8 @@
       "when": "the migrations directory is listed and each filename's leading integer is extracted",
       "then": "the sequence of leading integers is strictly increasing with no duplicates, every file has a non-empty SQL body, and no file in the directory falls outside the wrangler-configured pattern",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-13102-2",
@@ -25,7 +26,8 @@
       "when": "the `list` then `apply` then `list` sequence runs against the local database",
       "then": "the first `list` prints every migration file as unapplied, the `apply` exits zero, and the second `list` prints zero unapplied migrations",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-13102-3",
@@ -34,12 +36,31 @@
       "when": "the bookkeeping table is read via `wrangler d1 execute <database> --local --command \"SELECT * FROM d1_migrations\"` (or the configured `migrations_table` name)",
       "then": "the returned row count equals the number of migration files in the directory, and the recorded identifiers match the migration filenames or their leading integers",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-13102-4",
+      "description": "Quota exhausted on D1 database write. Given the D1 database is at or above the plan's per-database size ceiling (10 GB on Paid, 500 MB on Free per the vendor page) and a migration would add rows exceeding the remaining headroom, when the deploy-gate's wrangler d1 migrations apply invocation runs, then the vendor returns a quota-exhausted error, the deploy-gate exits non-zero, no migrationsApplied fires, and the wrangler deploy step is not reached (deploy is gated per REQ-003).",
+      "given": "the D1 database is at or above the plan's size ceiling and a migration would exceed the headroom",
+      "when": "the deploy-gate runs wrangler d1 migrations apply",
+      "then": "the vendor returns quota exhausted; the deploy-gate exits non-zero; no migrationsApplied fires; wrangler deploy is not reached",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-1403-persistence-data-d1-deploy-gate",
+        "field": "responsibilities.gate"
+      },
+      "disposition": "template",
+      "vendorCitation": {
+        "url": "https://developers.cloudflare.com/d1/platform/limits/",
+        "verifiedOn": "2026-09-09"
+      }
     }
   ],
   "tacIds": [
     "TAC-1402-persistence-data-d1-migration-catalog"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }