rcf-lite 0.25.0 → 0.27.0

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "Each gate writes a machine-readable JSON report file at a stable path on every invocation",
   "description": "Every gate the suite invokes writes a JSON report file at a stable relative path under a project-configured report directory (default `.rcf/reports/ci/`). The per-gate report file is written whether the gate passed or failed. The report file carries the gate name, the underlying CLI invocation, the exit code, the start and end ISO-8601 timestamps, the duration in milliseconds, the tool version invoked, the captured stdout and stderr strings, and (v2 addition) a `checkKind` field naming the elicited-check kind (`validate`, `coverage-strict`, `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`, or `custom:<name>`). The report file's schema is stable within a blueprint major version; v1 additive fields (the `checkKind` addition) are preserved from v1.0.0 to v2.0.0.",
+  "deliveredBy": {
+    "tacId": "TAC-702-delivery-ci-workflows-gate-report",
+    "field": "interfaces.writeGateReport"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The suite emits an aggregate pipeline report summarising every gate's outcome at a stable path",
   "description": "The suite writes a single aggregate JSON report at a stable path under the same report directory (default `.rcf/reports/ci/pipeline.json`). The aggregate report carries the suite's own start and end ISO-8601 timestamps, the total duration, an overall pass/fail verdict, the fixed ordered list of gates the suite ran, and for each gate an entry naming the gate, its outcome, its duration, and the relative path to the per-gate report file. The aggregate schema is stable within a blueprint major version.",
+  "deliveredBy": {
+    "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
+    "field": "interfaces.writeAggregateReport"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "Gate failures produce operator-readable output naming the failing gate and pointing to the per-gate report",
   "description": "When any gate in the suite fails, the Node entry point writes an operator-readable failure summary to its own stderr and to the aggregate report's `failure` field. The summary names the failing gate, the failing invocation's exit code, the first few lines of the captured stderr, and the relative path to the per-gate report file the reviewer can open for the full detail. The suite continues past a failing gate to run the remaining required gates and record their outcomes; the aggregate exit is non-zero if any gate failed.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The suite refuses to declare a pipeline pass when any required gate report is missing from the aggregate",
   "description": "The aggregate report's `gates` array lists every required gate in fixed configured order. If the suite completes without a corresponding per-gate report on disk for any required gate (a runner crash, an unhandled exception in a gate invocation, a report directory that was not writable), the aggregate report records the missing gate as `missing` with an explanatory reason, the aggregate verdict is `failed`, and the suite exits non-zero. A missing report is never treated as an implicit pass.",
+  "deliveredBy": {
+    "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
+    "field": "interfaces.writeAggregateReport"
+  },
   "category": "nonFunctional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The blueprint ships illustrative GitHub Actions workflow files for every workflow the matrix materialises; alternate providers wire the same entry points per the four-point mapping",
   "description": "The blueprint's package resources include one illustrative GitHub Actions workflow file per workflow the v2 matrix materialises (`pull-request-checks.yml`, `default-branch-checks.yml`, `release.yml`, and `scheduled-audit.yml` under `assets/ci-provider-examples/github-actions/`). Each file names the required trigger set for its workflow, sets up Node and the package manager, installs dependencies, invokes the corresponding Node entry point (gate-runner for the check-set workflows, release orchestrator for the release workflow, scheduled-audit runner for the cron workflow), and uploads the report directory as a workflow artefact. The blueprint's guide names GitLab CI, CircleCI, Buildkite, and Jenkins as equally supported providers, calls out the four-point 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; sibling asset packs (v2.1 candidate) can ship them without changing the AC contracts.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The gate suite entry point is the same code path locally and in CI",
   "description": "The Node entry point script is invocable on a developer's machine with the same command the CI provider invokes, against the same tree the developer has checked out, and produces the same per-gate reports and aggregate report at the same stable paths. A developer reproducing a CI failure runs the same one line the CI job ran; no CI-only wrapper or environment shim is on the CI code path but not the developer's.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "nonFunctional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -2,7 +2,11 @@
   "reqId": "delivery-ci-workflows-REQ-011",
   "prdId": "PRD-001",
   "title": "The project declares its CI workflow shape in a stable in-repo configuration file the workflow-materialiser reads",
-  "description": "The project ships a `workflowShape` declaration at the stable path `.rcf/config/delivery-ci-workflows.json` on the project tree. The declaration carries three required top-level fields (`branchModel`, `checkSet`, `providerHint`), one optional top-level field (`releaseMode`; absent has the same effect as `releaseMode: none`, per Q6-B ratification), one optional fifth field (`scheduledAudit`, default false), and one optional sub-field (`trunkPullRequests`) that qualifies `branchModel: trunk`. The four-field composed form (`branchModel`, `checkSet`, `releaseMode`, `providerHint`, with `releaseMode` defaulted to `none` when absent) is the authoritative representation the downstream workflow-materialiser (TAC-704) and every AC in this blueprint bind against; the profile-alias convenience surface (REQ-013) expands to the same composed form before any consumer reads it. The declaration is a data file, not code; the workflow-materialiser reads it once at the start of every materialisation run and refuses to proceed when the file is absent or malformed.",
+  "description": "The project ships a `workflowShape` declaration at the stable path `.rcf/config/delivery-ci-workflows.json` on the project tree. The declaration carries three required top-level fields (`branchModel`, `checkSet`, `providerHint`), one optional top-level field (`releaseMode`; absent has the same effect as `releaseMode: none`, per Q6-B ratification), one optional fifth field (`scheduledAudit`, default false), and one optional sub-field (`trunkPullRequests`) that qualifies `branchModel: trunk`. The four-field composed form (`branchModel`, `checkSet`, `releaseMode`, `providerHint`, with `releaseMode` defaulted to `none` when absent) is the authoritative representation the downstream workflow-materialiser (TAC-704) and every AC in this blueprint bind against; the profile-alias convenience surface (REQ-013) expands to the same composed form before any consumer reads it. The declaration is a data file, not code; the workflow-materialiser reads it once at the start of every materialisation run and refuses to proceed when the file is absent or malformed. The `providerHint` field currently accepts one shipped-asset value, `githubActions`, whose runtime clause is: the workflow-materialiser reads `githubActions` from the declaration and seeds the shipped illustrative GitHub Actions workflow files from `assets/ci-provider-examples/github-actions/` (per REQ-009 and ADR-708). Other named provider hints are elicit-accepted but do not seed provider assets in v2 (per ADR-708-delivery-ci-workflows-provider-hint-shape); AC-6113-1 binds the four-field expansion including `providerHint: githubActions`.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",
@@ -14,5 +18,5 @@
   "version": "2.0.0",
   "status": "approved",
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "A missing or unrecognised workflowShape field is refused at boot with a stable-coded error naming the field",
   "description": "The workflow-materialiser performs a boot-check on the `workflowShape` declaration before any workflow file is produced. Any of the three required top-level fields (`branchModel`, `checkSet`, `providerHint`) being absent causes the materialiser to exit non-zero with a stable-coded error message that names the missing field. Any field (required or optional) carrying a value not in the recognised enumeration causes the same failure shape, with the message additionally naming the value it received and the allowed set. `releaseMode` being absent is NOT a failure (Q6-B ratification): the materialiser treats it as `releaseMode: none` and ships no release workflow. A `releaseMode: deployHandoff:<slug>` value additionally triggers a manifest boot-check (REQ-022) that names the required deploy blueprint if it is missing from `manifest.blueprints[]`. The boot-check runs before any workflow file is written; a partial workflow set never lands on disk.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "Named profile aliases expand to the authoritative four-field workflowShape form before any consumer reads it",
   "description": "The elicitation surface accepts a named profile alias (`smallLibrary`, `smallService`, `internalPackage`, `trunkLibrary`) in place of the four-field form. On boot the workflow-materialiser detects the alias, expands it to the shipped four-field composition, and treats the expanded form as authoritative for every downstream. Every AC in this blueprint binds to the four-field form only; the alias layer is a convenience surface, not an authoritative representation. An unrecognised alias name is refused at boot with a stable-coded error naming the alias and listing the shipped set. A project that wants a shape the shipped aliases do not name uses the four-field form.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "should",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The feature-branch shape materialises pull-request-checks and default-branch-checks workflows against the required check set",
   "description": "When `workflowShape.branchModel` is `feature`, the workflow-materialiser produces two workflows sharing the same required check set: `pull-request-checks` firing on pull requests targeting the default branch, and `default-branch-checks` firing on pushes to the default branch. Both workflows invoke the same Node gate-runner entry point (TAC-701) with the required check set produced by the two-tier catalogue (mandatory tier plus the elicited subset from `checkSet`). Both workflows write their aggregate report to the stable path and preserve the ordering discipline. The blueprint contributes an AC that the project configure default-branch protection to require the `pull-request-checks` aggregate as a merge-blocking check; the configuration itself is a project responsibility on the platform's own surface.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The trunk-based shape is a first-class option with a sub-shape for optional pull-request use",
   "description": "When `workflowShape.branchModel` is `trunk`, the workflow-materialiser produces `default-branch-checks` as the always-on workflow firing on every push to the trunk branch. A nested `trunkPullRequests` field qualifies the shape: `never` (default) ships only `default-branch-checks`; `sometimes` additionally ships `pull-request-checks` against the same check set. The merge-policy AC states the property differently per sub-shape: without PRs, the trunk branch's push protection admits only commits whose `default-branch-checks` aggregate passed; with PRs, the trunk branch's protection admits only PRs whose `pull-request-checks` aggregate passed. Every other contract (check catalogue, report shape, ordering) is shared with the feature-branch shape.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "A linter check the project realises produces a stable-shape lint report and fails non-zero on any lint error",
   "description": "The elicited `linter` check, when the project enables it in `workflowShape.checkSet.linter`, runs a lint gate that exits non-zero on any lint error the project treats as blocking. The gate writes its per-gate report to `.rcf/reports/ci/lint.json` in the shared per-gate report shape (with `checkKind: \"linter\"`). The blueprint does not pick the linter tool; the project realises the runner over the tool of its choice and satisfies the runner-contract interface the gate-runner TAC binds. Warnings that the project does not treat as blocking are reported in the per-gate report without flipping the exit code.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "A formatter check the project realises produces a stable-shape formatter report and fails non-zero on any unformatted file",
   "description": "The elicited `formatter` check, when the project enables it in `workflowShape.checkSet.formatter`, runs a formatter check gate (not a formatter write) that exits non-zero when any tracked file would be rewritten by the formatter. The gate writes its per-gate report to `.rcf/reports/ci/format.json` in the shared per-gate report shape (with `checkKind: \"formatter\"`). The blueprint does not pick the formatter; the project realises the runner and satisfies the runner-contract interface.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "A typecheck the project realises produces a stable-shape typecheck report and fails non-zero on any type error",
   "description": "The elicited `typecheck` check, when the project enables it in `workflowShape.checkSet.typecheck`, runs a typechecker gate that exits non-zero on any type error. The gate writes its per-gate report to `.rcf/reports/ci/typecheck.json` in the shared per-gate report shape (with `checkKind: \"typecheck\"`). The check is applicable only when the project uses a typed language or a TypeScript-style build; the workflow-materialiser turns the check on by default when the project tree contains a `tsconfig.json` or an equivalent tool marker, off otherwise. The project overrides the auto-detection by setting the check-set flag explicitly.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "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.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "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.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "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.",
+  "deliveredBy": {
+    "tacId": "TAC-705-delivery-ci-workflows-release-workflow",
+    "field": "interfaces.runRelease"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "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.",
+  "deliveredBy": {
+    "tacId": "TAC-705-delivery-ci-workflows-release-workflow",
+    "field": "interfaces.runRelease"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "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.",
+  "deliveredBy": {
+    "tacId": "TAC-706-delivery-ci-workflows-scheduled-audit",
+    "field": "interfaces.runScheduledAudit"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -11,12 +11,13 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's path for the illustrative default.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6101-2",
@@ -25,7 +26,22 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6101-3",
+      "description": "A workflow whose trigger set omits one of the required events (a pull-request-checks workflow with only `push`) is refused at materialise-time with WORKFLOW_TRIGGER_INCOMPLETE naming the missing trigger; no workflow file is written.",
+      "given": "a workflowShape configuration whose materialised trigger set for a required workflow drops one of the required triggers",
+      "when": "the materialiser runs",
+      "then": "the process exits with a non-zero code and emits WORKFLOW_TRIGGER_INCOMPLETE naming the missing trigger and the workflow name; the workflow directory is unchanged",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "interfaces.materialise"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +49,5 @@
     "TAC-703-delivery-ci-workflows-aggregate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -16,7 +16,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-6102-2",
@@ -25,12 +26,27 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6102-3",
+      "description": "A gate that names an unknown executable in its command array (a `command[0]` that does not resolve on the PATH) is refused at gate spawn with a stable-coded GATE_SPAWN_FAILED naming the executable and the gate name; the runner does not continue with other gates until the operator resolves.",
+      "given": "a gate descriptor with command [\"nonexistent-bin\",\"arg\"] and a runner invoked against the descriptor",
+      "when": "the runner attempts to spawn the gate",
+      "then": "the gate reports failed with GATE_SPAWN_FAILED naming the executable and the gate; the per-gate report is written failed; the aggregate reflects the failure",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces.runGates"
+      }
     }
   ],
   "tacIds": [
     "TAC-701-delivery-ci-workflows-gate-runner"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,13 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's path for the illustrative default.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6103-2",
@@ -25,7 +26,22 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6103-3",
+      "description": "The validate gate exit code carries through to the pipeline: a validate command that returns exit 5 marks the gate failed with a per-gate report that records the exit code and the failing command; the aggregate refuses pipeline pass.",
+      "given": "a validate gate configured to run a stub that exits 5",
+      "when": "the runner invokes it",
+      "then": "the per-gate report writes verdict=failed with exitCode=5 and the command name; the aggregate refuses pipeline pass",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-702-delivery-ci-workflows-gate-report",
+        "field": "interfaces.writeGateReport"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +49,5 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,13 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's path for the illustrative default.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6104-2",
@@ -25,7 +26,22 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6104-3",
+      "description": "The strict coverage gate refuses to declare a pass when an AC has no resolving TC even if every other AC is covered; the per-gate report names the uncovered AC id and the aggregate refuses pipeline pass.",
+      "given": "a project tree where AC-999-x has no resolving TC and every other AC does",
+      "when": "the strict coverage gate runs",
+      "then": "the gate exits non-zero, the per-gate report names AC-999-x under uncovered, and the aggregate carries verdict=failed",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces.runGates"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +49,5 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,13 @@
   "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`.",
+      "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`. Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's path for the illustrative default.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6105-2",
@@ -25,12 +26,27 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6105-3",
+      "description": "An interrupted per-gate report rewrite (SIGKILL of the gate runner mid-write) never leaves a stale passing report standing for the current run: after interruption, a follow-up gate invocation on the same reportDir sees the previous report either fully replaced by the new one OR absent, never partially rewritten and never a stale success. Template values the applying agent sets: The applying agent supplies the elicited reportDir path; the AC substitutes it for the illustrative default.",
+      "given": "a reportDir containing a passing per-gate report from a previous run and a gate about to fail on the current run",
+      "when": "the gate runner is SIGKILLed mid-way through writing the new per-gate report, then a follow-up invocation reads the reportDir",
+      "then": "the follow-up invocation either finds the new failing report or no report at all for the interrupted gate; a subsequent aggregate step treats an absent report as missing per REQ-008; the previous run's passing report never survives the current run",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-702-delivery-ci-workflows-gate-report",
+        "field": "responsibilities[3]"
+      }
     }
   ],
   "tacIds": [
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,13 @@
   "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`).",
+      "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`). Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's path for the illustrative default.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6106-2",
@@ -25,12 +26,27 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6106-3",
+      "description": "The aggregate report writer refuses to overwrite a report path that resolves outside the elicited report directory (an attempted path traversal) with the stable code AGGREGATE_PATH_ESCAPE naming the offending path; the target file is not written.",
+      "given": "an aggregate writer invoked with a computed path that resolves outside the elicited report-dir (a symlink loop, a path traversal ../)",
+      "when": "the writer runs",
+      "then": "the writer refuses with AGGREGATE_PATH_ESCAPE naming the offending resolution; no bytes are written to the target",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
+        "field": "interfaces.writeAggregateReport"
+      }
     }
   ],
   "tacIds": [
     "TAC-703-delivery-ci-workflows-aggregate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,13 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's path for the illustrative default.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6107-2",
@@ -25,7 +26,22 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6107-3",
+      "description": "The operator-visible message on a gate failure names the failing gate first line, the failing command second line, and the per-gate report path third line; the format is stable across runs so downstream log parsers key on the shape.",
+      "given": "a run in which the linter gate fails",
+      "when": "the runner writes to stderr",
+      "then": "stderr's last three non-empty lines match the pattern gate:<name>, command:<argv>, report:<path>",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces.runGates"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +49,5 @@
     "TAC-703-delivery-ci-workflows-aggregate-report"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }