rcf-lite 0.13.0 → 0.15.0

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-019.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-019",
+  "prdId": "PRD-001",
+  "title": "A unit-test check the project realises produces a stable-shape test report and fails non-zero on any failing test",
+  "description": "The elicited `unitTest` check, when the project enables it in `workflowShape.checkSet.unitTest`, runs the project unit-test suite as a gate that exits non-zero on any failing test. The gate writes its per-gate report to `.rcf/reports/ci/test.json` in the shared per-gate report shape (with `checkKind: \"unitTest\"`). The blueprint does not pick the test runner; the project realises the runner and satisfies the runner-contract interface. A missing runner (an empty test suite before the project has any tests) is recorded in the per-gate report and does not by itself fail the gate.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A unit-test gate is table stakes for any greenfield project; naming it in the elicited catalogue keeps the default set aligned with what a project engineer expects to find in a CI floor. Preserving the tool choice at the project layer is what keeps the blueprint neutral across test frameworks.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:19-check-unit-test"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-020.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-020",
+  "prdId": "PRD-001",
+  "title": "A security-scan check the project realises produces a stable-shape scan report and fails non-zero on findings above the project threshold",
+  "description": "The elicited `securityScan` check, when the project enables it in `workflowShape.checkSet.securityScan`, runs a dependency-and-secret scan gate that exits non-zero when the scan finds any advisory at or above the project-configured severity threshold. The gate writes its per-gate report to `.rcf/reports/ci/security.json` in the shared per-gate report shape (with `checkKind: \"securityScan\"`). Findings below the threshold are reported in the per-gate report without flipping the exit code. The severity threshold is a project decision; the blueprint does not opine on the threshold.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "A security scan whose severity threshold is a build-in choice punishes projects whose risk posture is different from the blueprint author's; a threshold the project owns keeps the gate applicable across risk postures. Binding the exit-code semantic and the report shape as an AC contract preserves the stable surface downstream readers depend on.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:20-check-security-scan"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-021.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-021",
+  "prdId": "PRD-001",
+  "title": "The release workflow shape scales with the releaseMode dimension across four discrete modes",
+  "description": "When `workflowShape.releaseMode` is `none`, no release workflow ships. When `tagOnly`, a release workflow fires on the project-declared release trigger (a `release` event, a `workflow_dispatch`, or both) and creates a release entity on the CI provider's own release surface (a GitHub Release, a GitLab release, whatever the provider ships). When `tagPlusArtefact`, the release workflow also runs the project-realised artefact-publish step and uploads its output to the release entity; the AC contract requires the artefact-publish step to produce a verified artefact reachable at a stable identifier. When `deployHandoff:<slug>`, the release workflow additionally invokes the named deploy blueprint's promote workflow per REQ-022. The release workflow does not run the required check set; the check set already ran on the default-branch-checks workflow at the commit the release points at.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Release workflow shape scales with project maturity: an internal package has no release path (mode `none`); a documented release stamps a tag (`tagOnly`); a published library adds an artefact (`tagPlusArtefact`); a paired service hands off to deploy (`deployHandoff`). Four discrete modes cover the maturity range without inventing intermediate states the operator has to reason about. Excluding the check set from the release workflow avoids the redundant run-and-lengthen pattern.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:21-release-mode"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-022.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-022",
+  "prdId": "PRD-001",
+  "title": "The deployHandoff release mode invokes the named deploy blueprint's promote workflow and refuses at boot when that blueprint is absent",
+  "description": "When `workflowShape.releaseMode` is `deployHandoff:<slug>`, the release workflow invokes the named deploy blueprint's `promote` workflow via that blueprint's declared invocation contract (a `workflow_dispatch` event carrying the just-published version identifier as the `versionId` input). The release workflow's aggregate outcome is `passed` only when the promote workflow's outcome is `passed`. The workflow-materialiser performs a boot-check that refuses the value when the named deploy blueprint is absent from `manifest.blueprints[]`; the error names the missing blueprint by slug and points at `rcf define blueprint add <deploy-slug>` as the resolution.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Cross-blueprint composition works when the composing blueprint reaches for a stated invocation contract on the composed side, not when it duplicates the composed side's implementation. The `versionId`-optional-input contract on the deploy blueprint's promote workflow is already ratified; the release workflow calls it and inherits the promote workflow's outcome. The manifest boot-check catches the misconfiguration case (a project declaring a handoff to a target it has not applied) before the release workflow lands on disk.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:22-deploy-handoff"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/requirements/delivery-ci-workflows-req-023.json

