rcf-lite 0.26.0 → 0.28.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/docs/topics.md

@@ -79,4 +79,4 @@ Suffix-family ids (ADR, TAC) are string-distinct once slug-suffixed. SPA numbers
 
 ## v1.0.0 US-1101 collision note (preserved)
 
-In run4 of the watchpost case study, a project-side `US-1101` derived mechanically from `REQ-011` (leading `11` + sequence `01`) collided with the application-spa blueprint's `application-spa-us-1101` at the AC-id-scoping bucket. The seat allocated the project story as `US-1181` and moved on. Lesson: keep contributions on the LOW end of the band and leave headroom at the HIGH end for project-side stories that mechanically derive to your numbers. v1.1 preserves this lesson: US-1129 and US-1130 remain at the low end.
+A project-side `US-1101` derived mechanically from `REQ-011` (leading `11` + sequence `01`) collides with the application-spa blueprint's `application-spa-us-1101` at the AC-id-scoping bucket; the project story is allocated as `US-1181` instead. Rule: keep contributions on the LOW end of the band and leave headroom at the HIGH end for project-side stories that mechanically derive to your numbers. v1.1 preserves this rule: US-1129 and US-1130 remain at the low end.

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,10 +1,48 @@
+# Changelog
+
+## 2.3.5 - 2026-09-11
+
+probe-utils.writeReport no longer promotes an all-accountBoundSkipped row set to PASS via a separate override; aggregate() already returns PASS for a pure-skip set on its own and returns WARN when any WARN row is present, so an all-skipped array carrying a WARN row is no longer silently promoted. Anatomy suite tracks the strengthened shared helper.
+
+## 2.3.4 - 2026-09-11
+
+shared anatomy helper tightened; delivery-ci-workflows anatomy test passes shippedAcIds and browserOnlyAcIds into the helper and additionally checks every accountBoundSkipped row names exactly one declared env variable.
+
 # Changelog: delivery-ci-workflows blueprint
 
