rcf-lite 0.26.0 → 0.28.0

package/blueprints/messaging-queue-cloudflare/README.md

@@ -1,6 +1,6 @@
 # messaging-queue-cloudflare
 
-A directed producer-to-consumer worklist queue on Cloudflare Queues, accessed through a producer facade that is the sole reader of the Queues binding. Cloudflare Queues is the first adapter (queue binding under wrangler config, consumer registered on the Worker `queue` handler); the reserved `messaging-queue-postgres` sibling (Baz decision 7) mints on demand. Ships publish, consume, ack, retry, and DLQ; four lifecycle events (`producerReady`, `messagePublished`, `messageAcked`, `messageDeadLettered`) with a metadata-only field discipline. Composes on `deploy-cloudflare-workers` transitively via the wrangler binding, not through the capability mechanism, so `capabilities: ["queue"]` is what `jobs-background` reads to obtain the producer facade at apply time; no `requiresAppliedCapabilities` block ships at v1.0.0.
+A directed producer-to-consumer worklist queue on Cloudflare Queues, accessed through a producer facade that is the sole reader of the Queues binding. Cloudflare Queues is the first adapter (queue binding under wrangler config, consumer registered on the Worker `queue` handler); the reserved `messaging-queue-postgres` sibling (sibling reservation) mints on demand. Ships publish, consume, ack, retry, and DLQ; four lifecycle events (`producerReady`, `messagePublished`, `messageAcked`, `messageDeadLettered`) with a metadata-only field discipline. Composes on `deploy-cloudflare-workers` transitively via the wrangler binding, not through the capability mechanism, so `capabilities: ["queue"]` is what `jobs-background` reads to obtain the producer facade at apply time; no `requiresAppliedCapabilities` block ships at v1.0.0.
 
 ## What this blueprint gives you
 
