rcf-lite 0.26.0 → 0.27.0

package/blueprints/application-spa/contributions/user-stories/application-spa-us-1132.json

@@ -2,7 +2,7 @@
   "usId": "application-spa-US-1132",
   "prdId": "PRD-001",
   "reqId": "application-spa-REQ-018",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "approved",
   "title": "External-service-dependency provisioning adherence probe refuses ship on placeholder credentials or unratified deferrals",
   "asA": "operator responsible for the deployed application's dependence on external services",
@@ -11,12 +11,17 @@
   "acceptanceCriteria": [
     {
       "id": "AC-1132-1",
-      "description": "Every external-service dependency the application declares (email transports, payment providers, third-party API adapters, transactional-mail senders, SMS gateways, storage providers, and any other network dependency the runtime reaches for at request-time) is enumerated in a stable, discoverable manifest at ship-time. The manifest names, per dependency, the dependency id, the purpose, the credential field name, the intended provider, and a status of either 'verified' or 'deferred'. A dependency the app calls at runtime but does NOT declare in the manifest is a hard refusal.",
+      "description": "Every external-service dependency the application declares (email transports, payment providers, third-party API adapters, transactional-mail senders, SMS gateways, storage providers, and any other network dependency the runtime reaches for at request-time) is enumerated in a stable, discoverable manifest at ship-time. The manifest names, per dependency, the dependency id, the purpose, the credential field name, the intended provider, and a status of either 'verified' or 'deferred'. A dependency the app calls at runtime but does NOT declare in the manifest is a hard refusal. Applying agent sets: the enumerated external-service dependency set the applying project ships.",
       "given": "the application boot topology at ship",
       "when": "the external-service-dependency manifest is inspected",
       "then": "the manifest exists at the stable path the probe reads, enumerates every runtime-reached external service, and names a status per dependency; any runtime-reached external service missing from the manifest refuses ship",
       "testable": true,
-      "scope": "deployed"
+      "scope": "deployed",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-210-application-spa-external-dependency-provisioning-probe",
+        "field": "interfaces[3].name"
+      }
     },
     {
       "id": "AC-1132-2",
@@ -25,7 +30,12 @@
       "when": "the placeholder-shape detector is applied to each value",
       "then": "no manifest-named credential field carries a placeholder-shape value; a positive match refuses ship",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-210-application-spa-external-dependency-provisioning-probe",
+        "field": "interfaces[3].name"
+      }
     },
     {
       "id": "AC-1132-3",
@@ -34,16 +44,26 @@
       "when": "the probe replays the manifest-declared handshake against the shipped runtime",
       "then": "the provider returns a live acknowledgement whose id or timestamp is captured on the probe report; the run refuses ship on any absent or synthesised evidence",
       "testable": true,
-      "scope": "deployed"
+      "scope": "deployed",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-210-application-spa-external-dependency-provisioning-probe",
+        "field": "interfaces[3].name"
+      }
     },
     {
       "id": "AC-1132-4",
-      "description": "A dependency at status 'deferred' requires an operator-ratified deferral record persisted at a stable project-owned path. The record names the dependency id, the reason for deferral, the acknowledging operator identifier, the ISO-8601 acknowledgement timestamp, and the intended resolution route. A README note, a status.md 'quirk' or 'known-issue' line, a code comment, a commit message, or a work-item link on its own does NOT satisfy the deferral requirement. Absence of a ratified record for a 'deferred' dependency refuses ship.",
+      "description": "A dependency at status 'deferred' requires an operator-ratified deferral record persisted at a stable project-owned path. The record names the dependency id, the reason for deferral, the acknowledging operator identifier, the ISO-8601 acknowledgement timestamp, and the intended resolution route. A README note, a status.md 'quirk' or 'known-issue' line, a code comment, a commit message, or a work-item link on its own does NOT satisfy the deferral requirement. Absence of a ratified record for a 'deferred' dependency refuses ship. Applying agent sets: the deferral-record path, the acknowledging operator identifier, the acknowledgement timestamp and the intended re-verification deadline.",
       "given": "a dependency declared with status 'deferred' on the external-service-dependency manifest",
       "when": "the probe checks for the deferral record at the manifest-named path",
       "then": "the record exists at the stable path, carries the required fields, and is not stale beyond the ratified window; the run refuses ship on any missing, malformed, or expired record",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-210-application-spa-external-dependency-provisioning-probe",
+        "field": "interfaces[3].name"
+      }
     },
     {
       "id": "AC-1132-5",
@@ -52,7 +72,12 @@
       "when": "the report file is inspected on disk",
       "then": "the JSON at 'reports/external-dependency-provisioning.json' matches the shape declared by TAC-210 and its aggregate 'verdict' field agrees with the process exit code (0 for 'ok', non-zero for 'deployed-with-defects')",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-210-application-spa-external-dependency-provisioning-probe",
+        "field": "interfaces[3].name"
+      },
+      "disposition": "fixed"
     },
     {
       "id": "AC-1132-6",
@@ -61,12 +86,17 @@
       "when": "the probe reports 'deployed-with-defects' on any run",
       "then": "the aggregate report records the gate as failed and the runner exits non-zero",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-210-application-spa-external-dependency-provisioning-probe",
+        "field": "interfaces[3].name"
+      }
     }
   ],
   "tacIds": [
     "TAC-210-application-spa-external-dependency-provisioning-probe"
   ],
   "createdAt": "2026-08-24T13:00:00Z",
