rcf-lite 0.12.0 → 0.14.0

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

@@ -0,0 +1,72 @@
+{
+  "usId": "application-spa-US-1131",
+  "prdId": "PRD-001",
+  "reqId": "application-spa-REQ-018",
+  "version": "1.0.1",
+  "status": "approved",
+  "title": "Styled-under-shipped-CSP adherence probe refuses ship on inline styles or unstyled runtime",
+  "asA": "operator relying on the security baseline the application-spa blueprint declares",
+  "iWant": "a runtime check that fails the build when the application ships with inline style blocks, a CSP relaxed to unsafe-inline, or a runtime surface that renders unstyled under the shipped headers",
+  "soThat": "the application-spa-REQ-018 security floor is enforced at the ship gate and every UI surface reaches production styled without the CSP being weakened",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-1131-1",
+      "description": "The CSP served on every HTML document declares style-src that resolves to 'self' (or a nonce / hash allowlist), and NEVER contains the 'unsafe-inline' or 'unsafe-eval' relaxations. A wildcard style-src is refused; declaring 'unsafe-inline' as a fallback is refused. The CSP style-src is the sole styling-authority signal the runtime respects; a stylesheet the CSP would refuse is a defect, not a warning.",
+      "given": "the deployed application document response",
+      "when": "the Content-Security-Policy header is inspected",
+      "then": "style-src is present, resolves to 'self' or a nonce / hash allowlist, and contains neither 'unsafe-inline' nor 'unsafe-eval' nor a wildcard source",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-1131-2",
+      "description": "No HTML surface shipped by the application carries an inline <style> block. Stylesheets are served from same-origin routes referenced via <link rel=\"stylesheet\">; every occurrence of <style> in a rendered response body is a defect, including <style> injected via templating helpers or partials.",
+      "given": "any rendered HTML response from the application surface",
+      "when": "the response body is scanned for the substring '<style'",
+      "then": "zero occurrences are present; a positive match is a hard refusal",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-1131-3",
+      "description": "Every UI-bearing route renders styled UNDER the shipped strict CSP, AND the probe proves it exercised the requested surface (not a page a redirect would land on). A browser-driven check drives the same server instance that stamps the production security headers, navigates each enumerated UI route, and asserts (a) the browser's final URL path equals the requested route path; a silent redirect (for example an authenticated route 302'ing to /login when the harness session is broken) is a hard refusal because a headless browser follows redirects by default and would otherwise validate the redirect target's styled state seven times over, and (b) the computed body background is NOT the browser default (rgba(0,0,0,0) / transparent) and the computed body font-family resolves to a non-empty value. Verification runs through the production header path; a harness that strips the security headers, injects nonces the CSP does not declare, or invokes the app via app.inject() rather than a real browser fetch does NOT satisfy the AC. Cures the class of harness where a broken session lane silently causes every route assertion to run against /login (styled) and pass (watchpost run4 partial-acceptance gap, w-2026-08-24-003 / AC-1601-14).",
+      "given": "a server booted through the project's production entry point with every UI-bearing route registered",
+      "when": "a real browser navigates each enumerated route, its final URL is read, and getComputedStyle(document.body) is read",
+      "then": "the final URL path equals the requested route (no silent redirect chain to another surface) AND the computed background is not the browser default AND the computed font-family resolves; on any route the check fails, the run refuses ship with a per-route diagnostic naming the requested and landed paths",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-1131-4",
+      "description": "The stylesheet-serving route is registered by the same server construction that stamps the production security headers. A separate server instance, a static-file-only mount, or a build harness that skips the shipped header stack does NOT satisfy the AC. The intent is that a same-origin GET for the linked stylesheet URL returns 200 with content-type text/css under the same headers a browser sees for the HTML documents.",
+      "given": "the application boot topology at ship",
+      "when": "the boot topology is inspected AND a same-origin GET is issued for the URL every rendered HTML links via <link rel=\"stylesheet\">",
+      "then": "the stylesheet is served by the same server instance that stamps the production headers AND the response is 200 with content-type text/css",
+      "testable": true,
+      "scope": "deployed"
+    },
+    {
+      "id": "AC-1131-5",
+      "description": "The styled-under-shipped-CSP adherence probe (TAC-209) writes a JSON report at a stable relative path (`reports/csp-styled-adherence.json` under the configured report directory) naming every route probed, the CSP header captured for that route, whether an inline <style> was detected, the computed body background and font-family, the landed URL path (the browser's final URL after any redirect chain resolved) so a pathMismatch refusal names both the requested and landed paths, and an ok / fail verdict.",
+      "given": "a completed probe run (pass or fail)",
+      "when": "the report file is inspected on disk",
+      "then": "the JSON at `reports/csp-styled-adherence.json` matches the shape declared by TAC-209 and its verdict field agrees with the process exit code",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-1131-6",
+      "description": "When the styled-under-shipped-CSP adherence probe is wired as a gate in the delivery-ci-workflows runner (TAC-701), a non-zero probe exit propagates through the per-gate report (TAC-702) and the aggregate report (TAC-703), and the delivery-ci-workflows runner refuses ship with a non-zero exit.",
+      "given": "the delivery-ci-workflows runner configured with the styled-under-CSP adherence probe as a required gate",
+      "when": "the probe reports `fail` on any run",
+      "then": "the aggregate report records the gate as failed and the runner exits non-zero",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-209-application-spa-csp-styled-adherence-probe"
+  ],
+  "createdAt": "2026-08-24T10:30:00Z",
+  "updatedAt": "2026-08-31T11:15:00Z"
+}

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

