rcf-lite 0.26.0 → 0.28.0

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

@@ -2,7 +2,7 @@
   "reqId": "messaging-queue-cloudflare-REQ-002",
   "prdId": "PRD-001",
   "title": "Publish, consume and ack with stable message-id and producer-supplied trace-id",
-  "description": "The producer facade publishes messages with a stable message-id assigned by the Cloudflare Queues platform on send and a producer-supplied trace-id carried in the message headers. The consumer, registered on the Worker's queue handler, reads a batch of messages, dispatches each to the registered handler, acknowledges each per message on successful return, and returns retry when the handler throws a retryable error. The received body equals the published body byte-for-byte; the received headers include both the stable message-id and the producer-supplied trace-id. Publish is idempotent from the producer's point of view within a single facade instance (an application layer that reissues a publish for the same domain event gets a new message-id, per the at-least-once shape).",
+  "description": "The producer facade publishes messages with a stable message-id assigned by the Cloudflare Queues platform on send and a producer-supplied trace-id carried in the message headers. The consumer, registered on the Worker's queue handler, reads a batch of messages, dispatches each to the registered handler, acknowledges each per message on successful return, and returns retry when the handler throws a retryable error. The received body equals the published body byte-for-byte; the received headers include both the stable message-id and the producer-supplied trace-id. Publish is at-least-once (never idempotent; ADR-3002 records the ratified delivery semantics) from the producer's point of view within a single facade instance (an application layer that reissues a publish for the same domain event gets a new message-id, per the at-least-once shape).",
   "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": {
+    "adrId": "ADR-3002-messaging-queue-cloudflare-delivery-semantics",
+    "field": "decision.at-least-once"
+  }
 }

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

@@ -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-3002-messaging-queue-cloudflare-consumer-registration",
+    "field": "responsibilities.retryClassification"
+  }
 }

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

@@ -2,7 +2,7 @@
   "reqId": "messaging-queue-cloudflare-REQ-004",
   "prdId": "PRD-001",
   "title": "Dead-letter contract: elicited max-attempts default 3, DLQ retention 4 days, dead_letter_queue field on the consumer",
-  "description": "After the elicited max-attempts (default 3 per the Cloudflare Queues documented default) is reached on a message, the message lands on the configured dead-letter queue (DLQ) and the facade fires messageDeadLettered on the sink with the stable message-id, the queue name, and the terminal attempt count. The DLQ is declared per-consumer in wrangler config through the dead_letter_queue field (per https://developers.cloudflare.com/queues/configuration/dead-letter-queues/); the field syntax in wrangler.toml is dead_letter_queue = \"<dlq-queue-name>\" alongside max_retries on the [[queues.consumers]] block. The DLQ retention defaults to 4 days when no active consumer is attached per the same Cloudflare DLQ documentation. Consumer code can attach a DLQ consumer to drain the DLQ (via wrangler queues consumer add) for inspection or replay per the same Cloudflare DLQ documentation.",
+  "description": "After the elicited max-attempts (default 3 per the Cloudflare Queues documented default) is reached on a message, the message lands on the configured dead-letter queue (DLQ) and the facade fires messageDeadLettered on the sink with the stable message-id, the queue name, and the terminal attempt count. The DLQ is declared per-consumer in wrangler config through the dead_letter_queue field (per https://developers.cloudflare.com/queues/configuration/dead-letter-queues/); the field syntax in wrangler.toml is dead_letter_queue = \"<dlq-queue-name>\" alongside maxDeliveries mapped to the vendor max_retries field per TAC-3002 as (maxDeliveries - 1) so max_retries=2 delivers three times before DLQ on the [[queues.consumers]] block. The DLQ retention defaults to 4 days when no active consumer is attached per the same Cloudflare DLQ documentation. Consumer code can attach a DLQ consumer to drain the DLQ (via wrangler queues consumer add) for inspection or replay per the same Cloudflare DLQ documentation.",
   "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": {
+    "adrId": "ADR-3003-messaging-queue-cloudflare-max-attempts-floor",
+    "field": "decision.maxAttemptsCeiling"
+  }
 }

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

