rcf-lite 0.26.0 → 0.28.0

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)."
 }

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

@@ -11,21 +11,23 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6121-1",
-      "description": "When `workflowShape.releaseMode` is `none`, the workflow-materialiser writes no `release` workflow file to the provider's workflow path. A project with no release path does not ship a workflow.",
+      "description": "When `workflowShape.releaseMode` is `none`, the workflow-materialiser writes no `release` workflow file to the provider's workflow path. A project with no release path does not ship a workflow. 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 `releaseMode: none`",
       "when": "the workflow-materialiser runs",
       "then": "no `release` workflow file is created at the provider's workflow path and no `.rcf/reports/ci/release.json` file is written",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6121-2",
-      "description": "When `releaseMode` is `tagOnly`, the release workflow fires on a release trigger and creates a release entity on the CI provider's own release surface. No artefact-publish step ships. When `tagPlusArtefact`, the release workflow additionally runs the project-realised artefact-publish step and uploads its output to the release entity.",
+      "description": "When `releaseMode` is `tagOnly`, the release workflow fires on a release trigger and creates a release entity on the CI provider's own release surface. No artefact-publish step ships. When `tagPlusArtefact`, the release workflow additionally runs the project-realised artefact-publish step and uploads its output to the release entity. 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 `releaseMode: tagPlusArtefact` and a realised artefact-publish step",
       "when": "a release trigger fires",
       "then": "the release workflow creates the release entity, runs the artefact-publish step, uploads the published artefact to the release entity, and records the just-published version identifier in the aggregate report",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6121-3",
@@ -34,7 +36,22 @@
       "when": "the release trigger fires",
       "then": "the release workflow does not invoke the gate-runner entry point and the `pipeline.json` at the same commit remains the record of the check set outcome",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-6121-4",
+      "description": "A failed release entity creation step (a tag write refused, a release API rejection, a permissions error) fails the release aggregate with a stable-coded RELEASE_CREATE_FAILED naming the step and the provider response; downstream publication and promote steps do not run. Template values the applying agent sets: The applying agent supplies the elicited providerHint and releaseMode; the AC substitutes them for the illustrative GHA / tagOnly.",
+      "given": "a release workflow at releaseMode=tagOnly with the provider forced to return 4xx on the tag write",
+      "when": "the release workflow runs",
+      "then": "the release aggregate is failed with RELEASE_CREATE_FAILED naming the create step and the provider status; no downstream publication step runs; the workflow exit code is non-zero",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-705-delivery-ci-workflows-release-workflow",
+        "field": "internalStructure"
+      }
     }
   ],
   "tacIds": [
@@ -42,5 +59,5 @@
     "TAC-705-delivery-ci-workflows-release-workflow"
   ],
   "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-6122.json

@@ -11,30 +11,47 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6122-1",
-      "description": "When `workflowShape.releaseMode` is `deployHandoff:<slug>` and the named deploy blueprint is present in `manifest.blueprints[]`, the release workflow invokes the deploy blueprint's `promote` workflow via `workflow_dispatch` after the artefact-publish step succeeds. The invocation passes the just-published version identifier as the `versionId` input.",
+      "description": "When `workflowShape.releaseMode` is `deployHandoff:<slug>` and the named deploy blueprint is present in `manifest.blueprints[]`, the release workflow invokes the deploy blueprint's `promote` workflow via `workflow_dispatch` after the artefact-publish step succeeds. The invocation passes the just-published version identifier as the `versionId` input. 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 `releaseMode: deployHandoff:deploy-cloudflare-workers`, the named deploy blueprint applied, and an artefact-publish step that succeeded",
       "when": "the release trigger fires",
       "then": "the release workflow dispatches the promote workflow with `versionId` set to the just-published version identifier and waits on the promote workflow's outcome",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6122-2",
-      "description": "The release workflow's aggregate outcome is `passed` only when the promote workflow's outcome is `passed`. A failed promote workflow flips the release workflow's aggregate to `failed`.",
+      "description": "The release workflow's aggregate outcome is `passed` only when the promote workflow's outcome is `passed`. A failed promote workflow flips the release workflow's aggregate to `failed`. Template values the applying agent sets: The applying agent sets the elicited deployHandoff target blueprint name; the AC substitutes that name for the illustrative slug.",
       "given": "a release workflow in `deployHandoff` mode whose promote workflow returned a failed outcome",
       "when": "the release workflow aggregates its outcome",
       "then": "the release workflow's aggregate report at `.rcf/reports/ci/release.json` records `verdict: failed` and names the promote workflow's failure in its `gates[]` array",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6122-3",
