rcf-lite 0.27.0 → 0.28.1

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

package/blueprints/application-onboarding-tour/contributions/probes/probe-utils.mjs

@@ -0,0 +1,177 @@
+// Shared helpers for application-onboarding-tour 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-onboarding-tour/server.js
+// booted on a scratch port from the family range 47610-47619.
+// 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-onboarding-tour';
+export const PROJECT_ROOT = resolve(HERE, '..', '..', '..', '..');
+export const FIXTURE_DIR = resolve(PROJECT_ROOT, 'packages/rcf-lite/test/fixtures/probe-pack-application-onboarding-tour');
+export const REPORT_DIR = resolve(PROJECT_ROOT, '.rcf/reports/blueprints/application-onboarding-tour');
+export const PORT_RANGE_START = 47610;
+export const PORT_RANGE_END = 47619;
+export const DECLARED_ENV = Object.freeze(['PORT', 'TOUR_APPS', 'TOUR_STORE', 'TOUR_ANCHOR', '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-onboarding-tour/contributions/probes/run-checklist-anchor-open.mjs

@@ -0,0 +1,5 @@
+import runProbe from './checklist-anchor-open.mjs';
+import { runShim } from './probe-utils.mjs';
+
+const engine = { kind: 'fixture', image: 'test/fixtures/probe-pack-application-onboarding-tour/server.js', healthy: true };
+runShim('checklist-anchor-open', engine, runProbe);

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

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

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

@@ -0,0 +1,5 @@
+import runProbe from './first-run-detection.mjs';
+import { runShim } from './probe-utils.mjs';
+
+const engine = { kind: 'fixture', image: 'test/fixtures/probe-pack-application-onboarding-tour/server.js', healthy: true };
+runShim('first-run-detection', engine, runProbe);

package/blueprints/application-onboarding-tour/contributions/probes/run-stepper-role-dialog.mjs

@@ -0,0 +1,5 @@
+import runProbe from './stepper-role-dialog.mjs';
+import { runShim } from './probe-utils.mjs';
+
+const engine = { kind: 'fixture', image: 'test/fixtures/probe-pack-application-onboarding-tour/server.js', healthy: true };
+runShim('stepper-role-dialog', engine, runProbe);

package/blueprints/application-onboarding-tour/contributions/probes/stepper-role-dialog.mjs

@@ -0,0 +1,45 @@
+// application-onboarding-tour probe: step tooltip dialog contract
+// (AC-26102-1).
+//
+// AC-26102-1 requires observing a rendered tooltip dialog: focus
+// moves to the tooltip on open, role="dialog" plus aria-labelledby
+// point at the step heading, focus returns to the anchor on close
+// (Escape or dismiss control) per the ARIA APG dialog-modal pattern,
+// and the dialog remains within the viewport at the 1440 wide and 360
+// narrow breakpoints (WCAG 2.4.11 Focus Not Obscured Minimum). Every
+// assertion is browser-only: the tooltip is created by client script
+// in the DOM, focus movement and Escape handling are browser events,
+// and the responsive placement check requires a real viewport. This
+// probe records the non-observation and defers the observed
+// assertion to the pack's browser check (which uses
+// browser.resize(1440) and browser.resize(360) as the anatomy test
+// requires).
+//
+// AC-26102-1 first eight words: "Given a step showing a tooltip anchored to".
+
+import { fixtureFetch, startFixture } from './probe-utils.mjs';
+
+export const anchorAcId = 'application-onboarding-tour-AC-26102-1';
+export const accountBound = false;
+
+export default async function runProbe() {
+  const fixture = await startFixture();
+  const results = [];
+  try {
+    // Fixture reachability at /tour, recorded to prove the pack
+    // environment is honest before the browser check runs.
+    const res = await fixtureFetch(fixture.url, '/tour');
+    const reachable = res.status === 200 && !!res.requestId;
+    results.push({
+      anchorAcId,
+      notObservableAcId: anchorAcId,
+      verdict: 'warn',
+      notObservableHere: true,
+      reason: 'AC-26102-1 requires observing focus movement to the tooltip on open, role="dialog" plus aria-labelledby present on the rendered element, focus return to the anchor on close, and the dialog remaining within the viewport at 1440 and 360 breakpoints. All four assertions are browser-only: the tooltip is created by client script in the DOM, focus and Escape are browser events, and the placement check requires a real viewport. Deferred to the browser check in application-onboarding-tour.pack.mjs.',
+      detail: `Given a step showing a tooltip anchored to a UI element, the tooltip-render, focus-lifecycle, and viewport-placement assertions are browser-only; fixture reachability confirmed (status=${res.status}, requestId=${res.requestId || 'absent'}, reachable=${reachable}).`,
+    });
+  } finally {
+    await fixture.kill();
+  }
+  return { results };
+}

package/blueprints/application-spa/CHANGELOG.md

@@ -1,30 +1,39 @@
 # application-spa CHANGELOG
 
+## 1.5.11 - 2026-09-11
+
+- Adds a contributions/probes pack meeting rule 7d: each probe drives a real HTTP round trip against the dependency-free sample-app fixture at packages/rcf-lite/test/fixtures/probe-pack-application-spa/ and records the fixture-echoed x-fixture-request-id, response status, a distinctive body excerpt, the varied input and the derived output on every result row.
+- Probes: route-inventory-published, shell-nav-present, designed-empty-state.
+- Route-inventory probe injects two independent route sets into startServer({ routes }); reads /__routes and /__mounted for each; asserts both endpoints follow the injected input verbatim; asserts declared paths respond 200 and out-of-inventory paths return 404. Route inventory completeness is derived from probe-controlled input, not from fixture self-agreement.
+- Fixture README declares every env var the probes read (PORT, PROBE_PORT in the reserved 47300-47399 range). No account-bound branch: the engine is a local fixture.
+- Empty results now fail with detail "no checks ran"; anatomy test asserts each result carries evidence with a non-empty x-fixture-request-id AND a body excerpt or derived value, or an honest notObservableHere / accountBoundSkipped row carrying a shipped AC id; status zero never counts; {} is rejected as a populated derived value.
+- notObservableHere rows anchor nothing else (no anchorAcId, no anchorReqId); conformanceOnly rows carry a limitation naming the specific AC id and the property not observed.
+- Anatomy test pin bumped to 1.5.11 (probe modules, run-*.mjs wrappers, probe-utils.mjs helper, anchorReqId cross-check against contributed REQs, fixture env-var declaration).
+
+
 ## 1.5.6 - 2026-09-10
 
-Findings closed: F-3, F-4, F-5, F-6, F-7, F-8, F-9. Template-AC fill-in clauses on AC-1101-1, AC-1102-3, AC-1106-2, AC-1114-1 and AC-1131-3 now enumerate the specific applying-project substitutions (route inventory location, secondary-navigation toggle and breakpoint, semantic-token file and added keys, journey inventory and per-step states, UI-bearing routes and strict-CSP header set) in place of the generic "project-specific bindings, routes, thresholds, budgets, and names" phrasing. Register cleanup on the AC-1131-3 description (partial-acceptance defect described without prior-review internal identifiers) and on README shipped prose (removed prior-review internal identifiers, the numbered ratified-decision reference, and the dated ratified-policy reference).
+Template-AC fill-in clauses on AC-1101-1, AC-1102-3, AC-1106-2, AC-1114-1 and AC-1131-3 now enumerate the specific applying-project substitutions (route inventory location, secondary-navigation toggle and breakpoint, semantic-token file and added keys, journey inventory and per-step states, UI-bearing routes and strict-CSP header set) in place of the earlier generic "project-specific bindings, routes, thresholds, budgets, and names" phrasing, so applying projects have precise values to fill in.
 
 
 ## 1.5.5 - 2026-09-10
 
-Second closure fix on the dimension-d ownership sweep: REQ-009 no longer defines the deep-link return-to behaviour, referencing the owner at `TAC-201-application-spa-app-shell.responsibilities[5]` instead; `deliveredBy.field` re-pointed at `responsibilities[5]` (was generic `responsibilities`). Corrected the 1.5.4 changelog line that recorded the obsolete `responsibilities[0]` ownerRef for AC-1135-2 to `responsibilities[5]`. REQ-009 patch-bumped. Chain-consistency lint zero on pass 1 and pass 2.
+Dimension-d single-definition-ownership cleanup on REQ-009: REQ description now references the deep-link return-to behaviour owned on `TAC-201-application-spa-app-shell.responsibilities[5]` rather than restating it; `deliveredBy.field` re-pointed at `responsibilities[5]` (was generic `responsibilities`). Corrected the 1.5.4 changelog line that recorded the obsolete `responsibilities[0]` ownerRef for AC-1135-2 to `responsibilities[5]`. REQ-009 patch-bumped. Chain-consistency lint clean.
 
 ## 1.5.4 - 2026-09-10
 
-Dimension-b acceptance-criteria-sufficiency cleanup on US-1134 and US-1135: each story previously shipped a single AC. AC-1134-2 added to bind the icon-adherence probe refusal path on inline-SVG or unknown-alias violations against the primary-navigation slot (ownerRef TAC-208.interfaces.runIconAdherenceProbe). AC-1135-2 added to bind the signed-in and post-sign-out deep-link preservation and return-to flow on the app shell (ownerRef TAC-201.responsibilities[5]). Chain-consistency lint zero on pass 1 and pass 2.
+Dimension-b acceptance-criteria-sufficiency cleanup on US-1134 and US-1135: each story previously shipped a single AC. AC-1134-2 added to bind the icon-adherence probe refusal path on inline-SVG or unknown-alias violations against the primary-navigation slot (ownerRef TAC-208.interfaces.runIconAdherenceProbe). AC-1135-2 added to bind the signed-in and post-sign-out deep-link preservation and return-to flow on the app shell (ownerRef TAC-201.responsibilities[5]). Chain-consistency lint clean.
 
 ## 1.5.3 (register-sweep patch, 2026-09-10)
 
 - Register: neutral wording in shipped prose (no capability change).
 
-## 1.5.2 (application-core completion pass, 2026-09-09)
-
-- Donor hand-sweep on all 197 ACs: flipped 19 additional ACs from fixed to template where the assertion carries a project-set literal (per-project section inventories, viewport table widths, journey-inventory checkpoints and events, per-route empty-state text, cache-invalidation entry sets, canonical URL shapes cache keys derive from, offline telemetry buffer bound N, per-route payload budgets, external-dependency inventory, deferral-record path and metadata, core-flow definitions, plus the two review-fix-pass flips on AC-1111-5 tablist activation mode and AC-1116-2 journey preservation set). Each flipped AC carries an Applying agent sets: <specific values> clause. Final split: 173 fixed / 24 template.
-- Review fix pass 2026-09-10: F-1 vendorCitation added to AC-1126-4 (WCAG 2.5.8 target-size-minimum) and AC-1126-7 (WCAG 2.2 recommendation); F-2 completion sweep flipped AC-1111-5 and AC-1116-2 to template with Applying agent sets clauses; F-6 internal work-item ids stripped from README v1.2.0 and v1.3.0 changelog paragraphs, from TAC-209 responsibility and tradeoffs, from TAC-210 and TAC-211 purpose, and from AC-1131-3 (the class defect is named without the internal id); F-7 spa guide counts corrected to 76 documents / 35 user stories / 197 acceptance criteria.
-
-## 1.5.1 (application-core hardening, 2026-09-09)
+## 1.5.2 (2026-09-09)
 
-- hardening pass: chain-consistency lint zero (pass1 + pass2); added deliveredBy to every REQ pointing at a TAC responsibility or interface, added ownerRef and disposition to every AC per section 7b, closed case drifts on `content-security-policy` in REQ-018, AC-1125-1 and AC-1131-1 to match the owner spelling on TAC-209.
-- Added AC-1123-6 (telemetry buffer overflow with drop-oldest and drop-count observability on reconnect) covering the 2026-09-08 review finding F-1 on TAC-206.responsibilities[3], and AC-1107-6 (theme persistence failure: visible session-only theme, aria-live unsaved announcement, no persisted preference) covering F-2 on TAC-202.responsibilities[2].
+- Donor hand-sweep on all 197 ACs: flipped 19 additional ACs from fixed to template where the assertion carries a project-set literal (per-project section inventories, viewport table widths, journey-inventory checkpoints and events, per-route empty-state text, cache-invalidation entry sets, canonical URL shapes cache keys derive from, offline telemetry buffer bound N, per-route payload budgets, external-dependency inventory, deferral-record path and metadata, core-flow definitions, plus the AC-1111-5 tablist activation mode flip and the AC-1116-2 journey preservation set flip). Each flipped AC carries an Applying agent sets: <specific values> clause. Final split: 173 fixed / 24 template.
+- Register-and-citation sweep 2026-09-10: vendorCitation added to AC-1126-4 (WCAG 2.5.8 target-size-minimum) and AC-1126-7 (WCAG 2.2 recommendation); the completion sweep flipped AC-1111-5 and AC-1116-2 to template with Applying agent sets clauses; internal work-item ids stripped from README v1.2.0 and v1.3.0 changelog paragraphs, from TAC-209 responsibility and tradeoffs, from TAC-210 and TAC-211 purpose, and from AC-1131-3 (the class defect is named without the internal id); spa guide counts corrected to 76 documents / 35 user stories / 197 acceptance criteria.
 
+## 1.5.1 (2026-09-09)
 
+- Hardening cleanup: chain-consistency lint clean; added deliveredBy to every REQ pointing at a TAC responsibility or interface, added ownerRef and disposition to every AC per section 7b, closed case drifts on `content-security-policy` in REQ-018, AC-1125-1 and AC-1131-1 to match the owner spelling on TAC-209.
+- Added AC-1123-6 (telemetry buffer overflow with drop-oldest and drop-count observability on reconnect) on TAC-206.responsibilities[3], and AC-1107-6 (theme persistence failure: visible session-only theme, aria-live unsaved announcement, no persisted preference) on TAC-202.responsibilities[2], so applying projects have explicit acceptance criteria for both failure paths.

package/blueprints/application-spa/README.md

@@ -1,6 +1,6 @@
 # application-spa blueprint (v1.5.6)
 
-The first content blueprint on the rcf-build-lite blueprint mechanism (design brief v2, ratified). Scope: single-page applications with public and authenticated surfaces, session-based auth, single deployable, dark and light by default, fully responsive by default.
+Scope: single-page applications with public and authenticated surfaces, session-based auth, single deployable, dark and light by default, fully responsive by default.
 
 ## Apply
 
@@ -20,7 +20,7 @@ Phase 1 resolves local path sources only; registry and git-ref resolution is a m
 | Stylesheet | `assets/tokens/theme.css` | The tokens realised as CSS custom properties with the theme-switch, focus, and reduced-motion machinery |
 | Wireframes | `assets/wireframes/` | Nine canonical surfaces: dashboard, list, detail, form, empty, error, sign-in, sign-out, session-expired |
 | Component specs | `assets/component-specs/` | Behaviour contracts for the full application-spa-REQ-006 component inventory |
-| Viewport table | `assets/viewports.md` | The ratified 360/768/1024/1440 baseline and per-breakpoint layout rules |
+| Viewport table | `assets/viewports.md` | The shipped 360/768/1024/1440 baseline and per-breakpoint layout rules |
 | Sample data | `assets/sample-data/` | Neutral entities for skeletons, wireframe realisation, and state demos |
 | Guide | `guide/application-spa.md` | Operator-facing: when to use it, when not, what stays your call |
 | Coordination vocabulary | `docs/topics.md` | Exact global-topic strings and id number bands for composing blueprints |
@@ -29,21 +29,20 @@ The doc set is contributions (copied into the project tree by `rcf define bluepr
 
 ## What it contributes, and what it deliberately does not
 
-Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (a ratified shelf-wide policy) and no code.
+Contributed kinds: REQ, US (with inline ACs), TAC, ADR. Adherence is expressed as ACs; the blueprint ships no test files (a shelf-wide policy) and no code.
 
-No FBS contributions, as a matter of principle (a ratified shelf-wide policy): FBSs are the work of the implementing agent, not the blueprint; project constraints have to be applied at the time of creation. The blueprint contributes the WHAT; the implementing agent derives the HOW-tasks (FBS) in the host project, where the ACs contributed here get picked up by the project's own build sequencing. Structurally the same conclusion falls out of the mechanism: an FBS binds to a bsId and a buildOrder slot the blueprint cannot know.
+No FBS contributions, as a matter of principle (a shelf-wide policy): FBSs are the work of the implementing agent, not the blueprint; project constraints have to be applied at the time of creation. The blueprint contributes the WHAT; the implementing agent derives the HOW-tasks (FBS) in the host project, where the ACs contributed here get picked up by the project's own build sequencing. Structurally the same conclusion falls out of the mechanism: an FBS binds to a bsId and a buildOrder slot the blueprint cannot know.
 
 ## The five global decisions
 
 ADR-201 clientRouting, ADR-202 theming, ADR-203 clientState, ADR-204 errorEnvelope, ADR-205 authModel ship `scope: global`. Composing with the application-api-rest blueprint deliberately conflicts on `errorEnvelope` and `authModel`; see `docs/topics.md` for the exact strings, the expected resolutions, and the AC id band allocation (application-spa owns 1101-1899).
 
-## Quality bar (ratified)
-
+## Quality bar
 WCAG 2.2 AA (contrast 4.5:1 body / 3:1 large-and-non-text, visible focus, 24x24 targets, no traps), breakpoints 360/768/1024/1440 with zero horizontal overflow, dark/light token parity, modular type scale with 14/16px body floors, motion tokens honouring reduced motion, performance budget (FMP under 2s on 3G-fast, Lighthouse 90+, main-thread under 3s). Every bar is carried by ACs in the doc set, not by this README.
 
 ## What v1.1.0 adds
 
-v1.1.0 is an additive-non-global minor bump. No global topics change; no contribution is removed. The bump introduces the mechanism-reach cure for the icon and semantic-token disciplines that a prior review pass caught shipping while the build cycle ran green.
+v1.1.0 is an additive-non-global minor bump. No global topics change; no contribution is removed. The bump binds the icon and semantic-token disciplines to build-scan probes so a violation refuses ship rather than passing silently.
 
 - `application-spa-US-1129` (anchored to application-spa-REQ-005) with four ACs binding the token-adherence probe.
 - `application-spa-US-1130` (anchored to application-spa-REQ-011) with four ACs binding the icon-adherence probe.
@@ -55,7 +54,7 @@ The v1.1 probes are runtime-observable AC binding at the ship gate. When a proje
 
 ## What v1.2.0 adds
 
-v1.2.0 is an additive-non-global minor bump. No global topics change; no contribution is removed. The bump cures the styled-under-shipped-CSP mechanism-reach gap an early production review caught: FBS-011 declared strict CSP (`style-src 'self'`, no `'unsafe-inline'`), FBS-013/015 rendered inline `<style>` blocks, every existing UI-bearing gate passed, and every production page rendered unstyled at deploy because the harness bypassed the production security-header path.
+v1.2.0 is an additive-non-global minor bump. No global topics change; no contribution is removed. The bump binds the styled-under-shipped-CSP discipline: TAC-209 boots the target through the production entry-point path, drives a real headless browser at every enumerated UI route, and refuses on any inline `<style>` block, any `style-src` relaxation, any browser-default computed body background, or any non-200 `text/css` stylesheet response.
 
 - `application-spa-US-1131` (anchored to application-spa-REQ-018) with six ACs binding the styled-under-shipped-CSP probe.
 - `TAC-209-application-spa-csp-styled-adherence-probe`: a Node probe the project realises; boots the target server through the production entry-point path, drives a real headless browser at every enumerated UI route, refuses on any inline `<style>` block, any style-src relaxation, any browser-default computed body background, or any non-200 text/css stylesheet response.
@@ -63,13 +62,13 @@ v1.2.0 is an additive-non-global minor bump. No global topics change; no contrib
 
 ## What v1.3.0 adds
 
-v1.3.0 is an additive-non-global minor bump. No global topics change; no contribution is removed. The bump cures the deployment-gate class defect an early production review caught: the app was signed off as DEPLOYED with the only login path (magic-link email) inert because RESEND_API_KEY carried a placeholder value, admin access was reachable only via manually minted tokens, and the gap was filed as a "quirk" note in status.md rather than blocked at gate time. A real key existed in the estate the whole time.
+v1.3.0 is an additive-non-global minor bump. No global topics change; no contribution is removed. The bump binds two class rules the deployment / handover gates now compel: every credential field is checked against the canonical placeholder-shape detector before an aggregate verdict of `ok` is possible, and every core user flow (including the login path when the surface carries application-spa-REQ-009) executes end-to-end against the shipped runtime.
 
 The bump encodes three class rules the deployment / handover gates now compel:
 
 1. **External-service dependency provisioning.** Every external service the app calls at runtime is enumerated on a stable manifest; every credential field is checked against the canonical placeholder-shape detector; every `verified` dependency requires captured live-handshake evidence from the shipped runtime; every `deferred` dependency requires an operator-ratified persistent record (a README note or a status.md quirk line does NOT satisfy).
 2. **Core-flow end-to-end.** Every core user flow is enumerated on a stable manifest; authentication is ALWAYS included when the app has a application-spa-REQ-009 surface; every flow executes end-to-end against the shipped runtime (production entry-point construction, production security headers, real external providers) driven by a real browser, with captured evidence per flow; a skipped, timed-out, or absent flow is a hard refusal.
-3. **Sign-off vocabulary.** A run in which every core flow completes and every external dependency is verified-or-ratified-deferred lands at aggregate verdict `ok`. Any placeholder-shape credential, any missing handshake evidence, any unratified deferral, any core-flow fail-or-skip lands at aggregate verdict `deployed-with-defects`. A "documented workaround exists" does not convert a broken flow into `ok`; the aggregate verdict is what the delivery-ci-workflows runner surfaces.
+3. **Aggregate-verdict vocabulary.** A run in which every core flow completes and every external dependency is verified-or-ratified-deferred lands at aggregate verdict `ok`. Any placeholder-shape credential, any missing handshake evidence, any unratified deferral, any core-flow fail-or-skip lands at aggregate verdict `deployed-with-defects`. A "documented workaround exists" does not convert a broken flow into `ok`; the aggregate verdict is what the delivery-ci-workflows runner surfaces.
 
 Contributions: