rcf-lite 0.16.0 → 0.18.0

package/blueprints/observability-probe-endpoints/README.md

@@ -1,4 +1,4 @@
-# Observability probe endpoints blueprint (v1.0.0)
+# observability-probe-endpoints blueprint (v1.1.0)
 
 The tenth content blueprint on the rcf-build-lite blueprint mechanism, and the second in the `observability` category, sibling to the shipped `observability-essentials`. Scope: a health probe interface derived from an operator-declared target integration profile (`kubernetes`, `loadBalancer`, `uptimeMonitor`, `systemd`, `dockerHealthcheck`, `reverseProxy`, plus a `custom:<name>` slot). Each profile fixes the probe transport, path or command surface, response contract, and semantic distinction between liveness and readiness for the supervisor at hand. Kubernetes is the shipped default (HTTPGet `/live` and `/ready` on the request-traffic listener); every HTTP profile ships with a `probeListener.separatePort` opt-in for probe-traffic isolation from user traffic. Response contracts are minimal by construction; the profile validator refuses any override that would add a field beyond the enumerated set. Targeted at rcf-lite projects that must integrate with a specific EXTERNAL supervising system whose conventions drive the probe wire shape; not targeted at the self-supervised all-in-one observability case (observability-essentials owns that).
 
@@ -51,3 +51,7 @@ The probe surface always follows the operator-declared target integration profil
 
 - **Custom-profile contract adherence.** Projects that author a `custom:<name>` profile against the profile contract are expected to satisfy the same transport/paths/responseContract/semanticModel shape the shipped profiles do; the profile contract validator (TAC-1501) refuses a partial profile at boot, which is where the mechanism reach lands. What the validator cannot compel is that a project-authored custom profile's response shape is minimal in the AC-14105 and AC-14106 sense (a custom profile could in principle enumerate a rich field set the validator would accept as complete). Recorded here rather than smuggled in as an AC that would only apply to the shipped profiles. Promotion signal: a `custom-profile-shape-lint` addition to the profile contract validator that enforces the minimalism rule per field-set-size heuristic (harder than it sounds; some legitimate custom profiles do have wider fields); or a project-side grep gate. Project-side workaround until then: reviewers of a `custom:<name>` profile eyeball the enumerated field set against the pattern the shipped six carry.
 - **Kubernetes gRPC probe transport.** The `kubernetes` profile ships HTTPGet and TCPSocket transports (via TAC-1504's tcpAdapter selection) but not gRPC. A project on a gRPC-only mesh that wants the standard gRPC health protocol supersedes ADR-1503 with a project-level ADR selecting the gRPC transport, or authors a `custom:kubernetes-grpc` profile. Promotion signal: a shipped gRPC-transport handler in a v1.1 pass if enough rcf-lite projects reach for it. Project-side workaround: the `custom:<name>` slot is the mechanism escape hatch.
+
+## Optional startup path (v1.1.0)
+
+The Kubernetes profile gains an optional third path `startup` (default `/startup`) from v1.1.0. It is BOUND only when the operator sets `probeInterface.options.kubernetes.startup.enabled: true`; unset or `false`, the profile resolves as before with the two-path set (`/live`, `/ready`). The startup handler follows the same generation rules as the other Kubernetes-profile handlers (same `{"status":"pass"|"fail"}` body, same auth-exempt list emission, same listener topology). See US-14102 AC-14102-4 and US-14107 AC-14107-4 for the acceptance criteria, and the composing section in `guide/observability-probe-endpoints.md` for how essentials and api-rest defer their path opinions to this blueprint.

package/blueprints/observability-probe-endpoints/blueprint.json

@@ -1,28 +1,108 @@
 {
   "slug": "observability-probe-endpoints",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "category": "observability",
   "contributions": [
-    { "id": "observability-probe-endpoints-REQ-001", "kind": "req", "path": "requirements/observability-probe-endpoints-req-001.json" },
-    { "id": "observability-probe-endpoints-REQ-002", "kind": "req", "path": "requirements/observability-probe-endpoints-req-002.json" },
-    { "id": "observability-probe-endpoints-REQ-003", "kind": "req", "path": "requirements/observability-probe-endpoints-req-003.json" },
-    { "id": "observability-probe-endpoints-REQ-004", "kind": "req", "path": "requirements/observability-probe-endpoints-req-004.json" },
-    { "id": "observability-probe-endpoints-REQ-005", "kind": "req", "path": "requirements/observability-probe-endpoints-req-005.json" },
-    { "id": "observability-probe-endpoints-REQ-006", "kind": "req", "path": "requirements/observability-probe-endpoints-req-006.json" },
-    { "id": "observability-probe-endpoints-REQ-007", "kind": "req", "path": "requirements/observability-probe-endpoints-req-007.json" },
-    { "id": "observability-probe-endpoints-REQ-008", "kind": "req", "path": "requirements/observability-probe-endpoints-req-008.json" },
-    { "id": "observability-probe-endpoints-US-14101", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14101.json" },
-    { "id": "observability-probe-endpoints-US-14102", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14102.json" },
-    { "id": "observability-probe-endpoints-US-14103", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14103.json" },
-    { "id": "observability-probe-endpoints-US-14104", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14104.json" },
-    { "id": "observability-probe-endpoints-US-14105", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14105.json" },
-    { "id": "observability-probe-endpoints-US-14106", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14106.json" },
-    { "id": "observability-probe-endpoints-US-14107", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14107.json" },
-    { "id": "observability-probe-endpoints-US-14108", "kind": "us", "path": "user-stories/observability-probe-endpoints-us-14108.json" },
-    { "id": "TAC-1501-observability-probe-endpoints-profile-resolver", "kind": "tac", "path": "tacs/tac-1501-observability-probe-endpoints-profile-resolver.json" },
-    { "id": "TAC-1502-observability-probe-endpoints-handler-set", "kind": "tac", "path": "tacs/tac-1502-observability-probe-endpoints-handler-set.json" },
-    { "id": "TAC-1503-observability-probe-endpoints-listener-topology", "kind": "tac", "path": "tacs/tac-1503-observability-probe-endpoints-listener-topology.json" },
-    { "id": "TAC-1504-observability-probe-endpoints-non-http-adapters", "kind": "tac", "path": "tacs/tac-1504-observability-probe-endpoints-non-http-adapters.json" },
+    {
+      "id": "observability-probe-endpoints-REQ-001",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-001.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-002",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-002.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-003",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-003.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-004",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-004.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-005",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-005.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-006",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-006.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-007",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-007.json"
+    },
+    {
+      "id": "observability-probe-endpoints-REQ-008",
+      "kind": "req",
+      "path": "requirements/observability-probe-endpoints-req-008.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14101",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14101.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14102",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14102.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14103",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14103.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14104",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14104.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14105",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14105.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14106",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14106.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14107",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14107.json"
+    },
+    {
+      "id": "observability-probe-endpoints-US-14108",
+      "kind": "us",
+      "path": "user-stories/observability-probe-endpoints-us-14108.json"
+    },
+    {
+      "id": "TAC-1501-observability-probe-endpoints-profile-resolver",
+      "kind": "tac",
+      "path": "tacs/tac-1501-observability-probe-endpoints-profile-resolver.json"
+    },
+    {
+      "id": "TAC-1502-observability-probe-endpoints-handler-set",
+      "kind": "tac",
+      "path": "tacs/tac-1502-observability-probe-endpoints-handler-set.json"
+    },
+    {
+      "id": "TAC-1503-observability-probe-endpoints-listener-topology",
+      "kind": "tac",
+      "path": "tacs/tac-1503-observability-probe-endpoints-listener-topology.json"
+    },
+    {
+      "id": "TAC-1504-observability-probe-endpoints-non-http-adapters",
+      "kind": "tac",
+      "path": "tacs/tac-1504-observability-probe-endpoints-non-http-adapters.json"
+    },
     {
       "id": "ADR-1501-observability-probe-endpoints-health-probes",
       "kind": "adr",
@@ -37,8 +117,20 @@
       "scope": "global",
       "topic": "readinessSemantics"
     },
-    { "id": "ADR-1503-observability-probe-endpoints-kubernetes-default", "kind": "adr", "path": "adrs/adr-1503-observability-probe-endpoints-kubernetes-default.json" },
-    { "id": "ADR-1504-observability-probe-endpoints-separate-port-option", "kind": "adr", "path": "adrs/adr-1504-observability-probe-endpoints-separate-port-option.json" },
-    { "id": "ADR-1505-observability-probe-endpoints-external-response-secrecy", "kind": "adr", "path": "adrs/adr-1505-observability-probe-endpoints-external-response-secrecy.json" }
+    {
+      "id": "ADR-1503-observability-probe-endpoints-kubernetes-default",
+      "kind": "adr",
+      "path": "adrs/adr-1503-observability-probe-endpoints-kubernetes-default.json"
+    },
+    {
+      "id": "ADR-1504-observability-probe-endpoints-separate-port-option",
+      "kind": "adr",
+      "path": "adrs/adr-1504-observability-probe-endpoints-separate-port-option.json"
+    },
+    {
+      "id": "ADR-1505-observability-probe-endpoints-external-response-secrecy",
+      "kind": "adr",
+      "path": "adrs/adr-1505-observability-probe-endpoints-external-response-secrecy.json"
+    }
   ]
 }

package/blueprints/observability-probe-endpoints/contributions/adrs/adr-1503-observability-probe-endpoints-kubernetes-default.json

@@ -2,12 +2,12 @@
   "adrId": "ADR-1503-observability-probe-endpoints-kubernetes-default",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "status": "accepted",
-  "title": "Kubernetes is the shipped default target integration profile; HTTPGet /live and /ready on the request-traffic listener are its defaults",
+  "title": "Kubernetes is the shipped default target integration profile; HTTPGet /live and /ready on the request-traffic listener are its defaults, with an optional /startup path off by default",
   "context": "One of the shipped profiles has to be the default the process falls back on when the operator does not declare `probeInterface.profile` explicitly. The choice matters because the default is what a project on the shipped configuration exhibits before the operator has spent any time on the observability surface, and because the default shapes the reader's expectation of what the blueprint 'is about'. The round-2 canon selected Kubernetes as the default: `probe endpoints elicited per deployment type; k8s /live + /ready default; separate-port/separate-server option`.",
-  "decision": "The `kubernetes` profile is the shipped default. When the operator does not declare `probeInterface.profile`, the resolver falls back to `kubernetes` with the default paths `/live` (liveness) and `/ready` (readiness), the default `httpGet` transport, the response contract `{\"status\":\"pass\"|\"fail\"}`, the fused listener topology (probes on the user-traffic listener), and the `strict-any-fail-over-declared-deps` readiness aggregation. The paths and the readiness aggregation are overridable at boot via `probeInterface.options.kubernetes.paths` and `probeInterface.options.kubernetes.readinessRule`. The default hits without operator configuration; overriding is a small config change on the same shape.",
-  "consequences": "A project that applies this blueprint and nothing else immediately exhibits a Kubernetes-shaped probe surface at `/live` and `/ready`; the standard `livenessProbe` and `readinessProbe` of shape `httpGet: { path: /live, port: <containerPort> }` and `httpGet: { path: /ready, port: <containerPort> }` in a Kubernetes podspec work without further wiring. The default is scope-local because it is a preference not a contract: the ADR-1501 elicitation model is the global commitment and the Kubernetes profile is one instantiation of it. A project on Docker Compose or on a bare-metal load-balancer setup that runs the shipped default sees `/live` and `/ready` bound instead of `/health` and reads the disagreement as the signal to declare `probeInterface.profile: loadBalancer` at boot.",
+  "decision": "The `kubernetes` profile is the shipped default. When the operator does not declare `probeInterface.profile`, the resolver falls back to `kubernetes` with the default paths `/live` (liveness) and `/ready` (readiness), the default `httpGet` transport, the response contract `{\"status\":\"pass\"|\"fail\"}`, the fused listener topology (probes on the user-traffic listener), and the `strict-any-fail-over-declared-deps` readiness aggregation. An optional third path `startup` (default `/startup`) is available under `probeInterface.options.kubernetes.paths.startup`; it is BOUND only when the operator sets `probeInterface.options.kubernetes.startup.enabled: true`, and unset or `false` the profile resolves as before with the two-path set. The startup handler follows the same generation rules as the other Kubernetes-profile handlers: same `{\"status\":\"pass\"|\"fail\"}` body shape, same auth-exempt list emission (the resolved set includes `/startup` when the enable flag is set), same listener topology (fused with the user-traffic listener unless the separate-port option is chosen). The paths, the readiness aggregation, and the startup enablement are overridable at boot via `probeInterface.options.kubernetes.paths`, `probeInterface.options.kubernetes.readinessRule`, and `probeInterface.options.kubernetes.startup.enabled` respectively. The default hits without operator configuration; overriding is a small config change on the same shape.",
+  "consequences": "A project that applies this blueprint and nothing else immediately exhibits a Kubernetes-shaped probe surface at `/live` and `/ready`; the standard `livenessProbe` and `readinessProbe` of shape `httpGet: { path: /live, port: <containerPort> }` and `httpGet: { path: /ready, port: <containerPort> }` in a Kubernetes podspec work without further wiring. The default is scope-local because it is a preference not a contract: the ADR-1501 elicitation model is the global commitment and the Kubernetes profile is one instantiation of it. A project on Docker Compose or on a bare-metal load-balancer setup that runs the shipped default sees `/live` and `/ready` bound instead of `/health` and reads the disagreement as the signal to declare `probeInterface.profile: loadBalancer` at boot. The optional startup path lets a project that owns an initialisation-lifecycle predicate (config load, migrations, cache warm) surface it to the orchestrator without leaving the shipped default; a project without a startup-lifecycle predicate leaves the flag off and sees the two-path default it saw at v1.0.0. Enabling the startup path is a scope-local operator choice, not a shelf-wide contract change; the elicitation model itself (ADR-1501) is unchanged.",
   "alternativesConsidered": [
     {
       "name": "Load-balancer profile as the default",
@@ -26,5 +26,5 @@
     }
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-04T00:00:00Z"
 }

package/blueprints/observability-probe-endpoints/contributions/user-stories/observability-probe-endpoints-us-14102.json

@@ -2,7 +2,7 @@
   "usId": "observability-probe-endpoints-US-14102",
   "prdId": "PRD-001",
   "reqId": "observability-probe-endpoints-REQ-002",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "status": "approved",
   "title": "A Kubernetes-supervised replica is probed at /live and /ready on the request-traffic listener with no operator configuration",
   "asA": "kubelet running a probing loop against a pod that applied the blueprint with no explicit configuration",
@@ -35,6 +35,15 @@
       "then": "the first response has status 200 and body `{\"status\":\"pass\"}`; the second response has status 503 and body `{\"status\":\"fail\"}`",
       "testable": true,
       "scope": "runtime"
+    },
+    {
+      "id": "AC-14102-4",
+      "description": "When the operator sets probeInterface.options.kubernetes.startup.enabled: true on the shipped Kubernetes profile, the resolver returns a three-path set including the startup path (default /startup) and the handler-set builder generates a startup handler that answers pass once the operator-declared startup predicate returns pass and fail otherwise.",
+      "given": "a process on the shipped kubernetes profile with probeInterface.options.kubernetes.startup.enabled set to true, a startup predicate wired against a stubbed initialisation state, and the paths option left at its default",
+      "when": "the resolver runs at boot, and then GETs are issued against /startup with the stubbed state first fail then pass",
+      "then": "the resolver returns { profile: kubernetes, paths: [/live, /ready, /startup] }; the first GET on /startup returns 503 with body {\"status\":\"fail\"}; the second GET on /startup returns 200 with body {\"status\":\"pass\"}; without the enable flag the resolver returns two paths and no /startup handler is registered",
+      "testable": true,
+      "scope": "runtime"
     }
   ],
   "tacIds": [
@@ -42,5 +51,5 @@
     "TAC-1503-observability-probe-endpoints-listener-topology"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-04T00:00:00Z"
 }

package/blueprints/observability-probe-endpoints/contributions/user-stories/observability-probe-endpoints-us-14107.json

@@ -2,7 +2,7 @@
   "usId": "observability-probe-endpoints-US-14107",
   "prdId": "PRD-001",
   "reqId": "observability-probe-endpoints-REQ-007",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "status": "approved",
   "title": "The probe paths sit on the project's auth-exempt list scoped exactly to the resolved set on the resolved listener",
   "asA": "operator running the service behind an auth middleware that rejects unauthenticated requests by default",
@@ -35,11 +35,20 @@
       "then": "the list contains exactly the strings `/live` and `/ready` and their exact-match matcher rule; any injected entry containing `*` or a trailing slash to imply a prefix causes the emitter to refuse with a stable-coded error",
       "testable": true,
       "scope": "runtime"
+    },
+    {
+      "id": "AC-14107-4",
+      "description": "When the optional startup path is enabled on the Kubernetes profile, the exemption list produced by the profile at boot enumerates exactly three exact-match entries /live, /ready and /startup on the resolved listener; a wildcard or prefix entry (a trailing slash implying prefix, an entry containing *) causes the emitter to refuse with the same stable-coded error as AC-14107-3.",
+      "given": "the exemption list produced by the profile resolver on the Kubernetes profile with probeInterface.options.kubernetes.startup.enabled set to true",
+      "when": "the exemption-list emitter runs and the produced entries are inspected, and separately an injected entry containing */ or * is presented",
+      "then": "the list contains exactly the three strings /live, /ready and /startup and their exact-match matcher rule; any wildcard-shaped entry is refused with a stable-coded error",
+      "testable": true,
+      "scope": "runtime"
     }
   ],
   "tacIds": [
     "TAC-1503-observability-probe-endpoints-listener-topology"
   ],
   "createdAt": "2026-08-30T00:00:00Z",
-  "updatedAt": "2026-08-30T00:00:00Z"
+  "updatedAt": "2026-09-04T00:00:00Z"
 }

package/blueprints/observability-probe-endpoints/docs/topics.md

@@ -6,14 +6,14 @@ This file is the observability-probe-endpoints half of the cross-blueprint contr
 
 | Topic string | observability-probe-endpoints contribution | Origin | Composition note |
 |---|---|---|---|
-| `healthProbes` | ADR-1501-observability-probe-endpoints-health-probes | Reused from the observability-essentials vocabulary (observability-essentials contributes a self-supervised two-endpoint HTTP JSON contract on the request-traffic listener at the same topic string). This blueprint contributes an elicit-from-target-integration-profile model on the same topic string on purpose. | The one project-wide decision on the health probe interface. Composing this blueprint with observability-essentials fires a `globalAdrTopic` conflict by design because the two blueprints answer different questions: essentials commits to a self-supervised HTTP JSON floor; this blueprint commits to an elicit-and-adapt model whose shape follows the external supervisor. Expected resolution: one project-level ADR that either commits to the elicit-and-adapt model (external supervisor drives the shape) or the fused self-supervised model (project owns the shape) or an explicit hybrid with boundaries |
-| `readinessSemantics` | ADR-1502-observability-probe-endpoints-readiness-semantics | Reused from the observability-essentials vocabulary (observability-essentials contributes strict-any-fail-over-declared-deps as the project-wide readiness rule at the same topic string). This blueprint contributes per-profile readiness semantics on the same topic string on purpose. | The one project-wide readiness semantics decision. Composing with observability-essentials fires a `globalAdrTopic` conflict by design. Expected resolution: one project-level ADR that commits to one of the two rules or an explicit hybrid |
+| `healthProbes` | ADR-1501-observability-probe-endpoints-health-probes | From essentials v2.0.0 this blueprint is the SOLE shelf-wide claimant of `healthProbes`. Round 2 canon: probes elicited from a target-integration profile; Kubernetes default `/live` + `/ready` on the request-traffic listener. Essentials v2.0.0 (see `projects/rcf-lite-wsd/specs/rcf-lite-probe-path-alignment-spec-2026-09-04.md` section 4) dropped its own scope:global claim on this topic. | Composing this blueprint with observability-essentials v2.0.0 or later fires NO `globalAdrTopic` conflict on `healthProbes`; the resolved profile path binds automatically for essentials on the same project. A composing blueprint that holds a different endpoint contract (a single `/health` endpoint, a gRPC health protocol, probes on a separate admin port) contributes its own scope:global ADR on this string and lets composition surface the pairing. Expected resolution: one project-level ADR that either adopts the composing blueprint or supersedes both |
+| `readinessSemantics` | ADR-1502-observability-probe-endpoints-readiness-semantics | From essentials v2.0.0 this blueprint is the SOLE shelf-wide claimant of `readinessSemantics`. Round 2 canon: per-profile readiness semantics (Kubernetes profile default is strict-any-fail-over-declared-deps). Essentials v2.0.0 dropped its own scope:global claim on this topic (spec section 4). | Composing with observability-essentials v2.0.0 or later fires NO `globalAdrTopic` conflict on `readinessSemantics`. A composing blueprint that holds a different opinion (quorum aggregation, write-path-only readiness, graceful-degradation model) contributes its own scope:global ADR on this string and lets composition surface the pairing |
 
 The observability-probe-endpoints blueprint claims two global topics. Every other contribution is scope-local (ADR-1503 the Kubernetes default, ADR-1504 the separate-port option, and ADR-1505 the external-response secrecy rule do not contribute global topics; a composing blueprint that holds an opinion on the default profile, on probe-listener topology, or on response secrecy authors its own project-level ADR if it wants to override).
 
-Note on the deliberate conflict with observability-essentials: this blueprint is designed for the EXTERNAL-SYSTEM INTEGRATION case (orchestrators, load balancers, uptime monitors probing the service, with their conventions driving the wire shape). observability-essentials is designed for the SELF-SUPERVISED all-in-one case (probes plus public status page plus notification outcome sink for a project that designs its own observability floor). Both are legitimate; each is the right default for its case. The conflict is the mechanism telling the operator to pick one intentionally. Precedent for the vendor-sibling pattern: security-auth-clerk conflicts with security-auth-magic-link on `authModel` on purpose; persistence-data-d1 conflicts with persistence-data-sqlite on both `persistenceStore` and `migrationDiscipline` on purpose. This blueprint follows the same pattern on `healthProbes` and `readinessSemantics`.
+Note on the delineation with observability-essentials from essentials v2.0.0: essentials contributes the body shape, dep registry, probe-secrecy rule, status page and notification sink; this blueprint contributes the path binding and profile elicitation. The two compose without a conflict on `healthProbes` or `readinessSemantics` from essentials v2.0.0 forward (this blueprint is the sole claimant on both). Precedent for the deliberate-conflict pattern still stands on other topic pairs: security-auth-clerk conflicts with security-auth-magic-link on `authModel` on purpose; persistence-data-d1 conflicts with persistence-data-sqlite on both `persistenceStore` and `migrationDiscipline` on purpose.
 
-Note on the delineation from observability-essentials's `statusPageContract` topic: this blueprint does not contribute an opinion on the public status page. A project that wants the probe surface from this blueprint AND the public status page and notification outcome sink from observability-essentials resolves the two `healthProbes` and `readinessSemantics` conflicts with project-level ADRs and keeps `statusPageContract` on the essentials-supplied side; the blueprints then compose without further conflict.
+Note on the delineation from observability-essentials's `statusPageContract` topic: this blueprint does not contribute an opinion on the public status page. A project that wants the probe surface from this blueprint AND the public status page and notification outcome sink from observability-essentials composes the two cleanly from essentials v2.0.0 forward; `statusPageContract` stays on the essentials-supplied side and no probe-path or readiness-semantics conflict fires.
 
 Rules for new topics (inherited from the application-spa, application-api-rest, security-auth-magic-link, persistence-data-sqlite, delivery-ci-workflows, observability-essentials, security-secrets-management, security-auth-clerk, email-smtp-resend, and deploy-cloudflare-workers vocabularies, restated as law): lower camel case, one concept per topic, no version suffixes. A topic names the decision area, not the chosen answer. Do not mint variants of existing strings (`probeInterface`, `probeSurface`, `probes`, `livenessReadiness`, `probeTransport` are all wrong when `healthProbes` already exists; `readinessAggregation`, `readyPolicy`, `readinessRule` are all wrong when `readinessSemantics` already exists).
 
@@ -32,14 +32,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 14101-14108 sit at the LOW end of the 14101-14899 band on purpose. A project-side story that mechanically derives from an observability-probe-endpoints REQ id into the number `14108` would collide against observability-probe-endpoints-US-14108 in this package; the band leaves headroom at the HIGH end (US 14181-14899) so a project's own stories anchored to observability-probe-endpoints REQs can allocate without conflict. The watchpost run4 lesson applies here too. Band spacing between the previous HQ-lane row (persistence-data-d1, 13101-13899, 14xx) and this one (14101-14899, 15xx) reflects the four-digit widening pattern opened by security-auth-clerk at 10xx and continued through the round-2 HQ lane.
 

package/blueprints/observability-probe-endpoints/guide/observability-probe-endpoints.md

@@ -81,3 +81,13 @@ A project applies the observability-probe-endpoints blueprint on a fresh tree, d
 ## Cost-honesty paragraph
 
 Shipping this doc set costs the project the following. Every process pays the profile-resolver step at boot and one indirection through the frozen profile object at each probe binding site; the cost is small but real. A project that wants hot-reload of the profile selection restarts the process gracefully; the blueprint declines to support live rebinding. The separate-port topology opens a second HTTP listener when in effect; the extra port is a small memory cost and one more thing to think about in the deployment substrate. The profile-swap-is-config invariant costs the project a small amount of author discipline: per-profile branching in the boot path outside the resolver call site would defeat the invariant, and the AC scan catches the drift only if the project wires it into its own CI. The response-minimalism-by-construction rule costs the project any richer probe body it may have wanted for its own consumption (that surface belongs to observability-essentials, to an authenticated dashboard, or to a project-side triage endpoint outside the probe path set). The blueprint says nothing about the public status page, the notification outcome sink, metrics export, distributed tracing, or the auth model itself; a project that needs any of those spends its own build cycles on them and this blueprint does not save it any work there.
+
+## Composing with observability-essentials and application-api-rest
+
+From v1.1.0 this blueprint is the single owner of probe-path binding on the core shelf. The composition is documented in the ratified rcf-lite probe-path alignment spec (`projects/rcf-lite-wsd/specs/rcf-lite-probe-path-alignment-spec-2026-09-04.md`) and verified by the compose test at `packages/rcf-lite/test/blueprint/probe-path-alignment.test.js`.
+
+- observability-essentials (v2.0.0 and up) contributes body shape, dep registry, probe-secrecy, status page, and notification sink; it defers path binding to this blueprint when composed, and reads `probeInterface.paths` from project configuration when it is applied alone. Its `healthProbes` and `readinessSemantics` global claims were dropped in v2.0.0; this blueprint is now the sole `scope: global` claimant on both topics.
+- application-api-rest (v2.0.0 and up) contributes the request pipeline, auth middleware, error envelope, versioning, logging, migrations and meta endpoint; it defers probe paths to this blueprint (including the optional startup path). Its auth-middleware installer consumes the exempt path set this blueprint emits and no other; adjacent routes never fall under the same exemption.
+- The three-way compose test at `packages/rcf-lite/test/blueprint/probe-path-alignment.test.js` is the ratified truth for this shelf-alignment surface. Every ordering of the three blueprints applies cleanly; there is exactly one `scope: global` ADR per topic in the resulting manifest; no literal `/healthz`, `/readyz`, `/healthz/live`, `/healthz/ready` or `/healthz/startup` string appears outside this blueprint's own README and guide prose.
+
+Enabling the optional startup path costs one line of configuration: `probeInterface.options.kubernetes.startup.enabled: true`. The resolver emits a three-path set (`/live`, `/ready`, `/startup`) and the handler-set builder generates a startup handler that answers pass once the operator-declared startup predicate returns pass. api-rest projects that own an initialisation-lifecycle predicate (config load, migrations, cache warm) wire it here; projects that do not, leave the flag off and see the two-path default.

package/blueprints/persistence-data-d1/docs/topics.md

@@ -30,14 +30,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 13101-13107 sit at the LOW end of the 13101-13899 band on purpose. A project-side story that mechanically derives from a persistence-data-d1 REQ id into the number `13107` would collide against persistence-data-d1-US-13107 in this package; the band leaves headroom at the HIGH end (US 13181-13899) so a project's own stories anchored to persistence-data-d1 REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/persistence-data-sqlite/docs/topics.md

@@ -30,14 +30,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 5101-5111 sit at the LOW end of the 5101-5899 band on purpose. A project-side story that mechanically derives from `persistence-data-sqlite-REQ-011` into the number `5111` would collide against persistence-data-sqlite-US-5111 in this package; the band leaves headroom at the HIGH end (US 5181-5899) so a project's own stories anchored to persistence-data-sqlite REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-clerk/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 9101-9110 sit at the LOW end of the 9101-9899 band on purpose. A project-side story that mechanically derives from a security-auth-clerk REQ id into the number `9110` would collide against security-auth-clerk-US-9110 in this package; the band leaves headroom at the HIGH end (US 9181-9899) so a project's own stories anchored to security-auth-clerk REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-keycloak/docs/topics.md

@@ -38,14 +38,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 11101-11113 sit at the LOW end of the 11101-11899 band on purpose. A project-side story that mechanically derives from a security-auth-keycloak REQ id into the number `11113` would collide against security-auth-keycloak-US-11113 in this package; the band leaves headroom at the HIGH end (US 11181-11899) so a project's own stories anchored to security-auth-keycloak REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-magic-link/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 3101-3111 sit at the LOW end of the 3101-3899 band on purpose. A project-side story that mechanically derives from `security-auth-magic-link-REQ-011` into the number `3111` would collide against security-auth-magic-link-US-3111 in this package; the band leaves headroom at the HIGH end (US 3181-3899) so a project's own stories anchored to security-auth-magic-link REQs can allocate without conflict.
 

package/blueprints/security-auth-oauth2/docs/topics.md

@@ -38,14 +38,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 10101-10111 sit at the LOW end of the 10101-10899 band on purpose. A project-side story that mechanically derives from a security-auth-oauth2 REQ id into the number `10111` would collide against security-auth-oauth2-US-10111 in this package; the band leaves headroom at the HIGH end (US 10181-10899) so a project's own stories anchored to security-auth-oauth2 REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-secrets-management/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 8101-8110 sit at the LOW end of the 8101-8899 band on purpose. A project-side story that mechanically derives from a security-secrets-management REQ id into the number `8110` would collide against security-secrets-management-US-8110 in this package; the band leaves headroom at the HIGH end (US 8181-8899) so a project's own stories anchored to security-secrets-management REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/fixtures/canary-manifest.json

@@ -1,9 +1,9 @@
 {
   "registerCanary": [
     {
-      "id": "rc-2026-09-03-001",
-      "createdAt": "2026-09-03T13:16:14.200Z",
-      "buildVersion": "0.16.0-mockdriver",
+      "id": "rc-2026-09-04-001",
+      "createdAt": "2026-09-04T12:13:52.789Z",
+      "buildVersion": "0.18.0-mockdriver",
       "fixturePromptId": "canary-prompt-01",
       "responseWordCount": 55,
       "grades": {
@@ -34,9 +34,9 @@
       "shipDespiteFailReason": "mock canary driver used; no real subagent was dispatched. This record verifies canary infrastructure only, not the register itself."
     },
     {
-      "id": "rc-2026-09-03-002",
-      "createdAt": "2026-09-03T13:16:14.200Z",
-      "buildVersion": "0.16.0-mockdriver",
+      "id": "rc-2026-09-04-002",
+      "createdAt": "2026-09-04T12:13:52.790Z",
+      "buildVersion": "0.18.0-mockdriver",
       "fixturePromptId": "canary-prompt-02",
       "responseWordCount": 55,
       "grades": {
@@ -67,9 +67,9 @@
       "shipDespiteFailReason": "mock canary driver used; no real subagent was dispatched. This record verifies canary infrastructure only, not the register itself."
     },
     {
-      "id": "rc-2026-09-03-003",
-      "createdAt": "2026-09-03T13:16:14.201Z",
-      "buildVersion": "0.16.0-mockdriver",
+      "id": "rc-2026-09-04-003",
+      "createdAt": "2026-09-04T12:13:52.790Z",
+      "buildVersion": "0.18.0-mockdriver",
       "fixturePromptId": "canary-prompt-03",
       "responseWordCount": 55,
       "grades": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rcf-lite",
-  "version": "0.16.0",
+  "version": "0.18.0",
   "type": "module",
   "description": "One-install tooling for the Requirements Confidence Framework (RCF): the unified `rcf` CLI grouped into the five RCF tool groups (discover, define, build, verify, audit) plus a small core set (init, doctor, guidance, mcp), an MCP server, the live tree viewer and the fresh-context adversarial ship-gate verifier. Consumes @stravica-ai/rcf-schemas.",
   "license": "Apache-2.0",
@@ -69,6 +69,18 @@
     "js-yaml": "^4.1.0",
     "mermaid": "11.6.0"
   },
+  "peerDependencies": {
+    "@playwright/mcp": ">=0.0.40",
+    "playwright": ">=1.50.0"
+  },
+  "peerDependenciesMeta": {
+    "@playwright/mcp": {
+      "optional": true
+    },
+    "playwright": {
+      "optional": true
+    }
+  },
   "scripts": {
     "test": "node --test --test-concurrency=1 'test/**/*.test.js'",
     "vendor": "node scripts/vendor-mermaid.mjs",

package/rcf/code-nodes/cn-070.json

@@ -0,0 +1,12 @@
+{
+  "cnId": "CN-070",
+  "path": "src/verify/engine/launcher.js#PLAYWRIGHT_MCP_VERSION",
+  "title": "Pinned Playwright MCP version + composer",
+  "description": "Exports the PLAYWRIGHT_MCP_VERSION constant, the playwrightMcpConfig(version) composer, and the isSemverString(value) guard the CLI's override uses. DEFAULT_MCP_CONFIG is composed from PLAYWRIGHT_MCP_VERSION so nothing in the module surfaces @playwright/mcp@latest. The exported constant + composer are what src/verify/cli/run.js reuses when --playwright-mcp-version fires, and what src/verify/engine/index.js reads when it threads the effective pin into report.run.runStats.playwrightMcpVersion.",
+  "implementsAcIds": ["AC-1101-1", "AC-1101-2", "AC-1101-3", "AC-1101-4"],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-03T17:00:00Z",
+  "updatedAt": "2026-09-03T17:00:00Z"
+}

package/rcf/code-nodes/cn-071.json

@@ -0,0 +1,12 @@
+{
+  "cnId": "CN-071",
+  "path": "test/blueprint/apply-spa-v1-4-0-schema.test.js",
+  "title": "Application-spa v1.4.0 browserSurface + browser-facing user stories + e2e template",
+  "description": "The SPA blueprint at 1.4.0 declares the top-level browserSurface object and contributes application-spa-US-1134 (icon on the home route) and application-spa-US-1135 (unauthenticated protected route lands on sign-in) as browser-facing acceptance criteria. blueprints/application-spa/assets/tc-templates/e2e.md ships as the paste-in test-case template naming rcf verify browser as the driver seam. blueprints/delivery-ci-workflows/blueprint.json bumps to 2.2.0 with US-6124 binding AC-6124-1 on the elicited e2e check, plus the illustrative e2e job in pull-request-checks.yml and the alternate-provider notes. The applied SPA v1.4.0 manifest still validates against rcf-schemas 0.5.1 (test/blueprint/apply-spa-v1-4-0-schema.test.js) with no browserSurface field on the applied blueprint record; doctor and any future workflow-materialiser read browserSurface off the applied record's source reference.",
+  "implementsAcIds": ["AC-1102-1", "AC-1102-2", "AC-1102-3", "AC-1102-4", "AC-1102-5"],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-03T17:00:00Z",
+  "updatedAt": "2026-09-03T17:00:00Z"
+}

package/rcf/code-nodes/cn-072.json

@@ -0,0 +1,12 @@
+{
+  "cnId": "CN-072",
+  "path": "src/setup/playwright-checks.js#loadBrowserFacingSources",
+  "title": "Doctor's browser-facing projection + four Playwright checks",
+  "description": "loadBrowserFacingSources(projectRoot) walks manifest.blueprints[].source, reads each blueprint.json, and returns { browserFacing, sources[] } (spec 3.1). checkPlaywrightPresent(projectRoot) uses require.resolve('playwright'); checkBrowserPresent() probes PATH for chrome/chromium then ~/.cache/ms-playwright then `npx --no-install @playwright/mcp browser-status --json`; checkPlaywrightMcpReachable() spawns `npx --no-install @playwright/mcp --help` with a 15-second diagnostic ceiling. hasPlaywrightSignature + findProjectPlaywrightKey are the shared signature detectors doctor's redundant-entry check and init's project-scope probe consume. FIX_LINES exports the spec-verbatim fix lines; SKIP_LINE_NON_BROWSER_FACING is the single skip line for non-browser-facing projects. src/cli/doctor.js wires the four checks into KNOWN_CHECKS, honours the --check filter override on API-only projects (spec 3.5), and prints the skip line before the summary (spec 3.4).",
+  "implementsAcIds": ["AC-1103-1", "AC-1103-2", "AC-1103-3", "AC-1103-4"],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-03T17:00:00Z",
+  "updatedAt": "2026-09-03T17:00:00Z"
+}