rcf-lite 0.25.0 → 0.27.0

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

@@ -11,12 +11,13 @@
   "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.",
+      "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. 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": "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6108-2",
@@ -25,7 +26,22 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6108-3",
+      "description": "An interrupted aggregate report rewrite (SIGKILL of the aggregate step mid-write) never leaves a stale passing aggregate standing for the current run: after interruption, the aggregate is either the current run's fully-written value OR absent; the pipeline treats an absent aggregate as missing per REQ-008 and refuses a pipeline pass. 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 aggregate from a previous run and an aggregate step about to write for the current run",
+      "when": "the aggregate writer is SIGKILLed mid-way through writing, then the pipeline evaluates the aggregate",
+      "then": "the aggregate is either the new run's fully-written value or absent; the pipeline refuses the pass when absent; the previous run's aggregate never survives",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-703-delivery-ci-workflows-aggregate-report",
+        "field": "responsibilities[3]"
+      }
     }
   ],
   "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-6109.json

@@ -11,26 +11,33 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited providerHint; the AC substitutes the project's provider assets for the illustrative GitHub-Actions asset set.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited providerHint; the AC substitutes the project's provider assets for the illustrative GitHub-Actions asset set.",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces[2].name"
+      },
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     }
   ],
   "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",
+  "description": "Section 7a floor: two ACs. Guide and TAC-701 name no US-6109-specific failure paths beyond runner-missing (covered generically by AC-6102-3 unknown-executable refusal) and gate-aggregation gaps (covered by AC-6108-1 required-gate listing); this story owns the shipped GHA illustrative assets and the alternate-provider mapping documentation (per REQ-009 and assets/ci-provider-examples/notes.md)."
 }

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

@@ -11,26 +11,42 @@
   "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.",
+      "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. 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 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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited providerHint; the AC substitutes the project's provider assets for the illustrative GitHub-Actions asset set.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6110-3",
+      "description": "A gate that produces different exit codes locally versus in CI (a stateful runner that reads process.env.CI) fails the parity assertion: the local invocation and the CI invocation must produce equal per-gate JSON reports (excluding wall-clock durations); a difference is flagged as a parity defect the operator resolves at the gate implementation, not by tolerating drift.",
+      "given": "a gate whose exit code depends on process.env.CI (returns 0 locally, 1 in CI)",
+      "when": "the same tree is run locally and under CI=1",
+      "then": "the per-gate reports differ in verdict; the runner's parity-check flag (documented) marks the drift and the operator is directed to remove the CI-dependent branch from the gate",
+      "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-6111.json

@@ -11,26 +11,42 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6111-2",
-      "description": "The three required fields (`branchModel`, `checkSet`, `providerHint`), the optional `releaseMode` field (absent has the same effect as `releaseMode: none`, per Q6-B ratification), the optional `scheduledAudit` field, the optional `trunkPullRequests` sub-field, and the optional substitution-surface fields `defaultBranch` (default `main`), `trunkBranch` (default `main`), and `packageManager` (default `pnpm`; recognised set `pnpm`, `npm`, `yarn`, `bun`) are the complete surface the workflow-materialiser reads. No other field the file carries is interpreted at this version; unknown fields are ignored (forward-compatibility).",
+      "description": "The three required fields (`branchModel`, `checkSet`, `providerHint`), the optional `releaseMode` field (absent has the same effect as `releaseMode: none`, per Q6-B ratification), the optional `scheduledAudit` field, the optional `trunkPullRequests` sub-field, and the optional substitution-surface fields `defaultBranch` (default `main`), `trunkBranch` (default `main`), and `packageManager` (default `pnpm`; recognised set `pnpm`, `npm`, `yarn`, `bun`) are the complete surface the workflow-materialiser reads. No other field the file carries is interpreted at this version; unknown fields are ignored (forward-compatibility). Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a `workflowShape` declaration carrying the three required fields, the optional fields, and additional unknown fields",
       "when": "the workflow-materialiser reads the file",
       "then": "the materialiser processes the recognised fields (including the substitution-surface trio) and ignores the unknown fields without failing the boot-check",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6111-3",
