rcf-lite 0.26.0 → 0.28.0

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

@@ -14,18 +14,20 @@
       "description": "The application serves the liveness endpoint at a stable HTTP path supplied by project configuration under `probeInterface.paths.liveness` (with no shipped default from v2.0.0); a GET returns 200 when the process is running its event loop and returns application/json with a status field equal to pass. When observability-probe-endpoints v1.1.0 or later is composed on the same project the resolved profile liveness path substitutes for this configuration entry automatically.",
       "given": "the process is running normally with its event loop responsive",
       "when": "an unauthenticated GET is issued against the liveness path",
-      "then": "the response status code is 200, the Content-Type is application/json, and the JSON body's status field equals pass",
+      "then": "the response status code is 200, the response carries the header owned on TAC-801-observability-essentials-liveness-probe.responsibilities[1], and the JSON body's status field equals pass",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7101-2",
-      "description": "The liveness probe handler evaluates entirely in-process; a probe hit issues zero network calls to any declared dependency, verifiable by observing the network egress from the probe path.",
+      "description": "The liveness probe handler evaluates entirely in-process; a probe hit issues zero network calls to any declared dependency, verifiable by observing the network egress from the probe path. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "given": "the process is running and a network-egress observer is attached to the probe path",
       "when": "a GET is issued against the liveness path",
       "then": "the observer records zero egress connections attributable to the probe handler between request receipt and response send",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-7101-3",
@@ -34,7 +36,8 @@
       "when": "a GET is issued against the liveness path",
       "then": "the response status code is 200 and the JSON body's status field equals pass",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7101-4",
@@ -43,12 +46,27 @@
       "when": "the process attempts to boot",
       "then": "the boot fails with the stable-coded error PROBE_INTERFACE_PATHS_MISSING and the error message names probeInterface.paths.liveness as the missing key",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-7101-5",
