rcf-lite 0.27.0 → 0.28.0

package/blueprints/application-notifications-in-app/contributions/probes/run-live-region-preseeding.mjs

@@ -0,0 +1,5 @@
+import runProbe from './live-region-preseeding.mjs';
+import { runShim } from './probe-utils.mjs';
+
+const engine = { kind: 'fixture', image: 'test/fixtures/probe-pack-application-notifications-in-app/server.js', healthy: true };
+runShim('live-region-preseeding', engine, runProbe);

package/blueprints/application-notifications-in-app/contributions/probes/run-toast-contract.mjs

@@ -0,0 +1,5 @@
+import runProbe from './toast-contract.mjs';
+import { runShim } from './probe-utils.mjs';
+
+const engine = { kind: 'fixture', image: 'test/fixtures/probe-pack-application-notifications-in-app/server.js', healthy: true };
+runShim('toast-contract', engine, runProbe);

package/blueprints/application-notifications-in-app/contributions/probes/toast-contract.mjs

@@ -0,0 +1,92 @@
+// application-notifications-in-app probe: toast role/priority mapping
+// and the WCAG 2.2.1 timeout floor (AC-20102-1) plus the focus-pause
+// clause (AC-20102-4).
+//
+// AC-20102-1 concerns the client-JS-rendered toast DOM (priority to
+// role/wrapper mapping, one wrapper per body, data-shown-at and
+// data-dismissed-at ISO timestamps, elapsed timeout at or above the
+// six-second floor). All of that is browser-only in this fixture:
+// the toast DOM is created by the client script and the elapsed
+// timing runs off a browser timer. The AC-20102-1 clause is emitted
+// as a notObservableHere row anchored to AC-20102-1 (no focus-pause
+// language - focus-pause is a separate AC, AC-20102-4).
+//
+// AC-20102-4 is the focus-pause clause: a focused toast pauses the
+// timer and dismissal removes the toast. The fixture's current toast
+// factory renders the toast in client JS, sets data-dismissed-at on
+// dismiss but does not remove the toast from the DOM and does not
+// pause the timer on focus. That is a fixture-level gap against the
+// AC. Rather than attributing a positive observation, this probe
+// emits a conformanceOnly row (null anchor, per the null-anchor +
+// limitation contract) naming AC-20102-4 in the limitation so the
+// AC-property gap is honestly recorded.
+//
+// The pack aggregate stays warn (AMBER) via the shared aggregate()
+// rule (both rows carry verdict:'warn'). The fixture is still spun
+// up so the probe exercises the fixture lifecycle
+// (teardown-fails-verdict rule).
+
+import { fixtureFetch, startFixture, excerpt } from './probe-utils.mjs';
+
+export const anchorAcId = 'application-notifications-in-app-AC-20102-1';
+export const accountBound = false;
+
+export default async function runProbe() {
+  const fixture = await startFixture();
+  const results = [];
+  try {
+    // Reachability fetch: the fixture reports the shell root on /
+    // with data-toast-timeout-floor-seconds and the two live-region
+    // wrappers preseeded. Recorded so both conformance rows below
+    // carry a live x-fixture-request-id and a body excerpt from this
+    // run (rule-7d shape + tally: conformance rows require an
+    // evidence object; the shell body proves the fixture answered
+    // and lets a reader see the observable surface even though the
+    // client-JS toast rendering itself is not observable here).
+    const shell = await fixtureFetch(fixture.url, '/');
+    const shellRootMatch = (shell.body.match(/<div[^>]*data-region="shell-root"[^]{0,240}/) || [''])[0];
+    const timeoutFloorMatch = shell.body.match(/data-toast-timeout-floor-seconds="(\d+)"/);
+    const timeoutFloorSeconds = timeoutFloorMatch ? Number(timeoutFloorMatch[1]) : null;
+
+    results.push({
+      anchorAcId,
+      notObservableAcId: anchorAcId,
+      verdict: 'warn',
+      notObservableHere: true,
+      reason: 'AC-20102-1 requires observing client-driven toast emission into [data-live-region="polite"] with role="status" for info and [data-live-region="assertive"] with role="alert" for error, one wrapper per body, data-shown-at and data-dismissed-at ISO timestamps on the toast element, and the elapsed time between them at or above the ADR-2102 six-second floor. Toast DOM is emitted by client JS after load and elapsed timing runs off a browser timer, so a fixture-HTTP-only probe cannot observe them; a Playwright-driven check is required.',
+      detail: `Given a toast triggered by a background event, priority-to-role/wrapper mapping, one-shot announcement per wrapper, and the WCAG 2.2.1 six-second elapsed-timeout floor on data-shown-at/data-dismissed-at are all browser-only in this fixture; the shell root observed at GET / carries data-toast-timeout-floor-seconds=${timeoutFloorSeconds} (server-rendered constant, not the client-JS-driven toast) so the fixture reachability is recorded; needs a Playwright-driven observation for the toast contract itself; x-fixture-request-id=${shell.requestId}.`,
+      evidence: {
+        requestId: shell.requestId,
+        responseStatus: shell.status,
+        bodyExcerpt: excerpt(shellRootMatch),
+        derived: {
+          route: '/',
+          timeoutFloorSecondsServerRendered: timeoutFloorSeconds,
+          shellRootPresent: shellRootMatch.length > 0,
+        },
+      },
+    });
+
+    results.push({
+      anchorAcId: null,
+      conformanceOnly: true,
+      limitation: 'application-notifications-in-app-AC-20102-4: the focus-pause clause (a focused toast pauses the timer and resumes on focus loss) and the toast-dismissal DOM-removal contract require observing a running browser (focus events, timer state and DOM mutation), and additionally the shipped fixture toast factory does not pause the timer on focus and marks dismissal by setting data-dismissed-at rather than removing the toast from the DOM. Deferred to a Playwright-driven check and named here as a fixture gap so the operator sees the property claim without a positive observation.',
+      verdict: 'warn',
+      detail: `Given a toast triggered by a background event and a focused-toast clause per AC-20102-4, the focus-pause + dismissal-removal properties are not observed by this Node HTTP probe and the shipped fixture does not implement them; this row is a null-anchored conformance de-claim so the AC-20102-4 gap is on the record; fixture reachability confirmed via the same shell fetch (x-fixture-request-id=${shell.requestId}).`,
+      evidence: {
+        requestId: shell.requestId,
+        responseStatus: shell.status,
+        bodyExcerpt: excerpt(shellRootMatch),
+        derived: {
+          route: '/',
+          focusPauseObserved: false,
+          dismissalRemovesToast: false,
+          reason: 'browser-only clauses of AC-20102-4; fixture does not implement them either',
+        },
+      },
+    });
+  } finally {
+    await fixture.kill();
+  }
+  return { results };
+}