@@ -2,7 +2,7 @@
   "reqId": "messaging-queue-cloudflare-REQ-005",
   "prdId": "PRD-001",
   "title": "Batch consume: elicited batch size default 10 max 100, batch timeout default 5 seconds max 60 seconds",
-  "description": "The consumer reads messages in batches whose size is elicited (default 10, bounded above by the Cloudflare max 100 messages per batch per https://developers.cloudflare.com/queues/platform/limits/) and whose batch-timeout (batch wait) is elicited (default 5 seconds, bounded above by the Cloudflare max 60 seconds per the same limits doc). Batch settings live on the [[queues.consumers]] block in wrangler config as max_batch_size and max_batch_timeout. When the batch is full or the timeout fires, the Worker's queue handler receives the whole batch in one invocation; the facade dispatches per-message to the registered handler and acknowledges per-message. A batch member returning retry does not roll the whole batch back; only that message is redelivered.",
+  "description": "The consumer reads messages in batches whose size is elicited (default 10, bounded above by the Cloudflare max 100 messages per batch per https://developers.cloudflare.com/queues/platform/limits/) and whose batch-timeout (batch wait) is elicited (default 5 seconds, bounded above by the Cloudflare max 60 seconds per the same limits doc). Batch settings live on the [[queues.consumers]] block in wrangler config as max_batch_size and max_batch_timeout. When the batch is full or the timeout fires, the Worker's queue handler receives the whole batch in one invocation; the facade dispatches per-message to the registered handler and acknowledges per-message. A batch member returning retry does not roll the whole batch back; only that message is redelivered. The batch-size is elicited at apply time (default 10, ceiling 100 per the Cloudflare Queues platform-limits page). The batch-timeout-seconds is elicited at apply time (default 5, ceiling 60 per the same limits doc).",
   "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-3002-messaging-queue-cloudflare-consumer-registration",
+    "field": "responsibilities.createConsumer"
+  }
 }

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

@@ -2,7 +2,7 @@
   "reqId": "messaging-queue-cloudflare-REQ-006",
   "prdId": "PRD-001",
   "title": "Lifecycle events with metadata-only fields: producerReady, messagePublished, messageAcked, messageDeadLettered",
-  "description": "The facade fires four lifecycle events on the injected event sink: producerReady (once per facade instance, on the first successful ready-check), messagePublished (once per successful publish), messageAcked (once per successful ack), messageDeadLettered (once per DLQ landing). Every event record carries a metadata-only field whitelist: messageId, queueName, attempts (integer, 0 for producerReady and messagePublished), timestamp (ISO 8601 UTC). No event record contains the message body, any header value, any consumer-context field, or any producer-context field. The whitelist is enforced in code (the sink adapter refuses forbidden fields); a call site that hands a body-bearing payload to the sink is refused at author-side review.",
+  "description": "The facade fires four lifecycle events on the injected event sink: producerReady (once per facade instance, on the first successful ready-check), messagePublished (once per successful publish), messageAcked (once per successful ack), messageDeadLettered (once per DLQ landing). Every event record carries a metadata-only field whitelist: messageId, queueName, attempts (integer, 0 for producerReady and messagePublished), ts (ISO 8601 UTC). No event record contains the message body, any header value, any consumer-context field, or any producer-context field. The whitelist is enforced in code (the sink adapter refuses forbidden fields); a call site that hands a body-bearing payload to the sink is refused at the author-side check.",
   "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-3003-messaging-queue-cloudflare-event-sink",
+    "field": "responsibilities.producerReady"
+  }
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29101.json

@@ -16,7 +16,8 @@
       "when": "the process boots and the facade ready-check returns",
       "then": "a producerReady event fires on the injected event sink with a payload containing queueName; the facade exposes named domain verbs (publish, publishBatch) and does not re-export the raw Queues binding",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-29101-2",