@@ -0,0 +1,18 @@
+{
+  "reqId": "delivery-ci-workflows-REQ-023",
+  "prdId": "PRD-001",
+  "title": "An optional scheduledAudit dimension materialises a cron-triggered workflow running the required check set on cadence",
+  "description": "When `workflowShape.scheduledAudit` is `true`, the workflow-materialiser produces a `scheduled-audit` workflow that fires on a cron schedule (the provider's own schedule surface) and runs the same required check set the pull-request and default-branch workflows run. When the field is `false` (default), no scheduled workflow ships. The scheduled-audit workflow writes its aggregate report to a distinct stable path (`.rcf/reports/ci/scheduled-audit.json`) so a scheduled-run outcome never overwrites the most recent commit-triggered outcome downstream readers depend on.",
+  "category": "functional",
+  "domain": "continuous-integration",
+  "priority": "must",
+  "rationale": "Dependency updates and secret rotations do not always coincide with a merge; a scheduled cadence catches drift the commit-triggered workflows would miss. Making the dimension explicit (a top-level fifth field) rather than folding it under a specific check's cadence keeps the axis general: a future need for scheduled cadence on other checks generalises to `scheduledCadence: string` without displacing the fifth dimension.",
+  "tags": [
+    "blueprint:delivery-ci-workflows",
+    "category:23-scheduled-audit"
+  ],
+  "version": "2.0.0",
+  "status": "approved",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/{ci-pipeline/contributions/tacs/tac-701-ci-pipeline-gate-runner.json → delivery-ci-workflows/contributions/tacs/tac-701-delivery-ci-workflows-gate-runner.json}

@@ -1,5 +1,5 @@
 {
-  "tacId": "TAC-701-ci-pipeline-gate-runner",
+  "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
   "version": "1.0.0",
@@ -26,7 +26,7 @@
     {
       "name": "gate-descriptor",
       "kind": "value",
-      "description": "{ name: string, command: string[] } where `command[0]` is the executable (typically `rcf`) and the rest are argv. The set-of-two required for v1.0.0 is `[{ name: 'validate', command: ['rcf', 'validate'] }, { name: 'coverage-strict', command: ['rcf', 'coverage', '--strict'] }]`."
+      "description": "{ name: string, command: string[] } where `command[0]` is the executable (typically `rcf`) and the rest are argv. The rcf CLI groups verbs by RCF stage; the mandatory tier for v1.0.0 uses the grouped forms this TAC's responsibilities section names: `[{ name: 'validate', command: ['rcf', 'define', 'validate'] }, { name: 'coverage-strict', command: ['rcf', 'audit', 'coverage', '--strict'] }]`. A descriptor whose `command` array omits the group (`['rcf', 'validate']`, `['rcf', 'coverage', '--strict']`) does not resolve on any shipped rcf CLI and refuses at gate spawn; the gate-runner does not paper over the difference."
     },
     {
       "name": "entry-point CLI",
@@ -38,13 +38,13 @@
     {
       "name": "Per-gate report writer",
       "kind": "tac",
-      "tacId": "TAC-702-ci-pipeline-gate-report",
+      "tacId": "TAC-702-delivery-ci-workflows-gate-report",
       "description": "Called once per gate with the captured fields; writes the per-gate JSON report and returns the file path the aggregate writer records."
     },
     {
       "name": "Aggregate report writer",
       "kind": "tac",
-      "tacId": "TAC-703-ci-pipeline-aggregate-report",
+      "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
       "description": "Called once at end-of-suite with the ordered gate records; writes the aggregate JSON report and returns the verdict and its exit code."
     },
     {
@@ -55,5 +55,5 @@
   ],
   "tradeoffs": "Running every gate as a separate child process costs Node startup for each; that cost buys a stable exit-code contract and a stable stream capture surface that a library-mode invocation would obscure. Continuing past a failing gate costs a slightly longer pipeline; that cost buys the reviewer seeing every failure on one run instead of chasing them one at a time. The runner does not run gates in parallel: gate ordering is a stable property the aggregate report depends on, and the small gate count at v1.0.0 does not motivate a parallel-and-serialise design.",
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-08-31T00:00:00Z"
 }

package/blueprints/{ci-pipeline/contributions/tacs/tac-702-ci-pipeline-gate-report.json → delivery-ci-workflows/contributions/tacs/tac-702-delivery-ci-workflows-gate-report.json}

@@ -1,5 +1,5 @@
 {
-  "tacId": "TAC-702-ci-pipeline-gate-report",
+  "tacId": "TAC-702-delivery-ci-workflows-gate-report",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
   "version": "1.0.0",

package/blueprints/{ci-pipeline/contributions/tacs/tac-703-ci-pipeline-aggregate-report.json → delivery-ci-workflows/contributions/tacs/tac-703-delivery-ci-workflows-aggregate-report.json}

@@ -1,5 +1,5 @@
 {
-  "tacId": "TAC-703-ci-pipeline-aggregate-report",
+  "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
   "version": "1.0.0",
@@ -31,7 +31,7 @@
     {
       "name": "Per-gate report writer",
       "kind": "tac",
-      "tacId": "TAC-702-ci-pipeline-gate-report",
+      "tacId": "TAC-702-delivery-ci-workflows-gate-report",
       "description": "The per-gate reports the aggregate writer reads back to confirm each report's existence and to record its relative path in the aggregate."
     }
   ],

package/blueprints/delivery-ci-workflows/contributions/tacs/tac-704-delivery-ci-workflows-workflow-materialiser.json

@@ -0,0 +1,67 @@
+{
+  "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "approved",
+  "name": "Workflow materialiser (Node reader + writer)",
+  "purpose": "The Node module the project realises to READ the `workflowShape` declaration from `.rcf/config/delivery-ci-workflows.json` and WRITE the provider-specific workflow files that make up the workflow set. One materialiser per project; the same code path runs locally and in CI. The materialiser is not a runtime CI job; it is a build-time authoring step the project runs when its shape changes.",
+  "responsibilities": [
+    "Read `.rcf/config/delivery-ci-workflows.json` at project root and parse it as JSON (AC-6111-1, AC-6111-2).",
+    "Perform the boot-check: refuse missing required fields (`branchModel`, `checkSet`, `providerHint`), refuse unrecognised values on any field, refuse `deployHandoff:<slug>` when the deploy blueprint is absent from the manifest; exit non-zero with a stable-coded error naming the offending field (AC-6112-1, AC-6112-2, AC-6122-3).",
+    "Expand a profile alias to the four-field composed form before any downstream reads it; refuse an unrecognised alias (AC-6113-1, AC-6113-2).",
+    "Compute the workflow set from `workflowShape` per the matrix in the spec (§3.2): the two commit-triggered workflows per branch model, the release workflow per `releaseMode`, the scheduled-audit workflow per `scheduledAudit` (AC-6114-1, AC-6114-2, AC-6115-1, AC-6115-2, AC-6121-1, AC-6121-2, AC-6123-1, AC-6123-2).",
+    "Read the applied blueprint source from `rcf/manifest.json`'s `blueprints[].source` field (the path recorded when `rcf define blueprint add` ran) and resolve the provider asset directory as `<source>/assets/ci-provider-examples/<providerHint>/`; do not hard-code the source path against `node_modules/` or any other convention.",
+    "Write one workflow file per workflow in the set to the provider's workflow path (v2.0.0: `.github/workflows/` for GHA); alternate providers translate per the four-point mapping doc.",
+    "Substitute the trigger branch name into the produced commit-triggered workflows: on `branchModel: feature`, the `pull-request-checks` and `default-branch-checks` triggers name `workflowShape.defaultBranch` (default `main`); on `branchModel: trunk`, they name `workflowShape.trunkBranch` (default `main`). The substitution is applied against the `# @@RCF-SUB-BRANCH-NAME@@` marker that the illustrative assets carry immediately above their `branches:` line; the marker's next line (the `branches: [...]` list) is rewritten to name the configured branch, so the property AC-6114/6115 binds to (the branch model determines which branch triggers the workflow) is observable in the materialised output rather than being masked by a hard-coded `main`.",
+    "Substitute the package-manager setup and install steps into every produced workflow: read `workflowShape.packageManager` (default `pnpm`; recognised values `pnpm`, `npm`, `yarn`, `bun`); replace every line fenced between `# @@RCF-SUB-PKG-MGR-SETUP-BEGIN@@` and `# @@RCF-SUB-PKG-MGR-SETUP-END@@` (exclusive) with the per-manager setup block, and every line fenced between `# @@RCF-SUB-PKG-MGR-INSTALL-BEGIN@@` and `# @@RCF-SUB-PKG-MGR-INSTALL-END@@` (exclusive) with the per-manager install block, per the substitution table in `guide/delivery-ci-workflows.md`. Refuse an unrecognised `packageManager` with the same boot-check error path the enumerated fields use.",
+    "Materialisation is idempotent: re-running with the same `workflowShape` writes the same files byte-for-byte; changing the shape overwrites the workflow files atomically (temp file + rename).",
+    "Emit a materialiser-run summary to stdout naming the workflow files produced, the elicited-check set they carry, and the substituted branch name and package manager."
+  ],
+  "internalStructure": "One Node module exporting `materialise({ configPath, providerAssetDir, workflowOutDir })` and a shebang entry point invocable as `node <path>` with no required argv. The reader parses the config; the boot-check module validates each field against the recognised enumeration; the matrix module computes the workflow set from the composed shape; the writer module reads the provider asset templates, substitutes the required check set into the gate-runner invocation line, and writes the workflow files atomically.",
+  "interfaces": [
+    {
+      "name": "materialise",
+      "kind": "factory",
+      "description": "materialise({ configPath, providerAssetDir, workflowOutDir }) -> Promise<{ workflowsWritten: string[], summary: object }>; the sole callable the entry point invokes. Reads the config, runs the boot-check, computes the matrix, writes the workflows."
+    },
+    {
+      "name": "workflow-shape",
+      "kind": "value",
+      "description": "The parsed and composed `workflowShape`: `{ branchModel, checkSet, releaseMode, providerHint, scheduledAudit, trunkPullRequests, defaultBranch, trunkBranch, packageManager }` with alias expansion applied, `releaseMode` defaulted to `none` when absent, `defaultBranch` and `trunkBranch` defaulted to `main` when absent, and `packageManager` defaulted to `pnpm` when absent."
+    },
+    {
+      "name": "entry-point CLI",
+      "kind": "cli",
+      "description": "`node <entryPointPath>` with no required argv. Optional flag `--config <path>` overrides the default config path; `--out <path>` overrides the default workflow output directory. Exit code is 0 on success and non-zero (with the boot-check error code) on any refused input."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Gate runner",
+      "kind": "tac",
+      "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+      "description": "The materialiser writes workflow files whose command line invokes the gate-runner Node entry point with the elicited check set. The materialiser does not import the runner; it invokes the runner as a separate Node process at CI time."
+    },
+    {
+      "name": "Release workflow",
+      "kind": "tac",
+      "tacId": "TAC-705-delivery-ci-workflows-release-workflow",
+      "description": "The materialiser produces the release workflow file whose steps satisfy the release-workflow TAC per the elicited `releaseMode`."
+    },
+    {
+      "name": "Scheduled audit",
+      "kind": "tac",
+      "tacId": "TAC-706-delivery-ci-workflows-scheduled-audit",
+      "description": "The materialiser produces the scheduled-audit workflow file whose cron trigger satisfies the scheduled-audit TAC when `scheduledAudit: true`."
+    },
+    {
+      "name": "Manifest reader",
+      "kind": "external",
+      "description": "The materialiser reads `rcf/manifest.json` to perform the `deployHandoff` manifest boot-check (AC-6122-3); refusal names the missing slug and the resolution command."
+    }
+  ],
+  "tradeoffs": "A build-time materialiser costs an extra step in the project's onboarding (running `node <entryPointPath>` after editing the config) but buys byte-identical workflow files across two runs of the same shape, which is the property downstream tools (a diff-review, a CI-config-verifier) depend on. Writing to the provider workflow path (not a `dist/` directory) means the workflow files are committed and reviewable; the shape declaration and the materialised output are both under source control.",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T12:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/tacs/tac-705-delivery-ci-workflows-release-workflow.json

@@ -0,0 +1,51 @@
+{
+  "tacId": "TAC-705-delivery-ci-workflows-release-workflow",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "approved",
+  "name": "Release workflow (Node step orchestrator)",
+  "purpose": "The Node-side orchestrator the release workflow file invokes to run the release-flow steps per the elicited `releaseMode`. Owns the sequence: create release entity (all modes except `none`), run artefact-publish (from `tagPlusArtefact`), dispatch deploy promote workflow (`deployHandoff` only), aggregate the outcome into `.rcf/reports/ci/release.json`.",
+  "responsibilities": [
+    "Read the elicited `releaseMode` from the release workflow environment (the workflow file passes it in as an argument or an env var; the orchestrator does not read the config file at CI time).",
+    "When `releaseMode` is `tagOnly`, `tagPlusArtefact`, or `deployHandoff:<slug>`, create the release entity on the CI provider's release surface (AC-6121-2 the first sentence).",
+    "When `releaseMode` is `tagPlusArtefact` or `deployHandoff:<slug>`, invoke the project-realised artefact-publish step and capture the just-published version identifier (AC-6121-2 the second sentence).",
+    "When `releaseMode` is `deployHandoff:<slug>`, dispatch the named deploy blueprint's `promote` workflow via `workflow_dispatch`, passing the just-published version identifier as the `versionId` input; wait on the promote workflow's outcome (AC-6122-1).",
+    "Aggregate the outcome into `.rcf/reports/ci/release.json`: the release workflow's aggregate outcome is `passed` only when every step (tag creation, artefact publish where applicable, promote workflow outcome where applicable) is `passed` (AC-6122-2, AC-6121-3).",
+    "The release workflow does NOT invoke the gate-runner entry point; the check set already ran on the default-branch-checks workflow at the commit the release points at (AC-6121-3)."
+  ],
+  "internalStructure": "One Node module exporting `runRelease({ releaseMode, deployTarget, artefactStep })` and a shebang entry point invocable as `node <path>` with argv naming the release mode. The orchestrator sequences the steps as a fixed pipeline: `create-release-entity`, `publish-artefact` (conditional), `dispatch-promote` (conditional), `aggregate-report`. Each step writes its own per-step JSON record to `.rcf/reports/ci/release/<step>.json`; the aggregator gathers them into `.rcf/reports/ci/release.json`.",
+  "interfaces": [
+    {
+      "name": "runRelease",
+      "kind": "factory",
+      "description": "runRelease({ releaseMode, deployTarget, artefactStep }) -> Promise<{ verdict, versionId, releaseReportPath }>; the sole callable the release workflow file invokes."
+    },
+    {
+      "name": "release-mode",
+      "kind": "value",
+      "description": "One of `tagOnly`, `tagPlusArtefact`, `deployHandoff:<slug>`. The `none` mode never reaches the orchestrator because the release workflow itself is not materialised."
+    },
+    {
+      "name": "entry-point CLI",
+      "kind": "cli",
+      "description": "`node <entryPointPath> --mode <releaseMode>` with the release mode as required argv. Exit code is 0 on `verdict: passed` and non-zero on `verdict: failed`."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Deploy promote workflow",
+      "kind": "external",
+      "description": "For `deployHandoff:<slug>`, the deploy blueprint's `promote` workflow exposed via `workflow_dispatch` with a `versionId` input. The release orchestrator does not import the deploy blueprint; it dispatches the workflow through the CI provider's workflow-dispatch API."
+    },
+    {
+      "name": "Aggregate report writer",
+      "kind": "tac",
+      "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
+      "description": "The release workflow aggregate reuses the aggregate-report writer shape with the release-flow gate list in place of the check-set gate list."
+    }
+  ],
+  "tradeoffs": "Splitting the release workflow orchestrator from the commit-triggered gate-runner means two Node entry points, not one. The alternative (one runner that switches on trigger kind) conflates two distinct control flows: the commit-triggered gate set is a fixed check catalogue; the release-triggered flow is a variable pipeline whose step set depends on `releaseMode`. Keeping them separate makes each one's AC contract legible.",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

package/blueprints/delivery-ci-workflows/contributions/tacs/tac-706-delivery-ci-workflows-scheduled-audit.json

@@ -0,0 +1,38 @@
+{
+  "tacId": "TAC-706-delivery-ci-workflows-scheduled-audit",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "2.0.0",
+  "status": "approved",
+  "name": "Scheduled audit runner (cron-triggered gate invocation)",
+  "purpose": "The Node-side entry point the scheduled-audit workflow file invokes on a cron schedule. Runs the same required check set the commit-triggered workflows run, writes the aggregate report to a distinct stable path (`.rcf/reports/ci/scheduled-audit.json`) so scheduled-run outcomes never overwrite commit-triggered outcomes.",
+  "responsibilities": [
+    "Invoke the gate-runner entry point (TAC-701) with the required check set the project has elicited in `workflowShape.checkSet`, plus the mandatory tier (AC-6123-1).",
+    "Override the aggregate report path so the aggregate lands at `.rcf/reports/ci/scheduled-audit.json`, distinct from the commit-triggered `.rcf/reports/ci/pipeline.json` (AC-6123-1).",
+    "Do not ship when `workflowShape.scheduledAudit` is `false` or absent (the workflow-materialiser refuses to write the workflow file; the runner is not invoked because the workflow does not exist) (AC-6123-2)."
+  ],
+  "internalStructure": "A thin Node wrapper around the gate-runner entry point that overrides the aggregate report path and forwards the elicited check set. The wrapper is a shebang entry point invocable as `node <path>` with no required argv; the workflow file passes `--report-path .rcf/reports/ci/scheduled-audit.json` as its optional argument.",
+  "interfaces": [
+    {
+      "name": "runScheduledAudit",
+      "kind": "factory",
+      "description": "runScheduledAudit({ checkSet, reportPath }) -> Promise<{ verdict, exitCode, aggregateReportPath }>; the sole callable the entry point invokes."
+    },
+    {
+      "name": "entry-point CLI",
+      "kind": "cli",
+      "description": "`node <entryPointPath> --check-set <checkSet> --report-path <path>` with the elicited check set as required argv and the report path as an optional override. Exit code is the aggregate exit code."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Gate runner",
+      "kind": "tac",
+      "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+      "description": "The scheduled runner invokes the gate-runner Node entry point with the required check set; the check-set contract and the report shape are shared."
+    }
+  ],
+  "tradeoffs": "A distinct report path for the scheduled-audit workflow costs one extra path in the downstream reader's ingest logic; that cost buys the property that a scheduled-run outcome never overwrites the record of the most recent commit-triggered outcome. The alternative (writing to the same path) would collapse two distinct concerns into one file whose meaning shifts based on which workflow wrote it last.",
+  "createdAt": "2026-08-31T00:00:00Z",
+  "updatedAt": "2026-08-31T00:00:00Z"
+}

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

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6101",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-001",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The commit-triggered workflows run the required check set on every branch-model-defined trigger event",
+  "asA": "operator on an rcf-lite project with delivery-ci-workflows v2 applied",
+  "iWant": "the commit-triggered workflows the materialiser produced (pull-request-checks and default-branch-checks per the elicited branch model) to run the required check set on every trigger event that branch model defines",
+  "soThat": "no change reaches the default or trunk branch without the RCF chain, its coverage, and every enabled elicited check having been verified against the tree at the head commit",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6101-1",
+      "description": "The CI provider's jobs for the commit-triggered workflows are triggered by the trigger events the branch model defines: for feature-branch, pushes to the default branch and pull requests opened, synchronised, or reopened against the default branch; for trunk-based, pushes to the trunk branch and (in the `trunkPullRequests: sometimes` sub-shape) pull requests targeting the trunk branch. The trigger configuration is committed under source control, not set through a provider UI.",
+      "given": "the project's materialised workflow files and repository state at the head commit",
+      "when": "a trigger event fires that the elicited branch model names",
+      "then": "the aggregate pipeline report at the configured stable path (default `.rcf/reports/ci/pipeline.json`) is written by the resulting CI job, and its `trigger` field records the event kind and the workflow that ran",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6101-2",
+      "description": "The merge policy blocks a merge whose most recent aggregate pipeline run did not exit zero. The block is enforced by the repository's branch protection or the equivalent platform policy per the branch-model AC binding (AC-6114-3 for feature-branch; AC-6115-1 or AC-6115-2 for trunk-based).",
+      "given": "a change (a pull request in feature-branch or the with-PR trunk sub-shape, or a direct push in the trunk without-PR sub-shape) whose most recent aggregate pipeline run's report records `verdict: failed`",
+      "when": "the operator or an automated merge tool attempts to admit the change through the standard merge or push path",
+      "then": "the platform refuses the change, and the refusal reason references the failed required check that corresponds to the workflow that ran",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-703-delivery-ci-workflows-aggregate-report"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6102.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6102.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6102",
+  "usId": "delivery-ci-workflows-US-6102",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-002",
+  "reqId": "delivery-ci-workflows-REQ-002",
   "version": "1.0.0",
   "status": "approved",
   "title": "The gate suite is invoked as one Node entry point that any CI provider can run",
@@ -29,7 +29,7 @@
     }
   ],
   "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner"
+    "TAC-701-delivery-ci-workflows-gate-runner"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6103.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6103.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6103",
+  "usId": "delivery-ci-workflows-US-6103",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-003",
+  "reqId": "delivery-ci-workflows-REQ-003",
   "version": "1.0.0",
   "status": "approved",
   "title": "The suite runs the validate gate and fails the pipeline on any non-zero exit",
@@ -29,8 +29,8 @@
     }
   ],
   "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner",
-    "TAC-702-ci-pipeline-gate-report"
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6104.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6104.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6104",
+  "usId": "delivery-ci-workflows-US-6104",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-004",
+  "reqId": "delivery-ci-workflows-REQ-004",
   "version": "1.0.0",
   "status": "approved",
   "title": "The suite runs per-AC strict coverage and fails the pipeline on any gap",
@@ -29,8 +29,8 @@
     }
   ],
   "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner",
