rcf-lite 0.26.0 → 0.28.0

package/blueprints/application-onboarding-tour/contributions/requirements/application-onboarding-tour-req-005.json

@@ -0,0 +1,22 @@
+{
+  "reqId": "application-onboarding-tour-REQ-005",
+  "prdId": "PRD-001",
+  "title": "Dismissal policy: dismiss-permanently, dismiss-until-next-major and dismiss-until-next-minor each have a defined runtime clause",
+  "description": "The completion store honours the elicited dismissal-policy with a runtime clause per option. `dismiss-permanently` writes a terminal completion record and refuses re-surfacing regardless of any subsequent version bump: a principal who dismisses the tour never sees it again until the restart-tour control fires. `dismiss-until-next-major` writes a completion record carrying the current tour version and compares stored and current versions on the major segment on principal load: the tour re-surfaces when the majors differ, otherwise it stays dismissed. `dismiss-until-next-minor` writes a completion record carrying the current tour version and re-surfaces the tour when either the major or the minor segment differs on principal load. The record shape is identical across the three policies; only the comparison on load differs.",
+  "deliveredBy": {
+    "tacId": "TAC-2703-application-onboarding-tour-completion-store",
+    "field": "interfaces.completionStore"
+  },
+  "category": "functional",
+  "domain": "onboarding",
+  "priority": "must",
+  "rationale": "The elicit offers three dismissal policies but no requirement described what each option does. A principal on a project that chose `dismiss-until-next-major` inherited `dismiss-permanently` behaviour silently. Requiring a per-option clause turns the elicit into a chain-linked behaviour the completion store's read on load proves.",
+  "tags": [
+    "blueprint:application-onboarding-tour",
+    "category:05-dismissal-policy"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-10T00:00:00Z",
+  "updatedAt": "2026-09-10T00:00:00Z"
+}

package/blueprints/application-onboarding-tour/contributions/requirements/application-onboarding-tour-req-006.json

@@ -0,0 +1,22 @@
+{
+  "reqId": "application-onboarding-tour-REQ-006",
+  "prdId": "PRD-001",
+  "title": "Checklist anchor: dashboard-top, settings-page and custom-anchor each resolve to a rendered slot or a defined fallback",
+  "description": "The checklist slot honours the elicited checklist-anchor with a runtime clause per option. `dashboard-top` mounts the checklist at the top of the dashboard route provided by application-dashboard and refuses the mount (a WCAG 3.3.1 refusal announced on the settings surface) when application-dashboard is not applied. `settings-page` mounts the checklist at the settings route provided by application-account-settings and behaves as `dashboard-top` regarding refusal when the settings surface is unavailable. `custom-anchor` resolves an elicited CSS selector against the live DOM at load: on resolution the checklist mounts inside the resolved element with a default collapsed state (a <details> element with data-role=onboarding-tour-checklist and open=false); when the selector resolves to nothing or to an invisible or clipped element, the checklist mounts at the settings route as a fallback and the console log carries data-error=CHECKLIST_ANCHOR_UNRESOLVED naming the selector. In every branch, the checklist suppresses entirely when neither the dashboard nor the settings surface is applied and no usable custom anchor is set.",
+  "deliveredBy": {
+    "tacId": "TAC-2702-application-onboarding-tour-checklist-slot",
+    "field": "responsibilities.resolveAnchor"
+  },
+  "category": "functional",
+  "domain": "onboarding",
+  "priority": "must",
+  "rationale": "The elicit offers three checklist anchors but the shipped requirement covered dashboard-top and settings-page only. A project that chose custom-anchor inherited unspecified behaviour: no requirement described the default collapse state or what happens when the selector resolves to nothing. Requiring a per-option clause makes the fallback and the refusal observable.",
+  "tags": [
+    "blueprint:application-onboarding-tour",
+    "category:06-checklist-anchor"
+  ],
+  "version": "1.0.0",
+  "status": "approved",
+  "createdAt": "2026-09-10T00:00:00Z",
+  "updatedAt": "2026-09-10T00:00:00Z"
+}

package/blueprints/application-onboarding-tour/contributions/tacs/tac-2702-application-onboarding-tour-checklist-slot.json

@@ -10,7 +10,8 @@
     "Read the elicited checklist-anchor (ADR-2703) at load and mount the checklist at the resolved slot (AC-26103-1).",
     "Render the checklist as a <details> element carrying data-role=\"onboarding-tour-checklist\" whose open state mirrors the anchor: open on dashboard-top, closed on settings-page (AC-26103-1).",
     "Enumerate the applied tour surfaces as list items with a link to the restart-tour control on the settings surface.",
-    "Suppress the checklist entirely when neither the dashboard nor the settings surface is applied and no custom-anchor is supplied."
+    "Suppress the checklist entirely when neither the dashboard nor the settings surface is applied and no custom-anchor is supplied.",
+    "resolveAnchor: resolve the elicited checklist-anchor (dashboard-top, settings-page or custom-anchor) to a mounted <details> slot, or fall back to the settings surface with data-error=CHECKLIST_ANCHOR_UNRESOLVED (AC-26109-1 through AC-26109-5)."
   ],
   "internalStructure": "One checklist module that reads the applied capability set from the sidecar-adjacent applied-blueprint list, picks the anchor per the elicited value or the default derived at apply time, and mounts the <details> element into the resolved slot. The framework is not prescribed.",
   "interfaces": [

package/blueprints/application-onboarding-tour/contributions/tacs/tac-2703-application-onboarding-tour-completion-store.json

@@ -2,17 +2,17 @@
   "tacId": "TAC-2703-application-onboarding-tour-completion-store",
   "prdId": "PRD-001",
   "tadId": "TAD-001",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "status": "approved",
   "name": "Onboarding-tour completion-state store",
-  "purpose": "Owns the completion-state store contract: the writer the step runner calls on the last step, the reader first-run detection calls on principal load, and the clearer the restart-tour control calls. Delegates to the applied persistence blueprint when server-side-per-principal is elicited (and refuses at apply if no persistence blueprint is applied); falls back to spa-local-storage per Q4 or spa-session-storage per the elicit.",
+  "purpose": "Owns the completion-state store contract: the writer the step runner calls on the last step, the reader first-run detection calls on principal load, and the clearer the restart-tour control calls. The refusal semantics for the server-side-per-principal backend without an applied persistence blueprint are owned by `ADR-2702.decision`.",
   "responsibilities": [
     "Write the completion record on the last step (AC-26104-1).",
     "Read the completion record on principal load so first-run detection can gate the tour auto-open (AC-26105-1).",
     "Clear the completion record when the restart-tour control fires (AC-26104-1, AC-26106-1).",
-    "Refuse at apply when server-side-per-principal is elicited without an applied persistence blueprint."
+    "Enforce the refusal semantics owned by `ADR-2702.decision`."
   ],
-  "internalStructure": "One completion-store module with three backends (spa-local-storage, spa-session-storage, server-side-per-principal) selected at apply time from the elicited completion-state-store answer or the Q4 fallback (spa-local-storage). The server-side backend calls the applied persistence blueprint's writer through the projects own adapter interface; the two SPA backends read and write window.localStorage / window.sessionStorage under a namespaced key derived from the applied blueprint set version.",
+  "internalStructure": "One completion-store module with three backends (selected at apply time from the elicited `blueprint.json.elicits[id=completion-state-store]` answer). The server-side backend calls the applied persistence blueprint's writer through the projects own adapter interface; the missing-provider refusal semantics for that branch are owned by `ADR-2702.decision`. The SPA backends read and write from the browser storage the elicit selects under a namespaced key derived from the applied blueprint set version.",
   "interfaces": [
     {
       "name": "completionStore",
@@ -27,8 +27,8 @@
       "description": "Optional composition: only the server-side-per-principal backend delegates to an applied persistence blueprint writer. spa-local-storage and spa-session-storage need no persistence blueprint. The rcf-schemas 0.6.1 TAC dependency kind enum is limited to tac and external, so the composition-optional relation is recorded as external and made explicit in the description and notes."
     }
   ],
-  "tradeoffs": "spa-local-storage is chosen as the Q4 default because 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; spa-session-storage remains an option for a project that deliberately wants a per-session tour. server-side-per-principal is chosen when the tour completion is a real profile fact (a cross-device onboarding) rather than a per-browser convenience.",
-  "notes": "The blueprintSetVersion in the CompletionRecord is what lets ADR-2701's dismiss-until-next-major and dismiss-until-next-minor policies re-open the tour on the right bump. Known mechanism-reach gap: the server-side-per-principal backend cannot prove a round-trip in a unit test without an applied persistence blueprint; the pack skips the persistence round-trip check for spa-* stores (inspects the storage directly) and drives it for server-side-per-principal on the fixture branch that stands up an in-fixture writer. The Persistence blueprint dependency is recorded with kind external per the rcf-schemas 0.6.1 enum and is optional-composition semantically: server-side-per-principal delegates to the applied persistence blueprint writer, and the spa-local-storage and spa-session-storage backends need no persistence blueprint applied. Refusal at apply for the server-side-per-principal branch is enforced in the store module.",
+  "tradeoffs": "The three-backend choice and the default selection are owned by `ADR-2702.decision` and the manifest elicit `blueprint.json.elicits[id=completion-state-store]`; this TAC carries only the store contract, not the option-level rationale.",
+  "notes": "The blueprintSetVersion in the CompletionRecord is what lets ADR-2701's dismiss-until-next-major and dismiss-until-next-minor policies re-open the tour on the right bump. Known mechanism-reach gap: the server-side-per-principal backend cannot prove a round-trip in a unit test without an applied persistence blueprint; the pack skips the persistence round-trip check for the SPA stores (inspects the storage directly) and drives it for the server-side backend on the fixture branch that stands up an in-fixture writer. The Persistence blueprint dependency is recorded with kind external per the rcf-schemas 0.6.1 enum and is optional-composition semantically. The refusal path is enforced per `ADR-2702.decision`.",
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-07T00:45:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26101.json

@@ -13,7 +13,72 @@
       "id": "AC-26101-1",
       "testable": true,
       "scope": "runtime",
-      "description": "Given a first-run principal on the SPA, the tour opens on the highest-value surface with the first step; Escape dismisses the tour and hides the tooltip; keyboard-only users reach every tour control (previous, next, dismiss) via Tab in DOM order and activate the next control with Enter (WCAG 2.1.1 Keyboard, WCAG 2.1.2 No Keyboard Trap, WCAG 2.4.3 Focus Order). Anchors to TAC-2701-application-onboarding-tour-step-runner; probed by application-onboarding-tour.pack.mjs check AC-26101-1."
+      "description": "Given a first-run principal on the SPA, the tour opens on the highest-value surface with the first step; Escape dismisses the tour and hides the tooltip; keyboard-only users reach every tour control (previous, next, dismiss) via Tab in DOM order and activate the next control with Enter (WCAG 2.1.1 Keyboard, WCAG 2.1.2 No Keyboard Trap, WCAG 2.4.3 Focus Order). Anchors to TAC-2701-application-onboarding-tour-step-runner; probed by application-onboarding-tour.pack.mjs check AC-26101-1. (WCAG 2.1.2 verified against https://www.w3.org/TR/WCAG22/#no-keyboard-trap and WCAG 2.4.3 verified against https://www.w3.org/TR/WCAG22/#focus-order, 2026-09-10.)",
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://www.w3.org/TR/WCAG22/#keyboard",
+        "verifiedOn": "2026-09-10"
+      }
+    },
+    {
+      "id": "AC-26101-2",
+      "description": "When the current step's anchor selector resolves to nothing at open, the runner refuses the step render, focus stays on the last known anchor (or on the tour launcher for the first step), and the console log carries data-error=TOUR_ANCHOR_UNRESOLVED naming the selector; no floating dialog surfaces.",
+      "given": "the current step has an anchor that resolves to no element",
+      "when": "the runner attempts to open the step",
+      "then": "the step is skipped or the tour is closed with a defined error, no floating dialog appears, and data-error=TOUR_ANCHOR_UNRESOLVED is logged",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26101-3",
+      "description": "When the current step's anchor resolves to an invisible or clipped element that cannot fit the tooltip at the current breakpoint, the runner refuses the render and emits data-error=TOUR_ANCHOR_UNFIT; the dialog never renders floating or off-screen.",
+      "given": "the current step's anchor is present but hidden or clipped for the current viewport",
+      "when": "the runner attempts to open the step",
+      "then": "no tooltip renders, data-error=TOUR_ANCHOR_UNFIT is logged with the anchor and breakpoint, and the tour offers the next step or a defined close",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26101-4",
+      "description": "The tour opens on the highest-value surface as named by the elicited step manifest (the first step's anchor selector determines the surface); a manifest with fewer than 3 steps or more than 5 refuses at apply with STEP_MANIFEST_OUT_OF_RANGE naming the count.",
+      "given": "a project applying application-onboarding-tour",
+      "when": "apply runs against a step manifest with an out-of-range count",
+      "then": "apply exits with a non-zero code and STEP_MANIFEST_OUT_OF_RANGE names the count and the required range",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26101-5",
+      "description": "The elicited `tour-step-manifest` value is the ordered step list the runner walks; each entry names a step id, an anchor selector, a heading and a body. A manifest with fewer than 3 or more than 5 entries refuses at apply with STEP_MANIFEST_OUT_OF_RANGE naming the count. Applying agent sets: tour-step-manifest.",
+      "given": "a project applying application-onboarding-tour with a tour-step-manifest of N entries",
+      "when": "apply runs",
+      "then": "apply exits 0 with 3<=N<=5 and refuses with STEP_MANIFEST_OUT_OF_RANGE otherwise, naming N and the required range",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-26101-6",
+      "description": "The elicited `anchor-selectors` value supplies the per-step CSS selector the runner passes to document.querySelector at step-open time; a step whose selector resolves to no element or to a clipped element refuses the render with data-error=TOUR_ANCHOR_UNRESOLVED or TOUR_ANCHOR_UNFIT respectively (see AC-26101-2 and AC-26101-3). Applying agent sets: anchor-selectors.",
+      "given": "a project applying application-onboarding-tour with anchor-selectors set per manifest step",
+      "when": "the runner opens a step",
+      "then": "the runner queries the DOM with the elicited selector for that step and refuses the render with the named data-error when the selector does not resolve to a visible unclipped element",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-26101-7",
+      "description": "The elicited `per-step-content-voice` value supplies the heading and body strings the tooltip surfaces verbatim for each step; a step whose heading or body resolves to an empty string refuses at apply with STEP_CONTENT_MISSING naming the step id. Applying agent sets: per-step-content-voice.",
+      "given": "a project applying application-onboarding-tour with per-step-content-voice set for each manifest step",
+      "when": "apply runs",
+      "then": "apply refuses with STEP_CONTENT_MISSING naming the offending step id when any heading or body is empty, and exits 0 with the strings surfaced verbatim in the tooltip DOM at runtime otherwise",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template"
     }
   ],
   "tacIds": [
@@ -23,5 +88,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26102.json

@@ -13,7 +13,40 @@
       "id": "AC-26102-1",
       "testable": true,
       "scope": "runtime",
-      "description": "Given a step showing a tooltip anchored to a UI element, focus moves to the tooltip on open; the tooltip carries role=\"dialog\" with aria-labelledby pointing at the step heading; focus returns to the anchor on close (Escape or the dismiss control) per the ARIA APG dialog-modal pattern; focus is not obscured on the 1440 wide breakpoint or the 360 narrow breakpoint (WCAG 2.4.11 Focus Not Obscured Minimum). Anchors to TAC-2701-application-onboarding-tour-step-runner; probed by application-onboarding-tour.pack.mjs check AC-26102-1."
+      "description": "Given a step showing a tooltip anchored to a UI element, focus moves to the tooltip on open; the tooltip carries role=\"dialog\" with aria-labelledby pointing at the step heading; focus returns to the anchor on close (Escape or the dismiss control) per the ARIA APG dialog-modal pattern; focus is not obscured on the 1440 wide breakpoint or the 360 narrow breakpoint (WCAG 2.4.11 Focus Not Obscured Minimum). Anchors to TAC-2701-application-onboarding-tour-step-runner; probed by application-onboarding-tour.pack.mjs check AC-26102-1. (WCAG 2.4.11 verified against https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum, 2026-09-10.)",
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/",
+        "verifiedOn": "2026-09-10"
+      }
+    },
+    {
+      "id": "AC-26102-2",
+      "description": "The tooltip carries role=\"dialog\", aria-modal=\"true\" and aria-labelledby resolving to the step heading id (WCAG 1.3.1 and 4.1.2 via the ARIA APG dialog-modal pattern).",
+      "given": "a tour step opens",
+      "when": "the DOM is inspected",
+      "then": "the tooltip element carries role=\"dialog\", aria-modal=\"true\" and aria-labelledby resolving to a heading id present in the tooltip",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/",
+        "verifiedOn": "2026-09-10"
+      }
+    },
+    {
+      "id": "AC-26102-3",
+      "description": "Focus is trapped between the tour controls (previous, next, dismiss) while the dialog is open; Tab from the last control returns to the first, Shift+Tab from the first goes to the last, and Escape closes the dialog and returns focus to the anchor.",
+      "given": "a tour step is open",
+      "when": "the keyboard walks Tab / Shift+Tab / Escape",
+      "then": "focus stays within the tour controls until Escape or dismiss fires, then returns to the anchor",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/",
+        "verifiedOn": "2026-09-10"
+      }
     }
   ],
   "tacIds": [
@@ -23,5 +56,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26103.json

@@ -13,7 +13,18 @@
       "id": "AC-26103-1",
       "testable": true,
       "scope": "runtime",
-      "description": "Given the applied capability set includes application-dashboard, the checklist renders inside a <details open> element on the dashboard-top anchor slot; given the applied capability set does NOT include application-dashboard, the checklist renders inside a <details> (closed) element on the settings-page anchor slot; the <details> element carries data-role=\"onboarding-tour-checklist\" in both branches. Anchors to TAC-2702-application-onboarding-tour-checklist-slot; probed by application-onboarding-tour.pack.mjs check AC-26103-1 on both application-dashboard and settings-page branches."
+      "description": "Given the applied capability set includes application-dashboard, the checklist renders inside a <details open> element on the dashboard-top anchor slot; given the applied capability set does NOT include application-dashboard, the checklist renders inside a <details> (closed) element on the settings-page anchor slot; the <details> element carries data-role=\"onboarding-tour-checklist\" in both branches. Anchors to TAC-2702-application-onboarding-tour-checklist-slot; probed by application-onboarding-tour.pack.mjs check AC-26103-1 on both application-dashboard and settings-page branches.",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26103-2",
+      "description": "When application-dashboard is not applied, the checklist mounts on the settings route rather than falling through to nothing.",
+      "given": "application-dashboard is not applied",
+      "when": "the settings route renders",
+      "then": "the checklist appears on the settings route with data-role=onboarding-tour-checklist",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [
@@ -23,5 +34,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26104.json

@@ -13,7 +13,38 @@
       "id": "AC-26104-1",
       "testable": true,
       "scope": "runtime",
-      "description": "Given a completed tour, the completion state persists per principal in the applied persistence blueprint (or in spa-local-storage as the Q4 fallback per ADR-2702 when no persistence blueprint is applied); a restart-tour control is reachable from the settings surface (composing on application-account-settings when applied; on any settings surface as a fallback); activating the control clears the completion state and re-opens the tour on the next principal load. Anchors to TAC-2703-application-onboarding-tour-completion-store; probed by application-onboarding-tour.pack.mjs check AC-26104-1."
+      "description": "Given a completed tour, the completion state persists per principal in the applied persistence blueprint (or in spa-local-storage as the Q4 fallback per ADR-2702 when no persistence blueprint is applied); a restart-tour control is reachable from the settings surface (composing on application-account-settings when applied; on any settings surface as a fallback); activating the control clears the completion state and re-opens the tour on the next principal load. Anchors to TAC-2703-application-onboarding-tour-completion-store; probed by application-onboarding-tour.pack.mjs check AC-26104-1.",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26104-2",
+      "description": "When completion-state-store is `server-side-per-principal` and no persistence blueprint is applied, apply refuses with COMPLETION_STORE_MISSING_PROVIDER naming the required capability and no completion record is written.",
+      "given": "completion-state-store=server-side-per-principal with no persistence blueprint applied",
+      "when": "apply runs",
+      "then": "apply exits with a non-zero code, COMPLETION_STORE_MISSING_PROVIDER is emitted and no completion record is written to any store",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26104-3",
+      "description": "When the write of the completion record fails (a rejected persistence write or a full quota on spa-local-storage), the tour does not mark itself completed: the last step remains active or the dialog closes with data-error=COMPLETION_WRITE_FAILED, and the next principal load re-opens the tour.",
+      "given": "a tour completing while the store rejects the write",
+      "when": "the last step confirm fires",
+      "then": "no completed-success announcement is emitted, data-error=COMPLETION_WRITE_FAILED is logged, and a subsequent principal load re-opens the tour",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26104-4",
+      "description": "When the read of the completion record fails on principal load (an unreachable persistence backend or a corrupted spa-local-storage entry), the tour defaults to first-run behaviour and the console log carries data-error=COMPLETION_READ_FAILED; the tour never claims dismissed status on an unreadable record.",
+      "given": "a store that raises on read at principal load",
+      "when": "the principal loads",
+      "then": "the tour surfaces as first-run and data-error=COMPLETION_READ_FAILED is logged with the store kind",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [
@@ -23,5 +54,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26105.json

@@ -13,7 +13,18 @@
       "id": "AC-26105-1",
       "testable": true,
       "scope": "runtime",
-      "description": "Given a principal whose completion-state store contains no completion record for the applied blueprint set version, the tour auto-opens on the highest-value surface; given a principal whose completion-state store contains a completion record for the applied blueprint set version, the tour does NOT auto-open and only the checklist and the restart-tour control render. The check is documented as a mechanism-reach gap in the README (not directly probed at runtime; enforced by the fixture branch under manual boot for the gate reviewer)."
+      "description": "Given a principal whose completion-state store contains no completion record for the applied blueprint set version, the tour auto-opens on the highest-value surface; given a principal whose completion-state store contains a completion record for the applied blueprint set version, the tour does NOT auto-open and only the checklist and the restart-tour control render. The check is documented as a mechanism-reach gap in the README (not directly probed at runtime; enforced by the fixture branch under manual boot for the gate reviewer).",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26105-2",
+      "description": "A completion record with an unknown or unparseable tourVersion is treated as absent: the tour surfaces as first-run and the console log carries data-error=COMPLETION_RECORD_UNPARSEABLE naming the record id; no false dismissal is inherited.",
+      "given": "a completion record whose tourVersion cannot be parsed",
+      "when": "the principal loads",
+      "then": "the tour opens as first-run and data-error=COMPLETION_RECORD_UNPARSEABLE is logged",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [
@@ -23,5 +34,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26106.json

@@ -13,7 +13,18 @@
       "id": "AC-26106-1",
       "testable": true,
       "scope": "runtime",
-      "description": "The restart-tour control renders on the settings surface as a <button data-action=\"restart-tour\"> reachable via Tab and activatable with Enter; activating it clears the completion state in the applied store (per ADR-2702) and re-opens the tour on the highest-value surface on the next principal load. Covered as part of AC-26104-1's pack check (the check exercises the restart flow end-to-end)."
+      "description": "The restart-tour control renders on the settings surface as a <button data-action=\"restart-tour\"> reachable via Tab and activatable with Enter; activating it clears the completion state in the applied store (per ADR-2702) and re-opens the tour on the highest-value surface on the next principal load. Covered as part of AC-26104-1's pack check (the check exercises the restart flow end-to-end).",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26106-2",
+      "description": "When the restart-tour control fires but the completion store rejects the clear, the tour does not open and the console log carries data-error=COMPLETION_CLEAR_FAILED with a retry control; the control stays keyboard-reachable.",
+      "given": "the completion store rejects the clear",
+      "when": "a principal fires restart-tour",
+      "then": "the tour does not open, data-error=COMPLETION_CLEAR_FAILED is logged and a retry control renders keyboard-reachable",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
     }
   ],
   "tacIds": [
@@ -23,5 +34,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26107.json

@@ -13,7 +13,22 @@
       "id": "AC-26107-1",
       "testable": true,
       "scope": "runtime",
-      "description": "The tooltip carries aria-labelledby pointing at the step heading and aria-describedby pointing at the step body; focus moves into the tooltip on open so the screen reader reads the labelled and described text. Documented as a mechanism-reach gap for the described-text read order because rcf-lite does not drive a real screen reader in CI; the pack asserts the DOM contract and the fixture README names the manual screen-reader smoke."
+      "description": "The tooltip carries aria-labelledby pointing at the step heading and aria-describedby pointing at the step body; focus moves into the tooltip on open so the screen reader reads the labelled and described text. Documented as a mechanism-reach gap for the described-text read order because rcf-lite does not drive a real screen reader in CI; the pack asserts the DOM contract and the fixture README names the manual screen-reader smoke.",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26107-2",
+      "description": "On close of the tour (Escape, dismiss or last-step confirm), a polite live region announces the outcome (completed or dismissed) so screen-reader users know the state transition happened without inspecting the surface.",
+      "given": "a tour step is open and the principal closes the tour",
+      "when": "the tour closes",
+      "then": "a polite live region announces \"onboarding tour completed\" or \"onboarding tour dismissed\"",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "vendorCitation": {
+        "url": "https://www.w3.org/TR/WCAG22/#status-messages",
+        "verifiedOn": "2026-09-10"
+      }
     }
   ],
   "tacIds": [
@@ -23,5 +38,5 @@
     "blueprint:application-onboarding-tour"
   ],
   "createdAt": "2026-09-06T23:15:00Z",
-  "updatedAt": "2026-09-06T23:15:00Z"
+  "updatedAt": "2026-09-10T00:00:00Z"
 }

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26108.json