-  "updatedAt": "2026-08-24T13:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/application-spa/contributions/user-stories/application-spa-us-1133.json

@@ -2,7 +2,7 @@
   "usId": "application-spa-US-1133",
   "prdId": "PRD-001",
   "reqId": "application-spa-REQ-008",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "approved",
   "title": "Core-flow end-to-end adherence probe refuses ship without captured evidence every core flow completes against the shipped runtime",
   "asA": "operator relying on the journey-completeness discipline the application-spa blueprint declares",
@@ -11,12 +11,17 @@
   "acceptanceCriteria": [
     {
       "id": "AC-1133-1",
-      "description": "The application enumerates its core user flows in a stable, discoverable manifest at ship-time. Each enumerated flow names a flow id, an entry-point route, an ordered sequence of user-driven steps that reach a terminal success state, and a terminal success assertion (a DOM signal, a URL, or an authenticated-session signal). When the application declares any authentication surface (application-spa-REQ-009), authentication is ALWAYS enumerated as a core flow; the probe refuses ship when the manifest omits an authentication flow while application-spa-REQ-009 surfaces are present.",
+      "description": "The application enumerates its core user flows in a stable, discoverable manifest at ship-time. Each enumerated flow names a flow id, an entry route, an ordered sequence of user-driven steps that reach a terminal success state, and a terminal success assertion (a DOM signal, a URL, or an authenticated-session signal). When the application declares any authentication surface (application-spa-REQ-009), authentication is ALWAYS enumerated as a core flow; the probe refuses ship when the manifest omits an authentication flow while application-spa-REQ-009 surfaces are present. Applying agent sets: the flow id, entry route, step sequence and terminal success assertion per enumerated core flow.",
       "given": "the application boot topology at ship",
       "when": "the core-flow manifest is inspected",
       "then": "the manifest exists at the stable path the probe reads, enumerates every declared core flow with the required fields, and includes an authentication flow whenever the application has a application-spa-REQ-009 authentication surface",
       "testable": true,
-      "scope": "deployed"
+      "scope": "deployed",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-211-application-spa-core-flow-e2e-probe",
+        "field": "interfaces[3].name"
+      }
     },
     {
       "id": "AC-1133-2",
@@ -25,7 +30,12 @@
       "when": "every enumerated core flow is executed by a real browser against the shipped construction",
       "then": "every flow runs through the production entry-point path with real providers; any flow executed against a mocked provider or a bypassed header path refuses ship",
       "testable": true,
-      "scope": "deployed"
+      "scope": "deployed",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-207-application-spa-token-adherence-probe",
+        "field": "interfaces[1].name"
+      }
     },
     {
       "id": "AC-1133-3",
@@ -34,7 +44,8 @@
       "when": "the probe assembles its report",
       "then": "the flow is recorded as 'fail' (or 'skip') and the probe refuses ship; no workaround note, README caveat, or documented quirk overrides the refusal",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-1133-4",
@@ -43,7 +54,12 @@
       "when": "the probe run terminates",
       "then": "the probe report carries a structured refusal entry naming the flow, the divergence step, and the failing assertion; stdout names the flow id and the report path; the process exit is non-zero",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-207-application-spa-token-adherence-probe",
+        "field": "interfaces[1].name"
+      }
     },
     {
       "id": "AC-1133-5",
@@ -52,7 +68,12 @@
       "when": "the report file is inspected on disk",
       "then": "the JSON at 'reports/core-flow-e2e-adherence.json' matches the shape declared by TAC-211 and its aggregate 'verdict' agrees with the process exit code (0 for 'ok', non-zero for 'deployed-with-defects')",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "ownerRef": {
+        "tacId": "TAC-211-application-spa-core-flow-e2e-probe",
+        "field": "interfaces[3].name"
+      },
+      "disposition": "fixed"
     },
     {
       "id": "AC-1133-6",
@@ -61,12 +82,17 @@
       "when": "the probe reports 'deployed-with-defects' on any run",
       "then": "the aggregate report records the gate as failed and the runner exits non-zero",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-211-application-spa-core-flow-e2e-probe",
+        "field": "interfaces[3].name"
+      }
     }
   ],
   "tacIds": [
     "TAC-211-application-spa-core-flow-e2e-probe"
   ],
   "createdAt": "2026-08-24T13:00:00Z",
-  "updatedAt": "2026-08-24T13:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

package/blueprints/application-spa/contributions/user-stories/application-spa-us-1134.json

@@ -2,7 +2,7 @@
   "usId": "application-spa-US-1134",
   "prdId": "PRD-001",
   "reqId": "application-spa-REQ-011",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "status": "approved",
   "title": "Primary-nav icon renders at the expected size across declared themes on the home route in a browser (e2e)",
   "asA": "operator relying on the iconography discipline the application-spa blueprint declares",
@@ -16,9 +16,29 @@
       "when": "a real browser loads / in each theme declared on the blueprint's browserSurface and getBoundingClientRect() is read for the primary-nav icon",
       "then": "the icon's rendered box equals the iconAlias size token for the primary-nav slot in every theme; a mismatch, a zero-size box, or a missing icon refuses ship with a per-theme diagnostic",
       "testable": true,
-      "scope": "deployed"
+      "scope": "deployed",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-207-application-spa-token-adherence-probe",
+        "field": "interfaces[1].name"
+      }
+    },
+    {
+      "id": "AC-1134-2",
+      "description": "A shipped component that references the primary-navigation icon by an alias absent from the alias registry named on TAC-208-application-spa-icon-adherence-probe.responsibilities[1], or that inlines an SVG for that slot outside the registry, refuses ship through the icon adherence probe with a non-zero exit code and a per-file, per-line diagnostic on the probe report. A component scan that carries no such violation exits with code zero and the probe report verdict records the ok signal named on TAC-208-application-spa-icon-adherence-probe.interfaces.runIconAdherenceProbe. Applying agent sets: the project alias registry path, the component glob, and the report directory the probe reads and writes.",
+      "given": "the icon adherence probe wired as a delivery-ci-workflows gate with the project alias registry, the component glob, and the report directory configured",
+      "when": "the probe scans the shipped component source once for an inline SVG violation on the primary-navigation slot and once for a reference resolving to a name absent from the alias registry",
+      "then": "the probe exits non-zero on either violation with the offending file path, line number and offending name on the probe report; a clean scan exits zero and the report verdict records the ok signal",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-208-application-spa-icon-adherence-probe",
+        "field": "interfaces.runIconAdherenceProbe"
+      }
     }
   ],
   "createdAt": "2026-09-03T17:00:00Z",