-    "TAC-702-ci-pipeline-gate-report"
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6105.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6105.json}

@@ -1,8 +1,8 @@
 {
-  "usId": "ci-pipeline-US-6105",
+  "usId": "delivery-ci-workflows-US-6105",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-005",
-  "version": "1.0.0",
+  "reqId": "delivery-ci-workflows-REQ-005",
+  "version": "2.0.0",
   "status": "approved",
   "title": "Every gate leaves a machine-readable JSON report at a stable path",
   "asA": "downstream reader of the pipeline (a reviewer, a dashboard, an audit tool)",
@@ -11,10 +11,10 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6105-1",
-      "description": "Every gate the suite runs writes a JSON report file at `<reportDir>/<gate>.json` whether the gate passed or failed. The report carries a fixed set of fields: `gate`, `command`, `toolVersion`, `startedAt`, `endedAt`, `durationMs`, `exitCode`, `outcome`, `stdout`, `stderr`.",
+      "description": "Every gate the suite runs writes a JSON report file at `<reportDir>/<gate>.json` whether the gate passed or failed. The report carries a fixed set of fields: `gate`, `command`, `toolVersion`, `startedAt`, `endedAt`, `durationMs`, `exitCode`, `outcome`, `stdout`, `stderr`, and (v2 addition) `checkKind`.",
       "given": "the suite has run against any tree",
       "when": "the reviewer inspects the configured report directory after the run",
-      "then": "for every gate named in the aggregate report's `gates[]` array, a file at `<reportDir>/<gate>.json` exists whose top-level keys are exactly the fixed set above, and the value types match the stable schema (`startedAt` and `endedAt` are ISO-8601 strings, `durationMs` is an integer, `exitCode` is an integer, `outcome` is one of `passed` or `failed`)",
+      "then": "for every gate named in the aggregate report's `gates[]` array, a file at `<reportDir>/<gate>.json` exists whose top-level keys are exactly the fixed set above, and the value types match the stable schema (`startedAt` and `endedAt` are ISO-8601 strings, `durationMs` is an integer, `exitCode` is an integer, `outcome` is one of `passed` or `failed`, `checkKind` is one of `validate`, `coverage-strict`, `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`, or a `custom:<name>` string)",
       "testable": true,
       "scope": "runtime"
     },