@@ -0,0 +1,62 @@
+{
+  "usId": "application-onboarding-tour-US-26108",
+  "prdId": "PRD-001",
+  "reqId": "application-onboarding-tour-REQ-005",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The elicited dismissal-policy determines whether a version bump re-surfaces the tour",
+  "asA": "principal who dismissed the tour once on a project applying application-onboarding-tour",
+  "iWant": "a subsequent tour version bump to re-surface the tour only if the elicited policy says so",
+  "soThat": "a project's dismissal policy is the policy I actually experience across releases",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-26108-1",
+      "description": "When dismissal-policy is `dismiss-permanently` and the principal dismisses the tour, the completion record marks the dismissal terminal and no version bump re-opens the tour; only the restart-tour control clears the record and re-opens.",
+      "given": "dismissal-policy=dismiss-permanently applied and the principal dismissed the tour once",
+      "when": "the tour version bumps and the principal re-loads",
+      "then": "the tour stays dismissed regardless of the version bump; the restart-tour control clears the record and re-opens the tour",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26108-2",
+      "description": "When dismissal-policy is `dismiss-until-next-major` the completion store writes the dismissed tour's SemVer, and on principal load compares the stored major segment against the current tour's major segment; the tour re-opens iff the majors differ.",
+      "given": "dismissal-policy=dismiss-until-next-major applied and a completion record from tour v1.4.2",
+      "when": "the tour version changes",
+      "then": "a bump to v1.5.0 does not re-open the tour, a bump to v2.0.0 does re-open it",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26108-3",
+      "description": "When dismissal-policy is `dismiss-until-next-minor` the completion store writes the dismissed tour's SemVer, and on principal load compares stored and current major.minor; the tour re-opens iff either segment differs.",
+      "given": "dismissal-policy=dismiss-until-next-minor applied and a completion record from tour v1.4.2",
+      "when": "the tour version changes",
+      "then": "a bump to v1.4.9 does not re-open the tour, a bump to v1.5.0 does re-open it and a bump to v2.0.0 does re-open it",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26108-4",
+      "description": "The completion record shape is owned by `TAC-2703.interfaces.completionStore`; the record shape is identical across the three policies and only the load-time comparison differs. A stored record written under one policy is legal under another (the load-time comparison is what changes).",
+      "given": "a completion record written under any of the three policies",
+      "when": "the applied policy changes at re-apply time",
+      "then": "the record shape is unchanged and the load-time comparison uses the new policy",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "tacId": "TAC-2703-application-onboarding-tour-completion-store",
+        "field": "interfaces.completionStore"
+      }
+    }
+  ],
+  "tacIds": [
+    "TAC-2703-application-onboarding-tour-completion-store"
+  ],
+  "createdAt": "2026-09-10T00:00:00Z",
+  "updatedAt": "2026-09-10T00:00:00Z"
+}