@@ -25,10 +26,27 @@
       "when": "grep for a Queues binding dereference walks the tree outside the facade directory",
       "then": "no match is found outside the facade directory; the facade's public surface exports named domain verbs only, no raw binding reference",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-29101-3",
+      "description": "Binding missing at boot. Given the elicited queue-binding-name resolves to no binding on env (the wrangler.toml [[queues.producers]] block is absent, or the binding name is mistyped), when the producer facade opens on boot, then the facade refuses with a named error kind (missingQueueBinding); no producerReady fires on the sink.",
+      "given": "env[queue-binding-name] is undefined",
+      "when": "the producer facade opens on boot",
+      "then": "the facade refuses with missingQueueBinding; no producerReady fires",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3001-messaging-queue-cloudflare-producer-facade",
+        "field": "interfaces.createProducer"
+      },
+      "disposition": "template"
     }
   ],
-  "tacIds": ["TAC-3001-messaging-queue-cloudflare-producer-facade"],
+  "tacIds": [
+    "TAC-3001-messaging-queue-cloudflare-producer-facade"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29102.json

@@ -16,7 +16,8 @@
       "when": "the consumer processes the queue batch",
       "then": "all 5 messages are received with body byte-equal, message-id present and stable per message across the delivery, and the producer-supplied trace-id present on the message headers",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-29102-2",
@@ -25,10 +26,28 @@
       "when": "the consumer returns success",
       "then": "a messageAcked event fires with messageId and queueName; the message is not redelivered",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-29102-3",
+      "description": "Publish upstream refusal surfaces. Given the Cloudflare Queues API returns a non-2xx response to a publish call (throttled 429, or 5xx), when the producer's publish verb runs, then the facade catches the failure and emits publishFailed on the event sink carrying { queueName, tracelId, httpStatus, retryable: boolean }, the caller receives the error, and no messageAcked fires downstream for that trace-id.",
+      "given": "the Queues API returns non-2xx on publish",
+      "when": "the publish verb runs",
+      "then": "publishFailed fires with {queueName, traceId, httpStatus, retryable}; the caller receives the error; no messageAcked fires downstream",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3001-messaging-queue-cloudflare-producer-facade",
+        "field": "interfaces.producer.verbs"
+      },
+      "disposition": "template"
     }
   ],
-  "tacIds": ["TAC-3001-messaging-queue-cloudflare-producer-facade", "TAC-3002-messaging-queue-cloudflare-consumer-registration"],
+  "tacIds": [
+    "TAC-3001-messaging-queue-cloudflare-producer-facade",
+    "TAC-3002-messaging-queue-cloudflare-consumer-registration"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29103.json

@@ -16,10 +16,27 @@
       "when": "the consumer is invoked across successive deliveries",
       "then": "the message-id is stable across attempts 1 to 3; the attempt counter increments on each delivery; body, headers and producer-supplied trace-id remain byte-equal across attempts",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-29103-2",
+      "description": "Attempt counter monotonic across N retries. Given a consumer that returns retry on every delivery, when the queue redelivers up to maxDeliveries, then each delivery carries an attempt count strictly greater than the previous (1, 2, 3, ...), and the counter does not reset mid-cycle; a mutation SIMULATE_ATTEMPT_RESET=true swaps two attempt values and the assertion FAILS.",
+      "given": "a consumer that returns retry on every delivery",
+      "when": "the queue redelivers up to maxDeliveries",
+      "then": "each delivery carries a strictly greater attempt count; the reset mutation FAILS",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+        "field": "interfaces.createConsumer"
+      },
+      "disposition": "fixed"
     }
   ],