package/blueprints/application-notifications-in-app/contributions/tacs/tac-2101-application-notifications-in-app-live-region.json

@@ -28,7 +28,7 @@
     {
       "name": "priorityToRoleContract",
       "kind": "shape",
-      "description": "The ADR-2101 mapping: `info` maps to `{ wrapper: 'polite', role: 'status' }`; `error` maps to `{ wrapper: 'assertive', role: 'alert' }`. A priority outside the ADR-2101 enum is refused at project-side review."
+      "description": "The ADR-2101 mapping: `info` maps to `{ wrapper: 'polite', role: 'status' }`; `error` maps to `{ wrapper: 'assertive', role: 'alert' }`. A priority outside the ADR-2101 enum is refused at project-side check."
     }
   ],
   "dependencies": [
@@ -39,8 +39,8 @@
       "description": "Every toast the live-region factory emits records a delivery-log row through TAC-2102's `writeDeliveryRow`; ownership of the row shape lives here through the delegating call, ownership of the persistence layer lives on TAC-2102 and the applied `logging` companion."
     }
   ],
-  "tradeoffs": "The two-wrapper contract is opinionated: some designs use one wrapper per notification kind (informational, error, warning, success) with four ARIA politeness levels. This TAC insists on two wrappers because the WCAG 4.1.3 status-message clause and the ARIA APG alert pattern jointly draw the line at polite vs assertive; adding wrapper granularity that assistive technologies do not distinguish trades runtime discipline for false precision. The six-second timeout floor is deliberately not a ceiling: an elicited override raises the floor but never lowers it, so a design that shows a toast for two seconds fails at author-side review.",
-  "notes": "Known mechanism-reach gap: the pack asserts the disjoint-content rule (AC-20108-1) at the moment it inspects the wrappers, not continuously across the toast lifetime. A pathological implementation that briefly writes into both wrappers between two microtasks would not be caught by the pack; project-side review carries the residual. A v1.1 minor bump could add a MutationObserver-based check.",
+  "tradeoffs": "The two-wrapper contract is opinionated: some designs use one wrapper per notification kind (informational, error, warning, success) with four ARIA politeness levels. This TAC insists on two wrappers because the WCAG 4.1.3 status-message clause and the ARIA APG alert pattern jointly draw the line at polite vs assertive; adding wrapper granularity that assistive technologies do not distinguish trades runtime discipline for false precision. The six-second timeout floor is deliberately not a ceiling: an elicited override raises the floor but never lowers it, so a design that shows a toast for two seconds fails at the author-side check.",
+  "notes": "Known mechanism-reach gap: the pack asserts the disjoint-content rule (AC-20108-1) at the moment it inspects the wrappers, not continuously across the toast lifetime. A pathological implementation that briefly writes into both wrappers between two microtasks would not be caught by the pack; project-side check carries the residual. A v1.1 minor bump could add a MutationObserver-based check.",
   "createdAt": "2026-09-04T23:59:00Z",
   "updatedAt": "2026-09-04T23:59:00Z"
 }

package/blueprints/application-notifications-in-app/contributions/tacs/tac-2102-application-notifications-in-app-centre.json

@@ -48,7 +48,7 @@
     {
       "name": "Applied logging companion",
       "kind": "external",
-      "description": "The delivery-attempt log's persistence layer is the applied `logging` companion's; this TAC delegates the write path. A project applying this blueprint without a `logging` companion (neither applied nor registered library nor core shelf) sees the delivery-log endpoint returning an empty rows array, which fails project-side review."
+      "description": "The delivery-attempt log's persistence layer is the applied `logging` companion's; this TAC delegates the write path. A project applying this blueprint without a `logging` companion (neither applied nor registered library nor core shelf) sees the delivery-log endpoint returning an empty rows array, which fails project-side check."
     }
   ],
   "tradeoffs": "The centre reading through the delivery log (rather than a separate inbox store) keeps the shell single-sourced on the applied `logging` companion but couples the surface latency to the log query; a project with a very high notification volume may want to project a materialised inbox view alongside the log. This TAC accepts the coupling because it collapses two writers of the same row into one; a project that needs the materialised view supersedes with a project-authored REQ.",

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20101.json

@@ -21,7 +21,7 @@
     },
     {
       "id": "AC-20101-2",
-      "description": "Given the shell's live-region factory (TAC-2101 `renderLiveRegions`), a call at first render emits exactly two wrapper elements matching the AC-20101-1 shape and never re-creates them on subsequent renders (the wrappers are stable identity across the app lifetime). A factory that recreates the wrappers on a route change fails this AC at project-side review.",
+      "description": "Given the shell's live-region factory (TAC-2101 `renderLiveRegions`), a call at first render emits exactly two wrapper elements matching the AC-20101-1 shape and never re-creates them on subsequent renders (the wrappers are stable identity across the app lifetime). A factory that recreates the wrappers on a route change fails this AC at project-side check.",
       "given": "the shell's live-region factory",
       "when": "the factory is invoked at first render and again on a route change",
       "then": "the same two wrapper elements are returned; identity is stable",

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20102.json

@@ -21,7 +21,7 @@
     },
     {
       "id": "AC-20102-2",
-      "description": "Given the toast factory (TAC-2101 `renderToast({ priority, body })`), the factory picks the polite wrapper for `info` priority and the assertive wrapper for `error` priority; a factory that writes into both wrappers on one call, or picks the wrong wrapper for a priority, fails at project-side review.",
+      "description": "Given the toast factory (TAC-2101 `renderToast({ priority, body })`), the factory picks the polite wrapper for `info` priority and the assertive wrapper for `error` priority; a factory that writes into both wrappers on one call, or picks the wrong wrapper for a priority, fails at project-side check.",
       "given": "the toast factory",
       "when": "the factory is invoked at a given priority",
       "then": "the correct wrapper receives the toast",

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20103.json

@@ -21,7 +21,7 @@
     },
     {
       "id": "AC-20103-2",
-      "description": "Given the centre factory (TAC-2102 `renderCentre`), the factory reads the delivery-attempt log from REQ-005's endpoint and emits one wrapper per row within the retention window; a factory that emits rows older than the retention window, or that skips rows within the window, fails at project-side review.",
+      "description": "Given the centre factory (TAC-2102 `renderCentre`), the factory reads the delivery-attempt log from REQ-005's endpoint and emits one wrapper per row within the retention window; a factory that emits rows older than the retention window, or that skips rows within the window, fails at project-side check.",
       "given": "the centre factory",
       "when": "the delivery log is read",
       "then": "one wrapper is emitted per row within the retention window",

package/blueprints/application-notifications-in-app/contributions/user-stories/application-notifications-in-app-us-20105.json

@@ -25,7 +25,7 @@
     },
     {
       "id": "AC-20105-2",
-      "description": "Given the delivery-log write factory (TAC-2102 `writeDeliveryRow`), a call from the toast factory and a call from the centre factory both write through the applied `logging` companion's record factory (the row shape lives on this blueprint; the persistence layer lives on the companion). A row written outside the companion's factory bypasses the companion's retention and audit path and is refused at project-side review.",
+      "description": "Given the delivery-log write factory (TAC-2102 `writeDeliveryRow`), a call from the toast factory and a call from the centre factory both write through the applied `logging` companion's record factory (the row shape lives on this blueprint; the persistence layer lives on the companion). A row written outside the companion's factory bypasses the companion's retention and audit path and is refused at project-side check.",
       "given": "the delivery-log write factory",
       "when": "a toast or centre event surfaces a notification",
       "then": "a row lands through the applied logging companion",

package/blueprints/application-notifications-in-app/guide/application-notifications-in-app.md

@@ -37,11 +37,11 @@ Every route the applying project ships preseeds both live-region wrappers in the
 ## Common gotchas
 
 - The two live-region wrappers must be preseeded before the first notification. A lazy-mount defect is silent at the DOM (the wrapper appears "eventually") but loses the first announcement at the assistive-technology layer. The pack refuses ship on this shape.
-- The priority-to-role mapping is fixed at v1.0.0 (info to polite/status, error to assertive/alert). A third priority (`warning`) is a v1.1 minor bump because it changes the role vocabulary; free-form priorities are refused at project-side review.
+- The priority-to-role mapping is fixed at v1.0.0 (info to polite/status, error to assertive/alert). A third priority (`warning`) is a v1.1 minor bump because it changes the role vocabulary; free-form priorities are refused at project-side check.
 - The toast timeout floor is a floor, not a ceiling. Six seconds is the default; an operator-elicited value above the floor is honoured (thirty seconds), a value below the floor is refused at apply. The pack measures the actual elapsed time against the shell root's declared floor and against the six-second baseline; both must clear.
 - The centre enumerates items by `data-notification-id`, per the gate discipline. A centre implementation that uses only `role="listitem"` on the children (without a per-element id attribute) passes the accessibility contract but does not let the pack enumerate individual items reliably; ship both.
-- The family-prefix reservation is documented; naming a future notifications blueprint outside the family (`application-alerts-email`) reads against the reservation and stops at author-side review.
+- The family-prefix reservation is documented; naming a future notifications blueprint outside the family (`application-alerts-email`) reads against the reservation and stops at author-side check.
 
 ## Cost honesty
 
-Shipping this blueprint costs the project a design pass on the notification categories and retention window, and a build pass on the live-region factory and the centre inbox surface. It buys the WCAG 4.1.3 and WCAG 2.2.1 disciplines enforced at ship, the ARIA APG alert pattern on the assertive slot, the centre inbox with the acknowledge round-trip, the preferences UI with sibling delegation, and the family-prefix reservation that survives when the shelf grows a second notifications channel. The gate reviewer verifies the pack runs green against the sample-app fixture and reviews the applying project's own notifications surfaces against the ADR set.
+Shipping this blueprint costs the project a design pass on the notification categories and retention window, and a build pass on the live-region factory and the centre inbox surface. It buys the WCAG 4.1.3 and WCAG 2.2.1 disciplines enforced at ship, the ARIA APG alert pattern on the assertive slot, the centre inbox with the acknowledge round-trip, the preferences UI with sibling delegation, and the family-prefix reservation that survives when the shelf grows a second notifications channel. The gate reviewer verifies the pack runs green against the sample-app fixture and inspects the applying project's own notifications surfaces against the ADR set.

package/blueprints/application-onboarding-tour/CHANGELOG.md

@@ -1,5 +1,31 @@
 # application-onboarding-tour CHANGELOG
 
+## 1.1.9 - 2026-09-12
+
+- Fixture client script fix: the restart-tour click listener now calls `event.preventDefault()` when the button is a submit-button inside the progressive-enhancement `<form method="post" action="/actions/restart-tour">`, so JS-on activation POSTs the server-side clear exactly once (previously the native form submission and the fetch fired both writes; the clear was idempotent so no data was lost, but the duplicate POST was measurable on `/__requests`). JS-off activation continues to POST the form natively; JS-on drives the same POST via fetch. Probe assertions and record shape are unchanged.
+
+## 1.1.8 - 2026-09-12
+
+- completion-persistence (AC-26104-1) upgraded from a de-claim to an honest positive-evidence row that observes both the persistence half and the restart-control-activation half of the AC server-side. The fixture derives the server-side first-run flag on `/tour` from the applied `completion-state-store` elicit when its value is `server-side-per-principal`: pages render `data-tour-first-run="true"` when the principal has no completion record and `data-tour-first-run="false"` when a completion record is present (`data-tour-completion-source` and `data-tour-principal-id` name the source). The settings surface now renders the restart-tour control inside a progressive-enhancement `<form method="post" action="/actions/restart-tour">` carrying the principal-id in a hidden input, backed by a new server route that clears the applied server-side completion record for the principal and returns `200 { ok:true, cleared:true, restartControl:"restart-tour" }`; the client script also fires the same POST via fetch on click for SPA parity, but the form action is the source of truth even with JS off. The probe drives the full cycle - initial completion GET (404) and initial `/tour` render (`data-tour-first-run="true"`); POST completion write; subsequent completion GET and `/tour` render (`data-tour-first-run="false"`); `/settings` render carrying the restart-tour form with the hidden principal-id input; POST `/actions/restart-tour` (the same form submission the button fires); final completion GET (404) and `/tour` render (`data-tour-first-run="true"`). The `?break=no-persist` switch now refuses the server-side POST and the restart-tour form action with a defined error shape (`COMPLETION_WRITE_FAILED` / `COMPLETION_CLEAR_FAILED`), so the negative-variants anatomy assertion drives the completion-persistence aggregate to fail. First-run-detection's returning-principal row re-anchored to AC-26104-1 (the AC the suppression clause belongs to) and left as `notObservableHere` for the client-side auto-open branch; the misleading AC-26101-1 attribution is removed. Stepper-role-dialog rows keep `notObservableHere` on the browser-only halves. Positive-evidence row shape tightened in the anatomy helper: a positive row now requires a non-empty engine-returned `requestId` AND (a non-empty `bodyExcerpt` OR a non-empty `derived` object); a `{derived:{}}` alone or a `requestId` alone no longer counts, with two new negative-case tests covering the empty-derived and id-only patterns. Fixture README env-var manifest already declared `PROBE_BREAK` and the probe-utils `DECLARED_ENV` list already carries it.
+
+## 1.1.6 - 2026-09-11
+
+- Shared `aggregate()` no longer promotes warn rows to pass: any row with verdict warn (including honest de-claim rows) lifts the aggregate to warn; a probe whose rows are all warn aggregates to warn, not pass. Shared teardown propagates a SIGKILL failure through the returned kill() promise instead of swallowing it. completion-persistence AC-26104-1 row de-claimed to `conformanceOnly:true` with `verdict:'warn'` and a `limitation` naming the browser-only clause (the restart-tour control activation and subsequent tour re-open are browser-driven and not observed by this Node HTTP probe); the server-side write-read-clear cycle still drives the row observation and flips to fail if the fixture cycle breaks. first-run-detection and stepper-role-dialog rows keep `notObservableHere` on the browser-only halves and emit `verdict:'warn'`. checklist-anchor-open stays as a positive-observation row that fully observes AC-26103-1 across both applied-branches. Anatomy test extended with a negative-variant assertion that the shipped fixture break switches drive the checklist aggregate to fail.
+
+## 1.1.5 - 2026-09-11
+
+- completion-persistence probe now observes AC-26104-1's server-observable half. Fixture ships three new endpoints keyed by `x-principal-id` header (or `?principal-id=` query) exercised only when `TOUR_STORE=server-side-per-principal`: `POST /api/tour/completion` writes, `GET /api/tour/completion` reads (404 when absent, 200 with the record when present), `DELETE /api/tour/completion` clears (models the restart-tour control). Probe drives a fresh principal through the full sequence (initial absent -> write -> read -> clear -> absent again) instead of de-claiming as `notObservableHere`. first-run-detection and stepper-role-dialog rows keep `notObservableHere` on the browser-only halves but now emit `verdict:'warn'` (never `pass`) so the aggregate correctly reports amber for those AC halves. Anatomy test extended to enumerate the shipped AC/REQ id set and refuse any row whose anchor is not in it, and to accept the conformance-only row shape.
+
+## 1.1.4 - 2026-09-11
+
+- Fixture tour-open runtime condition corrected from `FIRST_RUN || !alreadyDone` to `!alreadyDone` alone per AC-26101-1 (the tour opens on first run once, not any time FIRST_RUN is set past a stored completion). first-run-detection, stepper-role-dialog and completion-persistence probes de-claimed to notObservableHere with their AC anchors (AC-26101-1, AC-26102-1, AC-26104-1) because the observable properties - tour open behaviour, dialog focus lifecycle, focus return, responsive placement, completion write-and-restart-read - are all client-JS-driven and only observable in a browser. checklist-anchor-open remains observed (server-side surfaces the applied-capability-driven checklist state); rule 10 applied to both branches. Positive-anchor-on-absence broken-variant rows removed. Anatomy test extended to accept notObservableHere row shape. Register cleanup.
+
+
+## 1.1.3 - 2026-09-11
+
+- Added a criterion-e probe pack (`contributions/probes/`) covering 4 properties the fixture engine at `packages/rcf-lite/test/fixtures/probe-pack-application-onboarding-tour/server.js` answers: `first-run-detection`, `stepper-role-dialog`, `checklist-anchor-open`, `completion-persistence`. Every response now carries an `x-fixture-request-id` header; probes record the id, the HTTP status and a body excerpt as positive evidence per rule 7d. Fixture README declares every env var the pack reads. Anatomy test at `packages/rcf-lite/test/blueprint/application-onboarding-tour-anatomy.test.js` pins the new pack files and asserts each result carries one of the four 7d evidence shapes.
+
+
 ## 1.1.2 (2026-09-10)
 
 ### Changed
@@ -15,13 +41,13 @@
 
 - Register: neutral wording in shipped prose (no capability change).
 
-## 1.1.0 (2026-09-10, hardening pass)
+## 1.1.0 (2026-09-10)
 
 ### Added
 
-- REQ-005 (dismissal-policy option coverage) and US-26108: dismiss-permanently, dismiss-until-next-major and dismiss-until-next-minor each carry a runtime clause tied to the completion store record shape. This is the section 7c worked example landed as written. Closes review finding [application-onboarding-tour] F-1.
-- REQ-006 (checklist-anchor option coverage) and US-26109: dashboard-top, settings-page and custom-anchor each mount at a resolved slot with a defined default open state; custom-anchor falls back to the settings route on an unresolved/invisible/clipped selector with data-error=CHECKLIST_ANCHOR_UNRESOLVED. Closes review finding [application-onboarding-tour] F-2.
-- Failure-path acceptance criteria on US-26101 (unresolved and clipped anchors, out-of-range step count), US-26102 (dialog-modal role/aria and focus trap with WCAG citation), US-26103 (settings-route fallback), US-26104 (missing-provider refusal, failed write and failed read on the completion store), US-26105 (unparseable completion record), US-26106 (failed clear on restart), US-26107 (polite live-region close announcement). Closes findings F-3 and F-4.
+- REQ-005 (dismissal-policy option coverage) and US-26108: dismiss-permanently, dismiss-until-next-major and dismiss-until-next-minor each carry a runtime clause tied to the completion store record shape. This is the section 7c worked example.
+- REQ-006 (checklist-anchor option coverage) and US-26109: dashboard-top, settings-page and custom-anchor each mount at a resolved slot with a defined default open state; custom-anchor falls back to the settings route on an unresolved/invisible/clipped selector with data-error=CHECKLIST_ANCHOR_UNRESOLVED.
+- Failure-path acceptance criteria on US-26101 (unresolved and clipped anchors, out-of-range step count), US-26102 (dialog-modal role/aria and focus trap with WCAG citation), US-26103 (settings-route fallback), US-26104 (missing-provider refusal, failed write and failed read on the completion store), US-26105 (unparseable completion record), US-26106 (failed clear on restart), US-26107 (polite live-region close announcement).
 - Vendor citations on the ARIA APG dialog-modal, focus-trap and WCAG live-region acceptance criteria (verified 2026-09-10).
 
 ### Changed
@@ -29,7 +55,7 @@
 - Every REQ now carries a deliveredBy link into TAC-2701 (step-runner), TAC-2702 (checklist-slot) or TAC-2703 (completion-store).
 - Every AC on every user story now carries an explicit disposition (fixed or template).
 - TAC-2702 responsibilities extended with resolveAnchor so REQ-006 delivery resolves.
-- Review fix pass (2026-09-10): REQ-001 extended with runtime clauses naming the three string elicits `tour-step-manifest`, `anchor-selectors` and `per-step-content-voice` and their refusal branches; US-26101 gained three template ACs (AC-26101-5, AC-26101-6, AC-26101-7) each carrying an `Applying agent sets: <elicit-id>.` clause; README, guide and CHANGELOG register scrubbed (no work-item ids). Closes review-fix-pass findings F-3, O-4.
+- REQ-001 extended with runtime clauses naming the three string elicits `tour-step-manifest`, `anchor-selectors` and `per-step-content-voice` and their refusal branches; US-26101 gained three template ACs (AC-26101-5, AC-26101-6, AC-26101-7) each carrying an `Applying agent sets: <elicit-id>.` clause.
 
 ## 1.0.0 (visual round, spec 2026-09-06 section 5.5)
 

package/blueprints/application-onboarding-tour/README.md

@@ -33,7 +33,7 @@ No `requiresAppliedCapabilities`: the blueprint has no hard dependency, and the
 
 ## Q4 fallback: completion-state store shape
 
-Q4 of the ratified spec (section 10) settles the completion-state fallback. When no persistence blueprint is applied AND the operator does not answer `completion-state-store` explicitly, the store defaults to `spa-local-storage`: a per-browser record so a returning principal on the same browser is not re-onboarded, and a different browser is re-onboarded. Rationale: a per-session tour that re-plays on every new session is worse than a one-time tour that persists across sessions on that browser; per the elicit surface, the operator can override to `spa-session-storage` (per-session refresh) or `server-side-per-principal` (cross-device; requires an applied persistence blueprint).
+When no persistence blueprint is applied AND the operator does not answer `completion-state-store` explicitly, the store defaults to `spa-local-storage`: a per-browser record so a returning principal on the same browser is not re-onboarded, and a different browser is re-onboarded. Rationale: a per-session tour that re-plays on every new session is worse than a one-time tour that persists across sessions on that browser; per the elicit surface, the operator can override to `spa-session-storage` (per-session refresh) or `server-side-per-principal` (cross-device; requires an applied persistence blueprint).
 
 ## Standards trace
 

package/blueprints/application-onboarding-tour/blueprint.json

@@ -1,6 +1,6 @@
 {
   "slug": "application-onboarding-tour",
-  "version": "1.1.2",
+  "version": "1.1.9",
   "category": "application",
   "elicits": [
     {
@@ -180,5 +180,7 @@
       "elicited": true,
       "standardsTraceClause": "generic enterprise practice"
     }
-  ]
-}
+  ],
+  "updatedAt": "2026-09-12T01:30:44Z",
+  "updatedIso": "2026-09-11T22:30:00Z"
+}

package/blueprints/application-onboarding-tour/contributions/probes/checklist-anchor-open.mjs

@@ -0,0 +1,81 @@
+// application-onboarding-tour probe: checklist collapse contract
+// (AC-26103-1).
+//
+// AC-26103-1 has three observable claims and every one is
+// server-observable in the fixture: (i) when application-dashboard is
+// in the applied set the checklist renders inside a <details open>
+// element on the dashboard-top anchor slot; (ii) when it is NOT in
+// the applied set the checklist renders inside a <details> (closed)
+// element on the settings-page anchor slot; (iii) the <details>
+// element carries data-role="onboarding-tour-checklist" in both
+// branches. The two rows below drive both branches and assert all
+// three claims per the first-eight-words rule (row detail opens on
+// the AC's first eight words verbatim).
+//
+// AC-26103-1 first eight words: "Given the applied capability set includes application-dashboard, the".
+
+import { fixtureFetch, startFixture, excerpt } from './probe-utils.mjs';
+
+export const anchorAcId = 'application-onboarding-tour-AC-26103-1';
+export const accountBound = false;
+
+function parseChecklist(body) {
+  const details = body.match(/<details data-role="onboarding-tour-checklist" data-anchor="([^"]+)"(\s+open)?>/);
+  const section = body.match(/<section data-role="onboarding-tour-checklist" data-anchor="([^"]+)">/);
+  if (details) return { kind: 'details', anchor: details[1], open: !!details[2], dataRolePresent: true };
+  if (section) return { kind: 'section', anchor: section[1], open: false, dataRolePresent: true };
+  return null;
+}
+
+export default async function runProbe() {
+  const fixture = await startFixture();
+  const results = [];
+  try {
+    // Applied-dashboard branch: expect <details open> on dashboard-top with
+    // data-role="onboarding-tour-checklist".
+    const withDash = await fixtureFetch(fixture.url, '/dashboard?apps=application-dashboard');
+    const parsedWith = parseChecklist(withDash.body);
+    const withPass = withDash.status === 200 && !!withDash.requestId
+      && parsedWith && parsedWith.kind === 'details'
+      && parsedWith.anchor === 'dashboard-top' && parsedWith.open === true
+      && parsedWith.dataRolePresent === true;
+    results.push({
+      anchorAcId,
+      verdict: withPass ? 'pass' : 'fail',
+      detail: withPass
+        ? `Given the applied capability set includes application-dashboard, the checklist rendered as <details data-role="onboarding-tour-checklist" data-anchor="dashboard-top" open> at GET /dashboard?apps=application-dashboard (kind=${parsedWith.kind}, anchor=${parsedWith.anchor}, open=${parsedWith.open}, dataRolePresent=${parsedWith.dataRolePresent}); x-fixture-request-id=${withDash.requestId}.`
+        : `Given the applied capability set includes application-dashboard, the AC-26103-1 dashboard-branch observation failed: status=${withDash.status} rid=${withDash.requestId} parsed=${JSON.stringify(parsedWith)}.`,
+      evidence: {
+        requestId: withDash.requestId,
+        responseStatus: withDash.status,
+        bodyExcerpt: excerpt((withDash.body.match(/<details data-role="onboarding-tour-checklist"[^>]{0,140}/) || [''])[0]),
+        derived: { branch: 'application-dashboard-applied', checklist: parsedWith },
+      },
+    });
+
+    // Not-applied branch: expect <details> (closed, no open attribute) on
+    // settings-page with data-role="onboarding-tour-checklist".
+    const noDash = await fixtureFetch(fixture.url, '/settings?apps=');
+    const parsedNo = parseChecklist(noDash.body);
+    const noPass = noDash.status === 200 && !!noDash.requestId
+      && parsedNo && parsedNo.kind === 'details'
+      && parsedNo.anchor === 'settings-page' && parsedNo.open === false
+      && parsedNo.dataRolePresent === true;
+    results.push({
+      anchorAcId,
+      verdict: noPass ? 'pass' : 'fail',
+      detail: noPass
+        ? `Given the applied capability set includes application-dashboard, the complementary NOT-applied branch was observed at GET /settings?apps=: checklist rendered as <details data-role="onboarding-tour-checklist" data-anchor="settings-page"> (kind=${parsedNo.kind}, anchor=${parsedNo.anchor}, open=${parsedNo.open}, dataRolePresent=${parsedNo.dataRolePresent}); x-fixture-request-id=${noDash.requestId}.`
+        : `Given the applied capability set includes application-dashboard, the AC-26103-1 NOT-applied-branch observation failed: status=${noDash.status} rid=${noDash.requestId} parsed=${JSON.stringify(parsedNo)}.`,
+      evidence: {
+        requestId: noDash.requestId,
+        responseStatus: noDash.status,
+        bodyExcerpt: excerpt((noDash.body.match(/<details data-role="onboarding-tour-checklist"[^>]{0,140}/) || [''])[0]),
+        derived: { branch: 'application-dashboard-not-applied', checklist: parsedNo },
+      },
+    });
+  } finally {
+    await fixture.kill();
+  }
+  return { results };
+}