package/blueprints/application-onboarding-tour/contributions/user-stories/application-onboarding-tour-us-26109.json

@@ -0,0 +1,72 @@
+{
+  "usId": "application-onboarding-tour-US-26109",
+  "prdId": "PRD-001",
+  "reqId": "application-onboarding-tour-REQ-006",
+  "version": "1.0.0",
+  "status": "approved",
+  "title": "The elicited checklist-anchor mounts the checklist at the resolved slot or a defined fallback",
+  "asA": "operator applying application-onboarding-tour with a chosen checklist-anchor",
+  "iWant": "the checklist to appear in the anchored slot with a defined open state and a defined fallback",
+  "soThat": "the checklist never lands silently in the wrong place or disappears without a reason I can trace",
+  "acceptanceCriteria": [
+    {
+      "id": "AC-26109-1",
+      "description": "When checklist-anchor is `dashboard-top` and application-dashboard is applied, the checklist mounts at the top of the dashboard route as a <details data-role=\"onboarding-tour-checklist\" open> element (open by default per ADR-2703).",
+      "given": "checklist-anchor=dashboard-top with application-dashboard applied",
+      "when": "the dashboard route renders",
+      "then": "the DOM carries a <details data-role=\"onboarding-tour-checklist\" open> element as the first child of the dashboard content region",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed",
+      "ownerRef": {
+        "adrId": "ADR-2703-application-onboarding-tour-checklist-anchor",
+        "field": "decision"
+      }
+    },
+    {
+      "id": "AC-26109-2",
+      "description": "When checklist-anchor is `settings-page` and application-account-settings is applied, the checklist mounts on the settings route with the same shape and default open=false.",
+      "given": "checklist-anchor=settings-page with application-account-settings applied",
+      "when": "the settings route renders",
+      "then": "the DOM carries a <details data-role=\"onboarding-tour-checklist\" open=false> element inside the settings content region",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26109-3",
+      "description": "When checklist-anchor is `custom-anchor` and the elicited CSS selector resolves to a visible, unclipped element on load, the checklist mounts inside that element with open=false and data-role=onboarding-tour-checklist. Applying agent sets: the anchor-selectors elicit's selector string.",
+      "given": "checklist-anchor=custom-anchor with a resolvable, visible selector",
+      "when": "the route with that selector renders",
+      "then": "the DOM carries the <details data-role=\"onboarding-tour-checklist\"> inside the resolved element",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "template"
+    },
+    {
+      "id": "AC-26109-4",
+      "description": "When checklist-anchor is `custom-anchor` and the selector resolves to nothing, to an invisible element or to a clipped element that cannot fit the checklist, the checklist mounts on the settings route as a fallback and the console log carries data-error=CHECKLIST_ANCHOR_UNRESOLVED naming the selector string. No dialog floats loose over the underlying surface.",
+      "given": "checklist-anchor=custom-anchor with an unresolvable, invisible or clipped selector",
+      "when": "the route renders",
+      "then": "the checklist mounts on the settings route and data-error=CHECKLIST_ANCHOR_UNRESOLVED is logged with the selector; no floating dialog surfaces",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    },
+    {
+      "id": "AC-26109-5",
+      "description": "When no dashboard surface, no settings surface and no usable custom anchor are available, the checklist suppresses entirely (no element is written to the DOM) and the sidecar records checklistSuppressed:true with the reason.",
+      "given": "no dashboard, no settings and no usable custom anchor applied",
+      "when": "any route renders",
+      "then": "no <details data-role=\"onboarding-tour-checklist\"> is present and the sidecar records checklistSuppressed:true",
+      "testable": true,
+      "scope": "runtime",
+      "disposition": "fixed"
+    }
+  ],
+  "tacIds": [
+    "TAC-2702-application-onboarding-tour-checklist-slot"
+  ],
+  "createdAt": "2026-09-10T00:00:00Z",
+  "updatedAt": "2026-09-10T00:00:00Z"
+}