@@ -0,0 +1,72 @@
+{
+  "usId": "application-spa-US-1132",
+  "prdId": "PRD-001",
+  "reqId": "application-spa-REQ-018",
+  "version": "1.0.0",
+  "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",
+  "iWant": "a runtime check that fails the build when the application ships with a declared external-service dependency whose credentials are placeholder-shaped, or whose provisioning has been silently deferred without an operator-ratified deferral record",
+  "soThat": "an app is never signed off as deployed while an external service the runtime depends on is inert on a placeholder key or has been quietly parked as a documented quirk",
+  "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.",
+      "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"
+    },
+    {
+      "id": "AC-1132-2",
+      "description": "Placeholder-shaped credential values are detected at gate time and refused. The placeholder-shape detector rejects: the empty string, the single characters '-' and '_', values matching /^(changeme|placeholder|example|test|dummy|fake|todo|tbd|xxx+|your[_-].+[_-]here)$/i, values matching /YOUR_.+_HERE/i, values equal to the literal strings 'null' or 'undefined' or 'None', and values that repeat a single character across their full length (e.g. 'xxxxxxxx'). A positive match against any credential field named on the manifest is a hard refusal, regardless of the declared status.",
+      "given": "the resolved value of every credential field named on the external-service-dependency manifest at ship",
+      "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"
+    },
+    {
+      "id": "AC-1132-3",
+      "description": "A dependency at status 'verified' requires captured evidence of a real live handshake with the external service, gathered from the SHIPPED runtime (the same server construction the production entry point boots). Evidence is a provider-side acknowledgement of a probe request: a provider message id, a 2xx from the provider's own status endpoint, or an equivalent provider-attested receipt. A unit-test pass, a mocked adapter response, a synthetic 'ok', or an in-process stub does NOT satisfy the evidence requirement.",
+      "given": "a dependency declared with status 'verified' on the external-service-dependency manifest",
+      "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"
+    },
+    {
+      "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.",
+      "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"
+    },
+    {
+      "id": "AC-1132-5",
+      "description": "The external-service-dependency provisioning probe (TAC-210) writes a JSON report at a stable relative path ('reports/external-dependency-provisioning.json' under the configured report directory) naming every dependency declared, the credential-field placeholder-detector verdict per dependency, the captured handshake evidence per 'verified' dependency, the ratified deferral record reference per 'deferred' dependency, per-dependency verdict, and an aggregate verdict of 'ok' | 'deployed-with-defects'. The 'ok' verdict is reserved for runs in which every declared dependency resolves to 'verified' with live evidence OR 'deferred' with a valid ratified record; any placeholder-shape match, any missing handshake evidence for a 'verified' entry, or any missing ratified record for a 'deferred' entry lands the aggregate at 'deployed-with-defects'.",
+      "given": "a completed probe run (pass or fail)",
+      "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"
+    },
+    {
+      "id": "AC-1132-6",
+      "description": "When the external-service-dependency provisioning probe is wired as a gate in the delivery-ci-workflows runner (TAC-701), a non-zero probe exit propagates through the per-gate report (TAC-702) and the aggregate report (TAC-703), and the delivery-ci-workflows runner refuses ship with a non-zero exit. The 'deployed-with-defects' probe verdict maps deterministically to a 'failed' entry in the TAC-703 aggregate; a run cannot land the pipeline aggregate at 'passed' while any external-service dependency carries placeholder credentials or an unratified deferral.",
+      "given": "the delivery-ci-workflows runner configured with the external-service-dependency provisioning probe as a required gate",
+      "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"
+    }
+  ],
+  "tacIds": [
+    "TAC-210-application-spa-external-dependency-provisioning-probe"
+  ],
+  "createdAt": "2026-08-24T13:00:00Z",
+  "updatedAt": "2026-08-24T13:00:00Z"
+}

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