-  "tacIds": ["TAC-3002-messaging-queue-cloudflare-consumer-registration"],
+  "tacIds": [
+    "TAC-3002-messaging-queue-cloudflare-consumer-registration"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29104.json

@@ -11,15 +11,37 @@
   "acceptanceCriteria": [
     {
       "id": "AC-29104-1",
-      "description": "Given a message that returns retry across max_retries deliveries (default 3), when the third delivery returns retry, then a messageDeadLettered event fires on the sink with the stable message-id, the queue name, and attempts equal to the terminal attempt count. The message is present on the DLQ; inspecting the DLQ through the fixture DLQ-inspector helper returns the body byte-equal to the original publish.",
-      "given": "the fixture with max_retries 3 and SIMULATE_CONSUMER_RETRY=true published once",
-      "when": "the delivery loop runs to exhaustion",
-      "then": "the retry-and-dlq probe records attempts 1, 2, 3 with the same message-id; messageDeadLettered fires with attempts equal to the terminal count; the DLQ-inspector reads the message body back byte-equal",
+      "description": "Given the consumer registered under maxDeliveries=3 (mapped to max_retries=2 on wrangler consumers per TAC-3002), when a handler refuses on delivery 1 and delivery 2 and delivery 3, then delivery 3's refusal routes the message into the DLQ (dead_letter_queue field), messageDeadLettered fires with { queueName, messageId, deliveries: 3, deadLetterQueue }, and no fourth delivery is attempted against the primary consumer. A boundary case at maxDeliveries=1 asserts the message crosses to DLQ on the first refusal.",
+      "given": "consumer registered under maxDeliveries=3 (max_retries=2)",
+      "when": "the handler refuses on deliveries 1, 2 and 3",
+      "then": "delivery 3's refusal dead-letters the message; messageDeadLettered fires with { queueName, messageId, deliveries: 3, deadLetterQueue }; no fourth primary delivery",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+        "field": "interfaces.createConsumer"
+      }
+    },
+    {
+      "id": "AC-29104-2",
+      "description": "Boundary at maxDeliveries=1. Given the consumer registered under maxDeliveries=1 (max_retries=0), when a handler refuses on delivery 1, then delivery 1's refusal routes the message into the DLQ immediately; messageDeadLettered fires with { queueName, messageId, deliveries: 1, deadLetterQueue }; no second primary delivery is attempted.",
+      "given": "consumer registered under maxDeliveries=1 (max_retries=0)",
+      "when": "the handler refuses on delivery 1",
+      "then": "the message crosses to DLQ on the first refusal; messageDeadLettered fires with deliveries=1; no second delivery",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+        "field": "interfaces.createConsumer"
+      },
+      "disposition": "template"
     }
   ],
-  "tacIds": ["TAC-3002-messaging-queue-cloudflare-consumer-registration", "TAC-3003-messaging-queue-cloudflare-event-sink"],
+  "tacIds": [
+    "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+    "TAC-3003-messaging-queue-cloudflare-event-sink"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29105.json

@@ -16,10 +16,27 @@
       "when": "the publish-to-delivery probe publishes 5 messages",
       "then": "the consumer receives them in one batch; per-message ack fires 5 times; the messageAcked events on the sink number 5",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-29105-2",
+      "description": "Batch-size ceiling refused at load. Given the elicited batch-size answered above the Cloudflare limit of 100, when the loader validates the elicited answer, then the loader refuses with a named error kind (batchSizeAboveCeiling) and the ship gate FAILS; a mutation SIMULATE_BATCH_LIMIT_BREACH=true forces a 150 value into the applied sidecar and the same refusal fires downstream.",
+      "given": "batch-size answered above 100",
+      "when": "the loader validates the elicited answer",
+      "then": "the loader refuses with batchSizeAboveCeiling; the ship gate FAILS; the mutation surfaces the same refusal downstream",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+        "field": "interfaces.createConsumer"
+      },
+      "disposition": "template"
     }
   ],