-  "updatedAt": "2026-09-03T17:00:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z",
+  "description": "A boundary-path AC covering the icon-adherence probe refusal on inline-SVG or unknown-alias violations against the primary-navigation icon slot; the browser render AC binds the success signal, the probe AC binds the shipped mechanism failure path."
 }

package/blueprints/application-spa/contributions/user-stories/application-spa-us-1135.json

@@ -2,7 +2,7 @@
   "usId": "application-spa-US-1135",
   "prdId": "PRD-001",
   "reqId": "application-spa-REQ-009",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "status": "approved",
   "title": "Unauthenticated visit to a protected route lands on the sign-in page in a browser (e2e)",
   "asA": "operator relying on the auth-surface discipline the application-spa blueprint declares",
@@ -16,9 +16,25 @@
       "when": "a real browser with no session state navigates to the protected route",
       "then": "the browser's final URL path equals the sign-in route path; any other landing (protected route rendered without auth, arbitrary other page, error page) refuses ship with a diagnostic naming requested, landed and expected paths",
       "testable": true,
-      "scope": "deployed"
+      "scope": "deployed",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-1135-2",
+      "description": "A signed-in browser opening a protected deep-link with a live session lands on the requested protected route, not on the sign-in route. A signed-in browser opening a sign-out surface and then reopening the same protected deep-link lands on the sign-in route with the originally requested route preserved on the return-to state owned on TAC-201-application-spa-app-shell.responsibilities[5], and after a fresh sign-in the browser lands on the originally requested protected route. Applying agent sets: the project-declared browserSurface.routes for the protected route, the sign-in route, and the sign-out surface.",
+      "given": "the application booted through its production entry point with a protected route, a sign-in route, and a sign-out surface all registered under browserSurface.routes",
+      "when": "a signed-in browser opens the protected deep-link, then signs out, then reopens the same deep-link, then signs in again",
+      "then": "the first open lands on the protected route; the second open (post sign-out) lands on the sign-in route with the return-to state preserving the originally requested path; the post-authentication landing is the originally requested protected route; any other landing refuses ship with a diagnostic naming the requested, landed, and expected paths",
+      "testable": true,
+      "scope": "deployed",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-201-application-spa-app-shell",
+        "field": "responsibilities[5]"
+      }
     }
   ],
   "createdAt": "2026-09-03T17:00:00Z",
-  "updatedAt": "2026-09-03T17:00:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z",
+  "description": "A boundary-path AC covering the deep-link preservation and post-sign-out return-to flow named on the app-shell; the arrival AC binds the unauthenticated-redirect success signal, this AC binds the signed-in and post-sign-out boundary transitions."
 }

package/blueprints/application-spa/guide/application-spa.md

@@ -4,7 +4,7 @@ This guide is for the human running the project, not the coding agent. It explai
 
 ## What this blueprint is
 
-A specification package for single-page applications with public and authenticated surfaces, session-based auth, one deployable, dark and light by default, fully responsive by default. Applying it (`rcf define blueprint add <path>`) merges 64 namespaced documents into your RCF tree: 21 requirements, 28 user stories carrying 167 acceptance criteria, 6 architectural components, and 9 decision records. It also ships a design system: contrast-validated design tokens for both themes, a realising stylesheet, wireframes for the nine canonical surfaces, per-component behaviour contracts, a viewport table, and sample data.
+A specification package for single-page applications with public and authenticated surfaces, session-based auth, one deployable, dark and light by default, fully responsive by default. Applying it (`rcf define blueprint add <path>`) merges 76 namespaced documents into your RCF tree: 21 requirements, 35 user stories carrying 199 acceptance criteria, 11 architectural components, and 9 decision records. It also ships a design system: contrast-validated design tokens for both themes, a realising stylesheet, wireframes for the nine canonical surfaces, per-component behaviour contracts, a viewport table, and sample data.
 
 The point, in one sentence: the visual and UX floor of your build becomes part of the specification, so the same build cycle that verifies your features also verifies that the product looks and behaves like someone cared.
 