@@ -0,0 +1,72 @@
+{
+  "usId": "application-spa-US-1133",
+  "prdId": "PRD-001",
+  "reqId": "application-spa-REQ-008",
+  "version": "1.0.0",
+  "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",
+  "iWant": "a runtime check that fails the build unless every core user flow the application enumerates completes end-to-end against the shipped runtime with real providers and captured evidence, with authentication always included when the application has any authentication surface",
+  "soThat": "an app is never signed off as done while its core flows (authentication first) are unproven end-to-end in the production runtime, and 'a workaround exists' explicitly does not convert a broken flow into a passing check",
+  "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.",
+      "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"
+    },
+    {
+      "id": "AC-1133-2",
+      "description": "Every enumerated core flow executes end-to-end against the SHIPPED runtime: the same server construction the production entry point boots (same route registration, same production security-header stack, same middleware, same static-asset serving), driven by a real headless browser against real external-service providers (not stubbed adapters, not app.inject, not a bespoke test harness). The probe refuses ship when any flow ran through an in-process fetch, a mocked provider, a header-stripping harness, or a server instance the production entry point does not construct.",
+      "given": "the server the probe drives",
+      "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"
+    },
+    {
+      "id": "AC-1133-3",
+      "description": "For every enumerated core flow the probe captures evidence sufficient to reconstruct the run: the ordered navigation trace (routes visited with response status codes), the terminal DOM assertion result, the wall-clock timing per step, and any provider-side ids the flow generated (e.g. an emailed magic-link id, a payment-provider intent id). A skipped, timed-out, or absent evidence entry for any enumerated core flow is a HARD REFUSAL; 'a documented workaround exists', a status.md quirk line, an operator note, or a mint-your-own-token bypass explicitly does NOT convert a broken or skipped flow into a passing verdict.",
+      "given": "an enumerated core flow whose captured evidence is absent, marked 'skipped', or ends in a non-success terminal state",
+      "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"
+    },
+    {
+      "id": "AC-1133-4",
+      "description": "For every core flow that fails or is skipped, the probe writes a machine-readable refusal on the report naming the flow id, the entry-point route, the step at which the flow diverged from expectation, the assertion that did not hold, and the captured evidence up to the divergence. The refusal renders in the probe's stdout with the flow id and the report path, so a delivery-ci-workflows operator reading the runner output sees which flow refused and where to look. Silent-log refusals are not permitted; every refusal exits the probe non-zero.",
+      "given": "any core flow the probe records as 'fail' or 'skip'",
+      "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"
+    },
+    {
+      "id": "AC-1133-5",
+      "description": "The core-flow end-to-end probe (TAC-211) writes a JSON report at a stable relative path ('reports/core-flow-e2e-adherence.json' under the configured report directory) naming every core flow enumerated, its captured evidence entry, its per-flow verdict ('ok' | 'fail' | 'skip'), and an aggregate 'verdict' field of 'ok' | 'deployed-with-defects'. The 'ok' aggregate is reserved for runs in which every enumerated core flow lands 'ok'; any 'fail' or 'skip' entry lands the aggregate at 'deployed-with-defects'.",
+      "given": "a completed probe run (pass or fail)",
+      "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"
+    },
+    {
+      "id": "AC-1133-6",
+      "description": "When the core-flow end-to-end probe is wired as a gate in the delivery-ci-workflows runner (TAC-701), a non-zero probe exit propagates through the per-gate report (TAC-702) and the aggregate report (TAC-703), and the delivery-ci-workflows runner refuses ship with a non-zero exit. The 'deployed-with-defects' probe verdict maps deterministically to a 'failed' entry in the TAC-703 aggregate; a run cannot land the pipeline aggregate at 'passed' while any enumerated core flow ran as 'fail' or 'skip'.",
+      "given": "the delivery-ci-workflows runner configured with the core-flow end-to-end probe as a required gate",
+      "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"
+    }
+  ],
+  "tacIds": [
+    "TAC-211-application-spa-core-flow-e2e-probe"
+  ],
+  "createdAt": "2026-08-24T13:00:00Z",
+  "updatedAt": "2026-08-24T13:00:00Z"
+}

package/blueprints/application-spa/docs/topics.md

@@ -0,0 +1,57 @@
+# application-spa blueprint coordination vocabulary
+
+This file is the cross-blueprint contract. The Phase 1 conflict detector matches scope:global ADR topics by EXACT string equality, and AC ids are unnamespaced by the 0.4.4 grammar. Any blueprint intended to compose with this one must reuse these exact strings and respect these bands.
+
+## Global ADR topics (exact strings)
+
+| Topic string | application-spa contribution | Meaning | Composition note |
+|---|---|---|---|
+| `clientRouting` | ADR-201-application-spa-routing | How URLs map to client surfaces | Owned by the client tier; a second client-tier blueprint on one project conflicts here by design |
+| `theming` | ADR-202-application-spa-theming | The one theming mechanism for the project | Any blueprint contributing themable UI must join or supersede this decision. v1.1 strengthens the ADR in place with a runtime-observable probe (TAC-207); topic ownership is unchanged. |
+| `clientState` | ADR-203-application-spa-client-state | Client cache and state regime | Client-tier owned |
+| `errorEnvelope` | ADR-204-application-spa-error-envelope | The wire error shape | The application-api-rest blueprint contributes its own scope:global ADR on this exact topic; `rcf define blueprint add application-api-rest` after application-spa (or vice versa) surfaces a DELIBERATE conflict for operator resolution. Expected resolution: one project-level ADR adopting RFC 7807 end to end, superseding both |
+| `authModel` | ADR-205-application-spa-auth-model | The project authentication model | Same deliberate pairing with the application-api-rest blueprint's auth-classes decision; security-auth-magic-link blueprint adds a third contributor. Resolve with one project-level ADR and `--resolve authModel=project:<id>` on subsequent adds |
+
+Rules for new topics: lower camel case, one concept per topic, no version suffixes. A topic names the decision area, not the chosen answer.
+
+v1.1 mints ZERO new global topics. The mechanism-reach cure lives entirely in additive non-global contributions (TAC-207, TAC-208, application-spa-US-1129, application-spa-US-1130) plus in-place amendments to ADR-206 and ADR-202 that strengthen the consequences narrative without moving the decision. `iconography` is NOT a global topic and remains non-global in v1.1.
+
+## Id number bands
+
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; only the band allocation prevents cross-blueprint AC collisions. The band IS the AC-collision enforcement mechanism: composing blueprints take a fresh band rather than proposing namespaced AC ids.
+
+## Full-ecosystem registry table (post-v1.1.0 SPA bump)
+
+This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| application-spa | 1101-1899 | 2xx | shipped v1.3.0 | `clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel` |
+| application-api-rest | 2101-2899 | 3xx | shipped v1.0.0 | `errorEnvelope`, `authModel`, `apiVersioning`, `logging` |
+| security-auth-magic-link | 3101-3899 | 5xx | shipped v1.0.0 | `authModel` |
+| email-smtp-resend | 4101-4899 | 4xx | shipped v1.0.0 | none |
+| hello-panel (walkthrough exemplar) | 4101-4899 | 4xx | doc-reserved; teaching exemplar in `packages/rcf-lite/docs/blueprint-authoring-walkthrough.md`, not shipped as a blueprint directory | `operatorPanel` |
+| persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| delivery-ci-workflows | 6101-6899 | 7xx | shipped v2.0.0 (renamed from ci-pipeline) | `ciGates`, `strictCoverageGate`, `releaseArtefacts` |
+| observability-essentials | 7101-7899 | 8xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics`, `statusPageContract` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `secretsSource` |
+| security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
+| security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
+| security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
+| deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.0.0 | `deploymentTarget` |
+| persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics` |
+
+SPA v1.1.0 stays on the LOW end of its band: v1.0.0 occupied US-1101 through US-1128; v1.1.0 adds US-1129 and US-1130, leaving headroom above 1130 for future minor bumps and for project-side stories that mechanically derive to the 11xx numeric range.
+
+Suffix-family ids (ADR, TAC) are string-distinct once slug-suffixed. SPA numbers its ADRs and TACs in the 2xx block for legibility: v1.0.0 ADR-201 through ADR-209 and TAC-201 through TAC-206; v1.1.0 adds TAC-207-application-spa-token-adherence-probe and TAC-208-application-spa-icon-adherence-probe.
+
+## Shared expectations for composing blueprints
+
+- Reuse `errorEnvelope`, `authModel`, and `theming` exactly as spelled above; do not mint `errorShape`, `auth`, or theme variants. New blueprints authoring in the `theming` space either supersede ADR-202 with a project-level ruling or supersede-and-adopt.
+- The SPA data layer consumes RFC 7807 problem details (ADR-204) and cookie-based sessions (ADR-205); a client-tier blueprint's decisions should state their client-facing halves in terms compatible with these or expect the operator to supersede both.
+- The v1.1 token-adherence probe and icon-adherence probe are BLUEPRINT ACs bound to BLUEPRINT TACs. A composing project realises the TACs against its own build layout; the ACs are runtime-observable and TC-bindable in the project's build cycle.
+
+## 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.

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