@@ -44,15 +44,15 @@ Queue name (or binding name in a Workers deploy); `max_retries` before DLQ (defa
 
 ## Composition and conflicts
 
-Composes on `deploy-cloudflare-workers` transitively via the wrangler binding (not through the capability mechanism), so no `requiresAppliedCapabilities` block ships at v1.0.0. Contributes ADR-3002 as `scope: global` on new topic `deliverySemantics`; a future `messaging-queue-postgres` sibling (Baz decision 7, deferred v1.0.0 pending demand) or an exactly-once / at-most-once sibling would conflict here by design. `capabilities: ["queue"]`; `providesRoles: []`.
+Composes on `deploy-cloudflare-workers` transitively via the wrangler binding (not through the capability mechanism), so no `requiresAppliedCapabilities` block ships at v1.0.0. Contributes ADR-3002 as `scope: global` on new topic `deliverySemantics`; a future `messaging-queue-postgres` sibling (sibling reservation, deferred v1.0.0 pending demand) or an exactly-once / at-most-once sibling would conflict here by design. `capabilities: ["queue"]`; `providesRoles: []`.
 
 ## Reserved sibling
 
-`messaging-queue-postgres` (Baz decision 7). Reserved slug beside the `queue` capability row in `packages/rcf-lite/docs/blueprint-authoring.md` section 6a. When demand mints it, the sibling composes on `persistence-data-postgres` as its transport and conflicts by design on `deliverySemantics` with this blueprint; the operator picks one queue backend per project via a project-level ADR.
+`messaging-queue-postgres` (sibling reservation). Reserved slug beside the `queue` capability row in `packages/rcf-lite/docs/blueprint-authoring.md` section 6a. When demand mints it, the sibling composes on `persistence-data-postgres` as its transport and conflicts by design on `deliverySemantics` with this blueprint; the operator picks one queue backend per project via a project-level ADR.
 
 ## The six probes
 
-Each probe is a Node module under `contributions/probes/` exporting the round-5 spec section 3.2 verdict envelope, with a matching `run-<probe-name>.mjs` shim that drives the probe against the shared fixture's T-3 slice and writes the per-blueprint report at `.rcf/reports/blueprints/messaging-queue-cloudflare/<probe-name>.json`.
+Each probe is a Node module under `contributions/probes/` exporting the shipped verdict envelope, with a matching `run-<probe-name>.mjs` shim that drives the probe against the shared fixture's slice and writes the per-blueprint report at `.rcf/reports/blueprints/messaging-queue-cloudflare/<probe-name>.json`.
 
 | Probe | Anchor AC | What it proves | accountBound |
 |---|---|---|---|
@@ -60,7 +60,7 @@ Each probe is a Node module under `contributions/probes/` exporting the round-5
 | `publish-to-delivery` | AC-29102-1, AC-29102-2, AC-29105-1, AC-29108-1 | 5 messages round-trip body byte-equal with stable message-ids and producer-supplied trace-ids preserved; per-message ack; wrangler-dev-equivalent seam. | false |
 | `retry-and-dlq` | AC-29103-1, AC-29104-1 | Consumer returning `retry` observes same stable message-id with attempts 1..max_retries; DLQ landing fires `messageDeadLettered` at `max_retries + 1`; DLQ contents body byte-equal via the DLQ inspector helper. | false |
 | `event-secrecy` | AC-29106-1 | Every event record carries only the whitelist (event, ts, messageId, queueName, attempts); no PII fixture text on JSON grep. | false |
-| `real-account-concurrency-smoke` | AC-29108-2 | Self-provisioning (v1.0.2): the fixture shim (`packages/rcf-lite/test/fixtures/cf-platform/h2-cf-queue-real-account-shim.mjs`) mints a scratch Cloudflare Queue under the H-2 prefix `h2-cf-probe-integrity-scratch-q-`, a scratch KV namespace for consumer telemetry under `h2-cf-probe-integrity-scratch-kv-tel-`, and a throwaway consumer Worker under `h2-cf-probe-integrity-scratch-w-` bound to the queue (consumer) with `RCF_TEST_QUEUE` (shipped queue binding name) + `RCF_TEST_TELEMETRY_KV` bindings. The Worker has NO fetch surface and NO workers.dev subdomain is enabled (Dave ruling 376b4f30): the consumer is invoked BY THE QUEUE, not over HTTP. Driver publishes 500 messages in 10 concurrent 50-message batches via the Cloudflare Queues REST publish endpoint, polls the telemetry KV namespace via the KV REST list + get endpoints until drained, and asserts `totalConsumed === published` and `1 < maxConcurrent <= 250` per https://developers.cloudflare.com/queues/platform/limits/. Teardown deletes Worker, Queue and telemetry KV namespace on exit; the shim's separate `sweepOrphans` path lists over the account with full pagination (Dave ruling 4e9ff62d item 5) and deletes any prefixed residue after a mid-run crash. **The local proof exercises OUR lifecycle logic against a mock of Cloudflare's contract; the real-account gate is the only surface that proves the wire format.** Without `CI_HAS_CLOUDFLARE_ACCOUNT` records `accountBoundSkipped: true`. | true |
+| `real-account-concurrency-smoke` | AC-29108-2 | Self-provisioning (v1.0.2): the fixture shim (`packages/rcf-lite/test/fixtures/cf-platform/h2-cf-queue-real-account-shim.mjs`) mints a scratch Cloudflare Queue under the CI scratch prefix `h2-cf-probe-integrity-scratch-q-`, a scratch KV namespace for consumer telemetry under `h2-cf-probe-integrity-scratch-kv-tel-`, and a throwaway consumer Worker under `h2-cf-probe-integrity-scratch-w-` bound to the queue (consumer) with `RCF_TEST_QUEUE` (shipped queue binding name) + `RCF_TEST_TELEMETRY_KV` bindings. The Worker has no fetch surface and no workers.dev subdomain is enabled: the consumer is invoked BY THE QUEUE, not over HTTP. Driver publishes 500 messages in 10 concurrent 50-message batches via the Cloudflare Queues REST publish endpoint, polls the telemetry KV namespace via the KV REST list + get endpoints until drained, and asserts `totalConsumed === published` and `1 < maxConcurrent <= 250` per https://developers.cloudflare.com/queues/platform/limits/. Teardown deletes Worker, Queue and telemetry KV namespace on exit; the shim's separate `sweepOrphans` path lists over the account with full pagination and deletes any prefixed residue after a mid-run crash. Without `CI_HAS_CLOUDFLARE_ACCOUNT` records `accountBoundSkipped: true`. | true |
 
 ## Anatomy
 
@@ -98,20 +98,20 @@ blueprints/messaging-queue-cloudflare/
 
 ## Known limitations and mechanism-reach gaps
 
-The five local probes drive the fixture's in-memory queue-driver (`src/queue-driver.mjs`), which realises the Cloudflare Queues binding shape (`send` / `sendBatch` on the producer side, batch envelope with per-message `ack` / `retry` on the consumer side) so the producer facade module and consumer registration are indistinguishable from a live Queues run at the facade boundary. The wrangler-dev-equivalent seam (SDR-3-a on US-29107) is a deliberate v1.0.0 posture: rcf-lite gains no runtime dependency, CI stays reproducible without a live Cloudflare account, and Cloudflare Queues does not support consumer concurrency under `wrangler dev` per https://developers.cloudflare.com/queues/configuration/local-development/ (that assertion is what `real-account-concurrency-smoke` carries as `accountBound: true`).
+The five local probes drive the fixture's in-memory queue-driver (`src/queue-driver.mjs`), which realises the Cloudflare Queues binding shape (`send` / `sendBatch` on the producer side, batch envelope with per-message `ack` / `retry` on the consumer side) so the producer facade module and consumer registration are indistinguishable from a live Queues run at the facade boundary. The wrangler-dev-equivalent seam (the wrangler-dev-equivalent seam decision on US-29107) is a deliberate v1.0.0 posture: rcf-lite gains no runtime dependency, CI stays reproducible without a live Cloudflare account, and Cloudflare Queues does not support consumer concurrency under `wrangler dev` per https://developers.cloudflare.com/queues/configuration/local-development/ (that assertion is what `real-account-concurrency-smoke` carries as `accountBound: true`).
 
 Two live paths are unproven at v1.0.0 and are recorded per AC below so the gate reviewer and any downstream composing blueprint see exactly what is and is not proven for each AC. The gate reviewer's own single `wrangler dev` run and the `accountBound` smoke are what promote these gaps to proven.
 
-- **AC-29101-1** (producer facade opens on boot; `producerReady` fires with `queueName`): proven against the in-memory realisation of the Cloudflare Queues binding shape (probe `producer-facade-ready`, verdict pass); live Queues delivery unproven pending a reviewer `wrangler dev` run or the accountBound smoke.
+- **AC-29101-1** (producer facade opens on boot; `producerReady` fires with `queueName`): proven against the in-memory realisation of the Cloudflare Queues binding shape (probe `producer-facade-ready`, verdict pass); live Queues delivery unproven pending an operator `wrangler dev` run or the accountBound smoke.
 - **AC-29101-2** (sole-reader grep on the applied fixture): proven against the in-memory realisation (source-tree scan of `src/producer.mjs` against `src/consumer.mjs` peers); live-Queues source-tree posture is identical (the grep target is the fixture tree, not the vendor surface), so this AC has no live-only gap.
-- **AC-29102-1** (5 messages round-trip body byte-equal with stable message-id and producer-supplied trace-id): proven against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); live Queues delivery of the same 5-message batch unproven pending a reviewer `wrangler dev` run or the accountBound smoke.
-- **AC-29102-2** (`messageAcked` fires per successful consumer return; message not redelivered): proven against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); live Queues per-message ack behaviour unproven pending a reviewer `wrangler dev` run or the accountBound smoke.
-- **AC-29103-1** (retry trajectory: same stable message-id across attempts 1..max_retries with incrementing attempt counter): proven against the in-memory realisation of the binding shape (probe `retry-and-dlq`, verdict pass with attempts 1,2,3 on the same message-id); live Queues retry counter observation unproven pending a reviewer `wrangler dev` run or the accountBound smoke.
-- **AC-29104-1** (DLQ landing at `max_retries + 1` with `messageDeadLettered` event and body byte-equal on DLQ inspection): proven against the in-memory realisation of the binding shape (probe `retry-and-dlq`, verdict pass with DLQ landing at attempts=4 and byte-equal body); live Queues DLQ landing via wrangler `dead_letter_queue` field and inspection via `wrangler queues consumer add --dead-letter-queue` unproven pending a reviewer `wrangler dev` run or the accountBound smoke.
-- **AC-29105-1** (batch consume: 5 messages in one batch, per-message ack semantics under `max_batch_size = 10`): proven against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); live Queues `max_batch_size` / `max_batch_timeout` behaviour on the [[queues.consumers]] block unproven pending a reviewer `wrangler dev` run or the accountBound smoke.
+- **AC-29102-1** (5 messages round-trip body byte-equal with stable message-id and producer-supplied trace-id): proven against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); live Queues delivery of the same 5-message batch unproven pending an operator `wrangler dev` run or the accountBound smoke.
+- **AC-29102-2** (`messageAcked` fires per successful consumer return; message not redelivered): proven against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); live Queues per-message ack behaviour unproven pending an operator `wrangler dev` run or the accountBound smoke.
+- **AC-29103-1** (retry trajectory: same stable message-id across attempts 1..max_retries with incrementing attempt counter): proven against the in-memory realisation of the binding shape (probe `retry-and-dlq`, verdict pass with attempts 1,2,3 on the same message-id); live Queues retry counter observation unproven pending an operator `wrangler dev` run or the accountBound smoke.
+- **AC-29104-1** (DLQ landing at `max_retries + 1` with `messageDeadLettered` event and body byte-equal on DLQ inspection): proven against the in-memory realisation of the binding shape (probe `retry-and-dlq`, verdict pass with DLQ landing at attempts=4 and byte-equal body); live Queues DLQ landing via wrangler `dead_letter_queue` field and inspection via `wrangler queues consumer add --dead-letter-queue` unproven pending an operator `wrangler dev` run or the accountBound smoke.
+- **AC-29105-1** (batch consume: 5 messages in one batch, per-message ack semantics under `max_batch_size = 10`): proven against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); live Queues `max_batch_size` / `max_batch_timeout` behaviour on the [[queues.consumers]] block unproven pending an operator `wrangler dev` run or the accountBound smoke.
 - **AC-29106-1** (metadata-only event whitelist; no PII body / header value / consumer context leaks): proven end-to-end against the in-memory realisation (probe `event-secrecy`, verdict pass; the whitelist is code-enforced in `src/event-sink.mjs`, independent of transport); live-Queues run does not change the sink code path, so this AC has no live-only gap.