@@ -37,4 +37,4 @@ Walk any journey in the finished product and try to catch it looking abandoned:
 
 ## Cost honesty
 
-This doc set makes builds slower to declare done, on purpose: 167 criteria is the price of "no route ships half-dressed". If the project is a one-day throwaway, that price is wrong for you; skip the blueprint rather than opting out of half of it. If the project has users, the price is the product.
+This doc set makes builds slower to declare done, on purpose: 199 criteria is the price of "no route ships half-dressed". If the project is a one-day throwaway, that price is wrong for you; skip the blueprint rather than opting out of half of it. If the project has users, the price is the product.

package/blueprints/delivery-ci-workflows/CHANGELOG.md

@@ -1,7 +1,25 @@
 # Changelog: delivery-ci-workflows blueprint
 
+## 2.3.1 (register-sweep patch, 2026-09-10)
+
+- Register: neutral wording in shipped prose (no capability change).
+
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); the blueprint version is semver per the authoring standard section 8.
 
+
+## 2.3.0 (hardening pass, 2026-09-09)
+
+- Adds `elicits[]` with seven apply-time answers: `branch-model` (enum feature/trunk, default feature; ADR-706), `check-set` (string JSON of booleans; REQs 016-020), `release-mode` (enum none/tagOnly/tagPlusArtefact/deployHandoff, default none; ADR-707), `scheduled-audit` (enum off/on, default off; ADR-710), `provider-hint` (enum githubActions, default githubActions; ADR-708), `report-dir` (string, default .rcf/reports; ADR-704), `deploy-handoff-target` (string, blank when not deployHandoff; REQ-022).
+- Adds `deliveredBy` to all 23 REQs pointing at TAC-701/702/703/704/705/706 responsibility-carrying interfaces. Closes 14 pass-2 lint findings.
+- Closes the pass-1 lint finding on AC-6109-2: adds ownerRef pointing at TAC-701-delivery-ci-workflows-gate-runner.interfaces[2].name (the entry-point CLI it restates).
+- Closes F-1 (interrupted report writes could leave stale success): adds AC-6105-3 and AC-6108-3 asserting an interrupted per-gate and aggregate rewrite never leaves a stale-success from a previous run; the pipeline refuses pass on absent aggregate per REQ-008.
+- Closes F-2 (release entity creation and artefact publication had only success cases): adds AC-6121-4 (RELEASE_CREATE_FAILED naming step + provider status; no downstream publication or promote) and AC-6122-4 (RELEASE_PUBLISH_FAILED naming artefact + provider response; no promote step).
+- Closes F-3 (missing/malformed workflow config): adds AC-6112-3 (absent .rcf/config/delivery-ci-workflows.json -> WORKFLOW_CONFIG_MISSING; no workflow file written) and AC-6112-4 (unparseable JSON -> WORKFLOW_CONFIG_UNPARSEABLE naming file + parser error).
+- Re-sweeps every existing AC's `disposition` per section 7b: ACs referencing workflowShape values, provider hint, elicited check catalogue, report directory, and deployHandoff target flipped to `template` with `templateFillIns`; the remaining ACs stay `fixed`.
+- Review fix pass (F-1): flips AC-6104-3, AC-6106-3, AC-6119-2 to `disposition: fixed` (three ACs describe blueprint-invariant semantics with no elicited substitution in the assertion); adds the section 7b fill-in sentence naming the elicited values the applying agent sets to the remaining eight template ACs (AC-6111-3, AC-6113-3, AC-6115-3, AC-6116-2, AC-6118-3, AC-6120-2, AC-6123-3, AC-6124-2).
+- Review fix pass (F-6): extends REQ-011 description with a runtime clause naming the literal `providerHint: githubActions` value (the one shipped-asset provider hint in v2 per ADR-708); AC-6113-1 already binds the four-field expansion including `providerHint: githubActions`.
+- Review fix pass (F-8): adds section 7a coverage-note descriptions to US-6109, US-6116, US-6117, US-6119, US-6120, US-6124 recording the guide-and-TAC trace outcome per story (none had mechanism-specific failure paths named in the guide or TAC beyond the ACs each story already binds; runner-missing and gate-aggregation gaps route generically through AC-6102-3 and AC-6108-1).
+
 ## [2.0.0] - 2026-08-31
 
 Rename from `ci-pipeline` and redesign into a workflow SET the operator declares via a `workflowShape` block; introduces the elicited-check tier (linter, formatter, typecheck, unitTest, securityScan) alongside the preserved v1 RCF-gate mandatory tier; introduces the release workflow scaled across four modes; introduces the optional scheduled-audit workflow; mints one new global topic (`releaseArtefacts`). Ratified 2026-08-31 (Q1 one-blueprint-the-set; Q6-B releaseMode-optional; all other section-12 questions accepted as recommended).