@@ -0,0 +1,40 @@
+# The application-spa blueprint: an operator's guide
+
+This guide is for the human running the project, not the coding agent. It explains what applying this blueprint buys you, when it is the wrong tool, and what still needs your judgement afterwards.
+
+## 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.
+
+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.
+
+## What it deliberately is not
+
+- It is not code. No components, no framework choice, no test files. Your working agent implements tests from the ACs the same way it does for your own stories, and writes the application in whatever stack the project chose. (Blueprints shipping tests was considered and ratified out: adherence is expressed as ACs, decision 5 of the design brief.)
+- It is not your product spec. It says every route must handle empty, loading, error, and success; it cannot know what your routes are. Elicitation still happens; this package is the floor under it.
+- It does not ship FBS work items. FBSs are the work of the implementing agent, not the blueprint: build tasks have to be derived in the host project at creation time, where the project's own constraints, sequencing, and existing work apply. The blueprint contributes the WHAT (REQ/US/AC/TAC/ADR); your project derives the HOW.
+
+## When to reach for it
+
+Any project whose primary surface is a browser SPA: dashboards, admin panels, SaaS products, internal tools that deserve to feel like products. Compose it freely with an API blueprint; that composition is the intended shape.
+
+## When it does not fit
+
+- Server-rendered or content-first sites (marketing, docs): the routing and state decisions here assume a client-side application; a future static-site blueprint is the right home.
+- Native or hybrid mobile shells: the breakpoints and target-size floors overlap, but the navigation and auth decisions do not transfer.
+- Projects with a mandated design system: apply the blueprint for its behavioural ACs, then supersede the theming ADR and swap the token values; the parity and contrast ACs still hold and will validate your mandated palette.
+
+## What a good outcome looks like
+
+Walk any journey in the finished product and try to catch it looking abandoned: force an error, empty a list, expire the session mid-form, switch to dark, drop the network, tab through without a mouse, load it on a phone. A build that honours this doc set has a designed answer everywhere you poke. That is the measure: what the user sees out of the box, against how much was left for them to discover broken.
+
+## Your decisions that remain open
+
+1. Copy. Every empty state, error, and onboarding surface carries product-specific copy; the ACs require the template text be replaced (AC-1124-5).
+2. The five global decisions. Routing, theming, client state, error envelope, auth model ship as accepted defaults. Disagree by superseding with a project-level ADR, not by editing the blueprint's files.
+3. Composition conflicts. Adding a REST-style blueprint will surface deliberate conflicts on `errorEnvelope` and `authModel`. That is the mechanism working: resolve each with one project-level decision.
+4. Key routes and journeys. The performance and journey ACs bind to inventories your project declares during elicitation. Declare them honestly; an empty journey inventory makes those ACs vacuously green and that defeats the point.
+
+## 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.

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

