rcf-lite 0.22.0 → 0.23.0

package/blueprints/deploy-cloudflare-workers/contributions/adrs/adr-1306-deploy-cloudflare-workers-spa-shape.json

@@ -0,0 +1,30 @@
+{
+  "adrId": "ADR-1306-deploy-cloudflare-workers-spa-shape",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.2.0",
+  "status": "accepted",
+  "title": "Workers-with-static-assets is the ratified SPA-on-Workers deploy shape; Pages is a documented alternative held for legacy projects only",
+  "context": "Cloudflare ships two shapes for browsing static assets in front of a Workers-tier deploy target: Cloudflare Pages (a workflow-shaped product with its own build pipeline and its own preview URL model) and Workers-with-static-assets (a wrangler.toml [assets] block declaring a directory the Cloudflare runtime serves at the edge). Cloudflare's own Pages landing page states, verbatim (fetched 2026-09-06): 'Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare's primary platform for building applications. Start new projects with Workers.' The prior v1.1.0 blueprint blessed neither shape as the default; v1.1.0 taught the wrangler [assets] block in an asset sample but left the shape choice implicit. The T-0 round bumps the blueprint to v1.2.0 to close the gap: a rcf-lite project choosing SPA-on-Workers gets a single, ratified wrangler shape rather than a hand-rolled convention, and the ratified shape follows Cloudflare's own recommendation for new projects.",
+  "decision": "The blueprint blesses Workers-with-static-assets as the ratified SPA-on-Workers deploy shape (recommendedDefault true for new SPA projects). A project answering the elicited assets-directory parameter with a non-empty path emits an [assets] block on wrangler.toml whose directory value carries the elicited path; a project answering with an empty path keeps the bare-Worker shape (no [assets] block). The elicited run-worker-first (boolean, default false) surfaces the SPA fallback discipline: truthy answers emit run_worker_first = true under the [assets] block; falsy or unanswered answers omit the field, letting Cloudflare's runtime run asset lookup before the Worker fetch handler. The blueprint does not mint a Cloudflare Pages blueprint; a future deploy-cloudflare-pages-legacy sibling mints on demand only if a project cannot make the jump. Every existing v1.1.0 contribution carries through unchanged.",
+  "consequences": "One ratified shape lands on the shelf for greenfield SPA-on-Workers projects; the shape's standards trace is the Cloudflare Pages landing-page recommendation (2026-09-06 snapshot). The two new elicits become part of the operator surface at blueprint add: assets-directory names the static-assets root, run-worker-first names the SPA fallback discipline. A project generating both an [assets] block and a Pages-only pages_build_output_dir field is a mixed-shape drift the T-0 probe (assets-manifest-scan.mjs) refuses. A project on the legacy Pages shape stays on v1.1.0 semantics until it migrates; the guide's new Workers-with-static-assets section links Cloudflare's migrate-from-Pages walkthrough for projects that choose to jump. Future round-6 blueprints (T-1 KV, T-2 cron, T-3 DO, T-4 Access, T-5 Turnstile, T-6 rate-limiting) all compose on this shape via the shared cf-platform sample-app fixture.",
+  "alternativesConsidered": [
+    {
+      "name": "Ship a Cloudflare Pages blueprint alongside deploy-cloudflare-workers",
+      "summary": "Mint a fresh deploy-cloudflare-pages blueprint that owns the Pages workflow surface (build pipeline, preview URLs, deploy hooks) and lets the operator pick shapes at apply.",
+      "reasonNotChosen": "Cloudflare's Pages landing page tells new projects to start with Workers. A Pages blueprint would ship a shape Cloudflare tells greenfield projects not to start. The maintenance load of a second deploy blueprint (its own ADRs, its own vendor URL trace, its own promote workflow) buys a shape Cloudflare itself recommends against; the round-6 spec (ruling 1) rejects the sibling and folds Workers-with-static-assets into this blueprint's minor bump instead."
+    },
+    {
+      "name": "Leave the shape choice implicit as the v1.1.0 blueprint does",
+      "summary": "Keep the wrangler-shape asset sample as an example only; do not mint an ADR blessing Workers-with-static-assets and do not elicit the assets-directory or run-worker-first parameters.",
+      "reasonNotChosen": "The v1.1.0 sample teaches the shape but does not commit to it; a project applying the blueprint has to reach for the sample and decide alone. Naming the ratified default as an ADR with a standards trace makes the shape decision legible in the applied project, and eliciting the two knobs surfaces the ratified shape's parameters where the operator can see them at apply."
+    },
+    {
+      "name": "Bless Workers-with-static-assets only through the guide, without an ADR contribution",
+      "summary": "Add the guide section but do not mint an ADR; keep the shape as prose guidance rather than an architected decision.",
+      "reasonNotChosen": "The standards-derived-discipline discipline (blueprint-authoring.md section 8a) requires an ADR with standardsTraceClause for any decision that traces to a vendor standard. Blessing the shape only in the guide leaves no traceable decision record and no place for a superseding project-level ADR to hang off. The blueprint's own trace mechanism is exactly this shape."
+    }
+  ],
+  "createdAt": "2026-09-07T00:00:00Z",
+  "updatedAt": "2026-09-07T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/probes/assets-manifest-scan.mjs

@@ -0,0 +1,207 @@
+// Source-tree scan probe for the deploy-cloudflare-workers v1.2.0
+// Workers-with-static-assets shape (T-0 of the Cloudflare round 6
+// spec, section 5.0). accountBound false: this probe reads the
+// applied fixture wrangler.toml and asserts three properties:
+//
+//   1. When the elicited assets-directory answer is non-empty, the
+//      [assets] table's directory field equals the elicited answer
+//      (assetsBlockEmitted, canonical AC-12113-1).
+//   2. When the elicited run-worker-first answer is truthy, the
+//      [assets] table carries run_worker_first equal to true; when
+//      falsy or unanswered, run_worker_first is absent
+//      (spaFallbackShape facet of AC-12113-1).
+//   3. The manifest never carries a Pages-only pages_build_output_dir
+//      field alongside [assets]; the two shapes are mutually
+//      exclusive per Cloudflare's static-assets doc.
+//
+// Verdict envelope per spec section 3.2: { verdict, detail,
+// anchorAcId, aggregateVerdict } where anchorAcId is
+// AC-12113-1 (the assetsBlockEmitted anchor). aggregateVerdict is
+// pass when every result is pass, warn when any is warn (unused
+// here), fail when any is fail. Cleans up any temporary files it
+// wrote on exit.
+
+import { readFile, writeFile, mkdir, rm } from 'node:fs/promises';
+import { dirname, resolve, join } from 'node:path';
+
+export const anchorAcId = 'AC-12113-1';
+export const accountBound = false;
+
+// Minimal wrangler.toml reader. Handles the small subset of TOML the
+// blueprint's manifest declares (top-level scalars, one [assets]
+// table, and boolean/string literals). Reaches for no runtime dep;
+// keeps the probe accountBound-false and dependency-free.
+export function parseWranglerToml(text) {
+  const lines = text.split(/\r?\n/);
+  const root = {};
+  let currentTable = root;
+  let currentTableName = '';
+  for (const raw of lines) {
+    const line = raw.replace(/^\s+/, '').replace(/\s+$/, '');
+    if (line === '' || line.startsWith('#')) continue;
+    const tableMatch = line.match(/^\[([A-Za-z0-9_.\-]+)\]$/);
+    if (tableMatch) {
+      currentTableName = tableMatch[1];
+      root[currentTableName] = root[currentTableName] || {};
+      currentTable = root[currentTableName];
+      continue;
+    }
+    const kv = line.match(/^([A-Za-z0-9_\-]+)\s*=\s*(.+)$/);
+    if (!kv) continue;
+    const key = kv[1];
+    let value = kv[2].trim();
+    // Strip trailing comments (a naive #-then-space split; sufficient
+    // for the wrangler shapes this blueprint generates).
+    const hashAt = value.indexOf(' #');
+    if (hashAt !== -1) value = value.slice(0, hashAt).trim();
+    if (value === 'true') {
+      currentTable[key] = true;
+    } else if (value === 'false') {
+      currentTable[key] = false;
+    } else if (/^-?\d+$/.test(value)) {
+      currentTable[key] = Number(value);
+    } else if (value.startsWith('"') && value.endsWith('"')) {
+      currentTable[key] = value.slice(1, -1);
+    } else if (value.startsWith("'") && value.endsWith("'")) {
+      currentTable[key] = value.slice(1, -1);
+    } else {
+      currentTable[key] = value;
+    }
+  }
+  return root;
+}
+
+// Drive the scan against the fixture. `opts.fixtureRoot` names the
+// directory the wrangler.toml lives in; `opts.elicited` names the
+// answers the fixture baked in (assets-directory string, run-worker-
+// first boolean). Optionally `opts.simulate` is one of
+// 'mixed-shape' or 'empty-assets': the caller rewrites wrangler.toml
+// in a scratch copy for the simulate branches so the base fixture
+// stays honest.
+export async function scan(opts) {
+  const fixtureRoot = opts.fixtureRoot;
+  const elicited = opts.elicited || {};
+  const manifestPath = opts.manifestPath || join(fixtureRoot, 'wrangler.toml');
+  const text = await readFile(manifestPath, 'utf8');
+  const parsed = parseWranglerToml(text);
+  const results = [];
+  const detail = {
+    manifestPath,
+    parsed,
+    elicited: {
+      assetsDirectory: elicited['assets-directory'] || '',
+      runWorkerFirst: elicited['run-worker-first'] === true,
+    },
+  };
+
+  const assets = parsed.assets || null;
+  const answered = detail.elicited.assetsDirectory !== '';
+  if (answered) {
+    if (!assets) {
+      results.push({
+        verdict: 'fail',
+        detail: 'assets table absent: elicited assets-directory is "' + detail.elicited.assetsDirectory + '" but wrangler.toml carries no [assets] block',
+        anchorAcId,
+      });
+    } else if (assets.directory !== detail.elicited.assetsDirectory) {
+      results.push({
+        verdict: 'fail',
+        detail: 'assets.directory mismatch: wrangler.toml carries directory=' + JSON.stringify(assets.directory) + ' but elicited answer is ' + JSON.stringify(detail.elicited.assetsDirectory),
+        anchorAcId,
+      });
+    } else {
+      results.push({
+        verdict: 'pass',
+        detail: 'assets.directory equals elicited assets-directory answer ' + JSON.stringify(assets.directory),
+        anchorAcId,
+      });
+    }
+    const runWorkerFirstOnManifest = assets && Object.prototype.hasOwnProperty.call(assets, 'run_worker_first');
+    if (detail.elicited.runWorkerFirst) {
+      if (!runWorkerFirstOnManifest || assets.run_worker_first !== true) {
+        results.push({
+          verdict: 'fail',
+          detail: 'run_worker_first mismatch: elicited answer is true but manifest carries ' + (runWorkerFirstOnManifest ? String(assets.run_worker_first) : 'no run_worker_first key'),
+          anchorAcId,
+        });
+      } else {
+        results.push({
+          verdict: 'pass',
+          detail: 'assets.run_worker_first equals true, matching the elicited run-worker-first answer',
+          anchorAcId,
+        });
+      }
+    } else {
+      if (runWorkerFirstOnManifest && assets.run_worker_first !== false) {
+        results.push({
+          verdict: 'fail',
+          detail: 'run_worker_first mismatch: elicited answer is falsy but manifest carries run_worker_first=' + JSON.stringify(assets.run_worker_first),
+          anchorAcId,
+        });
+      } else {
+        results.push({
+          verdict: 'pass',
+          detail: 'assets.run_worker_first is absent (or false), matching the falsy elicited run-worker-first answer',
+          anchorAcId,
+        });
+      }
+    }
+  } else {
+    if (assets) {
+      results.push({
+        verdict: 'fail',
+        detail: 'assets table present without an elicited assets-directory answer: bare-Worker shape expected, wrangler.toml carries [assets] block',
+        anchorAcId,
+      });
+    } else {
+      results.push({
+        verdict: 'pass',
+        detail: 'no [assets] block on wrangler.toml, matching the bare-Worker shape (assets-directory elicit unanswered)',
+        anchorAcId,
+      });
+    }
+  }
+
+  const pagesFieldAtRoot = Object.prototype.hasOwnProperty.call(parsed, 'pages_build_output_dir');
+  const pagesFieldUnderAssets = assets && Object.prototype.hasOwnProperty.call(assets, 'pages_build_output_dir');
+  if (pagesFieldAtRoot || pagesFieldUnderAssets) {
+    results.push({
+      verdict: 'fail',
+      detail: 'mixed-shape drift: wrangler.toml carries pages_build_output_dir (' + (pagesFieldAtRoot ? 'top-level' : 'inside [assets]') + ') alongside the Workers-with-static-assets shape; the two are mutually exclusive per Cloudflare static-assets doc',
+      anchorAcId,
+    });
+  } else {
+    results.push({
+      verdict: 'pass',
+      detail: 'no pages_build_output_dir field on wrangler.toml (Workers-with-static-assets shape is exclusive of the Pages shape)',
+      anchorAcId,
+    });
+  }
+
+  const aggregateVerdict = results.some((r) => r.verdict === 'fail')
+    ? 'fail'
+    : results.some((r) => r.verdict === 'warn')
+      ? 'warn'
+      : 'pass';
+
+  return { verdict: aggregateVerdict, aggregateVerdict, anchorAcId, results, detail };
+}
+
+// Convenience for the run-shim: write a report file next to a
+// project-relative .rcf/reports/ path. Creates the directory if it
+// does not exist; the shim removes any scratch file it wrote to
+// simulate the mixed-shape or empty-assets branch before exit.
+export async function writeReport(reportPath, report) {
+  await mkdir(dirname(reportPath), { recursive: true });
+  await writeFile(reportPath, JSON.stringify(report, null, 2) + '\n', 'utf8');
+}
+
+export async function removeIfExists(path) {
+  try {
+    await rm(path, { force: true });
+  } catch (_err) {
+    // Nothing to clean.
+  }
+}
+
+export default { scan, writeReport, removeIfExists, parseWranglerToml, anchorAcId, accountBound };

package/blueprints/deploy-cloudflare-workers/contributions/requirements/deploy-cloudflare-workers-req-013.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-013",
+  "prdId": "PRD-001",
+  "title": "Workers-with-static-assets shape: an [assets] directory declared under wrangler blesses static assets served by the Worker",
+  "description": "The blueprint blesses the Workers-with-static-assets deploy shape as the ratified SPA-on-Workers shape (per ADR-1306, quoting the Cloudflare Pages landing-page recommendation verbatim). A project answering the elicited `assets-directory` parameter with a non-empty path emits an `[assets]` block on `wrangler.toml` whose `directory` value carries the elicited path (for example `directory = \"./dist\"`). Cloudflare's Workers runtime serves files from that directory at the edge before the Worker fetch handler runs (unless `run_worker_first` is set truthy per REQ-014). A project answering with an empty path keeps the bare-Worker shape (no `[assets]` block, no static-asset lookup). The wrangler manifest MUST NOT carry any Pages-only field (`pages_build_output_dir`) alongside `[assets]`; the two shapes are mutually exclusive per Cloudflare's static-assets doc.",
+  "category": "technical",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "Cloudflare's own Pages landing page tells new projects to start with Workers; the Workers-with-static-assets shape is the primary SPA-on-Workers deploy shape. Blessing it here means a rcf-lite project choosing SPA-on-Workers gets a single, ratified wrangler shape rather than a hand-rolled convention. The mutual exclusion of `[assets]` and `pages_build_output_dir` keeps a project from silently drifting into a mixed-shape wrangler that Cloudflare's runtime refuses at deploy time.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:13-static-assets"
+  ],
+  "version": "1.2.0",
+  "status": "approved",
+  "createdAt": "2026-09-07T00:00:00Z",
+  "updatedAt": "2026-09-07T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/requirements/deploy-cloudflare-workers-req-014.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-014",
+  "prdId": "PRD-001",
+  "title": "SPA fallback discipline: run_worker_first flips the assets pipeline off the fetch handler's critical path",
+  "description": "The blueprint elicits `run-worker-first` (boolean, default false) alongside the `[assets] directory` shape from REQ-013. When the operator answers truthy, the generated wrangler manifest emits `run_worker_first = true` under the `[assets]` block: Cloudflare's runtime runs the Worker's fetch handler BEFORE looking up a static asset for the requested path. That is the shape a SPA-on-Workers project uses when the Worker owns arbitrary routing or when the Worker's auth middleware must gate every path a static file could shadow. When the operator answers falsy or leaves the elicit unanswered, `run_worker_first` is absent from the manifest and Cloudflare's runtime looks up a static asset first, falling back to the Worker only when no asset matches. The Worker code and the guide teach both shapes; the elicit surface is one boolean, the wrangler shape is one line.",
+  "category": "technical",
+  "domain": "deploy",
+  "priority": "should",
+  "rationale": "The default (asset lookup first, Worker on miss) is right for a static-content-heavy project. The truthy branch is what keeps auth middleware from being silently bypassed by an unauthenticated request for a file the assets pipeline serves from the edge cache. Naming the discipline as its own REQ makes the shape trade legible; anchoring the elicit to a wrangler line keeps the choice observable in the applied project.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:13-static-assets"
+  ],
+  "version": "1.2.0",
+  "status": "approved",
+  "createdAt": "2026-09-07T00:00:00Z",
+  "updatedAt": "2026-09-07T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/user-stories/deploy-cloudflare-workers-us-12113.json