+      "description": "A workflowShape configuration whose branchModel is `trunk` but whose materialised outputs still write a pull-request-checks workflow (drift from ADR-706 defaults) fails a materialiser self-check: the writer refuses with WORKFLOW_SHAPE_MISMATCH naming branchModel and the extra file. Prevents silent divergence from the ratified shape mapping. Template values the applying agent sets: The applying agent sets the elicited workflowShape.branchModel; the AC substitutes the project's branch model for the illustrative trunk and the writer-refused file for pull-request-checks.yml.",
+      "given": "a materialiser invoked with branchModel=trunk and a stub that would still emit pull-request-checks.yml",
+      "when": "the materialiser runs its self-check",
+      "then": "the writer refuses with WORKFLOW_SHAPE_MISMATCH naming branchModel=trunk and the pull-request-checks.yml file; nothing is written",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "interfaces.materialise"
+      }
     }
   ],
   "tacIds": [
     "TAC-704-delivery-ci-workflows-workflow-materialiser"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,26 +11,56 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6112-3",
+      "description": "An absent .rcf/config/delivery-ci-workflows.json file is refused at materialise-time with a stable-coded WORKFLOW_CONFIG_MISSING naming the expected path; no workflow file is written to the workflow directory.",
+      "given": "a project tree that has never applied a workflow shape (no .rcf/config/delivery-ci-workflows.json)",
+      "when": "the workflow-materialiser runs",
+      "then": "the materialiser exits with a non-zero code and emits WORKFLOW_CONFIG_MISSING naming the expected path; the workflow directory is unchanged",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "responsibilities[0]"
+      }
+    },
+    {
+      "id": "AC-6112-4",
+      "description": "An unparseable .rcf/config/delivery-ci-workflows.json (invalid JSON) is refused at materialise-time with a stable-coded WORKFLOW_CONFIG_UNPARSEABLE naming the file path and the parser error; no workflow file is written.",
+      "given": "a project tree with .rcf/config/delivery-ci-workflows.json containing invalid JSON (e.g. a trailing comma before EOF)",
+      "when": "the workflow-materialiser runs",
+      "then": "the materialiser exits with a non-zero code and emits WORKFLOW_CONFIG_UNPARSEABLE naming the file path and the parser error position; the workflow directory is unchanged",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "responsibilities[0]"
+      }
     }
   ],
   "tacIds": [
     "TAC-704-delivery-ci-workflows-workflow-materialiser"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,26 +11,42 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6113-3",
+      "description": "A workflowShape configuration that combines a named profile alias with an inline override for the same field fails at expansion time with WORKFLOW_SHAPE_CONFLICT naming the field and the two sources; the materialiser refuses ambiguity. Template values the applying agent sets: The applying agent sets the elicited workflowShape (the profile alias name and any inline field override); the AC substitutes the project's alias and inline pair for the illustrative trunk-lite profile paired with branchModel=feature.",
+      "given": "a workflowShape configuration with profile=trunk-lite AND branchModel=feature (the alias sets trunk, the inline sets feature)",
+      "when": "the expander runs",
+      "then": "the expander refuses with WORKFLOW_SHAPE_CONFLICT naming branchModel and the two sources",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "interfaces.materialise"
+      }
     }
   ],
   "tacIds": [
     "TAC-704-delivery-ci-workflows-workflow-materialiser"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,21 +11,23 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6114-1",
-      "description": "With `workflowShape.branchModel: feature`, the materialiser produces a `pull-request-checks` workflow triggered by pull requests targeting the configured default branch (`workflowShape.defaultBranch`, default `main`). The workflow invokes the Node gate-runner entry point (TAC-701) with the required check set (mandatory tier plus every `checkSet` flag set true).",
+      "description": "With `workflowShape.branchModel: feature`, the materialiser produces a `pull-request-checks` workflow triggered by pull requests targeting the configured default branch (`workflowShape.defaultBranch`, default `main`). The workflow invokes the Node gate-runner entry point (TAC-701) with the required check set (mandatory tier plus every `checkSet` flag set true). Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a `workflowShape` with `branchModel: feature`, `defaultBranch: develop`, and every `checkSet` flag true",
       "when": "the workflow-materialiser runs",
       "then": "a `pull-request-checks` workflow file lands at the provider's workflow path, its trigger's branch list names `develop` (the configured default branch, not the placeholder marker and not a hard-coded `main`), and its command line invokes the Node gate-runner entry point with the required check set",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6114-2",
-      "description": "With `branchModel: feature`, the materialiser additionally produces a `default-branch-checks` workflow triggered by pushes to the configured default branch. The workflow invokes the same Node gate-runner entry point on the same required check set.",
+      "description": "With `branchModel: feature`, the materialiser additionally produces a `default-branch-checks` workflow triggered by pushes to the configured default branch. The workflow invokes the same Node gate-runner entry point on the same required check set. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "the same `workflowShape` (`branchModel: feature`, `defaultBranch: develop`)",
       "when": "the workflow-materialiser runs",
       "then": "a `default-branch-checks` workflow file lands at the provider's workflow path, its trigger's branch list names `develop`, and its command line invokes the Node gate-runner entry point with the required check set",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6114-3",
@@ -34,7 +36,8 @@
       "when": "a pull request whose most recent `pull-request-checks` aggregate report records `verdict: failed` is submitted for merge",
       "then": "the platform refuses the merge and the refusal reason references the failed `pull-request-checks` required check",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -11,21 +11,37 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6115-1",
-      "description": "With `workflowShape.branchModel: trunk` and `trunkPullRequests` absent or `never`, the materialiser produces `default-branch-checks` only, triggered by pushes to the configured trunk branch (`workflowShape.trunkBranch`, default `main`). The `pull-request-checks` workflow does not ship in this shape.",
+      "description": "With `workflowShape.branchModel: trunk` and `trunkPullRequests` absent or `never`, the materialiser produces `default-branch-checks` only, triggered by pushes to the configured trunk branch (`workflowShape.trunkBranch`, default `main`). The `pull-request-checks` workflow does not ship in this shape. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a `workflowShape` with `branchModel: trunk`, `trunkBranch: trunk`, and no `trunkPullRequests` field",
       "when": "the workflow-materialiser runs",
       "then": "a `default-branch-checks` workflow file lands at the provider's workflow path, its trigger's branch list names `trunk` (the configured trunk branch), no `pull-request-checks` workflow file lands, and the merge-policy AC binds to the trunk-branch push-protection property",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6115-2",
-      "description": "With `branchModel: trunk` and `trunkPullRequests: sometimes`, the materialiser additionally produces `pull-request-checks` on the same required check set as `default-branch-checks`, both triggered against the configured trunk branch.",
+      "description": "With `branchModel: trunk` and `trunkPullRequests: sometimes`, the materialiser additionally produces `pull-request-checks` on the same required check set as `default-branch-checks`, both triggered against the configured trunk branch. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a `workflowShape` with `branchModel: trunk`, `trunkBranch: trunk`, and `trunkPullRequests: sometimes`",
       "when": "the workflow-materialiser runs",
       "then": "both workflow files land at the provider's workflow path with their trigger branch lists naming `trunk`, and the merge-policy AC binds to the trunk-branch protection property that admits only PRs whose `pull-request-checks` aggregate passed",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6115-3",
+      "description": "A trunk-shape workflow whose optional pull-request-checks sub-shape is disabled does not write pull-request-checks.yml, even when the elicited providerHint would otherwise ship it; the materialiser refuses to write an unreferenced file. Template values the applying agent sets: The applying agent sets the elicited workflowShape trunk sub-shape (branchModel=trunk and the trunkPullRequests toggle); the AC substitutes the project's sub-shape for the illustrative trunk-with-pull-requests-disabled case.",
+      "given": "a trunk shape with pull-request-checks disabled",
+      "when": "the materialiser runs",
+      "then": "no pull-request-checks.yml is written; the default-branch-checks.yml still writes; the run reports zero extra artefacts",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "interfaces.materialise"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +49,5 @@
     "TAC-701-delivery-ci-workflows-gate-runner"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,27 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6116-1",
-      "description": "When `checkSet.linter` is true, the gate-runner runs the project-realised linter runner, captures its exit code and streams, and writes the per-gate report to `.rcf/reports/ci/lint.json` with `checkKind: \"linter\"`. A non-zero exit code from the runner flips the gate outcome to `failed`.",
+      "description": "When `checkSet.linter` is true, the gate-runner runs the project-realised linter runner, captures its exit code and streams, and writes the per-gate report to `.rcf/reports/ci/lint.json` with `checkKind: \"linter\"`. A non-zero exit code from the runner flips the gate outcome to `failed`. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a project with `checkSet.linter: true` and a realised linter runner satisfying the runner-contract interface",
       "when": "a CI workflow invokes the gate-runner",
       "then": "a report file at `.rcf/reports/ci/lint.json` is written with `checkKind: \"linter\"`, and the gate outcome tracks the runner exit code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6116-2",
+      "description": "The linter gate's per-gate report at the elicited report-dir path carries a stable shape (fields verdict, exitCode, checkKind, findings[], reportedAt) even when the underlying linter produces no findings; a zero-finding run writes findings=[] rather than omitting the array. Template values the applying agent sets: The applying agent sets the elicited report directory; the AC substitutes the project's report path for the illustrative .rcf/reports/ci/lint.json default.",
+      "given": "the linter gate runs against a tree that produces zero lint findings",
+      "when": "the gate report is written",
+      "then": "the report file exists at the elicited path with verdict=passed, exitCode=0, checkKind=linter, findings=[] and a valid reportedAt timestamp",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-702-delivery-ci-workflows-gate-report",
+        "field": "interfaces.gate-report-schema"
+      }
     }
   ],
   "tacIds": [
@@ -24,5 +39,6 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "description": "Section 7a floor: two ACs. Guide and TAC-701 name no linter-specific failure paths beyond runner-missing (AC-6102-3) and gate-aggregation gaps (AC-6108-1); this story owns the linter-specific gate mechanics (per-gate report at .rcf/reports/ci/lint.json with checkKind=linter, zero-finding runs writing findings=[])."
 }

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

@@ -11,12 +11,27 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6117-1",
-      "description": "When `checkSet.formatter` is true, the gate-runner runs the project-realised formatter runner in check mode. A non-zero exit code from the runner (indicating one or more files would be rewritten) flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/format.json` carries `checkKind: \"formatter\"`.",
+      "description": "When `checkSet.formatter` is true, the gate-runner runs the project-realised formatter runner in check mode. A non-zero exit code from the runner (indicating one or more files would be rewritten) flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/format.json` carries `checkKind: \"formatter\"`. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a project with `checkSet.formatter: true` and a realised formatter runner in check mode",
       "when": "a CI workflow invokes the gate-runner",
       "then": "a report file at `.rcf/reports/ci/format.json` is written with `checkKind: \"formatter\"`, and the gate outcome tracks the runner exit code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6117-2",
+      "description": "The formatter gate refuses to write files (it runs in --check mode); a formatter that mutates files during its run flips the gate to failed with FORMATTER_MUTATED_TREE naming the offending file, so a misconfigured hook never rewrites the tree on the CI runner.",
+      "given": "a formatter gate configured with a hook that mutates files under packages/",
+      "when": "the gate runs",
+      "then": "the gate exits non-zero with FORMATTER_MUTATED_TREE naming the mutated file; the tree is captured pre-run and compared post-run to detect the mutation",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces.runGates"
+      }
     }
   ],
   "tacIds": [
@@ -24,5 +39,6 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "description": "Section 7a floor: two ACs. Guide and TAC-701 name no formatter-specific failure paths beyond runner-missing (AC-6102-3), gate-aggregation gaps (AC-6108-1), and the mutation-refusal path bound by AC-6117-2; this story owns the formatter-specific gate mechanics (check-mode invocation, unformatted-file exit-code semantic)."
 }

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

