rcf-lite 0.13.0 → 0.14.0

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6114.json

@@ -0,0 +1,46 @@
+{
+  "usId": "delivery-ci-workflows-US-6114",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-014",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The feature-branch shape materialises pull-request-checks and default-branch-checks",
+  "asA": "operator on a feature-branch project with delivery-ci-workflows v2 applied",
+  "iWant": "the workflow-materialiser to produce two workflows (pull-request-checks and default-branch-checks) sharing the same required check set",
+  "soThat": "every push to the default branch and every pull request against it is gated identically and my merge policy has one aggregate to bind to",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6114-1",
+      "description": "With `workflowShape.branchModel: feature`, the materialiser produces a `pull-request-checks` workflow triggered by pull requests targeting the default branch. The workflow invokes the Node gate-runner entry point (TAC-701) with the required check set (mandatory tier plus every `checkSet` flag set true).",
+      "given": "a `workflowShape` with `branchModel: feature` and every `checkSet` flag true",
+      "when": "the workflow-materialiser runs",
+      "then": "a `pull-request-checks` workflow file lands at the provider's workflow path, its trigger set names pull requests against the default branch, and its command line invokes the Node gate-runner entry point with the required check set",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6114-2",
+      "description": "With `branchModel: feature`, the materialiser additionally produces a `default-branch-checks` workflow triggered by pushes to the default branch. The workflow invokes the same Node gate-runner entry point on the same required check set.",
+      "given": "the same `workflowShape`",
+      "when": "the workflow-materialiser runs",
+      "then": "a `default-branch-checks` workflow file lands at the provider's workflow path, its trigger set names pushes to the default branch, and its command line invokes the Node gate-runner entry point with the required check set",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6114-3",
+      "description": "The AC contract requires the project to configure default-branch protection (or the platform equivalent) to require the `pull-request-checks` aggregate as a merge-blocking check. The blueprint states the property; the configuration itself lives on the platform surface.",
+      "given": "a feature-branch project with the two workflows materialised",
+      "when": "a pull request whose most recent `pull-request-checks` aggregate report records `verdict: failed` is submitted for merge",
+      "then": "the platform refuses the merge and the refusal reason references the failed `pull-request-checks` required check",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "TAC-701-delivery-ci-workflows-gate-runner"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6115.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6115",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-015",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The trunk shape materialises default-branch-checks and optionally pull-request-checks",
+  "asA": "operator on a trunk-based project with delivery-ci-workflows v2 applied",
+  "iWant": "the workflow-materialiser to produce `default-branch-checks` always, plus `pull-request-checks` when I opt into the sub-shape",
+  "soThat": "my trunk-based project gates every commit to trunk and only ships a PR workflow when I actually use PRs",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6115-1",
+      "description": "With `workflowShape.branchModel: trunk` and `trunkPullRequests` absent or `never`, the materialiser produces `default-branch-checks` only. The `pull-request-checks` workflow does not ship in this shape.",
+      "given": "a `workflowShape` with `branchModel: trunk` and no `trunkPullRequests` field",
+      "when": "the workflow-materialiser runs",
+      "then": "a `default-branch-checks` workflow file lands at the provider's workflow path, no `pull-request-checks` workflow file lands, and the merge-policy AC binds to the trunk-branch push-protection property",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6115-2",
+      "description": "With `branchModel: trunk` and `trunkPullRequests: sometimes`, the materialiser additionally produces `pull-request-checks` on the same required check set as `default-branch-checks`.",
+      "given": "a `workflowShape` with `branchModel: trunk` and `trunkPullRequests: sometimes`",
+      "when": "the workflow-materialiser runs",
+      "then": "both workflow files land at the provider's workflow path, and the merge-policy AC binds to the default-branch-protection property that admits only PRs whose `pull-request-checks` aggregate passed",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "TAC-701-delivery-ci-workflows-gate-runner"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6116.json

@@ -0,0 +1,28 @@
+{
+  "usId": "delivery-ci-workflows-US-6116",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-016",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The linter check produces a stable-shape lint report and fails non-zero on any lint error",
+  "asA": "operator whose project enables the elicited linter check",
+  "iWant": "a lint gate whose report shape and exit-code semantic are stable across projects",
+  "soThat": "downstream readers (dashboards, merge queues) can consume lint outcomes without per-project scraping",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6116-1",
+      "description": "When `checkSet.linter` is true, the gate-runner runs the project-realised linter runner, captures its exit code and streams, and writes the per-gate report to `.rcf/reports/ci/lint.json` with `checkKind: \"linter\"`. A non-zero exit code from the runner flips the gate outcome to `failed`.",
+      "given": "a project with `checkSet.linter: true` and a realised linter runner satisfying the runner-contract interface",
+      "when": "a CI workflow invokes the gate-runner",
+      "then": "a report file at `.rcf/reports/ci/lint.json` is written with `checkKind: \"linter\"`, and the gate outcome tracks the runner exit code",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6117.json

@@ -0,0 +1,28 @@
+{
+  "usId": "delivery-ci-workflows-US-6117",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-017",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The formatter check runs in check mode and fails non-zero on any unformatted file",
+  "asA": "operator whose project enables the elicited formatter check",
+  "iWant": "a formatter gate that CHECKS (not writes) and fails on any file the formatter would rewrite",
+  "soThat": "unformatted commits are caught in CI rather than masked by a rewrite step",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6117-1",
+      "description": "When `checkSet.formatter` is true, the gate-runner runs the project-realised formatter runner in check mode. A non-zero exit code from the runner (indicating one or more files would be rewritten) flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/format.json` carries `checkKind: \"formatter\"`.",
+      "given": "a project with `checkSet.formatter: true` and a realised formatter runner in check mode",
+      "when": "a CI workflow invokes the gate-runner",
+      "then": "a report file at `.rcf/reports/ci/format.json` is written with `checkKind: \"formatter\"`, and the gate outcome tracks the runner exit code",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6118.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6118",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-018",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The typecheck runs when the project has a typechecker configured and fails non-zero on any type error",
+  "asA": "operator whose project uses a typechecked language",
+  "iWant": "the typecheck gate to run when my project has a typechecker configured and be off when it does not",
+  "soThat": "the default aligns with project shape without me writing an explicit override",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6118-1",
+      "description": "When `checkSet.typecheck` is true (or the auto-detect finds a `tsconfig.json` or equivalent tool marker at the project root and the flag is unset), the gate-runner runs the project-realised typecheck runner. A non-zero exit flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/typecheck.json` carries `checkKind: \"typecheck\"`.",
+      "given": "a project with `checkSet.typecheck: true` and a realised typecheck runner",
+      "when": "a CI workflow invokes the gate-runner",
+      "then": "a report file at `.rcf/reports/ci/typecheck.json` is written with `checkKind: \"typecheck\"`, and the gate outcome tracks the runner exit code",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6118-2",
+      "description": "When `checkSet.typecheck` is unset and the project tree contains no `tsconfig.json` or equivalent tool marker, the auto-detect leaves the check off and no `typecheck.json` report file is written.",
+      "given": "a project with `checkSet.typecheck` unset and no typechecker marker at the project root",
+      "when": "a CI workflow invokes the gate-runner",
+      "then": "no `typecheck` gate is included in the aggregate report and no `.rcf/reports/ci/typecheck.json` file is written",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6119.json

@@ -0,0 +1,28 @@
+{
+  "usId": "delivery-ci-workflows-US-6119",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-019",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The unit-test check runs the project suite as a gate and fails non-zero on any failing test",
+  "asA": "operator whose project has a unit-test suite",
+  "iWant": "a unit-test gate whose exit-code and report shape are the same as every other elicited check",
+  "soThat": "the aggregate report treats unit tests as one gate among many with the same downstream contract",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6119-1",
+      "description": "When `checkSet.unitTest` is true, the gate-runner runs the project-realised unit-test runner. A non-zero exit code flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/test.json` carries `checkKind: \"unitTest\"`.",
+      "given": "a project with `checkSet.unitTest: true` and a realised unit-test runner",
+      "when": "a CI workflow invokes the gate-runner",
+      "then": "a report file at `.rcf/reports/ci/test.json` is written with `checkKind: \"unitTest\"`, and the gate outcome tracks the runner exit code",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6120.json

@@ -0,0 +1,28 @@
+{
+  "usId": "delivery-ci-workflows-US-6120",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-020",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The security-scan check fails non-zero on findings at or above the project severity threshold",
+  "asA": "operator whose project enables the elicited security-scan check",
+  "iWant": "a security-scan gate whose exit code is driven by the project-configured severity threshold, not a build-in choice",
+  "soThat": "the gate applies across risk postures without changing the tool or the report shape",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6120-1",
+      "description": "When `checkSet.securityScan` is true, the gate-runner runs the project-realised security-scan runner. A non-zero exit code (indicating one or more findings at or above the project-configured severity threshold) flips the gate outcome to `failed`. Findings below the threshold are recorded in the per-gate report without flipping the exit code. The per-gate report at `.rcf/reports/ci/security.json` carries `checkKind: \"securityScan\"`.",
+      "given": "a project with `checkSet.securityScan: true` and a realised security-scan runner configured with the project's severity threshold",
+      "when": "a CI workflow invokes the gate-runner",
+      "then": "a report file at `.rcf/reports/ci/security.json` is written with `checkKind: \"securityScan\"`, and the gate outcome tracks the runner exit code",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6121.json

@@ -0,0 +1,46 @@
+{
+  "usId": "delivery-ci-workflows-US-6121",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-021",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The release workflow shape scales with the releaseMode dimension",
+  "asA": "operator declaring a release path on delivery-ci-workflows v2",
+  "iWant": "the release workflow the materialiser produces to scale with what my project has already declared (no release, tag only, tag plus artefact, or handoff to deploy)",
+  "soThat": "I choose the maturity level of my release path once and the workflow set follows",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6121-1",
+      "description": "When `workflowShape.releaseMode` is `none`, the workflow-materialiser writes no `release` workflow file to the provider's workflow path. A project with no release path does not ship a workflow.",
+      "given": "a `workflowShape` with `releaseMode: none`",
+      "when": "the workflow-materialiser runs",
+      "then": "no `release` workflow file is created at the provider's workflow path and no `.rcf/reports/ci/release.json` file is written",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6121-2",
+      "description": "When `releaseMode` is `tagOnly`, the release workflow fires on a release trigger and creates a release entity on the CI provider's own release surface. No artefact-publish step ships. When `tagPlusArtefact`, the release workflow additionally runs the project-realised artefact-publish step and uploads its output to the release entity.",
+      "given": "a `workflowShape` with `releaseMode: tagPlusArtefact` and a realised artefact-publish step",
+      "when": "a release trigger fires",
+      "then": "the release workflow creates the release entity, runs the artefact-publish step, uploads the published artefact to the release entity, and records the just-published version identifier in the aggregate report",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6121-3",
+      "description": "The release workflow does not include the required check set. Its aggregate report at `.rcf/reports/ci/release.json` carries the release-flow outcome (tag creation, artefact publish, optional deploy handoff) and not the gate-runner outcome.",
+      "given": "a release workflow materialised in any non-`none` mode",
+      "when": "the release trigger fires",
+      "then": "the release workflow does not invoke the gate-runner entry point and the `pipeline.json` at the same commit remains the record of the check set outcome",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "TAC-705-delivery-ci-workflows-release-workflow"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6122.json

@@ -0,0 +1,46 @@
+{
+  "usId": "delivery-ci-workflows-US-6122",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-022",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The deployHandoff release mode invokes the deploy blueprint's promote workflow and refuses at boot when that blueprint is absent",
+  "asA": "operator declaring a paired service on delivery-ci-workflows v2",
+  "iWant": "the release workflow to hand off to the named deploy blueprint's promote workflow after the artefact-publish step succeeds",
+  "soThat": "the CI-side and deploy-side workflows compose without either duplicating the other's WHAT",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6122-1",
+      "description": "When `workflowShape.releaseMode` is `deployHandoff:<slug>` and the named deploy blueprint is present in `manifest.blueprints[]`, the release workflow invokes the deploy blueprint's `promote` workflow via `workflow_dispatch` after the artefact-publish step succeeds. The invocation passes the just-published version identifier as the `versionId` input.",
+      "given": "a `workflowShape` with `releaseMode: deployHandoff:deploy-cloudflare-workers`, the named deploy blueprint applied, and an artefact-publish step that succeeded",
+      "when": "the release trigger fires",
+      "then": "the release workflow dispatches the promote workflow with `versionId` set to the just-published version identifier and waits on the promote workflow's outcome",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6122-2",
+      "description": "The release workflow's aggregate outcome is `passed` only when the promote workflow's outcome is `passed`. A failed promote workflow flips the release workflow's aggregate to `failed`.",
+      "given": "a release workflow in `deployHandoff` mode whose promote workflow returned a failed outcome",
+      "when": "the release workflow aggregates its outcome",
+      "then": "the release workflow's aggregate report at `.rcf/reports/ci/release.json` records `verdict: failed` and names the promote workflow's failure in its `gates[]` array",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6122-3",
+      "description": "When `releaseMode` is `deployHandoff:<slug>` and the named deploy blueprint is not present in `manifest.blueprints[]`, the workflow-materialiser boot-check refuses with a stable-coded error naming the missing blueprint slug and pointing at `rcf define blueprint add <deploy-slug>`.",
+      "given": "a `workflowShape` with `releaseMode: deployHandoff:deploy-cloudflare-workers` and no such blueprint in the manifest",
+      "when": "the workflow-materialiser boots",
+      "then": "the materialiser exits non-zero with a stable-coded error naming the missing slug and pointing at the resolution command, and no release workflow file lands on disk",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "TAC-705-delivery-ci-workflows-release-workflow"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6123.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6123",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-023",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The scheduledAudit dimension materialises a cron workflow running the required check set on cadence",
+  "asA": "operator wanting to catch dependency drift and secret rotations between merges",
+  "iWant": "to opt into a scheduled workflow that runs the same required check set on a cron cadence",
+  "soThat": "drift that does not coincide with a merge is caught rather than missed until the next unrelated PR",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6123-1",
+      "description": "When `workflowShape.scheduledAudit` is `true`, the workflow-materialiser produces a `scheduled-audit` workflow triggered by the provider's cron surface, running the same required check set the pull-request and default-branch workflows run. The aggregate report writes to `.rcf/reports/ci/scheduled-audit.json` (distinct from the commit-triggered `pipeline.json`).",
+      "given": "a `workflowShape` with `scheduledAudit: true`",
+      "when": "the workflow-materialiser runs",
+      "then": "a `scheduled-audit` workflow file lands at the provider's workflow path, its trigger set names a cron schedule, and its command line invokes the Node gate-runner entry point with the required check set writing to the distinct report path",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6123-2",
+      "description": "When `scheduledAudit` is `false` or absent, no scheduled workflow ships and no `.rcf/reports/ci/scheduled-audit.json` file path is populated.",
+      "given": "a `workflowShape` with `scheduledAudit` absent (default `false`)",
+      "when": "the workflow-materialiser runs",
+      "then": "no `scheduled-audit` workflow file is created and no `.rcf/reports/ci/scheduled-audit.json` file path is written",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "TAC-706-delivery-ci-workflows-scheduled-audit"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/docs/topics.md

@@ -0,0 +1,61 @@
+# delivery-ci-workflows blueprint coordination vocabulary
+
+This file is the delivery-ci-workflows 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 | delivery-ci-workflows contribution | Origin | Composition note |
+|---|---|---|---|
+| `ciGates` | ADR-701-delivery-ci-workflows-ci-gates | Minted at v1 by the ci-pipeline predecessor; broadened at v2.0.0 to name the required check set (mandatory tier plus elicited subset from `workflowShape.checkSet`) | The required check set every commit-triggered workflow runs. Any composing blueprint that ships its own required-check opinion (an adherence-pack blueprint, a browser-verify blueprint, an observability probe 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 extended catalogue and states the reasoning |
+| `strictCoverageGate` | ADR-702-delivery-ci-workflows-strict-coverage-gate | Preserved verbatim from v1 | The coverage-mode posture for the required gate (per-AC strict, not shallow-any). A composing blueprint that holds an opinion on coverage-mode policy (a shallow-any-for-early-projects blueprint, a coverage-with-grace-window blueprint) conflicts here by design. Expected resolution: one project-level ADR fixing the coverage posture |
+| `releaseArtefacts` | ADR-709-delivery-ci-workflows-release-artefacts | **Minted at v2.0.0** | The decision area of what the release workflow produces on a release trigger. The delivery-side answer is the four-mode `releaseMode` enumeration (`none`, `tagOnly`, `tagPlusArtefact`, `deployHandoff:<slug>`). A future `security-release-provenance` blueprint (minting a signature-attestation opinion) or a `delivery-release-notes` blueprint (minting a changelog opinion) 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 extended answer |
+
+The delivery-ci-workflows blueprint claims three global topics at v2.0.0 (`ciGates` broadened, `strictCoverageGate` preserved, `releaseArtefacts` new). Every other contribution is scope-local; a composing blueprint that holds an opinion on runner language, report shape, elicitation surface, branch model, release workflow shape, provider hint, or scheduled audit authors its own project-level ADR if it wants to override.
+
+### Deliberate conflicts declared
+
+Where this blueprint's set overlaps other blueprints' topics, the resolution paths are documented at authoring rather than left to composition-time surprise:
+
+- **`ciGates` vs any future adherence-pack or browser-verify blueprint**: expected conflict on the `ciGates` string. Resolution: the project-level ADR names the extended catalogue including the composing blueprint's checks.
+- **`releaseArtefacts` vs any future `security-release-provenance` blueprint**: expected conflict on the `releaseArtefacts` string. Resolution: the project-level ADR fixes the artefact production shape including signatures and provenance blocks.
+- **`releaseArtefacts` vs any future `delivery-release-notes` blueprint**: expected conflict on the `releaseArtefacts` string (release notes are one kind of artefact the release workflow produces). Resolution: the project-level ADR names the release-notes production alongside the artefact publish step.
+
+`branchModel` is deliberately NOT minted as a global topic. No shipped or plausible sibling blueprint has a legitimate opinion on branch model choice; minting the string would create a resolution surface for a conflict that would not materialise. If evidence emerges to the contrary, `branchModel` can be minted in a v2.x minor bump.
+
+Note on the delineation from the application-api-rest blueprint's `logging` topic and the persistence-data-sqlite blueprint's store event log: `logging` (owned by application-api-rest ADR-304) governs the wire-log shape of the HTTP tier; persistence ADR-603 governs the store-event log shape. This blueprint's report shape (ADR-704) governs the pipeline-run report shape, which is a build-time artefact, not a runtime log. The three surfaces may share a shipper but do not share a topic. A blueprint that contributes a unified telemetry discipline across build-time and runtime surfaces would author its own scope:global ADR and expect to conflict with all three, not just here.
+
+Rules for new topics (inherited from the application-spa, application-api-rest, security-auth-magic-link, and persistence 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 (`ciChecks`, `pipelineGates`, `strictCoverage`, `coverageStrict` are all wrong when `ciGates` and `strictCoverageGate` already exist).
+
+## Id number bands (registry bootstrap)
+
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (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 6101-6110 sit at the LOW end of the 6101-6899 band on purpose. A project-side story that mechanically derives from `delivery-ci-workflows-REQ-011` into the number `6111` would collide against delivery-ci-workflows-US-6111 in this package; the band leaves headroom at the HIGH end (US 6181-6899) so a project's own stories anchored to delivery-ci-workflows REQs can allocate without conflict. The watchpost run4 lesson applies here too.
+
+## Shared expectations for future composing blueprints
+
+- Reuse `ciGates` exactly as spelled here when your blueprint holds an opinion on the required check set every commit-triggered workflow runs; contribute your own scope:global ADR on that string and let composition surface the pairing. An observability-essentials blueprint that ships health-probe or status-page gates as required will conflict here by design.
+- Reuse `strictCoverageGate` exactly as spelled here when your blueprint holds an opinion on the coverage-mode policy (strict per-AC versus shallow-any versus grace-window); a blueprint that ships a different posture conflicts here.
+- Reuse `releaseArtefacts` exactly as spelled here when your blueprint holds an opinion on what the release workflow produces on a release trigger (an artefact-signing opinion, a provenance-block opinion, a release-notes opinion); contribute your own scope:global ADR on that string and expect a project-level ADR to fix the extended answer.
+- This blueprint's decision at v2.0.0 states the mandatory tier (`validate` and `coverage-strict` in that order) plus the elicited tier (linter, formatter, typecheck, unitTest, securityScan) driven by `workflowShape.checkSet`, the four-mode `releaseMode` enumeration on `releaseArtefacts`, the Node-only entry-point shape (ADR-703), and the report shape (ADR-704 with the v2 `checkKind` addition). Compose compatible adherence packs, browser-verify shipping, or observability probes, or expect the operator to supersede with one project-level ADR per topic.
+- Global topics that plausibly belong to a future blueprint and are NOT claimed by any shipped blueprint: `adherencePack` (an adherence-shipping blueprint's natural global), `mutationSampling` (a mutation-testing blueprint's natural global). 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/delivery-ci-workflows/guide/delivery-ci-workflows.md

@@ -0,0 +1,136 @@
+# delivery-ci-workflows blueprint guide
+
+## What it is
+
+The default CI floor for rcf-lite projects, expressed as a workflow SET the operator declares once and the workflow-materialiser produces from that declaration. The blueprint contributes the WHAT of the workflow set: which workflows exist per branch model, which required check set every check-set workflow runs, what the release workflow does per release mode, what the scheduled-audit workflow does when enabled, and what report files land on disk after every run. Each workflow is a single Node entry point the CI job invokes with one line; the elicitation surface is the four required plus two optional fields of `workflowShape` in `.rcf/config/delivery-ci-workflows.json` on the project tree.
+
+Concretely, the blueprint ships 23 requirements, 23 user stories (roughly 50 acceptance criteria), 6 architecture components, and 10 architecture decision records. Three ADRs are `scope: global` on the topics `ciGates` (the required check set every commit-triggered workflow runs), `strictCoverageGate` (the per-AC strict coverage posture), and `releaseArtefacts` (the four-mode release workflow shape); the other seven ADRs are scope-local.
+
+## What it is not
+
+Not a matrix of provider-specific configuration files. v2.0.0 ships one illustrative GitHub Actions workflow file per workflow the matrix materialises under `assets/ci-provider-examples/github-actions/` (`pull-request-checks.yml`, `default-branch-checks.yml`, `release.yml`, `scheduled-audit.yml`) as copy-paste starting points. Alternate providers (GitLab CI, CircleCI, Buildkite, Jenkins) wire the same Node entry points per the four-point mapping named below applied to each workflow; the blueprint does not carry per-provider configuration files for those runners at v2.0.0.
+
+Not a source-code contribution. The blueprint contributes the workflow-materialiser contract, the gate-runner contract, the release-workflow contract, the scheduled-audit contract, the per-gate report writer contract, the aggregate report writer contract, and the discipline that binds them. The project realises the Node entry points against those contracts in its own build cycle; the blueprint does not ship the entry-point source.
+
+Not a choice of linter, formatter, typechecker, test runner, or security scanner. The elicited check catalogue names the check kinds; the project picks the tools that satisfy the runner-contract interfaces. A code-formatting style guide, a security-scan severity threshold, and the linter rule set are all project decisions the blueprint does not opine on.
+
+Not a release-mechanism. The release workflow reacts to a tag or a `workflow_dispatch`; the project creates the tag through its own release mechanism (a `standard-version` invocation, a manual git tag, a release-please bot). The blueprint does not ship a tag-creation workflow, a changelog generator, or a version-bump tool.
+
+Not a merge-queue integration or a coverage-trend dashboard. A project that wants either reads the aggregate reports from the queue tool or the dashboard of its choice; the blueprint owns the aggregate report shapes and stability, not the reader wiring.
+
+Not a branch-protection or merge-policy configuration. AC-6101-2, AC-6114-3, AC-6115-1, and AC-6115-2 state the property the project owes on the platform's own configuration surface per branch model; the blueprint does not ship the configuration file.
+
+## When to reach for it
+
+Reach for the `delivery-ci-workflows` blueprint when:
+
+- The project is an rcf-lite deployment with an RCF chain and a default or trunk branch.
+- The project's CI provider can run Node 24 or later on its runner (every mainstream provider can).
+- The project wants the required check set (RCF chain plus enabled elicited checks) to be a merge-blocking property, not an author-time habit.
+- The project wants a stable per-run report artefact any downstream reader (dashboard, audit tool, merge queue) can pick up without scraping the CI provider's log surface.
+- The project wants a release workflow that scales with what the project has already declared (from `none` for internal packages up to `deployHandoff:<slug>` for paired services).
+
+## When it does not fit
+
+Do not reach for the `delivery-ci-workflows` blueprint when:
+
+- The project does not use RCF (no `rcf/` tree, no `rcf define validate` invocation makes sense).
+- The project runs on a CI provider whose runners cannot execute Node 24 or later.
+- The project wants a coverage-mode grace window on newly introduced ACs (supersede ADR-702 with a project-level ADR stating the grace window).
+- The project wants required checks that are not in the catalogue and not naturally cross-blueprint (a mutation-testing gate, an accessibility scan). Supersede ADR-701 with a project-level ADR listing the extended catalogue and register the check under `custom:<name>`.
+
+## What a good outcome looks like
+
+A project applies the `delivery-ci-workflows` blueprint on a fresh tree, populates `.rcf/config/delivery-ci-workflows.json` with its `workflowShape` (four required fields plus any optional ones), realises the six TACs in project-authored FBSes, and lands on a deployed workflow set where:
+
+- Every commit-triggered event fires the appropriate workflow (per branch model). The workflow's aggregate report at `.rcf/reports/ci/pipeline.json` records the trigger, the timing, and the ordered gate outcomes including the `checkKind` per gate.
+- A pull request whose head commit fails any required check sees the failed check in the aggregate, sees the specific issue in the per-gate report, and cannot be merged through the platform's standard merge path.
+- A pull request whose head commit passes every required check sees `verdict: passed` in the aggregate, sees green on the platform's required-check surface, and can be merged.
+- A release trigger fires the release workflow per `releaseMode`: `none` means no workflow at all; `tagOnly` creates a release entity; `tagPlusArtefact` also publishes an artefact; `deployHandoff:<slug>` also invokes the named deploy blueprint's promote workflow with the `versionId` input.
+- When `scheduledAudit: true`, the scheduled-audit workflow fires on a cron cadence and writes to `.rcf/reports/ci/scheduled-audit.json`, distinct from commit-triggered `pipeline.json`.
+- A developer reproducing a CI failure on their machine runs the same one-line invocation the CI job's step recorded and sees the same per-gate outcomes at the same report paths.
+
+## The workflowShape declaration (four dimensions plus two optional)
+
+The project ships `.rcf/config/delivery-ci-workflows.json` at the project root. The declaration has three required fields, one optional field with defined default semantics, and two optional dimensions.
+
+```json
+{
+  "workflowShape": {
+    "branchModel": "feature",
+    "checkSet": {
+      "linter": true,
+      "formatter": true,
+      "typecheck": true,
+      "unitTest": true,
+      "securityScan": true
+    },
+    "releaseMode": "tagPlusArtefact",
+    "providerHint": "githubActions",
+    "scheduledAudit": false
+  }
+}
+```
+
+- `branchModel` (required): `feature` or `trunk`.
+- `checkSet` (required): object of booleans keyed by elicited-check name.
+- `providerHint` (required): `githubActions`, `gitlabCi`, `circleCi`, `buildkite`, or `jenkins`.
+- `releaseMode` (OPTIONAL, Q6-B ratification): `none`, `tagOnly`, `tagPlusArtefact`, or `deployHandoff:<slug>`. An absent field is treated the same as `none` (no release workflow ships). Not having a release path yet is a common scenario when starting a project; the ratification chose ergonomics over an explicit `none`.
+- `scheduledAudit` (optional): boolean; default `false`.
+- `trunkPullRequests` (optional; qualifies `branchModel: trunk`): `never` or `sometimes`; default `never`.
+
+### Profile aliases
+
+Named profile aliases (`smallLibrary`, `smallService`, `internalPackage`, `trunkLibrary`) compose the four-field form. The materialiser expands the alias to the four-field form at boot; every AC binds to the four-field form. Adding an alias is a minor bump; renaming or removing an alias is a minor bump.
+
+## The check catalogue
+
+Two tiers:
+
+- **Mandatory tier** (preserved from v1): `validate` (running `rcf define validate`) then `coverage-strict` (running `rcf audit coverage --strict`), in that order.
+- **Elicited tier** (v2 additions): `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`. Default: every catalogued check on. Per-check auto-detection may adjust the default (typecheck defaults on when the project tree contains a `tsconfig.json` or equivalent tool marker).
+
+Each elicited check ships an AC contract stating what its runner must produce: a non-zero exit code on any blocking finding, a per-gate report at the check's stable path, and a `checkKind` field naming the check kind. The blueprint does NOT ship the linter, formatter, typechecker, test runner, or scanner; the project picks the tools.
+
+Custom checks (`custom:<name>`) supersede this ADR at the project level and register alongside the catalogued checks in the aggregate.
+
+## The four release modes
+
+`releaseMode` scales what the release workflow does:
+
+- `none` (or absent, per Q6-B ratification): no release workflow ships.
+- `tagOnly`: on a release trigger, creates a release entity on the provider's release surface (a GitHub Release, a GitLab release).
+- `tagPlusArtefact`: on a release trigger, creates the release entity and runs the project-realised artefact-publish step, uploading the artefact to the release entity.
+- `deployHandoff:<slug>`: on a release trigger, runs the tagPlusArtefact flow and then dispatches the named deploy blueprint's `promote` workflow via `workflow_dispatch` with the just-published version identifier as the `versionId` input.
+
+The release workflow does NOT invoke the required check set: that already ran on the `default-branch-checks` workflow at the commit the release points at.
+
+The `deployHandoff:<slug>` mode has a manifest boot-check: the materialiser refuses when the named deploy blueprint is absent from `manifest.blueprints[]`.
+
+## Wiring alternate CI providers (four-point mapping applied per workflow)
+
+Every mainstream CI provider ships the same four ingredients under a different runner language. The blueprint's Node entry points are the fourth ingredient (one per workflow); the other three are provider-specific. The illustrative GitHub Actions workflow files show all four applied per workflow; alternate providers translate the first three and keep the fourth unchanged per workflow:
+
+1. Job trigger. The trigger set per workflow (pull_request into the target branch for `pull-request-checks`; push to the target branch for `default-branch-checks`; release event or workflow_dispatch for `release`; cron schedule for `scheduled-audit`).
+2. Node setup.
+3. Package-manager setup and install.
+4. Node entry-point invocation and artefact upload per workflow.
+
+See `assets/ci-provider-examples/notes.md` for the per-provider translation.
+
+## Operator decisions that remain open after apply
+
+- The workflow shape declaration (`.rcf/config/delivery-ci-workflows.json` populated).
+- Report directory path (default `.rcf/reports/ci/`).
+- Tool choices for elicited checks (linter, formatter, typechecker, unit-test runner, security scanner).
+- Security-scan severity threshold.
+- Coverage-mode posture (supersede ADR-702 with a project-level ADR if a different posture is wanted).
+- CI provider choice and the trigger/setup/install steps per workflow.
+- Branch-protection or push-protection configuration on the default or trunk branch per branch model.
+- Artefact-upload retention and destination.
+- Merge-queue integration and coverage-trend dashboard wiring.
+- Release-mechanism (how tags get created).
+
+## Cost-honesty paragraph
+
+Shipping this doc set costs the project the following. Every commit-triggered event runs the required check set every time; the elicited tier lengthens wall time in proportion to the number of enabled checks. The strict-coverage posture makes every new AC a two-file edit (author the AC and author the TC that resolves it). Adding a check kind outside the catalogue is a project-level ADR plus a runner realisation, not a knob-flip. The illustrative GHA assets are a starting point; a project on another provider owes the translation of the first three of the four mapping points per workflow (extending v1's per-workflow cost to a per-workflow-set cost). Branch-protection configuration is not shipped by the blueprint; a project that forgets to configure it satisfies every AC on the doc set and still ships a workflow set that does not block merges. The report directory grows one per-gate file per gate per run plus one aggregate per workflow per run; a project that runs many workflows against short-lived branches accumulates reports until the CI provider's artefact retention rolls them off.

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

@@ -6,11 +6,11 @@ This file is the deploy-cloudflare-workers half of the cross-blueprint contract.
 
 | 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`), ci-pipeline (`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 |
+| `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, ci-pipeline, 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).
+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)
 
@@ -26,7 +26,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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` |
-| ci-pipeline | 6101-6899 | 7xx | shipped v1.0.0 | `ciGates`, `strictCoverageGate` |
+| 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` |