rcf-lite 0.12.0 → 0.14.0

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

@@ -0,0 +1,46 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12105",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Preview and production surfaces live at distinct URLs both discoverable from the manifest",
+  "asA": "operator investigating a change or an incident",
+  "iWant": "one command to print the preview URLs and the production URL for the Worker",
+  "soThat": "the dashboard is not a step on any triage path",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12105-1",
+      "description": "The Deploy Adapter's `deploy status` (or equivalent named verb on the adapter surface) returns a structured object naming the current production URL, the preview alias URL, and the currently-serving version id.",
+      "given": "an operator on a machine authenticated to the deploy vendor",
+      "when": "the operator invokes the adapter's `deploy status` verb",
+      "then": "the response is a structured object whose fields include `productionUrl`, `previewAliasUrl`, and `currentlyServingVersionId`; every field is populated",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12105-2",
+      "description": "The preview alias URL and the production URL are never equal; a manifest whose production route resolves to the same host as the preview alias URL is refused by the adapter with a stable-coded error.",
+      "given": "a `wrangler.toml` whose production route stanza names the same host as the preview alias URL",
+      "when": "the adapter loads the manifest",
+      "then": "the load throws a `DEPLOY_URL_COLLAPSED` error naming both URLs; no deploy verb accepts the manifest",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12105-3",
+      "description": "A request to the production URL and a request to the preview alias URL immediately after an upload but before a promote resolve to different version ids in their health-probe responses.",
+      "given": "production serving version P and an uploaded-not-promoted version W behind preview alias A",
+      "when": "a health probe hits the production URL and a second health probe hits A",
+      "then": "the production response body carries `versionSha` of P and the preview response body carries `versionSha` of W; the two values are not equal",
+      "testable": true,
+      "scope": "deployed"
+    }
+  ],
+  "tacIds": [
+    "TAC-1303-deploy-cloudflare-workers-preview-url-resolver",
+    "TAC-1301-deploy-cloudflare-workers-deploy-adapter"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,46 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12106",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Secret bindings resolve through the secrets contract; no secret value ever lives in the manifest",
+  "asA": "reviewer of a change that touches deploy config",
+  "iWant": "certainty that a PR touching wrangler config cannot leak a secret",
+  "soThat": "review moves as fast as the config change and nothing else",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12106-1",
+      "description": "Every secret binding the Worker consumes at runtime is referenced implicitly via the runtime's env accessor (in the default JS/TS Worker, `env.<NAME>`) in the Worker source; wrangler 4.x has no `[secrets]` block, no `secrets.required[]` list, and no empty-value binding entry for secrets, and the vendor treats each such env-accessor reference as an implicit secret binding declaration and refuses `wrangler deploy` when the 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, sourced from the project's secrets contract.",
+      "given": "a project that has applied both this blueprint and the `security-secrets-management` blueprint (or an equivalent project-authored secrets contract)",
+      "when": "the Worker source is scanned for env-accessor references that resolve to secret bindings (per the manifest loader's binding-kind classification) and each such name is cross-checked against the secrets contract's declared names",
+      "then": "every implicitly-referenced secret name maps to a name declared in the secrets contract; every name has a resolvable value in the active deploy environment; the manifest carries no `[secrets]` block, no `secrets.required[]` list, and no binding declaration with an inline secret value",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12106-2",
+      "description": "The CI workflows redact any log line that would emit a resolved secret value.",
+      "given": "a CI run whose steps read a resolved secret value into a shell step that would echo it",
+      "when": "the run's captured logs are inspected byte-for-byte after completion",
+      "then": "no log line contains any byte sequence in the resolved-values set; every substitution shows a fixed placeholder in the emitted line",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12106-3",
+      "description": "A committed file whose bytes match any resolved secret value is refused by the CI gate.",
+      "given": "a change that adds a file whose contents include a byte sequence equal to any resolved secret value",
+      "when": "the CI gate scans the change",
+      "then": "the run fails with a stable-coded `DEPLOY_SECRET_LEAKED_IN_FILE` error naming the offending path and the logical name of the matching secret",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1302-deploy-cloudflare-workers-wrangler-manifest",
+    "TAC-1301-deploy-cloudflare-workers-deploy-adapter"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,46 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12107",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-007",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The build-and-upload workflow runs on every merge to main and records the version id",
+  "asA": "reviewer following a merged change",
+  "iWant": "the CI run for the merge to surface the uploaded version id and both preview URLs",
+  "soThat": "I can reach the preview surface and reference the version id without hunting",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12107-1",
+      "description": "The `build-and-upload` workflow triggers on `push` to the `main` branch (and on the project's chosen linear-history proxy for merges), and does not trigger on `pull_request` or any other event.",
+      "given": "the `build-and-upload` workflow file",
+      "when": "the trigger stanza is parsed",
+      "then": "the trigger set contains `push` scoped to the `main` branch (or the equivalent linear-history proxy); it contains no `pull_request` or `schedule` trigger",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12107-2",
+      "description": "A successful run writes the uploaded version id, the version-id URL, and the preview alias URL to a structured output the `promote` workflow's `resolveNewestOfMain` path can read.",
+      "given": "a successful `build-and-upload` run on a merge to main",
+      "when": "the run's outputs are inspected after completion",
+      "then": "a structured output object exists whose fields include `versionId`, `versionIdUrl`, and `previewAliasUrl`; every field is populated with a non-empty string; the `previewAliasUrl` host segment carries the operator-chosen alias string",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12107-3",
+      "description": "The workflow authenticates to the vendor through named CI secrets (a vendor API token and a vendor account id) scoped to the Worker's account; neither secret ever appears in any log line.",
+      "given": "a `build-and-upload` run that reads the vendor API token and account id from named CI secrets",
+      "when": "the run's captured logs are inspected byte-for-byte",
+      "then": "no log line contains the API token bytes; no log line contains the account id bytes; both are populated only into the vendor CLI's environment and redacted from any emitted line",
+      "testable": true,
+      "scope": "deployed"
+    }
+  ],
+  "tacIds": [
+    "TAC-1306-deploy-cloudflare-workers-deploy-ci-workflows",
+    "TAC-1301-deploy-cloudflare-workers-deploy-adapter"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,46 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12108",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-008",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The promote workflow is manually triggered and accepts an optional versionId input",
+  "asA": "operator shipping a change to production",
+  "iWant": "one promote workflow that ships the newest-of-main by default and accepts an explicit version id",
+  "soThat": "the common ship, a hotfix, and a rollback all travel the same path",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12108-1",
+      "description": "The `promote` workflow declares one input field `versionId` typed as an optional string.",
+      "given": "the `promote` workflow file",
+      "when": "the input stanza is parsed",
+      "then": "one input `versionId` exists and is not marked required; the workflow declares no other input fields",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12108-2",
+      "description": "A promote invocation with an empty `versionId` input resolves the newest-of-main by querying the Deploy Adapter's `resolveNewestOfMain` verb and then promotes THAT version.",
+      "given": "the preview alias `main` currently resolves to version W",
+      "when": "the `promote` workflow runs with `versionId=''`",
+      "then": "the workflow invokes `resolveNewestOfMain` returning W, calls `promoteVersion({ versionId: W })`, and the recorded promote record names W as `promotedVersionId`",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12108-3",
+      "description": "A promote invocation whose input `versionId` is not present in `listVersions()` fails before calling `promoteVersion` and records nothing to the deploy log.",
+      "given": "an id `not-a-version` absent from `listVersions()`",
+      "when": "the `promote` workflow runs with `versionId='not-a-version'`",
+      "then": "the run fails with the `DEPLOY_VERSION_NOT_FOUND` code from the adapter, no vendor promote call is issued, and no promote record is appended to the deploy log",
+      "testable": true,
+      "scope": "deployed"
+    }
+  ],
+  "tacIds": [
+    "TAC-1304-deploy-cloudflare-workers-promote-gate",
+    "TAC-1306-deploy-cloudflare-workers-deploy-ci-workflows"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,47 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12109",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-009",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Rollback is a promote of a prior version id",
+  "asA": "operator responding to a bad release",
+  "iWant": "the same promote workflow to take a prior version id and route production to it",
+  "soThat": "rollback carries the same audit shape and post-promote verification as every other ship",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12109-1",
+      "description": "The Deploy Adapter's `listVersions` verb returns the recent version history with the currently-serving version id marked; the `promote` workflow's `versionId` input accepts any id present in this list.",
+      "given": "an operator on a machine authenticated to the deploy vendor",
+      "when": "the operator invokes `deployAdapter.listVersions()` and picks a prior id P then triggers the `promote` workflow with `versionId=P`",
+      "then": "`listVersions` returns a list containing P with the currently-serving flag on the correct entry; the `promote` run succeeds; the deploy-log record names P as `promotedVersionId` and the prior currently-serving id as `previousVersionId`",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12109-2",
+      "description": "The project's source tree contains no separately-authored `rollback` verb that bypasses the `promote` workflow, the deploy-log record, or the post-promote verifier.",
+      "given": "the project source tree",
+      "when": "a scan searches for verbs named `rollback` (or synonyms `revert`, `undoPromote`) that spawn the vendor CLI or issue a vendor deploy call outside the Deploy Adapter",
+      "then": "no such verb exists; every rollback path routes through the `promote` workflow and the Deploy Adapter",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12109-3",
+      "description": "A rollback promote runs the served-surface verifier against the production URL and fails the run if any probe path fails, exactly like a forward promote.",
+      "given": "a promote of a prior version id P that intentionally fails a probe (a probe path P is missing from the older bundle)",
+      "when": "the `promote` workflow completes",
+      "then": "the workflow exits non-zero with `PROMOTE_VERIFY_FAILED`; the failing probe path and the response status are recorded; the deploy-log record does not mark the release successful",
+      "testable": true,
+      "scope": "deployed"
+    }
+  ],
+  "tacIds": [
+    "TAC-1301-deploy-cloudflare-workers-deploy-adapter",
+    "TAC-1304-deploy-cloudflare-workers-promote-gate",
+    "TAC-1305-deploy-cloudflare-workers-served-surface-verifier"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,46 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12110",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-010",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Every promote runs bounded served-surface probes and fails on breach",
+  "asA": "operator answering to a released change",
+  "iWant": "the promote workflow to fail loudly and record diagnostics when the promoted version does not serve correctly",
+  "soThat": "a bad promote never quietly stays in place while the pipeline reports green",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12110-1",
+      "description": "The Served-surface Verifier hits the fixed probe path set against the PRODUCTION URL immediately after `promoteVersion` returns success; every probe is retried up to six times over up to sixty seconds with per-request timeouts of at most five seconds.",
+      "given": "a promote of version W and a project-declared probe set including path `/healthz`",
+      "when": "the verifier runs",
+      "then": "at least one HTTP request to the production URL's `/healthz` completes within the sixty-second window; the request carries no `Authorization` header that would bypass a production auth layer; the retry count for any single probe does not exceed six",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12110-2",
+      "description": "A probe passes when the response status is in the project-declared success set AND the response body carries the expected shape. For the mandatory health probe, `expectShape.versionSha` is substituted at verify time with the promote record's `versionSha` field (the git commit sha the promoted version was built from); the substitution value is NOT the promote record's `promotedVersionId` (the vendor-assigned version UUID), which names a different identifier and will never match the health-probe body.",
+      "given": "a successful promote of W with promote record `{ promotedVersionId: 'v-uuid-W', versionSha: 'sha-W' }` and a `/healthz` probe declared as `{ status: [200], expectShape: { versionSha: '<PROMOTED_VERSION_SHA>' } }`",
+      "when": "the verifier receives the response",
+      "then": "the verifier substitutes `sha-W` into the `expectShape.versionSha` slot before requesting; the probe passes exactly when the status is 200 AND the JSON body's `versionSha` matches `sha-W`; a 200 response whose `versionSha` names a different sha fails the probe",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12110-3",
+      "description": "If any probe path exhausts its retries without passing, the workflow exits non-zero with the stable code `PROMOTE_VERIFY_FAILED` and records the failing probe path, the last response status seen, and the elapsed time to the deploy log.",
+      "given": "a promote of a version whose `/healthz` never returns 200 within the window",
+      "when": "the verifier completes",
+      "then": "the workflow exits non-zero; the exit records include the stable code `PROMOTE_VERIFY_FAILED`; the deploy log entry names the failing probe path, the last status observed, and the elapsed time; the release is not marked successful",
+      "testable": true,
+      "scope": "deployed"
+    }
+  ],
+  "tacIds": [
+    "TAC-1305-deploy-cloudflare-workers-served-surface-verifier",
+    "TAC-1304-deploy-cloudflare-workers-promote-gate"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,45 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12111",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-011",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Local dev-mode is never authoritative for ship coverage",
+  "asA": "engineer authoring runtime-verify tests",
+  "iWant": "the ship gate to refuse a deployed-scope AC bound to a dev-mode probe",
+  "soThat": "no emulator drift can pass for a real runtime signal",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12111-1",
+      "description": "A test case whose runtime probe hits the local dev-mode URL (matching the pattern for the vendor's local emulator, for example `http://localhost:8787` or the `wrangler dev` bound port) is refused as coverage for any AC whose `scope` is `deployed`.",
+      "given": "an AC with `scope: 'deployed'` bound to a TC whose runtime target URL matches the dev-mode pattern",
+      "when": "the coverage gate walks the AC-to-TC bindings",
+      "then": "the gate reports the binding as `DEPLOY_DEV_MODE_INADMISSIBLE`, refuses to count it toward the AC's coverage, and lists the offending TC and its target URL",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12111-2",
+      "description": "A probe against a preview alias URL, a version-id URL, or the production URL is accepted as coverage for a deployed-scope AC.",
+      "given": "an AC with `scope: 'deployed'` bound to a TC whose runtime target URL matches the vendor's preview or production URL patterns",
+      "when": "the coverage gate walks the AC-to-TC bindings",
+      "then": "the gate accepts the binding as valid coverage; the coverage counter increments for the AC",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-12111-3",
+      "description": "The project's runtime-verify catalogue documents the dev-mode drift classes (regular-expression engine differences, static-assets ordering differences, binding-emulation differences, timeout behaviour) so an engineer authoring a probe knows which behaviours cannot be trusted at the local surface.",
+      "given": "the project's runtime-verify catalogue file",
+      "when": "the file is read",
+      "then": "the file names at least four dev-mode drift classes with a one-line example of each and a pointer to the vendor's changelog or release notes where the class is described",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-1305-deploy-cloudflare-workers-served-surface-verifier"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,46 @@
+{
+  "usId": "deploy-cloudflare-workers-US-12112",
+  "prdId": "PRD-001",
+  "reqId": "deploy-cloudflare-workers-REQ-012",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Every uploaded version carries build-provenance readable at runtime",
+  "asA": "operator triaging an incident",
+  "iWant": "one HTTP request to the running Worker to name the commit, the build time, and the CI run URL",
+  "soThat": "the served surface is self-identifying without any dashboard step",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-12112-1",
+      "description": "The `build-and-upload` workflow injects the commit sha, the build ISO 8601 timestamp, and the CI run URL into the Worker's bundle (as build-time constants, as `vars`, or via the Deploy Adapter's `describeVersion` surface); the values are readable from within the Worker at request time.",
+      "given": "a `build-and-upload` run at commit C at time T triggered from CI run R",
+      "when": "the resulting Worker's runtime code reads the provenance surface",
+      "then": "the surface returns an object whose `versionSha` equals C's short sha, whose `builtAt` equals T formatted as ISO 8601, and whose `ciRunUrl` equals R",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12112-2",
+      "description": "A fixed health-probe path (project-declared, `/healthz` by common default) responds with a JSON body carrying stable field names `versionSha`, `builtAt`, and `ciRunUrl` on any deployed URL (preview alias, version id, production).",
+      "given": "a deployed Worker at any of the three URL kinds",
+      "when": "an HTTP GET hits the project's declared health-probe path",
+      "then": "the response body is JSON with fields `versionSha`, `builtAt`, `ciRunUrl`; all three fields are populated with non-empty strings; the response status is in the success set",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-12112-3",
+      "description": "The Served-surface Verifier uses the `versionSha` field on the probe response body (the git commit sha the served version was built from) to confirm the promoted version is the version being served; the value the verifier compares against is the promote record's `versionSha` field, distinct from the promote record's `promotedVersionId` (the vendor-assigned version UUID). A promote whose post-promote probe returns a `versionSha` that does not match the promote record's `versionSha` fails the release.",
+      "given": "a promote of version W with promote record `{ promotedVersionId: 'v-uuid-W', versionSha: 'sha-W' }`",
+      "when": "the verifier's post-promote probe returns a body whose `versionSha` reads `sha-P` (a stale prior version)",
+      "then": "the verifier records the mismatch as `PROMOTE_VERIFY_FAILED` with the observed `sha-P` and the expected `sha-W`; the release is not marked successful",
+      "testable": true,
+      "scope": "deployed"
+    }
+  ],
+  "tacIds": [
+    "TAC-1305-deploy-cloudflare-workers-served-surface-verifier",
+    "TAC-1306-deploy-cloudflare-workers-deploy-ci-workflows"
+  ],
+  "createdAt": "2026-08-30T00:00:00Z",
+  "updatedAt": "2026-08-30T00:00:00Z"
+}

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