@@ -11,21 +11,37 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6118-1",
-      "description": "When `checkSet.typecheck` is true (or the auto-detect finds a `tsconfig.json` or equivalent tool marker at the project root and the flag is unset), the gate-runner runs the project-realised typecheck runner. A non-zero exit flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/typecheck.json` carries `checkKind: \"typecheck\"`.",
+      "description": "When `checkSet.typecheck` is true (or the auto-detect finds a `tsconfig.json` or equivalent tool marker at the project root and the flag is unset), the gate-runner runs the project-realised typecheck runner. A non-zero exit flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/typecheck.json` carries `checkKind: \"typecheck\"`. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a project with `checkSet.typecheck: true` and a realised typecheck runner",
       "when": "a CI workflow invokes the gate-runner",
       "then": "a report file at `.rcf/reports/ci/typecheck.json` is written with `checkKind: \"typecheck\"`, and the gate outcome tracks the runner exit code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6118-2",
-      "description": "When `checkSet.typecheck` is unset and the project tree contains no `tsconfig.json` or equivalent tool marker, the auto-detect leaves the check off and no `typecheck.json` report file is written.",
+      "description": "When `checkSet.typecheck` is unset and the project tree contains no `tsconfig.json` or equivalent tool marker, the auto-detect leaves the check off and no `typecheck.json` report file is written. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a project with `checkSet.typecheck` unset and no typechecker marker at the project root",
       "when": "a CI workflow invokes the gate-runner",
       "then": "no `typecheck` gate is included in the aggregate report and no `.rcf/reports/ci/typecheck.json` file is written",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6118-3",
