UX strategy for the integrated review programme

1. Purpose and status

Temporary planning document; planning only. This page is the end-to-end user-experience strategy for every screen the programme adds or changes, written to resolve the round-2 UX review (UX-01 to UX-22, its §3 strategy and §4 questions) and the UX-relevant findings of the other round-2 reviews (PH-13, PH-19, PH-35; review AC-17, AC-19, AC-27, AC-28, AC-29; SR-25; DD-11's user-facing glossary and Q-D4/Q-D5; V2-22, V2-25; RT-10, RT-14, RT-22; NS-07, NS-10, NS-13). Its changes to the other package documents have been merged into them: acceptance criteria §2 (AC-ALL-06 to AC-ALL-08; the AC-UX metrics in §2.3), §3 (UI-1 to UI-11 and the width matrix) and §5 (PE-05 and the user-testing tasks); contracts C17; open questions §3 (U30–U45 and the revised U6, U13, U16, U27) and §4 (A-24 rewritten, A-37, A-38); the integrated plan (R2a, R3a–R3c and R4a scope, §6.1 and §6.2 gates, §7, §9 and §10); and the UI comparison §2.3, §4 and §5.

Authority. Chris's 3 October decision UI1 (every new and updated screen is consistent, modern and Material 3 under FEAT-023's contract; decision register §1.11) is OWNER. The approved AF2 validation and presentation plan (/home/chris/workspace/syrf/handover/2026-09-13-af2-validation-presentation-plan.md, approved 14 September) and the project-navigation handoff rev 2 (/home/chris/workspace/syrf/main/docs/features/material-3-migration/handoffs/project-navigation-drawer/README.md, implemented by the navigation plan) are DOC-APPROVED inputs. Everything else here is PROPOSAL unless it carries a ledger ID. Product choices that need Chris are cited by their Batch D IDs from the round-2 brief (D1-06, D2-07, D2-08, D2-10, D2-12, D3-01 to D3-08, D3-15, D3-17, D3-19, D3-20, D3-23, D4-01, D4-13, D4-18, D4-19); no new question IDs are minted here. D1-06 (the tester panel) was approved as recommended on 3 October (register §1.13), and Chris named the panel late that evening (register §1.14; §9); no external SyRF users are named yet. D4-18 was answered the same night ("independent of funders"); its recorded reading keeps the independent WCAG 2.1 AA audit at GA and stays PROPOSAL until Chris confirms it in the G0 dossier. Owner session, 5 October 2026: most of the Batch D items named in this paragraph are now decided; §1.1 records which.

Code baseline. Current-UI claims were re-checked on main at de3e98c59 (3 October 2026):

Claim	Evidence (/home/chris/workspace/syrf/main/…)
No keyboard decision shortcuts exist on the reviewer page; no kbd hint renders	src/services/web/src/app/stage/stage-review/review-decision-card/review-decision-card.component.spec.ts:391-392 ("No I/E shortcuts exist yet"); no keydown host listener under src/services/web/src/app/stage/
The only onboarding is a one-shot hint with a "GOT IT" button; the public "What's new" is a marketing page	…/stage/stage-review/review-first-run-hint/review-first-run-hint.component.html:19-27; …/info/home/whats-new/
Per-user review preferences and the My studies navigator already exist	…/stage/stage-review/review-preferences-dialog/, …/stage/stage-review/my-studies-navigator/
AF2's action bar already says "Save progress" (compact "Save"), "Complete" and "Edit annotations"	…/shared/annotation/annotation-form-v2/annotation-form-v2.component.html:419, :466, :506
Typed message constants exist for one feature; a help-URL guard spec exists	…/study-presence/session-messages.ts; …/shared/pipes/user-guide-url/no-hardcoded-help-urls.spec.ts
Shared shells and primitives exist: page shell and page state, section shell, overlay scroll, row overflow	…/shared/page-shell/, …/shared/side-nav/, …/shared/overlay-scroll/, …/shared/row-overflow/
The e2e stack has no axe dependency and runs every Playwright project on Desktop Chrome	e2e/package.json (no @axe-core); e2e/playwright.config.ts:60-115
The question-tree designer still uses native HTML5 drag events	…/project/project-admin/question-management/design/question-node/question-node.component.html:12 (dragstart); …/design/design.component.html:67-201 (dragover/drop); …/design/annotation-question-tree-drag-drop.feature.ts:125-226 (DragEvent, dataTransfer)
No .browserslistrc; TypeScript target ES2022; no stylelint configuration	src/services/web/tsconfig.json:42; absence verified by listing
check:theme-migration scans M2 APIs, private Material paths and legacy Bootstrap imports only	src/services/web/scripts/check-theme-migration.mjs:20-55
themeToggle defaults off and is on in staging	src/charts/syrf-common/env-mapping.yaml:1467-1475; /home/chris/workspace/cluster-gitops/syrf/environments/staging/web/values.yaml:62, …/staging/api/values.yaml:91
LogRocket and Google Analytics are configurable; Sentry is bundled	env-mapping.yaml:1563-1572, :2031-2036; src/services/web/package.json:60-62, :77-78 (runtime state per environment UNVERIFIED)
Debug panels render on reviewer-reachable routes	…/stage/stage-reconcile/stage-reconcile.component.html:4-17 (app-debugger-group), :18 (gdColumns); …/stage/stage-review/review-completed/review-completed.component.html:28-38
Legacy project navigation keeps "Studies" and "Screening" sections	…/project/project-nav/project-nav.component.ts:438-548 (Screening info group visible: false at :519)
The project index has a "Pending Projects" tab and no cross-project work list	…/project-index/project-index.component.html:56-86
The user guide still says "Save" and "Submit" in one place and "Save progress" and "Complete" in another; the screening progress copy says "Unavailable"	user-guide/annotating.md:239-249 vs :375-376; user-guide/stages/screening.md:37; user-guide/getting-started/glossary.md exists

1.1 Owner-session integration (5 October 2026)

Chris decided the UX packages U1 to U3 and related amendments in the owner session of 4–5 October 2026 (consolidation §6; condensed packages U1 to U3 with their amendments and final clarifications). The detailed screens and rules are in the UX, devices and work discovery specification (the UX spec, rules UX-R…, evidence UX-AE…); the other eight specifications own the behaviour those screens show. The consolidation wins over older text on this page. Earlier wording is kept and marked where it is superseded. Amendment IDs (OS-A…) are those of the owner-session integration.

Authority boundary. These are planning approvals. Brief approval and implementation authorisation are separate (D1-04) and on hold since 5 October 2026. Nothing here authorises implementation, telemetry collection, a PWA build, offline writes, messaging the design session or building a new prototype. No gate has passed.

Decision statuses for this page.

ID	Status	What it settles here	Sections changed
Q-12	Decided (4 October)	A step selector with one form area in the existing annotation workspace	§4.3, §7.1, §11 (U7)
D3-03	Decided-amended (U1 with wording flexibility, OS-A21)	Save progress, Complete, Needs updating, Outdated answers, Fix, Accepted answers ("gold standard" in help text) and Screening result; "Draft auto-saved" and "Version checkpoint saved" as illustrative labels whose meaning is fixed	§2, §4.3, §5.2, §6.4
D3-04	Decided (U1)	Material 3 sentence case	§4.2, §5.2
D3-05	Decided-amended (U2 device scope)	Screening and full annotation on phones, tablets and desktops at launch; the largest project is an acceptance case	§6.1, §8.2, §8.3, §9
D3-06	Decided-amended (U2 final clarification, OS-A23)	Refreshed design and as many compatible new features as possible on legacy screens, with no change to review-workflow semantics before a confirmed conversion	§3.4, §14
D3-07	Decided (U3)	Project My work, a cross-project tab and a global badge even when notifications are muted; pending admin changes shown; full global landing page deferred	§3.1
D3-08	Decided (U3)	The agreed tester panel with no extra external recruitment now; consent-based timing telemetry without answer content	§9, §10
D3-01	Brief item (T-UX-00)	Material 3 roles, dark-mode and staging checks, visual baselines	§14
D3-02	Brief item (T-UX-00)	Release design reviews, risky-screen previews, routine checks	§13.2
D3-14	Decided (owner session, outside the register)	Add missing staging seeds; preserve staging data where possible; never production	§9
D3-15	Decided (owner session, outside the register)	Firefox, WebKit and touch coverage	§8.3
D2-07, D2-08	Decided (owner session, outside the register)	Form-owned inactivity timeout and in-progress limit; one shared session and place across tabs and devices with base-version checks	§5.4, §5.5, §6.5
D2-12	Replaced (OS-A29)	One consolidated current Study with reversible unmerge	§3.1, §5.2, §11 (U41)
D2-16	Replaced	No size-based exclusion; the largest project is an acceptance case	§5.5, §9
D3-20, D3-23	Brief items (T-SP-00, T-AC-00)	Presence counts with names only for Monitor holders; resolved notices leave counts and stay in history	§3.1, §5.4, §7.6
D3-22, D3-24	Decided-amended, Decided (O2)	Informative, permission-aware emails; per-project mute	§7.9
D4-01	Decided (S1, with OS-A16)	Unsure key where the profile enables it	§5.2, §6.1

Amendments outside the register count that change this page. Draft and checkpoint status (OS-A21); compatible features on legacy screens (OS-A23); PWA exploration beyond the MVP (OS-A22, §16); reconciled-answer hints with click-to-fill (OS-A04, §4.3, §7.1); form- and profile-owned blinding with unpredictable candidate order (OS-A02, OS-A03, §7.3); screening tie adjudication in an adjudication step (OS-A13, §7.3); reviewer-pool browsing and Saved work (OS-A27, OS-A05, §7.11); the admin eligibility explanation (OS-A08, §7.12); question-design presence (OS-A01, §7.13); active-work impact previews (consolidation §6, §7.14); the merge and unmerge wizard (OS-A29, §7.15); training (OS-A18, §7.16); contribution exclusion, reversible project deletion, the catalogue and notification content settings (OS-A24, OS-A25, D2-15, OS-A26, §7.17); the design-prototype handoff (OS-A30, §4.4).

Ambiguities recorded on this page (from UX spec §12; no owner answer is assumed). A1, holding edits on the device during a connection loss (§6.4); A2, reconciliation and design screens on phones (§7.3); A3, the largest project as test data (§9).

2. UX principles for SyRF

1. Reviewer time is the scarce resource. Reviewers screen and extract for hours a week. Every change to the reviewer page is measured against today's time per decision and per form (AC-UX-03, AC-UX-04), and nothing reviewer-visible ships without a keyboard path.
2. Independence and blinding are visible, never implied. Candidates never see each other (VS1 default off, BL1 aliases); the UI says when a view would make work "informed" (VS2) before the reviewer sees it; presence shows counts, not names (pending D3-20); decision buttons stay equal-weight so the interface does not nudge a decision (Review Prototype v4 correction 3). Owner session: candidates still never see each other's candidate answers, but labelled hints from existing accepted answers are shown by default and copied only by an explicit click, with exposure recorded (OS-A04, superseding "VS1 default off"); reconciliation blinding is owned by the form or profile and uses context-local aliases (OS-A02, OS-A03, superseding "BL1 aliases"); presence follows D3-20 (brief item).
3. Honesty about state and versions. The four AF2 facts stay separate (answer progress, readiness, reveal, persistence). Copy never says "saved" for a kept draft, never "Completed" for an answer scope, never shows a count without a real numerator, and always says which version counts (SL3). Freshness is labelled, not assumed. Owner session (OS-A21): the owner's illustrative labels "Draft auto-saved" and "Version checkpoint saved" replace the word rule about "saved"; the meaning rule stands, so an autosaved draft is never called a version or a submission and a checkpoint never implies completion.
4. Consistency and Material 3 (UI1). One design system of record (§4), one button and type language (D3-04), one copy deck (§5), and the same chrome in legacy and canonical projects (§3.4). A pattern is specified once and reused. Owner session: legacy projects also get every compatible new feature (D3-06 as amended, OS-A23), and every device class gets the same features (D3-05).
5. Accessible by construction. WCAG 2.2 AA is the working standard (audited to 2.1 AA at GA, D4-18); keyboard, screen-reader, forced-colours, reflow and touch requirements are part of every pattern's specification, not a ship-gate afterthought (§8).
6. Change is budgeted. Reviewers see at most three bundles of visible change before GA; each bundle ships with a "What changed" panel, a tour and help links (§12).
7. Evidence, not opinion. Real reviewers test prototypes before freezes and releases before pilots; UX metrics are acceptance criteria with thresholds (§9, §10).

3. Information architecture

3.1 Project IA (C17) with My work

C17's navigation stands: Overview, Review, Reconcile, Design, Stages, Members & groups, Data, Project settings; "Library" stays with Study Management. This strategy adds one surface and two chrome elements (PROPOSAL, pending D3-07). Owner session: D3-07 is Decided (U3, 4 October 2026): project My work, the cross-project tab and the global badge work even when notifications are muted, pending admin changes are shown, and the full global landing page is deferred (UX-R18 to UX-R23).