-- **AC-29108-1** (wrangler-dev-equivalent seam round-trip): proven end-to-end against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); a live `wrangler dev` process was not driven in this pass. Rationale: SDR-3-a on US-29107 makes the wrangler-dev-equivalent seam the shipped local seam because Cloudflare Queues does not support consumer concurrency under `wrangler dev` and does not support `wrangler dev --remote` per the local-development doc, so a live-wrangler run adds observability (a real process on port 8787) but does not add facade-contract certainty over the in-memory realisation. The gate reviewer drives one live `wrangler dev` run in their own scratch to close the observability gap.
-- **AC-29108-2** (real-account concurrency smoke: 500 messages, consumer concurrency up to 250): as of v1.0.2 the probe SELF-PROVISIONS the throwaway Queue + consumer Worker + telemetry KV namespace under the H-2 prefixes and requires no hand-provisioned CI infrastructure (`w-2026-09-08-dave-017`). Declared env for a live run: `CI_HAS_CLOUDFLARE_ACCOUNT` + `CF_ACCOUNT_ID` + `CF_API_TOKEN`. Without `CI_HAS_CLOUDFLARE_ACCOUNT` the probe records `accountBoundSkipped: true` per spec section 3.5 and the per-blueprint report carries `aggregateVerdict: pass` on the skipped shape. **The local proof harness under `packages/rcf-lite/test/fixtures/cf-platform/test/` is a mock of Cloudflare's REST contract, not the wire; the local runs exercise OUR lifecycle logic against that mock, and the real-account gate is the only surface that proves the wire format.**
+- **AC-29108-1** (wrangler-dev-equivalent seam round-trip): proven end-to-end against the in-memory realisation of the binding shape (probe `publish-to-delivery`, verdict pass); a live `wrangler dev` process is not driven by this seam. Rationale: the wrangler-dev-equivalent seam decision on US-29107 makes the wrangler-dev-equivalent seam the shipped local seam because Cloudflare Queues does not support consumer concurrency under `wrangler dev` and does not support `wrangler dev --remote` per the local-development doc, so a live-wrangler run adds observability (a real process on port 8787) but does not add facade-contract certainty over the in-memory realisation. The gate reviewer drives one live `wrangler dev` run to close the observability gap.
+- **AC-29108-2** (real-account concurrency smoke: 500 messages, consumer concurrency up to 250): as of v1.0.2 the probe SELF-PROVISIONS the throwaway Queue + consumer Worker + telemetry KV namespace under the CI scratch prefixes and requires no hand-provisioned CI infrastructure . Declared env for a live run: `CI_HAS_CLOUDFLARE_ACCOUNT` + `CF_ACCOUNT_ID` + `CF_API_TOKEN`. Without `CI_HAS_CLOUDFLARE_ACCOUNT` the probe records `accountBoundSkipped: true` per spec section 3.5 and the per-blueprint report carries `aggregateVerdict: pass` on the skipped shape. **The local proof harness under `packages/rcf-lite/test/fixtures/cf-platform/test/` is a mock of Cloudflare's REST contract, not the wire; the local runs exercise OUR lifecycle logic against that mock, and the real-account gate is the only surface that proves the wire format.**
 
 ## Other limitations (not mechanism-reach gaps)
 

package/blueprints/messaging-queue-cloudflare/blueprint.json