@@ -0,0 +1,36 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12113",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-013",
+  "version": "1.2.0",
+  "status": "approved",
+  "title": "SPA-on-Workers deploy shape: [assets] block emitted with the elicited directory and the run_worker_first hint",
+  "asA": "operator deploying a SPA on Cloudflare Workers",
+  "iWant": "the generated wrangler.toml to carry an [assets] block whose directory matches my elicited answer and whose run_worker_first field carries my elicited SPA fallback choice",
+  "soThat": "my SPA-on-Workers project ships with a single, ratified wrangler shape and my static assets and my auth-gated routes both behave the way Cloudflare's runtime documents them",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12113-1",
+      "description": "Given the operator answers assets-directory with a non-empty path P at blueprint add, when the wrangler manifest generator emits wrangler.toml, then the manifest contains exactly one [assets] block whose directory field equals P (with the leading `./` preserved when the operator answered `./P`) and the manifest carries no pages_build_output_dir field. When the operator answers assets-directory with an empty string or leaves the elicit unanswered, the manifest carries no [assets] block and no pages_build_output_dir field. Anchored to TAC-1302-deploy-cloudflare-workers-wrangler-manifest; probed by assets-manifest-scan.mjs (source-tree scan against the applied fixture wrangler.toml) with anchorAcId AC-12113-1.",
+      "given": "an applied fixture whose operator answered assets-directory = ./dist at blueprint add",
+      "when": "the probe module assets-manifest-scan.mjs parses the fixture wrangler.toml",
+      "then": "the parsed structure contains an assets table whose directory string equals ./dist and no top-level pages_build_output_dir key; the probe returns verdict pass",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12113-2",
+      "description": "Given the operator answers run-worker-first with true alongside a non-empty assets-directory, when the manifest is generated, then the [assets] block carries run_worker_first = true. Given the operator answers run-worker-first with false or leaves it unanswered, when the manifest is generated, then the [assets] block does NOT carry a run_worker_first key (Cloudflare's runtime treats the absent field as the default asset-lookup-first shape). Anchored to TAC-1302; probed by assets-manifest-scan.mjs with anchorAcId AC-12113-1 (the same module surfaces both facets of the shape).",
+      "given": "an applied fixture whose operator answered assets-directory = ./dist and run-worker-first = true",
+      "when": "the probe module parses the fixture wrangler.toml",
+      "then": "the parsed [assets] table carries run_worker_first equal to true; when the fixture is switched with SIMULATE_EMPTY_ASSETS=true the run_worker_first field is absent (the whole [assets] block is absent) and the probe still returns verdict pass because the bare-Worker shape is legal",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1302-deploy-cloudflare-workers-wrangler-manifest"
+  ],
+  "createdAt": "2026-09-07T00:00:00Z",
+  "updatedAt": "2026-09-07T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/user-stories/deploy-cloudflare-workers-us-12114.json