Element	What it is	Release	Window
My work (project level)	The reviewer's and reconciler's landing inside a project: every actionable item by role, with the four feature-owned queues as filters and the inbox as history	R3c (badge, banner, "changes awaiting approval"); R4a (full surface, "assigned reconciliation work", "requested reviews"); R4b adds "my concerns and outcomes"	U30 in W1
Global My work badge	An app-bar badge whose count is computed at read time over the four queues and the admission-based "to review" count, across projects; no notification flag involved	R3c	U30
Cross-project My work tab	A tab beside "Pending Projects" on the project index listing actionable items grouped by project (the #2621 global landing stays post-GA with its own owner)	R4a	U30
Admin banner	On a project overview, "N changes awaiting your approval" for pending LC1 requests, with every notification flag off	R3c	U30
Workflow version badge and panel	A badge in the overview and rail naming the project's workflow version; a panel in Project settings (admitted or classic, read-only containment, who changed it, when)	R0 (panel), R2a (badge, banner)	U32 in W0

My work contents (by role). To review (studies available to you by step, with Start or Continue); Needs your attention (Needs updating, Outdated answers with Fix, kept changes whose slot was released); Reconciliation (assigned to you, available, held); Requested reviews; Your queries (concerns and their outcomes); Awaiting your approval (admins: LC1 change requests, a stalled publication). Counts are computed at read time; rows deep-link to the task identity (RE4) and use stage-owned aliases (BL1) use context-local labels under the form's or profile's blinding, never an alias that carries across Studies (owner session, OS-A02, OS-A03). An item resolved by someone else leaves the list but stays in history (pending D3-23 D3-23, brief item). Empty states say why ("Nothing to review: this stage is waiting on other reviewers"). The inbox (when enabled) is delivery and history, never the source of truth (A-07).

Owner session additions to My work (UX spec §3.5):

Role	Added rows (owning specification)
Reviewer	Saved work you may still finish after a Study left the pool (SP); drafts whose place was released (RD); merge conflicts delegated to you (DM); training to complete or retry (TI); requested reviews from additional-review requests, which raise the effective target (RD)
Reconciler or adjudicator	Adjudication assigned to you or to your group (RS)
Administrator	Changes awaiting your approval, for example a protected change to a Completed stage (SP, Q-02); publications in progress or blocked (RD); merge conflicts awaiting resolution (DM); external screening runs awaiting acceptance (RI); training attempts awaiting manual assessment (TI); conversion findings needing action (BC)

The badge counts actionable rows across projects, independent of notification flags, per-project email mute (D3-24) and inbox state. Counts come from indexed read-time queries, never a stored counter; a failed query shows "Couldn't load", never a false 0 (PROPOSAL: 60-second refresh, proposed, not approved).

Where the new PRISMA, deduplication and adoption surfaces live. Data › PRISMA (report views and the reported-counts entry, R5b; per-search external-step records are entered on the search's own page under Study Management › Searches, P1). Study Management › Processing shows deduplication runs as long-running operations (P2), and Study Management › Library gains the duplicate review queue and the merge and unmerge wizard (P2a to P2c; OS-A29; D2-12 replaced by the consolidated merge). Adoption (R6) and the admission action (R0) live in Project settings › Workflow version; operator-only surfaces (adoption manifests, dry-runs) stay in the Admin Console.

Owner session placements. The duplicate review queue hosts the merge and unmerge wizard (D2-12 replaced, OS-A29; §7.15). R6 becomes universal baseline conversion waves: trials and pilots are admitted from Project settings › Workflow version, wave operations stay operator surfaces, and conversion findings reach admins through My work (BC spec). PRISMA views label imported references, source documents and Study items, and show coverage values and the machine-assisted share (RI spec §13). Design gains an AI screening models page listing model configuration versions and their use (RI spec §3.11; layout here, lane XS1 proposed). The application gains a restricted Deleted projects view, the catalogue browser with its publication-request queue, and Project settings gains notification content settings (ACD spec §13; §7.17).

3.2 Route inventory with an owner per route group

Following the M3 programme's "one owner per route group" rule. Paths marked (indicative) are proposals; verified paths come from project-nav.component.ts.

Route group	Routes	Mode	Owner	First release
Application chrome	app bar, My work badge, inbox button, help menu	both	M3 navigation owner (navigation plan slice 2); L16 for the badge	R3c
Project rail and footer checklist	rail sections per mode; setup checklist (readiness-based content from R2a)	both	M3 navigation owner; L16 supplies section models	R2a
Overview	project overview, admin banner, workflow version badge	both	L16	R2a
My work	my-work (indicative)	both (legacy shows the inbox-independent items it has)	L16 with L6 (reconciliation rows) and L4 (admission rows)	R3c, R4a
Review	stage review workspace (AF2, Dockview, step strip)	both	AF2 and stage-review programme; L5 lands programme changes in the agreed order	R2a onward
Reconcile	reconcile/… per study × form task (indicative)	canonical	L6	R4a
Design	questions, entity types, concepts & rules, outcome schemas, forms, screening profiles	canonical (legacy keeps the legacy editor)	L2; L9 (C1); L10 (O1)	R1a, R2a, R3b, C1, O1
Stages	per stage: overview, steps & settings, monitor	canonical; legacy keeps today's settings	L4 (designer), L16 (overview DTOs)	R3a
Members & groups	members, groups, permissions	both	L8 with the authorization programme	R1b
Data	export, history, agreement, PRISMA	both (export); canonical (history, agreement, PRISMA)	L11; L12 (PRISMA)	R2a, R5a, R5c, R5b
Study Management	studies, searches, processing (verified)	both	Study Management owner; L12 adds the dedup queue and merge wizard	P1, P2
Legacy sections	screening/overview, admin/screening-settings (verified) and today's stage settings	legacy only	unchanged owners; M3 restyle under D3-06	GA (restyle)
Project settings	general settings, workflow version panel	both	L16; L0 (admission action)	R0
Notifications	inbox, preferences	both	notification programme (M3 redesign before R2c, NS-10)	before R2c
Setup	guided setup wizard	canonical	L13	R3d
Owner session: Deleted projects	restricted list and restore (indicative projects/deleted)	both	ACD spec owner (T-AC-00)	X-DEL
Owner session: Catalogue	catalogue browser, item versions, publication requests (indicative)	both	ACD spec owner (T-AC-00)	R1a
Owner session: Design › AI screening models	model configuration versions and their runs (indicative)	canonical	RI spec owner (T-RI-00)	XS1 (proposed)
Owner session: Stages › Monitor › Why?	eligibility explanation timeline for a Study and stage (indicative)	canonical (current-state only on legacy)	SP and UX spec owners (T-SP-00, T-UX-00)	SP history release; timeline behind stageEligibilityTimeline (PROPOSAL)
Owner session: Review › Browse and Saved work	reviewer-pool browse list and Saved work (indicative)	canonical	SP spec owner (T-SP-00)	R3a (browsing optional, PROPOSAL stage setting)
Owner session: Training	training steps inside the step selector; assessment queue for admins	canonical	TI spec owner (T-TI-00)	Lane TR1

3.3 Workflow version badge and panel

• Names (PROPOSAL, confirmed with D3-03): "Classic workflow" for legacy projects and "Versioned workflow" for admitted projects. "Canonical" and "legacy" never appear in the UI (DD-11 glossary). Owner session: D3-03 was decided without these two names, so they stay PROPOSALs for the copy deck at F1c. "Classic workflow" is temporary: every project converts to the faithful baseline after pilots (OS-A15).
• Badge: in the overview header and as a rail footer line; text plus a shape, never colour alone; tooltip and panel link.
• Panel (Project settings › Workflow version): current version; what it means for this project (two sentences and a help link); admitted by whom and when; read-only containment state ("Reviewing is paused while this project is checked") with who set it and when; the audited admit or remove action for application administrators (R0). The panel is the admission and rollback UI that UX-18 found missing.
• Reviewer banner (read-only containment, U28): "This project is read-only while it is checked. Your changes are kept. Nothing you saved is lost." No edit control is enabled.

3.4 Legacy coexistence and the minimum shared chrome (D3-06)

Until adoption, a user who holds both kinds of project must still feel they are in one product:

Identical in both modes	Differs by mode
App bar, My work badge, inbox, help menu; project rail geometry, colours, type and states; Overview layout; Members & groups; Data › Export page; Project settings; the workflow version badge; status chips, page shell, page state, long-running job language; copy deck terms	Rail sections: legacy keeps "Studies" and "Screening" and today's stage settings; versioned projects show Design, Stages, Reconcile and the Data subsections; the question editor's two modes (C17)

Pending D3-06, legacy screens (chrome and shared pages, no behaviour change) are restyled under FEAT-023 so the atomic cutover covers them. U27 becomes a cross-project consistency check with a tester who holds both kinds of project (U45 extends it to the restyle).

Owner session (D3-06 decided-amended through the U2 final clarification, OS-A23). "Restyled with no behaviour change" is superseded. Existing and legacy project screens get the refreshed design and as many compatible new features as possible, while progression, screening, annotation, eligibility, serving and other workflow semantics stay faithful until a confirmed conversion or a later configuration change (UX-R16). A feature is compatible only if it leaves those semantics unchanged and the legacy flags-off spec set still passes (AC-ALL-02). The UX brief keeps a compatibility register listing each feature, its verdict, the reason and the parity evidence (UX-R17; a document, not a database record). Initial verdicts (PROPOSAL, UX spec §3.4):

Feature	Unconverted projects	Why (PROPOSAL)
Material 3 restyle of chrome and shared pages	Compatible	Appearance only
Navigation rail, help links, "What changed" panel	Compatible	No workflow semantics
My work, cross-project tab and badge	Compatible	Lists legacy work computable from current state
Phone and tablet layouts for legacy screening and annotation	Compatible	Layout only; the same actions
Keyboard screening shortcuts	Compatible	The same decisions through another input
Dark mode and accessibility fixes	Compatible	Presentation only
Draft and checkpoint status labels	Not compatible as worded	A legacy save overwrites the session and creates no immutable version; legacy screens keep truthful legacy wording
Step selector	Not compatible	Unconverted stages have no steps; the opt-in wizard maps them
Unsure, discussion, tie adjudication	Not compatible	They change screening semantics
Reconciled-answer hints and click-to-fill	Not compatible	They change exposure
Reviewer-pool browsing	Not compatible	It changes serving
Eligibility explanation	Compatible for current state only	No pool history exists before tracking begins; the panel says so
Presence counts	Compatible where tracking is already on	Existing behaviour

Coexistence itself is temporary: after pilots, universal baseline conversion moves every remaining project into the new structures (OS-A15; BC spec).

4. Design system of record and pattern inventory

4.1 System of record

The design system of record is FEAT-023's emitted token contract (--mat-sys-* roles from mat.theme() and documented --syrf-* brand or domain roles, measured by src/services/web/scripts/token-contrast-contract.mjs) plus the shared Angular components: shared/page-shell (page shell and page state), shared/side-nav (section shell), the project navigation rail (navigation plan decision 2), shared/overlay-scroll, shared/row-overflow, the StatusView chip contract (Study Management D5; kinds ok, info, warn, stopped, muted) and the long-running-job visual language (docs/features/material-3-migration/technical-plan.md, "Long-running-job visual-language contract"). Prototype kits (_ds React bundle, QM v2 HTML, redesign v7, #2621) are design inputs; their token names are mapped, never copied (v10 README "Design tokens"). A new shared token goes through FEAT-023's serial theme-contract change.

4.2 Button and type language (D3-04)

Pending D3-04 (owner session: D3-04 decided through U1, 4 October 2026): Material 3 sentence case for every label; button shape and radius from the M3 component theme as emitted, no per-feature radius overrides; no ALL-CAPS tracking; type from the M3 type scale and the --syrf-space-* ladder (Study Management token mapping). The v4 stage-review spec is re-audited against this before further parity work; items that change:

v4 spec item	Under D3-04
ALL-CAPS 13px/500 letterspaced buttons (corrections 3, 4, 11; "Design tokens")	Sentence case, M3 button type and shape
4px button and input radii, 8px cards, hex values	M3 shape and colour roles; no literals (UI-1, UI-10)
"Unsaved changes" chip; footer "All changes saved"	Save-status indicator and copy deck terms (§6.4); owner session: Draft auto-saved, Version checkpoint saved and Complete as distinct states (OS-A21)
"Remove all annotations…" (destructive)	Versioned clear or "Discard kept changes" wording (AC-R2a-09)
Sidenav in-flow at 1200px	lt_lg edge (1239.98px) from break-points.ts
Equal-weight outlined Include and Exclude with kbd hints	Kept (deliberate non-nudging); hints render only once shortcuts exist (U33)
Anchored What's new tour	Kept as the shared tour component (§12)
Content threshold 980px of remaining width	Kept as a content-driven rule; verified at 925px (UI-6)

4.3 Pattern inventory

Each pattern is specified once (states: hover, focus-visible, pressed, selected, disabled, error, loading, empty; tokens; keyboard model; narrow behaviour; copy keys), built once as a shared component, and shown on a spec gallery route behind a flag (E84). Status is per release; every pattern enters U43 before its first consumer builds.

Pattern	Used by	States and tokens	Keyboard model	Narrow behaviour	Copy keys (deck)	First
Step strip (owner session: "step selector", Q-12 decided)	reviewer page (Q-12, U7)	selected, available, locked, done, skipped, held; owner session: adds "not applicable", shows the system adjudication step only to eligible adjudicators and training steps where configured; --mat-sys-secondary-container selected; status by shape plus text	[ ] move, Enter opens, roving tabindex	collapses to a select-like menu below lt_sm	steps.*	R3a
Save-status indicator	AF2 action bar, reconcile host, setup wizard	Saving, Kept, Retrying, Offline, Failed, Saved, Completed (§6.4) owner session (OS-A21; UX spec §3.2): Not started, Draft auto-saved, Version checkpoint saved, Draft auto-saved with last checkpoint, Complete, Complete with newer draft, Saving, Retrying, Offline, Failed (§6.4)	status is a polite live region; Retry is a button	icon plus short text below lt_sm	save.*	R2a
Conflict and take-over screens	reviewer and reconciler forms	read-only, take-over, stale base, copy kept (§6.5); owner session (D2-08): one shared session across tabs and devices; a same-answer change from a stale base shows a conflict panel with both values; read-only with take-over is only a brief option for small screens	focus moves to the summary; one primary action	full-width card	conflict.*	R2a
Status chips (StatusView kinds extended)	sessions, forms, versions, queues	Needs updating, Outdated answers, Held, In progress (saved) Version checkpoint saved, Kept changes Draft auto-saved, Completed, Unpublished, Current version, Published; owner session: Saved work, No longer in this stage, Pending adjudication, Single annotator; each kind maps to an existing StatusView kind	none (chips are not targets)	wraps; never truncates the kind word	status.*	R2a
Version badge	forms, profiles, sessions, stage settings	current, superseded, unpublished	tooltip on focus	text stays	version.*	R2a
History timeline	history panel, gold history (4.4)	current, pinned inputs, policy-derived, withdrawn, inputs changed	list semantics; Enter opens a version	single column	history.*	R2a, R4a
Candidate pills and agreement icon	reconciliation form (4a)	agree, differ, one-sided, N candidates with overflow menu; selector never hides a disagreeing candidate (U1); owner session: context-local labels in random order with no chronology clues when blinded (OS-A02, OS-A03); a one-candidate layout for required human reconciliation (OS-A28); blank comparisons labelled "Not assessed" (Q-04)	arrow keys between pills; Enter copies an answer	selector plus single column	reconcile.*	R4a
Prefill (autofill) marker	reconciliation form	prefilled, edited, accepted (RE2: no per-field confirm)	none; marker is described by the field's accessible description	unchanged	reconcile.prefill	R4a
Impact flow scaffold (stepper)	publication, profile publication, stage settings publish	review, impact, choices, confirm; busy; blocked by stale evidence	stepper roles; Escape asks before discarding	one step per screen	publish.*	R2c
Queue list (My work rows)	My work, pool, queues	actionable, waiting, held, resolved	list with row actions; Enter opens	cards below lt_sm	mywork.*	R3c
Workflow version badge and panel	overview, rail, settings	classic, versioned, read-only	panel is a page	text	workflow.*	R0, R2a
What changed panel	app bar	unread, read, dismissed per user	dialog trap and return	full-screen sheet below lt_sm	per-release keys	R2a
Anchored tour	reviewer page, reconciler page	step, paused, resumed	Esc pauses; arrows move; focus follows the spotlight	not shown below lt_sm (RP4)	per-tour keys	R3a
Presence count chip	study header, pool	held, released, offline; counts only (D3-20, now a brief item: names only for Monitor holders, never across reconciliation blinding)	none	hidden below lt_sm	slot.*	R2b
Progress vocabulary strip	reviewer progress, stage overview	your work, available to you, waiting on others, locked by a step, enough reviewers	none	wraps	progress.*	R2b
Keyboard hint (kbd)	decision card, action bar	rendered only when the shortcut is live	n/a	hidden when a touch pointer is primary	keys.*	R3a
Blinded bibliographic placeholder	screening card	hidden authors, journal, year with a reason line (SR-25, PROPOSAL)	n/a	text	blind.*	R3b
Owner session: reconciled-answer hint and click-to-fill (OS-A04)	reviewer form	hint shown (labelled with authority and snapshot), hint used, hint hidden by step, no applicable hint (no control shown); replacing an own value needs an explicit choice	"Use accepted answer" is a button per question; "Use all available accepted answers" in the action bar	inline under the control	hint.*	R4a
Owner session: eligibility explanation timeline (OS-A08)	Stages › Monitor, Study history; reviewer "Why isn't this available to me?"	entry, departure, review start, completion, configuration change, continuation, tracking gap, "No review is recorded"; historical versions labelled	list semantics; Enter opens the evidence	single column	explain.*	SP history release
Owner session: design-page presence (OS-A01)	question and form design pages	viewing, editing, editing marker per question, live update arrived, conflict (both versions kept), publishing banner, live updates paused	avatars have names as accessible labels; conflict panel takes focus	avatars collapse to a count	presence.*	R1a, R2a
Owner session: active-work impact preview (consolidation §6)	publication, target change, merge, unmerge, capacity, filter, continuation, stage completion, policy, import acceptance, exclusion, deletion, conversion waves	computing, ready, changed since reviewed, Apply anyway available (temporary reservations only), committed, refused; counts for all, names only with Monitor	stepper roles from the impact scaffold; Confirm and Apply anyway are separate buttons	one section per screen	impact.*	R2c
Owner session: reviewer-pool browse list and Saved work (OS-A27, OS-A05)	Review › Browse; Saved work	available, waiting for the team's screening result, enough reviewers, stopped by exclusion, no longer in this stage; own status per step only	list with row actions; Enter opens; start re-checks admission	cards below lt_sm	browse.*, saved.*	R3a
Owner session: adjudication task (OS-A13)	adjudication step	assigned to me, assigned to my group, claimed, rationale required, inputs changed, resolved	as the reconciliation form	selector plus single column	adjudicate.*	R4p
Owner session: merge conflict resolution (OS-A29)	merge wizard, delegated task	agreeing (prefilled controls), conflicting (side by side), delegated, resolved, unresolved pending	as the reconciliation form	single column	merge.*	P2b
Owner session: training attempt and feedback (OS-A18)	training steps; assessment queue	not started, in progress, submitted, awaiting assessment, passed, failed, retry allowed or not, admitted	as the reviewer form	as the reviewer form	training.*	Lane TR1
Owner session: consent card (D3-08)	first pilot visit per project	asked, granted, declined, withdrawn	dialog trap and return	full-screen sheet below lt_sm	consent.*	R2a pilots

Existing shared components are mandatory where they apply: app-page-shell and app-page-state on every new admin page; the StatusView chip for every status; the long-running-job language for every operation that can take more than a few seconds (publication phase 2, ASySD matching, as-of export generation, O2 dry-runs, adoption waves), each with a place in Processing or a release-owned surface (U40).

4.4 Handoff template

Every prototype pack ships with a handoff on this template, modelled on the navigation handoff (docs/features/material-3-migration/handoffs/project-navigation-drawer/README.md):

1. Why it changed (one paragraph; the decisions it serves, by ledger ID).
2. Geometry (exact): widths, heights, radii, spacing from --syrf-space-*.
3. Type and colour: a table of element → role (--mat-sys-* or --syrf-*); no literals; a token-mapping table from the prototype's variables.
4. Data model: the DTO or store shape the pattern renders, including freshness labels.
5. Behaviour: states, transitions, keyboard model, pointer and touch, narrow behaviour at the UI-6 widths, reduced motion.
6. Copy keys: every string, by deck key, with the glossary term it uses.
7. Accessibility: roles, names, live regions, focus order and return, forced colours.
8. Acceptance checks: numbered, each tied to a defect found in review.
9. Known gaps.
10. Deviations log: filled by the implementing agent (file:line), as the navigation plan does.
11. Audit against code: DONE, PARTIAL or NOT DONE with file:line, before building.
12. Fixture data used: realistic open-licence abstracts and a 200-question form where relevant.

Next design iteration input (owner session, OS-A30). The design-prototype handoff is the self-contained specification for iterating SyRF Prototype v10 against the owner-session decisions: goals, terminology, roles and blinding, the screen inventory with the step selector and one form area, flows and states, configuration ownership, phone, tablet and desktop requirements, MVP and deferred scope, traceability, the prototype changes and a copy-ready design-session prompt. The comparison of v10 and Review Prototype v4 with the decisions is in the UI coverage comparison §6. Prototype packs that come back follow the template above. Producing the handoff is the deliverable; no design session is messaged and no new prototype is built by this package.

5. Copy deck and glossary

5.1 Mechanism (E83, F1c)

• One copy deck document in the programme's feature folder under docs/features/ (copy-deck.md, PROPOSAL location), with one definition per term, its internal name (DD glossary), where it appears, and "never use" alternatives.
• Typed message constants per feature (<feature>-messages.ts, as const), following src/services/web/src/app/study-presence/session-messages.ts and the session copy review. Core verbs and terms live in one shared constants file consumed by every feature.
• A guard spec over the programme's folders fails when a template or constant uses a banned string ("Save draft", "All changes saved", "Submit", "Gold standard" as a bare label, "Outcome" for a screening result, "Unavailable" for progress, "canonical", "legacy") or hard-codes a core verb instead of importing it; modelled on no-hardcoded-help-urls.spec.ts.
• User-guide glossary parity: every deck term marked glossary must have an entry in user-guide/getting-started/glossary.md; a docs script checks it in CI. The guide's "Save"/"Submit" wording (annotating.md:239-249) is corrected in the R2a docs PR.
• Validation: a terminology card sort in W0 (U42) before the deck freezes at F1c.

5.2 Terms and verbs (D3-03, Q-D4, Q-D5, DD-11)

User-facing term	Meaning	Internal name	Never use	Label
Save progress	Create an immutable incomplete version that becomes current	SaveSession	Save, Save draft	pending D3-03 decided D3-03 (U1, 4 October 2026) (already shipped in AF2 and the guide)
Complete	Validate and create an immutable completed version that counts	CompleteSession	Submit, Finish	pending D3-03 decided D3-03 (U1)
Changes kept, not yet saved Draft auto-saved (illustrative; owner session, OS-A21)	The autosaved draft is held on the server as a recoverable draft; it is not a version or a submission	SessionDraft	Saved, Draft saved, All changes saved; superseded: "Changes kept, not yet saved", "Autosaved—not yet submitted"	pending D3-03 decided D3-03 with wording flexibility: the words may change through design review, the meaning may not
Owner session: Version checkpoint saved (illustrative)	Save progress created an immutable incomplete version; it does not imply completion; it stays visible when newer edits are autosaved	SaveSession result	Saved (alone), Submitted, Completed	Decided D3-03 with the U1 amendment and wording flexibility
Needs updating	An answer invalidated by a publication choice; blocks Complete until valid	policy requireReanswer	Invalid, Stale	pending D3-03 decided D3-03
Outdated answers	A session pins a superseded shared revision; a warning that never blocks alone	SF5 flag	Contains outdated annotations (DTO wording only)	pending D3-03 decided D3-03; owner session: the form may instead block completion until addressed (D4-17, O3)
Fix	Create a current incomplete version from an outdated session and open it	FixTransition	Repair, Reopen	pending D3-03 decided D3-03
Update to version N	Move a session to the current form version (Upgrade transition, VA-10)	Upgrade	Migrate, Rebase	PROPOSAL
Accepted answers (gold standard)	The reconciler's authoritative answer set; "(gold standard)" in help text on first use	StudyGold, GoldSnapshot	Gold as a bare label, Reconciled answers as a status	pending D3-03 decided D3-03 (Q-D4); owner session: authority labels Single annotator, Human reconciled, Adjudicated, Merge resolved (AcceptedResultVersion)
Screening result	The collective result for a profile (Pending, Conflict, Included, Excluded)	ScreeningOutcome	Screening outcome (UI), Outcome	pending D3-03 decided D3-03 (Q-D5); owner session: adds Awaiting extra review, In discussion and Pending adjudication, none of which is a definite outcome
Your decision	A reviewer's own Include or Exclude (or Unsure if D4-01 where the profile enables it; D4-01 decided)	ScreeningDecision	Vote	PROPOSAL
Outcome measure, outcome data	Measured outcomes and their series	OutcomeMeasure, Observation	Outcome for screening	DD glossary
Query, concern, resolution	A challenge to an accepted answer and its per-raiser result	Concern, ConcernResolution	Outcome for a query	DD glossary
Publish (a form or profile version)	Make a version current with a recorded impact choice	FormVersionIssue, ProfileVersionIssue	Release, Deploy	DD glossary
Unpublished	A form, profile or question version not yet published; editable until first use	draft definition	Draft	PROPOSAL (PH-19)
Review (your review of a study)	A reviewer's work on one study and one form, across stages	FormSession	Session	PROPOSAL
Step	One unit of a stage's workflow (screening, form or both)	ReviewStep	Task, Phase	ledger DP6
Screening profile	Profile-owned eligibility questions and rules	ScreeningProfile	Rationale, Criteria set	DP4
Primary and secondary study (duplicates) Consolidated Study and input Studies (owner session; DM spec)	Merge as alias; records keep their own study One consolidated current Study after a merge; the inputs are kept as history and restored by an unmerge	StudyAlias Study state, StudyVersion, StudyMerge, StudyUnmerge	Canonical study; alias	DD glossary; D2-12 replaced (OS-A29)
Classic workflow, Versioned workflow	A project's mode before and after admission	CanonicalEnrolment	Legacy, Canonical, New	PROPOSAL (§3.3)
Review slot	The reviewer's right to review a study for a form; held while active	SlotReservation	Spot, Reservation, Session	shipped (session-messages.ts), RT-22
Enough reviewers	The study has the reviews it needs for that step; no new slot	capacity	Unavailable, Sufficiently screened, At capacity	RT-22, UX-22
Released	The slot is no longer held (idle or offline timers lapsed)	expiry	Expired, Removed	RT-22
Offline	The browser cannot reach SyRF	connection state	Disconnected from the server	RT-22
Informed, independent	Whether a contribution was made after seeing accepted answers (VS2)	ExposureState	Contaminated	VS2
Held	Reconciliation work waiting on a compatibility decision	task held state	Blocked	v10 §3
Accepted copy, Copy from another tab	A draft kept from a non-holder tab after take-over (§6.5)	conflict copy	Conflict	PROPOSAL; owner session: under D2-08 (one shared session across tabs) the copy arises only from a stale-base conflict
Owner session: Saved work	Started work a reviewer may still finish after the Study left the stage pool or after exclusion	continuation basis	Pool, Available	SP spec §13
Owner session: No longer in this stage	The Study left the stage's pool (filter-driven departure)	StagePoolDeparted	Excluded (unless the reason is a screening Exclude)	SP spec §13
Owner session: Waiting for the team's screening result	A step needs the collective Include (stage setting)	progression basis	Locked (alone), Pending	SP spec §13
Owner session: Enough reviewers are already working on this	No place is free on the form or step	capacity	Unavailable, At capacity	SP spec §13; D3-19
Owner session: Stopped by exclusion; Already sufficiently reviewed; No review is recorded	Exclusion-stop applies; the activity is sufficient from evidence collected anywhere; history shows no review (never an invented reason)	exclusion-stop; sufficiency; absence of records	Rejected; Done; Skipped	SP spec §13
Owner session: Unsure	A reviewer's own decision that the Study is not excluded but not a definite Include	ScreeningDecision value	Maybe, Don't know	D4-01 decided
Owner session: Adjudication; adjudicator	Resolution of a tie or unresolved Unsure by an assigned member or group member, in the adjudication step	AdjudicationTask	Override, Tie-break vote	OS-A13
Owner session: Hint from accepted answers; Use accepted answer	A labelled existing accepted answer; the explicit copy action	HintExposure, HintAdoption	Prefilled, Suggested answer	OS-A04
Owner session: AI-model-generated screening decision; AI screening model	A screening decision imported from an AI screening model, attributed to the model, never to a person	ExternalScreeningDecision	Model decision, Robot, Auto-screen	RI spec (superseded wording 14)
Owner session: Deleted project	A project in the reversible deleted state, restorable from the Deleted projects view	Project.deletionState	Archived, Removed, Erased	OS-A25

Distinct terms for each kind of draft (PH-19, ADR-010's five conflated drafts): reviewer autosave = "kept changes"; explicit incomplete version = "progress saved" or "In progress (saved)"; reconciler autosave = "kept changes" (same machine); correction in progress = "Correction in progress" (v10 r5); unpublished definition = "Unpublished"; resumable setup = "Setup in progress"; conflict copy = "Copy from another tab". The word "draft" appears only in the deck's internal-name column.

Owner session (OS-A21). Reviewer and reconciler autosave become "Draft auto-saved" and an explicit incomplete version becomes "Version checkpoint saved" (both illustrative). The owner's wording uses the word "draft" for the autosaved state, so "the word 'draft' appears only in the internal-name column" is superseded for that one term. The other draft kinds keep their distinct terms ("Correction in progress", "Unpublished", "Setup in progress", "Copy from another tab") so the five meanings stay separate. Design-page drafts of questions and forms are "Unpublished" and are never labelled with the reviewer status words.

Readiness vocabulary (approved AF2 four-state model, PH-19; DOC-APPROVED). Answer scopes (categories, entities, branches, steps) use exactly the four approved states and their precedence: Needs attention (a revealed applicable issue), Ready (every applicable completion requirement met), In progress (some meaningful answers, work remaining), Not started; "No applicable questions" is handled before them, and 0/0 counters are hidden. "Ready" is for answer scopes; "Completed" is reserved for the persisted review lifecycle. Counts are named ("1 of 3 required answered"). The programme extends the model with two scope-level markers that never change a state's meaning: Needs updating (a publication choice invalidated an answer; shown as Needs attention with its own wording) and Outdated answers (a shared revision was superseded; a warning that never blocks alone). Status glyphs are shape-distinct with contextual accessible names, never colour alone.

5.3 Reviewer progress vocabulary (UX-22)

Term	Replaces	Where
Your work: N in progress, N completed	"Incomplete studies" headings	My work, My studies navigator, stage progress dialog
Available to you	"Studies to screen"	progress strip
Waiting on others	(none; today shows "Unavailable")	progress strip, My work empty state
Locked by a step	(new, R3a)	step strip tooltip, My work
Enough reviewers	"Unavailable", "sufficiently screened" (user-guide/stages/screening.md:37)	progress strip, slot copy

5.4 Slot and presence copy (RT-22, D2-07, D3-19, D3-20)

Pending D2-07's recommended rule (held while active under today's idle and disconnect timers counting draft activity; released when they lapse with the draft kept; Complete still allowed as an extra contribution unless an optional capacity cap applies, D3-17):

Owner session (D2-07 and D2-08 decided; D3-17 and D3-18 carry-forward alignment). The "middle ground" rule above is superseded. The form owns the inactivity timeout and the per-reviewer in-progress limit across every route and tab. One shared session holds one place across tabs, devices and stage routes; an idle or closed tab never releases it while another connection is active; when the session times out the place is released and the draft is kept (SP spec §3.11). The capacity cap is a form-owned baseline separate from the target, off by default and equal to the effective target when enabled (both defaults proposed, not approved); it never evicts held work. In the copy below, read "slot" as "review place" and "Your changes are kept" as "Your draft is kept". Where tracking is off the admin UI says "capacity not enforced".

State	Copy (Comfort, Explain, Act)
Held	"Your review slot on this study is held while you work. Your changes are kept as you go." (status line only; no banner)
Idle warning	"You haven't done anything here for a while. Your slot will be released in [countdown], but your changes are kept."
Released, slot still available	"Your review slot was released while you were away. Your changes are kept. Continue to take a slot again."
Released, enough reviewers, no cap	"This study now has enough reviewers. Your changes are kept, and you can still complete this review as an extra review."
Released, enough reviewers, cap applies	"This study now has enough reviewers, so this review can't be completed. Keep your changes or discard them." [Keep] [Discard…]
Dependent step refused at Include (D3-19)	"Your Include is recorded. This study already has enough reviewers for [step]; nothing more is needed from you here." Owner session (D3-19 brief item): the step shows "Enough reviewers are already working on this" and the screening decision stands
Offline	"You're offline. Changes are kept on this device until you reconnect. Your slot is held for [countdown]." Owner session: local holding on the device is ambiguity A1 (§6.4); the UX spec's illustrative copy is "Offline. Your latest edits are held until you reconnect."
Presence (D3-20)	"N reviewers on this study now" (count only; names only in Monitor for capability holders; never shown in reconciliation). Owner session: D3-20 is a brief item; a Monitor holder who is also the blinded reconciler for that Study sees no names (SP-AMB-07 recommendation)
Owner session: Saved work after departure (OS-A05)	"This study is no longer in this stage. You can still finish the work you started; your draft is kept." With a restriction: "An administrator has stopped further work on studies that left this stage. Your draft is kept."
Reconciler editor claim refused (X-RECLAIM)	"Someone else is reconciling this study right now. Choose another study or come back later."

5.5 Error and recovery copy for typed conflicts (UX-17)

Every typed outcome names what moved, what is kept and one primary action. All strings come from the deck; focus moves to the summary; nothing is lost silently.

Typed outcome (C18)	What the reviewer sees	Options	Preserved
Stale base (Save or Complete on a superseded draft etag or base)	"A newer version of this review was saved, perhaps in another tab. Your changes here are kept as a copy."	Open current version (primary); Compare copies	Both: the current version and the copy
Two-tab lease (second tab opens). Superseded (D2-08 decided): both tabs edit the one shared session with base-version checks; a same-answer conflict shows a panel with both values. Read-only with take-over is only a brief option for small screens (RD §12)	"This review is open in another tab or on another device."	Take over editing (primary); View only	The other tab's edits become a copy on take-over
Lease lost (this tab was taken over). Superseded with the row above	"Editing moved to another tab. Changes you made here since [time] are kept as a copy."	Reload; Compare copies	The copy
Retryable conflict or outcome unknown	Save-status Retrying; after exhaustion, Failed with Retry	Retry; keep working	Kept changes on this device
Locked, fenced, publication in progress (D2-10)	"This form is being updated. Reviewing resumes in about [n]. Your changes are kept." with a progress line	Wait; go to My work	Draft
Size limit exceeded (E28). Owner session: D2-16 is replaced; limits are engineered for the largest project, an acceptance case (RD-R33), so this copy applies only to genuine limits beyond it	"This review is too large to keep in one piece. Save progress now to keep what you have."	Save progress (primary)	Draft up to the limit
Conflicted legacy answer	"Two earlier answers to this question disagree. Choose which to keep."	Choose; keep both visible in history	Both revisions
Held for compatibility (R4a)	"This study is held until an administrator decides whether versions are compatible."	Open another task	Nothing changes
Revoked access	"You no longer have access to this project." (inbox: "Related item unavailable")	Go to My work	Drafts retrievable by owners (AC-ALL-18)
Admission refused, feature unavailable	"This isn't available in this project yet."	Back	n/a
Read-only containment (U28)	§3.3 banner	None; nothing is editable	Everything saved
Enough reviewers (AtCapacity)	§5.4	Keep or discard	Kept changes
Owner session: project deleted (OS-A25)	"This project has been deleted. Your draft is kept."	Go to My work	Draft and all history
Owner session: continuation restricted (ContinuationRestricted, OS-A05)	"This study is no longer in this stage and further work on it has been stopped. Your draft is kept."	Go to Saved work or My work	Draft
Owner session: stale browse item	"No longer available in this stage" (rendered under blinding)	Back to the list	Nothing changes
Owner session: impact changed at commit	"The impact changed since you reviewed it." with the difference listed	Review and confirm again; Cancel	Nothing commits

6. Reviewer efficiency

6.1 Keyboard screening path (UX-02, PH-35; R3a/R3b scope, E87)

Moved into this plan's scope at R3a (default profile without eligibility questions) and R3b (profiles with eligibility questions), because they belong to the screening renderer and step strip that F5 owns, not to the AF2 parity join. Pending D3-05 the same path works on a phone for title and abstract steps. Owner session (D3-05 decided-amended): phones, tablets and desktops support screening and full annotation at launch, including very large forms, with no feature removed solely because the device is a phone (UX-R04 to UX-R07). Presentation may differ by device; draft, Save progress, Complete, validation and access behave identically.

Situation	Keys	Actions per decision
Plain profile (no eligibility questions, reasons off)	I include, E exclude; auto-advance follows the review preference ("open the next study" default)	1
Reasons required on Exclude (DP5)	E, then a reason by number key or arrows and Enter	2
Derived decision (DP3, profiles with eligibility questions)	answer questions by number keys or arrows; the derived decision and its reasoning update live but never vote; Enter submits	answers + 1 (the submit is the decision)
Unsure (if D4-01 approves D4-01 decided, S1)	U as a third decision key where the profile allows it; "Unanswered only" moves to Shift+U	1
Skip without deciding (RC6)	N	1 (records nothing)
Navigate	J jump to next required, [ ] previous or next step or category	n/a

Rules: keys are ignored while a dialog, menu or text field is active; the decision card shows kbd hints only once the shortcut is live (review-decision-card.component.spec.ts:391-392); under DP3 the I and E keys are inert and the hint reads "Answer the questions; Enter records your decision", so one key never contradicts a derived decision (PH-35); every key has a visible button equivalent; a 390px phone shows the same card with 44px targets and the keyboard hidden (U33). The ≤2 actions rule counts actions beyond answering eligibility questions.

6.2 Live completeness and jump

Every form host (reviewer, reconciler, setup wizard) shows "N required missing · Jump to next" in its action bar while incomplete (grey pending; error only after a rejected Complete), per Review Prototype v4 and the approved AF2 plan's summary pattern. Jump opens the right step, category, branch and entity, waits for the target to mount and focuses the control. The reconciler's count reads "N to resolve" (v10 §7). Validated in U34.

6.3 Input latency under autosave

Autosave never blocks input. Draft serialisation and the write happen off the input path (debounced; PROPOSAL 2 s per AC-R2a-28); the per-holder write sequence makes duplicates harmless (brief §1.8). Budget: keystroke-to-paint p95 under 50 ms at 200 and 1,000 questions on the AF2 perf spec's reference profile (e2e/tests/perf/annotation-form-perf.spec.ts), measured with autosave on (AC-UX-04).

6.4 Save-status state machine (UX-04)

One quiet status in the action bar; one polite live region; no toast per autosave; the dirty navigation guard arms on any kept change that has not reached the server.

State	Trigger	Copy	Announce	Actions
Clean (owner session: Version checkpoint saved, or Complete)	no change since the last version	"Progress saved [time]" or "Completed" "Version checkpoint saved [time]" or "Complete · [time]" (illustrative)	no	none
Saving	a change is being kept	"Keeping changes…" "Saving draft…"	no	none
Kept (owner session: Draft auto-saved)	the server acknowledged the draft (etag advanced)	"Changes kept, not yet saved" "Draft auto-saved · no checkpoint yet", or "Draft auto-saved · last checkpoint [time]" when a checkpoint exists, or "Draft auto-saved · your completed version ([time]) still counts" after Complete (illustrative)	once per editing session, not per keystroke	Save progress, Complete
Retrying	a retryable error or outcome unknown; same write sequence resent with backoff	"Trouble keeping changes. Retrying…" "Trouble saving draft. Retrying…"	once	none; input continues
Offline kept on this device (owner session: subject to ambiguity A1 below)	navigator.onLine false or health probe failing; changes written to a bounded local copy (IndexedDB)	"You're offline. Changes kept on this device." "Offline. Your latest edits are held until you reconnect." (illustrative)	once	none; input continues
Failed	retries exhausted or a non-retryable typed outcome	"Changes couldn't be kept on the server. They're still on this device." "Draft not saved to the server" with Retry	once, with focus to the status on an explicit Save or Complete	Retry; Save progress stays available when the server returns
Reconnected	connectivity restored; local copy replayed in sequence	"Reconnected. Changes kept." returns to "Draft auto-saved"	once	none
Owner session: Not started	no draft and no version	"Not started"	no	none
Owner session: incomplete Save over a completed version	the reviewer presses Save progress while the latest version is completed	Confirmation first: "Saving progress now replaces your completed version. This review will stop counting as complete until you complete it again." (Q-27)	the dialog	Save progress; Complete instead; Cancel

Rules: the local copy replays only while the server draft etag is the one it was based on; otherwise it becomes a "Copy from another tab" (§6.5) and is never applied silently; Save progress and Complete present the draft etag and consume the draft atomically; a stale autosave arriving after a newer explicit version is discarded by the client (brief §1.8). Harvested from QM v2 §14 (.local/qm-designer-handover/04-versioning-and-publishing/publishing-versioning-ux.md:845-928) with the states renamed to the deck. Validated in U31; AC-UX-06 covers recovery.

Owner session (D3-03 with the U1 amendment and wording flexibility, OS-A21). The states are renamed as marked. The three meanings are fixed and the words are illustrative: a recoverable autosaved draft ("Draft auto-saved"), an explicit immutable checkpoint ("Version checkpoint saved") and a completed version ("Complete"). An autosaved draft is never called a version or a submission, a checkpoint never implies completion, and an earlier checkpoint stays visible when newer edits are autosaved (UX-R11 to UX-R13). The copy-deck guard rejects the superseded strings "Changes kept, not yet saved", "Autosaved—not yet submitted" and "Save draft" (UX-R15, PROPOSAL enforcement). Legacy screens keep truthful legacy wording, because a legacy save overwrites the session (§3.4).

Ambiguity A1: holding edits on the device during a connection loss (UX spec §12; no owner answer assumed). The "Offline kept on this device" row, E82 and AC-UX-06 assume a bounded local copy in IndexedDB replayed on reconnect. The owner said no offline writes are authorised and protected data must not be cached by accident (U2 PWA clarification). Options: (a) keep a bounded in-session holding area for short interruptions, cleared at logout, completion and access loss, never used to fetch new work, replayed only when the server base version still matches; (b) hold edits in memory only, so closing the tab loses unacknowledged edits; © remove local holding until the PWA design decides. Recommendation: (a), described as connectivity resilience within one editing session and confirmed explicitly in the UX brief because it stores answer data on the device. Until confirmed, the row and AC-UX-06's 60-second offline interval stay PROPOSALs.

6.5 Conflict screens

• Two-tab take-over (RT-10, D2-08): the second tab opens read-only with a banner and "Take over editing"; take-over transfers the lease by stable client tab ID; the displaced tab is told why, keeps a local copy until reload, and its unsaved edits are kept server-side as a bounded conflict copy ("keeps both" is literal). Copies appear in the history panel with timestamps; the reviewer chooses "Use this copy" or "Discard copy" (audited). Works with tracking off. Superseded (D2-08 decided in the owner session): one reviewer uses one shared session and place across tabs and devices. Connections are tracked separately, both edit with base-version checks, and a change to the same answer from a stale base shows a conflict panel with both values; nothing is discarded silently. The read-only and take-over presentation is only a brief option for small screens (RD spec §12; UX spec §8).
• Stale base: §5.5 row 1. The screen shows both timestamps, which tab or device made them when known, and a per-question comparison for small forms (a count plus "Compare" for large).
• Enough reviewers after a released slot: §5.4; a draft never holds a slot for days (D2-07). Owner session: the form's inactivity timeout releases the place and keeps the draft; completing it later re-checks capacity (D2-07 decided).

7. Key flows

7.1 Reviewer screening and annotation

Study header (title, position, chips: Your decision, Completed, In progress (saved), Kept changes, Needs updating) → step strip (R3a) → one form area for the selected step → decision card (equal-weight Include and Exclude; derived decision with reasoning under DP3; reasons under DP5) → action bar (Revert, N required missing · Jump, Save progress, Complete) → save-status line. Needs updating shows beside each affected question with "Why it changed" and "What to do differently" (VU2); Complete is refused until valid, with the summary focused (approved AF2 plan). Outdated answers show a non-blocking warning with Fix (R2d). Presence shows counts only. The history panel lists versions, kept copies and policy-derived revisions with provenance.

Owner session. The step strip is the step selector with one form area (Q-12 decided). The chips read Version checkpoint saved and Draft auto-saved (OS-A21). Where the form shows hints, applicable accepted answers appear as labelled hints beside the control, with "Use accepted answer" per question and "Use all available accepted answers"; nothing is prefilled, and exposure and adoption are recorded (OS-A04; RS-R31 to RS-R38). Unsure is a third decision where the profile enables it (D4-01). A locked step says why and what unlocks it, without revealing other reviewers' decisions. Outdated answers may block Complete where the form chose that mode (D4-17). Generated session versions from a publication appear in history with their publication as cause (D2-01 as amended). The flow runs on phones, tablets and desktops with the same functions (D3-05).

7.2 Fix, Upgrade and Needs updating

Situation	What the reviewer sees	Action	Result
Publication chose requireReanswer	"Needs updating" chip on the session in My work and on the question in the form; blocks Complete	Answer; Complete	A new version pinned to the current form version
Publication chose doNothing; session pinned to an older version	Version badge "On form v1 (current is v3)" with "Update to v3"	Update to v3 (Upgrade, VA-10)	A current incomplete version with unchanged answers carried where compatible
A shared answer changed elsewhere (SF5)	"Outdated answers" warning on the session; Complete still counts (AC-R2d-05)	Fix	A current incomplete version opens; the outdated answers are marked
Fix on a session pinned to a Completed stage (LC1)	"This stage is complete. Your fix will wait for an administrator."	Request the change	A pending request in "changes awaiting approval"; the reviewer sees its state in My work

7.3 Reconciler end-to-end journey (UX-14)

Pool (KPI cards, Start reconciling, assigned-first then random eligible as the next-task rule, PROPOSAL) → task header (how assigned, "Reviewers blinded", editor claim held) → screening part first (RX1, R4p: decisions, reasons, must-agree answers) → matching (3a; drag with CDK pointer events plus a keyboard "Pair with…" path) → form part (4a: pills, agreement icon, autofill marker, "N to resolve", Complete anyway after the unseen-control warning) → Complete (gold snapshot) → next task (same rule) or back to pool.

• Narrow layout: below lt_md a candidate selector plus a single column; disagreeing candidates are never hidden by the selector; the side-by-side view is desktop-only.
• VS2 disclosure (U16): before accepted answers are shown to a candidate under VS1 on, a one-time interstitial: "You are about to view accepted answers for this study. Your contribution will be recorded as informed." [View accepted answers] [Not now]. Owner session (OS-A04): hints are shown by default from the form baseline, so the interstitial no longer gates viewing. The reviewer form labels each hint as an existing accepted answer, and "informed" is recorded when a hint renders in view and when it is adopted (RS-R34, RS-R35). Whether a one-time explanation of what "informed" means is still wanted is a design detail for U16.
• Release and reacquire (RA3, RA4): copy in the deck; an admin release keeps saved work.
• Validated as U36 (journey) with U1, U4, U16, U20 as its parts.
• Owner session (OS-A02, OS-A03, OS-A13, OS-A28, Q-11, Q-30). The task header's "Reviewers blinded" comes from the form's setting (annotation) or the profile's (screening), blinded by default. Candidates appear in a random order under context-local labels with no submission times or other chronology clues. A target-one form that requires human reconciliation shows a one-candidate layout: the single candidate's answers beside the reconciler's form, labelled so the result reads "Human reconciled". Screening ties and unresolved Unsure go to a separate adjudication step in the step selector, shown only to eligible adjudicators, with assignment to a member or a group and the individual resolver recorded. Bulk acceptance appears only where the form enables it. Unstarted-assignment expiry is optional and off by default.
• Ambiguity A2: reconciliation and design screens on phones (UX spec §12; no owner answer assumed). D3-05 requires screening and full annotation on phones. Options: (a) require phone acceptance for reconciliation too; (b) keep reconciliation's narrow layout usable with no feature removed, without a phone acceptance gate; © desktop only. Recommendation: (b) for reconciliation, with design and admin screens responsive but not phone-accepted at launch (PROPOSALs).

7.4 Admin publication as a staged flow (UX-10)

Replaces "one dialog combining five concerns" with a four-step flow on the impact scaffold:

1. Review changes: changed questions grouped by category (FEAT-003 categories, PH-18) with the system-suggested compatibility and the admin's confirmation (D2-02).
2. Impact summary: per prior version and per bound stage, the counts of completed, saved-incomplete and draft-only sessions, with freshness labels and the stale-evidence gate.
3. Choices with defaults: per changed question, requireReanswer, autoUpdate (within a compatible class only) or doNothing, with within-session conflicts resolved explicitly; a "what reviewers will see" preview renders the form with Needs updating markers for a sample session in each category.
4. Confirm: a dry-run summary table (sessions affected per choice, notices to be sent once per recipient, time estimate for phase 2); the preview digest is re-checked and the admin re-confirms if it changed (brief §1.1).

After confirm: a long-running operation row (phase 2 progress with a real numerator) and, where admission pauses (D2-10), the reviewer-facing pause copy. Prototyped on a realistic fixture (10 changed questions, 3 stages, 200 sessions across the three categories); comprehension criterion in AC-UX-02. Validated in U6 (revised).

Owner session. Step 1's "admin's confirmation (D2-02)" becomes the publisher's explicit compatibility and mapping declaration, immutable from commit; SyRF only suggests defaults (Q-34 decided; D2-02 decided-amended). A standard-target change is a publication with impact even without question changes (OS-A12). The impact summary names the attributable generated session versions the publication will write (D2-01 decided-amended). Step 4 uses the shared active-work impact preview (§7.14) and its recheck at commit. Profile publications follow the same flow with mismatch detection (Q-26 decided). Only one publication runs per form; collaborators see "Publishing by [name] since [time]. You can keep editing drafts." (§7.13).

7.5 Stage designer and step strip

The v10 r2 steps editor in a tabbed layout (U12): steps, dependency edges separate from display order, the effective-policy preview backed by the real admission service, cycle rejection, EW1, VS1, BL1 and lifecycle mode; versioned settings publish uses the same impact scaffold. The reviewer sees the result as the step strip (U7, Q-12).

Owner session (Q-15 replaced; Q-01, Q-02, Q-28; OS-A05, OS-A27). The designer gains a stage study filter editor: clauses on screening-profile outcomes and reconciled answers in AND/OR groups, which defines the stage's pool, with a feedback notice when a clause reads an activity bound in the same stage. No cross-stage route control exists. Steps keep in-stage dependencies, with progression after the reviewer's own Include by default and a stage setting that requires collective Include. Each step has exclusion-stop, and the stage shows "Finishing work already started" settings (saved work after exclusion; continuation after pool departure; placement is SP-AMB-01). A route capacity cap may be stricter than the form baseline. Optional reviewer-pool browsing is a stage setting (PROPOSAL). BL1 and VS1 leave the stage: blinding is on the form or profile, and the hint baseline is on the form with a step hide-only override. System adjudication and training steps appear as step kinds. The lifecycle follows Q-02: an automatic Completed stage recalculates when remaining work appears, and a manual one stays Completed until reopened.

7.6 Lifecycle approvals

Changes awaiting approval (R3c) appear in My work and the admin banner; the approve dialog (U10) shows the specific change, its effect on readiness and shared work, and "approved by you" or "decided by [alias]" once another admin acts (pending D3-23). Owner session: D3-23 is a brief item (resolved notices leave unread counts and stay in history, with the resolver reference shaped by disclosure). Under Q-02, approval is needed for protected changes acting on a Completed stage itself; new arrivals with remaining work recalculate an automatic Completed stage without a hold.

7.7 Guided setup with an interim checklist (UX-19)

R2a replaces the footer checklist's content with readiness-based tasks (profile, form, step, members) while keeping its placement and interaction (21 September decision). R3d's guided route (U11, prototyped in W1) is measured by AC-UX-07: a new admin reaches a screenable stage from templates in 20 minutes or less without help.

7.8 Exports and PRISMA

The export page gains a Current, Previous versions, As of date selector with manifest download and per-dataset coverage labels (U22); unmasking follows the disclosure contract (U26). PRISMA views under Data show the diagram, reported external counts marked as reported, coverage and lower bounds for adopted projects (U23). Owner session (RI spec §13): PRISMA views label imported references, source documents and Study items; show report identity, reason, retrieval and pool-tracking coverage and the machine-assisted share per phase; and present actual review through a stage as the reporting priority, with pool history as separate audit data (OS-A09). Stage flow views never label a departure as an exclusion unless it was a screening Exclude. Exports gain lane X1's comparison export, codebook and RIS, and the machine-source columns (D4-09, OS-A20).

7.9 Notifications versus work queues (NS-07, NS-10, NS-13)

My work is the source of truth; the inbox is delivery and history. The notification stack's inbox and preferences screens meet UI-1 to UI-11 before testers see them and the conversation, issue and PDF screens before production (pending D3-01), through a Material 3 inbox redesign PR before R2c (NS's evidence for the current inbox is in the stack worktree, CODE-PR, not re-read here). Flood controls before R2c: mark all read; project and kind filters; a context line from the resolver; "hide unavailable"; an unread count that excludes resolved items (D3-23); digests grouped by project and kind; jittered refetch with per-request authority memoisation; older publication notices for the same form marked superseded. Emails name the project only (pending D3-22). Owner session: "Emails name the project only" is superseded (D3-22 decided-amended through O2): emails and digests may include project and study context including study titles; aliases and other content follow recipient permission and blinding; answers and free text are configurable per project (off by default, PROPOSAL); rights are checked at delivery. A person can mute email per project while in-app notices continue (D3-24). Project settings gain a notification content screen for that policy. D3-01 and D3-23 are brief items. Notification delivery remains unauthorised (notifications integration §7).

7.10 Admission and pilot operations

The workflow version panel (§3.3) is the admit or remove screen; the read-only containment banner is what reviewers see after a rollback (U28, U32). Owner session: after trials and pilots, universal conversion waves reach every project with a notice period; findings and blockers appear in admins' My work, and a later in-engine wizard can redesign a converted project through versioned publication (OS-A14, OS-A15; BC spec).

7.11 Reviewer-pool browsing and Saved work (owner session, OS-A27, OS-A05)

When a stage enables browsing (PROPOSAL: a stage setting, off by default), a reviewer can list their own reviewer study pool: the Studies in the stage's current pool that are allocated or assigned to them and currently available. Each row shows bibliographic details (hidden where the profile blinds them), the reviewer's own status per step and availability ("Available", "Waiting for the team's screening result", "Enough reviewers", "Stopped by exclusion"). It never shows other reviewers' decisions, answers, identities or timing. The list is dynamic: a Study that becomes unavailable leaves it, and starting work re-checks admission. Browsing grants nothing. Started work that may continue after a Study left the pool appears in a separate Saved work list with its reason (SP spec §3.6, §3.9; UX spec §3.5).

7.12 Eligibility explanation (owner session, OS-A08)

An admin "Why?" panel, opened from a Study's history or a Monitor row, shows in time order the pool entries and departures with filter versions and clause results, review starts and submissions with the eligibility recorded at the time, configuration changes, the current reason category and any continuation after departure. Historical entries show the versions in force then. A Study that was eligible and not reviewed says "No review is recorded"; a tracking gap says "History before [date] was not tracked". Reviewers get "Why isn't this available to me?" with their own reasons only (UX spec §3.7; UX-R27 to UX-R29). On unconverted projects it explains current state only.

7.13 Presence on question-design pages (owner session, OS-A01)

Authorised users see who else is viewing and editing a design page, with names, avatars and a per-question editing marker. Accepted changes appear live in other views and never overwrite what a user is typing; when two people changed the same item, both versions stay visible and recoverable. Each accepted change shows its author and time in history; presence itself is not an audit record. Many drafts may be open, one publication runs per form (UX spec §3.8).

7.14 Active-work impact previews (owner session, consolidation §6)

One shared preview screen precedes every admin action that affects people working now: what changes; who is affected (counts for everyone, names only for Monitor holders, never across reconciliation blinding); what is kept; which temporary reservations would be released; dependent results whose inputs change; which notices will be sent. Actions are Cancel, Confirm and, only when the change conflicts with temporary reservations, Apply anyway, whose text names what it releases. Apply anyway never bypasses permissions, allocation constraints or invalid configuration. The impact is rechecked at commit; a changed impact shows the difference and asks again (UX spec §3.9; ACD spec §3.10). It builds on the impact flow scaffold of §4.3; the first consumer is R2c publication.

7.15 Duplicate merge and unmerge wizard (owner session, OS-A29)

The wizard previews the merge with active-work warnings, shows agreeing answers in resolution controls and conflicts side by side in a reconciliation-like view, lets the merging user resolve or delegate a conflict to the original reviewer as a task, asks the merger to confirm the resulting effective target, rechecks at commit and records the actual resolver. Unmerge is a new action with per-item carry-forward choices (to either restored Study, or left on the historical merged Study). Study-level bibliographic fields show their source or manual override (DM spec). Validated as U41.

7.16 Training (owner session, OS-A18)

A training step appears in the step selector where configured. The reviewer practises on reference Studies, submits an attempt and sees feedback as the policy allows; reference answers never appear before submission. Admins see an assessment queue, can pass or fail attempts with feedback, decide retries under the policy and see admissions to a group with the attempt, assessment and policy that caused them. Training works by keyboard, touch and screen reader on every device class (TI spec; TI-AE14, TI-AE15).

7.17 Access, catalogue and deletion screens (owner session; ACD spec)

• Contribution exclusion dialog (OS-A24): choose the form, profile, stage or project; give a reason; review the impact preview, including dependent results; resolve mixed route provenance explicitly; confirm. Reachable from the membership-disable workflow.
• Deleted projects view (OS-A25): a restricted list with deletion records and a restore action with reason and impact preview; restoration never revives stale reservations.
• Catalogue browser and request queue (D2-15): browse and copy catalogue item versions with provenance; request publication; catalogue administrators review requests.
• Notification content settings (D3-22): the project's content classes for emails and digests, narrowing what disclosure allows.
• Account deletion display: names of deleted accounts keep showing to authorised viewers, with an "(account deleted)" suffix (PROPOSAL); joining terms explain that contributions stay attributed (legal review before release).

8. Accessibility standard and harness

8.1 Standard

WCAG 2.2 AA is the working standard (PROPOSAL): it adds the criteria this programme needs anyway (focus not obscured, dragging-movement alternatives, minimum target size, consistent help). The GA audit is to WCAG 2.1 AA with an independent auditor (D4-18); 2.2-only criteria are reported separately.

8.2 Harness (E85, L17, W0 and S0)

Element	Implementation	Evidence
axe in journey specs	@axe-core/playwright added to e2e/; a per-route check with a committed baseline; journey specs call axe at named states (form open, failed Complete, conflict, dialog open)	zero serious or critical (AC-UX-09)
Screen-reader matrix	NVDA with Firefox and Chrome; VoiceOver with Safari (macOS); VoiceOver with iOS Safari for phone screening only and phone annotation (D3-05 decided-amended; UX-AE30); run at staging acceptance by a named person on the release's main tasks	checklist signed per release
Keyboard-only journeys	the release's main tasks completed by keyboard alone with visible focus; transcript attached	per release
Live regions	one polite region per page for save status, conflicts and status; one announcement per outcome; never per keystroke or per tab change; assertive never for autosave	pattern spec
Focus management	focus to the validation summary on a failed Complete; dialog trap and return; take-over moves focus to the banner; Jump focuses the control	pattern spec
Forced colours	Playwright forcedColors: 'active' screenshots on the five key surfaces; transparent outlines beside box-shadows (navigation plan decision 5)	tier-1 matrix
Reduced motion	every transition honours prefers-reduced-motion; static indeterminate tracks (Study Management D16)	guard in pattern specs
Zoom and reflow	200% zoom and 400% reflow at 320 CSS px with no page-level horizontal scroll; short-height layouts (1280×600) keep the action bar reachable	UI-6 matrix
Touch targets	44 px or more below 600 px (Study Management D17); 24 px minimum everywhere (WCAG 2.2)	tier-1 check
Contrast	pnpm run check:contrast in both layers; status never by colour alone	per PR

8.3 Browser and device matrix (PH-13, review AC-19, D3-15)

Browser	Coverage	Lane
Chromium (Desktop Chrome)	full E2E, perf, axe	existing projects
Firefox	smoke journeys: reviewer screening and annotation, reconciler task, publication flow, My work	new Playwright project on the smoke label
WebKit	the same smoke journeys plus phone screening at 390 px with touch; owner session: plus phone annotation at 390 px and tablet journeys at 768 px with touch (D3-05, D3-15)	new Playwright project
Touch (iPad, phone)	pointer-based CDK drag only; native HTML5 drag is banned in programme folders by a guard spec; the question-tree designer moves to CDK before R1a ships (question-node.component.html:12)	R1a precondition
Browser floor	commit a .browserslistrc, lower the TypeScript target and add the needed polyfills (the May analysis's BUILD.F1 to F3) before R1a	programme-integration item; recorded here as part of E85

Pending D3-15 for the Firefox, WebKit and touch acceptance rows. Owner session: D3-15 is Decided (Firefox, WebKit and touch coverage). Chromium keeps full end-to-end, performance and accessibility runs; Firefox and WebKit run smoke journeys; touch journeys run at 390 px and 768 px; real-device spot checks on iOS Safari and Android Chrome at staging acceptance are a PROPOSAL (UX-R44).

9. Research plan with real users

Study	When	Who	Method	Measures
Baseline of today's screening and annotation	W0, before the R2a build	6 to 8 reviewers across the reviewer and admin roles (panel per D1-06), at least two external SyRF users (D3-08) the agreed tester panel; no extra external recruitment now (D3-08 decided)	Moderated think-aloud on staging, production-equivalent configuration (AF2 off) and, as a second reference, AF2 and the redesigned shell on; realistic open-licence content	Time per title and abstract decision; time per 30-question form; actions per decision; confusion points; SUS; a review of support requests and the FAQ
Formative, per freeze gate	W0 to W3, one pack per gate (F1c: reviewer states, forms, history, export disclosure, My work, slots; F2: publication flow; F3: step strip, stage designer, route messages, Skip; F4: N-candidate workspace, matching, assignment, queries; F5: screening renderer, DP2 correction; F6: as-of export, PRISMA; F-C and F-O: cohort chip, schema authoring; R3d: guided setup)	5 or more per affected role, at least two external from the agreed tester panel (D3-08)	Prototype pack with handoff; tasks mirror the §5 explain questions	AC-UX-01, AC-UX-02 on the prototype; pass bars in §11
Summative, per release	Before each ship gate	The tier's panel (five for T1, three elsewhere, D1-06)	Staging with the seeded pilot projects plus one realistic-content project	AC-UX-01 to AC-UX-09
Pilot diaries	During each staging and production pilot	Pilot project members	A two-week diary (three questions a day) or weekly 20-minute interviews	Pain points to the backlog; PE evidence
Terminology card sort	W0	8 to 12 participants across roles	Closed card sort of the deck terms against meanings; "which version counts" vignettes	≥ 80% agreement per core term; U42
Instrumented timing on pilots	From R2a pilots, if D3-08 approves approved with consent (D3-08 decided)	Pilot projects, opt-in at admission; owner session: each user also consents and can withdraw (two-level consent, PROPOSAL)	Privacy-safe events: study opened to decision; form opened to Complete; actions per decision; no content, no identifiers beyond a per-project hash	AC-UX-03, AC-UX-04 at pilot scale

The tester panel (D1-06, named by Chris on 3 October 2026; register §1.14). T1 releases: Gillian Currie, Alexandra Bannach Brown, Francesca Tinsdeall, Chris Sena and Nadia Soleman. Other releases: Gillian Currie, Alexandra Bannach Brown and Francesca Tinsdeall. No external SyRF users are named yet; D1-06 asked for at least two "where possible", so the baseline and formative rows' external participants are still to be recruited (D3-08). Owner session (D3-08 decided through U3, 4 October 2026): the agreed panel is unchanged and no extra external recruitment is required now; "at least two external SyRF users where possible" no longer sets a requirement (UX-R24).

Owner-session requirements for the research plan.

• Device scope (D3-05). Formative and summative tasks include full annotation on a 390 px phone and a 768 px tablet, not only title and abstract screening. The largest project (2,023 questions; the figure is VB-12's and UNVERIFIED) is an acceptance case on every device class, never excluded for size (D2-16 replaced; UX-R07). Benchmark tier RV-DS-04 is its synthetic stand-in.
• Ambiguity A3: the largest project as test data (UX spec §12; no owner answer assumed). Options: (a) a synthetic replica at the RV-DS-04 shape; (b) a structure-only replica measured from the real project; © the real project. Recommendation: (a) now; (b) only after a separately approved read-only measurement that copies no study content or answers; never ©.
• Consent-based timing telemetry (D3-08). Timing events are recorded only when the project administrator enabled pilot timing at admission and the user consented; withdrawing stops new events at once. Events carry hashed keys, device class and form-size tier, never answer content, free text, titles, names or clear identifiers. They live in a separate store with time-limited retention, are reported only in aggregate with a minimum group size, and are never used to judge an individual (UX spec §3.6; the store, retention of the pilot plus 90 days, the group size of 3 and the pilotTimingTelemetry flag are PROPOSALs).
• Staging seeds (D3-14 decided). Missing staging seeds are added, existing staging data is preserved where possible, justified staging changes are allowed and production is never touched. Seeds this plan needs (PROPOSAL): a synthetic large-form project; a cross-project My work seed; an eligibility-history seed with a tracking gap, a departure and a continuation; a question-design seed with two administrators; and the existing legacy seed projects for the refresh checks.

Consent and data handling. A short consent text in the session invite and in the pilot admission step; session notes and derived metrics only; recordings optional, stored on CAMARADES storage and deleted after 90 days (PROPOSAL); sessions use the open-licence seed project, never a live review; no clinical, report or participant data in notes or events. LogRocket session recording and Google Analytics are not used for UX metrics; the LogRocket flag stays off for this purpose (UX-21).

Realistic content. L17 builds a "Realistic content (open licence)" seed project from openly licensed abstracts and full texts so that screening-speed findings transfer, alongside the seeded pilot projects in acceptance criteria §6.

10. UX metrics and acceptance

Thresholds are PROPOSAL until confirmed at the consuming freeze gate; telemetry rows apply only if D3-08 approves. PE-05 is redefined as AC-UX-01 and AC-UX-02 being met for every user-testing task of the release. Owner session: D3-08 approved telemetry with consent and without answer content, so the telemetry parts below apply to consenting pilot participants only. AC-UX-04 gains a phone-profile budget set at the R2a freeze from measurement (UX-AE06). AC-UX-06's "two-tab take-over" becomes recovery from a shared-session conflict across two tabs (D2-08), and its offline interval depends on ambiguity A1 (§6.4).

ID	Criterion	Verified by	Applies to
AC-UX-01	Task success: at least 80% of testers complete each release task in §5 of the acceptance criteria without help	UT	every user-facing release
AC-UX-02	Comprehension: at least 80% of testers answer each explain question correctly against its model answer (which version counts; why a study is offered or locked; what an accepted answer rests on; what a publication will do)	UT	R2a, R2c, R3a, R3b, R4a, R5a, R5b and every release with an explain task
AC-UX-03	Screening throughput: median time per title and abstract decision and median actions per decision on the realistic-content project are no worse than the baseline study; a keyboard-only path exists with at most two actions per decision beyond answering eligibility questions	UT, E (keyboard), telemetry if D3-08 with consent (D3-08 decided)	R3a, R3b, then every release touching the screening card
AC-UX-04	Annotation: time to complete the baseline 30-question form is at most the baseline plus 10%; keystroke-to-paint p95 under 50 ms with autosave on at 200 and 1,000 questions	UT, B	R2a, then every release touching the form
AC-UX-05	Reconciliation: median time per three-candidate study is at most 1.5× the two-candidate task on the same build	UT	R4a, R4p, R4c
AC-UX-06	Error recovery: every tester recovers from a two-tab take-over, a stale base and a 60-second offline interval without losing an edit made before the event	UT, E (network throttling)	R2a, R4a
AC-UX-07	Setup: a new administrator reaches a screenable stage from templates in 20 minutes or less without help	UT	R3d
AC-UX-08	Satisfaction: SEQ at least 5.5 per task, or SUS at least 70 per role per release	UT	every user-facing release
AC-UX-09	Accessibility: zero serious or critical axe findings on the release's routes; the main tasks complete by keyboard alone; the screen-reader checklist passes; forced colours and 400% reflow pass on the five key surfaces	A, E	every release

11. U-validation schedule

Rule: every U runs in a window at least one before the build that consumes it, and the consuming freeze gate's exit evidence lists it as passed. "Passed" means: the U's tasks meet AC-UX-01, its explain questions meet AC-UX-02, no unresolved severity-1 usability finding (lost work, a wrong decision, a disclosure), the keyboard path and screen-reader meaning are present on the prototype, and every string comes from the deck. Per-U specifics follow. One documented exception: R1a and R1b build in W0 (plan §7) and nothing is prototyped before G0, so U19 and U8's visibility part run first in W0 and the R1a and R1b UI slices build after they pass, within the same window; their later parts (U8 dialog and delegation) keep the one-window rule.

U	Window	Consuming build (window)	Gate exit	Tasks and explain questions	Pass bar specifics
U1	W0 prototype; W2 validation	R4a (W3)	F4	Reconcile a study with three and four candidates; explain why a candidate is hidden or not	AC-UX-05; no disagreeing candidate hidden in any test
U2	W1	R3a (W2)	F3	Skip a step; explain what was recorded	100% say "nothing"
U3	W0	C1 (W1)	F-C	Select cohorts without losing place	AC-UX-01
U4	W1	R2d (W2), R4a (W3)	F2 (Fix part), F4	Fix an outdated session; see the unseen-control warning and Complete anyway	AC-UX-01; warning list with jump links used by ≥ 80%
U5	W1	R2c, R3a (W2)	F2, F3	Wait through a publication pause; read a route-change message	no tester infers another reviewer's vote
U6 (revised)	W1	R2c (W2)	F2	Predict a publication's effect on each session category from the staged flow. Owner session: include a target-only publication, generated session versions and an impact that changes before commit (recheck)	AC-UX-02 per category
U7	W1	R3a (W2)	F3	Use the step strip versus card-per-step. Owner session: Q-12 decided the step selector with one form area; U7 now checks its layout before the freeze (UX-R03), including the narrow menu and the adjudication and training step kinds	preference and AC-UX-03
U8	W0 (visibility), W1 (dialog), W2 (delegation)	R1b (W0), R1c, R1d (floating)	R1b, R1c, R1d	Say who can do what and why	AC-UX-02
U9	W0 (ordinary), W2 (profile)	R2a (W1), R3b (W3)	F1c, F5	Edit a question and a profile question; explain ownership. Owner session: two administrators edit the same design page and resolve a same-item conflict (OS-A01; UX-AE20, UX-AE21)	no ownership confusion
U10	W1	R3c (W2)	F3	Approve a change to a Completed stage, predicting its effect	AC-UX-02
U11	W1	R3d (W4)	R3d	Set up from templates; resume a saved setup	AC-UX-07
U12	W1	R3a (W2)	F3	Build a dependency graph; read the effective-policy preview. Owner session: also author a stage study filter and explain why a Study is in or out of the pool (Q-15 replaced)	cycle refused; preview matches admission
U13	W0	R2a (W1)	F1c	Edit, save and complete; say which version counts. Owner session: read Draft auto-saved, Version checkpoint saved and Complete, and the confirmation before an incomplete Save replaces a completed version (OS-A21; UX-AE07, UX-AE08)	AC-UX-02 ("which version counts")
U14	W0	R2a (W1)	F1c	Compose a form; bind it. Owner session: set the standard target (a publication) and the form's reconciliation, hint, capacity, timeout and limit settings	AC-UX-01
U15	W0	R2a (W1)	F1c	Read history; find a kept copy	AC-UX-01
U16	W2	R4a (W3)	F4	View accepted answers after the VS2 disclosure; explain "informed". Owner session: use labelled hints and click-to-fill; explain what adopting a hint records (OS-A04)	AC-UX-02
U17	W2	R3b (W3)	F5	Screen with eligibility questions; explain what the decision rests on; keyboard path under DP3. Owner session: include Unsure and explain what happens next under the profile's tie policy (D4-01, OS-A16)	AC-UX-02, AC-UX-03
U18	W2	R3b (W3)	F5	Correct an own Exclude from history	AC-UX-01
U19	W0	R1a (W0)	R1a	Browse and import templates	AC-UX-01
U20	W2	R4a (W3)	F4	Assignment, expiry, release, request an additional review; next-task rule. Owner session: expiry is optional and off by default (Q-30); the request raises the effective target and may name people or groups	AC-UX-01
U21	W2	R4b (W3)	F4	Raise a query; find its outcome	AC-UX-01
U22	W3	R5a (W4)	F6a	Download an as-of export; explain coverage labels	AC-UX-02
U23	W3	R5b (W5)	F6b	Read the PRISMA diagram with reported counts	AC-UX-02
U24	W0	O1 (W1)	F-O	Create an outcome measure; choose a schema	AC-UX-01
U25	one window before each release's kinds	per release	per release	Open an inbox item to its task; see "Related item unavailable"	deep link honours task identity and aliases
U26	W0	R2a (W1)	F1c	Export with and without unmasking; explain who may unmask	AC-UX-02
U27	W0 (navigation), W3 (both project kinds)	R2a (W1), GA	F1c, GA	Switch between a classic and a versioned project; explain the badge. Owner session: coexistence is temporary (universal conversion, OS-A15)	AC-UX-02
U28	W0	R2a (W1)	F1c	Read the read-only banner; find kept work	AC-UX-01
U29	W3	R5c (W4)	R5c	Explain independent versus informed figures	AC-UX-02
U30 (new)	W1	R3c (W2), R4a (W3)	F3	From the project index, reach an assignment in an unopened project in one step; as an admin, see a pending request without opening the project; use the four queue filters. Owner session: D3-07 decided; also with the project's email muted (D3-24; UX-AE12 to UX-AE14)	AC-UX-01; with every notification flag off
U31 (new)	W0	R2a (W1)	F1c	Work through Saving, Kept, Retrying, Offline, Failed; take over from a second tab; recover a stale base. Owner session: states renamed (Draft auto-saved, Version checkpoint saved); the second tab edits the shared session and resolves a conflict (D2-08); the offline part depends on ambiguity A1	AC-UX-06
U32 (new)	W0	R0 (W1 deploy), R2a (W1)	F1c	Read the workflow version badge and panel; admit a project; read the containment banner	AC-UX-02
U33 (new)	W1	R3a (W2), R3b (W3)	F3, F5	Screen 20 studies by keyboard on a desktop and 20 on a 390px phone with the keyboard hidden; DP3 and DP5 variants. Owner session: add full annotation of the RV-DS-04-shaped form on a 390 px phone and a 768 px tablet with touch, including a failed Complete and Jump (D3-05; UX-AE03)	AC-UX-03; ≤ 2 actions per decision
U34 (new)	W0	R2a (W1), R3a (W2)	F1c, F3	Use "N required missing · Jump" and Unanswered only on a 200-question form	AC-UX-04; every jump lands on the control
U35 (new)	W0 (panel), W1 (tour)	R2a (W1), R3a (W2)	F1c, F3	Read the "What changed" panel; dismiss it; replay the tour; open a help link	AC-UX-01; help link opens the right guide anchor
U36 (new)	W2	R4a (W3)	F4	The reconciler journey end to end at 1440px and 925px and in the narrow layout. Owner session: blinded candidates in random order, the one-candidate layout and a screening adjudication task (OS-A02, OS-A28, OS-A13)	AC-UX-05; no disagreeing candidate hidden
U37 (new)	W1	R2c (W2)	F2	Use the redesigned inbox and preferences; mark all read; filter; see "resolved". Owner session: mute one project's email and set the project's notification content (D3-22, D3-24)	AC-UX-01; UI-1 to UI-11 pass on the stack's screens
U38 (new)	W0	R2b (W1), R3a (W2)	F1c, F3	Read slot and presence states; a released slot with and without the cap; an Include refused for a dependent step. Owner session: form-owned timeout and cap (D2-07, D3-17); Saved work after a departure (OS-A05)	AC-UX-02; no tester reads a name they should not
U39 (new)	W0	R2a (W1)	F1c	Follow the readiness-based checklist to a screenable stage on the interim route	AC-UX-07 on the interim route (PROPOSAL 30 minutes)
U40 (new)	W1	R2c (W2), P2 (W3), R5a (W4), O2	F2, P2	Watch a publication phase 2, an ASySD run and an as-of export in Processing; explain the status	job language honoured; no fabricated progress
U41 (new)	W2	P2 (W3)	P2	Resolve a duplicate pair; merge and split; explain where the secondary's reviews went. Owner session: D2-12 replaced: merge into one consolidated Study with conflict resolution or delegation, then unmerge with carry-forward choices (OS-A29)	AC-UX-02 (pending D2-12 D2-12 replaced)
U42 (new)	W0	F1c copy deck	F1c	Terminology card sort and "which version counts" vignettes	≥ 80% agreement per core term
U43 (new)	W0, then per new pattern	the first consumer of each pattern	F1c and each gate	Pattern gallery review: every pattern's states, keyboard model, narrow behaviour and copy keys	Chris's per-PR acceptance (D3-02); axe clean
U44 (new)	W2	R3b (W3)	F5	Screen with bibliographic details hidden (SR-25)	AC-UX-03 unchanged; provenance records hidden metadata
U45 (new)	W3	GA	GA	A tester holding both project kinds walks the restyled legacy chrome and shared pages. Owner session: includes the compatible features in the compatibility register (OS-A23)	no behaviour workflow-semantics change; AC-UX-02 on the badge

Validation needs added by the owner session (5 October 2026). This page mints no U IDs; the owner of open questions §3 assigns them. Each follows the one-window rule above. Evidence IDs are the UX spec's unless stated.

Need	Consuming build	Tasks and explain questions	Evidence
Eligibility explanation	SP history release (timeline behind its UI flag)	As an admin, explain why a Study was reviewed in a stage it no longer matches, and why another was never reviewed; as a reviewer, explain why a Study is not available	UX-AE18, UX-AE19
Reviewer-pool browsing and Saved work	R3c (opt-in per stage)	Find a Study in the browse list, explain why one is unavailable, finish started work from Saved work	SP spec §11
Active-work impact preview	R2c (first consumer)	Predict what a capacity reduction does to people working now; use Apply anyway; respond to a changed impact	UX-AE22 to UX-AE24
Training setup and attempt	Lane TR1	A designer sets up a training step with references, policy and admission; a trainee fails, retries and passes	TI-AE14, TI-AE15
Contribution exclusion and project deletion	Per ACD spec §10	Exclude a member's work from one form and predict the effect; delete and restore a project	ACD-AE05 to ACD-AE16, ACD-AE28
Consent for pilot timing	R2a pilots	Read the consent card; decline; withdraw later	UX-AE16, UX-AE17

12. Change management

• Three reviewer-visible bundles (PROPOSAL): (1) "Versioned reviews" with R2a, R2b and R2c's reviewer-facing parts (kept changes, Save progress and Complete versions, history, Needs updating); (2) "Steps and screening" with R3a and R3b (step strip, screening renderer, derived decisions, reasons, keyboard path, My work badge from R3c); (3) "Workspace additions" with R2d, C1 and O1 (Fix, population chip, outcome schema entry) and R4a's VS1 display. Reconcilers get one bundle (R4a, R4p, R4b). Admin configuration changes are not bundled but get the panel. Anything reviewer-visible outside its bundle ships dark until the bundle's enablement. Owner session: bundle 1 shows Draft auto-saved, Version checkpoint saved and Complete (OS-A21); bundle 2 carries the step selector and, where profiles enable them, Unsure and the adjudication step; bundle 3's "VS1 display" becomes reconciled-answer hints with click-to-fill (OS-A04). Phone and tablet layouts ship with each bundle, not later (D3-05).
• "What changed" panel from R2a (AC-ALL-06 extended): keyed by bundle, per-user dismissal stored with the review preferences, read at page load (no notification dependency), each item linking to the user guide page drafted under its target marker (brief §1.15).
• Anchored tour component built once at R3a (spotlight, popover, pause and resume as in Review Prototype v4) and reused by every later bundle; not shown below lt_sm.
• Contextual help on every new screen through the existing userGuideUrl pipe, enforced by no-hardcoded-help-urls.spec.ts; help links are placed consistently (WCAG 2.2 consistent help).
• User-guide parity: pages drafted under target markers and published at enablement; the glossary parity check (§5.1) runs in docs CI.

13. Design QA process

13.1 Tier 1, per PR, agent-run (D3-02)

Check	Tool or evidence
Theme guards	pnpm run check:theme-migration, pnpm run check:contrast, syrf-theme.spec.ts, the UI-10 guard spec
Screenshot matrix	light theme at the UI-6 widths (320, 390, 599, 600, 768, 904, 905, 925, 1239, 1240, 1439, 1440; 200% zoom; 400% reflow; short height), named states per pattern; dark via token checks per PR
axe	per-route and journey-state results, zero serious or critical
Keyboard journey transcript	the PR's main task by keyboard, with focus order
State coverage list	every state in the pattern spec shown
Copy-deck compliance	the guard spec plus a manual read of new strings
Design-QA checklist against the handoff	DONE, PARTIAL, NOT DONE with file:line; deviations with reasons
Second agent review	a fresh-context agent compares the evidence with the handoff and the pattern inventory

13.2 Tier 2, Chris, per release

Chris accepts the release's bundle of screens on staging (dark mode through themeToggle, which is on there) with the tier-1 evidence, plus spot checks on previews. Per-PR acceptance is limited to new shared patterns (U43) and five high-risk surfaces: the publication flow, the reconciliation workspace, the stage designer, Members & groups and guided setup (D3-02). Assumption A-24 is rewritten accordingly (open questions §4). Owner session: D3-02 is a brief item (T-UX-00): each release brief carries one integrated staging design review, previews for new shared patterns and high-risk screens, and routine checks per PR (UX-R42). Proposed additions to the high-risk list (PROPOSAL): the merge and unmerge wizard, import acceptance, the eligibility explanation, large-form annotation on phones and the active-work impact preview.

13.3 Materially changed

A screen is materially changed when any of these holds: a new route; a new or changed shared pattern; a changed primary action or its placement; changed copy for a core verb; a changed layout at any UI-6 width; a changed keyboard model or focus order. Colour-role swaps and copy fixes within the deck are not material.

14. Material 3 sequencing and dark mode (D3-01)

• Now: M3 roles over the current components (no component-generation islands), every new route registered in FEAT-023's route inventory and baselines (UI-9), the UI-10 literal guard, and check:theme-migration on every PR. UI-3 is rewritten so it is checked statically (review AC-17): roles and public APIs only, no M3 component islands, registered routes. Pending D3-01 the FEAT-023 light cutover is sequenced before R2a's reviewer UI where possible (join X-M3), otherwise before GA; new screens are verified on the path the preview renders plus the static checks (A-37).
• Dark mode: evidence per PR is the token-contrast contract in both layers; evidence per release is a dark screenshot set on staging with themeToggle on; full dark screenshot sets per PR start only when FEAT-023 activates dark mode (Wave 6). V2-22's UI1 reading (production users see M3 roles on M2 components until the cutover) is put to Chris in D3-01.
• Notification stack screens: inbox and preferences meet UI-1 to UI-11 before testers see them; conversation, issue and PDF screens before production (NS-10, D3-01).
• Legacy restyle: chrome and shared pages under D3-06, verified by U45. Owner session: D3-06 is decided-amended; the restyle carries every compatible new feature (§3.4, OS-A23).
• Owner session: D3-01 is a brief item (T-UX-00): coordinate Material 3 roles and themes, staging dark-mode checks and visual baselines with the Material 3 programme, and record the cutover sequencing for the reviewer UI in the brief (UX-R41). The "Pending D3-01" markers above read as this brief treatment.

15. Decisions needed, engineering items, validations and assumptions

15.1 Batch D decisions this strategy rests on

D1-06 (tester panel; decided 3 October and named that night, with no external SyRF users yet), D2-07 (slot held by a draft), D2-08 (two-tab take-over), D2-10 (scoped pauses copy), D2-12 (alias presentation), D3-01 (UI1 before cutover; stack screens), D3-02 (acceptance cadence), D3-03 (copy deck terms, including the workflow names and Q-D4/Q-D5), D3-04 (button and type language), D3-05 (phone screening), D3-06 (legacy restyle), D3-07 (My work), D3-08 (participants and telemetry), D3-15 (browsers and touch), D3-17 (capacity cap copy), D3-19 (dependent-step claim), D3-20 (presence disclosure), D3-22 (email content), D3-23 (resolved notices), D4-01 (Unsure key), D4-13 (primary reason order in the reason picker), D4-18 (WCAG audit; answered 3 October, with the audit kept under the recorded reading Chris confirms in the G0 dossier), D4-19 (blinding and random serving as core behaviours).

Status after the owner session (5 October 2026). The list above is history.

ID	Status	Note
D1-06	Decided (3 October)	Panel unchanged; no extra external recruitment (D3-08)
D2-07	Decided	Form-owned inactivity timeout and in-progress limit; expiry keeps the draft
D2-08	Decided	One shared session and place across tabs and devices; take-over UX is a brief detail
D2-10	Brief item	Tested publication active-work protection; measured pause and operation limits (proposed, not approved)
D2-12	Replaced	Consolidated Study with reversible unmerge
D3-01	Brief item	§14
D3-02	Brief item	§13.2
D3-03	Decided-amended	Illustrative draft and checkpoint labels (OS-A21); workflow names stay PROPOSAL
D3-04	Decided	Sentence case
D3-05	Decided-amended	Full annotation on phones, tablets and desktops at launch
D3-06	Decided-amended	Compatible features on legacy screens (OS-A23)
D3-07	Decided	My work, cross-project tab, global badge
D3-08	Decided	Agreed panel; consent-based telemetry
D3-15	Decided	Firefox, WebKit and touch
D3-17	Brief item (carry-forward alignment)	Capacity cap separate from target; defaults proposed
D3-19	Brief item	Dependent claim at personal Include
D3-20	Brief item	Counts; names for Monitor holders; never across blinding
D3-22	Decided-amended	Informative, permission-aware email
D3-23	Brief item	Resolved notices with history
D4-01	Decided (with OS-A16)	Unsure key where enabled
D4-13	Decided-amended	Primary reason is guidance
D4-18	Answered 3 October	Reading awaits G0-D1
D4-19	Decided-amended	Blinded by default; optional browsing

15.2 Engineering items E82 to E87

ID	Item	Lane	Gate
E82	Save-status state machine, bounded local copy (IndexedDB) with sequence replay, conflict and take-over screens, typed-outcome recovery copy; lease by stable client tab ID with REST heartbeat; works with tracking off. Owner session: states renamed (OS-A21); the local copy waits on ambiguity A1; take-over is superseded by the shared session (D2-08), and the stable tab ID identifies connections	L5 with L1	F1c (copy), R2a
E83	Copy deck mechanism: deck document, typed message constants per feature, shared core-terms file, banned-string and import guard spec, user-guide glossary parity script in docs CI	L16	F1c
E84	Pattern inventory as shared components, spec gallery route behind a flag, handoff template, "What changed" panel with per-user dismissal, anchored tour component, contextual help on every new screen	L16 with L5	F1c, R2a (panel), R3a (tour)
E85	Accessibility and browser harness: @axe-core/playwright with baselines and journey-state checks, screenshot matrix at the UI-6 widths, forced-colours and reduced-motion runs, Firefox and WebKit smoke projects, native-drag guard spec, CDK drag for the question tree before R1a, browser floor (.browserslistrc, target, polyfills)	L17	W0 and S0; R1a precondition
E86	My work: read-time counts endpoint over the four queues and admission-based work, project-level surface, global badge, cross-project tab, admin LC1 banner, deep links by task identity and alias; workflow version badge and panel, admission action, containment banner, legacy explainer	L16 with L6, L4, L0	R0 (panel), R3c, R4a
E87	Reviewer efficiency: keyboard screening path reconciled with DP3 and DP5, live completeness and jump on every host, input-latency budget under autosave, privacy-safe timing events (subject to D3-08) and the baseline measurement protocol. Owner session: telemetry approved with consent (D3-08); phone-profile latency budget (UX-AE06); whole-form validation independent of mounted rows (UX-R06)	L5 with L3 and L17	R2a (count, latency), R3a, R3b (keys)

15.3 UI validations U30 to U45

Listed with windows and pass bars in §11; the open-questions rows are in open questions §3.

15.4 Assumptions

ID	Assumption	Basis	Cost if wrong
A-37	FEAT-023's light cutover does not land before R2a's reviewer UI; new screens are built on M3 roles over the current components and verified on the Material 2 bridge plus the static checks (UI-3, UI-9, UI-10)	FEAT-023 README (Waves 0 to 4 open; Wave 5 unscheduled); D3-01 pending	If the cutover lands earlier, the screenshot matrix is re-run on the M3 path at cutover; no plan change
A-38	The tester panel (D1-06) and at least two external SyRF users are is available for the W0 baseline study and monthly sessions. Owner session: external participants are not required (D3-08 decided)	D1-06 (approved 3 October; named that night, with no external SyRF users yet, §9) and the D3-08 recommendation D3-08 as decided	AC-UX-03 and AC-UX-04 are re-based on R2a's first summative session, which doubles as the baseline; the thresholds stay PROPOSAL until then

16. PWA exploration beyond the MVP (owner session, 5 October 2026)

Decision (U2 exploration and scope clarification, OS-A22). Making SyRF a Progressive Web App is a feasibility exploration beyond the MVP, including whether allocated studies could be cached. It is not an approved PWA implementation, an offline review requirement or a launch commitment. Full phone, tablet and desktop annotation stays a launch requirement (D3-05). No offline writes are authorised, and protected study data is never cached as an accidental default (UX-R38 to UX-R40).

Repository finding (UX spec §3.11; re-checked read-only on 5 October 2026, source-status inventory §1 item 27):

Item	Observed
src/services/web/src/site.webmanifest	Present; name and short_name empty; display: standalone; white theme and background; icons at /android-chrome-192x192.png and /android-chrome-512x512.png
Icon files	At src/assets/img/android-chrome-192x192.png and -512x512.png, so the manifest's root paths do not match where the build copies them
src/services/web/angular.json assets	src/favicon.ico, src/assets and library globs; the manifest is not listed, so it is probably not copied into the build
src/services/web/src/index.html	theme-color, viewport and apple-mobile-web-app-* tags; no <link rel="manifest">
Service worker	No @angular/service-worker dependency, no ngsw-config.json, no service-worker reference in the web source

The app is therefore very likely not installable as a PWA today. Nothing was built or run, so this stays UNVERIFIED. Existing metadata is not evidence of PWA readiness.

What the exploration must answer. Installability and standalone behaviour per browser (including iOS Safari's limits); update and caching behaviour, including service-worker version skew against the forced-reload contract (AC-T-04); authentication, token handling and cache clearing at logout or access removal; draft persistence and connectivity handling (ambiguity A1, §6.4); whether and how allocated studies could be cached (which data, protection at rest, eviction, revocation when access is removed, and blinding); and what a real offline review mode would need (version checks, publication rules, authorisation revalidation, conflicts).

Output. A feasibility report and a proposed scope for an owner decision (UX-AE25). No implementation, no feature flag, no protected-data caching by default and no offline writes. The exploration is PWA1 in the rollout plan, a non-MVP exploration timed so it never delays MVP work.

Resolution record

Finding	Category	Where	Note
UX-01	Adopted	§9, §10; acceptance criteria §2.3 and §5	Research plan with baseline, formative, summative, diaries, card sort; AC-UX-01..09 carry the metrics and PE-05 is redefined through AC-UX-01 and 02; participants pending D1-06 (shape approved 3 October; names needed for G0) and D3-08, telemetry pending D3-08. Update: the panel was named late on 3 October (§9); external participants remain pending D3-08
UX-02	Adopted	§6.1 to §6.3, §10, E87; integrated plan R3a/R3b	Keyboard path and live completeness moved into R3a/R3b scope; AC-UX-03/04; AF2 parity exit set named in programme-integration (other drafter)
UX-03	Corrected	§11; integrated plan §6.1 and §7	Every U placed one window before its build; gate exit evidence lists U's
UX-04	Adopted	§6.4, §6.5, E82, U31	State machine, local copy, conflict screens; QM v2 §14 harvested; drafts model per brief §1.8
UX-05	Adopted	§5, E83, U42; contracts C17	Copy deck at F1c with typed constants, guard spec and glossary parity; terms pending D3-03
UX-06	Adopted	§8.2, E85	Accessibility harness in W0; screen-reader matrix; checklist per release
UX-07	Adopted	§4, U43, E84	Design system of record, pattern inventory, handoff template; button and type language pending D3-04
UX-08	Adopted	§3.1, E86, U30	Project-level My work in R3c/R4a plus NS-07's badge, tab and banner; global landing post-GA; pending D3-07
UX-09	Adopted	§12	Three bundles; "What changed" panel from R2a (AC-ALL-06 extended); tour at R3a; help links
UX-10	Adopted	§7.4, U6 revised	Staged flow with preview and dry-run; comprehension in AC-UX-02
UX-11	Adopted	§3.3, §3.4, U32, U45	Shared chrome, workflow version badge, explainer; legacy restyle pending D3-06
UX-12	Question	§14, A-37	D3-01; dark evidence by token checks plus staging themeToggle
UX-13	Adopted	§13	Two-tier design QA; "materially changed" defined; cadence pending D3-02
UX-14	Adopted	§7.3, U36, U16 wording	Journey map, narrow layout, VS2 disclosure copy, next-task rule as PROPOSAL
UX-15	Corrected	§8.2; acceptance criteria UI-6	Widths from break-points.ts edges plus 320, 390, 925; touch targets; phone screening pending D3-05
UX-16	Adopted	§4.3, U40; acceptance criteria UI-2	Shells and StatusView mandatory; long-running operations mapped to the job language
UX-17	Adopted	§5.5, U31	Error and recovery copy per typed outcome; AC-UX-06
UX-18	Adopted	§3.3, U32	Workflow version panel and containment banner
UX-19	Adopted	§7.7, U39, U11 moved to W1	Interim checklist at R2a; AC-UX-07
UX-20	Adopted	acceptance criteria UI-2	No debug components on reviewer-reachable routes unless the debug flag is on; review-completed page in R2b's revision
UX-21	Question	§9	D3-08; LogRocket and GA never used for UX metrics
UX-22	Adopted	§5.3	Reviewer progress vocabulary in the deck and R2b's progress-list revision
UX §3 strategy	Adopted	§3 to §13	Incorporated with the amendments above
UX §4 Q1 to Q9	Question	§15.1	Q1 D3-01; Q2 resolved by the staging themeToggle evidence rule (§14); Q3 D3-04; Q4 D3-03; Q5 D3-08; Q6 D3-05; Q7 D3-06; Q8 D3-07; Q9 D3-02
PH-13	Adopted	§8.3, E85	Browser and device matrix; CDK drag for the question tree and the browser floor as R1a preconditions
PH-19	Adopted	§5.2	Four-state vocabulary and "Save progress" reused; a distinct term per kind of draft
PH-35	Adopted	§6.1, U17, U33	One-key decisions reconciled with DP3 and DP5
review AC-17	Corrected	§14; acceptance criteria UI-3, UI-9	UI-3 statically checkable; routes registered; D3-01
review AC-19	Adopted	§8; acceptance criteria AC-ALL-07	Live regions, focus, forced colours, 400% reflow, short height, touch targets, screen-reader matrix, Firefox and WebKit; one width list
review AC-27	Adopted	acceptance criteria UI-10	Literal-colour guard spec over programme folders (no stylelint exists)
review AC-28	Adopted	§4.3, §13.3; acceptance criteria UI-2, UI-5, UI-8	Pattern checklist, handoff linked, "materially changed" defined
review AC-29	Adopted	§11; acceptance criteria §5.3 and §5.4	Tasks for every release, explain rubric, pass bar per U
SR-25	Adopted	§4.3, U44	Bibliographic blinding placeholder as a per-profile option, PROPOSAL, default off; provenance records it
DD-11 (glossary)	Adopted	§5.2	User-facing terms aligned with the DD glossary; internal names unchanged
Q-D4, Q-D5	Question	§5.2	Covered by D3-03 ("Accepted answers (gold standard)", "Screening result")
V2-22	Corrected	acceptance criteria UI-6, UI-8; §14	925px added; A-24 cited and rewritten; UI1 reading put to Chris in D3-01
V2-25	Corrected	acceptance criteria §5.3	Tasks for R2b, R2d, R3c, R4b, R4p, R5c, P1, P2 and C2; O2's operations are covered by U40
RT-10	Adopted	§6.5, E82	Lease by stable tab ID, take-over UI, works untracked; D2-08
RT-14	Adopted	§5.4, §4.3 (presence chip)	Counts and own place only; names with the Monitor capability; D3-20
RT-22	Adopted	§5.4	Slot vocabulary and the D2-07 rule copy in the deck; slot states in U38 (extends U13)
Q-RT6, Q-RT7	Question	§5.4, §6.5	D3-20, D2-08
NS-07	Adopted	§3.1, E86, U30	Flag-independent badge, cross-project tab and admin banner merged with UX-08
NS-10	Adopted	§7.9, §14, U37	Stack screens meet UI1 before testers; M3 inbox redesign before R2c; timing D3-01
NS-13	Adopted	§7.9, U37	Flood controls before R2c; resolved items per D3-23
Q-N3, Q-N5	Question	§7.6, §7.9	D3-23, D3-01

Owner session, 5 October 2026: the "pending D3-0x" notes in this record are history. Current statuses are in §1.1 and §15.1; the round-2 categories stand.