@@ -0,0 +1,39 @@
+# Changelog: delivery-ci-workflows blueprint
+
+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.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).
+
+### Changed (BREAKING)
+
+- **Slug rename**: `ci-pipeline` -> `delivery-ci-workflows`. Directory `blueprints/ci-pipeline/` -> `blueprints/delivery-ci-workflows/`. Every contribution id rewrites: prefix-family `ci-pipeline-REQ-NNN` -> `delivery-ci-workflows-REQ-NNN` (numbers preserved), suffix-family `TAC-70N-ci-pipeline-<tail>` -> `TAC-70N-delivery-ci-workflows-<tail>` (numbers and tails preserved).
+- **`ciGates` topic answer surface broadened**: the topic string is unchanged; the delivery-side answer is now the mandatory tier (v1 fixed two-gate set, preserved verbatim) plus the elicited tier the project turns on and off through `workflowShape.checkSet` (default: every catalogued elicited check on). Downstream readers of the aggregate report see a longer `gates[]` array; the report shape itself is unchanged.
+- **New global topic**: `releaseArtefacts` is minted for the decision area of what the release workflow produces on a release trigger. ADR-709 is the delivery-side answer (the four-mode `releaseMode` enumeration).
+- **`workflowShape` elicitation surface required**: the project ships `.rcf/config/delivery-ci-workflows.json` with three required fields (`branchModel`, `checkSet`, `providerHint`) plus one optional field (`releaseMode`, absent = no release workflow, per Q6-B ratification) and two optional dimensions (`scheduledAudit`, `trunkPullRequests`). The workflow-materialiser boot-check refuses on missing required fields or unrecognised values.
+
+### 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.
+- 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.
+- Distinct aggregate report paths per workflow: commit-triggered stays at `.rcf/reports/ci/pipeline.json`; release writes to `.rcf/reports/ci/release.json`; scheduled-audit writes to `.rcf/reports/ci/scheduled-audit.json`.
+- GHA illustrative asset set now covers one file per workflow in the matrix under `assets/ci-provider-examples/github-actions/`. The alternate-provider notes doc extends the four-point mapping to cover every workflow.
+
+### Migration
+
+For a project that applied `ci-pipeline` v1:
+
+1. `rcf define blueprint remove ci-pipeline`.
+2. `rcf define blueprint add <path>/blueprints/delivery-ci-workflows`.
+3. Populate `.rcf/config/delivery-ci-workflows.json` with the `workflowShape` block (see the guide for the four dimensions plus the two optional).
+4. Run the project-realised workflow-materialiser (TAC-704 realisation) to produce the workflow set.
+5. Any project-authored ADR that superseded v1's `ciGates` topic is re-authored to supersede v2's `ciGates` (topic string unchanged; the mechanism records the pair).
+6. Downstream readers that read per-gate reports pick up the new `checkKind` field; readers written against the v1 fixed key set continue to work (the v1 keys are a strict subset).
+
+## [1.0.0] - 2026-08-24
+
+Initial release under the `ci-pipeline` slug. Ships the two-gate mandatory suite (`validate` then `coverage-strict`), the Node-only runner contract, the per-gate and aggregate JSON report shapes, and one illustrative GHA workflow. Two global topics: `ciGates`, `strictCoverageGate`. Superseded by v2.0.0 under the `delivery-ci-workflows` slug.

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

