rcf-lite 0.26.0 → 0.28.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/docs/topics.md

@@ -10,7 +10,7 @@ The neutrality rule (round-2 amendment) applies: `email-smtp-resend` ships alone
 
 ## Id number bands (registry bootstrap)
 
-AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands.
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is policy; this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands.
 
 This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
 
@@ -55,8 +55,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 4101-4106 sit at the LOW end of the 4101-4899 band on purpose. A project-side story that mechanically derives from an email-smtp-resend REQ id into the number `4106` (leading `4` + sequence `106`) would collide against email-smtp-resend-US-4106 in this package; the band leaves headroom at the HIGH end (US 4181-4899) so a project's own stories anchored to email-smtp-resend REQs can allocate without conflict. The watchpost run4 lesson applies here too.
-
+US 4101-4106 sit at the LOW end of the 4101-4899 band on purpose. A project-side story that mechanically derives from an email-smtp-resend REQ id into the number `4106` (leading `4` + sequence `106`) would collide against email-smtp-resend-US-4106 in this package; the band leaves headroom at the HIGH end (US 4181-4899) so a project's own stories anchored to email-smtp-resend REQs can allocate without conflict.
 ## Shared expectations for future composing blueprints
 
 - The mail-adapter contract itself is owned by the magic-link blueprint's `TAC-504-security-auth-magic-link-email-delivery-adapter`, not by this blueprint. A sibling `email-smtp-<othervendor>` blueprint that plugs into the same slot inherits the four-class error taxonomy (`RESEND_*` codes generalise to a `<VENDOR>_*` prefix on the sibling; the class semantics stay the same), the retry-and-backoff posture (ADR-402 is a supersede target), and the webhook signature-and-replay discipline (the header names, the algorithm identifier, and the tolerance window remain configuration references; the vendor's specifics live on the sibling's own `docs/topics.md`).

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,101 @@
+# Changelog
+
+## 1.1.10 - 2026-09-12
+
+The AC-30109-1 counting-row `detail` now opens with the first eight words of the AC's `description` text ("The retry-and-fail probe's report, after the three failing") before naming the observation, so the row is textually attached to its anchor AC. The record was regenerated verbatim against the shipped in-memory fixture. Anatomy pin bumped to 1.1.10.
+
+- fix: `blueprints/jobs-background/contributions/probes/retry-and-fail.mjs` AC-30109-1 row `detail` (both `pass` and `fail` verdict branches) opens with the first eight words of the AC's `description`, then names the observation.
+
+## 1.1.9 - 2026-09-12
+
+AC-30109-1 is now observed locally (`dlqInvoked:true`); `STRICT_ID_KEYS` is tightened to engine-returned scalars only; the anatomy comment is aligned with the in-memory validation the predicate enforces. Anatomy pin bumped to 1.1.9.
+
+- fix: `packages/rcf-lite/test/fixtures/infra-s3-and-queue/src/jobs-runtime.mjs` terminal-failure branch now routes the message to the driver's DLQ producer path (`msg.retry()` on an already-terminal attempt increments attempts past `maxRetries` so the driver pushes the entry to `state.dlq`). The earlier behaviour ack'd terminally failing messages, which silently discarded the failing job.
+- fix: `blueprints/jobs-background/contributions/probes/retry-and-fail.mjs` adds a second row anchored to AC-30109-1 that asserts `dlqInvoked:true` after the three failing jobStarted events and the terminal jobFailed event. The row carries the scheduler-minted `jobId` as its scalar id witness alongside `attemptsSequence` as derived.
+- fix: `packages/rcf-lite/test/blueprint/jobs-background-anatomy.test.js` STRICT_ID_KEYS removed the plural / probe-selected keys (`requestIds`, `vendorRequestIds`, `metadataRequestId`, `httpRequestId`, `observedUploadId`, `dlqTransportMessageIds`, `primaryTransportMessageId`, `jobIds`, `dlqPayloadJobIds`, `expectedPayloadJobId`) so only engine-returned scalar identifiers qualify as id-witnesses.
+- prose: anatomy header comment corrected to describe the in-memory validation the anatomy performs (probes invoked directly; no `.rcf/reports` record read on this seam).
+
+
+## 1.1.8 - 2026-09-11
+
+Engine-returned identifiers only, plus non-"true" gate-skip parseability. The jobs-background anatomy `STRICT_ID_KEYS` retains engine-returned scalars only, the anatomy enforces distinct `idWitness` / `derivedWitness` keys, and the non-"true" gate-skip reason on `retry-and-fail-real-account` is emitted in the `<VAR> (not "true")` shape the anatomy parses to the same bare env-var name as `<VAR> unset`. Pre-condition failure branches on `apply-time-override` and `apply-time-refusal` are `conformanceOnly` (they fire before any job or message id is minted). A negative unit test in the anatomy proves both skip shapes parse to the bare env-var name and rejects malformed shapes. Anatomy pin bumped to 1.1.8.
+
+- fix: `blueprints/jobs-background/contributions/probes/retry-and-fail-real-account.mjs` line 104 now emits `skipRow('CI_HAS_CLOUDFLARE_ACCOUNT (not "true")')` when the gate variable is set to a non-"true" value, matching the shape the anatomy strips via `/ unset$| \(not "true"\)$/`.
+- fix: `packages/rcf-lite/test/blueprint/jobs-background-anatomy.test.js` STRICT_ID_KEYS retains engine-returned scalars only (`requestId`, `eTag`, `versionId`, `uploadId`, `queueId`, `messageId`, `jobId`, `rowId`, `insertedId`, `backendPid`, `transactionId`, `migrationVersion` and their labelled siblings). `bucketName`, `scratchBucket`, `queueName`, `databaseName` and the checksum keys were removed. Same-file strict-AND now asserts idWitness and derivedWitness sit under DIFFERENT keys.
+- fix: `apply-time-override` and `apply-time-refusal` pre-condition failure branches (rcf init / apply failing before the runtime probe path) are declaimed to `conformanceOnly` with a limitation naming the runtime AC and why no engine-minted id exists on this row.
+- add: `packages/rcf-lite/test/blueprint/jobs-background-anatomy.test.js` carries a negative unit test that constructs the `<VAR> unset` and `<VAR> (not "true")` shapes and asserts both parse to the same bare env-var name; malformed shapes such as `<VAR> set to "1" (not "true")` are rejected.
+- prose: run-notes reworded to state engine-returned-only identifiers where relevant.
+
+
+
+## 1.1.7 - 2026-09-11
+
+The probe owns its skip, the anatomy invokes every probe unconditionally, and the anatomy-only `RCF_ANATOMY_RUN_PROBES` gate is retired. The jobs-background anatomy test removes the outer gate, invokes each probe directly, and validates whatever comes back: local probes (`apply-time-refusal`, `apply-time-override`, `fake-clock-cron`, `retry-and-fail`, `event-secrecy`) drive the in-memory queue driver and the rcf-lite CLI on scratch dirs and produce real evidence rows; the live probe (`retry-and-fail-real-account`) returns its own exact one-variable `accountBoundSkipped` row when `CF_API_BASE` or an account variable is unset. Anatomy pin bumped to 1.1.7.
+
+- fix: `RCF_ANATOMY_RUN_PROBES` outer gate retired from the jobs anatomy test; the probe owns its skip.
+- fix: fake-clock-cron rows carry a scalar `jobId` (from the jobStarted / jobScheduled event) so the strict AND-witness check sees a real engine-minted id alongside the derived counters.
+- fix: retry-and-fail row carries a scalar `jobId` (the first observed jobStarted event); the distinct-jobId list moves to `distinctJobIdList` (a non-id key).
+- fix: event-secrecy row carries a scalar `jobId` (from the first event on the run-log stream) alongside the whitelist and leaked-literal derived witnesses.
+- fix: apply-time-refusal and apply-time-override rows are honestly de-claimed to `conformanceOnly` against their real ACs (AC-jobs-requiresQueue and AC-jobs-overrideRecorded): compose-time refusal and sidecar-notes properties are observed by CLI exit code and stderr/notes grep, not by a minted engine id.
+- fix: anatomy identifier predicate is string-only and non-empty; booleans, numbers, arrays and objects never satisfy an engine-minted id key.
+- fix: anatomy limitation-token regex broadened to `AC-[A-Za-z0-9-]+` so every AC token is checked for membership in the shipped user-story AC set.
+
+
+## 1.1.6 - 2026-09-11
+
+Strict-anatomy rewrite of the 7d witness rules. The anatomy test now REQUIRES an AC-id-membership check on every limitation and every notObservableHere.ac against the shipped user-story set (numeric AC-30xxx-x and labelled AC-jobs-* both accepted), REQUIRES both an id-shape witness AND a derived-value witness on every non-declaimed row (strict AND, never OR), invokes every probe directly and validates each returned row in-memory, and requires accountBoundSkipped rows to name exactly one env var declared on the probe DECLARED_ENV list. Anatomy pin bumped to 1.1.6.
+
+- fix: fake-clock-cron probe row 0 now carries `fireEventCount` and `firePresent` alongside `fires`/`cron`; row 1 carries `jobStartedTimestamp` and `jobStartedAttempts` alongside `jobStartedEvent`; row 2 carries `jobCompletedDurationMs` and `jobCompletedTimestamp` alongside `jobCompletedEvent`. The `extra.engineNote` now honestly acknowledges that the paired real-account probe does NOT exercise cron and therefore does NOT supply cron-trigger evidence; live wrangler-dev cron-trigger firing under workerCron scheduler mode remains a per-AC mechanism-reach gap.
+- fix: retry-and-fail-real-account.mjs API base URL is now a required declared variable: `CF_API_BASE` is on `DECLARED_ENV` and the probe reads it directly with no literal endpoint host in source. When unset the probe records an exact one-variable skip on the row.
+- fix: run-notes correction so the queue-listing polls-taken count matches the record (pollsTaken=1).
+- register: neutral wording on the 1.0.0 and 1.1.5 entries (no capability change).
+
+## 1.1.5 - 2026-09-11
+
+Positive-evidence conformance work on the shared infra-s3-and-queue fixture (authoring standard section 7d), plus one live-engine run on Cloudflare Queues for the real-account probe. The infra-s3-and-queue fixture README gains a Declared env vars table for the jobs-background pack (naming the actual env reads on `src/producer.mjs`: `RCF_QUEUE_NAME`, `RCF_DLQ_NAME`, `RCF_MAX_RETRIES`, `RCF_BATCH_SIZE`, `RCF_BATCH_TIMEOUT_MS`, `WRANGLER_DEV_PORT`, plus the `SIMULATE_HANDLER_THROW` and `SIMULATE_PII_IN_JOB_INPUT` switches, and the new probe's `CI_HAS_CLOUDFLARE_ACCOUNT`, `CF_ACCOUNT_ID`, `CF_API_TOKEN` real-account gates); an off-table read is refused at gate. The five local probes execute against the in-memory queue-driver seam and fake-clock scheduler as shipped, producing rcf-lite bin exit codes, stable-message-id tags, sidecar contents, jobId-and-attempts trajectories, and a run-log grep-clean over the PII fixture literals as positive evidence. Anatomy pin extended to include the Declared env vars section on the fixture README, to derive the declared names from actual `process.env` and `env.` reads on producer.mjs AND the real-account probe (so table drift on either surface is caught statically), and to pin `fake-clock-cron` as a local-conformance probe.
+
+- fix: fixture Declared env vars table for the jobs-background pack replaces the legacy names `QUEUE_NAME`/`DLQ_NAME`/`QUEUE_MAX_RETRIES` (which the code does not read) with the actual `RCF_*` reads + `WRANGLER_DEV_PORT`; the anatomy test derives the expected env-var list from concrete `env.<NAME>` matches on both `packages/rcf-lite/test/fixtures/infra-s3-and-queue/src/producer.mjs` and the real-account probe source.
+- fix: fake-clock-cron probe records the scheduled-to-started latency (jobStarted timestamp minus jobScheduled timestamp) but does NOT assert a tolerance: the row is conformance-only (`anchorAcId: null`, limitation names AC-jobs-scheduledRunsOnCron and states that `scheduledAt` is `new Date().toISOString()` at publish time so the delta is a same-clock intra-runtime measurement, not a wall-clock cron-boundary comparison). The row no longer claims the paired real-account run provides cron-trigger coverage (the real-account run only drives Cloudflare Queues).
+- fix: probe results carry per-row `evidence` bags; `aggregate([])` returns `fail` with `no checks ran` instead of default-pass; the `runShim` also fails-with-no-checks-ran on a null/undefined probe return.
+- add: `retry-and-fail-real-account.mjs` (live-engine coverage) drives a scratch Cloudflare Queue and DLQ through the vendor's REST + `http_pull` consumer contract. Every non-skip row is conformance-only (`anchorAcId: null`) with a limitation naming the nearest shipped AC id and the property it states that this probe does not positively observe: the attempts-counter row cites AC-jobs-retryOnHandlerFailure (the AC states applied in-memory queue redelivery and jobStarted-on-sink events; the probe records the vendor Cloudflare Queues attempts counter [0,1,2,3] instead), the DLQ landing row cites AC-30109-1 (the AC pins the in-memory driver DLQ-producer invocation; the probe records real Cloudflare Queues DLQ landing), and the queue provisioning + teardown rows cite AC-jobs-requiresQueue as the nearest shipped AC. The row scope is the vendor queue transport (not the in-process jobs runtime; that surface is proven by `retry-and-fail.mjs`). Post-run absence is asserted only when the Queues listing returns HTTP 200 and json.success=true (an unsuccessful listing never normalises to an empty list). DLQ ack failures land on the teardown record and fail the teardown row. Both queues are destroyed on teardown and teardown is a result row (teardown FAIL fails the verdict).
+- fixture: `src/scheduler.mjs`'s `publishOne` records `scheduledAt` as `new Date().toISOString()` in the runtime's own time domain (matching the `Date.now()` domain the runtime stamps on `jobStarted`), and the fake clock still drives WHEN cron fires; `src/bucket-ops.mjs` added as a thin `@aws-sdk/client-s3` wrapper (see object-storage-s3 changelog); no new runtime dependencies land on rcf-lite or the fixture.
+- fix: fixture Declared env vars section headers name only the pack; supporting prose no longer carries internal provenance references.
+
+## 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
+
+Dimension-d ownership sweep for REQ-002 continued: 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 user-story-30102 patch-bumped. Chain-consistency lint zero on repeat invocation. Later residues cleared without a further bump: the user-story-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 composition guide; on a bare project with no applied `queue` capability, apply refuses with exit 3 and the stable message id `jobs-background-no-queue`. Chains 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 (user-story-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 the AC-mechanism-reach checklist item 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).
 - 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.
+
+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 the wrangler-dev-equivalent seam decision.
 
 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 gate reviewer's follow-up run per the wrangler-dev-equivalent seam decision; 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.10",
   "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,59 @@
       "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"
+    }
+  ],
+  "updatedAt": "2026-09-12"
 }

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",