rcf-lite 0.17.0 → 0.19.0

package/blueprints/observability-logging/contributions/user-stories/observability-logging-us-15108.json

@@ -0,0 +1,25 @@
+{
+  "usId": "observability-logging-US-15108",
+  "prdId": "PRD-001",
+  "reqId": "observability-logging-REQ-003",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "A redaction category unknown to the boundary is refused at configuration time rather than silently ignored",
+  "asA": "operator elicited into ADR-1603 with a mis-spelled additional category name",
+  "iWant": "the factory to refuse the redaction category at configuration time with a message naming the offending value",
+  "soThat": "a typo in an added category does not silently disable redaction for that field pattern",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-15108-1",
+      "description": "The factory's redaction configuration accepts kebab-cased or dotted-namespace category names (matching the ADR-1603 recommended-default shape) and refuses any other shape with a message naming the offending value and the accepted grammar.",
+      "given": "an application configured with a redaction categories list including 'PII Email' (space, mixed case)",
+      "when": "the factory is constructed",
+      "then": "construction throws with a message naming 'PII Email' as the offending value",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": ["TAC-1602-observability-logging-redaction-boundary"],
+  "createdAt": "2026-09-04T12:20:00Z",
+  "updatedAt": "2026-09-04T12:20:00Z"
+}

package/blueprints/observability-logging/docs/topics.md

@@ -0,0 +1,21 @@
+# observability-logging: coordination vocabulary
+
+## Global topics
+
+| Topic | Owning ADR | Meaning | Composition note |
+|---|---|---|---|
+| `logging` | `ADR-1601-observability-logging-line-shape` | Structured single-line JSON emission contract with the shared minimum field set. | Shelf-canonical claim from v1.0.0. A composing blueprint that ships a different logging contract (structured multi-line, per-service special format, non-JSON) conflicts by design; the operator resolves at project level via `rcf define blueprint supersede logging --incoming <source>`. A library-registered logging provider (wsd-logging, acme-log-emit) is preferred over this shelf provider by the companion-suggestion mechanism. |
+
+## Deliberately unclaimed topics
+
+- `logRedaction` (text-level redaction of the `message` string). Named here so a future companion blueprint can claim it cleanly; this blueprint's redaction is field-name granularity per ADR-1603.
+- `logTransport` (the transport downstream of stdout). Owned by the surrounding platform; a future blueprint may claim it if the shelf ever ships one.
+- `logMetricsBridge` (emitting log-derived metrics). Named here so a future `metrics-store` companion can claim it cleanly.
+
+## Shelf id band and suffix block
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| observability-logging | 15101-15899 | 16xx | shipped v1.0.0 | `logging` |
+
+The shelf-wide band registry lives in `packages/rcf-lite/docs/blueprint-authoring.md` section 5.

package/blueprints/observability-logging/guide/observability-logging.md

@@ -0,0 +1,36 @@
+# Guide: observability-logging (v1.0.0)
+
+## What it is
+
+A shipped, org-neutral logging contract for a rcf-lite project. Every log emission lands as one JSON object per line on stdout with a shared field set the applying operator's ingestion pipeline can consume without a per-service parser. Correlation identifiers propagate through the request-scoped context and reflect on outbound requests. A field-name redaction boundary keeps PII out of emitted lines by rule, not by hope. The operator elicits the correlation header name, the redaction category additions and the minimum level per environment at apply.
+
+## What it deliberately is not
+
+- Not a log transport. The blueprint ships to stdout; the applying platform pipes it into whatever ingestion service the operator chose. Elastic Common Schema, Loki, Datadog and Splunk all consume one JSON object per line without a per-blueprint adapter.
+- Not a metrics or tracing surface. Metrics belong to a future `metrics-store` companion; tracing belongs to a distributed-tracing companion. This blueprint contributes neither.
+- Not a text-level PII scrubber. Redaction is field-name granularity per ADR-1603; a PII value concatenated into the `message` string is not caught.
+
+## When to reach for it
+
+- Any project that has not yet applied a logging companion. Applying this blueprint gives a working structured emission surface without registering a library.
+- Any project whose applied service blueprints (application-api-rest, application-spa) declare `suggestedCompanions: ["logging"]` and no more specific library provides the role.
+
+## When it does not fit
+
+- A project standing on an organisation with a shipped logging library (`wsd-logging`, `acme-log-emit`) that provides the `logging` role. Register the library and the companion-suggestion mechanism resolves to the library's provider over this shelf fallback.
+- A project that needs multi-line stack trace emission for a legacy consumer. This blueprint ships single-line JSON only; a project-level `logging` topic supersede lets the project author a different contract.
+
+## What a good outcome looks like
+
+- One JSON object per line on stdout, correlation identifier threaded across services, PII fields redacted at the boundary, level filter honoured per environment, in-memory capture mode used in tests. `rcf define validate` clean; log ingestion pipeline queries partition cleanly by environment, serviceName and serviceVersion.
+
+## The operator decisions that remain open
+
+- **The inbound correlation header name** (ADR-1602). Recommended default `X-Correlation-Id`; elicited alternative per project. Set the value the surrounding platform's proxy or client tooling already stamps.
+- **The redaction categories additions** (ADR-1603). Recommended defaults cover the six common cases; a project with a domain-specific field (ssn, iban, jwt) adds it at apply.
+- **The minimum log level per environment** (ADR-1604). Recommended vocabulary is trace / debug / info / warn / error / fatal; elicited minimum per environment. Production is typically info; development is typically debug or trace.
+- **The log transport downstream of stdout.** Out of scope for this blueprint; the surrounding platform's pipe wires ingestion.
+
+## Cost-honesty
+
+Applying this blueprint adds five REQs, eight USs, two TACs and four ADRs to the project's chain. The runtime cost is one factory per boot plus one redaction pass per emission. There is no runtime dependency added to the project's `package.json`; the factory is authored against the applying project's own runtime. The main hidden cost is the discipline of routing every emission through the factory: the guide's `Known mechanism-reach gaps` section names the class and the project-side workarounds.

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.