@@ -0,0 +1,57 @@
+# Delivery-ci-workflows blueprint (v2.0.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.
+
+## Apply
+
+```
+rcf define blueprint add <path-to>/blueprints/delivery-ci-workflows
+```
+
+Phase 1 resolves local path sources only; registry and git-ref resolution is a mechanism follow-up. Apply is idempotent; `rcf define blueprint list` shows the applied entry; `rcf define blueprint remove delivery-ci-workflows` cleanly removes an unreferenced application.
+
+Projects on the v1 `ci-pipeline` slug follow the migration path in the CHANGELOG: remove `ci-pipeline`, add `delivery-ci-workflows`, populate `.rcf/config/delivery-ci-workflows.json`, re-run the workflow-materialiser.
+
+## Anatomy
+
+| Piece | Where | What |
+|---|---|---|
+| Metadata | `blueprint.json` | Slug, version, and the 62 contributions with scope/topic on the three global ADRs |
+| 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 |
+| 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 |
+
+The doc set is contributions (copied into the project tree by `rcf define blueprint add`); the guide, assets, and docs are package-resident references. Guide rendering into `rcf/knowledge/docs/blueprint-guides/` and asset ingestion are mechanism follow-ups; until they land, the working agent reads them from the applied blueprint's source path recorded in `manifest.blueprints[].source`.
+
+## 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.
+
+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.
+
+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.
+
+## The three global decisions
+
+ADR-701-delivery-ci-workflows-ci-gates ships `scope: global` on topic `ciGates`. This is the project's required check set: the two mandatory tier gates (`validate` then `coverage-strict`) plus the elicited subset from `workflowShape.checkSet` (default: every catalogued elicited check on). A composing blueprint that ships its own required-check opinion (adherence packs, browser-verify smokes, observability probes) conflicts here by design and expects a project-level ADR that names the extended set.
+
+ADR-702-delivery-ci-workflows-strict-coverage-gate ships `scope: global` on topic `strictCoverageGate`. This is the project's coverage-mode posture: per-AC strict, not shallow-any. Preserved verbatim from v1. A composing blueprint that holds a different coverage posture conflicts here by design.
+
+ADR-709-delivery-ci-workflows-release-artefacts ships `scope: global` on topic `releaseArtefacts` (new at v2). This names the decision area of what the release workflow produces on a release trigger; the delivery-side answer is the four `releaseMode` values. A future `security-release-provenance` or `delivery-release-notes` blueprint that opines on the same decision area conflicts here and expects a project-level ADR that fixes the extended answer.
+
+See `docs/topics.md` for the exact strings, the expected resolutions, the delineation from the application-api-rest blueprint's `logging` topic, and the AC id band allocation (delivery-ci-workflows owns 6101-6899).
+
+## Quality bar
+
+The workflow-materialiser reads `.rcf/config/delivery-ci-workflows.json` and refuses to run when the three required fields are missing or when any field carries an unrecognised value; the required check set runs on every commit-triggered workflow the branch model defines; the mandatory tier runs first in order (`validate` then `coverage-strict`); the elicited tier runs after the mandatory tier in stable but non-load-bearing order; per-gate JSON reports at stable paths carry the v1 fixed key set plus the v2 `checkKind` field; distinct workflows write to distinct aggregate paths (`.rcf/reports/ci/pipeline.json` for commit-triggered, `.rcf/reports/ci/release.json` for release, `.rcf/reports/ci/scheduled-audit.json` for scheduled); a missing required gate report is recorded as `outcome: missing` and flips the aggregate to `failed`; the release workflow shape scales across four discrete modes with the `none` semantic reached either by explicit value or by absent field; the `deployHandoff:<slug>` mode invokes the named deploy blueprint's `promote` workflow with the `versionId` input and refuses at boot when the deploy blueprint is absent; the applied blueprint's source path carries one illustrative GHA workflow file per workflow in the matrix and a notes file mapping four points to alternate providers. Every bar is carried by ACs in the doc set, not by this README.
+
+## Known mechanism-reach gaps
+
+None at v2.0.0. Every AC on every story is bound to at least one TAC that the host project must realise, and every AC's `then` clause is runtime-observable in the materialised workflow files, the aggregate report files at their stable paths, and the platform's own branch-protection or push-protection surface. The mechanism-reach principle from the authoring standard section 7 is satisfied at ship. The operational responsibility a project must own is the branch-protection or equivalent merge-policy configuration on the default or trunk branch that binds the aggregate exit to the merge criterion (AC-6101-2, AC-6114-3, AC-6115-1, AC-6115-2); that responsibility is stated as an AC observable on the platform's own configuration surface, not a smuggled runtime probe.
+
+## Verification depth
+
+The four illustrative GHA workflow files under `assets/ci-provider-examples/github-actions/` are YAML-shape-valid (parseable, `on:` trigger blocks well-formed, jobs and steps structurally complete) and serve as copy-paste starting points; they are NOT executed as part of this blueprint's ship gate. Every non-mandatory-tier check runner and every workflow behaviour (materialiser boot-check, gate-runner orchestration, release-workflow orchestration, scheduled-audit runner, deploy-handoff dispatch, aggregate-report writing) is project-realised against the TAC contracts (TAC-701..706); end-to-end workflow execution is verified in the consuming project's own CI at apply-time, per the mechanism-reach principle. The v1 mandatory-tier upload+promote path (per the v1 blueprint under the old `ci-pipeline` slug) remains dogfood-proven and is preserved verbatim as the mandatory tier here; the v2 elicited-tier catalogue, the new workflow-materialiser TAC, and the release/scheduled-audit workflows are new AC contracts whose runtime enforcement is the applying project's responsibility.