+      "description": "A typecheck configured on a project that has no typechecker at all skips with checkKind=typecheck and verdict=skipped (with a stable reason `no-typechecker-configured`); the aggregate treats skipped as pass for the aggregate report only when the required set does not include typecheck, else refuses pipeline pass. Template values the applying agent sets: The applying agent sets the elicited workflowShape.checkSet (specifically the typecheck flag) and the required-set membership; the AC substitutes the project's checkSet for the illustrative typecheck-required configuration.",
+      "given": "a project with checkSet.typecheck true but no tsconfig or equivalent",
+      "when": "the gate runs",
+      "then": "the per-gate report writes verdict=skipped with reason=no-typechecker-configured; the aggregate refuses pass when typecheck is in the required set",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "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-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,12 +11,27 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6119-1",
-      "description": "When `checkSet.unitTest` is true, the gate-runner runs the project-realised unit-test runner. A non-zero exit code flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/test.json` carries `checkKind: \"unitTest\"`.",
+      "description": "When `checkSet.unitTest` is true, the gate-runner runs the project-realised unit-test runner. A non-zero exit code flips the gate outcome to `failed`. The per-gate report at `.rcf/reports/ci/test.json` carries `checkKind: \"unitTest\"`. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a project with `checkSet.unitTest: true` and a realised unit-test runner",
       "when": "a CI workflow invokes the gate-runner",
       "then": "a report file at `.rcf/reports/ci/test.json` is written with `checkKind: \"unitTest\"`, and the gate outcome tracks the runner exit code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6119-2",
+      "description": "The unit-test gate refuses to declare a pass when the underlying test runner exits 0 but the tap/junit-shaped output reports at least one `fail` line; the gate parses the runner's test-report artefact and takes the stricter of exit code and parsed status.",
+      "given": "a unit-test runner that exits 0 but emits a tap output with `not ok` on one test",
+      "when": "the gate runs",
+      "then": "the per-gate report writes verdict=failed naming the failing test id and pointing at the tap artefact",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces.runGates"
+      }
     }
   ],
   "tacIds": [
@@ -24,5 +39,6 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "description": "Section 7a floor: two ACs. Guide and TAC-701 name no unit-test-specific failure paths beyond runner-missing (AC-6102-3), gate-aggregation gaps (AC-6108-1), and the exit-zero-but-parsed-failures path bound by AC-6119-2; this story owns the unit-test-specific gate mechanics (per-gate report at .rcf/reports/ci/test.json with checkKind=unitTest, tap-parsed strict verdict)."
 }

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

@@ -11,12 +11,27 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6120-1",
-      "description": "When `checkSet.securityScan` is true, the gate-runner runs the project-realised security-scan runner. A non-zero exit code (indicating one or more findings at or above the project-configured severity threshold) flips the gate outcome to `failed`. Findings below the threshold are recorded in the per-gate report without flipping the exit code. The per-gate report at `.rcf/reports/ci/security.json` carries `checkKind: \"securityScan\"`.",
+      "description": "When `checkSet.securityScan` is true, the gate-runner runs the project-realised security-scan runner. A non-zero exit code (indicating one or more findings at or above the project-configured severity threshold) flips the gate outcome to `failed`. Findings below the threshold are recorded in the per-gate report without flipping the exit code. The per-gate report at `.rcf/reports/ci/security.json` carries `checkKind: \"securityScan\"`. Template values the applying agent sets: The applying agent sets the workflowShape elicits (checkSet, branchModel, releaseMode, scheduledAudit, providerHint); the AC substitutes the project's declaration for the illustrative shape values.",
       "given": "a project with `checkSet.securityScan: true` and a realised security-scan runner configured with the project's severity threshold",
       "when": "a CI workflow invokes the gate-runner",
       "then": "a report file at `.rcf/reports/ci/security.json` is written with `checkKind: \"securityScan\"`, and the gate outcome tracks the runner exit code",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6120-2",
+      "description": "The security-scan gate reads the project severity threshold and fails at or above it; a finding one severity level below the threshold does not fail the gate but is written to the per-gate report so the operator sees the near-miss. Template values the applying agent sets: The applying agent supplies the project's severity threshold and the scanner's finding shape; the AC substitutes them for the illustrative threshold=high paired with a medium finding and a high finding.",
+      "given": "a security scanner configured with threshold=high and a run that yields a medium finding and a high finding",
+      "when": "the gate runs",
+      "then": "the per-gate report writes verdict=failed on the high finding; the medium finding appears under `belowThreshold[]` with severity=medium; the report is written even when the gate fails",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+        "field": "interfaces.runGates"
+      }
     }
   ],
   "tacIds": [
@@ -24,5 +39,6 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-08-31T00:00:00Z",
-  "updatedAt": "2026-08-31T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "description": "Section 7a floor: two ACs. Guide and TAC-701 name no security-scan-specific failure paths beyond runner-missing (AC-6102-3), gate-aggregation gaps (AC-6108-1), and the severity-threshold path bound by AC-6120-2; this story owns the security-scan-specific gate mechanics (per-gate report at .rcf/reports/ci/security.json with belowThreshold[] carrying near-misses)."
 }