rcf-lite 0.13.0 → 0.15.0

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

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6111",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-011",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The project declares its workflow shape in a stable in-repo file the materialiser reads",
+  "asA": "operator standing up an rcf-lite project with the delivery-ci-workflows blueprint applied",
+  "iWant": "to declare my project's CI workflow shape once in a stable in-repo configuration file that the workflow-materialiser reads on every run",
+  "soThat": "the workflow set my project produces is a function of a checked-in declaration, not a hidden default or an operator's memory",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6111-1",
+      "description": "The workflow-materialiser reads its input `workflowShape` from the stable path `.rcf/config/delivery-ci-workflows.json` on the project tree. The reader path is documented in the blueprint guide and does not vary with CI provider.",
+      "given": "a project that has applied delivery-ci-workflows v2 and populated `.rcf/config/delivery-ci-workflows.json`",
+      "when": "the workflow-materialiser runs (locally or in CI)",
+      "then": "the materialiser reads the file at the documented path and treats its `workflowShape` as authoritative",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6111-2",
+      "description": "The three required fields (`branchModel`, `checkSet`, `providerHint`), the optional `releaseMode` field (absent has the same effect as `releaseMode: none`, per Q6-B ratification), the optional `scheduledAudit` field, the optional `trunkPullRequests` sub-field, and the optional substitution-surface fields `defaultBranch` (default `main`), `trunkBranch` (default `main`), and `packageManager` (default `pnpm`; recognised set `pnpm`, `npm`, `yarn`, `bun`) are the complete surface the workflow-materialiser reads. No other field the file carries is interpreted at this version; unknown fields are ignored (forward-compatibility).",
+      "given": "a `workflowShape` declaration carrying the three required fields, the optional fields, and additional unknown fields",
+      "when": "the workflow-materialiser reads the file",
+      "then": "the materialiser processes the recognised fields (including the substitution-surface trio) and ignores the unknown fields without failing the boot-check",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

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

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6112",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-012",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "A missing or unrecognised workflowShape field fails fast with a stable-coded error",
+  "asA": "operator maintaining a project on delivery-ci-workflows v2",
+  "iWant": "the workflow-materialiser to refuse to run when its input `workflowShape` is missing a required field or carries an unrecognised value",
+  "soThat": "a misconfiguration is caught at boot with a message I can match on, not by a subtly wrong-shaped workflow set landing on disk",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6112-1",
+      "description": "A `workflowShape` missing any of the three required fields (`branchModel`, `checkSet`, `providerHint`) causes the workflow-materialiser to exit non-zero with a stable error code and a message naming the missing field. `releaseMode` being absent does NOT fail the boot-check (per Q6-B ratification): the materialiser treats absent `releaseMode` as `releaseMode: none` and ships no release workflow. No workflow file is written when the boot-check does fail.",
+      "given": "a `workflowShape` declaration whose `providerHint` field is absent (or any of the three required fields)",
+      "when": "the workflow-materialiser boots",
+      "then": "the materialiser exits non-zero, prints an error naming the missing field with a stable code, and leaves the provider's workflow directory unchanged",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6112-2",
+      "description": "A required field whose value is not in the recognised enumeration for that field causes the same failure shape: non-zero exit, stable-coded error, no workflow file written.",
+      "given": "a `workflowShape` carrying `branchModel: hybrid` (a value the enumeration does not include)",
+      "when": "the workflow-materialiser boots",
+      "then": "the materialiser exits non-zero, prints an error naming the field, the value received, and the recognised set, with a stable code",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

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

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6113",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-013",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "A named profile alias expands to the four-field workflowShape before any consumer reads it",
+  "asA": "operator standing up a small library project on delivery-ci-workflows v2",
+  "iWant": "to declare my workflow shape as a named profile alias (`smallLibrary`, `smallService`, `internalPackage`, `trunkLibrary`) rather than filling four fields explicitly",
+  "soThat": "the common cases stay short while every downstream still sees one authoritative representation",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6113-1",
+      "description": "A `workflowShape` declared as `{ \"alias\": \"smallLibrary\" }` is expanded at boot to the four-field form (`branchModel: feature`, `checkSet: <all-true>`, `releaseMode: tagPlusArtefact`, `providerHint: githubActions`). Every downstream in this blueprint binds to the four-field form.",
+      "given": "a `workflowShape` declaration carrying only the alias field with value `smallLibrary`",
+      "when": "the workflow-materialiser boots",
+      "then": "the materialiser expands the alias to the four-field composition, records the expansion in its own log, and treats the four-field form as authoritative for materialisation",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6113-2",
+      "description": "An alias name that the shipped set does not include causes a boot-check failure with a stable-coded error naming the alias and listing the shipped set. A project that wants a shape the aliases do not cover uses the four-field form directly.",
+      "given": "a `workflowShape` declared as `{ \"alias\": \"microservice\" }`",
+      "when": "the workflow-materialiser boots",
+      "then": "the materialiser exits non-zero with a stable-coded error naming the alias, the shipped-set list, and the four-field form as the fallback",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-704-delivery-ci-workflows-workflow-materialiser"
+  ],
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

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 configured default branch (`workflowShape.defaultBranch`, default `main`). 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`, `defaultBranch: develop`, 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's branch list names `develop` (the configured default branch, not the placeholder marker and not a hard-coded `main`), 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 configured default branch. The workflow invokes the same Node gate-runner entry point on the same required check set.",
+      "given": "the same `workflowShape` (`branchModel: feature`, `defaultBranch: develop`)",
+      "when": "the workflow-materialiser runs",
+      "then": "a `default-branch-checks` workflow file lands at the provider's workflow path, its trigger's branch list names `develop`, 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, triggered by pushes to the configured trunk branch (`workflowShape.trunkBranch`, default `main`). The `pull-request-checks` workflow does not ship in this shape.",
+      "given": "a `workflowShape` with `branchModel: trunk`, `trunkBranch: trunk`, and no `trunkPullRequests` field",
+      "when": "the workflow-materialiser runs",
+      "then": "a `default-branch-checks` workflow file lands at the provider's workflow path, its trigger's branch list names `trunk` (the configured trunk branch), 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`, both triggered against the configured trunk branch.",
+      "given": "a `workflowShape` with `branchModel: trunk`, `trunkBranch: trunk`, and `trunkPullRequests: sometimes`",
+      "when": "the workflow-materialiser runs",
+      "then": "both workflow files land at the provider's workflow path with their trigger branch lists naming `trunk`, and the merge-policy AC binds to the trunk-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.