@@ -0,0 +1,27 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12114",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-013",
+  "version": "1.2.0",
+  "status": "approved",
+  "title": "assets-directory elicitation: the operator picks the static-assets root at blueprint add",
+  "asA": "operator applying deploy-cloudflare-workers on a fresh project",
+  "iWant": "the blueprint to prompt me for the static-assets directory at blueprint add and remember my answer on my project's sidecar so re-apply picks it back up",
+  "soThat": "my wrangler.toml reflects my project's build output shape without me having to hand-edit the [assets] block",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12114-1",
+      "description": "The blueprint.json elicits[] block declares an entry with id assets-directory, kind string, default empty. The blueprint loader accepts the entry (validateElicits shape gate on src/blueprint/loader.js). The CLI accepts --answer assets-directory=<path> at blueprint add; the applied sidecar records the answered value on appliedElicitations.assets-directory. When the operator does not pass --answer assets-directory, the effective value is the empty-string default and the wrangler generator emits no [assets] block.",
+      "given": "a fresh rcf init scratch project after rcf define blueprint add ./blueprints/deploy-cloudflare-workers --answer assets-directory=./public --answer run-worker-first=false",
+      "when": "the applied sidecar records the operator's answers and a wrangler.toml is generated",
+      "then": "appliedElicitations.assets-directory equals ./public; the generated wrangler.toml carries [assets] directory = \"./public\" and no run_worker_first field; the manifest carries no pages_build_output_dir field",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1302-deploy-cloudflare-workers-wrangler-manifest"
+  ],
+  "createdAt": "2026-09-07T00:00:00Z",
+  "updatedAt": "2026-09-07T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/user-stories/deploy-cloudflare-workers-us-12115.json