package/blueprints/delivery-ci-workflows/README.md

@@ -1,4 +1,4 @@
-# Delivery-ci-workflows blueprint (v2.0.0)
+# Delivery-ci-workflows blueprint (v2.3.0)
 
 The `delivery-ci-workflows` blueprint (renamed from `ci-pipeline` at v2.0.0) contributes the full workflow set an rcf-lite project runs on its CI provider: two commit-triggered workflows (pull-request-checks and default-branch-checks), an optional release workflow scaled across four modes, and an optional scheduled-audit workflow. The workflow set is a function of an operator-declared `workflowShape` covering four elicited dimensions plus one optional fifth: branch model (feature or trunk), check set (mandatory tier plus five elicited checks), release mode (none, tagOnly, tagPlusArtefact, or deployHandoff), provider hint (which CI provider's illustrative assets to seed from), and an optional scheduledAudit flag. The v1 RCF-gate suite is preserved verbatim as the mandatory tier inside a broader two-tier check catalogue.
 

package/blueprints/delivery-ci-workflows/blueprint.json

@@ -1,7 +1,68 @@
 {
   "slug": "delivery-ci-workflows",
-  "version": "2.2.0",
+  "version": "2.3.1",
   "category": "delivery",
+  "elicits": [
+    {
+      "id": "branch-model",
+      "prompt": "Branch model of the project (per ADR-706). feature: pull-request-checks + default-branch-checks. trunk: trunk-first with an optional pull-request-checks sub-shape.",
+      "kind": "enum",
+      "options": [
+        "feature",
+        "trunk"
+      ],
+      "default": "feature"
+    },
+    {
+      "id": "check-set",
+      "prompt": "Enabled elicited check kinds (per REQs 016-020, ADR-701). JSON object of booleans keyed by check kind: linter, formatter, typecheck, unitTest, securityScan.",
+      "kind": "string",
+      "default": "{\"linter\":true,\"formatter\":true,\"typecheck\":true,\"unitTest\":true,\"securityScan\":true}"
+    },
+    {
+      "id": "release-mode",
+      "prompt": "Release workflow mode (per ADR-707). none: no release workflow. tagOnly: tag write only. tagPlusArtefact: tag write plus artefact publication. deployHandoff: invokes the named deploy blueprint's promote workflow.",
+      "kind": "enum",
+      "options": [
+        "none",
+        "tagOnly",
+        "tagPlusArtefact",
+        "deployHandoff"
+      ],
+      "default": "none"
+    },
+    {
+      "id": "scheduled-audit",
+      "prompt": "Scheduled-audit workflow enabled per ADR-710 (cron-triggered required check set on cadence).",
+      "kind": "enum",
+      "options": [
+        "off",
+        "on"
+      ],
+      "default": "off"
+    },
+    {
+      "id": "provider-hint",
+      "prompt": "Provider whose illustrative asset set the blueprint ships per ADR-708 (v2.0.0 ships GHA only; alternate providers wire the same Node entry points).",
+      "kind": "enum",
+      "options": [
+        "githubActions"
+      ],
+      "default": "githubActions"
+    },
+    {
+      "id": "report-dir",
+      "prompt": "Report directory the gate runner writes per-gate and aggregate reports into (per ADR-704). Relative or absolute path; recommended default .rcf/reports.",
+      "kind": "string",
+      "default": ".rcf/reports"
+    },
+    {
+      "id": "deploy-handoff-target",
+      "prompt": "Slug of the deploy blueprint the deployHandoff release-mode invokes (per REQ-022). Required when release-mode is deployHandoff; refused at boot otherwise.",
+      "kind": "string",
+      "default": ""
+    }
+  ],
   "contributions": [
     {
       "id": "delivery-ci-workflows-REQ-001",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The materialised commit-triggered workflows run the required check set on every trigger event the branch model defines",
   "description": "The commit-triggered workflows the materialiser produces (per REQ-014 for feature-branch and REQ-015 for trunk-based) run the required check set on every trigger event the elicited branch model defines: for feature-branch, pushes to the default branch and pull requests targeting the default branch; for trunk-based, pushes to the trunk branch (and, in the sub-shape where `trunkPullRequests: sometimes`, pull requests targeting the trunk branch). The workflows' aggregate exit status is the merge criterion: the branch protection or equivalent policy refuses to admit a change whose most recent aggregate run did not exit zero, per the merge-policy AC binding for the branch model in play (AC-6114-3, AC-6115-1, AC-6115-2). No manual override path bypasses the required check set; a hotfix that skips it requires a documented ADR trail.",
+  "deliveredBy": {
+    "tacId": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+    "field": "interfaces.materialise"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The gate suite is invoked as one Node entry point that is CI-provider-neutral",
   "description": "The project realises a single Node entry point script that runs every RCF gate in order. The entry point is a plain Node process invoked by whatever runner the project's CI provider ships (GitHub Actions job step, GitLab job script, CircleCI step, Buildkite command, Jenkins stage). The CI-provider job definition contains one invocation line and the standard Node and package-manager setup steps; every gate-specific piece of logic lives in the Node entry point.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "technical",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The suite runs the schema-and-reference validation gate and refuses on non-zero exit",
   "description": "The Node entry point invokes `rcf define validate` as a required gate. The gate runs with the project's tree at the pull request's head commit. A non-zero exit code from `rcf define validate` terminates the suite and marks the aggregate result as failed. The failing invocation's stdout and stderr are captured to the gate report file so the reviewer can read the specific schema or reference issue without re-running the gate.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

@@ -3,6 +3,10 @@
   "prdId": "PRD-001",
   "title": "The suite runs the per-AC strict coverage gate and refuses on non-zero exit",
   "description": "The Node entry point invokes `rcf audit coverage --strict` as a required gate. The gate runs against the tree at the pull request's head commit and reports per-AC coverage: every AC on every US must resolve to a TC whose testPointer points at a real test. A non-zero exit code (mechanism exit 4 on gaps) terminates the suite and marks the aggregate result as failed. The strict-flag invocation is the sole coverage mode the suite runs; shallow-any is not accepted as a substitute.",
+  "deliveredBy": {
+    "tacId": "TAC-701-delivery-ci-workflows-gate-runner",
+    "field": "interfaces.runGates"
+  },
   "category": "functional",
   "domain": "continuous-integration",
   "priority": "must",

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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