-  "tacIds": ["TAC-3002-messaging-queue-cloudflare-consumer-registration"],
+  "tacIds": [
+    "TAC-3002-messaging-queue-cloudflare-consumer-registration"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29106.json

@@ -11,15 +11,36 @@
   "acceptanceCriteria": [
     {
       "id": "AC-29106-1",
-      "description": "Given the SIMULATE_PII_IN_BODY=true induced-failure switch driving publish and ack with a PII fixture body (userId 1234, ssn 123-45-6789), when the event-secrecy probe captures the events, then every event record carries exactly the whitelist fields (event, messageId, queueName, attempts, timestamp) and no more; no body bytes, no header value, no userId string, no ssn string, no consumer-context field appears in any record, verified by JSON-stringify substring grep.",
+      "description": "Given the SIMULATE_PII_IN_BODY=true induced-failure switch driving publish and ack with a PII fixture body (userId 1234, ssn 123-45-6789), when the event-secrecy probe captures the events, then every event record carries exactly the whitelist fields (event, messageId, queueName, attempts, ts (number of milliseconds since epoch)) and no more; no body bytes, no header value, no userId string, no ssn string, no consumer-context field appears in any record, verified by JSON-stringify substring grep.",
       "given": "the PII fixture body driven through publish, consume and ack",
       "when": "the event-secrecy probe reads the captured event records",
       "then": "every record carries only the whitelist; JSON-stringify substring grep for the fixture PII strings returns no match on any record",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-3003-messaging-queue-cloudflare-event-sink",
+        "field": "interfaces.createSinkAdapter"
+      }
+    },
+    {
+      "id": "AC-29106-2",
+      "description": "Secret exclusion by grep-across-source. Given the producer facade source, the consumer registration source, and the event sink source, when a source-tree scan searches every onEvent call site for header values, message body bytes, and any elicited binding name substring, then no match is found; a mutation SIMULATE_HEADER_VALUE_IN_EVENT=true injects a header value into one event record and the scan FAILS naming the leaked event id.",
+      "given": "the producer, consumer and sink source files",
+      "when": "a source-tree scan runs across every onEvent call site",
+      "then": "no header-value, body-byte, or binding-name match is found; the header-leak mutation FAILS",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3001-messaging-queue-cloudflare-producer-facade",
+        "field": "interfaces.onEvent"
+      },
+      "disposition": "fixed"
     }
   ],
-  "tacIds": ["TAC-3003-messaging-queue-cloudflare-event-sink"],
+  "tacIds": [
+    "TAC-3003-messaging-queue-cloudflare-event-sink"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29107.json

@@ -16,10 +16,32 @@
       "when": "the producer-facade-ready and publish-to-delivery run-shims execute",
       "then": "each shim exits 0; the per-blueprint reports carry aggregateVerdict pass; the event records observed include producerReady with queueName and 5 messageAcked events with matching messageIds",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-29107-2",
+      "description": "wrangler dev absent surfaces cleanly. Given wrangler is not on PATH on the runner's process shell, when the wrangler-dev round-trip probe runs, then the probe skips with accountBoundSkipped: true and a non-empty reason naming the missing wrangler binary; no partial round-trip is asserted.",
+      "given": "wrangler is not on PATH",
+      "when": "the wrangler-dev round-trip probe runs",
+      "then": "the probe skips with accountBoundSkipped: true and a non-empty reason naming missing wrangler; no partial round-trip is asserted",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3001-messaging-queue-cloudflare-producer-facade",
+        "field": "interfaces.producer.verbs"
+      },
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://developers.cloudflare.com/workers/wrangler/commands/#dev",
+        "verifiedOn": "2026-09-09"
+      }
     }
   ],
