rcf-lite 0.27.0 → 0.28.1

package/blueprints/application-notifications-in-app/contributions/probes/probe-utils.mjs

@@ -0,0 +1,177 @@
+// Shared helpers for application-notifications-in-app contributions/probes/.
+//
+// The real engine for every probe in this pack is the fixture HTTP
+// server at packages/rcf-lite/test/fixtures/probe-pack-application-notifications-in-app/server.js
+// booted on a scratch port from the family range 47640-47649.
+// The fixture echoes a per-request x-fixture-request-id header on
+// every response; probes record that id and a response body excerpt
+// as positive evidence per rule 7d.
+//
+// No account credentials or network calls: every probe is
+// local-fixture-driven, so no probe carries an account-bound branch
+// or a CI_HAS_* gate. Declared env vars are the fixture's own
+// PORT and (where the fixture reads them) the CAPS/state switches
+// the probes drive via query string.
+
+import { spawn } from 'node:child_process';
+import { mkdir, writeFile } from 'node:fs/promises';
+import { createServer } from 'node:net';
+import { dirname, resolve } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const HERE = dirname(fileURLToPath(import.meta.url));
+
+export const SLUG = 'application-notifications-in-app';
+export const PROJECT_ROOT = resolve(HERE, '..', '..', '..', '..');
+export const FIXTURE_DIR = resolve(PROJECT_ROOT, 'packages/rcf-lite/test/fixtures/probe-pack-application-notifications-in-app');
+export const REPORT_DIR = resolve(PROJECT_ROOT, '.rcf/reports/blueprints/application-notifications-in-app');
+export const PORT_RANGE_START = 47640;
+export const PORT_RANGE_END = 47649;
+export const DECLARED_ENV = Object.freeze(['PORT', 'PROBE_BREAK']);
+export const REQUEST_ID_HEADER = 'x-fixture-request-id';
+
+// Pick a free port from the fixture family range. Falls back to
+// asking the OS for an ephemeral port only if the whole range is
+// held by other workers (never expected on a single-machine run).
+export async function pickPort() {
+  for (let port = PORT_RANGE_START; port <= PORT_RANGE_END; port += 1) {
+    if (await canBind(port)) return port;
+  }
+  return await bindEphemeral();
+}
+
+function canBind(port) {
+  return new Promise((res) => {
+    const s = createServer();
+    s.once('error', () => res(false));
+    s.listen(port, '127.0.0.1', () => {
+      const bound = s.address();
+      s.close(() => res(!!bound));
+    });
+  });
+}
+
+function bindEphemeral() {
+  return new Promise((res) => {
+    const s = createServer();
+    s.listen(0, '127.0.0.1', () => {
+      const port = s.address().port;
+      s.close(() => res(port));
+    });
+  });
+}
+
+// Spawns the fixture server as a child on `port` with the given
+// env overlay; resolves once the fixture has printed LISTENING and
+// returns { child, url, kill } (kill is synchronous best-effort).
+export async function startFixture({ port, env = {} } = {}) {
+  const boundPort = port ?? await pickPort();
+  const child = spawn(process.execPath, ['server.js'], {
+    cwd: FIXTURE_DIR,
+    env: { ...process.env, PORT: String(boundPort), ...env },
+    stdio: ['ignore', 'pipe', 'pipe'],
+  });
+  await new Promise((res, rej) => {
+    const timer = setTimeout(() => rej(new Error(`fixture did not print LISTENING within 4s on port ${boundPort}`)), 4000);
+    let stderrBuf = '';
+    child.stderr.on('data', (chunk) => { stderrBuf += String(chunk); });
+    child.on('exit', (code) => rej(new Error(`fixture exited early (code=${code}) stderr=${stderrBuf.slice(0, 400)}`)));
+    child.stdout.on('data', (chunk) => {
+      if (String(chunk).includes(`LISTENING ${boundPort}`)) { clearTimeout(timer); res(); }
+    });
+  });
+  const url = new URL(`http://127.0.0.1:${boundPort}`);
+  return {
+    child,
+    url,
+    port: boundPort,
+    // Await child exit and propagate any error. A teardown failure
+    // must fail the verdict (the teardown-propagation rule);
+    // no swallowed errors here.
+    kill: () => new Promise((res, rej) => {
+      let settled = false;
+      const done = (err) => { if (settled) return; settled = true; err ? rej(err) : res(); };
+      child.once('exit', () => done());
+      child.once('error', (err) => done(err));
+      try { child.kill('SIGTERM'); } catch (err) { return done(err); }
+      setTimeout(() => {
+        if (settled) return;
+        try { child.kill('SIGKILL'); } catch (err) { return done(err); }
+      }, 4000);
+    }),
+  };
+}
+
+// Issue an HTTP request against the fixture and return
+// { status, headers, body, requestId }.
+export async function fixtureFetch(url, pathAndQuery, init = {}) {
+  const target = new URL(pathAndQuery, url);
+  const res = await fetch(target, init);
+  const body = await res.text();
+  const requestId = res.headers.get(REQUEST_ID_HEADER);
+  return { status: res.status, headers: Object.fromEntries(res.headers.entries()), body, requestId };
+}
+
+export function excerpt(body, maxLen = 240) {
+  if (typeof body !== 'string') return '';
+  return body.length <= maxLen ? body : body.slice(0, maxLen) + '…';
+}
+
+export function aggregate(results) {
+  // Positive-evidence rule: no-checks-ran is a fail.
+  if (!Array.isArray(results) || results.length === 0) return 'fail';
+  if (results.some((r) => r.verdict === 'fail')) return 'fail';
+  // Any warn row lifts the aggregate to warn, including honest
+  // notObservableHere de-claims. A probe whose rows are all warn
+  // aggregates to warn, not pass; the shelf reads amber and the tally
+  // accepts a warn aggregate as problems=0 when no fail row is present.
+  if (results.some((r) => r && r.verdict === 'warn')) return 'warn';
+  return 'pass';
+}
+
+export async function writeReport({ probeName, engine, results, extra }) {
+  await mkdir(REPORT_DIR, { recursive: true });
+  const report = {
+    slug: SLUG,
+    probeName,
+    runAt: new Date().toISOString(),
+    engine,
+    results,
+    aggregateVerdict: aggregate(results),
+    ...(extra ?? {}),
+  };
+  const filepath = resolve(REPORT_DIR, `${probeName}.json`);
+  await writeFile(filepath, JSON.stringify(report, null, 2) + '\n', 'utf8');
+  return { report, path: filepath };
+}
+
+export async function runShim(probeName, engine, mainFn) {
+  try {
+    const outcome = (await mainFn()) ?? { results: [] };
+    const { results, extra } = outcome;
+    const { report, path: filepath } = await writeReport({ probeName, engine, results, extra });
+    process.stdout.write(JSON.stringify(report, null, 2) + '\n');
+    process.stdout.write(`report written to ${filepath}\n`);
+    if (report.aggregateVerdict === 'fail') process.exitCode = 1;
+  } catch (err) {
+    // Positive-evidence rule (exception fallback): exception rows have no
+    // observed AC; anchor null (never a fabricated id like
+    // "unknown"), carry an evidence object with the error excerpt.
+    const message = err && err.message ? err.message : String(err);
+    const stack = err && err.stack ? err.stack : String(err);
+    const results = [{
+      anchorAcId: null,
+      verdict: 'fail',
+      detail: `probe threw: ${message}`,
+      evidence: {
+        errorMessage: message,
+        errorExcerpt: excerpt(stack, 480),
+      },
+    }];
+    const { report, path: filepath } = await writeReport({ probeName, engine, results });
+    process.stdout.write(JSON.stringify(report, null, 2) + '\n');
+    process.stderr.write(`probe error: ${stack}\n`);
+    process.stderr.write(`report written to ${filepath}\n`);
+    process.exitCode = 1;
+  }
+}

package/blueprints/application-notifications-in-app/contributions/probes/run-centre-acknowledge-round-trip.mjs

@@ -0,0 +1,5 @@
+import runProbe from './centre-acknowledge-round-trip.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('centre-acknowledge-round-trip', engine, runProbe);

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 };
+}