@@ -0,0 +1,46 @@
+# deploy-cloudflare-workers blueprint coordination vocabulary
+
+This file is the deploy-cloudflare-workers half of the cross-blueprint contract. The Phase 1 conflict detector matches scope:global ADR topics by EXACT string equality, and AC ids are unnamespaced by the 0.4.4 grammar. Any blueprint intended to compose with this one must reuse these exact strings and respect these bands.
+
+## Global ADR topics this blueprint contributes (exact strings)
+
+| Topic string | deploy-cloudflare-workers contribution | Origin | Composition note |
+|---|---|---|---|
+| `deploymentTarget` | ADR-1301-deploy-cloudflare-workers-deployment-target | Minted here; pre-cleared as unclaimed against application-spa (`clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel`), application-api-rest (`errorEnvelope`, `authModel`, `apiVersioning`, `logging`), security-auth-magic-link (`authModel`), persistence-data-sqlite (`persistenceStore`, `migrationDiscipline`), delivery-ci-workflows (`ciGates`, `strictCoverageGate`), observability-essentials (`healthProbes`, `readinessSemantics`, `statusPageContract`), security-secrets-management (`secretsSource`), and the hello-panel walkthrough exemplar (`operatorPanel`) | The one project-wide model for how bits reach a running target: an artefact-upload + explicit-promote model, versions addressable at stable preview URLs, one adapter as the sole vendor caller, one served-surface verifier on every promote. A composing blueprint that holds a different opinion on the deployment shape (a container-image-per-commit + rolling-deploy blueprint, a coupled-merge-to-production blueprint, a serverless-function-per-endpoint blueprint) contributes its own scope:global ADR on this exact string and lets composition surface the pairing. Expected resolution: one project-level ADR that fixes the deployment shape and the vendor selection |
+
+The deploy-cloudflare-workers blueprint claims one global topic. Every other contribution is scope-local (ADR-1302 through ADR-1305 name the default vendor, the preview-vs-production URL model, the rollback-is-promote posture, and the dev-mode drift posture without contributing global topics; a composing blueprint that holds a different opinion on any of them authors its own project-level ADR if it wants to override).
+
+Rules for new topics (inherited from the application-spa, application-api-rest, security-auth-magic-link, persistence-data-sqlite, delivery-ci-workflows, observability-essentials, and security-secrets-management vocabularies, restated as law): lower camel case, one concept per topic, no version suffixes. A topic names the decision area, not the chosen answer. Do not mint variants of existing strings (`deploy`, `deployVendor`, `deployPipeline`, `shipTarget` are all wrong when `deploymentTarget` already exists).
+
+## Id number bands (registry bootstrap)
+
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.5.0 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (v1.1 candidate).
+
+This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| application-spa | 1101-1899 | 2xx | shipped v1.3.0 | `clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel` |
+| application-api-rest | 2101-2899 | 3xx | shipped v1.0.0 | `errorEnvelope`, `authModel`, `apiVersioning`, `logging` |
+| security-auth-magic-link | 3101-3899 | 5xx | shipped v1.0.0 | `authModel` |
+| email-smtp-resend | 4101-4899 | 4xx | shipped v1.0.0 | none |
+| hello-panel (walkthrough exemplar) | 4101-4899 | 4xx | doc-reserved; teaching exemplar in `packages/rcf-lite/docs/blueprint-authoring-walkthrough.md`, not shipped as a blueprint directory | `operatorPanel` |
+| persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| delivery-ci-workflows | 6101-6899 | 7xx | shipped v2.0.0 (renamed from ci-pipeline) | `ciGates`, `strictCoverageGate`, `releaseArtefacts` |
+| observability-essentials | 7101-7899 | 8xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics`, `statusPageContract` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `secretsSource` |
+| 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` |
+| persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics` |
+
+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.
+
+## Shared expectations for future composing blueprints
+
+- Reuse `deploymentTarget` exactly as spelled here when your blueprint holds an opinion on the project's deployment shape; contribute your own scope:global ADR on that string and let composition surface the pairing. A container-image-per-commit blueprint, a merge-to-production blueprint, or a serverless-function-per-endpoint blueprint will conflict here by design and expect a project-level ADR resolution.
+- Vendor choice sits at ADR-1302 (scope-local) by design: the contract is at ADR-1301, the default is at ADR-1302. A composing blueprint that wants a different DEFAULT vendor without changing the contract does not conflict on `deploymentTarget`; the operator supersedes ADR-1302 with a project-level ADR and swaps the vendor binding.
+- Preview-vs-production URL model (ADR-1303), rollback-is-promote posture (ADR-1304), and dev-mode drift posture (ADR-1305) are scope-local. A composing blueprint that holds an opinion on any of them authors its own project-level ADR; none of them are minted as globals because the space of legitimate variations is smaller than the space of legitimate `deploymentTarget` variations.
+- Global topics that plausibly belong to a future blueprint and are NOT claimed by any shipped blueprint: `messageSerialisation` and `deliverySemantics` (a message-consumer blueprint's natural globals), `caching` (unclaimed by every shipped blueprint), `metricsExport` and `tracingProtocol` (natural globals for a metrics or tracing blueprint), `deploymentPackaging` (unclaimed; a natural global for a container-image or artefact-bundling blueprint that composes above the deploy target). Define any of these in your own package's topics doc, in this file's format, and consider whether the band-registry table above needs your slug added.

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

@@ -0,0 +1,74 @@
+# Deploy Cloudflare Workers blueprint guide
+
+## What it is
+
+A default deployment floor for small greenfield rcf-lite projects that ship to an edge-runtime target. The blueprint contributes the WHAT of a deployment pattern: how the project declares its deploy shape in a repo-root wrangler manifest, how one Deploy Adapter is the sole caller of the deploy vendor, how every merge to the main branch uploads an artefact version reachable at both a permanent per-version-id URL and a stable preview alias URL, how production only changes when the operator triggers an explicit promote workflow, how rollback rides the same promote path with a prior version id supplied, how every promote runs bounded served-surface probes against the production URL, how local dev-mode is refused as coverage for deployed-scope ACs, and how every uploaded version carries build provenance readable at a fixed health probe.
+
+Concretely, the blueprint ships twelve requirements, twelve user stories (thirty-six acceptance criteria), six architecture components, and five architecture decision records. One ADR is `scope: global` on the `deploymentTarget` topic; the other four are scope-local operational ADRs (default vendor, preview-vs-production URL model, rollback-is-promote posture, dev-mode drift posture) that a composing blueprint does not conflict with by default.
+
+## What it is not
+
+Not a vendor CLI. The default vendor named in ADR-1302 is Cloudflare Workers via the `wrangler` CLI, chosen for the zero-infrastructure floor the rcf-lite tier expects. Larger deployments supersede ADR-1302 with a project-level ADR and swap the adapter's vendor binding for Fly, Vercel, a hyperscaler's FaaS surface, or a project-authored target; the ADR-1301 contract stays intact.
+
+Not a promote-approval workflow. The blueprint mandates that production only changes on an explicit operator trigger; who is allowed to hit the trigger and whether a second reviewer must approve first is a CI-platform authorisation concern that layers above the `workflow_dispatch` primitive. A project that wants two-person integrity on every promote wraps the `promote` workflow in the platform's manual-approval primitive.
+
+Not a canary controller. The vendor's own gradual-rollout primitives (percentage-scoped promotes on Cloudflare's `wrangler versions deploy`, or the equivalent on another vendor) are optional operator patterns above the blueprint. The blueprint mandates the served-surface verifier on the eventual full promote; a project running a percentage rollout invokes the verifier on the final 100% promote and adds its own probe cadence during the ramp.
+
+Not an artefact registry. The deploy vendor's own version-upload primitive IS the artefact store. The blueprint does not introduce a container registry, a bundle archive, or an object-storage-backed release store; a project that wants those authors them above the blueprint.
+
+Not a status page. The observability-essentials blueprint owns `statusPageContract`; this blueprint's deploy-log feeds records into whatever status-page implementation the operator wires above. The blueprint fixes the SHAPE of the deploy-log record, not where the records land or how they are rendered to users.
+
+Not the secrets pipeline. The security-secrets-management blueprint owns `secretsSource`; this blueprint consumes the secrets contract for the vendor API token and any application secret bindings the Worker reads at runtime. A project that has not applied the secrets blueprint authors an equivalent contract themselves; the deploy blueprint's REQ-006 references the contract by shape, not by that blueprint's slug.
+
+## When to reach for it
+
+Reach for the deploy-cloudflare-workers blueprint when:
+
+- The project ships to an edge-runtime target or is willing to fit into one; the runtime model (per-request handler, no long-lived process, bindings for storage and compute) matches what the project needs.
+- The default vendor's zero-infrastructure floor is real for the project (no cluster to run, no image registry to feed, no per-region deploy control needed on day one), or the operator is willing to supersede ADR-1302 with a different vendor and swap the adapter's binding.
+- The team wants merge-to-preview and explicit-promote-to-production as a durable pattern, not as a discipline held by convention. The blueprint's promote-is-explicit invariant is enforced at the workflow-file level, not at the reviewer's memory.
+- Rollback needs to sit on the same ship path as forward promote; the same audit trail, the same secret binding, the same served-surface verifier. An incident is the wrong time to discover a bespoke rollback script has drifted.
+- The project is willing to run bounded served-surface probes against the production URL immediately after every promote. A promote that does not verify what it just shipped is not the shape this blueprint contributes.
+- The project is a small greenfield rcf-lite deployment (single Worker or a small Worker fleet, one small team or one solo operator, no ops team standing by) where the zero-infrastructure deploy story is a feature.
+
+## When it does not fit
+
+Do not reach for the deploy-cloudflare-workers blueprint when:
+
+- The project runs a long-lived process (a WebSocket server holding thousands of connections, a queue worker with a heavy warm-up, a stateful game server). The Worker runtime is per-request; the blueprint's contract assumes an artefact-upload + explicit-promote model. A project on a long-lived-process shape wants a different deploy target and a different blueprint.
+- The project has a hard corporate mandate for a specific hyperscaler and there is no useful default to ship on day one because everything already lives in that hyperscaler. Apply the blueprint anyway if you want the ADR-1301 contract, but expect to supersede ADR-1302 with a project-level ADR at apply time and swap the vendor binding.
+- The project requires per-region deploy control finer than what the default vendor's own gradual-rollout primitives support. The blueprint composes cleanly with a canary controller layered above; if the controller is the ship path itself, the blueprint's promote-is-explicit invariant becomes a fit only if the controller wraps the promote workflow rather than replacing it.
+- Compliance requires a deploy audit stream shape different from the one the blueprint fixes (a regulator-mandated field set, a specific SIEM schema). The blueprint fixes the SHAPE of the deploy-log record; a project with a stricter schema supersedes the relevant TAC responsibility with a project-level ADR that names the target schema and the mapping.
+- The deploy target has no working custom-domain or workers.dev production route (a fully self-hosted stack, an air-gapped deployment). The blueprint's URL model assumes both a preview alias URL and a production URL exist and are distinct hostnames; a fully self-hosted target picks a different blueprint (a future `deploy-docker-compose-vps` blueprint at a different altitude would fit).
+
+An earlier design pass scoped a Fly.io-paired shipping candidate (`deploy-fly-io`) alongside this one under a two-or-none rule for accountBound blueprints. The rule was amended (2026-08-30) from a hard shipping gate to demand-driven direction; a second accountBound deploy blueprint mints when demand arrives. Neutrality is served by the ADR-1301 contract, by the vendor-agnostic adapter port at TAC-1301, and by ADR-1302 explicitly reserving Fly.io, Vercel, hyperscaler FaaS, and self-hosted VPS as promotion paths superseded through a project-level ADR.
+
+## What a good outcome looks like
+
+A project applies the blueprint on a fresh tree, declares its Worker in `wrangler.toml` at the repo root (name, main entry, `compatibility_date`, and every binding the Worker reads), picks its preview alias string (`main` is the common default), realises the six TACs in project-authored FBSes with the default `wrangler`-shelling vendor binding, wires the two GHA workflows from the ship assets, and lands on a deployed application where:
+
+- Every merge to main produces an uploaded Worker version reachable at a stable preview alias URL (say `main-app.example.workers.dev`) and at a permanent per-version-id URL (a hostname prefixed by the vendor's version-id primitive). The `build-and-upload` run's summary carries both URLs and the version id.
+- The production URL (say `app.example.com` on a mapped custom domain) is a third, distinct hostname. It continues to serve the previously-promoted version until an operator triggers the `promote` workflow.
+- The `promote` workflow runs on `workflow_dispatch` with an optional `versionId` input. Empty defaults to the newest-of-main resolved through the Deploy Adapter's `resolveNewestOfMain`; a hotfix or rollback supplies an explicit version id from `deployAdapter.listVersions()`.
+- Every promote runs the Served-surface Verifier against the production URL: at least the `/healthz` probe returning a JSON body whose `versionSha` matches the promoted version's build sha, plus one project smoke probe. A probe breach fails the workflow with `PROMOTE_VERIFY_FAILED` and refuses to mark the release successful.
+- Rollback is `promote` with a prior version id supplied. The audit trail is uniform: the same `promotedVersionId`, `promotedBy`, `previousVersionId`, `promotedAt` fields on every promote record, indistinguishable in shape between a forward promote and a rollback.
+- The Worker's health probe answers with the commit sha, the build ISO 8601 timestamp, and the CI run URL that produced the version. A single request to `/healthz` on any of the three URL kinds identifies which version is being served without any dashboard step.
+- The wrangler manifest is safe to review: no secret value lives in it; every secret binding is declared by name only and populated on the deploy target through the secrets contract. A CI redactor guarantees no log line emits any resolved secret value.
+- Tests scoped `deployed` in the RCF coverage tag run against the preview URL, the per-version-id URL, or the production URL; the coverage gate refuses a binding whose target is a dev-mode local URL. Dev-mode remains valid for `runtime`-scope tests and for developer-loop iteration.
+
+## Operator decisions that remain open after apply
+
+- Vendor choice (Cloudflare Workers default, or a superseding project-level ADR selecting Fly.io, Vercel, AWS Lambda, GCP Cloud Run, or a project-authored target). Blueprint owns the contract on both sides of the boundary; project owns the vendor.
+- Preview alias string (`main` common default; project-specific names supported). Blueprint owns the alias-URL discipline; project owns the string.
+- Production URL shape (custom domain mapped through the vendor, or a workers.dev production hostname on projects without a custom domain). Blueprint owns the constraint that production and preview URLs are distinct; project owns the choice.
+- Probe set for the served-surface verifier (the health probe is mandatory; each smoke probe is a project decision informed by the project's own surface). Blueprint owns the retry bounds and the pass criteria; project owns the paths and the expected shapes.
+- Health-probe path (`/healthz` common default; project may pick another). Blueprint owns the response-body shape and its role as verifier evidence; project owns the path.
+- CI platform (GitHub Actions default, ships as a shipped asset; other platforms adapt the trigger stanzas and input handling). Blueprint owns the workflow behaviour; project owns the platform adaptation.
+- Promote authorisation model (the CI platform's own permission model on the manual-trigger primitive, plus any operator-added approval steps). Blueprint owns that promote is an explicit act; project owns who may perform it.
+- Deploy-log sink (a JSONL file in a durable location, an audit event bus, a database table, a status-page ingestion source through the observability-essentials blueprint). Blueprint owns the record shape; project owns where records land.
+- Rollback-window depth (how many prior versions the operator keeps discoverable through `listVersions`). Blueprint owns that rollback IS a promote; project owns the depth policy.
+- Custom-domain provisioning (project-owned; the blueprint does not itself mint DNS or issue TLS). The vendor's own custom-hostname primitive is where the project binds the production URL to a domain it controls.
+
+## 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.

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

@@ -0,0 +1,45 @@
+# Email SMTP Resend blueprint (v1.0.0)
+
+The ninth content blueprint on the rcf-build-lite blueprint mechanism. Scope: a Resend-backed mail-adapter that fills the magic-link blueprint's `TAC-504-security-auth-magic-link-email-delivery-adapter` slot as a shipped default. Transport is Resend's SMTP submission endpoint (keeps the adapter close to a generic SMTP shape a follow-up `email-smtp-<othervendor>` blueprint can sibling cleanly). Vendor default is Resend; the mail-adapter contract itself lives on the magic-link blueprint and remains vendor-neutral. Ships two TACs (send adapter, delivery-webhook verifier), no scope:global ADRs.
+
+## Apply
+
+```
+rcf define blueprint add <path-to>/blueprints/email-smtp-resend
+```
+
+Phase 1 resolves local path sources only; registry and git-ref resolution is a mechanism follow-up. Apply is idempotent; `rcf define blueprint list` shows the applied entry grouped under the `email` category; `rcf define blueprint remove email-smtp-resend` cleanly removes an unreferenced application.
+
+## Anatomy
+
+| Piece | Where | What |
+|---|---|---|
+| Metadata | `blueprint.json` | Slug, version, category `email`, and 16 contributions (all scope-local) |
+| Doc set | `contributions/` | 6 REQs, 6 USs (15 ACs), 2 TACs, 2 ADRs, all schema-valid and namespaced (`email-smtp-resend-REQ-001` prefix family; `TAC-401-email-smtp-resend-send-adapter` suffix family) |
+| Stub adapter reference | `assets/stub-adapter.md` | Record-only test double shape-compatible with the real adapter and with the magic-link blueprint's `TAC-504` interface |
+| From-address rotation pattern | `assets/from-address-rotation-pattern.md` | Generic reference-per-surface routing shape for projects that ship several product surfaces from several verified domains; placeholder values only |
+| Resend verification pointer | `assets/resend-verification-pointer.md` | Public-docs pointer for Resend's sender-domain verification workflow; no embedded checklist |
+| Guide | `guide/email-smtp-resend.md` | Operator-facing: when to use it, when not, what stays your call, the promotion signals for an API-transport supersede and a sibling vendor blueprint |
+| Coordination vocabulary | `docs/topics.md` | The id band this blueprint owns (US 4101-4899, ADR/TAC 4xx), the shared id-band registry across the shipped set, and the reason this blueprint contributes zero scope:global topics |
+
+The doc set is contributions (copied into the project tree by `rcf define blueprint add`); the guide, assets, and docs are package-resident references. Guide rendering into `rcf/knowledge/docs/blueprint-guides/` and asset ingestion are mechanism follow-ups; until they land, the working agent reads them from the applied blueprint's source path recorded in `manifest.blueprints[].source`.
+
+## What it contributes, and what it deliberately does not
+
+Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (ratified decision 5) and no code.
+
+No FBS contributions, as a matter of principle (ratified policy 2026-08-19): FBSes are the work of the implementing agent, not the blueprint; project constraints have to be applied at the time of creation. The blueprint contributes the WHAT (the send-contract shape, the SMTP transport choice, the four-class error taxonomy, the retry-and-backoff posture, the webhook signature verification, the replay defence, the boundary discipline on the SMTP client library and the secret references); the implementing agent derives the HOW-tasks (FBS) in the host project, where the ACs contributed here get picked up by the project's own build sequencing.
+
+Deliberately not contributed: the magic-link blueprint's auth routes themselves (they live on the magic-link blueprint; this blueprint is an ADAPTER only); the mail-adapter interface as a global topic (the interface belongs to the magic-link blueprint's `TAC-504`, not to this blueprint); an SMTP client library or an HTTP client library (project picks from what it already carries; the adapter injects the client at boot); a specific YAML or JSON schema library; a Secrets Manager client (composable with the shipped `security-secrets-management` blueprint or with a project-authored secret-reference resolver of the same shape); a shared event bus for delivery events (the verifier hands parsed events to a downstream handler the project realises; where those events go beyond the handler is a project concern); regulatory or compliance workflow (double-opt-in surfaces, unsubscribe UI, retention of consent records live outside this blueprint's scope); the Resend HTTP API path (project supersedes ADR-401 and swaps the adapter's internal client if the API path is preferred, without changing the interface the auth routes call).
+
+## The zero-global-topic story
+
+This blueprint contributes no `scope: "global"` ADR topics on purpose. The mail-adapter contract is owned upstream on the magic-link blueprint's `TAC-504`; the transport choice and the retry posture are project-local decisions a project can supersede with a project-level ADR without cross-blueprint conflict. Neither is a shared vocabulary a composing blueprint needs to conflict with by string equality. See `docs/topics.md` for the exact reasoning, the id-band allocation (US 4101-4899, ADR/TAC suffix block 4xx), and the shared-registry table.
+
+## Quality bar
+
+One `send({ to, subject, textBody, htmlBody })` method as the sole auth-facing surface; the fixed outcome shape `{ ok, providerStatus, providerMessageId, error }` on every call; exactly one SMTP submission per adapter call on the successful path; four-class error taxonomy (`RESEND_RATE_LIMITED`, `RESEND_SENDER_UNVERIFIED`, `RESEND_RECIPIENT_REJECTED`, `RESEND_TRANSPORT_ERROR`) surfaced on the `error` field with no recipient identity leaked; bounded jittered retry on transient classes and immediate return on terminal classes; webhook signature verification against the configured signing secret with constant-time comparison; HTTP 401 empty-body refusal on mismatch with a `webhookVerificationFailed` audit; stale-timestamp refusal against the configured tolerance window with a `webhookReplayStale` audit; duplicate-event-id refusal against a bounded event-id store with a `webhookReplayDuplicate` audit and HTTP 200 acknowledgement; the SMTP client library imported from exactly one module (the adapter); no literal SMTP credential, sender address, or signing secret in adapter source. Every bar is carried by ACs in the doc set, not by this README.
+
+## Known mechanism-reach gaps
+
+None at v1.0.0. Every AC on every story is bound to at least one TAC that the host project must realise, and every AC's `then` clause is runtime-observable in the deployed application (SMTP submission counters for send-side ACs, byte-scan for recipient-identity suppression, HTTP status and audit-sink observation for webhook ACs, source-tree import-graph scan for the SMTP-client boundary property, source-scan for the no-literal-credential property). The mechanism-reach principle from the authoring standard section 7 is satisfied at ship: a project that applies this blueprint and does not realise a TAC leaves an unresolved `tacIds` reference on the story that `rcf define validate` and `rcf audit coverage` refuse. The one operational surface a project must own on its own is the SMTP client library selection and the event-id store choice (an in-memory LRU for a single-process deployment, a shared store for a horizontally-scaled deployment); each is stated as a TAC interface, not as a smuggled runtime probe. The one AC whose runtime observability depends on operator readiness is AC-4101-2 (the happy-path successful send), which requires a verified sender domain with the provider; the AC is scoped to a running project whose configuration passes verification, and the `assets/resend-verification-pointer.md` pointer names where the operator completes that work.