@@ -29,7 +29,7 @@
     }
   ],
   "tacIds": [
-    "TAC-702-ci-pipeline-gate-report"
+    "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6106.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6106.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6106",
+  "usId": "delivery-ci-workflows-US-6106",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-006",
+  "reqId": "delivery-ci-workflows-REQ-006",
   "version": "1.0.0",
   "status": "approved",
   "title": "The suite emits an aggregate pipeline report at a stable path",
@@ -29,7 +29,7 @@
     }
   ],
   "tacIds": [
-    "TAC-703-ci-pipeline-aggregate-report"
+    "TAC-703-delivery-ci-workflows-aggregate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6107.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6107.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6107",
+  "usId": "delivery-ci-workflows-US-6107",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-007",
+  "reqId": "delivery-ci-workflows-REQ-007",
   "version": "1.0.0",
   "status": "approved",
   "title": "A gate failure surfaces the failing gate and its report path in the operator-visible output",
@@ -14,7 +14,7 @@
       "description": "On any gate failure, the Node entry point writes an operator-readable failure summary to its own stderr naming the failing gate, its exit code, and the relative path to the per-gate report file.",
       "given": "an invocation of the suite whose `validate` (or any) gate fails",
       "when": "the reviewer reads the runner-log tail (the Node process's own stderr)",
-      "then": "the tail contains a single-line summary matching the shape `[ci-pipeline] gate '<gate>' failed (exit <n>); report: <reportDir>/<gate>.json`, and the reference report file exists at the named path",
+      "then": "the tail contains a single-line summary matching the shape `[delivery-ci-workflows] gate '<gate>' failed (exit <n>); report: <reportDir>/<gate>.json`, and the reference report file exists at the named path",
       "testable": true,
       "scope": "runtime"
     },