-  "tacIds": ["TAC-3001-messaging-queue-cloudflare-producer-facade", "TAC-3002-messaging-queue-cloudflare-consumer-registration"],
+  "tacIds": [
+    "TAC-3001-messaging-queue-cloudflare-producer-facade",
+    "TAC-3002-messaging-queue-cloudflare-consumer-registration"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/contributions/user-stories/messaging-queue-cloudflare-us-29108.json

@@ -6,20 +6,42 @@
   "status": "approved",
   "title": "Real-account concurrency smoke: 500 messages processed concurrently up to the 250 cap",
   "asA": "developer verifying the facade works against a real Cloudflare account",
-  "iWant": "a smoke test that publishes 500 messages against the shared HQ queue rcf-lite-ci-queue-smoke and asserts the consumer processes them concurrently up to the documented 250-invocation cap",
+  "iWant": "a smoke test that publishes 500 messages against the shared CI queue rcf-lite-ci-queue-smoke and asserts the consumer processes them concurrently up to the documented 250-invocation cap",
   "soThat": "the shipped shape's compatibility with the real Cloudflare Queues surface is proven end-to-end at least once per release, without requiring every CI run to be account-bound",
   "acceptanceCriteria": [
     {
       "id": "AC-29108-2",
-      "description": "Given CI_HAS_CLOUDFLARE_ACCOUNT=1 and the credentials for the shared HQ queue rcf-lite-ci-queue-smoke wired via security-secrets-management, when the real-account-concurrency-smoke probe runs against the real queue, then 500 messages are published, the consumer processes them concurrently up to the 250 push-based invocation cap Cloudflare documents at https://developers.cloudflare.com/queues/platform/limits/, and the smoke drains the queue on exit. Without CI_HAS_CLOUDFLARE_ACCOUNT the probe records accountBoundSkipped true per spec section 3.5 and the per-blueprint report carries aggregateVerdict pass.",
-      "given": "the shared HQ queue rcf-lite-ci-queue-smoke on Baz's account, or the env var unset",
+      "description": "Given CI_HAS_CLOUDFLARE_ACCOUNT=1 and the credentials for the shared CI queue rcf-lite-ci-queue-smoke wired via security-secrets-management, when the real-account-concurrency-smoke probe runs against the real queue, then 500 messages are published, the consumer processes them concurrently up to the 250 push-based invocation cap Cloudflare documents at https://developers.cloudflare.com/queues/platform/limits/, and the smoke drains the queue on exit. Without CI_HAS_CLOUDFLARE_ACCOUNT the probe records accountBoundSkipped true per spec section 3.5 and the per-blueprint report carries aggregateVerdict pass.",
+      "given": "the shared CI queue rcf-lite-ci-queue-smoke on the maintainer's account, or the env var unset",
       "when": "the real-account-concurrency-smoke run-shim executes",
       "then": "with the env var set, 500 messages round-trip with observed concurrency below or equal to 250; with the env var unset, the report carries accountBoundSkipped true and aggregateVerdict pass; the shim exits 0 in both paths",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://developers.cloudflare.com/queues/",
+        "verifiedOn": "2026-09-09"
+      }
+    },
+    {
+      "id": "AC-29108-3",
+      "description": "Concurrency cap enforced. Given 500 messages published in a burst on the real-account probe, when the consumer processes them, then at no observed moment is the concurrent in-flight count greater than the Cloudflare-documented 250 cap; a mutation SIMULATE_CONCURRENCY_BREACH=true drives the concurrency past 250 and the smoke FAILS naming the observed peak.",
+      "given": "500 messages published in a burst",
+      "when": "the consumer processes them under the real-account probe",
+      "then": "in-flight count never exceeds 250; the breach mutation FAILS naming the observed peak",
+      "testable": true,
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-3002-messaging-queue-cloudflare-consumer-registration",
+        "field": "interfaces.createConsumer"
+      },
+      "disposition": "template"
     }
   ],
-  "tacIds": ["TAC-3001-messaging-queue-cloudflare-producer-facade", "TAC-3002-messaging-queue-cloudflare-consumer-registration"],
+  "tacIds": [
+    "TAC-3001-messaging-queue-cloudflare-producer-facade",
+    "TAC-3002-messaging-queue-cloudflare-consumer-registration"
+  ],
   "createdAt": "2026-09-06T21:00:00.000Z",
-  "updatedAt": "2026-09-06T21:00:00.000Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/messaging-queue-cloudflare/docs/topics.md