package/blueprints/application-onboarding-tour/contributions/probes/completion-persistence.mjs

@@ -0,0 +1,159 @@
+// application-onboarding-tour probe: completion-state persistence and
+// restart-tour activation (AC-26104-1) - server-side per-principal
+// store (spa-local-storage and spa-session-storage variants are
+// browser only; the server-side-per-principal store IS observable
+// from a Node HTTP probe and this probe drives it via the applied
+// completion API and the progressive-enhancement restart-tour form
+// action, both of which are the fixture's own engine).
+//
+// AC-26104-1 first eight words: "Given a completed tour, the completion state persists".
+//
+// Server-observable steps this probe drives:
+//   1. Fresh principalId: GET /api/tour/completion returns 404.
+//   2. GET /tour renders data-tour-first-run="true" for the fresh
+//      principal (the server-side first-run flag is derived from the
+//      applied completion store on server render).
+//   3. POST /api/tour/completion writes a record: 200 with the record
+//      echoed.
+//   4. GET /api/tour/completion returns 200 with the same record
+//      (persistence across requests, i.e. the "restart read"): this
+//      is the server-side persistence half of the AC.
+//   5. GET /tour then renders data-tour-first-run="false" (the
+//      completion feeds the server-derived first-run flag on the next
+//      principal load).
+//   6. GET /settings renders the restart-tour control inside a
+//      <form method="post" action="/actions/restart-tour"> with the
+//      principal-id in a hidden input (progressive enhancement:
+//      activating the control POSTs the form even when JS is off).
+//   7. POST /actions/restart-tour (the form submission the settings
+//      restart control drives) returns 200 { ok:true, cleared:true }
+//      and clears the server-side record.
+//   8. GET /api/tour/completion returns 404 again (record cleared by
+//      the restart-control activation).
+//   9. GET /tour then renders data-tour-first-run="true" (the tour
+//      re-opens on the next principal load, per AC-26104-1's
+//      "activating the control ... re-opens the tour on the next
+//      principal load" clause).
+// Every step varies inputs (principalId is a fresh UUID, the record
+// carries a distinct completedAt ISO) and asserts derived outputs
+// the fixture had no choice about (the record echoed back, the
+// data-tour-first-run flag flipping, the form-action response
+// carrying cleared=true).
+//
+// The dialog-open behaviour and keyboard-only walk asked for by
+// AC-26101-1 / AC-26102-1 are browser-only and covered by
+// first-run-detection and stepper-role-dialog. This probe now
+// observes AC-26104-1's persistence AND the server-observable half
+// of the restart-tour activation (the form action the button fires
+// server-side).
+
+import { fixtureFetch, startFixture, excerpt } from './probe-utils.mjs';
+import { randomUUID } from 'node:crypto';
+
+export const anchorAcId = 'application-onboarding-tour-AC-26104-1';
+export const accountBound = false;
+
+const FIRST_EIGHT = 'Given a completed tour, the completion state persists';
+
+export default async function runProbe() {
+  const fixture = await startFixture({ env: { TOUR_STORE: 'server-side-per-principal' } });
+  const results = [];
+  try {
+    const principalId = 'probe-tour-' + randomUUID();
+    const completedAt = new Date().toISOString();
+    const store = 'server-side-per-principal';
+    // Step 1a: initial completion GET is 404 (no record for this principal).
+    const initial = await fixtureFetch(fixture.url, `/api/tour/completion?principal-id=${principalId}&store=${store}`);
+    const initialBody = JSON.parse(initial.body || '{}');
+    // Step 1b: initial /tour render shows data-tour-first-run="true" for the
+    // fresh principal (server-derived from the empty completion store).
+    const initialTour = await fixtureFetch(fixture.url, `/tour?store=${store}&principal-id=${principalId}`);
+    const initialFirstRunTrue = /data-tour-first-run="true"/.test(initialTour.body)
+      && new RegExp(`data-tour-principal-id="${principalId}"`).test(initialTour.body);
+    // Step 2: POST completion.
+    const writeRes = await fixtureFetch(fixture.url, `/api/tour/completion?principal-id=${principalId}&store=${store}`, {
+      method: 'POST',
+      headers: { 'content-type': 'application/json' },
+      body: JSON.stringify({ completedAt, blueprintSetVersion: '1.0.0', stepIds: ['step-1', 'step-2', 'step-3'] }),
+    });
+    const writeBody = JSON.parse(writeRes.body || '{}');
+    // Step 3a: completion GET reflects the written record (server-scoped
+    // persistence across requests).
+    const readRes = await fixtureFetch(fixture.url, `/api/tour/completion?principal-id=${principalId}&store=${store}`);
+    const readBody = JSON.parse(readRes.body || '{}');
+    // Step 3b: /tour render for the same principal now shows
+    // data-tour-first-run="false" (the completion feeds the server-derived
+    // first-run flag on the next principal load).
+    const afterWriteTour = await fixtureFetch(fixture.url, `/tour?store=${store}&principal-id=${principalId}`);
+    const afterWriteFirstRunFalse = /data-tour-first-run="false"/.test(afterWriteTour.body);
+    // Step 4: settings surface reachable and the restart-tour control
+    // is inside a POST form pointing at /actions/restart-tour with the
+    // principal-id in a hidden input (progressive-enhancement: this is
+    // what activating the button does on the server, regardless of JS).
+    const settings = await fixtureFetch(fixture.url, `/settings?store=${store}&principal-id=${principalId}`);
+    const restartFormActionMatch = settings.body.match(/<form[^>]*method="post"[^>]*action="\/actions\/restart-tour[^"]*"[^>]*>[\s\S]*?<button[^>]*data-action="restart-tour"[\s\S]*?<\/form>/i);
+    const settingsCarriesRestartForm = !!restartFormActionMatch
+      && new RegExp(`name="principal-id"[^>]*value="${principalId}"`).test(restartFormActionMatch[0]);
+    const settingsReachable = settings.status === 200 && !!settings.requestId && settingsCarriesRestartForm;
+    // Step 5: POST /actions/restart-tour (the form submission the
+    // restart control fires). This is the server-observable "restart
+    // control activation" - the same POST fires whether the click was
+    // JS-driven or a plain form submit.
+    const restartRes = await fixtureFetch(fixture.url, `/actions/restart-tour?principal-id=${principalId}&store=${store}`, { method: 'POST' });
+    let restartBody = {};
+    try { restartBody = JSON.parse(restartRes.body || '{}'); } catch (_) { /* body parse */ }
+    // Step 6a: completion GET after restart-control activation returns 404 again.
+    const afterClear = await fixtureFetch(fixture.url, `/api/tour/completion?principal-id=${principalId}&store=${store}`);
+    const afterClearBody = JSON.parse(afterClear.body || '{}');
+    // Step 6b: /tour render for the same principal returns to
+    // data-tour-first-run="true" (the restart activation re-opens the
+    // tour on the next principal load, per AC-26104-1).
+    const afterClearTour = await fixtureFetch(fixture.url, `/tour?store=${store}&principal-id=${principalId}`);
+    const afterClearFirstRunTrue = /data-tour-first-run="true"/.test(afterClearTour.body);
+
+    const writePass = writeRes.status === 200 && writeBody.ok === true
+      && writeBody.record && writeBody.record.completedAt === completedAt;
+    const readPass = readRes.status === 200 && readBody.completed === true
+      && readBody.record && readBody.record.completedAt === completedAt
+      && Array.isArray(readBody.record.stepIds) && readBody.record.stepIds.length === 3;
+    const restartActivationPass = restartRes.status === 200 && restartBody.ok === true
+      && restartBody.principalId === principalId && restartBody.cleared === true
+      && restartBody.restartControl === 'restart-tour';
+    const initialAbsent = initial.status === 404 && initialBody.completed === false;
+    const afterClearAbsent = afterClear.status === 404 && afterClearBody.completed === false;
+    const pass = !!initial.requestId && !!writeRes.requestId && !!readRes.requestId && !!restartRes.requestId && !!afterClear.requestId && !!afterClearTour.requestId
+      && initialAbsent && writePass && readPass && settingsReachable && restartActivationPass && afterClearAbsent
+      && initialFirstRunTrue && afterWriteFirstRunFalse && afterClearFirstRunTrue;
+
+    results.push({
+      anchorAcId,
+      verdict: pass ? 'pass' : 'fail',
+      detail: pass
+        ? `${FIRST_EIGHT} for a fresh principalId ${principalId} under completion-state-store server-side-per-principal: initial completion GET returned 404 and the /tour render carried data-tour-first-run="true"; POST wrote a record with completedAt=${completedAt} and 3 stepIds; a subsequent completion GET returned the same record (persistence across requests) and the /tour render carried data-tour-first-run="false" (the completion feeds the server-derived first-run flag on the next principal load); the /settings render carried a <form method="post" action="/actions/restart-tour"> wrapping the data-action="restart-tour" button with the principal-id in a hidden input; POST /actions/restart-tour returned 200 { ok:true, cleared:true, principalId, restartControl:"restart-tour" } (the restart-control activation cleared the applied server-side store); a further completion GET returned 404 and the /tour render returned to data-tour-first-run="true" (the restart activation re-opens the tour on the next principal load); x-fixture-request-id (final)=${afterClearTour.requestId}`
+        : `${FIRST_EIGHT} evidence gap: initial=${initial.status}/${initialAbsent} initialFirstRunTrue=${initialFirstRunTrue} write=${writeRes.status}/${writePass} read=${readRes.status}/${readPass} afterWriteFirstRunFalse=${afterWriteFirstRunFalse} settings=${settings.status}/${settingsReachable} restart=${restartRes.status}/${restartActivationPass} afterClear=${afterClear.status}/${afterClearAbsent} afterClearFirstRunTrue=${afterClearFirstRunTrue}`,
+      evidence: {
+        requestId: afterClearTour.requestId,
+        responseStatus: afterClearTour.status,
+        bodyExcerpt: excerpt(JSON.stringify({ initial: initialBody, write: writeBody, read: readBody, restart: restartBody, afterClear: afterClearBody, firstRun: { initialFirstRunTrue, afterWriteFirstRunFalse, afterClearFirstRunTrue } })),
+        derived: {
+          principalId,
+          completedAt,
+          initialAbsent,
+          writePass,
+          readPass,
+          settingsReachable,
+          restartActivationPass,
+          afterClearAbsent,
+          initialFirstRunTrue,
+          afterWriteFirstRunFalse,
+          afterClearFirstRunTrue,
+          restartFormAction: '/actions/restart-tour',
+          restartRequestId: restartRes.requestId,
+        },
+      },
+    });
+  } finally {
+    await fixture.kill();
+  }
+  return { results };
+}