+## 2.3.3 - 2026-09-11
+
+Adds a contributions/probes/ pack (workflow-template-shape, node-gate-entrypoint, real-account-github-actions-run-record) with a fixture-side workflow-lint helper under packages/rcf-lite/test/fixtures/probe-pack-delivery-ci-workflows/. Probes run against the shipped workflow templates on Node 24 and against real GitHub Actions on the account-bound branch (CI_HAS_GITHUB_ACTIONS gate + RCF_FIXTURE_CIW_REPO, one variable per skip row).
+
+Anchoring: every row is de-claimed (conformanceOnly, anchorAcId=null) with a limitation naming a shipped AC id:
+- workflow-template-shape: template shape row -> AC-6101-1 (materialiser wiring not observed); actionlint row -> AC-6101-3 (materialiser refusal not observed; honest accountBoundSkipped naming RCF_FIXTURE_CIW_ACTIONLINT_PATH when the binary is not runnable); branch-protection row -> AC-6101-2 (repository merge-policy not observable at shelf without a probe-controlled repository).
+- node-gate-entrypoint: single-line invocation row -> AC-6102-2 (absence of gate-specific logic elsewhere in the job not observed); entry-point unique row -> AC-6102-1 (runtime aggregate report and project tree unavailable).
+- real-account-github-actions-run-record: every row -> AC-6101-1 (a gh run list record is not evidence of the configured trigger set nor of the aggregate pipeline report's `trigger` field); accountBoundSkipped rows name exactly one declared variable; a gh auth failure with the gate set is a FAIL.
+probe-utils aggregate follows the standard fail>warn>pass rule with no warn-to-pass promotion; every warn-shaped row was converted to a conformanceOnly or accountBoundSkipped row so aggregate=pass carries only pass rows. probe-utils fallback anchor is null.
+
+## 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 (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.
+- Adds the missing coverage on AC-6109-2: adds ownerRef pointing at TAC-701-delivery-ci-workflows-gate-runner.interfaces[2].name (the entry-point CLI it restates).
+- The interrupted report writes could leave stale success gap is fixed: 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.
+- The release entity creation and artefact publication had only success cases gap is fixed: 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).
+- The missing/malformed workflow config gap is fixed: 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`.
+- 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).
+- 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`.
+- 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).
+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`). Shipped shape: the blueprint owns the whole set (one-blueprint-the-set), `releaseMode` is optional, and other choices default per the shipped recommendations.
 
 ### Changed (BREAKING)
 
@@ -16,7 +54,7 @@ Rename from `ci-pipeline` and redesign into a workflow SET the operator declares
 ### Added
 
 - Six new REQs covering the elicitation surface (REQ-011, REQ-012, REQ-013), branch model (REQ-014, REQ-015), the elicited check catalogue (REQ-016..020), the release workflow (REQ-021), the deploy handoff (REQ-022), and the scheduled-audit dimension (REQ-023). Total REQ count: 23 (up from 10 at v1).
-- Corresponding new user stories US-6111..US-6123 (23 total) with additive ACs; the aggregate AC count sits inside the ratified 6101-6899 band.
+- Corresponding new user stories US-6111..US-6123 (23 total) with additive ACs; the aggregate AC count sits inside the shipped 6101-6899 band.
 - Three new TACs: TAC-704 (workflow-materialiser), TAC-705 (release-workflow orchestrator), TAC-706 (scheduled-audit runner). The v1 three TACs (gate-runner, per-gate report, aggregate report) are preserved verbatim except for the report-writer picking up the v2 `checkKind` field.
 - Six new ADRs: ADR-705 (elicitation-surface location), ADR-706 (branch-model defaults), ADR-707 (release-workflow shape), ADR-708 (provider-hint shape), ADR-709 (`releaseArtefacts` global), ADR-710 (scheduled-audit dimension). The v1 four ADRs are preserved with content updated for v2 broadened scope.
 - Per-gate report shape gains a `checkKind` field naming the elicited-check kind (`validate`, `coverage-strict`, `linter`, `formatter`, `typecheck`, `unitTest`, `securityScan`, `custom:<name>`). The v1 fixed key set is preserved as a strict subset.

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.
 
@@ -20,7 +20,7 @@ Projects on the v1 `ci-pipeline` slug follow the migration path in the CHANGELOG
 | Doc set | `contributions/` | 23 REQs, 23 USs, 6 TACs, 10 ADRs, all schema-valid and namespaced (`delivery-ci-workflows-REQ-NNN` prefix family; `ADR-70N-delivery-ci-workflows-<tail>` suffix family) |
 | GitHub Actions assets | `assets/ci-provider-examples/github-actions/` | One illustrative workflow file per workflow the matrix materialises (`pull-request-checks.yml`, `default-branch-checks.yml`, `release.yml`, `scheduled-audit.yml`) |
 | Alternate-provider notes | `assets/ci-provider-examples/notes.md` | The four-point mapping (job trigger, Node setup, single-line entry-point invocation, artefact upload) applied per workflow for GitLab CI, CircleCI, Buildkite, and Jenkins |
-| Report-shape samples | `assets/report-samples/per-gate.json`, `assets/report-samples/pipeline.json` | Worked examples of a per-gate report (with the v2 `checkKind` field) and an aggregate report at the ratified schemas |
+| Report-shape samples | `assets/report-samples/per-gate.json`, `assets/report-samples/pipeline.json` | Worked examples of a per-gate report (with the v2 `checkKind` field) and an aggregate report at the shipped schemas |
 | Guide | `guide/delivery-ci-workflows.md` | Operator-facing: workflow-shape declaration, elicited-check catalogue, the four release modes, the deploy handoff contract, the scheduled-audit cadence |
 | Coordination vocabulary | `docs/topics.md` | The three global-topic strings this blueprint contributes and the shared id band registry |
 
@@ -28,9 +28,9 @@ The doc set is contributions (copied into the project tree by `rcf define bluepr
 
 ## What it contributes, and what it deliberately does not
 
-Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (ratified decision preserved from v1) and no code.
+Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (shipped policy preserved from v1) and no code.
 
-No FBS contributions, as a matter of principle (ratified policy 2026-08-19): FBSs are the work of the implementing agent, not the blueprint. The blueprint contributes the WHAT (the workflow-materialiser contract, the gate-runner contract, the release-workflow contract, the scheduled-audit contract, the check-catalogue AC contracts, the report shapes); the implementing agent derives the HOW-tasks in the host project against those contracts.
+No FBS contributions, as a matter of principle (policy): FBSs are the work of the implementing agent, not the blueprint. The blueprint contributes the WHAT (the workflow-materialiser contract, the gate-runner contract, the release-workflow contract, the scheduled-audit contract, the check-catalogue AC contracts, the report shapes); the implementing agent derives the HOW-tasks in the host project against those contracts.
 
 Deliberately not contributed: a matrix of provider-specific configuration files (v2.0.0 ships GHA only; alternate providers wire the same entry points per the guide's four-point mapping applied per workflow); provider-specific pipeline plugins or actions; the linter, formatter, typechecker, unit-test runner, or security scanner (the elicited checks name the kind; the project picks the tool); a code-formatting style guide or a security-scan severity threshold (project decisions); a release-mechanism (no `standard-version` invocation, no `release-please` config, no `changesets` schema; the workflow reacts to a tag or dispatch, does not create it); a merge-queue integration; a coverage-trend dashboard.
 

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

@@ -1,7 +1,68 @@
 {
   "slug": "delivery-ci-workflows",
-  "version": "2.2.0",
+  "version": "2.3.5",
   "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",
@@ -324,5 +385,6 @@
       "kind": "adr",
       "path": "adrs/adr-710-delivery-ci-workflows-scheduled-audit.json"
     }
-  ]
+  ],
+  "updatedAt": "2026-09-11"
 }