@@ -56,7 +56,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 29101-29108 sit at the LOW end of the 29101-29899 band on purpose (watchpost run-4 lesson). A project-side story mechanically derived from a messaging-queue-cloudflare REQ id into the number 29110 would collide against a shipped US-29110; band headroom (29109-29899) leaves that space.
+US 29101-29108 sit at the LOW end of the 29101-29899 band on purpose. A project-side story mechanically derived from a messaging-queue-cloudflare REQ id into the number 29110 would collide against a shipped US-29110; band headroom (29109-29899) leaves that space.
 
 ADR/TAC suffixes for this blueprint use the 3001-3099 block, continuing the shelf pattern.
 
@@ -64,8 +64,8 @@ ADR/TAC suffixes for this blueprint use the 3001-3099 block, continuing the shel
 
 - Reuse `deliverySemantics` exactly as spelled here when your blueprint holds an opinion on the delivery-guarantee contract for the primary worklist queue; contribute your own scope:global ADR on that string and let composition surface the pairing.
 - A future exactly-once, at-most-once, or `messaging-queue-postgres` sibling mints on demand; each claims `deliverySemantics` and conflicts by design.
-- `jobs-background` (round-5 track T-4) reads the `queue` capability declared on `blueprint.json` per section 6a of `blueprint-authoring.md` to obtain the producer facade at apply time via the T-5 visual-round capability-declaration mechanism.
+- `jobs-background` (round-5 sibling on the jobs track) reads the `queue` capability declared on `blueprint.json` per section 6a of `blueprint-authoring.md` to obtain the producer facade at apply time via the visual-round capability-declaration mechanism.
 
 ## Deliberate-conflict statement
 
-This blueprint's ADR-3002 on `deliverySemantics` is a first shipped answer to a topic that will conflict, by design, with future exactly-once or at-most-once siblings, and with the reserved `messaging-queue-postgres` sibling (Baz decision 7). Applying `messaging-queue-cloudflare` alongside a hypothetical `messaging-queue-postgres` raises one `globalAdrTopic` conflict the operator resolves via one of the four documented resolutions per topic (adopt one, keep the existing one, author a project-level supersede ADR, or `--resolve <topic>=project:<ADR-id>` on the add).
+This blueprint's ADR-3002 on `deliverySemantics` is a first shipped answer to a topic that will conflict, by design, with future exactly-once or at-most-once siblings, and with the reserved `messaging-queue-postgres` sibling (sibling reservation). Applying `messaging-queue-cloudflare` alongside a hypothetical `messaging-queue-postgres` raises one `globalAdrTopic` conflict the operator resolves via one of the four documented resolutions per topic (adopt one, keep the existing one, author a project-level supersede ADR, or `--resolve <topic>=project:<ADR-id>` on the add).

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

@@ -6,7 +6,7 @@ A directed producer-to-consumer worklist queue on Cloudflare Queues: publish, co
 
 Four lifecycle events fire on the injected event sink with a rigid metadata-only whitelist (`event`, `ts`, `messageId`, `queueName`, `attempts`); consumer logging cannot leak object body bytes, header values, consumer-context fields or PII from the message body. The whitelist is enforced in code by the sink adapter (`event-sink.mjs`), not just documented.
 
-The reserved sibling `messaging-queue-postgres` (Baz decision 7, deferred v1.0.0 pending demand) mints on demand and conflicts by design on `deliverySemantics` with this blueprint; the operator picks one queue backend per project via a project-level ADR.
+The reserved sibling `messaging-queue-postgres` (sibling reservation, deferred v1.0.0 pending demand) mints on demand and conflicts by design on `deliverySemantics` with this blueprint; the operator picks one queue backend per project via a project-level ADR.
 
 ## Apply this blueprint
 