+      "description": "A liveness handler on a process whose in-process self-check predicate returns fail (a scheduled watchdog tick that has not fired within its budget) answers HTTP 503 with content-length 0 and an empty body, so the orchestrator restarts the process on the next probe interval. The predicate is response-capable by design: it observes a boolean the handler reads without I/O. Template values the applying agent sets: The applying agent supplies the elicited liveness-probe-path and the project-owned self-check predicate; the AC substitutes both.",
+      "given": "a running application with an operator-declared watchdog tick scheduled every 1 second and a 5-second budget; the tick has not fired for 6 seconds so the predicate is fail",
+      "when": "the orchestrator issues HTTP GET on the elicited liveness-probe-path",
+      "then": "the response is HTTP 503 with content-length 0 and an empty body; a follow-up GET while the predicate stays fail continues to answer 503; a GET after the predicate returns pass answers 200",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-801-observability-essentials-liveness-probe",
+        "field": "interfaces.createLivenessHandler"
+      }
     }
   ],
   "tacIds": [
     "TAC-801-observability-essentials-liveness-probe"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-09-04T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -14,9 +14,10 @@
       "description": "The application serves the readiness endpoint at a stable HTTP path supplied by project configuration under `probeInterface.paths.readiness` (with no shipped default from v2.0.0), distinct from the liveness path; a GET returns 200 with a JSON body when every declared readiness dependency is passing and returns 503 with a JSON body when at least one declared readiness dependency is failing. When observability-probe-endpoints v1.1.0 or later is composed on the same project the resolved profile readiness path substitutes for this configuration entry automatically.",
       "given": "the process is running and the readiness dependency set is declared",
       "when": "an unauthenticated GET is issued against the readiness path against a healthy dependency set, then against a set with at least one failing dependency",
-      "then": "the first response has status code 200 with JSON body status equal to pass; the second response has status code 503 with JSON body status equal to fail; both bodies have Content-Type application/json",
+      "then": "the first response has status code 200 with JSON body status equal to pass; the second response has status code 503 with JSON body status equal to fail; both responses carry the header owned on TAC-801-observability-essentials-liveness-probe.responsibilities[1]",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7102-2",
@@ -25,7 +26,8 @@
       "when": "a GET is issued against the readiness path targeting the same listener address as request traffic",
       "then": "the response is served by the application, not refused with a connection error, and the readiness handler and a representative request handler both bind to the same address:port pair as reported by the process",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7102-3",
@@ -34,7 +36,8 @@
       "when": "the readiness probe returns 503 across a five-minute window",
       "then": "the process exit code is not emitted, the process remains running throughout the window, and the liveness probe continues to return 200 with status pass",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7102-4",
@@ -43,7 +46,8 @@
       "when": "the process attempts to boot",
       "then": "the boot fails with the stable-coded error PROBE_INTERFACE_PATHS_MISSING and the error message names probeInterface.paths.readiness as the missing key",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -11,12 +11,13 @@
   "acceptanceCriteria": [
     {
       "id": "AC-7103-1",
-      "description": "The readiness dependency set is declared at boot from application configuration; the application refuses to boot with a stable error code if the declaration is missing or if any declared entry lacks a name, and the declaration set is inspectable from the running process through the probe response.",
+      "description": "The readiness dependency set is declared at boot from application configuration; the application refuses to boot with a stable error code if the declaration is missing or if any declared entry lacks a name, and the declaration set is inspectable from the running process through the probe response. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "given": "the process is configured with a readiness dependency declaration that names each dependency",
       "when": "the readiness probe is hit after successful boot",
       "then": "the JSON body's checks object contains one entry per declared dependency, keyed by the dependency name from the declaration, with no additional keys and no missing keys",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-7103-2",
@@ -25,21 +26,65 @@
       "when": "the response body is inspected",
       "then": "every entry in the checks object has a state field valued pass or fail and a checkedAt field valued as a parseable ISO-8601 timestamp no older than the readiness evaluation budget declared in configuration",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7103-3",
-      "description": "Dependencies not present in the readiness declaration never appear in the probe response and never affect the aggregate status.",
+      "description": "Dependencies not present in the readiness declaration never appear in the probe response and never affect the aggregate status. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "given": "the process depends on several downstream services but declares only a strict subset as readiness dependencies",
       "when": "the readiness probe is hit while an undeclared downstream service is offline",
       "then": "the undeclared service name never appears as a key in the checks object, and the aggregate status field remains pass so long as every declared dependency is passing",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-7103-4",
+      "description": "The readiness probe refuses to boot when the dependency-set declaration is absent from the applied configuration; the process exits with a non-zero code and emits READINESS_DEPS_MISSING naming the missing configuration key.",
+      "given": "a running application with no declared-dependency-set entry on the applied configuration",
+      "when": "the readiness handler boots",
+      "then": "the process exits with a non-zero code and emits a READINESS_DEPS_MISSING error naming the missing configuration key; no readiness listener binds",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-802-observability-essentials-readiness-probe",
+        "field": "interfaces.dependencyRegistry"
+      }
+    },
+    {
+      "id": "AC-7103-5",
+      "description": "The readiness probe refuses to boot when the declared dependency set contains a duplicate name; the process exits with a non-zero code and emits READINESS_DEPS_DUPLICATE naming the offending duplicate. Template values the applying agent sets: The applying agent supplies the declared-dependency-set (which will contain the duplicate the AC exercises); the AC substitutes those names.",
+      "given": "a running application with the elicited declared-dependency-set including two dependencies with the same name",
+      "when": "the readiness handler boots",
+      "then": "the process exits with a non-zero code and emits READINESS_DEPS_DUPLICATE naming the duplicate name; no readiness listener binds",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-802-observability-essentials-readiness-probe",
+        "field": "interfaces.dependencyRegistry"
+      }
+    },
+    {
+      "id": "AC-7103-6",
+      "description": "The readiness probe refuses to boot when a declared dependency has a blank name or a name that fails the accepted grammar; the process exits with a non-zero code and emits READINESS_DEPS_MALFORMED naming the offending value.",
+      "given": "a running application with a declared dependency name set to the empty string OR containing a whitespace character",
+      "when": "the readiness handler boots",
+      "then": "the process exits with a non-zero code and emits READINESS_DEPS_MALFORMED naming the offending value; no readiness listener binds",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-802-observability-essentials-readiness-probe",
+        "field": "interfaces.dependencyRegistry"
+      }
     }
   ],
   "tacIds": [
     "TAC-802-observability-essentials-readiness-probe"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -14,9 +14,10 @@
       "description": "The application serves the status page at a stable HTTP path declared in configuration (default /status), responds to an unauthenticated GET with 200 and text/html, and renders exactly the declared component list with no phantom components and no missing components.",
       "given": "the process is running with a component declaration that names N components",
       "when": "an unauthenticated GET is issued against the status page path",
-      "then": "the response status code is 200, the Content-Type begins with text/html, and the rendered document contains exactly N component elements, each carrying the declared component name as text content",
+      "then": "the response status code is 200, the response carries the status-page variant of the header owned on TAC-801-observability-essentials-liveness-probe.responsibilities[1] (text/html for this endpoint), and the rendered document contains exactly N component elements, each carrying the declared component name as text content",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7104-2",
@@ -25,7 +26,8 @@
       "when": "the rendered document is queried for the per-component state attribute",
       "then": "every component element carries a state attribute whose value is one of the four enum strings; no other value appears",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7104-3",
@@ -34,7 +36,8 @@
       "when": "the status page is rendered",
       "then": "the rendered component elements appear in the same order as the declaration, verified by walking the rendered document's component elements top-to-bottom and comparing to the declared order",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -16,7 +16,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7105-2",
@@ -25,7 +26,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7105-3",
@@ -34,7 +36,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -11,21 +11,23 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited notification-outcome-substrate; the AC substitutes the project's substrate for the illustrative sqlite.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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).",
+      "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). Template values the applying agent sets: The applying agent sets the elicited notification-outcome-substrate; the AC substitutes the project's substrate for the illustrative sqlite.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-7106-3",
@@ -34,12 +36,41 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-7106-4",
+      "description": "Notification outcome records persist across a process restart of the outcome sink: after N outcome records are written and the sink process is restarted, a query by recipient returns the same N records with the same fields as before the restart. Template values the applying agent sets: The applying agent supplies the elicited notification-outcome-substrate; the AC substitutes it for the illustrative sqlite path.",
+      "given": "a running application configured with the elicited notification-outcome-substrate on a durable path; 5 outcome records written with distinct recipient values",
+      "when": "the sink process is stopped and restarted, then a query is issued for each recipient",
+      "then": "the query returns 5 records; every returned record has the same outcome fields as the record that was written before the restart",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-804-observability-essentials-notification-outcome",
+        "field": "interfaces.createOutcomeSink"
+      }
+    },
+    {
+      "id": "AC-7106-5",
+      "description": "A failed write to the notification outcome sink (a substrate error, a full disk, a network partition on a remote substrate) is signalled to the caller with a stable-coded NOTIFICATION_OUTCOME_WRITE_FAILED error; the notification send call itself does not silently succeed with the outcome record lost. Template values the applying agent sets: The applying agent supplies the failure-mode fixture per its chosen substrate (a disk fill for sqlite, a stopped daemon for postgres); the AC substitutes the substrate.",
+      "given": "a running application with a notification-outcome-substrate that has been forced into a failure mode (a full disk on sqlite, a stopped postgres server)",
+      "when": "a caller records an outcome",
+      "then": "the recordOutcome call rejects with NOTIFICATION_OUTCOME_WRITE_FAILED naming the substrate error; the notification's own send status reflects the failure per the caller's policy; a subsequent queryByRecipient shows no fabricated record for the failed write",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-804-observability-essentials-notification-outcome",
+        "field": "interfaces.recordOutcome"
+      }
     }
   ],
   "tacIds": [
     "TAC-804-observability-essentials-notification-outcome"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -11,30 +11,37 @@
   "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.",
+      "description": "Both probe responses carry the response header owned on TAC-801-observability-essentials-liveness-probe.responsibilities[1]; 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",
+      "then": "each response carries the response header owned on TAC-801-observability-essentials-liveness-probe.responsibilities[1], 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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7107-2",
-      "description": "The readiness body carries a checks object keyed by declared dependency name; the liveness body has no checks field.",
+      "description": "The readiness body carries a checks object keyed by declared dependency name; the liveness body has no checks field. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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",
+      "description": "The probe response JSON body shape is snapshot-locked against the v2 baseline captured at 2026-09-09: any candidate release comparing against the current v2 baseline SHALL keep every documented field name and JSON type on the /live and /ready responses, and any field addition SHALL preserve the shape of every earlier v2.x release. A candidate that renames or removes a documented field fails the check with a stable code naming the offending field. Template values the applying agent sets: The applying agent sets the elicited liveness-probe-path; the AC substitutes it for the illustrative /live.",
+      "given": "the v2 baseline snapshot at blueprints/observability-essentials/assets/probe-samples/probe-response-baseline.v2.json and a candidate release's /live and /ready JSON body samples on the same profile",
+      "when": "the release-time compatibility check runs the candidate samples against the v2 baseline snapshot",
+      "then": "every field name and JSON type present on the v2 baseline is present on the candidate at the same top-level path; a rename or removal fails with the stable code PROBE_BODY_SHAPE_DRIFT naming the offending field; a candidate that adds fields without renaming or removing any passes",
       "testable": true,
-      "scope": "runtime"
+      "scope": "runtime",
+      "disposition": "template",
+      "ownerRef": {
+        "tacId": "TAC-802-observability-essentials-readiness-probe",
+        "field": "interfaces.probeBodyShapeCompatibility"
+      }
     }
   ],
   "tacIds": [
@@ -42,5 +49,5 @@
     "TAC-802-observability-essentials-readiness-probe"
   ],
   "createdAt": "2026-08-24T00:00:00Z",