package/blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/default-branch-checks.yml

@@ -0,0 +1,55 @@
+# Illustrative default-branch-checks workflow for the delivery-ci-workflows blueprint.
+# Copy this file into the host project as `.github/workflows/default-branch-checks.yml`
+# and adjust the `node-version`, package-manager setup, and entry-point path
+# to match the project's realised gate runner (TAC-701).
+#
+# Feature-branch shape: pushes to the default branch (which happens on merge).
+# Trunk-based shape: pushes to the trunk branch (every commit). The workflow
+# shape is identical; only the branch name on the `on: push:` block differs.
+#
+# The workflow runs the same required check set as pull-request-checks and
+# writes to the same aggregate report path `.rcf/reports/ci/pipeline.json`.
+#
+# See `guide/delivery-ci-workflows.md` (four-point mapping) for translating
+# this workflow to GitLab CI, CircleCI, Buildkite, or Jenkins.
+
+name: default-branch-checks
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  check-set:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - name: checkout
+        uses: actions/checkout@v4
+
+      - name: setup pnpm
+        uses: pnpm/action-setup@v4
+        with:
+          version: 9
+
+      - name: setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: pnpm
+
+      - name: install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - name: run rcf check set
+        run: node scripts/rcf-ci.js
+
+      - name: upload rcf ci reports
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: default-branch-checks-reports
+          path: .rcf/reports/ci/
+          if-no-files-found: warn
+          retention-days: 30

package/blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/pull-request-checks.yml

@@ -0,0 +1,65 @@
+# Illustrative pull-request-checks workflow for the delivery-ci-workflows blueprint.
+# Copy this file into the host project as `.github/workflows/pull-request-checks.yml`
+# and adjust the `node-version`, package-manager setup, and entry-point path
+# to match the project's realised gate runner (TAC-701).
+#
+# The workflow runs one CI-provider-neutral Node entry point that invokes the
+# required check set (the mandatory tier plus the elicited subset the project
+# turned on in workflowShape.checkSet), writes per-gate and aggregate JSON
+# reports under `.rcf/reports/ci/`, and uploads the report directory as a
+# workflow artefact for downstream readers.
+#
+# Feature-branch shape: pull requests targeting the default branch.
+# Trunk-based shape (trunkPullRequests: sometimes): pull requests targeting
+# the trunk branch. Adjust the branch name on the `on: pull_request:` block.
+#
+# See `guide/delivery-ci-workflows.md` (four-point mapping) for translating
+# this workflow to GitLab CI, CircleCI, Buildkite, or Jenkins.
+
+name: pull-request-checks
+
+on:
+  pull_request:
+    branches: [main]
+
+jobs:
+  check-set:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - name: checkout
+        uses: actions/checkout@v4
+
+      - name: setup pnpm
+        uses: pnpm/action-setup@v4
+        with:
+          version: 9
+
+      - name: setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: pnpm
+
+      - name: install dependencies
+        run: pnpm install --frozen-lockfile
+
+      # Single-line invocation of the project's realised gate runner.
+      # The runner spawns the mandatory tier (`rcf define validate` then
+      # `rcf audit coverage --strict`) and then every elicited check the
+      # project turned on in workflowShape.checkSet, writes
+      # `.rcf/reports/ci/<gate>.json` per gate with the `checkKind` field,
+      # and writes `.rcf/reports/ci/pipeline.json` as the aggregate. Its
+      # exit code is the pipeline's aggregate exit code.
+      - name: run rcf check set
+        run: node scripts/rcf-ci.js
+
+      - name: upload rcf ci reports
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: pull-request-checks-reports
+          path: .rcf/reports/ci/
+          if-no-files-found: warn
+          retention-days: 30