rcf-lite 0.12.0 → 0.14.0

package/blueprints/observability-essentials/contributions/user-stories/observability-essentials-us-7105.json

@@ -0,0 +1,45 @@
+{
+  "usId": "observability-essentials-US-7105",
+  "prdId": "PRD-001",
+  "reqId": "observability-essentials-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "External reader sees an active incident notice on the status page during an outage",
+  "asA": "external reader visiting the status page during an active incident",
+  "iWant": "the page to surface active incident notices with a stable structure the operator has populated",
+  "soThat": "I see what the operator has said about the incident, when it started, and how bad it is, without hunting for a Twitter thread",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-7105-1",
+      "description": "When one or more incident notices are active, the status page renders a notices region above the component list; each notice is a distinct element carrying title, body, severity, startedAt and (optionally) componentIds as machine-readable fields.",
+      "given": "the operator has posted two active incident notices, one with componentIds referencing two declared components and one without",
+      "when": "the status page is rendered and the notices region is queried",
+      "then": "the notices region contains exactly two notice elements, each with a title field, a body field, a severity field, and a startedAt field; the first notice element carries a componentIds field naming the two referenced components, the second notice element either omits the componentIds field or renders it as an empty list",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7105-2",
+      "description": "The severity field on each notice is one of a fixed enum (info, warning, critical); no other value is renderable.",
+      "given": "notices exist at each of the three severities",
+      "when": "the status page is rendered and every notice element's severity field is inspected",
+      "then": "every severity value is one of info, warning, or critical; no notice renders with any other severity value",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7105-3",
+      "description": "When no notices are active, the notices region is either absent from the rendered document or clearly labelled as empty; no stale notice from a resolved incident appears.",
+      "given": "the operator has resolved every previously active incident and no notice is currently active",
+      "when": "the status page is rendered",
+      "then": "the rendered document either contains no notices region element or contains a notices region element carrying an emptyState marker; no notice element from any previously active incident is present",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-803-observability-essentials-status-page"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/observability-essentials/contributions/user-stories/observability-essentials-us-7106.json

@@ -0,0 +1,45 @@
+{
+  "usId": "observability-essentials-US-7106",
+  "prdId": "PRD-001",
+  "reqId": "observability-essentials-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Operator answers 'did the customer get the notification' from the outcome sink",
+  "asA": "operator investigating a customer report of a missing notification (email, SMS, push, webhook)",
+  "iWant": "every notification attempt to record an outcome on a durable sink queryable by recipient and time window",
+  "soThat": "I answer whether the outcome was delivered, failed, pending, or suppressed without hunting a provider dashboard",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-7106-1",
+      "description": "Every notification attempt writes exactly one outcome record to the durable outcome sink before the attempting code returns; the record carries notificationId, channel, recipient, outcome, attemptedAt, and (when outcome is failed) errorCode fields.",
+      "given": "the process is instrumented to attempt one notification per invocation across each declared channel",
+      "when": "an attempt is invoked and returns, and the sink is queried for that notificationId",
+      "then": "the sink returns exactly one record for that notificationId with all required fields populated, and the record's attemptedAt is no later than the return time of the attempt call",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7106-2",
+      "description": "The outcome field is one of a fixed enum (delivered, failed, pending, suppressed); the channel field is one of a fixed enum declared in configuration (email, sms, push, webhook, or the project's declared channel set).",
+      "given": "the process attempts notifications across every declared channel including deliberately-failing and deliberately-suppressed cases",
+      "when": "the sink is queried for the attempt records",
+      "then": "every record's outcome field is one of delivered, failed, pending, or suppressed, and every record's channel field is a member of the declared channel enum",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7106-3",
+      "description": "The operator queries the sink by recipient identifier and time window and receives the outcome records that match; a recipient with no attempts in the window returns an empty result rather than an error.",
+      "given": "the sink holds outcome records across a mix of recipients and time windows",
+      "when": "the operator issues a query for a recipient identifier within a bounded time window",
+      "then": "the returned result set contains every outcome record whose recipient equals the queried recipient and whose attemptedAt is within the window, and a query for a recipient with zero matching records returns an empty result set",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-804-observability-essentials-notification-outcome"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/observability-essentials/contributions/user-stories/observability-essentials-us-7107.json

@@ -0,0 +1,46 @@
+{
+  "usId": "observability-essentials-US-7107",
+  "prdId": "PRD-001",
+  "reqId": "observability-essentials-REQ-007",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Monitoring integration consumes the probe JSON body without hand-parsing HTML",
+  "asA": "third-party monitoring integration or dashboard consuming the application's probe endpoints",
+  "iWant": "a stable JSON response shape from both probes with stable field names and an ISO-8601 timestamp on every response",
+  "soThat": "I wire the integration once and it does not break when a patch release ships",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-7107-1",
+      "description": "Both probe responses declare Content-Type application/json; both bodies parse as JSON and contain a status field (pass or fail) and a checkedAt field with a parseable ISO-8601 timestamp.",
+      "given": "the process is running and both probes are reachable",
+      "when": "GETs are issued against each probe path and each response body is JSON-parsed",
+      "then": "each response has Content-Type application/json, each body parses without error, each parsed body has a status field valued pass or fail, and each body has a checkedAt field that parses as a valid ISO-8601 date-time",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7107-2",
+      "description": "The readiness body carries a checks object keyed by declared dependency name; the liveness body has no checks field.",
+      "given": "the process has declared a readiness dependency set and both probes are reachable",
+      "when": "the two probe response bodies are compared",
+      "then": "the readiness body contains a checks object with one entry per declared readiness dependency, and the liveness body contains no checks field",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7107-3",
+      "description": "Field names on both probe response bodies are stable across the blueprint's version series: a patch or minor release does not rename status, checkedAt, or checks.",
+      "given": "the blueprint at v1.0.0 declares its probe body field names",
+      "when": "a project inspects the field names on both probe bodies at v1.0.0 and again at any subsequent v1.x.y release",
+      "then": "the top-level field names status, checkedAt, and checks (readiness only) are present at both versions with the same casing and the same value shapes; a rename would require a major version bump per the blueprint's own versioning policy",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-801-observability-essentials-liveness-probe",
+    "TAC-802-observability-essentials-readiness-probe"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/observability-essentials/contributions/user-stories/observability-essentials-us-7108.json

@@ -0,0 +1,47 @@
+{
+  "usId": "observability-essentials-US-7108",
+  "prdId": "PRD-001",
+  "reqId": "observability-essentials-REQ-008",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Orchestrator and external reader reach probes and status page without credentials",
+  "asA": "orchestrator, load balancer, or external reader that has no service credentials",
+  "iWant": "the liveness path, readiness path, and status page path to be exempt from every authentication gate the application applies to other paths",
+  "soThat": "the probes are usable by the systems that operate the deployment and the status page is usable by the readers it is written for",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-7108-1",
+      "description": "The liveness, readiness, and status page paths respond to a GET carrying no cookie, no Authorization header, and no session token, with a 2xx response (or a 5xx that reflects the probe answer, not an auth challenge); no path returns 401 or 403 to an unauthenticated request.",
+      "given": "the process is running with the application's normal authentication middleware active",
+      "when": "unauthenticated GETs are issued against each of the three paths in turn",
+      "then": "no response carries status code 401 or 403 and none carries a WWW-Authenticate response header; each response is either a 2xx probe pass, a 5xx probe fail, or a 2xx status page",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7108-2",
+      "description": "The three paths are declared at boot as auth-exempt in the application's authentication middleware; the exempt list is inspectable from the running process (through configuration read or a debug endpoint operators use in staging).",
+      "given": "the process is running with an auth-exempt path list declared in configuration",
+      "when": "the running process's exempt list is inspected",
+      "then": "the list contains the three configured paths (liveness, readiness, status page) and no others that were not deliberately declared",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7108-3",
+      "description": "A request that carries valid authentication credentials against one of the three exempt paths still receives the probe or status-page response; the exemption is one-directional (auth not required), not one that refuses authenticated callers.",
+      "given": "the process is running with valid credentials available to the caller",
+      "when": "an authenticated GET is issued against each of the three exempt paths",
+      "then": "each response is identical in shape and status code to the unauthenticated case; no path refuses the authenticated caller",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-801-observability-essentials-liveness-probe",
+    "TAC-802-observability-essentials-readiness-probe",
+    "TAC-803-observability-essentials-status-page"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/observability-essentials/contributions/user-stories/observability-essentials-us-7109.json

@@ -0,0 +1,45 @@
+{
+  "usId": "observability-essentials-US-7109",
+  "prdId": "PRD-001",
+  "reqId": "observability-essentials-REQ-009",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "External reader never sees internal identifiers, metric values, or dependency names on the status page",
+  "asA": "security-conscious external reader (and the security reviewer for the deployed application)",
+  "iWant": "the public status page to expose only the declared component vocabulary and the incident notice fields",
+  "soThat": "internal topology and performance detail is not committed as public contract and does not become reconnaissance material for a targeted attack",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-7109-1",
+      "description": "The rendered status page contains no host identifiers, no replica identifiers, no database identifiers, no queue names, no internal URLs, and no build hashes anywhere in its markup or its script tags; a grep of the fully-rendered document for a known internal identifier of each class returns zero matches.",
+      "given": "the running process has known values for each identifier class (host name H, replica id R, database identifier D, queue name Q, internal URL U, build hash B)",
+      "when": "the fully-rendered status page document is fetched and grepped for each of H, R, D, Q, U, and B",
+      "then": "every grep returns zero matches, including inside script tags and inline JSON payloads",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7109-2",
+      "description": "The rendered status page contains no raw metric values: no request counts, no latency numbers, no error rates, no queue depths appear as text or as data attributes.",
+      "given": "the running process is emitting internal metrics with known non-zero values",
+      "when": "the rendered status page document is inspected for numeric content outside the incident notice startedAt timestamps",
+      "then": "no metric value from the internal metric surface appears as text content or data attribute on any element",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7109-3",
+      "description": "The readiness probe body may name declared dependencies (that is its purpose); the status page must not name them. The declared-component vocabulary and the declared-readiness-dependency vocabulary are distinct sets, and no declared readiness dependency name appears on the public status page.",
+      "given": "the process declares a readiness dependency set with distinct names from the declared status-page component set",
+      "when": "the public status page is fetched and grepped for each declared readiness dependency name",
+      "then": "every grep returns zero matches; a grep of the readiness probe body for the same names returns non-zero matches, demonstrating the surfaces are distinct",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-803-observability-essentials-status-page"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

package/blueprints/observability-essentials/contributions/user-stories/observability-essentials-us-7110.json

@@ -0,0 +1,46 @@
+{
+  "usId": "observability-essentials-US-7110",
+  "prdId": "PRD-001",
+  "reqId": "observability-essentials-REQ-010",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "Probes stay responsive under a downstream dependency outage",
+  "asA": "operator whose downstream dependency has gone slow or unresponsive",
+  "iWant": "the readiness probe to answer within its declared budget even when a declared dependency is hanging on network calls",
+  "soThat": "a downstream partial outage does not cause the load balancer to time out the probe and cascade the failure into every replica going unready simultaneously",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-7110-1",
+      "description": "The readiness probe handler returns a response within the readiness evaluation budget declared in configuration (default 1 second) regardless of the responsiveness of any declared dependency; the handler reads a cached last-known state populated by a background evaluator, never issues a synchronous network round trip to a dep from inside the handler.",
+      "given": "a declared readiness dependency's real endpoint is configured to hang indefinitely (a network sink with no responder)",
+      "when": "a GET is issued against the readiness path and the response time is measured",
+      "then": "the response arrives within the declared readiness evaluation budget (default 1 second) and the response's checks entry for the hanging dependency shows state fail with a checkedAt that reflects the last background evaluation attempt, not the current probe-hit time",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7110-2",
+      "description": "The background dep-health evaluator runs on its own cadence, declared in configuration; every declared readiness dependency is evaluated at least once per cadence interval regardless of the state of any other dependency.",
+      "given": "the process is running with N declared dependencies including one that hangs and the background evaluator cadence declared as C seconds",
+      "when": "the process runs for at least 3 * C seconds and each dependency's checkedAt timestamp is sampled from the readiness body",
+      "then": "every non-hanging dependency's checkedAt advances at least twice within the window; the hanging dependency's checkedAt advances or its state transitions to fail with a checkedAt that reflects the evaluator's own attempt time, and no other dependency's evaluation is starved by the hanging one",
+      "testable": true,
+      "scope": "runtime"
+    },
+    {
+      "id": "AC-7110-3",
+      "description": "The liveness probe handler under the same hanging-dependency conditions still returns 200 within a bounded budget (default 250 milliseconds), demonstrating that liveness is decoupled from downstream dep health.",
+      "given": "a declared readiness dependency is hanging and the readiness probe is returning 503",
+      "when": "a GET is issued against the liveness path and the response time is measured",
+      "then": "the response status is 200, the response body's status field is pass, and the response arrives within 250 milliseconds",
+      "testable": true,
+      "scope": "runtime"
+    }
+  ],
+  "tacIds": [
+    "TAC-801-observability-essentials-liveness-probe",
+    "TAC-802-observability-essentials-readiness-probe"
+  ],
+  "createdAt": "2026-08-24T00:00:00Z",
+  "updatedAt": "2026-08-24T00:00:00Z"
+}

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

@@ -0,0 +1,57 @@
+# observability-essentials blueprint coordination vocabulary
+
+This file is the observability-essentials half of the cross-blueprint contract. The Phase 1 conflict detector matches scope:global ADR topics by EXACT string equality, and AC ids are unnamespaced by the 0.4.4 grammar. Any blueprint intended to compose with this one must reuse these exact strings and respect these bands.
+
+## Global ADR topics this blueprint contributes (exact strings)
+
+| Topic string | observability-essentials contribution | Origin | Composition note |
+|---|---|---|---|
+| `healthProbes` | ADR-801-observability-essentials-health-probes | Minted here; pre-cleared as unclaimed against application-spa (`clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel`), application-api-rest (`errorEnvelope`, `authModel`, `apiVersioning`, `logging`), security-auth-magic-link (`authModel`), persistence-data-sqlite (`persistenceStore`, `migrationDiscipline`), delivery-ci-workflows (`ciGates`, `strictCoverageGate`), and the hello-panel walkthrough exemplar (`operatorPanel`) | The one HTTP health probe contract for the project: two endpoints (liveness /healthz, readiness /readyz), shared JSON body shape, served on the request-traffic listener. A composing blueprint that holds a different endpoint contract (a single /health endpoint, gRPC health protocol, probes on a separate admin port) contributes its own scope:global ADR on this exact string and lets composition surface the pairing. Expected resolution: one project-level ADR that fixes the endpoint contract |
+| `readinessSemantics` | ADR-802-observability-essentials-readiness-semantics | Minted here; pre-cleared as unclaimed against application-spa, application-api-rest, security-auth-magic-link, persistence-data-sqlite, delivery-ci-workflows, and hello-panel | The one readiness aggregation and declaration scope for the project: strict-any-fail over an explicit boot-time-declared dependency set, evaluated against per-dep cached state. A composing blueprint that holds a different opinion (quorum aggregation, write-path-only readiness, graceful-degradation model) conflicts here by design. Expected resolution: one project-level ADR fixing the semantics |
+| `statusPageContract` | ADR-803-observability-essentials-status-page-contract | Minted here; pre-cleared as unclaimed against application-spa, application-api-rest, security-auth-magic-link, persistence-data-sqlite, delivery-ci-workflows, and hello-panel | The one public status page contract for the project: declared component list plus fixed state enum plus stable-fielded incident notices. A composing blueprint that wants a different public contract (JSON endpoint at /status.json, historical uptime cells as v1 requirement, webhook-posted notices) conflicts here by design. Expected resolution: one project-level ADR fixing the public contract |
+
+The observability-essentials blueprint claims three global topics. Every other contribution is scope-local (ADR-804 probe secrecy and ADR-805 notification outcome model do not contribute global topics; a composing blueprint that holds an opinion on probe auth policy or notification outcome shape authors its own project-level ADR if it wants to override).
+
+Note on the delineation from the hello-panel walkthrough's `operatorPanel` topic: `operatorPanel` (owned by the hello-panel walkthrough exemplar) governs the project's PRIMARY operator drift-detection surface, an AUTHENTICATED surface for the operator. This blueprint's status page (ADR-803) governs the PUBLIC status surface for external readers. The two surfaces are deliberately distinct in audience and vocabulary; this blueprint MUST NOT touch `operatorPanel` and does not contribute an ADR on it.
+
+Note on the delineation from the application-api-rest blueprint's `logging` topic: `logging` (owned by application-api-rest ADR-304) governs the wire-log shape of the HTTP tier. This blueprint's notification outcome sink (ADR-805) is a durable record surface for notification attempts, not a log; the two do not overlap.
+
+Note on the delineation from the persistence-data-sqlite blueprint's `persistenceStore` topic: this blueprint's notification outcome sink is substrate-agnostic. When composing with the persistence-data-sqlite blueprint, the outcome sink's substrate is a facade verb on that store; the observability-essentials blueprint does not itself hold an opinion on the store engine and does not conflict on `persistenceStore`.
+
+Rules for new topics (inherited from the application-spa, application-api-rest, security-auth-magic-link, and persistence 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 (`healthEndpoints`, `probes`, `livenessReadiness` are all wrong when `healthProbes` already exists; `readinessAggregation`, `readyPolicy` are all wrong when `readinessSemantics` already exists; `statusPage`, `publicStatus`, `uptimePage` are all wrong when `statusPageContract` already exists).
+
+## Id number bands (registry bootstrap)
+
+AC ids (and therefore US numeric ids, which anchor them) are NOT namespaced by the 0.4.4 schema grammar; the band allocation IS the AC-collision enforcement mechanism. Composing blueprints take a fresh band rather than proposing namespaced AC ids. Band allocation is ratified policy (2026-08-19); this table is the shared registry-bootstrap replicated across every shipped and forthcoming blueprint's `docs/topics.md` until a mechanism-side central registry lands (v1.1 candidate).
+
+This table is maintained shelf-wide across every blueprint's `docs/topics.md`. Rows are recorded at ship, never predicted.
+
+| Blueprint | US band | ADR/TAC suffix block | Status | Global topics |
+|---|---|---|---|---|
+| application-spa | 1101-1899 | 2xx | shipped v1.3.0 | `clientRouting`, `theming`, `clientState`, `errorEnvelope`, `authModel` |
+| application-api-rest | 2101-2899 | 3xx | shipped v1.0.0 | `errorEnvelope`, `authModel`, `apiVersioning`, `logging` |
+| security-auth-magic-link | 3101-3899 | 5xx | shipped v1.0.0 | `authModel` |
+| email-smtp-resend | 4101-4899 | 4xx | shipped v1.0.0 | none |
+| hello-panel (walkthrough exemplar) | 4101-4899 | 4xx | doc-reserved; teaching exemplar in `packages/rcf-lite/docs/blueprint-authoring-walkthrough.md`, not shipped as a blueprint directory | `operatorPanel` |
+| persistence-data-sqlite | 5101-5899 | 6xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| delivery-ci-workflows | 6101-6899 | 7xx | shipped v2.0.0 (renamed from ci-pipeline) | `ciGates`, `strictCoverageGate`, `releaseArtefacts` |
+| observability-essentials | 7101-7899 | 8xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics`, `statusPageContract` |
+| security-secrets-management | 8101-8899 | 9xx | shipped v1.0.0 | `secretsSource` |
+| security-auth-clerk | 9101-9899 | 10xx | shipped v1.0.0 | `authModel` |
+| security-auth-oauth2 | 10101-10899 | 11xx | shipped v1.0.0 | `authModel` |
+| security-auth-keycloak | 11101-11899 | 12xx | shipped v1.0.0 | `authModel` |
+| deploy-cloudflare-workers | 12101-12899 | 13xx | shipped v1.0.0 | `deploymentTarget` |
+| persistence-data-d1 | 13101-13899 | 14xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
+| observability-probe-endpoints | 14101-14899 | 15xx | shipped v1.0.0 | `healthProbes`, `readinessSemantics` |
+
+US 7101-7110 sit at the LOW end of the 7101-7899 band on purpose. A project-side story that mechanically derives from an observability-essentials REQs id into the number `7110` would collide against observability-essentials-US-7110 in this package; the band leaves headroom at the HIGH end (US 7181-7899) so a project's own stories anchored to observability-essentials REQs can allocate without conflict. The watchpost run4 lesson applies here too.
+
+Row-status caveat: the delivery-ci-workflows seat shipped first (PR #95 merged at 595cab9c on main). This branch was rebased onto that main; the delivery-ci-workflows row reflects the shipped state, and the observability row flips to `shipped v1.0.0` at this branch's merge (Dave coordinates that final flip in the merge commit or an immediate follow-up).
+
+## Shared expectations for future composing blueprints
+
+- Reuse `healthProbes` exactly as spelled here when your blueprint holds an opinion on the health endpoint contract; contribute your own scope:global ADR on that string and let composition surface the pairing. A gRPC-health blueprint or a single-endpoint blueprint will conflict here by design.
+- Reuse `readinessSemantics` exactly as spelled here when your blueprint holds an opinion on readiness aggregation or the declaration scope; a quorum-aggregation blueprint conflicts here by design.
+- Reuse `statusPageContract` exactly as spelled here when your blueprint holds an opinion on the public status surface; a machine-readable JSON-endpoint blueprint or a historical-uptime blueprint conflicts here by design.
+- This blueprint's decision states the two-endpoint HTTP JSON contract, the strict-any-fail explicit-declaration readiness semantics, and the declared-component fixed-enum status page. Compose compatible metrics-export, tracing, or authenticated-operator-dashboard blueprints, or expect the operator to supersede with one project-level ADR per topic.
+- Global topics that plausibly belong to a future blueprint and are NOT claimed by any shipped blueprint: `messageSerialisation` and `deliverySemantics` (a message-consumer blueprint's natural globals), `caching` (unclaimed by every shipped blueprint), `metricsExport` and `tracingProtocol` (natural globals for a metrics or tracing blueprint that would compose alongside this one). Define any of these in your own package's topics doc, in this file's format, and consider whether the band-registry table above needs your slug added.

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

@@ -0,0 +1,68 @@
+# Observability blueprint guide
+
+## What it is
+
+A default observability floor for small greenfield rcf-lite projects. The blueprint contributes the WHAT of an observability pattern: how the process advertises liveness to its orchestrator, how it advertises readiness to its load balancer, how external readers see the current state of the service on a public status page, and how the project records the outcome of every notification it attempts. The default endpoint shape is HTTP with a stable JSON body; metrics export, distributed tracing, and log shipping are documented future variants behind their own future blueprints.
+
+Concretely, the blueprint ships ten requirements, ten user stories (thirty acceptance criteria), four architecture components, and five architecture decision records. Three ADRs are `scope: global` on the topics `healthProbes` (the two-endpoint HTTP JSON contract), `readinessSemantics` (strict-any-fail over an explicit boot-time-declared dependency set with cached per-dep state), and `statusPageContract` (the declared component list, the fixed state enum, and the stable notice fields on the public status page); the other two are scope-local operational ADRs (probe secrecy, notification outcome model) that a composing blueprint does not conflict with by default.
+
+## What it is not
+
+Not a metrics-export surface. There is no Prometheus scrape endpoint, no StatsD emission, no OpenTelemetry metrics contract. Projects that need metrics wire them in project-side or wait for a future `metrics-export` blueprint that composes alongside this one.
+
+Not a distributed-tracing surface. There is no span emission contract, no propagation rules, no sampling policy. A future `tracing` blueprint composes alongside this one; until then, projects that need distributed tracing supersede with a project-level ADR or add a project-authored tracing surface.
+
+Not a log-shipping surface. The application-api-rest blueprint's `logging` topic governs the wire-log shape of the HTTP tier; this blueprint does not extend or conflict with that. Notification outcome records are a durable record surface, not a log.
+
+Not an authenticated operator dashboard. The readiness probe body exposes granular per-dependency state for operator consumption, but a rich UI for internal state (per-endpoint metrics, per-request tracing, live event streams) is out of scope; projects that need it author it on top of the readiness surface and their own authenticated dashboards.
+
+Not a historical uptime chart on the status page. The public status page renders current state only at v1.0.0 (see the README's Known mechanism-reach gaps). Projects that need historical uptime cells layer them on top of a project-owned metrics substrate; a future `metrics-store` blueprint or persistence-event-log-fed variant lifts this into an AC at v1.1.
+
+Not an operator drift-detection panel. The hello-panel walkthrough exemplar's `operatorPanel` topic (authenticated persistent operator status panel above the main content) is deliberately distinct from this blueprint's `statusPageContract`; the two surfaces have different audiences (operator vs external reader) and different vocabularies. A project that wants both applies both blueprints and lets them compose.
+
+## When to reach for it
+
+Reach for the observability-essentials blueprint when:
+
+- The project is a small greenfield rcf-lite deployment (single deployable, one small team, one host or a small container fleet, no ops team standing by).
+- The deploy target runs under an orchestrator that consumes HTTP health probes (Kubernetes, systemd with sd_notify or an http-check add-on, a container platform with an equivalent probe contract).
+- The service has external readers (customers, partners, anonymous visitors) who need a canonical answer to 'is this up right now' without opening a support ticket.
+- The project sends notifications (email, SMS, push, webhook) to human recipients and needs to answer 'did the customer get it' from a queryable record rather than by hunting a provider dashboard.
+- The observability posture is 'start with the two-endpoint HTTP contract plus a public status page, layer metrics and tracing in later'; the blueprint's contract survives that layering, because the probe endpoints are the orchestrator's floor and everything else composes above them.
+
+## When it does not fit
+
+Do not reach for the observability-essentials blueprint when:
+
+- The orchestrator does not consume HTTP probes and cannot be reconfigured to (a proprietary orchestration substrate with a fixed non-HTTP health contract, a gRPC-first application on a gRPC-only mesh). A project with these needs supersedes ADR-801 with a project-level ADR selecting the orchestrator's native probe surface; the readiness semantics (ADR-802) and the status page contract (ADR-803) are transport-agnostic and carry over.
+- The service has no external readers and no public status contract is needed (an internal-only tool consumed only by authenticated operators). A project with these needs applies the blueprint with the status page path unrouted or supersedes ADR-803 with a project-level ADR declining the public surface. The probes stay useful.
+- The service sends no notifications (a read-only API, a batch-only pipeline). A project with these needs applies the blueprint without wiring TAC-804 into any code path; the notification outcome sink is dormant.
+- The observability posture is metrics-first or tracing-first (a project that has already committed to OpenTelemetry end-to-end and does not want a lightweight two-probe HTTP floor on top). A project with these needs supersedes the health probe ADR with a project-level ADR mapping to the OpenTelemetry contract; the notification outcome sink and the public status page contract stay useful.
+- The project needs multi-region status roll-up on the public page (per-region component state, per-region incident notices). Out of scope at v1.0.0; a future `multi-region-status` blueprint composes alongside this one, or a project supersedes ADR-803 with a project-level ADR extending the component vocabulary to include region.
+
+The design brief `w-2026-07-28-029` originally scoped observability as one of the five stock blueprint categories for the ergonomics ship gate. The observability-essentials blueprint at v1.0.0 does not include metrics export or distributed tracing because both are separate decision areas with their own contract surfaces (metrics-export names the wire format for a scrape or push; tracing names the propagation and sampling policy); folding them into one blueprint would produce a package with four global topics that a project has to resolve piecewise. Shipping the two-endpoint HTTP contract plus the public status page plus the notification outcome sink is the shape that fits the mechanism today; a future `metrics-export` blueprint plus a future `tracing` blueprint is the natural evolution.
+
+## What a good outcome looks like
+
+A project applies the observability-essentials blueprint on a fresh tree, declares its readiness dependency set (payments-provider, primary-store, sms-gateway) in configuration, declares its public component list (Payments, Notifications, Data) in configuration, wires TAC-801 through TAC-804 into project-authored FBSes, and lands on a deployed application where:
+
+- The orchestrator hits /healthz on the request-traffic listener every N seconds; every hit gets 200 with the JSON body inside a millisecond budget; a stuck process is restarted within N seconds of wedging.
+- The load balancer hits /readyz on the request-traffic listener every N seconds; a healthy replica gets 200 and stays in rotation, a replica whose declared payments-provider dependency has gone offline gets 503 and is pulled from rotation without restart. The replica comes back to rotation when the dependency's cached state returns to pass.
+- An external customer visits /status without a login, sees the three declared components (Payments: operational, Notifications: degraded, Data: operational) with the current state enum values as data attributes, sees the active incident notice above the component list with its title, body, severity, startedAt and componentIds fields, and does not see any hostname, replica id, database identifier, queue name, internal URL, build hash, request count, latency number, error rate, queue depth, or readiness dependency name anywhere on the page.
+- Every notification the application attempts records exactly one outcome record on the durable sink with the notificationId, channel, recipient, outcome, attemptedAt, and (on failure) errorCode fields; the operator queries the sink by recipient identifier and time window and gets the outcome records that match; a recipient with no attempts in the window returns an empty result set.
+- A downstream partial outage (a payments-provider that has gone slow) turns the readiness cached state for that dependency to fail; readiness probes return 503 within the readiness evaluation budget; liveness probes continue to return 200 within the tighter liveness budget; the load balancer pulls the affected replicas from rotation; the orchestrator does not restart them; the payments-provider recovers, the background evaluator refreshes the cached state to pass, readiness returns 200, and the replicas re-enter rotation without human intervention.
+
+## Operator decisions that remain open after apply
+
+- The liveness path, the readiness path, and the status page path defaults are /healthz, /readyz, and /status; the project overrides them at boot for compliance with a particular orchestrator convention or platform mandate.
+- The readiness dependency set (which downstream deps a failure of makes this replica unfit to serve). Blueprint owns the strict-any-fail semantics and the declaration shape; project owns the concrete dep list.
+- The public component list on the status page (name and order). Blueprint owns the vocabulary shape and the state enum; project owns the components themselves and the mapping from internal dep state to public component state.
+- The active incident notice authoring workflow (how the operator posts a notice, where the notice store lives, who has permission to post). Blueprint owns the notice field set and the render contract; project owns the write path.
+- The background dep-health evaluator cadence and per-dep evaluation budget. Blueprint owns the pattern (cached state, background evaluator, per-dep budget); project owns the concrete cadence and per-dep budget values.
+- The notification outcome sink substrate (composing with persistence: a facade verb on that store; standalone: a project-authored durable writer). Blueprint owns the record shape and the enums; project owns the substrate.
+- The auth-exempt list (the three paths the blueprint declares; the project decides whether any additional paths should be exempt or whether the exempt list should be stricter).
+- Whether to publish the readiness probe path (and its body) to third-party monitoring integrations. Blueprint owns the body shape stability guarantee; project owns the publish decision.
+
+## Cost-honesty paragraph
+
+Shipping this doc set costs the project the following. Every request path pays two probe endpoints on the same listener as request traffic; both handlers are trivial but still consume a small share of the router's dispatch cost. The background dep-health evaluator runs on its own cadence for the process lifetime; a project with N declared dependencies pays N per-dep evaluations per cadence, and each evaluation is a project-authored function that can spend as much time as it likes inside its own budget. The public status page is a first-class HTTP surface the project owns forever: renaming a declared component is a public-contract change; adding a new component is a public-contract change; the fixed state enum and fixed notice severity enum are commitments. The notification outcome sink adds a durable write per notification attempt; a project that sends millions of notifications a day pays proportionately, and the durable substrate has to handle the write rate. The three auth-exempt paths are a security invariant the project maintains across every auth middleware refactor. In return, the project gets: a restart signal decoupled from downstream health, a rotation signal that names which dep failed, a public surface that answers 'is this up' without human involvement, and an answer to 'did the customer get the notification' that is a query not an escalation.

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

@@ -0,0 +1,53 @@
+# Observability probe endpoints blueprint (v1.0.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).
+
+## Apply
+
+```
+rcf define blueprint add <path-to>/blueprints/observability-probe-endpoints
+```
+
+Phase 1 resolves local path sources only; registry and git-ref resolution is a mechanism follow-up. Apply is idempotent; `rcf define blueprint list` shows the applied entry grouped under the `observability` category; `rcf define blueprint remove observability-probe-endpoints` cleanly removes an unreferenced application.
+
+## Anatomy
+
+| Piece | Where | What |
+|---|---|---|
+| Metadata | `blueprint.json` | Slug, version, category `observability`, and the 25 contributions with scope/topic on the two global ADRs |
+| Doc set | `contributions/` | 8 REQs, 8 USs (24 ACs), 4 TACs, 5 ADRs, all schema-valid and namespaced (`observability-probe-endpoints-REQ-001` prefix family; `ADR-1501-observability-probe-endpoints-health-probes` suffix family) |
+| Kubernetes probe sample | `assets/kubernetes/podspec-probes.md` | The exact `livenessProbe` and `readinessProbe` fragments for a Kubernetes podspec that consumes the shipped default HTTPGet `/live` and `/ready` surface, with placeholder container name and port |
+| Kubernetes separate-port sample | `assets/kubernetes/podspec-probes-separate-port.md` | The podspec fragment for the separate-port topology with a dedicated `containerPort` for probes that is not published on the `Service` |
+| Load-balancer health-check sample | `assets/load-balancer/health-check-config.md` | A vendor-neutral load-balancer target-group health-check configuration illustrating the single-endpoint `/health` GET with status-code-only response |
+| systemd unit sample | `assets/systemd/notify-service.md` | A `Type=notify` systemd unit fragment illustrating the `sd_notify(READY=1)` and `WATCHDOG=1` posture |
+| Docker HEALTHCHECK sample | `assets/docker/dockerfile-healthcheck.md` | A Dockerfile fragment with `HEALTHCHECK CMD` invoking the profile's exec-transport entry point |
+| Uptime monitor URL sample | `assets/uptime-monitor/monitor-config.md` | A vendor-neutral uptime-monitor configuration example for the single-URL check pattern |
+| Guide | `guide/observability-probe-endpoints.md` | Operator-facing: when to use it, when not, boundary with observability-essentials, what stays your call, promotion signals |
+| Coordination vocabulary | `docs/topics.md` | The two global-topic strings this blueprint contributes and the shared id band registry (twelve shipped or in-flight blueprints including this one) |
+
+The doc set is contributions (copied into the project tree by `rcf define blueprint add`); the guide, assets, and docs are package-resident references. Guide rendering into `rcf/knowledge/docs/blueprint-guides/` and asset ingestion are mechanism follow-ups; until they land, the working agent reads them from the applied blueprint's source path recorded in `manifest.blueprints[].source`.
+
+## What it contributes, and what it deliberately does not
+
+Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (ratified decision 5) and no code.
+
+No FBS contributions, as a matter of principle (ratified policy 2026-08-19): FBSs are the work of the implementing agent, not the blueprint; project constraints have to be applied at the time of creation. The blueprint contributes the WHAT (the elicitation surface, the six shipped profile contracts, the two-listener topology option, the auth-exempt-list emission, the response-contract secrecy rule, the profile-swap-is-config invariant); the implementing agent derives the HOW-tasks (FBS) in the host project, where the ACs contributed here get picked up by the project's own build sequencing.
+
+Deliberately not contributed: a public status page (observability-essentials owns `statusPageContract` for that audience); a notification outcome sink (observability-essentials owns that); an authenticated operator dashboard for granular internal state (project-authored on top of the readiness predicate); a metrics-export surface (a future `metrics-export` blueprint composes alongside); a distributed-tracing surface (a future `tracing` blueprint composes alongside); a log-shipping surface (application-api-rest's `logging` topic governs the wire-log shape of the HTTP tier); the readiness predicate implementation itself (project-authored; the blueprint fixes the boundary and each profile's default aggregation rule, not the per-dependency check code); the auth middleware installer (project-authored; the blueprint emits an exact-match exempt list the installer consumes); the vendor-CLI or client-library binding for any supervisor beyond the profile contract (project-authored inside a `custom:<name>` profile).
+
+## The two global decisions
+
+ADR-1501-observability-probe-endpoints-health-probes ships `scope: global` on topic `healthProbes`. This is the project's health probe interface: elicited from the target integration profile, materialised by the profile-resolver into a frozen object that drives every downstream binding. A composing blueprint that holds a different opinion on the health probe interface (observability-essentials's self-supervised two-endpoint HTTP JSON floor is the shipped example; a future metrics-probe hybrid or a health-protocol variant would compose here too) conflicts by design.
+
+ADR-1502-observability-probe-endpoints-readiness-semantics ships `scope: global` on topic `readinessSemantics`. This is the project's readiness aggregation and cadence: elicited per profile so the shape and the flip window follow what the supervising system reads. A composing blueprint that holds a different opinion on readiness semantics (observability-essentials's strict-any-fail-over-declared-deps as the ONE project-wide rule is the shipped example) conflicts by design.
+
+Both ADRs conflict with observability-essentials on the same two topic strings on purpose. See `docs/topics.md` for the exact strings, the four documented resolution paths per conflict, the boundary with observability-essentials's `statusPageContract` (which this blueprint does not touch), and the AC id band allocation (observability-probe-endpoints owns 14101-14899, ADR/TAC suffix block 15xx).
+
+## Quality bar
+
+The probe surface always follows the operator-declared target integration profile; a missing or unrecognised declaration refuses boot with a stable-coded error naming the field. The Kubernetes profile is the shipped default; a bare apply exhibits HTTPGet `/live` and `/ready` on the request-traffic listener with the `{"status":"pass"|"fail"}` body shape and no operator configuration. Each of the six shipped profiles resolves to a config object whose transport, path (or command/notify equivalent), response contract, and semantic model are all present; a partial profile is refused at boot. Every HTTP profile carries a `probeListener.separatePort` opt-in; when set, probe handlers bind to a dedicated listener that serves only the resolved probe path set and no other routes; when unset, probe handlers bind to the user-traffic listener. Response contracts are minimal by construction: HTTP profiles that consume status-only carry content-length zero on every response; HTTP profiles that consume a body emit exactly the enumerated field set (`{"status":"pass"|"fail"}` for Kubernetes and nothing more); the profile validator refuses any override that would add a field beyond the enumerated set. No dependency name, environment name, hostname, replica id, build hash, or commit sha ever appears on any external-visible probe response. The auth-exempt list emitted by the topology component is exact-match scoped to the resolved probe path set on the resolved listener; a wildcard or prefix matcher is refused. Switching profiles is a configuration change; the source tree carries no per-profile conditional outside the profile modules and the profile-resolver. Every bar is carried by ACs in the doc set, not by this README.
+
+## Known mechanism-reach gaps
+
+- **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.

package/blueprints/observability-probe-endpoints/assets/docker/dockerfile-healthcheck.md

@@ -0,0 +1,19 @@
+# Docker HEALTHCHECK
+
+Reference for a Dockerfile fragment consuming the `dockerHealthcheck` profile's exec transport. The `HEALTHCHECK CMD` invokes the entry point the profile exposes; the exit code IS the probe answer.
+
+```dockerfile
+# ... application build stages omitted ...
+
+HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
+  CMD /usr/local/bin/<service-binary> --healthcheck || exit 1
+```
+
+Notes.
+
+- The `--healthcheck` flag on the service binary is the profile's exec entry point (TAC-1504's `execAdapter` exposes `runHealthcheck`); it reads the readiness predicate and exits 0 on pass, non-zero on fail.
+- `--interval`, `--timeout`, `--start-period`, `--retries` are Docker HEALTHCHECK defaults; tune per the container orchestrator's expectations.
+- `docker inspect` and Docker Compose's `depends_on: condition: service_healthy` consume the resulting health status.
+- No HTTP probe listener is opened by the process when the `dockerHealthcheck` profile is selected (AC-14105-3).
+
+Reference: docs.docker.com/reference/dockerfile/#healthcheck for the HEALTHCHECK instruction reference.

package/blueprints/observability-probe-endpoints/assets/kubernetes/podspec-probes-separate-port.md

@@ -0,0 +1,54 @@
+# Kubernetes probe podspec (separate-port topology)
+
+Reference fragment for a Kubernetes podspec that consumes the `kubernetes` profile with `probeListener.separatePort: 9091`: probes bind to a dedicated container port that is NOT published on the `Service`; only the traffic port is public. The kubelet reaches the probe port on the pod network.
+
+```yaml
+containers:
+  - name: <container-name>
+    image: <image-ref>
+    ports:
+      - name: http
+        containerPort: 8080
+      - name: probe
+        containerPort: 9091
+    livenessProbe:
+      httpGet:
+        path: /live
+        port: probe
+      initialDelaySeconds: 5
+      periodSeconds: 10
+      timeoutSeconds: 1
+      failureThreshold: 3
+    readinessProbe:
+      httpGet:
+        path: /ready
+        port: probe
+      initialDelaySeconds: 2
+      periodSeconds: 5
+      timeoutSeconds: 1
+      failureThreshold: 3
+```
+
+And the matching `Service` that publishes only the traffic port:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: <service-name>
+spec:
+  selector:
+    app: <selector-label>
+  ports:
+    - name: http
+      port: 80
+      targetPort: http
+```
+
+Notes.
+
+- The probe port (`9091` here) appears on the pod but not on the `Service`; the probe surface is reachable to the kubelet on the pod network and not from cluster consumers of the `Service`.
+- The separate probe listener binds only the profile's resolved probe path set; any other path on port 9091 returns not-found (AC-14104-2).
+- Reachability equivalence between probes and user traffic is traded for probe-traffic isolation; the fused topology is the default and matches observability-essentials's posture for the case where the trade goes the other way.
+
+Reference: kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes for probe field references and the pattern of using a distinct container port for probes.

package/blueprints/observability-probe-endpoints/assets/kubernetes/podspec-probes.md

@@ -0,0 +1,36 @@
+# Kubernetes probe podspec (fused topology default)
+
+Reference fragment for a Kubernetes podspec that consumes the shipped `kubernetes` profile default: HTTPGet `/live` and `/ready` on the container's request-traffic port. The port name below assumes the container publishes its user-traffic listener on a named port `http`; substitute the project's chosen name.
+
+```yaml
+containers:
+  - name: <container-name>
+    image: <image-ref>
+    ports:
+      - name: http
+        containerPort: 8080
+    livenessProbe:
+      httpGet:
+        path: /live
+        port: http
+      initialDelaySeconds: 5
+      periodSeconds: 10
+      timeoutSeconds: 1
+      failureThreshold: 3
+    readinessProbe:
+      httpGet:
+        path: /ready
+        port: http
+      initialDelaySeconds: 2
+      periodSeconds: 5
+      timeoutSeconds: 1
+      failureThreshold: 3
+```
+
+Notes.
+
+- The paths `/live` and `/ready` match the shipped `kubernetes` profile default. Override in the profile with `probeInterface.options.kubernetes.paths.{liveness,readiness}` and adjust these fragments to match.
+- `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, and `failureThreshold` are project defaults; tune per the supervising cluster's expectations.
+- The response contract is `{"status":"pass"}` on pass and `{"status":"fail"}` on fail with status codes 200 and 503; the kubelet reads only the status code. The body is present for operator triage under `kubectl describe pod` and equivalent introspection paths, and stays minimal by construction (ADR-1505).
+
+Reference: kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes for the probe reference; kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#httpgetaction-v1-core for the HTTPGetAction field reference.