rcf-lite 0.12.0 → 0.14.0

package/blueprints/delivery-ci-workflows/contributions/tacs/tac-703-delivery-ci-workflows-aggregate-report.json

@@ -0,0 +1,41 @@
+{
+  "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "1.0.0",
+  "status": "approved",
+  "name": "Aggregate report writer",
+  "purpose": "The module that writes the single aggregate JSON report at `<reportDir>/pipeline.json` at the end of every suite invocation. Owns the aggregate report schema, the fixed-order gate array, the missing-report detection pass, and the verdict rule that maps per-gate outcomes to the aggregate verdict.",
+  "responsibilities": [
+    "Write a JSON file at `<reportDir>/pipeline.json` on every suite completion (AC-6106-1).",
+    "Populate the fixed key set: `verdict`, `trigger`, `startedAt`, `endedAt`, `durationMs`, `runner` (with nested `entryPoint`, optional `environment`), and `gates[]` (each entry naming `gate`, `outcome`, `durationMs`, `reportPath`, optional `reason` on missing) (AC-6106-1, AC-6102-1, AC-6110-2).",
+    "Order the `gates[]` array in the fixed configured order (the runner's gate set), not in completion order (AC-6108-1).",
+    "For each configured gate, check whether the corresponding per-gate report exists on disk; if not, record the entry as `outcome: missing` with a `reason` string derived from the runner's captured failure (killed child, uncaught exception, write failure, permission error) (AC-6108-1).",
+    "Set `verdict: passed` if and only if every gate entry's outcome is `passed`; otherwise set `verdict: failed`. A single `failed` or `missing` outcome flips the aggregate verdict (AC-6106-2, AC-6108-1, AC-6108-2).",
+    "Return the aggregate exit code to the runner: 0 on `passed`, non-zero on `failed`."
+  ],
+  "internalStructure": "One module that exports a `writeAggregateReport({ reportDir, trigger, startedAt, endedAt, runner, gates })` function returning `{ verdict, exitCode, aggregateReportPath }`. Walks the ordered `gates` input, checks each per-gate report file's existence, resolves each `reportPath` to a relative path from `reportDir`. Serialises the fixed key set to JSON with 2-space indent, writes atomically (temp + rename). Never writes `verdict: passed` while any gate outcome is other than `passed`.",
+  "interfaces": [
+    {
+      "name": "writeAggregateReport",
+      "kind": "write-api",
+      "description": "writeAggregateReport({ reportDir, trigger, startedAt, endedAt, runner, gates }) -> Promise<{ verdict, exitCode, aggregateReportPath }>. Writes the aggregate JSON report atomically and resolves with the verdict and the aggregate exit code."
+    },
+    {
+      "name": "aggregate-report-schema",
+      "kind": "schema",
+      "description": "Top-level keys exactly: `verdict` (enum `passed` | `failed`), `trigger` (string; the CI event kind or `local`), `startedAt` (ISO-8601), `endedAt` (ISO-8601), `durationMs` (integer), `runner` (object with `entryPoint` string and optional `environment` object), `gates[]` (array of `{ gate, outcome, durationMs, reportPath, reason? }` in configured order). No other keys at v1.0.0."
+    }
+  ],
+  "dependencies": [
+    {
+      "name": "Per-gate report writer",
+      "kind": "tac",
+      "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."
+    }
+  ],
+  "tradeoffs": "The verdict rule is deliberately strict: any non-`passed` outcome flips the aggregate. A more nuanced rule (advisory gates, warning outcomes) is a v1.1 minor-bump candidate; v1.0.0 does not ship it because the two required gates are both hard gates. The aggregate schema is fixed within a major version; additive fields are a minor bump.",
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

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/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6102.json

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6102",
+  "prdId": "PRD-001",
+  "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",
+  "asA": "operator picking or moving between CI providers on an rcf-lite project",
+  "iWant": "the gate suite to be a plain Node script the CI job invokes with one line",
+  "soThat": "moving from one provider to another is a rewrite of the trigger definition, not a rewrite of the gates",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6102-1",
+      "description": "The gate runner is a single Node entry point on disk under the project's tree (a script or module invocable as `node <path>` with no shell glue). The runner's file path is the same on every host.",
+      "given": "the project tree at the head commit",
+      "when": "the aggregate report is written by any CI run",
+      "then": "the aggregate report's `runner.entryPoint` field records a project-relative path to a `.js` or `.mjs` file that exists at that path in the tree",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6102-2",
+      "description": "The CI provider's job definition invokes the gate runner with a single command line: a `node <path>` invocation (or a package-manager script that resolves to the same). No gate-specific logic sits inside the CI provider's job definition.",
+      "given": "the project's CI configuration file(s) committed under source control",
+      "when": "an operator reads the job step that produces the pipeline report",
+      "then": "the step is a single-line invocation of the Node entry point (or an equivalent package-manager script), and every gate-level branching, timing, and report-writing responsibility lives inside the Node runner rather than the CI configuration",
+      "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/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6103.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6103",
+  "prdId": "PRD-001",
+  "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",
+  "asA": "reviewer opening a pull request against the default branch",
+  "iWant": "the pipeline to have already run `rcf define validate` against the head commit's tree and refused the run on any schema or reference issue",
+  "soThat": "I never review a change whose chain is structurally broken",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6103-1",
+      "description": "The suite invokes `rcf define validate` before any other gate. The gate's exit code, captured stdout, and captured stderr are written to a per-gate report at the configured stable path.",
+      "given": "the pipeline has run against the head commit",
+      "when": "the reviewer opens the per-gate report file at `<reportDir>/validate.json`",
+      "then": "the file exists, its `gate` field is `validate`, its `command` field names the `rcf define validate` invocation, its `exitCode` field records the underlying process exit code, and its `stdout` and `stderr` fields carry the captured streams",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6103-2",
+      "description": "A non-zero exit from `rcf define validate` marks the aggregate verdict as failed and the aggregate exit code as non-zero. The pipeline does not proceed to declare the run passed on the basis of downstream gates alone.",
+      "given": "an invocation of the suite against a tree that fails `rcf define validate` (a deliberately broken reference)",
+      "when": "the suite completes",
+      "then": "the aggregate report's `verdict` field is `failed`, its `gates[]` entry for `validate` records `outcome: failed`, and the Node entry point's process exit code is non-zero",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "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/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6104.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6104",
+  "prdId": "PRD-001",
+  "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",
+  "asA": "reviewer accountable for the RCF chain on merge",
+  "iWant": "the pipeline to have already run `rcf audit coverage --strict` and refused on any AC without a resolving TC",
+  "soThat": "a merge that ships an AC unbound to a TC is impossible",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6104-1",
+      "description": "The suite invokes `rcf audit coverage --strict` as a required gate after `rcf define validate`. The gate's exit code, captured stdout, and captured stderr are written to a per-gate report at the configured stable path.",
+      "given": "the pipeline has run against the head commit",
+      "when": "the reviewer opens the per-gate report file at `<reportDir>/coverage-strict.json`",
+      "then": "the file exists, its `gate` field is `coverage-strict`, its `command` field names the `rcf audit coverage --strict` invocation, its `exitCode` field records the underlying process exit code, and its `stdout` and `stderr` fields carry the captured streams",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6104-2",
+      "description": "A non-zero exit from `rcf audit coverage --strict` (exit 4 on gaps, per mechanism) marks the aggregate verdict as failed and the aggregate exit code as non-zero. The suite never substitutes shallow-any coverage for strict coverage.",
+      "given": "an invocation of the suite against a tree with a deliberately uncovered AC",
+      "when": "the suite completes",
+      "then": "the aggregate report's `verdict` field is `failed`, its `gates[]` entry for `coverage-strict` records `outcome: failed` with the underlying exit code preserved, and no gate report on disk records a shallow-any invocation for coverage",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "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/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6105.json

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6105",
+  "prdId": "PRD-001",
+  "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)",
+  "iWant": "each gate the suite runs to write a JSON report file at a stable relative path with a stable schema",
+  "soThat": "I can pick up the gate's outcome without re-running it or scraping the CI provider's log surface",
+  "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`, 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`, `checkKind` is one of `validate`, `coverage-strict`, `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`, or a `custom:<name>` string)",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6105-2",
+      "description": "The `toolVersion` field records the underlying CLI's version string (the value `rcf --version` prints) at the time the gate ran. A tool-version mismatch across two pipeline runs of the same commit is visible in the report without re-running the gate.",
+      "given": "two invocations of the suite against the same commit under two different installed versions of the `rcf` CLI",
+      "when": "the reviewer diffs the two runs' per-gate reports",
+      "then": "the `toolVersion` field in the affected per-gate reports differs between the two runs, and the value on each side matches what the invoked `rcf --version` prints on that host",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-702-delivery-ci-workflows-gate-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-6106.json

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6106",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The suite emits an aggregate pipeline report at a stable path",
+  "asA": "downstream reader who needs the single-record verdict of a pipeline run",
+  "iWant": "an aggregate report at a stable path summarising every gate's outcome and pointing at the per-gate reports",
+  "soThat": "the pipeline's answer is one JSON file whose shape I can rely on across blueprint minor versions",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6106-1",
+      "description": "The suite writes an aggregate report at `<reportDir>/pipeline.json` on every run. The aggregate carries `verdict`, `trigger`, `startedAt`, `endedAt`, `durationMs`, `runner.entryPoint`, and `gates[]` (each entry naming `gate`, `outcome`, `durationMs`, and `reportPath`).",
+      "given": "the suite has run against any tree",
+      "when": "the reviewer opens `<reportDir>/pipeline.json`",
+      "then": "the file exists, its top-level keys are exactly the fixed set above, `verdict` is one of `passed` or `failed`, `gates[]` is a non-empty array in fixed configured order, and every `reportPath` value resolves to an existing per-gate report file at that relative path",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6106-2",
+      "description": "The aggregate verdict is `passed` if and only if every gates[] entry's `outcome` is `passed` and no entry's outcome is `missing`.",
+      "given": "any suite run whose gates[] array contains at least one entry with outcome `failed` or `missing`",
+      "when": "the reviewer reads the aggregate report",
+      "then": "the aggregate report's `verdict` field is `failed`, and the aggregate does not record `passed` while any per-gate entry recorded a non-`passed` outcome",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "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-6107.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6107",
+  "prdId": "PRD-001",
+  "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",
+  "asA": "reviewer whose first look at a red CI job is the runner-log tail",
+  "iWant": "the tail of the failing pipeline job to name the failing gate and point me at the report file",
+  "soThat": "I find the detail I need without clicking through the provider's UI",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6107-1",
+      "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 `[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"
+    },
+    {
+      "id": "AC-6107-2",
+      "description": "The suite continues past a failing gate to run the remaining required gates and record their outcomes. Multiple gate failures produce multiple entries in the aggregate report's `gates[]` array, each carrying its own outcome and report path.",
+      "given": "a suite invocation against a tree that fails both `validate` and `coverage-strict`",
+      "when": "the suite completes",
+      "then": "the aggregate report's `gates[]` array contains both `validate` and `coverage-strict` entries, each with `outcome: failed`, and each with a `reportPath` value pointing to an existing per-gate report file",
+      "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/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6108.json

@@ -0,0 +1,37 @@
+{
+  "usId": "delivery-ci-workflows-US-6108",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-008",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "A missing gate report is never treated as an implicit pass",
+  "asA": "reviewer trusting the aggregate report as the sole ledger of what actually ran",
+  "iWant": "the aggregate verdict to be `failed` on any missing required gate report",
+  "soThat": "a runner crash, an unhandled exception, or a write failure cannot be indistinguishable from success",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6108-1",
+      "description": "The aggregate report records the fixed configured set of required gates as its `gates[]` array in configured order. A required gate whose per-gate report file was not written during the run is recorded in the array with `outcome: missing` and a `reason` field naming the failure mode.",
+      "given": "a suite invocation in which the `coverage-strict` gate's Node child process was killed before its report could be written (or the report directory was not writable, or the child exited with an uncaught exception)",
+      "when": "the aggregate report is written at the end of the run",
+      "then": "the aggregate report's `gates[]` array contains a `coverage-strict` entry with `outcome: missing`, its `reason` field carries a non-empty string, and the aggregate `verdict` is `failed`",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6108-2",
+      "description": "The Node entry point's process exit code is non-zero when any required gate's outcome is `missing`, even if no gate outcome is `failed`.",
+      "given": "a suite invocation whose required-gate set has one gate outcome `missing` and every other outcome `passed`",
+      "when": "the Node entry point completes",
+      "then": "the process exit code is non-zero, and the aggregate report's `verdict` is `failed`",
+      "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/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/delivery-ci-workflows/contributions/user-stories/delivery-ci-workflows-us-6110.json

@@ -0,0 +1,36 @@
+{
+  "usId": "delivery-ci-workflows-US-6110",
+  "prdId": "PRD-001",
+  "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",
+  "asA": "developer reproducing a CI failure on my own machine",
+  "iWant": "the exact command the CI job ran to run the same way on my checkout",
+  "soThat": "I reproduce the failure without guessing which flag or wrapper produced it",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6110-1",
+      "description": "The CI provider's job step invokes the Node entry point with the same command a developer runs locally: the same file path, the same required arguments, the same environment variables the entry point reads (report directory path, tool-version pin). No CI-only wrapper script sits between the runner and the Node entry point.",
+      "given": "an rcf-lite project with this blueprint applied and a CI job wired per the illustrative example",
+      "when": "a developer runs the same command line the CI job's invocation step records against their local checkout at the same commit",
+      "then": "the aggregate report the local run writes at the configured report directory carries the same `runner.entryPoint`, the same `gates[]` ordering, and the same per-gate outcomes as the CI run's aggregate report for that commit, given the same rcf CLI version installed locally",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-6110-2",
+      "description": "The gate entry point reads no CI-provider-specific environment variable to alter its behaviour. Every configuration input the entry point honours is documented and available to a developer running locally.",
+      "given": "the applied blueprint's source path and the project's realised gate entry point",
+      "when": "the reviewer greps the entry point's source and its dependency modules for reads against known CI-provider environment variables (`GITHUB_ACTIONS`, `GITLAB_CI`, `CIRCLECI`, `BUILDKITE`, `JENKINS_URL`)",
+      "then": "no read of any of those variables gates the entry point's control flow or its gate set; if any such variable is read it is only for reporting into the aggregate report's `runner.environment` metadata field",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}