@@ -39,12 +39,14 @@ const { id } = await producer.publish({ userId: '42', action: 'sendConfirmation'
 
 // publish a batch
 await producer.publishBatch([
-  { body: { seq: 1 }, headers: { 'x-trace-id': 't-1' } },
-  { body: { seq: 2 }, headers: { 'x-trace-id': 't-2' } },
+  { body: { seq: 1 }, headers: { 'x-trace-id': 'trace-order-1001' } },
+  { body: { seq: 2 }, headers: { 'x-trace-id': 'trace-order-1002' } },
 ]);
 ```
 
-The facade is the sole holder of the queue binding reference per REQ-001. A call site that reaches into `env.<binding>.send()` directly is refused at author-side review.
+The `x-trace-id` header and the publish and publishBatch verbs are owned at `TAC-3001.interfaces[2].description`; the values above are illustrative.
+
+The facade is the sole holder of the queue binding reference per REQ-001. A call site that reaches into `env.<binding>.send()` directly is refused at the author-side check.
 
 ## Consumer registration shape
 
@@ -89,7 +91,7 @@ Miniflare (`https://developers.cloudflare.com/workers/testing/miniflare/`, fetch
 
 ## Real-account smoke section
 
-`node ../../../../blueprints/messaging-queue-cloudflare/contributions/probes/run-real-account-concurrency-smoke.mjs` is the accountBound probe. Without `CI_HAS_CLOUDFLARE_ACCOUNT` it exits 0 with `accountBoundSkipped: true` per spec section 3.5 and the per-blueprint report reads `aggregateVerdict: pass`. With `CI_HAS_CLOUDFLARE_ACCOUNT=1` plus credentials for the shared HQ queue `rcf-lite-ci-queue-smoke` (Q2 default) wired via `security-secrets-management`, a live-account run is queued as a v1.0.0 follow-up: the run itself rides `deploy-cloudflare-workers`' surface (not a Node probe module) since Cloudflare Queues does not support `wrangler dev --remote`, and the v1.0.0 probe stops short of driving deployment machinery.
+`node ../../../../blueprints/messaging-queue-cloudflare/contributions/probes/run-real-account-concurrency-smoke.mjs` is the accountBound probe. Without `CI_HAS_CLOUDFLARE_ACCOUNT` it exits 0 with `accountBoundSkipped: true` per spec section 3.5 and the per-blueprint report reads `aggregateVerdict: pass`. With `CI_HAS_CLOUDFLARE_ACCOUNT=1` plus credentials for the shared CI queue `rcf-lite-ci-queue-smoke` (Q2 default) wired via `security-secrets-management`, a live-account run is queued as a v1.0.0 follow-up: the run itself rides `deploy-cloudflare-workers`' surface (not a Node probe module) since Cloudflare Queues does not support `wrangler dev --remote`, and the v1.0.0 probe stops short of driving deployment machinery.
 
 ## Retry and DLQ discipline
 
@@ -101,7 +103,7 @@ ADR-3004 sets `max_batch_size` to 10 (ceiling 100) and `max_batch_timeout` to 5
 
 ## Composition with jobs-background
 
-`jobs-background` (round-5 track T-4) declares `requiresAppliedCapabilities: ["queue"]`; applying `jobs-background` on a project that already applied `messaging-queue-cloudflare` gets the T-4 apply-time capability check to pass with the `queue` capability discovered on the applied manifest. The T-4 blueprint enqueues jobs through the producer facade this blueprint exposes; the retry-and-DLQ trajectory is what turns transient job failures into eventual success and permanent failures into a DLQ receipt.
+`jobs-background` (round-5 sibling on the jobs track) declares `requiresAppliedCapabilities: ["queue"]`; applying `jobs-background` on a project that already applied `messaging-queue-cloudflare` gets the apply-time capability check to pass with the `queue` capability discovered on the applied manifest. The jobs-background blueprint enqueues jobs through the producer facade this blueprint exposes; the retry-and-DLQ trajectory is what turns transient job failures into eventual success and permanent failures into a DLQ receipt.
 
 ## What this blueprint does not do