-  "updatedAt": "2026-08-24T00:00:00Z"
+  "updatedAt": "2026-09-09T00:00:00Z"
 }

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

@@ -16,7 +16,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7108-2",
@@ -25,7 +26,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7108-3",
@@ -34,7 +36,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -16,7 +16,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "id": "AC-7109-2",
@@ -25,16 +26,18 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     }
   ],
   "tacIds": [

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

@@ -11,21 +11,23 @@
   "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "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.",
+      "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. Template values the applying agent sets: The applying agent sets the elicited declared-dependency-set; the AC substitutes the project's dependency names for the illustrative paymentsProvider / primaryStore tokens.",
       "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"
+      "scope": "runtime",
+      "disposition": "template"
     },
     {
       "id": "AC-7110-3",
@@ -34,7 +36,8 @@
       "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"
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [

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

@@ -29,7 +29,7 @@ Rules for new topics (inherited from the application-spa, application-api-rest,
 
 ## 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).
+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 policy; 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.
 
@@ -74,9 +74,8 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
 | edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
-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).
+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.
+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 (the maintainer coordinates that final flip in the merge commit or an immediate follow-up).
 
 ## Shared expectations for future composing blueprints
 

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

@@ -40,7 +40,7 @@ Do not reach for the observability-essentials blueprint when:
 - 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.
+The original design brief 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
 

package/blueprints/observability-logging/CHANGELOG.md

@@ -1,9 +1,49 @@
+# Changelog
+
+## 1.3.7 - 2026-09-11
+
+Identifier-pairing rule tightened to equality. `line-shape-and-fields` now records each AC-15101-1/-3/-4 row's supplied correlation id under `suppliedInput` (with the parsed log-line object under `line`) so the row can be verified as `line.correlationId === suppliedInput`; the AC-15101-1 row also carries the observedEmissions list its detail already names. `correlation-id-flow` AC-15102-1 header-absent row records the fixture-minted UUID as an engine-minted `requestId` (with `absentSuppliedInput: true` for readability) instead of a `<no-header>` sentinel that could not equal the echoed value.
+
+## 1.3.6 - 2026-09-11
+
+redaction-boundary probe now emits one payload per recommended-default category (credential, token, bearer, pii.email, pii.name, pii.address) inside its own runWithCorrelation(randomUUID(), ...) so each row records a per-emission correlation id paired to the emitted line's correlationId; every one of the six mandatory categories AC-15103-1 names is now anchored to AC-15103-1 with derived redacted value AND payload-unmutated observation. The AC-15103-4-shaped row is emitted in its own correlation context and records the supplied/emitted correlationId pair alongside userId preservation and pii.email redaction. Anatomy helper strict-evidence contract tightened: bare `suppliedInput`, `headerName`, `workflowName`, `line.correlationId`, `observed[].supplied` and `observedRoundTrips[].supplied` no longer satisfy the identifier half on their own; each must be paired with the engine's echo of that value (echoedHeader, derivedResponseHeader, a returned resource id, or a log-line correlationId equal to the value the probe supplied).
+
+
+## 1.3.5 - 2026-09-11
+
+redaction-boundary probe now wraps each emission in runWithCorrelation(randomUUID(), ...) so every AC-15103-1 row and the AC-15103-4-shaped row carry a real per-emission correlation id as the identifier alongside the derived redacted value; the run-notes claim about redaction-boundary correlation ids is now true to the recorded rows. correlation-id-flow AC-15102-3 row (bare emission with correlationId=null by design) is de-claimed to conformanceOnly, since a bare emission carries no engine-returned identifier.
+
+## 1.3.4 - 2026-09-11
+
+line-shape-and-fields probe now wraps every emission (per-level, BigInt, reserved-key-collision) in runWithCorrelation(randomUUID(), ...) so each emitted log line carries a real correlation id; the AC-15101-1/-3/-4 rows record the parsed line object plus a correlationIdEchoed identifier and a bodyExcerpt derived value.
+
 # observability-logging CHANGELOG
 
-## 1.2.0 (visual round T-4, spec 2026-09-06 section 5.4.2, Baz Q2 default)
+## 1.3.3 - 2026-09-11
+
+Adds a contributions/probes/ pack (line-shape-and-fields, correlation-id-flow, redaction-boundary) with a fixture-side logger factory and HTTP transport under packages/rcf-lite/test/fixtures/probe-pack-observability-logging/. Probes run against the fixture on Node 24. No account gate.
+
+Anchoring: line-shape-and-fields anchors AC-15101-1/3/4 (seven-field minimum with per-field non-empty-string type checks and ISO-8601 timestamp; BigInt folded to a decimal string; reserved-key collision safety). correlation-id-flow anchors AC-15102-1 with BOTH the header-present clause (three varied inbound ids echoed on the response header, response body and emitted log line with a fixture-computed sequence and hash the probe recomputes locally) AND the header-absent clause (fixture mints a v4 UUID, response body carries mintedFromAbsent=true and the correlationId, the emitted line matches); also anchors AC-15102-3 (bare emission with no ambient context carries correlationId=null). The monotonic-sequence row de-claims with the limitation naming AC-15102-1. redaction-boundary anchors AC-15103-1 (top-level recommended-default category folded with `[REDACTED:<category>]` AND the caller's original payload object unmutated after log.info returns) and AC-15103-4 (the { user: { id, pii: { email } } } shape with user.id preserved and user.pii.email redacted, plus caller unmutated). The nested top-level pii row and the bare `note` row de-claim with limitations naming AC-15103-4 and AC-15103-3 respectively. probe-utils normalisation and thrown-error rows carry an evidence object; the fallback anchorAcId is null.
+
+## 1.3.1 (register-sweep patch, 2026-09-10)
+
+- Register: neutral wording in shipped prose (no capability change).
+
+## 1.3.0 (2026-09-09)
+
+- Removes `sessionInventory` from `capabilities[]`. The section 7c backing requirement never landed on this blueprint: a logging surface does not own or deliver a session-listing surface. The applied `security-auth-clerk` blueprint owns `sessionInventory` through `TAC-1003-security-auth-clerk-session-verifier.interfaces.sessionInventory` (being defined on the security branch tonight); a project that runs Clerk continues to gate the account-settings sessions surface via that capability, unchanged. Shelf-wide grep of `requiresAppliedCapabilities` names no consumer that requires `sessionInventory` from this blueprint; the soft consumer (`application-account-settings` probe pack check `AC-25106-1` via `readAppliedCapabilities`) reads the union across applied blueprints and is unaffected. Removal is reasoned per section 7c, not a downgrade of the semantic surface.
+- Adds `elicits[]` with four apply-time answers: `correlation-header-name` (string, default X-Correlation-Id; ADR-1602), `minimum-log-level` (enum trace/debug/info/warn/error/fatal, default info; ADR-1604), `redaction-categories-additions` (string, default blank; ADR-1603) and `boot-identity-fields` (string, JSON object with environment/serviceName/serviceVersion; REQ-005). Every option value is backed by a must-priority REQ description (section 7c criterion a).
+- Adds `ADR-1605-observability-logging-serialisation-refusal`: BigInt values fold to their decimal string form on the emitted line; circular references and function references are dropped with one stderr notice naming the offending dotted path. Closes the family-pass F-4 chain-contradiction specimen (TAC-1601 internalStructure previously described a BigInt fold while REQ-001 / AC-15101-2 described a drop). TAC-1601 internalStructure and responsibility 4 are rewritten to reference ADR-1605; the F-4 outcome split is separately observable at AC-15101-2 (drop for circular/function) and AC-15101-3 (BigInt fold).
+- Adds `REQ-006` and `US-15109` naming the `auditLog` capability explicitly: the audit-log stream carries actor, target, before, after and correlationId on the shared minimum field set the consumer (application-admin-console AC-21105-1) reads. Backs the `auditLog` token per section 7c.
+- Grows `US-15101` from 2 ACs to 5 ACs: adds AC-15101-3 (BigInt fold oracle), AC-15101-4 (reserved-name collision refusal), AC-15101-5 (ISO-8601 timestamp millisecond oracle). Every existing and new AC on the story carries `disposition`; ACs observing a specific TAC surface carry `ownerRef`.
+- Adds `deliveredBy` to every REQ: REQ-001/002/003/005 point at TAC-1601 or TAC-1602 interfaces the responsibility genuinely carries; REQ-004 delivered by ADR-1604. Closes 5 pass-2 lint findings; per-blueprint `rcf define blueprint lint-consistency` reports zero on pass 1 and pass 2.
+- adds section 7a coverage-note descriptions to US-15106 and US-15108 recording the guide-and-TAC trace outcome (no additional mechanism-specific failure paths named beyond the two ACs each story already binds).
+- Register scan fix (customer-facing register): neutralises historical CHANGELOG entries (1.1.0 and 1.2.0) so shipped content carries no internal author names.
+
+## 1.2.0 (visual round, spec 2026-09-06 section 5.4.2, operator Q2 default)
 
-- Declares `capabilities: [auditLog, sessionInventory]` on `blueprint.json`. The `sessionInventory` addition ships the logging-as-session-inventory projection: a project may configure the logger session-emission channel as the source the account-settings sessions surface reads (device labels from the User-Agent header, last-active from the last event emitted per session, terminate as an operator write into the same channel). Additive per section 6 of `blueprint-authoring.md`. Consumed at apply time by the visual round T-4 `application-account-settings` blueprint. A project that does not run the logger as a session store leaves the surface capability supplied by the applied auth blueprint alone; the account-settings blueprint reads the union.
+- Declares `capabilities: [auditLog, sessionInventory]` on `blueprint.json`. The `sessionInventory` addition ships the logging-as-session-inventory projection: a project may configure the logger session-emission channel as the source the account-settings sessions surface reads (device labels from the User-Agent header, last-active from the last event emitted per session, terminate as an operator write into the same channel). Additive per section 6 of `blueprint-authoring.md`. Consumed at apply time by the visual round `application-account-settings` blueprint. A project that does not run the logger as a session store leaves the surface capability supplied by the applied auth blueprint alone; the account-settings blueprint reads the union.
 
-## 1.1.0 (visual round T-5, spec 2026-09-04 section 5.5.2, Baz Q2 default)
+## 1.1.0 (visual round, spec 2026-09-04 section 5.5.2, operator Q2 default)
 
-- Declares `capabilities: [auditLog]` on `blueprint.json`. No other change. The new field is additive per section 6 of `blueprint-authoring.md` (an additive optional field with no global-topic change is a minor bump). Keeps a single grammar for capability declaration: consumer blueprints read the union of declared `capabilities[]` on applied blueprints, never the `providesRoles[]` -> capability inference. This is the ratified rule (one grammar, no role-to-capability inference); the section 6a table previously noted `auditLog` as "implicit through the `logging` role" and now names `observability-logging` as the explicit shelf provider. Consumed at apply time by the visual round T-5 `application-admin-console` blueprint to gate the audit-log surface (probe pack check `AC-21105-1`).
+- Declares `capabilities: [auditLog]` on `blueprint.json`. No other change. The new field is additive per section 6 of `blueprint-authoring.md` (an additive optional field with no global-topic change is a minor bump). Keeps a single grammar for capability declaration: consumer blueprints read the union of declared `capabilities[]` on applied blueprints, never the `providesRoles[]` -> capability inference. This is the shipped rule (one grammar, no role-to-capability inference); the section 6a table previously noted `auditLog` as "implicit through the `logging` role" and now names `observability-logging` as the explicit shelf provider. Consumed at apply time by the `application-admin-console` blueprint to gate the audit-log surface (probe pack check `AC-21105-1`).