rcf-lite 0.16.0 → 0.18.0

package/blueprints/delivery-ci-workflows/assets/ci-provider-examples/notes.md

@@ -2,6 +2,24 @@
 
 The blueprint ships one illustrative provider example (GitHub Actions, four workflow files under `github-actions/`). Every mainstream provider hosts the same workflow set by translating four points per workflow and keeping the Node entry-point invocations unchanged. These notes are read alongside `guide/delivery-ci-workflows.md`, not instead of it.
 
+## The e2e job (v2.2.0)
+
+When a project applies at least one blueprint declaring `.browserSurface.declared: true` on its source `blueprint.json` (for example `application-spa` v1.4.0), the workflow-materialiser adds an `e2e` job to `pull-request-checks`. The GitHub Actions shape ships in `github-actions/pull-request-checks.yml`. Every provider hosts the same job by translating four points:
+
+1. **Trigger.** Same trigger as the check-set job on the same workflow; the e2e job is a peer, not a separate workflow.
+2. **Browser tooling install.** After Node + package-manager setup, install a Playwright browser: `npx playwright install chromium --with-deps` (or the provider's equivalent). rcf-lite pins `@playwright/mcp` for `rcf verify`; the same browser installation drives the project's e2e suite.
+3. **Runner invocation.** `node scripts/rcf-ci-e2e.js` (the project-owned e2e runner; writes `.rcf/reports/ci/e2e.json` with `checkKind: "e2e"`).
+4. **Browser-artefact upload.** Upload screenshots and HTML captures alongside the per-gate report so a failing run has visible evidence.
+
+The four provider translations follow the same substitution shape as the check-set job:
+
+- **GitLab CI.** Add an `e2e` job in `.gitlab-ci.yml`; `image: mcr.microsoft.com/playwright:v1.50.0-noble` or install chromium via `apt-get` then `npx playwright install`; invoke `node scripts/rcf-ci-e2e.js`; upload with `artifacts: { when: always, paths: [.rcf/reports/ci/e2e.json, playwright-report/, test-results/] }`.
+- **CircleCI.** Add an `e2e` job in `.circleci/config.yml`; `- browser-tools/install-browser-tools` orb + `npx playwright install chromium`; invoke as above; `store_artifacts: { path: playwright-report }` plus `store_artifacts: { path: .rcf/reports/ci/e2e.json }`.
+- **Buildkite.** Add an `e2e` step; install chromium via the pipeline setup hook or a Docker plugin (`docker#v5.0.0`); invoke as above; `artifact_paths: [".rcf/reports/ci/e2e.json", "playwright-report/**", "test-results/**"]`.
+- **Jenkins.** Add an `e2e` stage; install chromium via `sh 'npx playwright install chromium --with-deps'`; invoke as above; `archiveArtifacts artifacts: '.rcf/reports/ci/e2e.json, playwright-report/**, test-results/**', allowEmptyArchive: true`.
+
+Projects that apply no browser-facing blueprint delete the `e2e` job from the workflow (or the materialiser omits it on regeneration); the workflow reads byte-identical to a 2.1 project in that case.
+
 ## The workflow set the matrix materialises
 
 Which workflow files exist depends on `workflowShape`:

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

@@ -1,60 +1,273 @@
 {
   "slug": "delivery-ci-workflows",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "category": "delivery",
   "contributions": [
-    { "id": "delivery-ci-workflows-REQ-001", "kind": "req", "path": "requirements/delivery-ci-workflows-req-001.json" },
-    { "id": "delivery-ci-workflows-REQ-002", "kind": "req", "path": "requirements/delivery-ci-workflows-req-002.json" },
-    { "id": "delivery-ci-workflows-REQ-003", "kind": "req", "path": "requirements/delivery-ci-workflows-req-003.json" },
-    { "id": "delivery-ci-workflows-REQ-004", "kind": "req", "path": "requirements/delivery-ci-workflows-req-004.json" },
-    { "id": "delivery-ci-workflows-REQ-005", "kind": "req", "path": "requirements/delivery-ci-workflows-req-005.json" },
-    { "id": "delivery-ci-workflows-REQ-006", "kind": "req", "path": "requirements/delivery-ci-workflows-req-006.json" },
-    { "id": "delivery-ci-workflows-REQ-007", "kind": "req", "path": "requirements/delivery-ci-workflows-req-007.json" },
-    { "id": "delivery-ci-workflows-REQ-008", "kind": "req", "path": "requirements/delivery-ci-workflows-req-008.json" },
-    { "id": "delivery-ci-workflows-REQ-009", "kind": "req", "path": "requirements/delivery-ci-workflows-req-009.json" },
-    { "id": "delivery-ci-workflows-REQ-010", "kind": "req", "path": "requirements/delivery-ci-workflows-req-010.json" },
-    { "id": "delivery-ci-workflows-REQ-011", "kind": "req", "path": "requirements/delivery-ci-workflows-req-011.json" },
-    { "id": "delivery-ci-workflows-REQ-012", "kind": "req", "path": "requirements/delivery-ci-workflows-req-012.json" },
-    { "id": "delivery-ci-workflows-REQ-013", "kind": "req", "path": "requirements/delivery-ci-workflows-req-013.json" },
-    { "id": "delivery-ci-workflows-REQ-014", "kind": "req", "path": "requirements/delivery-ci-workflows-req-014.json" },
-    { "id": "delivery-ci-workflows-REQ-015", "kind": "req", "path": "requirements/delivery-ci-workflows-req-015.json" },
-    { "id": "delivery-ci-workflows-REQ-016", "kind": "req", "path": "requirements/delivery-ci-workflows-req-016.json" },
-    { "id": "delivery-ci-workflows-REQ-017", "kind": "req", "path": "requirements/delivery-ci-workflows-req-017.json" },
-    { "id": "delivery-ci-workflows-REQ-018", "kind": "req", "path": "requirements/delivery-ci-workflows-req-018.json" },
-    { "id": "delivery-ci-workflows-REQ-019", "kind": "req", "path": "requirements/delivery-ci-workflows-req-019.json" },
-    { "id": "delivery-ci-workflows-REQ-020", "kind": "req", "path": "requirements/delivery-ci-workflows-req-020.json" },
-    { "id": "delivery-ci-workflows-REQ-021", "kind": "req", "path": "requirements/delivery-ci-workflows-req-021.json" },
-    { "id": "delivery-ci-workflows-REQ-022", "kind": "req", "path": "requirements/delivery-ci-workflows-req-022.json" },
-    { "id": "delivery-ci-workflows-REQ-023", "kind": "req", "path": "requirements/delivery-ci-workflows-req-023.json" },
-    { "id": "delivery-ci-workflows-US-6101", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6101.json" },
-    { "id": "delivery-ci-workflows-US-6102", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6102.json" },
-    { "id": "delivery-ci-workflows-US-6103", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6103.json" },
-    { "id": "delivery-ci-workflows-US-6104", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6104.json" },
-    { "id": "delivery-ci-workflows-US-6105", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6105.json" },
-    { "id": "delivery-ci-workflows-US-6106", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6106.json" },
-    { "id": "delivery-ci-workflows-US-6107", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6107.json" },
-    { "id": "delivery-ci-workflows-US-6108", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6108.json" },
-    { "id": "delivery-ci-workflows-US-6109", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6109.json" },
-    { "id": "delivery-ci-workflows-US-6110", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6110.json" },
-    { "id": "delivery-ci-workflows-US-6111", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6111.json" },
-    { "id": "delivery-ci-workflows-US-6112", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6112.json" },
-    { "id": "delivery-ci-workflows-US-6113", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6113.json" },
-    { "id": "delivery-ci-workflows-US-6114", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6114.json" },
-    { "id": "delivery-ci-workflows-US-6115", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6115.json" },
-    { "id": "delivery-ci-workflows-US-6116", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6116.json" },
-    { "id": "delivery-ci-workflows-US-6117", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6117.json" },
-    { "id": "delivery-ci-workflows-US-6118", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6118.json" },
-    { "id": "delivery-ci-workflows-US-6119", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6119.json" },
-    { "id": "delivery-ci-workflows-US-6120", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6120.json" },
-    { "id": "delivery-ci-workflows-US-6121", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6121.json" },
-    { "id": "delivery-ci-workflows-US-6122", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6122.json" },
-    { "id": "delivery-ci-workflows-US-6123", "kind": "us", "path": "user-stories/delivery-ci-workflows-us-6123.json" },
-    { "id": "TAC-701-delivery-ci-workflows-gate-runner", "kind": "tac", "path": "tacs/tac-701-delivery-ci-workflows-gate-runner.json" },
-    { "id": "TAC-702-delivery-ci-workflows-gate-report", "kind": "tac", "path": "tacs/tac-702-delivery-ci-workflows-gate-report.json" },
-    { "id": "TAC-703-delivery-ci-workflows-aggregate-report", "kind": "tac", "path": "tacs/tac-703-delivery-ci-workflows-aggregate-report.json" },
-    { "id": "TAC-704-delivery-ci-workflows-workflow-materialiser", "kind": "tac", "path": "tacs/tac-704-delivery-ci-workflows-workflow-materialiser.json" },
-    { "id": "TAC-705-delivery-ci-workflows-release-workflow", "kind": "tac", "path": "tacs/tac-705-delivery-ci-workflows-release-workflow.json" },
-    { "id": "TAC-706-delivery-ci-workflows-scheduled-audit", "kind": "tac", "path": "tacs/tac-706-delivery-ci-workflows-scheduled-audit.json" },
+    {
+      "id": "delivery-ci-workflows-REQ-001",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-001.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-002",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-002.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-003",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-003.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-004",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-004.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-005",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-005.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-006",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-006.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-007",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-007.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-008",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-008.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-009",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-009.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-010",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-010.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-011",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-011.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-012",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-012.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-013",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-013.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-014",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-014.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-015",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-015.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-016",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-016.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-017",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-017.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-018",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-018.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-019",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-019.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-020",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-020.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-021",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-021.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-022",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-022.json"
+    },
+    {
+      "id": "delivery-ci-workflows-REQ-023",
+      "kind": "req",
+      "path": "requirements/delivery-ci-workflows-req-023.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6101",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6101.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6102",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6102.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6103",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6103.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6104",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6104.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6105",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6105.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6106",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6106.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6107",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6107.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6108",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6108.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6109",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6109.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6110",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6110.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6111",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6111.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6112",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6112.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6113",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6113.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6114",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6114.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6115",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6115.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6116",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6116.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6117",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6117.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6118",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6118.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6119",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6119.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6120",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6120.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6121",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6121.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6122",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6122.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6123",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6123.json"
+    },
+    {
+      "id": "delivery-ci-workflows-US-6124",
+      "kind": "us",
+      "path": "user-stories/delivery-ci-workflows-us-6124.json"
+    },
+    {
+      "id": "TAC-701-delivery-ci-workflows-gate-runner",
+      "kind": "tac",
+      "path": "tacs/tac-701-delivery-ci-workflows-gate-runner.json"
+    },
+    {
+      "id": "TAC-702-delivery-ci-workflows-gate-report",
+      "kind": "tac",
+      "path": "tacs/tac-702-delivery-ci-workflows-gate-report.json"
+    },
+    {
+      "id": "TAC-703-delivery-ci-workflows-aggregate-report",
+      "kind": "tac",
+      "path": "tacs/tac-703-delivery-ci-workflows-aggregate-report.json"
+    },
+    {
+      "id": "TAC-704-delivery-ci-workflows-workflow-materialiser",
+      "kind": "tac",
+      "path": "tacs/tac-704-delivery-ci-workflows-workflow-materialiser.json"
+    },
+    {
+      "id": "TAC-705-delivery-ci-workflows-release-workflow",
+      "kind": "tac",
+      "path": "tacs/tac-705-delivery-ci-workflows-release-workflow.json"
+    },
+    {
+      "id": "TAC-706-delivery-ci-workflows-scheduled-audit",
+      "kind": "tac",
+      "path": "tacs/tac-706-delivery-ci-workflows-scheduled-audit.json"
+    },
     {
       "id": "ADR-701-delivery-ci-workflows-ci-gates",
       "kind": "adr",
@@ -69,12 +282,36 @@
       "scope": "global",
       "topic": "strictCoverageGate"
     },
-    { "id": "ADR-703-delivery-ci-workflows-node-only-runner", "kind": "adr", "path": "adrs/adr-703-delivery-ci-workflows-node-only-runner.json" },
-    { "id": "ADR-704-delivery-ci-workflows-report-shape", "kind": "adr", "path": "adrs/adr-704-delivery-ci-workflows-report-shape.json" },
-    { "id": "ADR-705-delivery-ci-workflows-elicitation-surface", "kind": "adr", "path": "adrs/adr-705-delivery-ci-workflows-elicitation-surface.json" },
-    { "id": "ADR-706-delivery-ci-workflows-branch-model-defaults", "kind": "adr", "path": "adrs/adr-706-delivery-ci-workflows-branch-model-defaults.json" },
-    { "id": "ADR-707-delivery-ci-workflows-release-workflow-shape", "kind": "adr", "path": "adrs/adr-707-delivery-ci-workflows-release-workflow-shape.json" },
-    { "id": "ADR-708-delivery-ci-workflows-provider-hint-shape", "kind": "adr", "path": "adrs/adr-708-delivery-ci-workflows-provider-hint-shape.json" },
+    {
+      "id": "ADR-703-delivery-ci-workflows-node-only-runner",
+      "kind": "adr",
+      "path": "adrs/adr-703-delivery-ci-workflows-node-only-runner.json"
+    },
+    {
+      "id": "ADR-704-delivery-ci-workflows-report-shape",
+      "kind": "adr",
+      "path": "adrs/adr-704-delivery-ci-workflows-report-shape.json"
+    },
+    {
+      "id": "ADR-705-delivery-ci-workflows-elicitation-surface",
+      "kind": "adr",
+      "path": "adrs/adr-705-delivery-ci-workflows-elicitation-surface.json"
+    },
+    {
+      "id": "ADR-706-delivery-ci-workflows-branch-model-defaults",
+      "kind": "adr",
+      "path": "adrs/adr-706-delivery-ci-workflows-branch-model-defaults.json"
+    },
+    {
+      "id": "ADR-707-delivery-ci-workflows-release-workflow-shape",
+      "kind": "adr",
+      "path": "adrs/adr-707-delivery-ci-workflows-release-workflow-shape.json"
+    },
+    {
+      "id": "ADR-708-delivery-ci-workflows-provider-hint-shape",
+      "kind": "adr",
+      "path": "adrs/adr-708-delivery-ci-workflows-provider-hint-shape.json"
+    },
     {
       "id": "ADR-709-delivery-ci-workflows-release-artefacts",
       "kind": "adr",
@@ -82,6 +319,10 @@
       "scope": "global",
       "topic": "releaseArtefacts"
     },
-    { "id": "ADR-710-delivery-ci-workflows-scheduled-audit", "kind": "adr", "path": "adrs/adr-710-delivery-ci-workflows-scheduled-audit.json" }
+    {
+      "id": "ADR-710-delivery-ci-workflows-scheduled-audit",
+      "kind": "adr",
+      "path": "adrs/adr-710-delivery-ci-workflows-scheduled-audit.json"
+    }
   ]
 }

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

@@ -0,0 +1,28 @@
+{
+  "usId": "delivery-ci-workflows-US-6124",
+  "prdId": "PRD-001",
+  "reqId": "delivery-ci-workflows-REQ-019",
+  "version": "2.2.0",
+  "status": "approved",
+  "title": "The e2e check is documented in the illustrative pull-request-checks workflow and the check catalogue",
+  "asA": "operator whose project applies at least one blueprint declaring a browserSurface",
+  "iWant": "the illustrative pull-request-checks workflow to ship a documented e2e job block naming the four points a browser-facing project's e2e job satisfies (distinct job running the project's testLevel: e2e cases against a local preview or a --parity-env runtime, browser-artefact upload, distinct row in the aggregate pipeline report, per-gate report at .rcf/reports/ci/e2e.json), and the elicited checkSet.e2e entry to exist in the check catalogue so a project that turns the check off does so through a supported knob",
+  "soThat": "browser-facing projects get a documentation contract they copy-paste today, ahead of the runtime materialiser landing (spec amendment A2, 2026-09-03: rcf-lite ships no workflow-materialiser at this train, so this AC is documentation-only; the runtime iff wiring lands in a follow-up train with its own paired TS entry)",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-6124-1",
+      "description": "The illustrative pull-request-checks.yml under blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/ carries a documented e2e job block whose header comment names the four points a browser-facing project's e2e job satisfies: (a) runs the project's testLevel: e2e cases against a local preview or a --parity-env runtime, (b) uploads screenshots and HTML captures as workflow artefacts, (c) writes a distinct row to the aggregate pipeline report at .rcf/reports/ci/pipeline.json, (d) writes a per-gate report at .rcf/reports/ci/e2e.json with checkKind: 'e2e'. The header also tells a non-browser project to delete the e2e job before committing. The elicited checkSet.e2e entry exists in the delivery-ci-workflows check catalogue (blueprint.json) so a project that turns the check off does so through a supported knob. The runtime iff wiring (materialiser adds or omits the job based on manifest.blueprints[].source.browserSurface.declared and .rcf/config/delivery-ci-workflows.json:checkSet.e2e) lands in a follow-up train with its own TS entry; this AC is documentation-only per spec amendment A2 (2026-09-03).",
+      "given": "the delivery-ci-workflows blueprint at v2.2.0",
+      "when": "blueprints/delivery-ci-workflows/assets/ci-provider-examples/github-actions/pull-request-checks.yml and blueprint.json are inspected",
+      "then": "the illustrative pull-request-checks.yml declares an e2e job; the block above it names the four points and the delete-me note for non-browser projects; blueprint.json's check catalogue carries checkSet.e2e",
+      "testable": true,
+      "scope": "library"
+    }
+  ],
+  "tacIds": [
+    "TAC-701-delivery-ci-workflows-gate-runner",
+    "TAC-702-delivery-ci-workflows-gate-report"
+  ],
+  "createdAt": "2026-09-03T17:00:00Z",
+  "updatedAt": "2026-09-03T18:30:50Z"
+}

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

@@ -41,14 +41,14 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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` |
+| observability-essentials | 7101-7899 | 8xx | shipped v2.0.0 | `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` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
 
 US 6101-6110 sit at the LOW end of the 6101-6899 band on purpose. A project-side story that mechanically derives from `delivery-ci-workflows-REQ-011` into the number `6111` would collide against delivery-ci-workflows-US-6111 in this package; the band leaves headroom at the HIGH end (US 6181-6899) so a project's own stories anchored to delivery-ci-workflows REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/deploy-cloudflare-workers/docs/topics.md

@@ -27,14 +27,14 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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` |
+| observability-essentials | 7101-7899 | 8xx | shipped v2.0.0 | `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` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
 
 US 12101-12112 sit at the LOW end of the 12101-12899 band on purpose. A project-side story that mechanically derives from a deploy-cloudflare-workers REQ id into the number `12112` would collide against deploy-cloudflare-workers-US-12112 in this package; the band leaves headroom at the HIGH end (US 12181-12899) so a project's own stories anchored to deploy-cloudflare-workers REQs can allocate without conflict. The watchpost run4 lesson applies here too. Band spacing between the last shipped block (security-secrets-management, 8101-8899, 9xx) and this one (12101-12899, 13xx) leaves the 9xxx-11xxx US bands and the 10xx-12xx suffix blocks open for concurrent-lane authoring so a peer authoring another blueprint in the same PR window does not collide with this one.
 

package/blueprints/email-smtp-resend/docs/topics.md

@@ -23,14 +23,14 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | 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` |
+| observability-essentials | 7101-7899 | 8xx | shipped v2.0.0 | `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` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.1.0 | `healthProbes`, `readinessSemantics` |
 
 US 4101-4106 sit at the LOW end of the 4101-4899 band on purpose. A project-side story that mechanically derives from an email-smtp-resend REQ id into the number `4106` (leading `4` + sequence `106`) would collide against email-smtp-resend-US-4106 in this package; the band leaves headroom at the HIGH end (US 4181-4899) so a project's own stories anchored to email-smtp-resend REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/observability-essentials/README.md

@@ -1,6 +1,10 @@
-# Observability blueprint (v1.0.0)
+# Observability blueprint (v2.0.0)
 
-The fifth content blueprint on the rcf-build-lite blueprint mechanism (design brief v2, ratified; Phase 5 of the blueprint programme). Scope: two HTTP health probes (liveness /healthz answering strictly on in-process state, readiness /readyz aggregating over an explicit boot-time-declared dependency set with strict-any-fail semantics), a public status page rendering a declared component list plus stable-fielded incident notices, and a durable notification-outcome sink recording every attempt's outcome for later query by recipient and window. Targeted at small greenfield rcf-lite projects. Historical uptime charts, metrics export, and distributed tracing are documented future variants; the v1.0.0 blueprint ships the current-state contract only.
+The fifth content blueprint on the rcf-build-lite blueprint mechanism (design brief v2, ratified; Phase 5 of the blueprint programme). Scope: two HTTP health probes (liveness and readiness, path-neutral from v2.0.0: liveness answering strictly on in-process state, readiness aggregating over an explicit boot-time-declared dependency set with strict-any-fail semantics), a public status page rendering a declared component list plus stable-fielded incident notices, and a durable notification-outcome sink recording every attempt's outcome for later query by recipient and window. Targeted at small greenfield rcf-lite projects. Historical uptime charts, metrics export, and distributed tracing are documented future variants; the v2.0.0 blueprint ships the current-state contract only.
+
+## Breaking change in v2.0.0 (2026-09-04)
+
+This blueprint no longer claims the shelf-wide `healthProbes` or `readinessSemantics` global topics. Path binding moved to `observability-probe-endpoints` (spec `projects/rcf-lite-wsd/specs/rcf-lite-probe-path-alignment-spec-2026-09-04.md`, section 4). Essentials-alone projects now supply `probeInterface.paths.liveness` and `probeInterface.paths.readiness` at boot (a one-line configuration change per environment). Projects that compose `observability-probe-endpoints` v1.1.0 or later inherit its resolved path set automatically and see no functional change beyond the topic ownership. See CHANGELOG.md for the full migration checklist.
 
 ## Apply