-      "description": "When `releaseMode` is `deployHandoff:<slug>` and the named deploy blueprint is not present in `manifest.blueprints[]`, the workflow-materialiser boot-check refuses with a stable-coded error naming the missing blueprint slug and pointing at `rcf define blueprint add <deploy-slug>`.",
+      "description": "When `releaseMode` is `deployHandoff:<slug>` and the named deploy blueprint is not present in `manifest.blueprints[]`, the workflow-materialiser boot-check refuses with a stable-coded error naming the missing blueprint slug and pointing at `rcf define blueprint add <deploy-slug>`. 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 `releaseMode: deployHandoff:deploy-cloudflare-workers` and no such blueprint in the manifest",
       "when": "the workflow-materialiser boots",
       "then": "the materialiser exits non-zero with a stable-coded error naming the missing slug and pointing at the resolution command, and no release workflow file lands on disk",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6122-4",
+      "description": "A failed artefact publication step (a checksum mismatch, an upload rejection, a permissions error) fails the release aggregate with a stable-coded RELEASE_PUBLISH_FAILED naming the artefact and the provider response; the deployHandoff promote workflow is not invoked. Template values the applying agent sets: The applying agent supplies the elicited providerHint, releaseMode and artefact set; the AC substitutes those.",
+      "given": "a release workflow at releaseMode=tagPlusArtefact with the artefact upload forced to fail on a specific artefact",
+      "when": "the release workflow runs",
+      "then": "the release aggregate is failed with RELEASE_PUBLISH_FAILED naming the artefact and the provider response; no promote step runs; the workflow exit code is non-zero",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-705-delivery-ci-workflows-release-workflow",
+        "field": "interfaces.runRelease"
+      }
     }
   ],
   "tacIds": [
@@ -42,5 +59,5 @@
     "TAC-705-delivery-ci-workflows-release-workflow"
   ],
   "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-6123.json

@@ -11,21 +11,37 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6123-1",
-      "description": "When `workflowShape.scheduledAudit` is `true`, the workflow-materialiser produces a `scheduled-audit` workflow triggered by the provider's cron surface, running the same required check set the pull-request and default-branch workflows run. The aggregate report writes to `.rcf/reports/ci/scheduled-audit.json` (distinct from the commit-triggered `pipeline.json`).",
+      "description": "When `workflowShape.scheduledAudit` is `true`, the workflow-materialiser produces a `scheduled-audit` workflow triggered by the provider's cron surface, running the same required check set the pull-request and default-branch workflows run. The aggregate report writes to `.rcf/reports/ci/scheduled-audit.json` (distinct from the commit-triggered `pipeline.json`). 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 `scheduledAudit: true`",
       "when": "the workflow-materialiser runs",
       "then": "a `scheduled-audit` workflow file lands at the provider's workflow path, its trigger set names a cron schedule, and its command line invokes the Node gate-runner entry point with the required check set writing to the distinct report path",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-6123-2",
-      "description": "When `scheduledAudit` is `false` or absent, no scheduled workflow ships and no `.rcf/reports/ci/scheduled-audit.json` file path is populated.",
+      "description": "When `scheduledAudit` is `false` or absent, no scheduled workflow ships and no `.rcf/reports/ci/scheduled-audit.json` file path is populated. 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 `scheduledAudit` absent (default `false`)",
       "when": "the workflow-materialiser runs",
       "then": "no `scheduled-audit` workflow file is created and no `.rcf/reports/ci/scheduled-audit.json` file path is written",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6123-3",
+      "description": "The scheduled-audit workflow refuses to write when the check-set is empty (a workflowShape with scheduled-audit=on but checkSet all-false): the materialiser emits SCHEDULED_AUDIT_EMPTY_CHECKSET naming the empty checkSet; no cron workflow is written. Template values the applying agent sets: The applying agent sets the elicited workflowShape (scheduledAudit and checkSet); the AC substitutes the project's workflowShape for the illustrative scheduled-audit-on with checkSet all-false case.",
+      "given": "a workflowShape with scheduled-audit=on and every checkSet flag false",
+      "when": "the materialiser runs",
+      "then": "the materialiser exits with SCHEDULED_AUDIT_EMPTY_CHECKSET; no scheduled-audit.yml is written",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-706-delivery-ci-workflows-scheduled-audit",
+        "field": "interfaces.runScheduledAudit"
+      }
     }
   ],
   "tacIds": [
@@ -33,5 +49,5 @@
     "TAC-706-delivery-ci-workflows-scheduled-audit"
   ],
   "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-6124.json