@@ -0,0 +1,27 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12115",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-014",
+  "version": "1.2.0",
+  "status": "approved",
+  "title": "Migrate-from-Pages guidance: the guide links Cloudflare's own migrate-from-Pages walkthrough and pins the ratified shape choice",
+  "asA": "operator on a Cloudflare Pages project deciding whether to migrate",
+  "iWant": "the blueprint's guide to name the Workers-with-static-assets shape as the ratified default, quote Cloudflare's own landing-page recommendation verbatim, and link the migrate-from-Pages walkthrough Cloudflare publishes",
+  "soThat": "I can read the decision, the standards trace and the migration path in one place without stitching them together from three vendor pages",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12115-1",
+      "description": "The guide file blueprints/deploy-cloudflare-workers/guide/deploy-cloudflare-workers.md gains one new section titled Workers-with-static-assets: the SPA-on-Workers shape. The section carries the verbatim Cloudflare Pages landing-page quote (Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare's primary platform for building applications. Start new projects with Workers.), the two elicit signatures (assets-directory string default empty; run-worker-first boolean default false), a copy-paste wrangler.toml snippet showing the [assets] block with directory and the run_worker_first hint, and a link to the Cloudflare migrate-from-Pages guide at https://developers.cloudflare.com/workers/static-assets/migration-guides/migrate-from-pages/. The Cloudflare Workers static-assets doc at https://developers.cloudflare.com/workers/static-assets/ is cited in the same section. Both URLs return HTTP 200 at gate time.",
+      "given": "the updated guide file on the T-0 branch",
+      "when": "a reader opens the guide and grep locates the section heading, the verbatim quote and the two URLs",
+      "then": "the section heading appears once; the verbatim landing-page quote appears once; both Cloudflare URLs appear at least once each; a curl -fsSI on each URL returns HTTP 200",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": [
+    "TAC-1302-deploy-cloudflare-workers-wrangler-manifest"
+  ],
+  "createdAt": "2026-09-07T00:00:00Z",
+  "updatedAt": "2026-09-07T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/docs/topics.md