@@ -1,8 +1,10 @@
 {
   "slug": "messaging-queue-cloudflare",
-  "version": "1.0.2",
+  "version": "1.1.3",
   "category": "messaging",
-  "capabilities": ["queue"],
+  "capabilities": [
+    "queue"
+  ],
   "suggestedCompanions": [
     {
       "role": "logging",
@@ -14,23 +16,91 @@
     }
   ],
   "contributions": [
-    { "id": "messaging-queue-cloudflare-REQ-001", "kind": "req", "path": "requirements/messaging-queue-cloudflare-req-001.json" },
-    { "id": "messaging-queue-cloudflare-REQ-002", "kind": "req", "path": "requirements/messaging-queue-cloudflare-req-002.json" },
-    { "id": "messaging-queue-cloudflare-REQ-003", "kind": "req", "path": "requirements/messaging-queue-cloudflare-req-003.json" },
-    { "id": "messaging-queue-cloudflare-REQ-004", "kind": "req", "path": "requirements/messaging-queue-cloudflare-req-004.json" },
-    { "id": "messaging-queue-cloudflare-REQ-005", "kind": "req", "path": "requirements/messaging-queue-cloudflare-req-005.json" },
-    { "id": "messaging-queue-cloudflare-REQ-006", "kind": "req", "path": "requirements/messaging-queue-cloudflare-req-006.json" },
-    { "id": "messaging-queue-cloudflare-US-29101", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29101.json" },
-    { "id": "messaging-queue-cloudflare-US-29102", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29102.json" },
-    { "id": "messaging-queue-cloudflare-US-29103", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29103.json" },
-    { "id": "messaging-queue-cloudflare-US-29104", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29104.json" },
-    { "id": "messaging-queue-cloudflare-US-29105", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29105.json" },
-    { "id": "messaging-queue-cloudflare-US-29106", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29106.json" },
-    { "id": "messaging-queue-cloudflare-US-29107", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29107.json" },
-    { "id": "messaging-queue-cloudflare-US-29108", "kind": "us", "path": "user-stories/messaging-queue-cloudflare-us-29108.json" },
-    { "id": "TAC-3001-messaging-queue-cloudflare-producer-facade", "kind": "tac", "path": "tacs/tac-3001-messaging-queue-cloudflare-producer-facade.json" },
-    { "id": "TAC-3002-messaging-queue-cloudflare-consumer-registration", "kind": "tac", "path": "tacs/tac-3002-messaging-queue-cloudflare-consumer-registration.json" },
-    { "id": "TAC-3003-messaging-queue-cloudflare-event-sink", "kind": "tac", "path": "tacs/tac-3003-messaging-queue-cloudflare-event-sink.json" },
+    {
+      "id": "messaging-queue-cloudflare-REQ-001",
+      "kind": "req",
+      "path": "requirements/messaging-queue-cloudflare-req-001.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-REQ-002",
+      "kind": "req",
+      "path": "requirements/messaging-queue-cloudflare-req-002.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-REQ-003",
+      "kind": "req",
+      "path": "requirements/messaging-queue-cloudflare-req-003.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-REQ-004",
+      "kind": "req",
+      "path": "requirements/messaging-queue-cloudflare-req-004.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-REQ-005",
+      "kind": "req",
+      "path": "requirements/messaging-queue-cloudflare-req-005.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-REQ-006",
+      "kind": "req",
+      "path": "requirements/messaging-queue-cloudflare-req-006.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29101",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29101.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29102",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29102.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29103",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29103.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29104",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29104.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29105",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29105.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29106",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29106.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29107",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29107.json"
+    },
+    {
+      "id": "messaging-queue-cloudflare-US-29108",
+      "kind": "us",
+      "path": "user-stories/messaging-queue-cloudflare-us-29108.json"
+    },
+    {
+      "id": "TAC-3001-messaging-queue-cloudflare-producer-facade",
+      "kind": "tac",
+      "path": "tacs/tac-3001-messaging-queue-cloudflare-producer-facade.json"
+    },
+    {
+      "id": "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+      "kind": "tac",
+      "path": "tacs/tac-3002-messaging-queue-cloudflare-consumer-registration.json"
+    },
+    {
+      "id": "TAC-3003-messaging-queue-cloudflare-event-sink",
+      "kind": "tac",
+      "path": "tacs/tac-3003-messaging-queue-cloudflare-event-sink.json"
+    },
     {
       "id": "ADR-3001-messaging-queue-cloudflare-adapter",
       "kind": "adr",
@@ -63,5 +133,43 @@
       "elicited": true,
       "standardsTraceClause": "Cloudflare Queues per-consumer batch settings"
     }
+  ],
+  "elicits": [
+    {
+      "id": "queue-binding-name",
+      "prompt": "The Queues binding name declared under wrangler.toml [[queues.producers]] and [[queues.consumers]]. The producer facade reads env under this name at boot.",
+      "kind": "string",
+      "default": "RCF_TEST_QUEUE"
+    },
+    {
+      "id": "queue-name",
+      "prompt": "The Cloudflare Queues queue name the binding resolves to. The applied project asserts a real account queue at apply.",
+      "kind": "string",
+      "default": "app-queue"
+    },
+    {
+      "id": "max-attempts",
+      "prompt": "Max delivery attempts per ADR-3003 before a message crosses into the DLQ. Default 3 per the Cloudflare Queues documented default; floor 1; ceiling 100 per the Queues platform-limits page.",
+      "kind": "string",
+      "default": "3"
+    },
+    {
+      "id": "dead-letter-queue",
+      "prompt": "Dead-letter queue name attached under [[queues.consumers]].dead_letter_queue for the consumer. A dead-lettered message is stamped messageDeadLettered on the lifecycle sink; retention is 4 days per ADR-3003.",
+      "kind": "string",
+      "default": "app-queue-dlq"
+    },
+    {
+      "id": "batch-size",
+      "prompt": "max_batch_size for the consumer. Default 10 per ADR-3004; bounded above by 100 per the Cloudflare Queues platform-limits page.",
+      "kind": "string",
+      "default": "10"
+    },
+    {
+      "id": "batch-timeout-seconds",
+      "prompt": "max_batch_timeout seconds for the consumer. Default 5 per ADR-3004; bounded above by 60 per the Cloudflare Queues platform-limits page.",
+      "kind": "string",
+      "default": "5"
+    }
   ]
 }

package/blueprints/messaging-queue-cloudflare/contributions/adrs/adr-3001-messaging-queue-cloudflare-adapter.json

@@ -5,9 +5,9 @@
   "version": "1.0.0",
   "status": "accepted",
   "title": "Adapter: Cloudflare Queues as the shipped v1.0.0 first adapter",
-  "context": "A project deploying a directed producer-to-consumer worklist queue on Cloudflare Workers has one native shipped answer today: Cloudflare Queues. The Queues surface is bound through wrangler configuration (a [[queues.producers]] block for the producer facade to publish through, a [[queues.consumers]] block for the Worker queue handler to consume from), and the shipped Worker runtime binds env.<binding> to a Queues object with send / sendBatch on the producer side and a batch envelope with ack / retry on the consumer side per https://developers.cloudflare.com/queues/configuration/javascript-apis/. The v1.0.0 facade must hold the adapter reference opaque at the facade boundary so a future non-Cloudflare adapter (an SQS shim, the reserved messaging-queue-postgres sibling per Baz decision 7) slots in without a facade re-shape, and so a fixture-time in-memory adapter is testable without live Cloudflare Queues access.",
+  "context": "A project deploying a directed producer-to-consumer worklist queue on Cloudflare Workers has one native shipped answer today: Cloudflare Queues. The Queues surface is bound through wrangler configuration (a [[queues.producers]] block for the producer facade to publish through, a [[queues.consumers]] block for the Worker queue handler to consume from), and the shipped Worker runtime binds env.<binding> to a Queues object with send / sendBatch on the producer side and a batch envelope with ack / retry on the consumer side per https://developers.cloudflare.com/queues/configuration/javascript-apis/. The v1.0.0 facade must hold the adapter reference opaque at the facade boundary so a future non-Cloudflare adapter (an SQS shim, the reserved messaging-queue-postgres sibling per policy) slots in without a facade re-shape, and so a fixture-time in-memory adapter is testable without live Cloudflare Queues access.",
   "decision": "The shipped v1.0.0 default is Cloudflare Queues, wired through wrangler config (producer binding on [[queues.producers]], consumer on [[queues.consumers]] with dead_letter_queue and max_retries per https://developers.cloudflare.com/queues/configuration/dead-letter-queues/). The producer facade module is the sole holder of the Queues binding reference per REQ-001; the consumer registration module is the sole reader of the batch envelope per REQ-002. The adapter reference is OPAQUE at this ADR: the facade dereferences the elicited binding at the top of the module and any consumer wanting a different adapter (an SQS shim, the messaging-queue-postgres sibling minted on demand) replaces the binding reference here without touching the outward interface. A fixture-time in-memory adapter (used by the local probes) implements the same binding shape (send / sendBatch on the producer side, batch with ack / retry on the consumer side) so the facade and consumer surfaces are indistinguishable from the real Queues binding at the facade boundary. The 128 KB per-message cap and 100 messages per batch cap Cloudflare documents at https://developers.cloudflare.com/queues/platform/limits/ apply to every real-Queues run.",
-  "consequences": "The project inherits the Cloudflare Queues wire-format, the platform-assigned stable message-id, and the batch envelope's per-message ack semantics. Standards trace clause: Cloudflare Queues documented per-message and per-batch limits (per https://developers.cloudflare.com/queues/platform/limits/), Cloudflare Queues Worker queue-handler contract (per https://developers.cloudflare.com/queues/configuration/javascript-apis/), and Cloudflare Queues dead-letter documentation (per https://developers.cloudflare.com/queues/configuration/dead-letter-queues/). A future non-Cloudflare adapter mints under a sibling blueprint (reserved slug messaging-queue-postgres, Baz decision 7) and conflicts by design on deliverySemantics (ADR-3002) with this blueprint; the operator picks one queue backend per project via a project-level ADR.",
+  "consequences": "The project inherits the Cloudflare Queues wire-format, the platform-assigned stable message-id, and the batch envelope's per-message ack semantics. Standards trace clause: Cloudflare Queues documented per-message and per-batch limits (per https://developers.cloudflare.com/queues/platform/limits/), Cloudflare Queues Worker queue-handler contract (per https://developers.cloudflare.com/queues/configuration/javascript-apis/), and Cloudflare Queues dead-letter documentation (per https://developers.cloudflare.com/queues/configuration/dead-letter-queues/). A future non-Cloudflare adapter mints under a sibling blueprint (reserved slug messaging-queue-postgres, maintainer decision) and conflicts by design on deliverySemantics (ADR-3002) with this blueprint; the operator picks one queue backend per project via a project-level ADR.",
   "alternativesConsidered": [
     {
       "name": "External SQS or SNS as the shipped v1.0.0 default",
@@ -17,7 +17,7 @@
     {
       "name": "Kafka or NATS as the shipped v1.0.0 default",
       "summary": "Ship a self-hosted Kafka or NATS backend as the primary v1.0.0 queue.",
-      "reasonNotChosen": "A self-hosted Kafka or NATS backend adds a persistent operational surface every applying project has to run; the round-5 spec section 5.3 targets a directed producer-to-consumer worklist as a shipped shape whose applying project need not host a broker. The reserved messaging-queue-postgres sibling (Baz decision 7) covers the self-hosted-transport family separately when demand mints it."
+      "reasonNotChosen": "A self-hosted Kafka or NATS backend adds a persistent operational surface every applying project has to run; a directed producer-to-consumer worklist is a shipped shape whose applying project need not host a broker. The reserved messaging-queue-postgres sibling (sibling reservation) covers the self-hosted-transport family separately when demand mints it."
     },
     {
       "name": "Ship a hand-rolled fetch client against the Queues REST API",

package/blueprints/messaging-queue-cloudflare/contributions/adrs/adr-3002-messaging-queue-cloudflare-delivery-semantics.json

@@ -7,7 +7,7 @@
   "title": "Delivery semantics: at-least-once as the shipped shape (scope global, new topic deliverySemantics)",
   "context": "A directed producer-to-consumer worklist ships one of three delivery shapes at the transport contract: at-most-once (fire and forget, dedup at the producer), at-least-once (guaranteed delivery with duplicates possible, dedup at the consumer), or exactly-once (guaranteed delivery with dedup at the transport, expensive). Cloudflare Queues implements at-least-once with a stable message-id the consumer uses for its own dedup; the WSD-005 messaging standard (operator/knowledge/wsd/wsd-standards/wsd-005-messaging.md) makes at-least-once and out-of-order tolerance the shipped default for domain event handoffs; the messaging-queue-cloudflare blueprint claims the deliverySemantics topic on the shelf so future exactly-once or at-most-once siblings surface as DELIBERATE conflicts and not silent divergences.",
   "decision": "The shipped v1.0.0 shape is at-least-once. Every publish reaches every consumer at least once; duplicates are possible under retry-and-DLQ redelivery paths; consumer code that needs exactly-once semantics maintains its own dedup keyed on the stable message-id per REQ-002. The deliverySemantics topic scope is global on this blueprint; the topic string is deliverySemantics (lower camel case, one concept per topic, no version suffix, per the round-2 rules-for-new-topics clause on the shelf registry). Future exactly-once or at-most-once siblings would contribute the same topic string with a different answer, forcing a DELIBERATE conflict the operator resolves with a project-level ADR per the round-2 conflict pattern.",
-  "consequences": "The applying project inherits an at-least-once transport with a stable message-id it uses for consumer-side dedup when the domain calls for exactly-once processing. Standards trace clause: WSD-005 clauses on at-least-once and out-of-order tolerance (satisfied by the message-id and trace-id header contract). The reserved messaging-queue-postgres sibling (Baz decision 7) will claim deliverySemantics with an at-least-once answer too; two shipped answers on one topic surface a DELIBERATE conflict the operator resolves by picking one queue backend per project via a project-level ADR (the same shape as errorEnvelope and authModel conflicts the SPA and API-REST blueprints already carry).",
+  "consequences": "The applying project inherits an at-least-once transport with a stable message-id it uses for consumer-side dedup when the domain calls for exactly-once processing. Standards trace clause: WSD-005 clauses on at-least-once and out-of-order tolerance (satisfied by the message-id and trace-id header contract). The reserved messaging-queue-postgres sibling (sibling reservation) will claim deliverySemantics with an at-least-once answer too; two shipped answers on one topic surface a DELIBERATE conflict the operator resolves by picking one queue backend per project via a project-level ADR (the same shape as errorEnvelope and authModel conflicts the SPA and API-REST blueprints already carry).",
   "alternativesConsidered": [
     {
       "name": "At-most-once as the shipped v1.0.0 default",

package/blueprints/messaging-queue-cloudflare/contributions/probes/real-account-concurrency-smoke.mjs

@@ -10,7 +10,7 @@
  * and a throwaway consumer Worker under `h2-cf-probe-integrity-
  * scratch-w-` bound to the queue (consumer) with RCF_TEST_QUEUE
  * (shipped queue producer binding name) + RCF_TEST_TELEMETRY_KV
- * bindings. NO workers.dev subdomain is enabled (Dave ruling
+ * bindings. NO workers.dev subdomain is enabled (operator ruling
  * 376b4f30): the consumer is invoked BY THE QUEUE, not over HTTP.
  *
  * Driver:
@@ -30,10 +30,10 @@
  * Local proof is a mock of Cloudflare's REST contract, not the wire.
  * The local run exercises OUR lifecycle logic against a mock of
  * Cloudflare's contract; the real-account gate is the only surface
- * that proves the wire format (Dave ruling 376b4f30). This probe is
+ * that proves the wire format (operator ruling). This probe is
  * therefore never described as "locally verified" - the local runs
  * are our own lifecycle-logic proof; wire correctness is proven at
- * the HQ real-account gate.
+ * the operator estate real-account gate.
  *
  * Declared env (dispatch requirement 4):
  *   CI_HAS_CLOUDFLARE_ACCOUNT   required to enter the driver path.
@@ -64,13 +64,118 @@ const DOCUMENTED_PUSH_CAP = 250;
 export const anchorAcId = 'AC-29108-2';
 export const accountBound = true;
 
-function skipResult(detail) {
+// Every env var the probe reads. Superset of the shim's DECLARED_ENV
+// (shim tracks its own reads; this probe additionally reads
+// GITHUB_RUN_ID for the mint runId derivation).
+const PROBE_DECLARED_ENV = Object.freeze([
+  ...DECLARED_ENV,
+  'GITHUB_RUN_ID',
+]);
+
+// Pre-flight observation: does the target Cloudflare account have a
+// workers.dev subdomain provisioned? The queue consumer-attach step
+// (see mintScratchQueueAndWorker) requires one, and on accounts
+// without it the attach rejects with HTTP 403 code 10063 leaving a
+// partial mint that the shim rolls back. Observing the account state
+// up front lets the probe record a declared skip whose reason names
+// the missing ACCOUNT prerequisite rather than any env var, and
+// whose detail carries the API status and code as evidence. Endpoint:
+// GET /accounts/{id}/workers/subdomain (verifiedOn 2026-09-11 per
+// https://developers.cloudflare.com/api/operations/worker-subdomain-get-subdomain).
+//
+// Return classification:
+//   - `provisioned`      : HTTP 200 with `success: true` and a
+//                          non-empty `result.subdomain`. The probe
+//                          runs mint / drive / teardown.
+//   - `affirmativelyAbsent`
+//                        : the AFFIRMATIVE absence shape the vendor
+//                          returns for an unprovisioned account,
+//                          EITHER HTTP 404 with error code 10007 OR
+//                          HTTP 200 with `success: true` and a plain
+//                          `result` object whose own `subdomain` key
+//                          is present and is exactly null or the
+//                          empty string ''. The probe records an
+//                          accountBoundSkipped declared skip.
+//   - `unclassified`     : any other shape - non-2xx/non-404, a 200
+//                          success body missing `result` or with
+//                          `result` an array / primitive / null, a
+//                          missing `subdomain` key, a `subdomain` of
+//                          the wrong JSON type (number, boolean,
+//                          object, array, whitespace-only string),
+//                          malformed JSON, unexpected status/code
+//                          combination. The probe fails the verdict
+//                          with the observed status and body code
+//                          in detail; a skip on a non-absence /
+//                          schema-malformed shape is a 7d violation.
+async function preflightWorkersDevSubdomain() {
+  const accountId = process.env.CF_ACCOUNT_ID;
+  const token = process.env.CF_API_TOKEN;
+  const base = (process.env.CF_API_BASE_URL && process.env.CF_API_BASE_URL.trim())
+    ? process.env.CF_API_BASE_URL.replace(/\/$/, '')
+    : 'https://api.cloudflare.com/client/v4';
+  const url = `${base}/accounts/${accountId}/workers/subdomain`;
+  const resp = await fetch(url, { method: 'GET', headers: { authorization: `Bearer ${token}` } });
+  const text = await resp.text();
+  let json = null;
+  let parseError = null;
+  try { json = JSON.parse(text); } catch (err) { parseError = err && err.message ? err.message : 'JSON parse failed'; }
+  const errorCode = json && Array.isArray(json.errors) && json.errors[0] && json.errors[0].code;
+  // Documented success response shape (per Cloudflare API docs for
+  // GET /accounts/{account_id}/workers/subdomain, verifiedOn
+  // 2026-09-11 via https://developers.cloudflare.com/api/operations/
+  // worker-subdomain-get-subdomain): result is an object with a
+  // `subdomain` field of type string (example: "my-subdomain"). The
+  // vendor does not document the unprovisioned shape explicitly, so
+  // this classifier applies the strictest defensible interpretation:
+  //   - provisioned         : result is a plain object, has own
+  //                           `subdomain` key, value is a NON-EMPTY
+  //                           string.
+  //   - affirmativelyAbsent : result is a plain object, has own
+  //                           `subdomain` key, value is EXACTLY null
+  //                           OR the empty string ''.
+  //   - unclassified        : every other structural shape - result
+  //                           missing / null / array / primitive,
+  //                           subdomain key absent, subdomain of any
+  //                           other type (number, boolean, object,
+  //                           array, whitespace-only string, etc).
+  // Schema-malformed success bodies (e.g. `{"success":true}` with no
+  // result, or result an array, or subdomain of the wrong type) are
+  // NOT treated as absence - they fail as unclassified so a reviewer
+  // sees the exact vendor signal rather than a silent skip.
+  const isPlainResultObject = json !== null
+    && typeof json === 'object'
+    && Object.prototype.hasOwnProperty.call(json, 'result')
+    && json.result !== null
+    && typeof json.result === 'object'
+    && !Array.isArray(json.result);
+  const hasSubdomainKey = isPlainResultObject
+    && Object.prototype.hasOwnProperty.call(json.result, 'subdomain');
+  const subdomainRaw = hasSubdomainKey ? json.result.subdomain : undefined;
+  const subdomainIsProvisionedString = typeof subdomainRaw === 'string' && subdomainRaw.length > 0 && subdomainRaw === subdomainRaw.trim() && subdomainRaw.trim().length > 0;
+  const subdomainIsAbsenceSentinel = subdomainRaw === null || subdomainRaw === '';
+  const subdomain = subdomainIsProvisionedString ? subdomainRaw : null;
+  let classification = 'unclassified';
+  if (parseError === null && json) {
+    if (resp.status === 200 && json.success === true && hasSubdomainKey && subdomainIsProvisionedString) {
+      classification = 'provisioned';
+    } else if (resp.status === 404 && json.success === false && errorCode === 10007) {
+      classification = 'affirmativelyAbsent';
+    } else if (resp.status === 200 && json.success === true && hasSubdomainKey && subdomainIsAbsenceSentinel) {
+      classification = 'affirmativelyAbsent';
+    }
+  }
+  const bodyExcerpt = text.length > 400 ? text.slice(0, 400) + '...(truncated)' : text;
+  return { status: resp.status, errorCode, subdomain, classification, parseError, bodyExcerpt };
+}
+
+function skipResult({ reason, detail }) {
   return [{
     anchorAcId: 'AC-29108-2',
     verdict: 'pass',
     detail,
     accountBoundSkipped: true,
-    envDeclared: Array.from(DECLARED_ENV),
+    reason,
+    envDeclared: PROBE_DECLARED_ENV,
     throwawayPrefixes: { queue: QUEUE_PREFIX, worker: WORKER_PREFIX, telemetryKv: TELEMETRY_KV_PREFIX },
   }];
 }
@@ -109,14 +214,53 @@ async function readTelemetryRecords({ namespaceId }) {
 export default async function runProbe() {
   const hasAccount = process.env.CI_HAS_CLOUDFLARE_ACCOUNT === '1' || process.env.CI_HAS_CLOUDFLARE_ACCOUNT === 'true';
   if (!hasAccount) {
-    return skipResult(`accountBoundSkipped: CI_HAS_CLOUDFLARE_ACCOUNT unset; a real-account run requires CI_HAS_CLOUDFLARE_ACCOUNT=true plus CF_ACCOUNT_ID and CF_API_TOKEN. The fixture mints its own throwaway Queue + consumer Worker + telemetry KV namespace under the H-2 prefixes; publishes via the CF Queues REST publish endpoint (no workers.dev subdomain enabled); reads telemetry via the KV REST list + get endpoints. Cap under test: ${DOCUMENTED_PUSH_CAP} concurrent invocations per push-consumer per https://developers.cloudflare.com/queues/platform/limits/. Message count: ${DEFAULT_MESSAGE_COUNT}.`);
+    return skipResult({
+      reason: 'CI_HAS_CLOUDFLARE_ACCOUNT',
+      detail: `accountBoundSkipped: CI_HAS_CLOUDFLARE_ACCOUNT unset; a real-account run requires CI_HAS_CLOUDFLARE_ACCOUNT=true. When set, the fixture shim self-provisions a throwaway Queue, consumer Worker and telemetry KV namespace under the frozen scratch prefixes, publishes via the Cloudflare Queues REST publish endpoint (verifiedOn 2026-09-10 per https://developers.cloudflare.com/api/operations/queue-publish-messages), reads telemetry via the KV REST list and get endpoints, and tears every resource down before exit. Cap under test: ${DOCUMENTED_PUSH_CAP} concurrent invocations per push-consumer per https://developers.cloudflare.com/queues/platform/limits/ (verifiedOn 2026-09-10). Message count: ${DEFAULT_MESSAGE_COUNT}.`,
+    });
+  }
+  const missingCreds = [];
+  if (!process.env.CF_ACCOUNT_ID) missingCreds.push('CF_ACCOUNT_ID');
+  if (!process.env.CF_API_TOKEN) missingCreds.push('CF_API_TOKEN');
+  if (missingCreds.length > 0) {
+    const noun = missingCreds.length > 1 ? 'those credentials are' : 'that credential is';
+    return skipResult({
+      reason: missingCreds.join(','),
+      detail: `accountBoundSkipped: ${missingCreds.join(' and ')} unset; a real-account run requires ${noun} present. Cap under test: ${DOCUMENTED_PUSH_CAP} concurrent invocations per push-consumer per https://developers.cloudflare.com/queues/platform/limits/ (verifiedOn 2026-09-10). Message count: ${DEFAULT_MESSAGE_COUNT}.`,
+    });
   }
-  if (!process.env.CF_ACCOUNT_ID || !process.env.CF_API_TOKEN) {
+  // Pre-flight account-state observation: the queue consumer-attach
+  // API requires the target Cloudflare account to have a workers.dev
+  // subdomain provisioned (rejects with HTTP 403 code 10063 without
+  // one, per https://developers.cloudflare.com/api/resources/queues/
+  // subresources/consumers/ verifiedOn 2026-09-10). This probe
+  // observes the subdomain state directly via
+  // GET /accounts/{id}/workers/subdomain and records a declared skip
+  // when the account has none - the reason names the missing ACCOUNT
+  // prerequisite (not an env var) and the detail carries the API
+  // status and error code as positive evidence of the observation.
+  // A fully capable account carries a subdomain and the probe
+  // proceeds unconditionally to mint / drive / teardown.
+  const preflight = await preflightWorkersDevSubdomain();
+  if (preflight.classification === 'affirmativelyAbsent') {
+    return skipResult({
+      reason: 'cloudflare-account-workers-dev-subdomain-not-provisioned',
+      detail: `accountBoundSkipped: pre-flight GET /accounts/{id}/workers/subdomain returned status=${preflight.status} errorCode=${preflight.errorCode ?? 'null'} subdomain=${preflight.subdomain ?? 'null'} - the target Cloudflare account affirms it has no workers.dev subdomain provisioned. The queue consumer-attach step (see https://developers.cloudflare.com/api/resources/queues/subresources/consumers/, verifiedOn 2026-09-10) rejects with HTTP 403 code 10063 in that state, so the probe cannot complete a live run against this account. The account prerequisite (a provisioned workers.dev subdomain) is out of the probe's authorship scope. Cap under test: ${DOCUMENTED_PUSH_CAP} concurrent invocations per push-consumer per https://developers.cloudflare.com/queues/platform/limits/ (verifiedOn 2026-09-10). Message count: ${DEFAULT_MESSAGE_COUNT}.`,
+    });
+  }
+  if (preflight.classification !== 'provisioned') {
+    // Any non-absence, non-success response from the pre-flight is a
+    // real failure that must not be swallowed as a skip (authoring
+    // standard section 7d: a bare pass on a shape the probe did not
+    // observe would be positive-evidence-missing). Detail carries the
+    // observed status, Cloudflare error code and body excerpt so the
+    // reviewer can act on the exact vendor signal.
     return [{
       anchorAcId: 'AC-29108-2',
       verdict: 'fail',
-      detail: `CI_HAS_CLOUDFLARE_ACCOUNT=true but one of CF_ACCOUNT_ID / CF_API_TOKEN is missing: accountIdPresent=${!!process.env.CF_ACCOUNT_ID} tokenPresent=${!!process.env.CF_API_TOKEN}.`,
-      envDeclared: Array.from(DECLARED_ENV),
+      detail: `pre-flight GET /accounts/{id}/workers/subdomain returned an unclassified shape: status=${preflight.status} errorCode=${preflight.errorCode ?? 'null'} subdomain=${preflight.subdomain ?? 'null'} parseError=${preflight.parseError ?? 'null'} bodyExcerpt=${preflight.bodyExcerpt}. The probe refuses to declare an accountBound skip on a shape that is neither the vendor's affirmative absence (HTTP 404 code 10007, or HTTP 200 with an empty subdomain) nor a provisioned subdomain (HTTP 200 with a non-empty result.subdomain).`,
+      envDeclared: PROBE_DECLARED_ENV,
+      preflight: { status: preflight.status, errorCode: preflight.errorCode, subdomain: preflight.subdomain, parseError: preflight.parseError },
     }];
   }
 
@@ -131,10 +275,11 @@ export default async function runProbe() {
       anchorAcId: 'AC-29108-2',
       verdict: 'fail',
       detail: `mintScratchQueueAndWorker failed: ${err.message}`,
-      envDeclared: Array.from(DECLARED_ENV),
+      envDeclared: PROBE_DECLARED_ENV,
     }];
   }
 
+  let results = null;
   try {
     const started = Date.now();
     const batches = [];
@@ -154,12 +299,13 @@ export default async function runProbe() {
     ));
     const publishFail = publishResults.find((r) => !r.ok);
     if (publishFail) {
-      return [{
+      results = [{
         anchorAcId: 'AC-29108-2',
         verdict: 'fail',
         detail: `queuePublishBatch failed: status=${publishFail.status} error=${publishFail.error}`,
-        envDeclared: Array.from(DECLARED_ENV),
+        envDeclared: PROBE_DECLARED_ENV,
       }];
+      return results;
     }
     const publishedCount = publishResults.reduce((acc, r) => acc + (r.count ?? 0), 0);
 
@@ -181,7 +327,7 @@ export default async function runProbe() {
     const observedConcurrency = maxConcurrent > 1;
     const allOk = drained && withinCap && observedConcurrency;
 
-    return [{
+    results = [{
       anchorAcId: 'AC-29108-2',
       verdict: allOk ? 'pass' : 'fail',
       detail: allOk
@@ -196,14 +342,36 @@ export default async function runProbe() {
       batches: batchesConsumed,
       maxConcurrent,
       elapsedMs: elapsed,
-      envDeclared: Array.from(DECLARED_ENV),
+      envDeclared: PROBE_DECLARED_ENV,
       throwawayPrefixes: { queue: QUEUE_PREFIX, worker: WORKER_PREFIX, telemetryKv: TELEMETRY_KV_PREFIX },
     }];
+    return results;
   } finally {
     try {
       await destroyScratchQueueAndWorker(mint);
     } catch (err) {
-      process.stderr.write(`h2-cf-queue probe: teardown failed for queue=${mint && mint.queue && mint.queue.id} worker=${mint && mint.worker && mint.worker.name} telemetryKv=${mint && mint.telemetryKv && mint.telemetryKv.id}: ${err.message}; sweepOrphans will collect on next run.\n`);
+      const orphaned = {
+        queueId: mint && mint.queue && mint.queue.id,
+        queueName: mint && mint.queue && mint.queue.name,
+        workerName: mint && mint.worker && mint.worker.name,
+        telemetryKvId: mint && mint.telemetryKv && mint.telemetryKv.id,
+      };
+      const orphanRecord = {
+        anchorAcId: 'AC-29108-2',
+        verdict: 'fail',
+        detail: `TEARDOWN FAILED: destroyScratchQueueAndWorker threw ${err && err.message ? err.message : String(err)}; potentially orphaned resources on the account: queue.id=${orphaned.queueId} queue.name=${orphaned.queueName} consumerWorker.name=${orphaned.workerName} telemetryKv.id=${orphaned.telemetryKvId}. sweepOrphans on the shim will collect on the next real-account run; a live account audit is still recommended.`,
+        teardownFailed: true,
+        orphaned,
+        envDeclared: PROBE_DECLARED_ENV,
+        throwawayPrefixes: { queue: QUEUE_PREFIX, worker: WORKER_PREFIX, telemetryKv: TELEMETRY_KV_PREFIX },
+      };
+      if (Array.isArray(results)) {
+        results.push(orphanRecord);
+      } else {
+        // Body threw before assigning results (would have propagated already);
+        // this branch keeps the safety net symmetric.
+        results = [orphanRecord];
+      }
     }
   }
 }

package/blueprints/messaging-queue-cloudflare/contributions/requirements/messaging-queue-cloudflare-req-001.json

@@ -2,7 +2,7 @@
   "reqId": "messaging-queue-cloudflare-REQ-001",
   "prdId": "PRD-001",
   "title": "One producer facade module is the sole reader of the Cloudflare Queues binding and opens on boot with producerReady",
-  "description": "The application publishes to the queue through a single producer facade module in the project's source tree that is the ONLY module holding a reference to the Cloudflare Queues binding (env.RCF_TEST_QUEUE in the fixture; the elicited binding name in a real project). Every other module that publishes reads the facade and calls its typed domain verbs (publish, publishBatch); no other module dereferences the raw Queues binding. On process boot, the facade opens against the bound queue and, once ready, emits a producerReady lifecycle event carrying the queue name. The queue name (or the binding name in a Workers deploy) is elicited at apply time under the Queues binding declared in wrangler config.",
+  "description": "The application publishes to the queue through a single producer facade module in the project's source tree that is the ONLY module holding a reference to the Cloudflare Queues binding (env.RCF_TEST_QUEUE in the fixture; the elicited binding name in a real project). Every other module that publishes reads the facade and calls its typed domain verbs (publish, publishBatch); no other module dereferences the raw Queues binding. On process boot, the facade opens against the bound queue and, once ready, emits a producerReady lifecycle event carrying the queue name. The queue name (or the binding name in a Workers deploy) is elicited at apply time under the Queues binding declared in wrangler config. The queue-binding-name is elicited at apply time; the producer facade dereferences env[queue-binding-name] once at boot and holds no other reference. The queue-name is elicited at apply time under the wrangler [[queues.producers]] declaration.",
   "category": "functional",
   "domain": "messaging",
   "priority": "must",
@@ -14,5 +14,9 @@
   "version": "1.0.0",
   "status": "approved",
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "deliveredBy": {
+    "tacId": "TAC-3001-messaging-queue-cloudflare-producer-facade",
+    "field": "responsibilities.producerReady"
+  }
 }