rcf-lite 0.13.0 → 0.14.0

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",
@@ -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."
     },
     {

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,64 @@
+{
+  "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).",
+    "Seed the provider-specific asset directory (v2.0.0: `assets/ci-provider-examples/github-actions/`) and 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.",
+    "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 and the elicited-check set they carry."
+  ],
+  "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 }` with alias expansion applied and `releaseMode` defaulted to `none` 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-31T00: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"

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` fifth field, and the optional `trunkPullRequests` sub-field are the complete surface the materialiser reads. No other field the file carries is interpreted by v2.0.0; 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 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"
+}