package/blueprints/application-onboarding-tour/contributions/probes/first-run-detection.mjs

@@ -0,0 +1,67 @@
+// application-onboarding-tour probe: first-run tour open (AC-26101-1).
+//
+// AC-26101-1 requires observing the tour dialog opening on the SPA
+// for a first-run principal, Escape dismissing the tooltip, and a
+// keyboard-only walk of the tour controls (WCAG 2.1.1, 2.1.2, 2.4.3).
+// Every one of those assertions is browser-only: the tour tooltip is
+// created by client script in the DOM, focus movement and Escape
+// dismissal are browser events, and no server-side marker in this
+// fixture represents the dialog-open state. Attempting to observe
+// the tour open from a fixture HTTP response would only inspect the
+// script's source text, not the dialog itself, so this probe emits
+// notObservableHere rows naming AC-26101-1 and defers the observed
+// assertion to the pack's browser check.
+//
+// The fixture is still spun up so the run record proves the fixture
+// answers the route, matching the pack's environment expectations.
+//
+// AC-26101-1 first eight words: "Given a first-run principal on the SPA, the".
+
+import { fixtureFetch, startFixture } from './probe-utils.mjs';
+
+export const anchorAcId = 'application-onboarding-tour-AC-26101-1';
+export const accountBound = false;
+
+export default async function runProbe() {
+  const fixture = await startFixture();
+  const results = [];
+  try {
+    // Prove the fixture is answering the SPA route before deferring the
+    // observation to the browser check; the response itself carries no
+    // AC-observable content.
+    for (const route of ['/tour', '/onboarding', '/welcome']) {
+      const res = await fixtureFetch(fixture.url, route);
+      const reachable = res.status === 200 && !!res.requestId;
+      results.push({
+        anchorAcId,
+        notObservableAcId: anchorAcId,
+        verdict: 'warn',
+        notObservableHere: true,
+        reason: 'AC-26101-1 requires observing the tour dialog opening on the SPA, focus movement to the tooltip, and Escape dismissing the dialog on a keyboard-only walk; those are DOM/browser events created by client script and cannot be observed from a fixture HTTP response body. The tour open is deferred to the browser check in application-onboarding-tour.pack.mjs.',
+        detail: `Given a first-run principal on the SPA, the tour-open assertion is browser-only for route ${route}; fixture reachability confirmed (status=${res.status}, requestId=${res.requestId || 'absent'}, reachable=${reachable}).`,
+      });
+    }
+    // Returning-principal suppression (a stored completion record must
+    // suppress the auto-open on the SPA) is AC-26104-1's clause, not
+    // AC-26101-1's. The server-side half of that AC (the completion
+    // store and the /tour data-tour-first-run="false" flag it drives on
+    // the next principal load) is observed positively by the
+    // completion-persistence probe. The client-side auto-open
+    // suppression itself (the JS-driven decision on the SPA) is
+    // browser-only; recorded here as notObservableHere against
+    // AC-26104-1 (the AC the suppression belongs to) so the operator
+    // sees the browser-only gap.
+    const suppressionAcId = 'application-onboarding-tour-AC-26104-1';
+    results.push({
+      anchorAcId: suppressionAcId,
+      notObservableAcId: suppressionAcId,
+      verdict: 'warn',
+      notObservableHere: true,
+      reason: 'AC-26104-1 requires that activating the restart-tour control clears the completion state and re-opens the tour on the next principal load; the server-observable half (server-side completion store + data-tour-first-run flag on /tour + the /actions/restart-tour form action) is covered positively by completion-persistence. The client-JS-driven auto-open suppression on the SPA (readCompletion -> !alreadyDone -> openStep(0)) is browser-only and cannot be observed from a fixture HTTP response. Deferred to the browser check.',
+      detail: 'Given a completed tour, the completion state persists per principal in the applied store; the client-side auto-open suppression branch (a stored completion record stops the client script re-opening the tour on the SPA) is browser-only. The server-side half of AC-26104-1 is positively observed by completion-persistence; this row records the client-only gap explicitly.',
+    });
+  } finally {
+    await fixture.kill();
+  }
+  return { results };
+}