@@ -11,12 +11,27 @@
   "acceptanceCriteria": [
     {
       "id": "AC-6124-1",
-      "description": "The illustrative pull-request-checks.yml under blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/ carries a documented e2e job block whose header comment names the four points a browser-facing project's e2e job satisfies: (a) runs the project's testLevel: e2e cases against a local preview or a --parity-env runtime, (b) uploads screenshots and HTML captures as workflow artefacts, (c) writes a distinct row to the aggregate pipeline report at .rcf/reports/ci/pipeline.json, (d) writes a per-gate report at .rcf/reports/ci/e2e.json with checkKind: 'e2e'. The header also tells a non-browser project to delete the e2e job before committing. The elicited checkSet.e2e entry exists in the delivery-ci-workflows check catalogue (blueprint.json) so a project that turns the check off does so through a supported knob. The runtime iff wiring (materialiser adds or omits the job based on manifest.blueprints[].source.browserSurface.declared and .rcf/config/delivery-ci-workflows.json:checkSet.e2e) lands in a follow-up train with its own TS entry; this AC is documentation-only per spec amendment A2 (2026-09-03).",
+      "description": "The illustrative pull-request-checks.yml under blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/ carries a documented e2e job block whose header comment names the four points a browser-facing project's e2e job satisfies: (a) runs the project's testLevel: e2e cases against a local preview or a --parity-env runtime, (b) uploads screenshots and HTML captures as workflow artefacts, (c) writes a distinct row to the aggregate pipeline report at .rcf/reports/ci/pipeline.json, (d) writes a per-gate report at .rcf/reports/ci/e2e.json with checkKind: 'e2e'. The header also tells a non-browser project to delete the e2e job before committing. The elicited checkSet.e2e entry exists in the delivery-ci-workflows check catalogue (blueprint.json) so a project that turns the check off does so through a supported knob. The runtime iff wiring (materialiser adds or omits the job based on manifest.blueprints[].source.browserSurface.declared and .rcf/config/delivery-ci-workflows.json:checkSet.e2e) lands in a follow-up train with its own TS entry; this AC is documentation-only per spec amendment A2 (2026-09-03). 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 delivery-ci-workflows blueprint at v2.2.0",
       "when": "blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/pull-request-checks.yml and blueprint.json are inspected",
       "then": "the illustrative pull-request-checks.yml declares an e2e job; the block above it names the four points and the delete-me note for non-browser projects; blueprint.json's check catalogue carries checkSet.e2e",
       "testable": true,
-      "scope": "library"
+      "scope": "library",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-6124-2",
+      "description": "A project with `checkSet.e2e: true` but no application-spa (or other browserSurface-declaring) blueprint applied fails materialise with E2E_CHECK_UNBACKED naming the missing browserSurface. Prevents shipping an e2e job without an application under test. Template on the elicited checkSet. Template values the applying agent sets: The applying agent sets the elicited workflowShape.checkSet (specifically the e2e flag) and the applied blueprint set; the AC substitutes them for the illustrative checkSet.e2e=true paired with no browserSurface-declaring blueprint.",
+      "given": "a workflowShape with checkSet.e2e=true and no applied blueprint declaring a browserSurface",
+      "when": "the materialiser runs",
+      "then": "the materialiser exits with E2E_CHECK_UNBACKED naming the missing browserSurface; no e2e job is written into the pull-request-checks workflow",
+      "testable": true,
+      "scope": "library",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+        "field": "interfaces.materialise"
+      }
     }
   ],
   "tacIds": [
@@ -24,5 +39,6 @@
     "TAC-702-delivery-ci-workflows-gate-report"
   ],
   "createdAt": "2026-09-03T17:00:00Z",
-  "updatedAt": "2026-09-03T18:30:50Z"
+  "updatedAt": "2026-09-09T00:00:00Z",
+  "description": "Section 7a floor: two ACs. Per spec amendment A2 (2026-09-03) this story is documentation-only at v2.3.0; the runtime iff wiring lands in a follow-up train. Guide and TAC-701 name no e2e-specific runtime failure paths beyond the E2E_CHECK_UNBACKED refusal bound by AC-6124-2; runner-missing and gate-aggregation gaps route generically through AC-6102-3 and AC-6108-1 when the runtime wiring lands."
 }

package/blueprints/delivery-ci-workflows/docs/topics.md

@@ -28,7 +28,7 @@ Rules for new topics (inherited from the application-spa, application-api-rest,
 
 ## Id number bands (registry bootstrap)
 
-AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (v1.1 candidate).
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is policy; this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (v1.1 candidate).
 
 This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
 
@@ -73,8 +73,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
 | edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
-US 6101-6110 sit at the LOW end of the 6101-6899 band on purpose. A project-side story that mechanically derives from `delivery-ci-workflows-REQ-011` into the number `6111` would collide against delivery-ci-workflows-US-6111 in this package; the band leaves headroom at the HIGH end (US 6181-6899) so a project's own stories anchored to delivery-ci-workflows REQs can allocate without conflict. The watchpost run4 lesson applies here too.
-
+US 6101-6110 sit at the LOW end of the 6101-6899 band on purpose. A project-side story that mechanically derives from `delivery-ci-workflows-REQ-011` into the number `6111` would collide against delivery-ci-workflows-US-6111 in this package; the band leaves headroom at the HIGH end (US 6181-6899) so a project's own stories anchored to delivery-ci-workflows REQs can allocate without conflict.
 ## Shared expectations for future composing blueprints
 
 - Reuse `ciGates` exactly as spelled here when your blueprint holds an opinion on the required check set every commit-triggered workflow runs; contribute your own scope:global ADR on that string and let composition surface the pairing. An observability-essentials blueprint that ships health-probe or status-page gates as required will conflict here by design.