package/blueprints/application-onboarding-tour/docs/topics.md

@@ -44,8 +44,8 @@ The shelf-wide band registry lives in `packages/rcf-lite/docs/blueprint-authorin
 - `application-spa` (round 1, shipped v1.5.0+): supplies the routing shell (`/tour`, `/dashboard`, `/settings`), the iconography and theming the tour uses. The tour still renders without the SPA blueprint; the project supplies its own routing.
 - `application-dashboard` (round 3, shipped v1.0.0): supplies the dashboard-top anchor slot where the checklist mounts as `<details open>` for returning principals. When absent, the checklist collapses to a `<details>` (closed) on the settings-page anchor (ADR-2703).
 - `application-notifications-in-app` (round 3, shipped v1.0.0): supplies the polite `aria-live` live region the tour-completion announcement uses. When absent, the tour is silent at the announce layer (the step runner still logs one line if a logging companion is present).
-- `application-account-settings` (round 4 T-4, shipped v1.0.0): supplies the settings surface where the restart-tour control lives. When absent, the restart-tour control renders on any settings-shaped surface (`/settings`, `/account`, `/account/settings`).
-- `application-empty-error-states` (round 4 T-1, shipped v1.0.0): the tour composes on the forbidden state when a principal reaches `/tour` without an authenticated session and an auth blueprint is applied. When no auth blueprint is applied, the tour behaves as a single-principal experience per the composition table.
+- `application-account-settings` (round 4, shipped v1.0.0): supplies the settings surface where the restart-tour control lives. When absent, the restart-tour control renders on any settings-shaped surface (`/settings`, `/account`, `/account/settings`).
+- `application-empty-error-states` (round 4, shipped v1.0.0): the tour composes on the forbidden state when a principal reaches `/tour` without an authenticated session and an auth blueprint is applied. When no auth blueprint is applied, the tour behaves as a single-principal experience per the composition table.
 
 ## Probe pack
 

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

@@ -32,7 +32,7 @@ When no persistence blueprint is applied AND the operator does not answer `compl
 - `AC-26105-1` first-run detection: manual verification via the fixture README boot line (open `/tour` twice, confirm the tour auto-opens on run 1 and does not on run 2).
 - `AC-26107-1` screen-reader traversal: the pack asserts the DOM contract; the manual VoiceOver smoke is in the fixture README.
 
-Both gaps ride runner cleanup `w-2026-09-04-dave-020`.
+Both gaps are planned for a follow-up minor runner cleanup.
 
 ## Compose targets
 

package/blueprints/application-onboarding-tour/probe-packs/application-onboarding-tour.pack.mjs

@@ -15,10 +15,10 @@
 //              completion-state store per the elicited shape, activates restart
 //              from the settings surface, asserts the tour re-opens)
 //
-// Every check drives the real Playwright browser the T-0 runner injects and
+// Every check drives the real Playwright browser the runner injects and
 // reads its per-check applicability from the blueprint applied sidecar
 // (rcf/blueprints/application-onboarding-tour.applied.json) written by the apply
-// verb. T-5 has no requiresAppliedCapabilities, but the checklist-slot check
+// verb. The blueprint has no requiresAppliedCapabilities, but the checklist-slot check
 // gates its dashboard-vs-settings branch on the applied-blueprint set
 // (application-dashboard present or not), and the persistence check gates its
 // backend on the elicited completion-state-store answer (with the Q4 fallback