@@ -29,8 +29,8 @@
     }
   ],
   "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner",
-    "TAC-703-ci-pipeline-aggregate-report"
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-703-delivery-ci-workflows-aggregate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6108.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6108.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6108",
+  "usId": "delivery-ci-workflows-US-6108",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-008",
+  "reqId": "delivery-ci-workflows-REQ-008",
   "version": "1.0.0",
   "status": "approved",
   "title": "A missing gate report is never treated as an implicit pass",
@@ -29,8 +29,8 @@
     }
   ],
   "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner",
-    "TAC-703-ci-pipeline-aggregate-report"
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-703-delivery-ci-workflows-aggregate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"

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

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6109",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-009",
+  "version": "2.0.0",
+  "status": "approved",
+  "title": "The blueprint ships one illustrative GitHub Actions workflow file per workflow the matrix materialises; alternate providers wire the same entry points",
+  "asA": "operator setting up CI on an rcf-lite project for the first time",
+  "iWant": "one worked example per workflow the matrix materialises so I have a copy-paste starting point for every trigger, setup, invoke, and artefact-upload shape",
+  "soThat": "I get a working workflow set on GHA out of the box and a stable mapping to other providers",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6109-1",
+      "description": "The applied blueprint's source path (recorded on `manifest.blueprints[delivery-ci-workflows].source`) contains one illustrative GitHub Actions workflow file per workflow in the matrix under `assets/ci-provider-examples/github-actions/`. At the widest shape the files are `pull-request-checks.yml`, `default-branch-checks.yml`, `release.yml`, and `scheduled-audit.yml`. Each workflow defines the required trigger set for its workflow, sets up Node and the package manager, installs dependencies, invokes the corresponding Node entry point as a single command line, and uploads the corresponding report directory or file as a workflow artefact.",
+      "given": "an rcf-lite project that has applied this blueprint",
+      "when": "the operator opens the blueprint's source path and reads the files under `assets/ci-provider-examples/github-actions/`",
+      "then": "the four workflow files exist at that path, each file's `on:` block names the trigger set corresponding to its workflow, each file's steps include a Node setup and a package-manager setup, one step per file invokes the appropriate Node entry point as a single `node <path>` line (or a package-manager script that resolves to the same), and a final step uploads the corresponding report path as a workflow artefact",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6109-2",
+      "description": "The applied blueprint's guide names GitLab CI, CircleCI, Buildkite, and Jenkins as equally supported providers, states the mapping (job trigger, Node setup, single-line entry-point invocation, artefact upload) applied to each workflow in the matrix, and states that the blueprint does not ship provider-specific configuration for those runners in v2.0.0.",
+      "given": "an rcf-lite project that has applied this blueprint",
+      "when": "the operator opens `guide/delivery-ci-workflows.md` from the blueprint's source path",
+      "then": "the guide's `when to reach for it` or an adjacent section names GitLab CI, CircleCI, Buildkite, and Jenkins by name, describes the four mapping points applied to each workflow the matrix materialises, and states that no provider-specific configuration file for those runners is shipped by the blueprint at v2.0.0",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/{ci-pipeline/contributions/user-stories/ci-pipeline-us-6110.json → delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6110.json}

@@ -1,7 +1,7 @@
 {
-  "usId": "ci-pipeline-US-6110",
+  "usId": "delivery-ci-workflows-US-6110",
   "prdId": "PRD-001",
-  "reqId": "ci-pipeline-REQ-010",
+  "reqId": "delivery-ci-workflows-REQ-010",
   "version": "1.0.0",
   "status": "approved",
   "title": "The gate suite entry point runs the same code path locally as in CI",
@@ -29,7 +29,7 @@
     }
   ],
   "tacIds": [
-    "TAC-701-ci-pipeline-gate-runner"
+    "TAC-701-delivery-ci-workflows-gate-runner"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
   "updatedAt": "2026-08-24T00:00:00Z"