rcf-lite 0.11.0 → 0.13.0

package/blueprints/deploy-cloudflare-workers/contributions/adrs/adr-1303-deploy-cloudflare-workers-preview-vs-production.json

@@ -0,0 +1,30 @@
+{
+  "adrId": "ADR-1303-deploy-cloudflare-workers-preview-vs-production",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Preview URLs (per-version-id + stable alias) and production URL are distinct addressable surfaces; the promote step is what changes which one production maps to",
+  "context": "The failure mode this ADR closes is the collapsed URL: a project where the reviewer of a merged change and the visitor to the deployed application look at the same URL. When the preview surface and the production surface are the same string, every merge is a production act, review is what happens after users notice, and rollback is a second merge landing before enough users notice. The vendor's own primitive shape supports keeping them distinct: every uploaded version has a permanent per-version-id URL and a mutable stable-alias URL that can be pointed at the newest-of-main; production is the mapped custom domain (or the workers.dev production host) whose current version id changes only on an explicit deploy verb.",
+  "decision": "The blueprint mandates three URL kinds per Worker, all distinct hostnames, all discoverable through the Deploy Adapter's `deploy status` verb: (1) a per-VERSION-ID URL, unique per upload, permanent, useful for pinning a change-review link; (2) a STABLE PREVIEW ALIAS URL fixed to an operator-chosen alias string (the common default is `main`), always resolving to the newest-of-main uploaded version, useful for a persistent stakeholder-shareable link; (3) a PRODUCTION URL, declared under the wrangler manifest's `route`/`routes`/`workers_dev`/custom-domain stanza, changing which version it maps to only when a `promote` workflow runs. The Preview URL Resolver (TAC-1303) assembles the first two and refuses any alias string whose assembled host segment equals the production URL's host segment. The manifest loader refuses a wrangler config whose production route resolves to the preview alias URL host with `DEPLOY_URL_COLLAPSED`.",
+  "consequences": "Reviewers and stakeholders reach the newest-of-main at a persistent, memorable URL that never masquerades as production. Users hit production at a hostname that only changes version behind an explicit operator act. Change-review links are pinnable to a specific version id and never rot. The trade is one Worker now surfaces three URLs the project has to reason about (and the operator has to explain once when a new engineer joins); the payoff is the class of leaks-through-collapsed-URL is closed by the manifest's own validation, not by discipline.",
+  "alternativesConsidered": [
+    {
+      "name": "Preview alias URL and production URL as the same string with a query parameter switching mode",
+      "summary": "One hostname, `?preview=1` flips to the newest-of-main; production is the default response.",
+      "reasonNotChosen": "The query-parameter mode is trivially forgettable and does not survive a link-shortener, an email quoting, or a browser that strips query strings. The class of leak this ADR closes reopens exactly when the operator hands out the URL to someone who does not add the query parameter."
+    },
+    {
+      "name": "Per-version URLs only; no stable alias URL",
+      "summary": "Every upload gets a URL; the stable-shareable-review-URL story is 'copy the URL from the CI run'.",
+      "reasonNotChosen": "The per-version-id URL is essential for pinning a change; the stable alias URL is essential for a persistent 'the latest' surface stakeholders can bookmark. Shipping only the first fails the persistent-review use case; the vendor's own primitive supports both cheaply so both ship."
+    },
+    {
+      "name": "Preview URL = production URL under a special header",
+      "summary": "One hostname; the vendor routes to the newest-of-main when a specific request header is set (a signed cookie, an auth-only bypass).",
+      "reasonNotChosen": "Same class as the query-parameter option: the mode is invisible to the URL string and non-portable across link handoffs. It also couples the preview surface to an auth model that may not exist on day one."
+    }
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/adrs/adr-1304-deploy-cloudflare-workers-rollback-is-promote.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-1304-deploy-cloudflare-workers-rollback-is-promote",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Rollback is a promote of a prior version id; the promote workflow is the sole ship-to-production path",
+  "context": "Rollback is one of the two shapes a project reaches for at exactly the wrong time to discover drift. The failure mode: a project ships a rollback verb once during setup, does not exercise it under pressure until an incident lands, then discovers the rollback path diverged from the ship path (a different vendor call, a different auth path, a different secret binding, a stale probe set, no served-surface verify). Framing rollback as a promote of a known-good version id keeps the audit shape uniform, the auth path identical, the probe set the same, and the served-surface verifier applied unconditionally.",
+  "decision": "Rolling production back to a previous version is not a distinct code path in the project. It is the same `promote` workflow triggered with the prior version id supplied as the `versionId` input. `listVersions` on the Deploy Adapter exposes the history with the currently-serving id marked so the operator can pick a known-good id. The deploy-log record for a rollback carries the same fields as any promote (`promotedVersionId`, `promotedBy`, `previousVersionId`, `promotedAt`). The vendor's own convenience verbs (a `wrangler rollback` shortcut when the default vendor is in play) are optional operator documentation; at the blueprint's contract level any such shortcut is a promote of a prior version id and the audit trail is identical. A project-authored `rollback` script that bypasses the Promote Gate, the deploy log, or the Served-surface Verifier is not permitted.",
+  "consequences": "One ship path serves every ship-to-production act: the merge-to-main promote, the hotfix promote of an out-of-sequence upload, the rollback promote of a prior version id. The audit trail is uniform; a query for 'every production change in the last week' answers the same way for a forward promote and a rollback. The trade: an operator responding to an incident with `wrangler rollback` at the command line (rather than through the `promote` workflow) bypasses the deploy-log record and the served-surface verifier; the blueprint documents this in the guide as a break-glass path that is not the recorded ship path.",
+  "alternativesConsidered": [
+    {
+      "name": "Bespoke `rollback` workflow with its own trigger and its own vendor call",
+      "summary": "A `rollback` workflow file separate from `promote`; triggers on manual dispatch; calls `wrangler rollback` (or the vendor's rollback verb) directly.",
+      "reasonNotChosen": "Two ship paths is one too many. The bespoke workflow drifts from the promote path over time (different secret binding, different logging, different probe set) and the drift is invisible until an incident. Keeping rollback on the same path as promote closes the class."
+    },
+    {
+      "name": "Rollback as a git revert + normal promote of the reverted-merge upload",
+      "summary": "Rollback is not a distinct verb at all; the operator opens a revert PR, waits for the merge, waits for the `build-and-upload` run, then promotes the new upload.",
+      "reasonNotChosen": "The revert flow works for cases where the incident is not urgent and the correct answer is a proper revert. It fails the incident case where the fix is a known-good version id from thirty minutes ago that the operator wants serving now. The chosen model handles both cases on one path."
+    }
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/adrs/adr-1305-deploy-cloudflare-workers-dev-mode-drift.json

@@ -0,0 +1,25 @@
+{
+  "adrId": "ADR-1305-deploy-cloudflare-workers-dev-mode-drift",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "accepted",
+  "title": "Local dev-mode is an emulator; ship-gate coverage never counts a dev-mode probe as a deployed observation",
+  "context": "Every deploy vendor of any complexity ships a local development mode: a process that runs on the developer's laptop and answers requests at a loopback port, approximating the deployed runtime. The failure mode is the emulator being treated as authoritative for ship coverage: an AC scoped `deployed` gets a test case that hits the dev-mode URL and passes there because the emulator handles the case, then fails on production because the emulator's regular-expression engine differs, or its static-assets ordering differs, or its binding-emulation surface differs. The RCF `deployed` scope tag exists precisely to close this class; the blueprint has to make the class refuseable at the coverage-gate layer.",
+  "decision": "The blueprint's `deployed`-scope ACs are only satisfied by a probe against an actual uploaded Worker: a per-version-id URL, a preview alias URL, or the production URL. A test case whose runtime target URL matches the dev-mode local pattern (`http://localhost:*`, `http://127.0.0.1:*`, or the vendor's local emulator loopback host) is refused as coverage for a `deployed`-scope AC with the code `DEPLOY_DEV_MODE_INADMISSIBLE`. Dev-mode remains a valid target for `runtime`-scope and `library`-scope ACs, and for developer-loop iteration; it is inadmissible for `deployed`-scope coverage. The project's runtime-verify catalogue names the dev-mode drift classes the operator authoring probes must be aware of; the catalogue is kept current against the vendor's release notes.",
+  "consequences": "The ship gate refuses a class of easy-to-hit false positives that would otherwise let a passing local test carry a broken deployed AC to green. The trade: some kinds of probe (a startup-behaviour probe, a code-shape probe) that would run cheaply against dev-mode now cost a full upload-plus-preview to satisfy the deployed-scope AC; the blueprint's guide names those as the classes the operator authors as `runtime`-scope ACs against dev-mode where the deployed observation adds no signal, and as `deployed`-scope ACs against the preview URL where it does.",
+  "alternativesConsidered": [
+    {
+      "name": "Treat dev-mode as fully-authoritative when a project-declared fidelity flag is set",
+      "summary": "The project declares 'dev-mode is close enough for our purposes' and the coverage gate accepts dev-mode probes for deployed-scope ACs.",
+      "reasonNotChosen": "The flag becomes an escape hatch that quietly disables the gate the RCF `deployed` scope tag exists to enforce. When the emulator drifts in a way the project does not yet know about, the flag masks it. If a project genuinely wants dev-mode as its runtime target, it authors those ACs as `runtime`-scope and does not need the flag."
+    },
+    {
+      "name": "Warn on dev-mode probes for deployed-scope ACs; do not refuse",
+      "summary": "The coverage gate emits a warning and counts the coverage anyway.",
+      "reasonNotChosen": "Warnings that do not refuse become noise. The class of drift this ADR closes is precisely the class where a project shipped for months on a warning nobody read. Refusing at the gate keeps the invariant load-bearing."
+    }
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-001",
+  "prdId": "PRD-001",
+  "title": "The repo-root wrangler manifest is the single declaration of the Worker's deploy shape",
+  "description": "A `wrangler.toml` (or the equivalent `wrangler.jsonc`) at the repo root is the sole declaration of the Worker's deploy shape. It carries the Worker `name`, the entrypoint `main`, a pinned `compatibility_date`, any `compatibility_flags`, and every non-secret binding the runtime needs: KV namespaces, D1 databases, R2 buckets, Durable Object namespaces, static-assets binding, and non-secret environment variables. Secret bindings are NOT declared in the manifest (wrangler 4.x has no `[secrets]` block, no `secrets.required[]` list, and no empty-value binding entry for secrets); the vendor treats every env-accessor reference from Worker code as an implicit secret binding declaration and enforces its presence at deploy time by refusing `wrangler deploy` when a referenced secret has not been set on the target. Nothing outside the manifest may configure a non-secret binding at deploy time; a non-secret binding referenced from Worker code but absent from the manifest is a build refusal (an implicitly-referenced secret is caught by the vendor's own pre-deploy refusal instead). No secret VALUE ever appears in the manifest.",
+  "category": "technical",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "A scattered deploy configuration is the failure mode this blueprint exists to end. If bindings are declared in ad-hoc scripts, CI environment blocks, or hand-edited before deploy, no one knows what the deployed Worker actually looks like. A single manifest at a known path makes the deploy shape legible to humans, to CI gates, to the vendor's deploy step, and to review of every change that touches a binding.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:01-manifest"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-002",
+  "prdId": "PRD-001",
+  "title": "One deploy adapter module is the sole caller of the deploy CLI",
+  "description": "The project exposes a single Deploy Adapter module that wraps the deploy CLI (the vendor's `wrangler` binary when the default vendor is in play). Every path that uploads a version, promotes a version, lists versions, or reads deploy state routes through this module. Nothing else in the project source tree spawns the CLI, imports the vendor SDK, or issues an HTTP call to the vendor's deploy API. The module exposes a fixed named-verb surface (`uploadVersion`, `promoteVersion`, `listVersions`, `resolveNewestOfMain`, `describeVersion`) that is stable across the blueprint's major version.",
+  "category": "technical",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "A vendor-neutral adapter port keeps the project free to change deploy vendors under the same interface. It also removes the class of bugs where two paths call the CLI with different flags and drift silently. One module, one boundary, one behaviour. The blueprint mandates the CONTRACT and defaults the VENDOR; a project that supersedes the default vendor swaps only the adapter's implementation.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:02-adapter-boundary"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-003",
+  "prdId": "PRD-001",
+  "title": "Every merge to the main branch uploads a Worker version addressable at a stable preview alias URL",
+  "description": "The CI pipeline runs a build+upload step on every merge to the main branch. The step produces an uploaded Worker version (the vendor's version primitive) with two addressable URLs recorded on the CI run: a permanent per-version-id URL, and a stable ALIAS URL fixed to the string `main` (or an equivalent operator-chosen alias) that always resolves to the newest-of-main upload. The alias URL never changes across re-uploads; the version-id URL is unique per upload and durable. The uploaded version does NOT serve production traffic; it exists only at the preview URLs until an explicit promote step runs. The version id and both URLs are surfaced in the CI run output.",
+  "category": "functional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "Uploading a version on merge without promoting it separates two concerns most teams tangle at their cost: 'is the artefact built and cleanly uploaded' from 'is production serving it now'. The stable preview alias URL is the shape a stakeholder can bookmark and share; the version-id URL is the shape a change-review workflow references verbatim. Both matter and both come from the same upload step.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:03-preview-upload"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-004",
+  "prdId": "PRD-001",
+  "title": "Production only changes via an explicit promote step; no upload path auto-promotes",
+  "description": "Production traffic serving is a distinct action from uploading a version. No CI path may take an uploaded version and route production traffic to it as a side effect of the upload. Production only changes when a Promote step runs and names the version id to serve. The promote step is authored as a separate CI workflow triggered by explicit operator action (`workflow_dispatch` on GitHub Actions or the equivalent manual-trigger primitive on other CI platforms). The promote workflow accepts one input: `versionId` (empty defaults to the newest-of-main resolved from the preview alias); every promote emits a structured record naming the version id promoted, the operator principal that triggered the workflow, the previously-serving version id, and the timestamp.",
+  "category": "functional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "The failure mode this ends: a merge lands, the CI pipeline deploys straight to production, and nobody notices the bad release until the phone rings. Decoupling upload from promote makes the ship-to-production act a first-class human decision. The default of newest-of-main keeps the promote fast for the common case; the explicit versionId keeps rollback and hotfix promotes on the same code path.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:04-explicit-promote"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-005",
+  "prdId": "PRD-001",
+  "title": "Preview and production surfaces are addressable at distinct URLs both discoverable from the manifest",
+  "description": "The deployed application is reachable at two distinct kinds of URL: a PREVIEW surface (per-version alias URLs and per-version-id URLs, both provided by the vendor at upload time on the workers.dev subdomain) and a PRODUCTION surface (a route or custom domain declared in `wrangler.toml` under a `route`/`routes`/`workers_dev` block, or a mapped custom hostname). A `deploy status` verb on the Deploy Adapter surfaces both URL kinds for the current state without requiring an operator to consult the vendor dashboard. The preview alias URL and the production URL are never the same string; a project that would collapse them into one URL is a misconfiguration the adapter refuses.",
+  "category": "functional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "Two URLs, two purposes. The preview URL is where a change lives before promote, where stakeholder review happens, where end-to-end probes hit the newest-of-main. The production URL is where users hit the promoted version. Collapsing them is the failure mode where reviewing a change means reviewing production; keeping them distinct is what makes the promote step meaningful.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:05-url-model"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-006",
+  "prdId": "PRD-001",
+  "title": "Secret bindings resolve through the project's secrets contract, never plaintext in the wrangler manifest",
+  "description": "Every secret the Worker reads at runtime is referenced implicitly through the runtime's env accessor (in the default JS/TS Worker, `env.<NAME>`); wrangler 4.x has no `[secrets]` block, no `secrets.required[]` list, and no empty-value binding entry for secrets, and the vendor treats every such env-accessor reference from Worker code as an implicit secret binding declaration, refusing `wrangler deploy` when a referenced secret has not been set on the target. Each such name is populated on the deploy target through the vendor's own secret-set flow (first-deploy via `wrangler deploy --secrets-file <tmp>`, steady-state via `wrangler secret put <NAME>`; see `assets/wrangler-samples/bootstrap-vs-steady-state.md`). The value is sourced from the project's secrets contract (as fixed by the `security-secrets-management` blueprint at slug `security-secrets-management` when applied, or by the equivalent project-authored contract). No secret VALUE ever lives in `wrangler.toml`, in a committed environment file, in a CI variable readable outside the promote job, or in the CI run's captured logs. A CI-side redactor scrubs any log line that would emit a resolved secret value.",
+  "category": "security",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "Secrets in deploy config is one of the two shapes of leak this blueprint refuses (the other is production auto-promote). Declaring bindings by name only forces the value to arrive through a controlled channel and keeps the manifest safe to review in a PR. The blueprint mandates the CONTRACT (values arrive through the secrets pipeline); the vendor default binds through `wrangler secret put`.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:06-secrets-boundary"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-007",
+  "prdId": "PRD-001",
+  "title": "A build-and-upload CI workflow runs on every merge to the main branch and records the uploaded version id",
+  "description": "A CI workflow named `build-and-upload` (or the project's chosen equivalent) triggers on `push` to the main branch (and on any linear-history proxy the project uses). It checks the tree out, installs dependencies at the pinned versions, runs the project's build step, then invokes the Deploy Adapter's `uploadVersion` verb naming the operator-chosen preview alias string. On success it writes the uploaded version id, the version-id URL, and the preview alias URL to the CI run's job summary and to a structured output the promote workflow reads. The workflow authenticates to the vendor through named CI secrets (a vendor API token and a vendor account id); the token is scoped to the Worker's account and never appears in any log line.",
+  "category": "functional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "The build-and-upload workflow is the mechanism half of REQ-003: every merge produces an uploaded, addressable version, without touching production. Making the version id and URLs discoverable in the CI run output is what makes the promote step's `newest-of-main` default computable and what makes the change reviewable at the preview URL by anyone with the CI run link.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:07-ci-build-upload"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-008",
+  "prdId": "PRD-001",
+  "title": "A promote CI workflow runs on explicit manual trigger and accepts an optional versionId input",
+  "description": "A CI workflow named `promote` (or the project's chosen equivalent) triggers only on manual operator action (`workflow_dispatch` on GitHub Actions or the equivalent explicit-trigger primitive on other CI platforms). It accepts one input field `versionId`: when supplied, the workflow promotes that exact version; when blank, the workflow calls the Deploy Adapter's `resolveNewestOfMain` verb to look up the current version id behind the preview alias and promotes THAT. It then invokes `promoteVersion` on the Deploy Adapter and, on success, invokes the served-surface verifier (REQ-010) before declaring the run successful. The workflow authenticates through the same named vendor CI secrets as `build-and-upload` and emits a structured record of the promote for the deploy log.",
+  "category": "functional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "One workflow for both cases keeps the promote path narrow and reviewable. The empty-input default answers the common case (ship what merged); the explicit-id input answers hotfix promotes and rollbacks without a second code path. Every promote runs through the same served-surface verifier gate so no promote can quietly ship a broken version.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:08-ci-promote"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-009",
+  "prdId": "PRD-001",
+  "title": "Rollback is a promote of a prior version id; the promote workflow is the sole ship-to-production path",
+  "description": "Rolling production back to a previous version is not a distinct code path in the project's deploy tooling. It is the same `promote` workflow (REQ-008) triggered with the prior version id supplied as the `versionId` input. The prior version id is discoverable by calling the Deploy Adapter's `listVersions` verb, which returns the recent history with the currently-serving id marked. A project may surface a `wrangler rollback` shortcut in operator documentation for convenience, but at the contract level the shortcut is a promote of the second-most-recent version id and the audit trail records it the same way. No project-authored `rollback` verb bypasses the promote workflow's structured record or the post-promote verifier.",
+  "category": "functional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "Two ship paths is one too many. If rollback has its own bespoke script, the script drifts from the promote path in exactly the moments an incident is the wrong time to discover drift. Framing rollback as a promote of a known-good version id keeps the ship path narrow, the audit shape uniform, and the post-promote verifier applied unconditionally.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:09-rollback"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-010",
+  "prdId": "PRD-001",
+  "title": "Every promote runs bounded served-surface probes against the production URL and fails the release on breach",
+  "description": "Immediately after a successful `promoteVersion` call, the promote workflow (REQ-008) invokes the Served-surface Verifier (TAC-1305). The verifier hits a fixed set of probe paths on the PRODUCTION URL (not the preview URL) with bounded retry semantics: at least three probe paths chosen by the project, each requested at most six times over at most sixty seconds, with a per-request timeout at most five seconds. A probe passes when the response status is in the project-declared success set and the response body carries the expected shape (for a health probe, a body containing the version-id string that was just promoted; for a smoke path, a project-declared invariant string). If any probe path fails every retry the workflow exits non-zero with a stable code `PROMOTE_VERIFY_FAILED`, records the failed probe path, the response status seen, the elapsed time, and refuses to mark the release successful.",
+  "category": "nonFunctional",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "A promote that does not verify the served surface is a promote taken on trust of the vendor's own success signal. The vendor's success signal covers 'the version is now the serving version', which is not the same as 'the served surface answers correctly'. Bounded retries are the discipline that catches propagation-lag class failures without turning transient blips into a stuck workflow.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:10-verify-served"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-011",
+  "prdId": "PRD-001",
+  "title": "Local dev-mode is an emulator; the ship gate never treats a dev-mode signal as authoritative",
+  "description": "The vendor's local development mode (`wrangler dev` on the default vendor) is an emulator, not the deployed runtime. It approximates the runtime shape but carries known behavioural differences (differing regular-expression engines, differing static-assets ordering, differing binding-emulation surface, differing timeout behaviour). The project may use dev-mode for developer-loop iteration. The ship gate does not: no test authored against `wrangler dev` counts as passing coverage for a deployed AC; the coverage tag `deployed` on any AC requires the served-surface probe hit an actual uploaded Worker (preview URL is fine; production URL is fine; dev-mode local URL is not). A project-side lint or CI check catches an AC-to-TC binding that attempts to substitute a dev-mode observation for a deployed one.",
+  "category": "technical",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "The reason a runtime-verify layer exists in RCF is that codebase-level tests cannot cover deployed behaviour. Letting an emulator stand in for the deployed runtime re-opens exactly the class of drift the deployed-scope tag exists to close. Naming the class of dev-mode-only tests inadmissible-as-deployed-coverage is the discipline.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:11-dev-mode-drift"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,18 @@
+{
+  "reqId": "deploy-cloudflare-workers-REQ-012",
+  "prdId": "PRD-001",
+  "title": "Every uploaded version carries build-provenance attributes readable at runtime",
+  "description": "Every version uploaded by the `build-and-upload` workflow carries three provenance attributes accessible from within the Worker at runtime: the commit sha of the source tree the version was built from, the ISO 8601 timestamp of the build, and the URL of the CI run that produced the upload. The three values are injected into the Worker's build (as build-time constants baked into the bundle, as `vars` populated by the CI step, or as a runtime-readable metadata surface the Deploy Adapter's `describeVersion` verb returns; the project picks the mechanism). A health probe exposes them on a fixed path; the response body carries a stable JSON shape whose `versionSha`, `builtAt`, and `ciRunUrl` fields are the served-surface verifier's evidence that the promoted version is the version it thinks it promoted.",
+  "category": "technical",
+  "domain": "deploy",
+  "priority": "must",
+  "rationale": "Without provenance the served-surface verifier cannot tell a successful promote from a stale response served by a routing layer that has not converged. Baking provenance into the version and surfacing it on a health probe is what makes the verifier's success signal load-bearing; it is also what makes incident triage answerable in one request.",
+  "tags": [
+    "blueprint:deploy-cloudflare-workers",
+    "category:12-provenance"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/tacs/tac-1301-deploy-cloudflare-workers-deploy-adapter.json

@@ -0,0 +1,54 @@
+{
+  "tacId": "TAC-1301-deploy-cloudflare-workers-deploy-adapter",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Deploy Adapter",
+  "purpose": "The one project module that talks to the deploy vendor. Wraps the vendor's CLI (or SDK) behind a fixed named-verb surface every other module imports. Uploads versions, promotes versions, lists version history, resolves the newest-of-main from the preview alias, and describes any single version's provenance and URLs. Nothing else in the project spawns the vendor CLI or issues a vendor deploy call.",
+  "responsibilities": [
+    "Expose `uploadVersion({ previewAlias })` that uploads the current build to the vendor and returns `{ versionId, versionIdUrl, previewAliasUrl }`; refuse an empty `previewAlias` with `DEPLOY_PREVIEW_ALIAS_REQUIRED` (AC-12102-2, AC-12103-1).",
+    "Expose `promoteVersion({ versionId })` that routes production traffic to the named version and returns `{ promotedVersionId, versionSha, previousVersionId }`; the returned `promotedVersionId` is the vendor-assigned version UUID (the string `wrangler versions deploy` took) and the returned `versionSha` is the git commit sha of the source tree the promoted version was built from (read from the version's provenance surface via `describeVersion`); refuse when `versionId` is absent from `listVersions()` with `DEPLOY_VERSION_NOT_FOUND` (AC-12102-3, AC-12108-3).",
+    "Expose `listVersions()` returning the recent version history with the currently-serving id marked (AC-12109-1).",
+    "Expose `resolveNewestOfMain()` that returns the version id currently behind the operator-chosen preview alias by reading `wrangler versions list --json` and picking the item with the greatest `metadata.created_on` whose `annotations['workers/alias']` matches the alias; there is no vendor CLI verb that maps an alias to a version id directly (AC-12108-2).",
+    "Expose `describeVersion({ versionId })` returning provenance (`versionSha`, `builtAt`, `ciRunUrl`) and URLs (`versionIdUrl`) for the named version; `versionSha` is the git commit sha baked into the version's bundle by `build-and-upload`, distinct from the version UUID `versionId` names (AC-12112-1, AC-12112-2).",
+    "Expose `resolveSubdomain()` that returns the account's workers.dev subdomain string every URL-assembly path needs; reads the `WORKERS_DEV_SUBDOMAIN` env var when set (project pin) and otherwise queries the vendor's `GET /accounts/<accountId>/workers/subdomain` REST endpoint; caches the value for the process's lifetime (AC-12105-1).",
+    "Refuse a manifest whose production route resolves to the same host as the preview alias URL with `DEPLOY_URL_COLLAPSED` (AC-12105-2).",
+    "Route every CLI invocation through a redactor that scrubs the vendor API token and account id from every emitted log line (AC-12107-3, AC-12106-2)."
+  ],
+  "internalStructure": "One stateless class per process with an injected vendor binding and an injected redactor. The vendor binding is a project-authored module implementing the port in the interfaces block; the default vendor binding shells to the `wrangler` CLI and lives under the same package as the adapter. Every verb is a thin translation from the named surface to a vendor CLI invocation (or SDK call) plus response parsing plus provenance-URL assembly.",
+  "interfaces": [
+    {
+      "name": "vendorBinding",
+      "kind": "read-write-api",
+      "description": "Project-supplied vendor binding implementing `uploadArtefact({ configPath, previewAlias })`, `deployVersion({ versionId })`, `listVersions()`, `resolveAlias({ alias })`, `getSubdomain({ accountId })`. The default binding shells to `wrangler versions upload --preview-alias <alias>`, `wrangler versions deploy <versionId>`, and `wrangler versions list --json` respectively; `resolveAlias` filters the `versions list --json` output on `annotations['workers/alias']` and picks the newest by `metadata.created_on` because wrangler 4.x has no CLI verb that resolves an alias to a version id (`wrangler versions view` accepts a version UUID only); `getSubdomain` calls the vendor's `GET /accounts/<accountId>/workers/subdomain` REST endpoint because `wrangler whoami` does not return the subdomain."
+    },
+    {
+      "name": "redactor",
+      "kind": "callback",
+      "description": "Log-line filter that replaces any bytes matching the vendor API token or account id with a fixed placeholder before emitting; runs on every stdout and stderr line the vendor CLI produces."
+    },
+    {
+      "name": "manifest",
+      "kind": "read-api",
+      "description": "The wrangler-manifest loader (TAC-1302) resolving the current Worker's config, the production route or custom-domain declaration, and the declared binding names."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Wrangler Manifest",
+      "kind": "tac",
+      "tacId": "TAC-1302-deploy-cloudflare-workers-wrangler-manifest",
+      "description": "Upstream source of the config the adapter passes to the vendor CLI, and the manifest the collapsed-URL guard reads."
+    },
+    {
+      "name": "Preview URL Resolver",
+      "kind": "tac",
+      "tacId": "TAC-1303-deploy-cloudflare-workers-preview-url-resolver",
+      "description": "Assembles the preview alias URL and version-id URL strings the adapter returns; consulted from `uploadVersion` and `describeVersion`."
+    }
+  ],
+  "tradeoffs": "The adapter is process-local and stateless; every call reaches the vendor. That means a chain of adapter calls in one CI step costs one vendor round-trip per call rather than a shared session. The trade keeps the adapter easy to reason about and easy to reimplement against a different vendor. A project that wants a session-shared invocation supplies a vendor binding whose backing is a long-lived process rather than a CLI spawn per call; the port shape does not change.",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/tacs/tac-1302-deploy-cloudflare-workers-wrangler-manifest.json

@@ -0,0 +1,45 @@
+{
+  "tacId": "TAC-1302-deploy-cloudflare-workers-wrangler-manifest",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Wrangler Manifest",
+  "purpose": "The repo-root deploy-configuration file (`wrangler.toml` or `wrangler.jsonc`) as loaded, validated, and exposed to the Deploy Adapter. Parses the manifest into an object the adapter and the CI gates consult, enforces the shape rules (required top-level keys, declared bindings, no inline secrets, no collapsed URLs), and refuses malformed or leaky manifests loudly.",
+  "responsibilities": [
+    "Parse `wrangler.toml` (or `wrangler.jsonc`) at the repo root; refuse absence with `WRANGLER_MANIFEST_MISSING` (AC-12101-1).",
+    "Validate the top-level keys `name`, `main`, `compatibility_date` are present and correctly typed; validate `main` resolves to an existing entry file; validate `compatibility_date` matches `\\d{4}-\\d{2}-\\d{2}` (AC-12101-1).",
+    "Cross-check every binding name referenced from the Worker source (via env-accessor scans keyed by binding name) against the manifest declarations; refuse a missing declaration with `WRANGLER_BINDING_UNDECLARED` naming the offending source path and the missing binding (AC-12101-2).",
+    "Refuse a manifest that carries any inline secret value; scan the parsed object for keys under the vendor's secret-declaration primitive whose value is not an empty declaration (AC-12101-3, AC-12106-1).",
+    "Refuse a manifest whose production route stanza resolves to the same host as the preview alias URL with `DEPLOY_URL_COLLAPSED` (AC-12105-2).",
+    "Expose a `bindings()` accessor listing every declared binding (kind, name) for downstream consumers.",
+    "Expose a `productionUrl()` accessor deriving the production URL from the `routes`/`route`/`workers_dev`/custom-domain declaration."
+  ],
+  "internalStructure": "One parser module per format (TOML and JSONC), one validator that walks the parsed object against the shape rules, one binding-usage scanner that walks the Worker source AST for env-accessor patterns, and one URL-derivation module that inspects the routes stanza. All pure functions; no I/O outside the initial file read.",
+  "interfaces": [
+    {
+      "name": "manifestFile",
+      "kind": "read-api",
+      "description": "Reads `wrangler.toml` or `wrangler.jsonc` at the repo root. The file's presence is required; the file's format is autodetected from the extension."
+    },
+    {
+      "name": "workerSourceScanner",
+      "kind": "read-api",
+      "description": "AST or regex scanner over the Worker source tree that emits every binding name referenced through env-accessor patterns (for the default JS/TS Worker, `env.<NAME>.<method>` and `process.env.<NAME>` are both matched)."
+    },
+    {
+      "name": "bindings",
+      "kind": "read-api",
+      "description": "Structured list of declared bindings emitted for downstream consumers. Each entry names the binding kind (KV, D1, R2, Durable Object, static assets, var, secret, service, queue) and the binding name."
+    },
+    {
+      "name": "productionUrl",
+      "kind": "read-api",
+      "description": "Returns the production URL derived from the manifest. When multiple routes are declared, returns the ordered list; when `workers_dev = true`, returns the workers.dev host."
+    }
+  ],
+  "dependencies": [],
+  "tradeoffs": "The loader owns validation but does not own the vendor's own manifest-level validation (which happens later at the vendor CLI). Two-stage validation means a manifest that passes this loader can still fail the vendor's own load; the trade keeps the loader project-local and fast (no vendor round-trip on every CI step) while catching the classes this blueprint cares about (undeclared bindings, inline secrets, collapsed URLs) before the vendor call. A project can point the loader at a project-authored TOML dialect (a preprocessor step) by wrapping the manifestFile interface.",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/tacs/tac-1303-deploy-cloudflare-workers-preview-url-resolver.json

@@ -0,0 +1,46 @@
+{
+  "tacId": "TAC-1303-deploy-cloudflare-workers-preview-url-resolver",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Preview URL Resolver",
+  "purpose": "The single project source of the string patterns for the two preview URL kinds (per-version-id URL, stable alias URL) and the mapping between an alias string and the version id it currently resolves to. Consulted by the Deploy Adapter's `uploadVersion` and `describeVersion` verbs and by every path that needs to reach the preview surface for review or verification.",
+  "responsibilities": [
+    "Assemble the per-version-id URL for a given version id and the currently-configured Worker name and vendor subdomain (AC-12103-1, AC-12103-2).",
+    "Assemble the stable preview alias URL for a given alias string and the currently-configured Worker name and vendor subdomain; ensure the alias is quoted verbatim in the host segment (AC-12102-2, AC-12103-1).",
+    "Given an alias string, query the vendor for the version id currently behind the alias and return it (`resolveNewestOfMain` on the Deploy Adapter delegates here) (AC-12108-2).",
+    "Refuse an alias string that would collide with the production route's host segment; return `DEPLOY_URL_COLLAPSED` (AC-12105-2).",
+    "Guarantee the preview URL host segment can never equal the production URL host segment; the invariant is a property test at build time (AC-12105-3).",
+    "Expose a `probeUrl(kind, id-or-alias)` verb that returns the URL to hit for a given probe target (`versionId`, `alias`, or `production`), so the Served-surface Verifier need not know URL assembly."
+  ],
+  "internalStructure": "Pure string-assembly module plus a thin query wrapper over the vendor's alias-lookup call. No cache: every alias query goes to the vendor because the alias is expected to change on every upload and the freshness cost of caching is not worth the complexity.",
+  "interfaces": [
+    {
+      "name": "workerIdentity",
+      "kind": "read-api",
+      "description": "Reads the Worker name from the wrangler manifest. Reads the vendor account's workers.dev subdomain from the Deploy Adapter's `resolveSubdomain()` verb (which honours a `WORKERS_DEV_SUBDOMAIN` env-var pin ahead of calling the vendor's `GET /accounts/<accountId>/workers/subdomain` REST endpoint, because no wrangler CLI verb returns the subdomain). Returns both as strings the URL-assembly functions consume."
+    },
+    {
+      "name": "aliasQuery",
+      "kind": "read-api",
+      "description": "Queries the vendor for the version id currently behind an alias by reading `wrangler versions list --json` and filtering on `annotations['workers/alias']`, returning the item with the greatest `metadata.created_on`; there is no direct CLI verb (`wrangler versions view` accepts a version UUID only). Returns the id or a stable `DEPLOY_ALIAS_UNKNOWN` error when no version carries the alias annotation."
+    },
+    {
+      "name": "probeUrl",
+      "kind": "read-api",
+      "description": "Named-verb URL accessor for downstream consumers. `probeUrl('versionId', 'v-123')` returns the per-version URL; `probeUrl('alias', 'main')` returns the alias URL; `probeUrl('production', null)` returns the production URL from the manifest."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Wrangler Manifest",
+      "kind": "tac",
+      "tacId": "TAC-1302-deploy-cloudflare-workers-wrangler-manifest",
+      "description": "Reads the Worker name and the production route stanza; the collapsed-URL invariant is checked against `productionUrl()`."
+    }
+  ],
+  "tradeoffs": "The resolver treats the vendor's URL-string patterns as stable within the blueprint's major version. When the vendor changes the pattern (a new subdomain scheme, a new alias-in-host format), a blueprint major bump is what tracks the change; a project that pinned an older pattern by hand-editing the resolver loses the invariant guard. The trade is a small coupling to the vendor's public URL contract in exchange for one place to change when it moves.",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

package/blueprints/deploy-cloudflare-workers/contributions/tacs/tac-1304-deploy-cloudflare-workers-promote-gate.json

@@ -0,0 +1,57 @@
+{
+  "tacId": "TAC-1304-deploy-cloudflare-workers-promote-gate",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Promote Gate",
+  "purpose": "The project-side guard that enforces production only changes on an explicit operator promote. Wraps the `promote` workflow's input handling, its version-id resolution, its call into the Deploy Adapter, and its post-promote invocation of the Served-surface Verifier. Emits the structured deploy-log record every promote leaves behind.",
+  "responsibilities": [
+    "Accept the `versionId` input from the promote workflow trigger; when empty, invoke `deployAdapter.resolveNewestOfMain()` to fill it (AC-12108-1, AC-12108-2).",
+    "Refuse a `versionId` absent from `deployAdapter.listVersions()` before any vendor call is issued; return `DEPLOY_VERSION_NOT_FOUND` (AC-12108-3).",
+    "Invoke `deployAdapter.promoteVersion({ versionId })`; capture the returned `{ promotedVersionId, versionSha, previousVersionId }` for the deploy-log record. `promotedVersionId` is the vendor-assigned version UUID; `versionSha` is the git commit sha of the source tree the promoted version was built from, read from the version's provenance surface; both are required on the record and both feed the Served-surface Verifier (the verifier reconciles the served health-probe body's `versionSha` against the record's `versionSha`) (AC-12104-3, AC-12109-1).",
+    "Immediately invoke the Served-surface Verifier against the production URL, passing the promote record's `versionSha` as the substitution value for `expectShape.versionSha` in the health-probe declaration; on any verifier failure exit non-zero with `PROMOTE_VERIFY_FAILED` and refuse to mark the release successful (AC-12109-3, AC-12110-1, AC-12110-3).",
+    "Emit the deploy-log record with fields `promotedVersionId`, `versionSha`, `promotedBy`, `previousVersionId`, `promotedAt`; every field is populated; no field carries a secret value (AC-12104-3).",
+    "Refuse to run when the invocation context is not the platform's explicit-manual-trigger primitive (a `workflow_dispatch` guard as the first step of the workflow) (AC-12104-1, AC-12104-2)."
+  ],
+  "internalStructure": "One workflow-orchestration function per CI platform (the default GitHub Actions form is shipped as an asset; other platforms adapt the same shape). The function is stateless; the workflow's own outputs are the durable state. The deploy-log record is written to a project-chosen sink (a JSONL file in a durable location, an audit event bus, a database table) through an injected `deployLog.append` callback.",
+  "interfaces": [
+    {
+      "name": "deployAdapter",
+      "kind": "read-write-api",
+      "description": "The Deploy Adapter port (TAC-1301). The promote gate calls `listVersions`, `resolveNewestOfMain`, and `promoteVersion` through this interface."
+    },
+    {
+      "name": "verifier",
+      "kind": "read-api",
+      "description": "The Served-surface Verifier callable that runs the post-promote probes and returns pass or a `PROMOTE_VERIFY_FAILED` failure description."
+    },
+    {
+      "name": "deployLog",
+      "kind": "callback",
+      "description": "Append callback invoked with the promote record `{ promotedVersionId, versionSha, promotedBy, previousVersionId, promotedAt }` on every successful promote and on every verifier-failed promote."
+    },
+    {
+      "name": "triggerContext",
+      "kind": "read-api",
+      "description": "Returns the platform's trigger information (event name, actor login). The gate refuses to proceed when the event name is not the platform's explicit-manual-trigger name (`workflow_dispatch` on GitHub Actions)."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Deploy Adapter",
+      "kind": "tac",
+      "tacId": "TAC-1301-deploy-cloudflare-workers-deploy-adapter",
+      "description": "Every version operation routes through the adapter; no direct vendor CLI call from the gate."
+    },
+    {
+      "name": "Served-surface Verifier",
+      "kind": "tac",
+      "tacId": "TAC-1305-deploy-cloudflare-workers-served-surface-verifier",
+      "description": "The post-promote probe layer; the gate invokes the verifier and honours its failure signal."
+    }
+  ],
+  "tradeoffs": "The gate is coupled to the workflow platform's explicit-trigger primitive. A project that runs on a CI platform without a distinct manual-trigger event needs a project-authored wrapper that supplies the equivalent (a manual-approval step; a webhook with an operator token check). The trade is the workflow platforms that ship this primitive natively (GitHub Actions, GitLab CI's manual jobs, Buildkite's block steps) all get the invariant enforced cheaply; the rest layer their own equivalent above.",
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}