rcf-lite 0.26.0 → 0.27.0

package/blueprints/email-smtp-resend/contributions/user-stories/email-smtp-resend-us-4102.json

@@ -2,7 +2,7 @@
   "usId": "email-smtp-resend-US-4102",
   "prdId": "PRD-001",
   "reqId": "email-smtp-resend-REQ-003",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "approved",
   "title": "The provider's unverified-sender refusal maps to a stable error code and does not leak the recipient",
   "asA": "operator running a deployed project where the sender domain has not yet been verified with the provider",
@@ -11,12 +11,17 @@
   "acceptanceCriteria": [
     {
       "id": "AC-4102-1",
-      "description": "When the provider refuses the submission because the sender domain or address is unverified, the adapter returns `{ ok: false, providerStatus, providerMessageId: null, error }` with `error` beginning with the code `RESEND_SENDER_UNVERIFIED` and `providerStatus` equal to the provider's own refusal status.",
+      "description": "When the provider refuses the submission because the sender domain or address is unverified, the adapter returns the refusal outcome owned on TAC-401-email-smtp-resend-send-adapter.interfaces.send with the `RESEND_SENDER_UNVERIFIED` code from the classification owned on TAC-401-email-smtp-resend-send-adapter.responsibilities[3].",
       "given": "a running project whose configured from-address is not verified with the provider",
-      "when": "the magic-link route calls `adapter.send({ to, subject, textBody, htmlBody })`",
-      "then": "the returned object matches the shape with `ok === false`, `providerMessageId === null`, `providerStatus` a positive integer, and `error` starting with `RESEND_SENDER_UNVERIFIED`",
+      "when": "the magic-link route calls the adapter's send interface defined on `TAC-401-email-smtp-resend-send-adapter.interfaces.send`",
+      "then": "the returned object matches the refusal shape owned on TAC-401-email-smtp-resend-send-adapter.interfaces.send and its `error` begins with `RESEND_SENDER_UNVERIFIED`",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-401-email-smtp-resend-send-adapter",
+        "field": "interfaces.send"
+      }
     },
     {
       "id": "AC-4102-2",
@@ -25,12 +30,27 @@
       "when": "the magic-link route calls `adapter.send({ to: distinctiveRecipient, subject: distinctiveSubject, textBody: distinctiveBody, htmlBody })` and the call resolves",
       "then": "the returned `error` string, every line the adapter emitted during the call, and every exception message caught contain none of the distinctive recipient, subject, or body substrings",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-4102-3",
+      "description": "The unverified-sender refusal maps to RESEND_SENDER_UNVERIFIED and does not surface the recipient identity: a probe of the returned error record shows only the stable code, the (redacted) provider response code and the sender placeholder reference; the recipient email is not on the error record even at debug level.",
+      "given": "a send with an unverified sender configured and a recipient \"recipient@example.test\" and a caller reading the error record",
+      "when": "the send() rejects",
+      "then": "the error carries code=RESEND_SENDER_UNVERIFIED and no field or nested field contains the string \"recipient@example.test\"; the sender placeholder reference name is present but the recipient email is not",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-401-email-smtp-resend-send-adapter",
+        "field": "responsibilities[5]"
+      }
     }
   ],
   "tacIds": [
     "TAC-401-email-smtp-resend-send-adapter"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/email-smtp-resend/contributions/user-stories/email-smtp-resend-us-4103.json

@@ -16,7 +16,8 @@
       "when": "the magic-link route triggers one adapter send",
       "then": "the submission counter after the adapter returns equals `1 + observed_retries`, `observed_retries` is at least one and at most the configured budget, and the returned object has `ok === true`",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-4103-2",
@@ -25,7 +26,8 @@
       "when": "the magic-link route triggers one adapter send",
       "then": "the adapter returns once, `ok === false`, `error` starts with `RESEND_RATE_LIMITED`, and the SMTP submission counter equals 3",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-4103-3",
@@ -34,12 +36,55 @@
       "when": "the magic-link route triggers one adapter send",
       "then": "the submission counter equals 1 and the returned object has `ok === false` with `error` starting with the terminal class code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-4103-4",
+      "description": "A generic transport failure (a TCP reset, a DNS resolution error, an SMTP handshake timeout) is classified as retryable per REQ-003; the adapter retries up to the bounded attempt count, and on eventual success within the attempt budget resolves with the message envelope id returned by Resend.",
+      "given": "a send call to the adapter with the SMTP client forced to reject on the first attempt with ECONNRESET and accept on the second attempt with envelope id \"smtp-envelope-777\"",
+      "when": "the caller invokes send()",
+      "then": "send() resolves with envelope id \"smtp-envelope-777\"; the adapter records exactly two attempts on the internal counter; no RESEND_TRANSPORT_ERROR is returned to the caller",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-401-email-smtp-resend-send-adapter",
+        "field": "responsibilities[5]"
+      }
+    },
+    {
+      "id": "AC-4103-5",
+      "description": "A generic transport failure that persists across the full attempt budget rejects with RESEND_TRANSPORT_ERROR naming the final transport class and the final attempt count (two per ADR-402); the caller sees no fabricated success envelope.",
+      "given": "a send call with the SMTP client forced to reject on every attempt with ECONNRESET",
+      "when": "the caller invokes send()",
+      "then": "send() rejects with RESEND_TRANSPORT_ERROR naming ECONNRESET and attemptCount 2; no envelope id is returned",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-401-email-smtp-resend-send-adapter",
+        "field": "responsibilities[5]"
+      }
+    },
+    {
+      "id": "AC-4103-6",
+      "description": "A provider 5xx response (a Resend server-side error) is classified as retryable per REQ-003 and REQ-004; the adapter retries with exponential full-jitter backoff and asserts that the scheduled delay before attempt 2 lies in [0, 250] milliseconds (base 250ms, first attempt) and before attempt 3 (if reached in a longer budget) would lie in [0, 500] milliseconds (2x base, capped at 8000ms). Template values the applying agent sets: The applying agent supplies the deterministic jitter source and clock; the AC substitutes the ADR-402 baseline retry parameters (base, cap, attempts).",
+      "given": "a send call with a deterministic jitter source (jitter() -> 0.5) and a deterministic clock, the SMTP client forced to return 5xx on every attempt, and the ADR-402 baseline (2 attempts, base 250ms, cap 8000ms, exponential full-jitter)",
+      "when": "the caller invokes send()",
+      "then": "the adapter schedules exactly one retry; the delay before the retry equals 125ms (0.5 * 250 * 1); send() rejects with RESEND_TRANSPORT_ERROR naming the provider 5xx and attemptCount 2; no delay exceeds 8000ms and no delay is negative",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "adrId": "ADR-402-email-smtp-resend-retry-and-backoff-posture",
+        "field": "decision.retryBackoff"
+      }
     }
   ],
   "tacIds": [
     "TAC-401-email-smtp-resend-send-adapter"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/email-smtp-resend/contributions/user-stories/email-smtp-resend-us-4104.json

@@ -16,7 +16,8 @@
       "when": "the POST is delivered to the webhook route",
       "then": "the response status is 200, the handler invocation counter increments by exactly one, and the parsed event delivered to the handler matches the POST body",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-4104-2",
@@ -25,7 +26,8 @@
       "when": "the POST is delivered to the webhook route",
       "then": "the response status is 401, the response body is empty, the handler invocation counter is unchanged, and the audit sink observes exactly one `webhookVerificationFailed` event",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-4104-3",
@@ -34,7 +36,8 @@
       "when": "a mix of matched and mismatched webhook posts is delivered",
       "then": "no captured response body, log line, or exception message contains the distinctive signing secret substring",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

package/blueprints/email-smtp-resend/contributions/user-stories/email-smtp-resend-us-4105.json

@@ -11,26 +11,42 @@
   "acceptanceCriteria": [
     {
       "id": "AC-4105-1",
-      "description": "A webhook POST whose timestamp header is older than the configured tolerance window is refused with HTTP 401 and an empty body; the downstream handler is not invoked and a `webhookReplayStale` audit event is emitted.",
+      "description": "A webhook POST whose timestamp header is older than the configured tolerance window is refused with HTTP 401 and an empty body; the downstream handler is not invoked and a `webhookReplayStale` audit event is emitted. Template values the applying agent sets: The applying agent sets the elicited replay tolerance window; the AC substitutes the project's window for the illustrative value.",
       "given": "a running project with a configured tolerance window of 300 seconds and a POST whose timestamp header is set to a value 301 or more seconds in the past",
       "when": "the POST is delivered to the webhook route",
       "then": "the response status is 401, the response body is empty, the handler invocation counter is unchanged, and the audit sink observes exactly one `webhookReplayStale` event",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-4105-2",
-      "description": "A signature-valid webhook POST whose delivery event id already appears in the bounded event-id store is acknowledged with HTTP 200 without invoking the downstream handler; a `webhookReplayDuplicate` audit event is emitted.",
+      "description": "A signature-valid webhook POST whose delivery event id already appears in the bounded event-id store is acknowledged with HTTP 200 without invoking the downstream handler; a `webhookReplayDuplicate` audit event is emitted. Template values the applying agent sets: The applying agent sets the elicited replay tolerance window; the AC substitutes the project's window for the illustrative value.",
       "given": "a running project with a signature-valid POST that has already been processed once (event id recorded in the store) and a second POST carrying the same event id inside the tolerance window",
       "when": "the second POST is delivered to the webhook route",
       "then": "the response status is 200, the handler invocation counter is unchanged from before the second POST, and the audit sink observes exactly one `webhookReplayDuplicate` event on the second POST",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-4105-3",
+      "description": "On accepting a delivery event, the verifier calls putIfAbsentWithExpiry(eventId, expiryMs) with expiryMs equal to the configured replay tolerance window; a re-post of the same event id BEFORE the window expires is refused as a duplicate; a re-post of the same event id AFTER the window expires is accepted normally. Template values the applying agent sets: The applying agent supplies the elicited replay tolerance window; the AC substitutes it for the illustrative 300000ms value.",
+      "given": "a webhook verifier configured with tolerance window 300000ms (5 minutes), a deterministic clock, and a first event with id \"evt-42\" accepted at T0",
+      "when": "the same event id is re-posted at T0+150000ms (inside window) and again at T0+400000ms (after window)",
+      "then": "the first re-post is refused with EVENT_REPLAY_DUPLICATE; the second re-post is accepted normally; the eventIdStore's putIfAbsentWithExpiry recorded expiryMs=300000 for the initial entry",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-402-email-smtp-resend-webhook-verifier",
+        "field": "interfaces.eventIdStore"
+      }
     }
   ],
   "tacIds": [
     "TAC-402-email-smtp-resend-webhook-verifier"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/email-smtp-resend/contributions/user-stories/email-smtp-resend-us-4106.json

@@ -16,16 +16,36 @@
       "when": "an import-graph scan enumerates every module of the application that imports the SMTP client library",
       "then": "the scan returns exactly one module and that module is the adapter module",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-4106-2",
-      "description": "The adapter resolves the SMTP username, the SMTP password, the from-address, and the webhook signing secret through the project's configured secret-reference resolver (a Secrets Manager client, a project-authored resolver, or an environment shim); no literal for any of the four values appears in the adapter's own source.",
-      "given": "the adapter module source and the four configuration references `RESEND_SMTP_USER`, `RESEND_SMTP_PASSWORD`, `RESEND_FROM_ADDRESS`, `RESEND_WEBHOOK_SIGNING_SECRET`",
-      "when": "the adapter source is scanned for literals and the reference names are cross-checked against the resolver invocation shape",
-      "then": "the source contains no literal for any of the four values, and each of the four reference names appears exactly at the resolver invocation site the adapter calls at boot",
+      "description": "The send adapter (TAC-401) resolves the SMTP host, username, password and the from-address through the project's configured secret-reference resolver at boot; no literal for any of these four values appears in the send adapter's own source. Template values the applying agent sets: The applying agent sets the four placeholder references (RESEND_SMTP_HOST, RESEND_SMTP_USERNAME, RESEND_SMTP_PASSWORD, RESEND_VERIFIED_SENDER_ADDRESS) on the elicited slots; the AC substitutes those names.",
+      "given": "the send-adapter module source and the four configuration references RESEND_SMTP_HOST, RESEND_SMTP_USERNAME, RESEND_SMTP_PASSWORD, RESEND_VERIFIED_SENDER_ADDRESS",
+      "when": "the send adapter source is scanned for literals and the reference names are cross-checked against the resolver invocation shape at TAC-401.responsibilities[8]",
+      "then": "the send adapter source contains no literal for any of the four values, and each of the four reference names appears exactly at the resolver invocation site the send adapter calls at boot",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-401-email-smtp-resend-send-adapter",
+        "field": "interfaces.secretResolver"
+      }
+    },
+    {
+      "id": "AC-4106-3",
+      "description": "The webhook verifier (TAC-402) resolves the webhook signing secret through the project's configured secret-reference resolver at boot; no literal for the webhook secret appears in the verifier's own source. The send adapter does not carry the webhook secret. Template values the applying agent sets: The applying agent sets the RESEND_WEBHOOK_SIGNING_SECRET placeholder reference on the verifier's elicited slot; the AC substitutes that name.",
+      "given": "the webhook-verifier module source and the reference RESEND_WEBHOOK_SIGNING_SECRET",
+      "when": "the verifier source is scanned for literals and the reference name is cross-checked against the resolver invocation shape at TAC-402.responsibilities[5]; the send adapter's source is scanned to confirm the webhook secret name does NOT appear there",
+      "then": "the verifier source contains no literal for the webhook secret, RESEND_WEBHOOK_SIGNING_SECRET appears exactly at the verifier's resolver invocation site, and the send adapter's source does not reference RESEND_WEBHOOK_SIGNING_SECRET at all",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-402-email-smtp-resend-webhook-verifier",
+        "field": "interfaces.secretResolver"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +53,5 @@
     "TAC-402-email-smtp-resend-webhook-verifier"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/email-smtp-resend/guide/email-smtp-resend.md

@@ -48,8 +48,8 @@ An earlier design pass considered leading with the Resend HTTP API as the defaul
 
 A project applies the magic-link blueprint, applies this blueprint, wires the adapter reference into the auth routes at composition time, sources `RESEND_SMTP_USER`, `RESEND_SMTP_PASSWORD`, `RESEND_FROM_ADDRESS`, and `RESEND_WEBHOOK_SIGNING_SECRET` through the project's secret resolver (the shipped `security-secrets-management` client, a project-authored resolver, or an environment shim), completes Resend's sender-domain verification, and lands on a deployed application where:
 
-- The magic-link mint step calls the adapter and observes `{ ok: true, providerStatus: 202, providerMessageId: '<vendor-id>', error: null }` on the successful path; exactly one SMTP submission goes out per call.
-- An unverified-sender configuration surfaces immediately as `{ ok: false, error: 'RESEND_SENDER_UNVERIFIED: ...' }`; no recipient identity appears on any log line the adapter emits or on any error string it returns.
+- The magic-link mint step calls the adapter and observes the success outcome owned on `TAC-401-email-smtp-resend-send-adapter.interfaces.send` on the successful path; exactly one SMTP submission goes out per call.
+- An unverified-sender configuration surfaces immediately as the refusal outcome owned on `TAC-401-email-smtp-resend-send-adapter.interfaces.send`, with the `RESEND_SENDER_UNVERIFIED` code from the classification owned on responsibilities[3]; no recipient identity appears on any log line the adapter emits or on any error string it returns.
 - A rate-limit refusal converts to a bounded delay (jittered exponential backoff, default 2 retries, cap 8000ms per attempt) rather than a retry storm; the caller sees one adapter return.
 - The webhook route accepts only signature-passing requests; a mismatched signature returns HTTP 401 with an empty body and emits a `webhookVerificationFailed` audit event; a stale-timestamp request is refused with `webhookReplayStale`; a duplicate delivery id inside the tolerance window is acknowledged HTTP 200 without re-invoking the downstream handler and emits `webhookReplayDuplicate`.
 - A source-tree import-graph scan of the deployed application finds the SMTP client library imported from exactly one module (the adapter); a source-scan of the adapter finds no literal for the SMTP credential, the from-address, or the signing secret.

package/blueprints/jobs-background/CHANGELOG.md

@@ -1,16 +1,40 @@
+# Changelog
+
+## 1.1.4 - 2026-09-10
+
+Register cleanup on shipped prose: neutral wording in README, `jobs-background-REQ-001.description`, `ADR-3103.consequences` and `TAC-3101.dependencies[2].description` with no capability change. README opening now names the applied-capability mechanism directly. REQ-001 states the exit-code and stable-message-id assertions in neutral form. ADR-3103 describes the sidecar-note construction in plain external terms without the internal repo-path reference. TAC-3101 reads "via the applied-capability mechanism". REQ-001, ADR-3103 and TAC-3101 patch-bumped. Anatomy pin updated to 1.1.4. Chain-consistency lint zero on pass 1 and pass 2. Closes criterion-f findings 3, 4, 5 and 7 for jobs-background; findings 2 and 6 were already closed on origin/main.
+
+## 1.1.3 - 2026-09-10
+
+Second closure fix on the dimension-d ownership sweep for REQ-002: migrated every reference from the intermediary `TAC-3101.responsibilities[0]` to the true owner `TAC-3101.interfaces.jobModule.default`. Removed the five-field shape restatement from `TAC-3101.purpose`, `AC-30102-1` (description and then-clause), the README table row for REQ-002, the "What this gives you" bullet, and the guide's "Writing a job" intro; each surface now points at the owner. The guide's demonstrative code sample remains as usage-demonstration below a one-line owner pointer. Anatomy pin updated to 1.1.3. TAC-3101, REQ-002 and US-30102 patch-bumped. Chain-consistency lint zero on pass 1 and pass 2. Third-pass residues cleared without a further bump: the US-30102 title and the guide's "What does NOT change" bullet now reference the owner instead of restating the five-field shape.
+
+## 1.1.2 - 2026-09-10
+
+Dimension-d single-definition-ownership cleanup on REQ-002: REQ description now references the job-definition module shape owned on TAC-3101.interfaces.jobModule.default rather than restating the exported field-name shape. Chain-consistency lint zero on pass 1 and pass 2.
+
+## 1.1.1 (register-sweep patch, 2026-09-10)
+
+- Register: neutral wording in shipped prose (no capability change).
+
+## 1.1.0 - 2026-09-09
+
+Adds the elicits block (jobs-directory, scheduler-mode, max-attempts, retry-backoff, handler-timeout-seconds, operator-surface) that the REQs and guide were already describing in prose. Adds a runtime clause naming the backgroundJobs applied capability on REQ-002. Adds deliveredBy on REQ-001 (pointing at ADR-3103 for the refusalMessageId decision), REQ-002 and REQ-004. Adds disposition to every AC.
+
 # jobs-background changelog
 
 ## 1.0.0 - 2026-09-06
 
-Initial release. Background-jobs discipline over an applied `queue` capability, with a job-definition contract, a POSIX-cron plus one-shot-delayed scheduler, a retry contract that inherits the applied queue's max-attempts ceiling, and a metadata-only run-log event stream at four moments. Composes on the T-5 capability-consumer mechanism from the visual round; refuses apply on a bare project with exit 3 and the stable message id `jobs-background-no-queue` per Baz decision 5. Landed via the infra round 5 spec (ratified 2026-09-06) as track T-4, chained after T-3 `messaging-queue-cloudflare` v1.0.0.
+Initial release. Background-jobs discipline over an applied `queue` capability, with a job-definition contract, a POSIX-cron plus one-shot-delayed scheduler, a retry contract that inherits the applied queue's max-attempts ceiling, and a metadata-only run-log event stream at four moments. Composes on the capability-consumer mechanism from the visual round; refuses apply on a bare project with exit 3 and the stable message id `jobs-background-no-queue` per maintainer decision. Landed via the infra round 5 spec (ratified 2026-09-06), chained after `messaging-queue-cloudflare` v1.0.0 as the applied queue capability.
 
 - 22 contributions: 6 REQs on `requiresAppliedCapabilities: [queue]` / job-definition / scheduler / retry / run-log / operator-facing surface; 9 USs at 30101-30109 (one per REQ plus three cross-cutting cases: apply-time refusal, scheduled fire on cron, retry-then-DLQ); 3 TACs (3101 job-definition module, 3102 scheduler, 3103 run-log event sink); 4 ADRs (3101 `scope: global` on new topic `backgroundJobModel` retry-and-schedule as the shipped shape, 3102 scheduler mode elicited across `inProcess` / `workerCron` / `external` with reserved v1.1.0 `workflows` slot per section 5.7 of the spec, 3103 requires `capabilities: ["queue"]` with `allowSkipFlag: "allow-no-queue-yet"` and refusal message id `jobs-background-no-queue`, 3104 default handler timeout 60 seconds floor 1 second ceiling bounded by the applied queue's consumer wall-clock which for Cloudflare Queues is 15 minutes per the fetched limits doc).
-- Five Node-only probes under `contributions/probes/` proven against the T-3 in-memory queue-driver seam and a fake-clock scheduler seam (SDR-3-a on US-29107 accepts the in-memory realisation of the Cloudflare Queues binding shape as the shipped local seam): `apply-time-refusal`, `apply-time-override`, `fake-clock-cron`, `retry-and-fail`, `event-secrecy`. All five carry `accountBound: false`; the live `wrangler dev` cron-trigger path is documented as a per-AC mechanism-reach gap in the fixture README per round-3 checklist 6.g.
-- T-4 slice of the shared sample-app fixture at `packages/rcf-lite/test/fixtures/infra-s3-and-queue/` adds a `jobs/` directory carrying two toy job-definition modules (`send-welcome-email.mjs` with `retryPolicy: { maxAttempts: 3, backoff: exponential }` and `timeoutMs: 60000`; `refresh-cache.mjs` with `retryPolicy: { maxAttempts: 5, backoff: constant }`, `timeoutMs: 10000`, `cron: '* * * * *'`), `src/jobs-runtime.mjs` realising the runtime, `src/scheduler.mjs` realising the `inProcess` scheduler with a fake-clock seam, and `src/job-run-log.mjs` realising the T-4-owned event sink (whitelist `event, jobId, jobName, attempts, duration, timestamp` plus optional `terminalErrorCode`). Two wired induced-failure switches (`SIMULATE_HANDLER_THROW`, `SIMULATE_PII_IN_JOB_INPUT`) drive the retry-and-fail and event-secrecy probe negative-run paths.
-- Declares `capabilities: ["backgroundJobs"]`, `suggestedCompanions: [{role: "logging"}, {role: "errorHandling"}]`, `providesRoles` absent, `requiresAppliedCapabilities: { capabilities: ["queue"], allowSkipFlag: "allow-no-queue-yet", refusalMessageId: "jobs-background-no-queue" }`. The T-3 `messaging-queue-cloudflare` v1.0.0 is the shipped provider of the `queue` capability.
-- Contributes ADR-3101 as `scope: global` on new topic `backgroundJobModel`. Future stateful-workflow siblings (Temporal-shape, Airflow-shape) will conflict here by design; the reserved round-6 Workflows adapter (per Baz section 5.7) lives INSIDE this blueprint as a v1.1.0 minor scheduler-mode value at ADR-3102, not as a sibling.
-- Every ADR contribution entry on `blueprint.json` carries a `standardsTraceClause` per section 8a.2 (mandatory per HQ mid-flight ruling after PR #154 gate).
+- Five Node-only probes under `contributions/probes/` proven against the in-memory queue-driver seam and a fake-clock scheduler seam (SDR-3-a on US-29107 accepts the in-memory realisation of the Cloudflare Queues binding shape as the shipped local seam): `apply-time-refusal`, `apply-time-override`, `fake-clock-cron`, `retry-and-fail`, `event-secrecy`. All five carry `accountBound: false`; the live `wrangler dev` cron-trigger path is documented as a per-AC mechanism-reach gap in the fixture README per round-3 checklist 6.g.
+- The jobs-background slice of the shared sample-app fixture at `packages/rcf-lite/test/fixtures/infra-s3-and-queue/` adds a `jobs/` directory carrying two toy job-definition modules (`send-welcome-email.mjs` with `retryPolicy: { maxAttempts: 3, backoff: exponential }` and `timeoutMs: 60000`; `refresh-cache.mjs` with `retryPolicy: { maxAttempts: 5, backoff: constant }`, `timeoutMs: 10000`, `cron: '* * * * *'`), `src/jobs-runtime.mjs` realising the runtime, `src/scheduler.mjs` realising the `inProcess` scheduler with a fake-clock seam, and `src/job-run-log.mjs` realising the jobs-background-owned event sink (whitelist `event, jobId, jobName, attempts, duration, timestamp` plus optional `terminalErrorCode`). Two wired induced-failure switches (`SIMULATE_HANDLER_THROW`, `SIMULATE_PII_IN_JOB_INPUT`) drive the retry-and-fail and event-secrecy probe negative-run paths.
+- Declares `capabilities: ["backgroundJobs"]`, `suggestedCompanions: [{role: "logging"}, {role: "errorHandling"}]`, `providesRoles` absent, `requiresAppliedCapabilities: { capabilities: ["queue"], allowSkipFlag: "allow-no-queue-yet", refusalMessageId: "jobs-background-no-queue" }`. The `messaging-queue-cloudflare` v1.0.0 is the shipped provider of the `queue` capability.
+- Contributes ADR-3101 as `scope: global` on new topic `backgroundJobModel`. Future stateful-workflow siblings (Temporal-shape, Airflow-shape) will conflict here by design; the reserved round-6 Workflows adapter (per spec section 5.7) lives INSIDE this blueprint as a v1.1.0 minor scheduler-mode value at ADR-3102, not as a sibling.
+- Every ADR contribution entry on `blueprint.json` carries a `standardsTraceClause` per section 8a.2 (mandatory per the operator estate mid-flight ruling after PR #154 gate).
 - Extends `packages/rcf-lite/docs/blueprint-authoring.md` section 6a capability-declaration table with one row for `backgroundJobs` naming the reserved stateful-workflow sibling posture per spec section 5.6.
 - Extends `packages/rcf-lite/src/cli/blueprint.js` OPTION_SPEC with `--allow-no-queue-yet` boolean flag piped into `allowNoAuthYet` alongside `--allow-no-auth-yet` and `--allow-no-secrets-yet`, and `packages/rcf-lite/src/blueprint/apply.js` `buildOverrideNote` family derivation to detect `queue` from the flag name so the sidecar notes read "no queue yet: applied under --allow-no-queue-yet" instead of "no auth yet".
 - Extends `packages/rcf-lite/test/blueprint/capabilities-apply.test.js` with four cases covering the queue-capability path end to end: bare-project refusal with tag and provider-name assertions, `--allow-no-queue-yet` override with queue-family sidecar-note assertion, happy path with `messaging-queue-cloudflare` applied producing `appliedCapabilities` including `queue`, and backward-compatible `--allow-no-auth-yet` also unblocks the override.
 - Reserved v1.1.0 minor: adds `scheduler: "workflows"` mode under ADR-3102 wrapping the same job-definition contract with Cloudflare Workflows `step.do` orchestration per section 5.7 of the spec and the fetched Workflows documentation.
+
+Review-fix (2026-09-09): Adds two option-binding ACs on scheduler-mode (AC-30103-3 workerCron, AC-30103-4 external) to close section 7c on the elicits catalogue. Adds four failure-path ACs walking the guide - retryPolicy.maxAttempts above the applied queue ceiling (AC-30102-3), and effective-delay per backoff shape with the 10-minute cap: exponential (AC-30104-3), constant (AC-30104-4), linear (AC-30104-5). Adds deliveredBy on REQ-003, REQ-005, REQ-006.

package/blueprints/jobs-background/README.md

@@ -1,12 +1,12 @@
 # jobs-background v1.0.0
 
-Background-jobs discipline over an applied `queue` capability. Ships a job-definition contract, a POSIX-cron plus one-shot-delayed scheduler, a retry contract that inherits the applied queue's max-attempts ceiling, and a metadata-only run-log event stream at four moments. Composes on the T-5 capability-consumer mechanism from the visual round; refuses apply on a bare project with exit 3 and the stable message id `jobs-background-no-queue` per Baz decision 5 on the ratified round-5 spec.
+Background-jobs discipline over an applied `queue` capability. Ships a job-definition contract, a POSIX-cron plus one-shot-delayed scheduler, a retry contract that inherits the applied queue's max-attempts ceiling, and a metadata-only run-log event stream at four moments. Composes on the applied-capability mechanism; refuses apply on a bare project with exit 3 and the stable message id `jobs-background-no-queue`.
 
 ## What this gives you
 
-- A job-definition module shape you export from `./jobs/*.mjs`: `{ name, handler, inputSchema, retryPolicy, timeoutMs }`.
+- A job-definition module shape you export from `./jobs/*.mjs`, owned on TAC-3101-jobs-background-job-definition.interfaces.jobModule.default; the shape's fields are the ones the owner names.
 - A scheduler with POSIX cron and one-shot-delayed shapes, elicited across `inProcess` (a Node long-lived process), `workerCron` (Cloudflare Cron Triggers) and `external` (a Kubernetes CronJob, a systemd timer, GitHub Actions schedule). A `workflows` mode is reserved for the v1.1.0 minor per section 5.7 of the spec.
-- A retry contract that inherits the applied queue's max-attempts ceiling (Cloudflare Queues at 100 per the T-3 messaging-queue-cloudflare ADR-3003) and expresses the elicited backoff shape (`exponential`, `constant`, `linear`).
+- A retry contract that inherits the applied queue's max-attempts ceiling (Cloudflare Queues at 100 per the messaging-queue-cloudflare ADR-3003) and expresses the elicited backoff shape (`exponential`, `constant`, `linear`).
 - A metadata-only run-log at four moments (`jobScheduled`, `jobStarted`, `jobCompleted`, `jobFailed`). Record whitelist: `{ jobId, jobName, attempts, duration, timestamp }` plus optional `terminalErrorCode`. No job input, no handler output, no user id, no email, no SSN, ever.
 - An operator-facing surface elicited across `cli`, `httpEndpoint`, or `none`. The blueprint ships the contract; the applying project builds the thin shim.
 
@@ -15,7 +15,7 @@ Background-jobs discipline over an applied `queue` capability. Ships a job-defin
 | REQ | Contract |
 |---|---|
 | `jobs-background-REQ-001` | Requires an applied `queue` capability; refuses apply on a bare project with exit 3 and the stable message id `jobs-background-no-queue`. |
-| `jobs-background-REQ-002` | Job-definition contract: name, handler, input schema (opaque per project), retry policy, timeout. |
+| `jobs-background-REQ-002` | Job-definition contract: shape owned on `TAC-3101-jobs-background-job-definition.interfaces.jobModule.default`. |
 | `jobs-background-REQ-003` | Scheduler contract: POSIX cron string and one-shot delayed. |
 | `jobs-background-REQ-004` | Retry contract: handler throws retryable error re-delivers via the applied queue; max-attempts elicited within the applied queue's own ceiling. |
 | `jobs-background-REQ-005` | Job-run event log: `jobScheduled`, `jobStarted`, `jobCompleted`, `jobFailed`; metadata-only whitelist. |
@@ -35,7 +35,7 @@ Background-jobs discipline over an applied `queue` capability. Ships a job-defin
 
 Apply refuses on a bare project (no applied blueprint declares `capabilities: ["queue"]`) with exit 3 and the stable first-line tag `[jobs-background-no-queue]`. The refusal message explicitly names `messaging-queue-cloudflare` as the shipped provider and `--allow-no-queue-yet` as the override.
 
-The `--allow-no-queue-yet` override records a note on the sidecar `rcf/blueprints/jobs-background.applied.json` (`notes: "no queue yet: applied under --allow-no-queue-yet; surfaces gated on queue will refuse at runtime until a queue blueprint is applied."`). Note: the spec section 5.4 prose reference to `manifest.blueprints[jobs-background].source.notes` is superseded by the shipped T-5 mechanism which writes the note on the sidecar because the applied-blueprint-record schema in rcf-schemas 0.6.1 is closed and cannot carry a `notes` field. `rcf define validate` reads the sidecar to flag surfaces that never activated.
+The `--allow-no-queue-yet` override records a note on the sidecar `rcf/blueprints/jobs-background.applied.json` (`notes: "no queue yet: applied under --allow-no-queue-yet; surfaces gated on queue will refuse at runtime until a queue blueprint is applied."`). Note: the spec section 5.4 prose reference to `manifest.blueprints[jobs-background].source.notes` is superseded by the shipped mechanism which writes the note on the sidecar because the applied-blueprint-record schema in rcf-schemas 0.6.1 is closed and cannot carry a `notes` field. `rcf define validate` reads the sidecar to flag surfaces that never activated.
 
 ## Scheduler mode ADR (ADR-3102)
 
@@ -70,7 +70,7 @@ Each probe module lives under `contributions/probes/` and exports the spec secti
 
 ## Running the probes
 
-The probes drive against the shared sample-app fixture at `packages/rcf-lite/test/fixtures/infra-s3-and-queue/` (extended with `jobs/`, `src/jobs-runtime.mjs`, `src/scheduler.mjs`, `src/job-run-log.mjs`). No Docker, no `wrangler dev` process required; the T-3 in-memory queue-driver seam is the shipped local seam per SDR-3-a.
+The probes drive against the shared sample-app fixture at `packages/rcf-lite/test/fixtures/infra-s3-and-queue/` (extended with `jobs/`, `src/jobs-runtime.mjs`, `src/scheduler.mjs`, `src/job-run-log.mjs`). No Docker, no `wrangler dev` process required; the in-memory queue-driver seam is the shipped local seam per SDR-3-a.
 
 Two-line boot for the two headline probes:
 
@@ -94,8 +94,8 @@ The remaining three shims (`run-apply-time-override.mjs`, `run-retry-and-fail.mj
 
 - AC-jobs-requiresQueue: PROVEN via `apply-time-refusal.mjs` against a bare scratch project on the shipped head (exit code and message id assertions run in-process). No live-only gap.
 - AC-jobs-overrideRecorded: PROVEN via `apply-time-override.mjs` on the shipped head (sidecar note grep asserts `no queue yet`, `--allow-no-queue-yet`, and family word `queue`). No live-only gap.
-- AC-jobs-scheduledRunsOnCron: PROVEN via `fake-clock-cron.mjs` on the shipped head against the in-memory queue-driver seam plus the injected fake-clock scheduler seam. LIVE `wrangler dev` cron-trigger firing under `workerCron` scheduler mode is the HQ gate reviewer's follow-up run per SDR-3-a; the shipped local seam proves the scheduler and runtime dispatch chain without a Cloudflare Queues account.
-- AC-jobs-retryOnHandlerFailure: PROVEN via `retry-and-fail.mjs` on the shipped head (three `jobStarted` records at attempts 1, 2, 3 followed by terminal `jobFailed`). The in-memory queue-driver's re-delivery loop matches Cloudflare Queues' retry semantics per T-3's opaque-adapter clause; a live-account run against Cloudflare Queues is the T-3 real-account concurrency smoke's territory, not T-4's.
+- AC-jobs-scheduledRunsOnCron: PROVEN via `fake-clock-cron.mjs` on the shipped head against the in-memory queue-driver seam plus the injected fake-clock scheduler seam. LIVE `wrangler dev` cron-trigger firing under `workerCron` scheduler mode is the operator estate gate reviewer's follow-up run per SDR-3-a; the shipped local seam proves the scheduler and runtime dispatch chain without a Cloudflare Queues account.
+- AC-jobs-retryOnHandlerFailure: PROVEN via `retry-and-fail.mjs` on the shipped head (three `jobStarted` records at attempts 1, 2, 3 followed by terminal `jobFailed`). The in-memory queue-driver's re-delivery loop matches Cloudflare Queues' retry semantics per the messaging-queue-cloudflare opaque-adapter clause; a live-account run against Cloudflare Queues is the messaging-queue-cloudflare real-account concurrency smoke's territory, not this blueprint's.
 - AC-jobs-eventSecrecy: PROVEN via `event-secrecy.mjs` on the shipped head (grep on the serialised run-log stream returns zero matches for every PII fixture literal). No live-only gap; the whitelist enforcement lives in code, not in a runtime environment.
 - `workerCron` refuses on an applied queue with no cron surface: DOCUMENTED at ADR-3102 in this blueprint's contribution set; not exercised at v1.0.0 because the shipped provider (`messaging-queue-cloudflare` v1.0.0) does not itself claim a cron surface (the cron surface is Workers-side per Cloudflare Cron Triggers, not Queues-side). A follow-up train fires the refusal live once a `queue`-capability provider with a cron surface ships.
 - Reserved v1.1.0 `workflows` scheduler mode: DOCUMENTED at ADR-3102; the `fake-clock-cron.mjs` probe grows a `workflows-scheduler` variant when the v1.1.0 minor lands per section 5.7 of the spec.

package/blueprints/jobs-background/blueprint.json

@@ -1,6 +1,6 @@
 {
   "slug": "jobs-background",
-  "version": "1.0.0",
+  "version": "1.1.4",
   "category": "jobs",
   "capabilities": [
     "backgroundJobs"
@@ -135,7 +135,7 @@
       "path": "adrs/adr-3103-jobs-background-requires-applied-capabilities.json",
       "recommendedDefault": true,
       "elicited": false,
-      "standardsTraceClause": "visual round spec section 5.5.2 (the T-5 capability-consumer mechanism)"
+      "standardsTraceClause": "visual round spec section 5.5.2 (the capability-consumer mechanism)"
     },
     {
       "id": "ADR-3104-jobs-background-timeout-floor",
@@ -145,5 +145,58 @@
       "elicited": true,
       "standardsTraceClause": "Cloudflare Queues consumer wall-clock ceiling per platform limits doc"
     }
+  ],
+  "elicits": [
+    {
+      "id": "jobs-directory",
+      "prompt": "Directory holding one job-definition module per job. Each module default-exports the shape owned on TAC-3101-jobs-background-job-definition.interfaces.jobModule.default and registerJobs walks the directory. Default apps/*/src/jobs under the applying project root.",
+      "kind": "string",
+      "default": "src/jobs"
+    },
+    {
+      "id": "scheduler-mode",
+      "prompt": "Scheduler mode per ADR-3102. inProcess drives the scheduler from a long-lived process (setInterval or a cron library). workerCron uses the Cloudflare Workers cron trigger. external uses an operator-provided cron surface calling the runtime through a triggerJob verb. workflows is reserved for v1.1.0.",
+      "kind": "enum",
+      "options": [
+        "inProcess",
+        "workerCron",
+        "external"
+      ],
+      "default": "workerCron"
+    },
+    {
+      "id": "max-attempts",
+      "prompt": "Max delivery attempts per job. Elicited within the applied queue capability's own ceiling; refused when higher than that ceiling. Default 3.",
+      "kind": "string",
+      "default": "3"
+    },
+    {
+      "id": "retry-backoff",
+      "prompt": "Retry backoff shape on the job-definition retryPolicy: constant delay between attempts, exponential doubling, or linear increase. Applied within the queue-owned redelivery mechanism.",
+      "kind": "enum",
+      "options": [
+        "constant",
+        "exponential",
+        "linear"
+      ],
+      "default": "exponential"
+    },
+    {
+      "id": "handler-timeout-seconds",
+      "prompt": "Handler wall-clock timeout per ADR-3104. Default 60 seconds; floor 1 second; ceiling bounded by the applied queue's consumer wall-clock. A handler exceeding the timeout raises a retryable timeout error routed through the queue redelivery mechanism.",
+      "kind": "string",
+      "default": "60"
+    },
+    {
+      "id": "operator-surface",
+      "prompt": "Operator-facing surface for triggering ad-hoc runs, inspecting the run log, and re-driving a failed job. cli ships a Node command; httpEndpoint ships a bearer-guarded route wired through the applied HTTP surface; none omits the operator surface (the applying project provides its own).",
+      "kind": "enum",
+      "options": [
+        "cli",
+        "httpEndpoint",
+        "none"
+      ],
+      "default": "cli"
+    }
   ]
 }

package/blueprints/jobs-background/contributions/adrs/adr-3102-jobs-background-scheduler-mode.json

@@ -17,7 +17,7 @@
     {
       "name": "Ship the reserved workflows mode at v1.0.0",
       "summary": "Include the Cloudflare Workflows step.do orchestration inline in the v1.0.0 shipped shape.",
-      "reasonNotChosen": "The round-6 Workflows adapter is on Baz per section 5.7 of the spec; v1.0.0 keeps the mode ELICITED at three values and the v1.1.0 minor adds workflows as the fourth. No topic conflict, no facade re-shape."
+      "reasonNotChosen": "The round-6 Workflows adapter is on the project maintainer per section 5.7 of the spec; v1.0.0 keeps the mode ELICITED at three values and the v1.1.0 minor adds workflows as the fourth. No topic conflict, no facade re-shape."
     }
   ],
   "createdAt": "2026-09-06T20:30:00.000Z",

package/blueprints/jobs-background/contributions/adrs/adr-3103-jobs-background-requires-applied-capabilities.json

@@ -2,17 +2,17 @@
   "adrId": "ADR-3103-jobs-background-requires-applied-capabilities",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "accepted",
   "title": "Requires capabilities: [queue] with allowSkipFlag allow-no-queue-yet and refusalMessageId jobs-background-no-queue",
-  "context": "jobs-background composes on an applied queue capability. Applying on a bare project (no queue provider applied) has two possible shapes: refuse-with-message (the T-5 capability-consumer mechanism, ratified for application-admin-console and object-storage-s3), or silently apply with a stub queue (which would leave the applying project with an unactivated job dispatch surface). Baz decision 5 (verbatim): jobs requires an applied queue and refuses on a bare project, with an override flag.",
-  "decision": "The blueprint declares requiresAppliedCapabilities { capabilities: [queue], allowSkipFlag: allow-no-queue-yet, refusalMessageId: jobs-background-no-queue }. The apply verb refuses with exit 3 and the first-line stderr tag [jobs-background-no-queue] when no applied blueprint declares capabilities: [queue]. The refusal message names the shipped provider messaging-queue-cloudflare and the override flag --allow-no-queue-yet explicitly per Q3 default. The override writes a sidecar note under the queue family on rcf/blueprints/jobs-background.applied.json so rcf define validate later flags surfaces that never activated. Because the applied-blueprint-record schema in rcf-schemas 0.6.1 is closed, the note lives on the sidecar (rcf/blueprints/<slug>.applied.json), not on manifest.blueprints[].source.notes; the shipped T-5 mechanism (T-2 precedent for object-storage-s3) is the source of truth for that placement.",
-  "consequences": "The applying project's apply-time behaviour is predictable: refuse on bare, override-with-note or apply-with-queue. Standards trace clause: visual round spec section 5.5.2 (the T-5 capability-consumer mechanism). Dashboards and lints bind to the stable message id jobs-background-no-queue. The queue-family family derivation in the sidecar-notes construction (packages/rcf-lite/src/blueprint/apply.js buildOverrideNote) is extended to detect queue from the flag name so the note reads 'no queue yet' (not 'no auth yet' or 'no secrets-management yet').",
+  "context": "jobs-background composes on an applied queue capability. Applying on a bare project (no queue provider applied) has two possible shapes: refuse-with-message (the capability-consumer mechanism, ratified for application-admin-console and object-storage-s3), or silently apply with a stub queue (which would leave the applying project with an unactivated job dispatch surface). maintainer decision (verbatim): jobs requires an applied queue and refuses on a bare project, with an override flag.",
+  "decision": "The blueprint declares requiresAppliedCapabilities { capabilities: [queue], allowSkipFlag: allow-no-queue-yet, refusalMessageId: jobs-background-no-queue }. The apply verb refuses with exit 3 and the first-line stderr tag [jobs-background-no-queue] when no applied blueprint declares capabilities: [queue]. The refusal message names the shipped provider messaging-queue-cloudflare and the override flag --allow-no-queue-yet explicitly per Q3 default. The override writes a sidecar note under the queue family on rcf/blueprints/jobs-background.applied.json so rcf define validate later flags surfaces that never activated. Because the applied-blueprint-record schema in rcf-schemas 0.6.1 is closed, the note lives on the sidecar (rcf/blueprints/<slug>.applied.json), not on manifest.blueprints[].source.notes; the shipped mechanism (earlier precedent for object-storage-s3) is the source of truth for that placement.",
+  "consequences": "The applying project's apply-time behaviour is predictable: refuse on bare, override-with-note, or apply-with-queue. Dashboards and lints bind to the stable message id jobs-background-no-queue. The sidecar-notes construction detects queue from the flag name so the note reads 'no queue yet' rather than 'no auth yet' or 'no secrets-management yet'.",
   "alternativesConsidered": [
     {
       "name": "Silently apply on a bare project with a stub queue",
       "summary": "Ship a no-op in-memory queue as the default when no queue capability is applied.",
-      "reasonNotChosen": "A silent stub loses the observability the T-5 mechanism gives; a project would ship jobs against a no-op queue without realising it. Baz decision 5 (verbatim) forecloses this."
+      "reasonNotChosen": "A silent stub loses the observability the mechanism gives; a project would ship jobs against a no-op queue without realising it. maintainer decision (verbatim) forecloses this."
     },
     {
       "name": "Refuse on a bare project without an override flag",
@@ -21,5 +21,5 @@
     }
   ],
   "createdAt": "2026-09-06T20:30:00.000Z",
-  "updatedAt": "2026-09-06T20:30:00.000Z"
+  "updatedAt": "2026-09-10T00:00:00.000Z"
 }

package/blueprints/jobs-background/contributions/probes/fake-clock-cron.mjs

@@ -2,7 +2,7 @@
  * Fake-clock cron probe.
  *
  * Drives the fixture scheduler (inProcess mode with the fake-clock seam)
- * plus the T-3 in-memory queue seam plus the T-4 jobs-runtime through
+ * plus the in-memory queue seam plus the jobs-runtime through
  * one POSIX cron minute for the refresh-cache job. Asserts a jobStarted
  * event fires on the injected run-log sink within the elicited
  * fireToleranceMs window (default 30000 ms) with jobName 'refresh-cache'

package/blueprints/jobs-background/contributions/probes/probe-utils.mjs

@@ -2,13 +2,13 @@
  * Shared helpers for jobs-background probes.
  *
  * Runtime-dependency posture: probes import the fixture's in-memory
- * queue-driver plus the T-4 jobs-runtime, scheduler and run-log from the
+ * queue-driver plus the jobs-runtime, scheduler and run-log from the
  * sample-app fixture's src/ tree so rcf-lite itself gains no new runtime
- * dependency (round-5 spec section 5, brief section 4). The T-3
+ * dependency (round-5 spec section 5, brief section 4). The
  * in-memory queue-driver realises the Cloudflare Queues binding shape;
- * the T-4 jobs-runtime consumes messages from the driver, dispatches to
+ * the jobs-runtime consumes messages from the driver, dispatches to
  * job-definition modules, and fires the four lifecycle events on the
- * T-4-owned run-log sink (whitelist { event, jobId, jobName, attempts,
+ * jobs-background-owned run-log sink (whitelist { event, jobId, jobName, attempts,
  * duration, timestamp } plus optional terminalErrorCode).
  */
 

package/blueprints/jobs-background/contributions/requirements/jobs-background-req-001.json

@@ -2,7 +2,7 @@
   "reqId": "jobs-background-REQ-001",
   "prdId": "PRD-001",
   "title": "Requires an applied queue capability; refuses apply on a bare project with exit 3 and the stable message id jobs-background-no-queue",
-  "description": "The jobs-background blueprint composes on an applied queue capability via the T-5 mechanism from the visual round. The apply verb refuses on a bare project (no applied blueprint declares capabilities: [queue]) with exit code 3 and a stable, dashboard-friendly message id jobs-background-no-queue on the first stderr line. The refusal message also names the shipped provider messaging-queue-cloudflare and the override flag --allow-no-queue-yet explicitly, per infra round 5 spec section 10 Q3 default asserting BOTH exit code AND stable message id. The override flag records a note on the sidecar rcf/blueprints/jobs-background.applied.json under the queue family so rcf define validate later flags surfaces gated on queue that never activated.",
+  "description": "The jobs-background blueprint composes on an applied queue capability via the applied-capability mechanism. The apply verb refuses on a bare project (no applied blueprint declares capabilities: [queue]) with exit code 3 and a stable, dashboard-friendly message id jobs-background-no-queue on the first stderr line. The refusal message also names the shipped provider messaging-queue-cloudflare and the override flag --allow-no-queue-yet explicitly, asserting both the exit code and the stable message id. The override flag records a note on the sidecar rcf/blueprints/jobs-background.applied.json under the queue family so rcf define validate later flags surfaces gated on queue that never activated.",
   "category": "functional",
   "domain": "jobs",
   "priority": "must",
@@ -11,8 +11,12 @@
     "blueprint:jobs-background",
     "category:00-composition"
   ],
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "approved",
   "createdAt": "2026-09-06T20:30:00.000Z",
-  "updatedAt": "2026-09-06T20:30:00.000Z"
+  "updatedAt": "2026-09-10T00:00:00.000Z",
+  "deliveredBy": {
+    "adrId": "ADR-3103-jobs-background-requires-applied-capabilities",
+    "field": "decision.refusalMessageId"
+  }
 }