package/blueprints/delivery-ci-workflows/contributions/adrs/adr-702-delivery-ci-workflows-strict-coverage-gate.json

@@ -5,14 +5,14 @@
   "version": "1.0.0",
   "status": "accepted",
   "title": "Coverage runs as per-AC strict; shallow-any is not accepted as a substitute in the required gate set",
-  "context": "The `rcf audit coverage` CLI runs in two modes: the default `shallow-any` (a REQ counts as covered when any AC on any US has any resolving TC) and the opt-in `--strict` (per-AC: every AC on every US must have a resolving TC). Shallow-any is useful for author-time exploration; it is the wrong mode for a merge-blocking gate because it hides the failure mode watchpost run4 caught in categories 5, 6, and 11 (an AC bound but no TC resolves it, and the REQ still reads as covered because some other AC's TC resolved). Choosing which coverage mode the pipeline runs is a policy decision distinct from choosing whether coverage runs at all.",
+  "context": "The `rcf audit coverage` CLI runs in two modes: the default `shallow-any` (a REQ counts as covered when any AC on any US has any resolving TC) and the opt-in `--strict` (per-AC: every AC on every US must have a resolving TC). Shallow-any is useful for author-time exploration; it is the wrong mode for a merge-blocking gate because it hides the concrete failure mode where an AC is bound but no TC resolves it and the REQ still reads as covered because some other AC's TC resolved. Choosing which coverage mode the pipeline runs is a policy decision distinct from choosing whether coverage runs at all.",
   "decision": "The required-gate coverage invocation is `rcf audit coverage --strict`. Every AC on every US must resolve to a TC whose testPointer points at a real test; a `covered-unresolved` or uncovered AC fails the gate. Shallow-any is not accepted as a substitute in the required-gate set. A project that needs an author-time shallow-any view for exploration runs `rcf audit coverage` locally without `--strict`; the pipeline's gate is unaffected. Composing blueprints that ship a coverage gate hold this topic (`strictCoverageGate`) and conflict here by design: a hypothetical `delivery-ci-workflows-shallow` blueprint or a project that wants the shallow-any mode as its floor supersedes this ADR with a project-level ADR stating the reasoning.",
   "consequences": "Every AC the RCF chain contributes must have a TC bound in the project's own build cycle before the pipeline turns green. That is the mechanism-reach discipline the strict mode enforces: shipping an AC without a TC is caught here, not in production. Composing blueprints (this one and any coverage-shipping blueprint the ecosystem grows) conflict on `strictCoverageGate` for one project-level ADR to fix. A project that thoughtfully accepts a shallow-any floor (small project, exploration phase, no operator-facing surface yet) authors that ADR and the pipeline follows.\n\nBootstrap consequence (loud): a fresh apply of the delivery-ci-workflows blueprint alongside any doc-heavy companion (an application-* blueprint plus a persistence-* blueprint contributes tens to hundreds of ACs and zero TCs) means the very first commit-triggered workflow the materialiser produces is guaranteed to refuse on this gate until either every AC has a resolving TC OR a project-level ADR demotes the gate. The guide's \"Bootstrap posture\" section names the two ratified paths (author-every-TC-first, or demote-to-advisory-with-exit-criterion) and points at the template ADR at `assets/bootstrap/adr-bootstrap-coverage-supersession.template.json` that expresses the demotion posture. A first-time operator who reaches this ADR through the aggregate-report refusal at their first PR has hit the trap; a first-time operator who reads the guide's bootstrap section before running the materialiser makes the posture choice at apply time.",
   "alternativesConsidered": [
     {
       "name": "Run shallow-any as the required mode with strict as a warning gate",
       "summary": "The pipeline runs `rcf audit coverage` in shallow-any mode as required and `rcf audit coverage --strict` as a soft advisory gate whose outcome does not block merge.",
-      "reasonNotChosen": "A warning gate people learn to ignore is a gate that does not exist. The strict-mode failures watchpost run4 caught were exactly the ones a warning-only gate would have surfaced and been dismissed. Strict as required is the shape that makes the mechanism useful in review."
+      "reasonNotChosen": "A warning-only gate permits the same failures and is ineffective."
     },
     {
       "name": "Run strict only after a grace period per REQ / US",

package/blueprints/delivery-ci-workflows/contributions/probes/node-gate-entrypoint.mjs

@@ -0,0 +1,76 @@
+// Node-gate-entrypoint probe for delivery-ci-workflows.
+//
+// AC-6102-2 requires the CI job's step to be a single-line node
+// invocation of the gate runner AND every gate-level branching,
+// timing, and report-writing responsibility to live inside the Node
+// runner rather than the CI configuration. This probe observes only
+// the single-line invocation half; it cannot cheaply prove absence of
+// branching/timing/report-writing logic elsewhere in the job. The row
+// is de-claimed (conformanceOnly) with the limitation naming AC-6102-2.
+//
+// AC-6102-1 requires the aggregate report's runner.entryPoint field
+// (a runtime property the project's rcf runner writes into
+// .rcf/reports/ci/pipeline.json) and requires the field's project-
+// relative path to exist in the tree. Neither the aggregate report
+// nor a project tree is available to a shelf probe; row de-claimed.
+import { loadTemplates, splitJobs, findJobEntries } from '../../../../packages/rcf-lite/test/fixtures/probe-pack-delivery-ci-workflows/src/workflow-lint.mjs';
+
+export const anchorAcId = 'AC-6102-2';
+export const accountBound = false;
+
+const LIM_6102_2 = `AC-6102-2: requires the CI job step to be a single-line node invocation AND every gate-level branching, timing, and report-writing responsibility to live inside the Node runner rather than the CI configuration. This row observes only the single-line invocation; it does not prove absence of gate-specific logic elsewhere in the job.`;
+const LIM_6102_1 = `AC-6102-1: requires the aggregate report's runner.entryPoint field (a runtime property the project's rcf runner writes into .rcf/reports/ci/pipeline.json) to record a project-relative .js/.mjs path AND that path to exist in the tree. Neither the runtime aggregate report nor a project tree is available to a shelf probe.`;
+
+export default async function runProbe() {
+  const templates = await loadTemplates();
+  const results = [];
+  if (templates.length === 0) {
+    results.push({
+      anchorAcId: null,
+      conformanceOnly: true,
+      limitation: LIM_6102_2,
+      verdict: 'fail',
+      detail: `observed no workflow templates found under the shipped github-actions assets directory; the single-line invocation observation cannot be made without at least one file.`,
+      evidence: { templateCount: 0, entries: [], bodyExcerpt: 'no templates' },
+    });
+    return { results, extra: { envDeclared: [], templateCount: 0 } };
+  }
+
+  const perFile = [];
+  let jobsScanned = 0;
+  let jobsWithExactlyOne = 0;
+  const violations = [];
+  for (const t of templates) {
+    const jobs = splitJobs(t.text);
+    const jobShapes = jobs.map((j) => {
+      const entries = findJobEntries(j.text);
+      const ok = entries.length === 1;
+      jobsScanned += 1;
+      if (ok) jobsWithExactlyOne += 1;
+      if (!ok) violations.push({ file: t.name, job: j.name, entries });
+      return { job: j.name, entries, oneEntryPoint: ok };
+    });
+    perFile.push({ file: t.name, jobCount: jobs.length, jobs: jobShapes });
+  }
+  results.push({
+    anchorAcId: null,
+    conformanceOnly: true,
+    limitation: LIM_6102_2,
+    verdict: jobsScanned > 0 && jobsWithExactlyOne === jobsScanned ? 'pass' : 'fail',
+    detail: `observed ${templates.length} workflow templates scanned; ${jobsScanned} jobs; ${jobsWithExactlyOne} jobs run exactly one 'node scripts/rcf-*.js' invocation; violations=${JSON.stringify(violations)}. Absence of gate-specific branching/timing/report-writing logic elsewhere in the job not observed.`,
+    evidence: { perFile, jobsScanned, jobsWithExactlyOne, violations, entries: perFile.flatMap((f) => f.jobs.flatMap((j) => j.entries)), bodyExcerpt: `jobs=${jobsScanned} oneEntry=${jobsWithExactlyOne}` },
+  });
+
+  const flat = perFile.flatMap((f) => f.jobs.flatMap((j) => j.entries));
+  const uniqueEntries = [...new Set(flat)];
+  results.push({
+    anchorAcId: null,
+    conformanceOnly: true,
+    limitation: LIM_6102_1,
+    verdict: 'pass',
+    detail: `observed ${flat.length} 'node scripts/rcf-*.{js,mjs}' entries across all jobs; uniqueEntries=${JSON.stringify(uniqueEntries)}. Each shipped template names its own canonical entry per workflow; the shelf cannot observe the runtime aggregate report's runner.entryPoint field or its path existence in a downstream tree.`,
+    evidence: { entries: flat, uniqueEntries, bodyExcerpt: `entries=${flat.length} unique=${uniqueEntries.length}` },
+  });
+
+  return { results, extra: { envDeclared: [], templateCount: templates.length, perFile } };
+}