@@ -32,7 +32,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
 | security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
 | security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
-| deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.0.0 | `deploymentTarget` |
+| deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.2.0 | `deploymentTarget` |
 | persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
 | application-datatable | 17101-17899 | 18xx | shipped v1.0.0 | none |
@@ -47,6 +47,8 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
+| jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 
 US 12101-12112 sit at the LOW end of the 12101-12899 band on purpose. A project-side story that mechanically derives from a deploy-cloudflare-workers REQ id into the number `12112` would collide against deploy-cloudflare-workers-US-12112 in this package; the band leaves headroom at the HIGH end (US 12181-12899) so a project's own stories anchored to deploy-cloudflare-workers REQs can allocate without conflict. The watchpost run4 lesson applies here too. Band spacing between the last shipped block (security-secrets-management, 8101-8899, 9xx) and this one (12101-12899, 13xx) leaves the 9xxx-11xxx US bands and the 10xx-12xx suffix blocks open for concurrent-lane authoring so a peer authoring another blueprint in the same PR window does not collide with this one.
 

package/blueprints/deploy-cloudflare-workers/guide/deploy-cloudflare-workers.md

@@ -72,3 +72,28 @@ A project applies the blueprint on a fresh tree, declares its Worker in `wrangle
 ## Cost-honesty paragraph
 
 Shipping this doc set costs the project the following. Every ship to production is now a two-step act (merge to main, then an operator-triggered promote) instead of a single-step merge-to-production; the discipline is intentional and adds a small friction to prototype-shaped work where merge-to-production is fine. The default Cloudflare Workers vendor commits the project to an edge-runtime shape; a project whose runtime needs a long-lived process cannot use the default and has to supersede ADR-1302. The served-surface verifier fails CI on real drift; a project that wants faster promotes buys them by tightening the probe set or by accepting a larger risk of a failed promote, neither is free. The three URL kinds (per-version-id, stable alias, production) are three hostnames the project has to reason about; a project that would rather have one hostname loses the class of leaks-through-collapsed-URL the blueprint's ADR-1303 closes. The wrangler manifest becomes a piece of documentation the project maintains as part of its normal change flow; a project that would rather push deploy config into ad-hoc shell scripts loses the manifest's own validation gate. The deploy-log record is a stream the project now maintains; wiring it to a real sink (a status page, a SIEM, a data warehouse) is a project cost the blueprint does not carry. The blueprint says nothing about the vendor's own dashboard workflows, about DNS and TLS provisioning outside the vendor's own custom-hostname primitive, about compliance reporting on deploy events, or about staged canary or blue-green rollouts; a project that needs any of those spends its own build cycles on them and this blueprint does not save it any work there.
+
+## Workers-with-static-assets: the SPA-on-Workers shape
+
+Cloudflare's own Pages landing page states, verbatim (fetched 2026-09-06): "Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare's primary platform for building applications. Start new projects with Workers." The `deploy-cloudflare-workers` v1.2.0 bump follows the recommendation: new SPA-on-Workers projects apply this blueprint in the Workers-with-static-assets shape rather than reaching for Cloudflare Pages. `ADR-1306-deploy-cloudflare-workers-spa-shape` is the ratified decision and carries the verbatim quote on its body plus the standards trace on the contribution entry (`standardsTraceClause: Cloudflare Pages landing-page recommendation (2026-09-06)`). Cloudflare's Workers static-assets docs at `https://developers.cloudflare.com/workers/static-assets/` are the operational reference for the shape; the migrate-from-Pages walkthrough at `https://developers.cloudflare.com/workers/static-assets/migration-guides/migrate-from-pages/` is the path for a project on Pages that wants to jump.
+
+The bump adds two elicits on the top-level `elicits[]` block:
+
+- `assets-directory` (kind `string`, default empty): the path (relative to the Worker source root) whose files Cloudflare serves at the edge as static assets. An empty answer keeps the bare-Worker shape (no `[assets]` block on the generated `wrangler.toml`); a non-empty answer emits `[assets] directory = "<answered path>"`.
+- `run-worker-first` (kind `boolean`, default `false`): the SPA fallback discipline. A truthy answer emits `run_worker_first = true` under the `[assets]` block; a falsy or unanswered answer omits the field, leaving Cloudflare's runtime to serve a matching static asset before the Worker fetch handler runs. The elicit is only meaningful when `assets-directory` is non-empty (a Worker with no assets has nothing to serve first); the loader-side `when-elicitedNonEmpty` predicate the spec calls for is a mechanism follow-up, so the elicit fires unconditionally today.
+
+Copy-paste `wrangler.toml` snippet for the ratified shape:
+
+```
+name = "my-spa-worker"
+main = "src/index.mjs"
+compatibility_date = "2026-09-06"
+
+[assets]
+directory = "./dist"
+run_worker_first = true
+```
+
+The `[assets]` block and Pages' `pages_build_output_dir` field are mutually exclusive per Cloudflare's static-assets doc; the T-0 probe `assets-manifest-scan.mjs` (`accountBound: false`, `anchorAcId: AC-12113-1`) refuses on a manifest that carries both. A project on the bare-Worker shape (no static assets served at the edge) leaves both elicits unanswered and the probe reports the bare shape as passing.
+
+Migrating from Cloudflare Pages: read Cloudflare's own walkthrough at `https://developers.cloudflare.com/workers/static-assets/migration-guides/migrate-from-pages/`, apply this blueprint at v1.2.0 with `assets-directory` set to the build-output directory the Pages project pointed at (typically `./dist`, `./build`, or `./public`), pick `run-worker-first` per the project's routing shape, and drop the Pages workflow. The Workers-with-static-assets shape covers the SPA and API surfaces the Pages workflow covered; the promote and rollback verbs on this blueprint carry through unchanged.

package/blueprints/email-smtp-resend/docs/topics.md

@@ -43,6 +43,8 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
 | object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
+| jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 
 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.
 

package/blueprints/jobs-background/CHANGELOG.md

@@ -0,0 +1,16 @@
+# 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.
+
+- 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).
+- 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.

package/blueprints/jobs-background/README.md

@@ -0,0 +1,105 @@
+# 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.
+
+## What this gives you
+
+- A job-definition module shape you export from `./jobs/*.mjs`: `{ name, handler, inputSchema, retryPolicy, timeoutMs }`.
+- 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 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.
+
+## The six REQs
+
+| 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-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. |
+| `jobs-background-REQ-006` | Operator-facing surface (elicited): `cli`, `httpEndpoint`, or `none`. |
+
+## Capability composition
+
+`requiresAppliedCapabilities` on `blueprint.json`:
+
+```json
+{
+  "capabilities": ["queue"],
+  "allowSkipFlag": "allow-no-queue-yet",
+  "refusalMessageId": "jobs-background-no-queue"
+}
+```
+
+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.
+
+## Scheduler mode ADR (ADR-3102)
+
+Scheduler mode is elicited across three values at v1.0.0 and reserves a fourth for v1.1.0:
+
+- `inProcess`: a long-lived Node process holding `setInterval` per cron string and `setTimeout` per one-shot delay. Fits Node-server deploys; unsuitable for Cloudflare Workers.
+- `workerCron`: Cloudflare Cron Triggers wire the scheduled event to a Worker handler that publishes to the applied queue, per the Cloudflare Cron Triggers documentation. Cron-trigger semantics are per-cron-string on the Worker's wrangler config, not per-job-cron on the runtime; the guide names the alignment. Refuses `workerCron` when the applied queue has no cron surface.
+- `external`: an external cron runner (Kubernetes CronJob, GitHub Actions schedule, systemd timer) invokes an operator surface with a fire-now command.
+- Reserved `workflows` (v1.1.0): wraps the same job-definition contract with Cloudflare Workflows `step.do` orchestration per section 5.7 of the spec and the round-6 proposal decision (b). Adds one enum value at ADR-3102 and one section to the guide; no facade re-shape.
+
+## Timeout ceiling (ADR-3104)
+
+Default handler `timeoutMs` is 60000 (60 seconds); floor is 1000 (1 second); ceiling is bounded by the applied queue's consumer wall-clock. Cloudflare Queues caps consumer wall-clock at 15 minutes per the platform limits documentation; a job-definition module declaring a `timeoutMs` above the ceiling refuses at boot with a clear error naming the ceiling and the applied provider.
+
+## Companions and capabilities
+
+- `capabilities: ["backgroundJobs"]` (per section 6a of `packages/rcf-lite/docs/blueprint-authoring.md`; a consumer blueprint reads this capability to obtain the job-definition and scheduler surfaces at apply time).
+- `providesRoles`: absent.
+- `suggestedCompanions`:
+  - `logging`: every `jobStarted` / `jobCompleted` / `jobFailed` event writes through the applied logger; a logging companion supplies the factory.
+  - `errorHandling`: a `jobFailed` constructs an internal error record with the terminal error code and the correlation id; an error-handling companion supplies the record factory and the boundary.
+
+## The five probes
+
+Each probe module lives under `contributions/probes/` and exports the spec section 3.2 verdict envelope with an `anchorAcId` matching a contributed AC id on the blueprint. Each has a matching `run-<probe-name>.mjs` shim writing a per-blueprint report at `.rcf/reports/blueprints/jobs-background/<probe-name>.json` per spec section 3.4.
+
+- `apply-time-refusal.mjs` (anchors `AC-jobs-requiresQueue`): invokes `rcf define blueprint add ./blueprints/jobs-background` against a bare Node scratch fixture with NO queue applied; asserts exit 3, greps stderr for the first-line tag `[jobs-background-no-queue]`, greps stderr for the explicit provider name `messaging-queue-cloudflare` and the override flag `--allow-no-queue-yet`. Q3 default per spec section 10: asserts BOTH exit code AND stable message id.
+- `apply-time-override.mjs` (anchors `AC-jobs-overrideRecorded`): same bare scratch fixture, but with `--allow-no-queue-yet`; asserts exit 0 and the sidecar `rcf/blueprints/jobs-background.applied.json` records `slug: jobs-background`, `allowNoAuthYet: true`, `appliedCapabilities: []`, and a `notes` field containing `no queue yet` and `--allow-no-queue-yet` and `queue` (but not the auth or secrets-management family words).
+- `fake-clock-cron.mjs` (anchors `AC-jobs-scheduledRunsOnCron`): with `messaging-queue-cloudflare` and `jobs-background` both applied on the shared sample-app fixture, drives the fixture's fake-clock scheduler through one POSIX cron minute for the refresh-cache job; asserts `jobStarted` fires within the elicited `fireToleranceMs` window (default 30000 ms) and `jobCompleted` fires within the elicited `timeoutMs` (10000 ms for refresh-cache).
+- `retry-and-fail.mjs` (anchors `AC-jobs-retryOnHandlerFailure`): with `SIMULATE_HANDLER_THROW=true` on the fixture, schedules a send-welcome-email job (`maxAttempts: 3`), drives the queue through re-deliveries; asserts three `jobStarted` events fire with the same `jobId` and attempts counter 1, 2, 3, followed by a terminal `jobFailed` with a `terminalErrorCode`.
+- `event-secrecy.mjs` (anchors `AC-jobs-eventSecrecy`): with `SIMULATE_PII_IN_JOB_INPUT=true` on the fixture, schedules a job with a PII fixture input `{ userId: 1234, ssn: "123-45-6789", email: "test@example.com" }`; drives to completion; asserts every event record carries only the whitelist `{ event, jobId, jobName, attempts, duration, timestamp }` (plus optional `terminalErrorCode`) and NO PII literal.
+
+## 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.
+
+Two-line boot for the two headline probes:
+
+```sh
+node ../../../../blueprints/jobs-background/contributions/probes/run-apply-time-refusal.mjs
+node ../../../../blueprints/jobs-background/contributions/probes/run-fake-clock-cron.mjs
+```
+
+The remaining three shims (`run-apply-time-override.mjs`, `run-retry-and-fail.mjs`, `run-event-secrecy.mjs`) follow the same pattern.
+
+## Elicited parameters
+
+- `jobsDir` (default `./jobs/`).
+- `defaultRetryPolicy` (`{ maxAttempts: 3, backoff: "exponential" }`).
+- `defaultTimeoutMs` (60000).
+- `schedulerMode` (`inProcess` | `workerCron` | `external`; reserved `workflows` at v1.1.0).
+- `operatorSurface` (`cli` | `httpEndpoint` | `none`).
+- `fireToleranceMs` (default 30000).
+
+## Known limitations (per-AC mechanism-reach form, round-3 checklist 6.g)
+
+- 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-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.
+
+## Reserved v1.1.0 minor: Workflows adapter
+
+The v1.1.0 minor adds a fourth `scheduler` value (`workflows`) at ADR-3102, wrapping the same job-definition contract with Cloudflare Workflows `step.do` orchestration per section 5.7 of the spec. No topic conflict (the `backgroundJobModel` topic answer stays retry-and-schedule), no facade re-shape. Adds one section to this guide.