Skip to content

Temporary planning review record. The report below is reproduced verbatim as returned by the independent read-only reviewer (Plan agent, Opus model, launched 3 October 2026 about 04:05 BST). Only this front matter and note were added. Resolutions are in the resolution matrix.

Review C: UI, workflow, permissions and programme integration

Reviewer: independent adversarial reviewer C, read-only, 2026-10-03.

Path legend (all absolute): - PKG = /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/ - PLAN = /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/ - MAIN = /home/chris/workspace/syrf/main/. Its HEAD is now 9d74077d8, because #3948 merged after the package's 78c6d097d baseline. The only web change since then is the generated API client and swagger, so every web line cited below is the same at the baseline. - WEB = MAIN/src/services/web/src/app/ - API = MAIN/src/services/api/SyRF.API.Endpoint/ - PR3944 = /home/chris/workspace/syrf/pr/pr3944.selected-reviewer-reconciliation-questions-yo2tmi/ - PR3947 = /home/chris/workspace/syrf/pr/pr3947.checked-pdf-proposals-and-explicit-administrator-a-r6bdl2/ - PR2621 = /home/chris/workspace/syrf/pr/pr2621.screening-profile-versioning-rationale/docs/features/landing-page/ - V10 = /home/chris/.codex/visualizations/2026/09/23/01a0cbec-0c32-7103-ab5a-bfc05665deb7/syrf-v10-review-2026-10-02/source/design_handoff_syrf_v10/ - AUTHZ = /home/chris/workspace/syrf/handover/2026-09-08-authorization-3335/

PR states were re-read live with read-only gh during this review.

Verdict

Not approvable for G0 in this dimension yet: two blockers and seventeen major findings.

The overall direction is sound and mostly well evidenced: contracts first, existing programmes keep ownership, notifications reuse the inbox stack, and multi-candidate reconciliation is validated before G5. Most current-implementation claims I spot-checked are accurate.

Five things undermine the plan as written:

  • R1 depends on gates the plan doesn't contain. It is sold as "G0 only" early value, but its group work depends on two authorization-programme gates that appear nowhere in the plan, and it reproduces another programme's work package.
  • The gates contradict the parallel windows. The gate table requires each release to be piloted before the next one starts, while the windows build them in parallel. Taken literally, the critical path is fully serial.
  • The #3944 recommendation (Q-10) is incomplete. It doesn't preserve reviewer independence, and it ignores that #3944 shares a flag with, and sits under, two unrelated stacked PRs.
  • The UI coverage comparison misses existing assets. It omits three #2621 prototypes and wrongly declares two gaps "uncovered".
  • Release value and pilots are overstated. Several confirmed decisions (QY6, LC1) are undermined by the "ship without notifications" fallback, and production pilots depend on several environment-wide flags, not only AF2.

Findings

ID Severity Location Finding Evidence Recommended resolution
C-01 Blocker PKG/integrated-plan.md §1 table l.46; §5 R1 l.203–224; §6 graph l.448 and gate table l.479–491; §7 l.500–501; §10 l.575. PKG/open-questions-and-assumptions.md A-17 l.130, Q-03 l.38, Q-09 l.30. PKG/contracts.md l.305 R1 is presented as "G0 only" early value, but its group management (R1(b)) depends on external gates that are not in §6 or the graph. (1) Gate G-D is the membership schema-1 migration applied and verified in production. That needs a formal Mongo migration runner (WP-M1) that doesn't exist, followed by WP-M2. (2) The "single ProjectAuthorityEvaluator, no second evaluator" rule only holds in enforced mode. Off and shadow modes make the byte-for-byte legacy decision, and enforcement is off everywhere until the authority programme's M6 cutover. The package's own C10 says the evaluator is "dark, enforced mode only". (3) Group create/edit authority under EditMemberships belongs to Q-03, which is in Batch B, not Batch A. R1(b) also takes over another programme's work. It is almost exactly #3335's WP11 (generalised permissions dialog, retire the stub tab, group CRUD in #2224's shape). WP11 depends on WP9 (the "why can/can't I" explanations), which U8 duplicates. #2224 is CONFLICTING and was written by another developer. R1© has no production value: AF2, the redesign shell and Dockview are all off in production. Knock-on effects: R3b SET2's "team/groups" step inherits the same gates, and the "early value in R1" claim (§10) reduces to R1(a). AUTHZ/PLAN.md:89 defines G-D; :114 WP9; :116 WP11 (depends on WP9 and G-D); :118–119 WP-M1/WP-M2; :136. There is no SyRF.ProjectManagement.Migrations project under MAIN/src. MAIN/docs/planning/application-authority-transition/implementation-plan.md:53 ("no new membership schema" in that programme); :321–331 (evaluator dark, enforced mode only); :457–465 (M6 cutover, no fallback to a weaker evaluator). MAIN/src/charts/syrf-common/env-mapping.yaml:807–812 (enforcement flags default off). gh #2224: CONFLICTING, author nurikarakaya; it edits PermissionReportResolver.cs, which main has since rewritten around the authority gate. Split R1(b). (b1), with no schema dependency: read-only Members & groups showing existing groups and grants, the generalised dialog over existing groups, and retirement of the mock stage page. (b2) group CRUD and assignment after named external joins: G-AUTH-D (WP-M1/M2 in production; owners #3335/#2042) and G-AUTH-C (enforced-mode cutover in the target environment). If legacy-path decisions are acceptable instead of the cutover, require parity tests showing custom-group grants decide identically in the legacy and evaluator paths. Record that WP9/WP11 are owned by the authorization programme, with L8 supplying PM1/PM2/U8 requirements. Get the #2224 author's agreement. Move the group-CRUD part of Q-03 into Batch A. Correct §1, the graph, W1/W2 and §10.
C-02 Blocker PKG/integrated-plan.md §6 l.484 (G3 entry "R2 piloted"), l.486 (G5 entry "R3 piloted; R2b shipped"), l.488 (G7); §7 W3 l.502, W4 l.503; coordination rule 1 l.510–511; §1 l.56–58 The gates and the parallel windows contradict each other. W3 builds R3 during the R2 pilot, and W4 builds R4 during the R3 pilot. But the graph puts G3 and G5 before R3 and R4, and their entry criteria require those pilots to be finished. Taken literally, the path is serial: G1 → R2 build → R2 pilot → G3 → R3 build → R3 pilot → G5 → R4 build → R4 pilot → G7 → R5. The plan conflates contract freeze (when consumers may build against fakes) with release go/no-go. The brief's core requirement, "maximize practical parallel work … join gates", depends on this distinction. The cited gate rows and window rows; mermaid l.454–460. Split each workflow gate into Gx-freeze (ADR, DTOs, fakes and conformance suite; building may start) and Gx-release (acceptance and pilot evidence; the release may ship). Redraw the graph and windows from the split gates and publish the true critical path.
C-03 Major PKG/integrated-plan.md mermaid l.458–460; G5 l.486; R4 l.354–381 The R4 core is unnecessarily serialized behind the R3 pilot. Ordinary study × form reconciliation (RE2–RE5, MG1, GS1, RA1–RA5) needs R2/R2b forms, sessions and minimal stage binding, not profiles or steps. Only the RX1/DP5 screening-profile part needs R3. Today main has no reconciler form at all: read-only cards in a 50/50 grid and no navigation. This is the largest user-visible gap, and the plan defers it by two full release cycles. WEB/stage/stage-reconcile/stage-reconcile.component.html:18–46; WEB/stage/stage.routes.ts:41–61; PKG/source-status-inventory.md fact 8 Split R4. R4a: form reconciliation, matching, gold snapshots, pool, assignment, extra review. Entry: R2b release, C9 freeze, U1, the relevant Q-03 subset and Q-10. R4-profile: the RX1/DP5 screening part. Entry: R3 release. Keep R4b and R4c after R4a.
C-04 Major PKG/integrated-plan.md R2 l.231–279, G2 l.483; R3 l.301–334 R2 is an oversized first canonical release. It has about 16 distinct MVP items: engine, versions, forms, a new drafts contract, Save/Complete, server-side validation, history, publication with impact across all prior versions, the C8 boundary, version export, legacy adapters, claim re-keying, allocation refusal and tally de-duplication. It has joins with four other owners (FEAT-024, presence, allocation, AF2), and no production surface until Q-26 is resolved. R3 is equally broad: a new profile domain, derived decisions, reasons, an AND/OR step editor, unified admission (including closing the eligibility programme's browser gap), claim/allocation/batch amendments, target-aware statistics, selection preview, the designer, overviews and PRISMA projections. Neither delivers value until the whole bundle passes. The cited MVP boundaries; §8 l.528–534 (joins) Offer smaller usable increments. R2a: single-stage versioned forms with explicit Save/Complete, history, and publication using the A-08 targeted refresh, which avoids the multi-stage claim and allocation joins. R2: shared multi-stage sessions. R3a: steps and DP6/DP7 routing driven by the legacy compatibility profile, which already exists in the adoption plan. R3: profile-owned eligibility questions, derived decisions and reasons. Give each increment its own acceptance criteria and pilot.
C-05 Major PKG/open-questions-and-assumptions.md Q-26 l.45, A-04 l.117; PKG/integrated-plan.md l.143–146, 255–258, 579; PKG/contracts.md C16 l.367; P1 lane l.405 Production pilots depend on several environment-wide flags, not just AF2: reviewEligibilityPolicy (R3 admission extends it), activeReviewerTrackingEnabled (R2's claim acceptance), stageReviewRedesign/stageReviewDockview (the R2/R3 reviewer UI extends the redesigned shell), and the notification flags. No generic per-project admission mechanism exists; FEAT-024 has its own registry. C16's "per-project allowlists" has no owner and no window, yet P1 (from G0) and every release assume it. Q-26 understates the AF2 work: by rule, AF2 eligibility must read the flag from the generated environment selector, so per-project admission is an AF2 contract change owned by that programme. MAIN/src/charts/syrf-common/env-mapping.yaml:1242–1250, 1333–1342, 1355–1374, 1596–1598. WEB/shared/annotation/annotation-form-v2/annotation-form-v2-eligibility.ts:59–60 ("Must be sourced from the generated selectAnnotationFormV2 selector"). MAIN/src/libs/project-management/SyRF.ProjectManagement.Mongo.Data/ProjectStatisticsProductionRegistry.cs (feature-specific). /home/chris/workspace/cluster-gitops/syrf/environments/staging/web/values.yaml:58–59 (only AF2 is on). Make a server-authoritative per-project admission service, consumed by both web and API, an explicit L0 deliverable at G1 with an owner and a window. Turn Q-26 into a per-flag decision table (AF2, eligibility, tracking, redesign/Dockview, notifications) agreed with each owner. Until then, label R2–R4 pilots "staging only".
C-06 Major PKG/notifications-integration.md §2 l.89–100, §1.3 item 8 l.78; PKG/open-questions Q-10 l.31; PKG/integrated-plan.md l.62–63, 369, 580 The Q-10 amendments are insufficient and miss the integration effects. (a) "Completed current sessions only" doesn't preserve independence. Legacy Complete can be reopened, and the reviewer's thread link opens the editable review route, so a questioned reviewer can still change answers. Exposure must be recorded, or the link made read-only, in every case. (b) Reconciler eligibility isn't checked. Any Reconcile holder can start a thread, including one who reviewed the study (only their own session is excluded from the candidates). This conflicts with "a reconciler is never offered a study they reviewed". © studyAttention gates #3944, #3945 (study issues) and #3947 (PDF proposals) together, and #3945/#3947 are stacked on #3944. "Amend before merge" therefore also blocks two unrelated features. The obvious alternatives aren't presented: split the flag, restack, or merge with the flag off and gate enablement on the amendments. PR3944/src/services/api/SyRF.API.Endpoint/Services/Notifications/StudyConversationAccess.cs:23–35, 49–56. PR3944/src/services/api/SyRF.API.Endpoint/Controllers/StudyConversationsController.cs:24–28, 91–94 (labels; reviewer ContextPath goes to /review/). PR3944/src/libs/project-management/SyRF.ProjectManagement.Mongo.Data/Repositories/StudyConversationRepository.cs:64–70. PR3947/src/charts/syrf-common/env-mapping.yaml:1153–1161 ("reconciliation conversations, study reports and authorized decisions"). PR3947/src/services/api/SyRF.API.Endpoint/Controllers/StudyIssuesController.cs:23; CheckedPdfProposalsController.cs:86. gh: #3945 is based on the #3944 branch, and #3947 on the #3945 branch. Reframe Q-10 as required before conversations are enabled, not necessarily before merge. Require: reviewer-private (one-to-one) visibility; an exposure marker on any questioned session, plus a read-only context link; a reconciler-eligibility check; exclusion of RA5 extra reviewers until they return their review. Offer merge options: a dedicated conversations flag that depends on notificationInbox, or restacking #3945/#3947 below #3944.
C-07 Major PKG/open-questions A-07 l.120; PKG/notifications-integration.md §5 l.152; PKG/integrated-plan.md R3b l.338–343, R4 l.357–368, R4b l.382–383 The "ship without notifications" fallback contradicts confirmed decisions that need delivery: QY6 (every raiser receives their outcome), LC1 (alert the admin and get confirmation before reopening a stage), and RA5/RA2–RA4 (the requested or assigned reviewer must learn about the work). No feature-owned in-app surface is specified to carry these if the notification stack hasn't merged. PLAN/review-form-owner-decisions-2026-10-02.md:220–224 (QY6); :853–859 (LC1); :260–266 (RA5) Specify feature-owned queues as both the source of truth and the fallback channel: My queries/outcomes, Pending stage-change approvals, Assigned reconciliation work, Requested reviews. Add acceptance tests that pass with every notification flag off. Otherwise, make the notification-base merge an R3b/R4/R4b entry criterion.
C-08 Major PKG/notifications-integration.md §3 l.108–123, §5 l.150–155; PKG/integrated-plan.md R1(b) l.208–214 (a) R1 bypasses an existing notification capture. R1's group, membership and grant changes alter effective Review grants, which #3941 captures transactionally as reviewAccessGranted. New endpoints, including #2224's (written before #3941), must reuse that capture or they silently skip access notifications. Both stacks edit ProjectController, and no R1 ↔ #3941 join or fan-out rule is planned. (b) The catalogue omits events v10 says must be designed: v10 §8 lists "notifications for assignment and for held or corrected items", and held answers and corrected-input re-checks are missing. © Further omissions: FV4 requirement revision ("you no longer need to re-answer"), RA5 withdrawal or expiry, and the reviewer-facing side of LC1 (drafts blocking completion). gh #3941 description ("membership and permission changes now save effective stage review grants"); its diff touches ProjectController.cs and StageNotificationCapture.cs. V10/RECONCILIATION.md:47–51, 197–199 Add an R1 ↔ #3941 join: R1(b) lands after #3941 or calls its capture, with bulk-grant fan-out limits. Add catalogue rows, with disclosure rules, for held items, corrected inputs, FV4 revision, RA5 cancellation and LC1 reviewer effects.
C-09 Major PKG/integrated-plan.md l.68–69, 122–124, 214, 218–220, 593–596; PKG/source-status-inventory.md §7 l.300; PKG/migration-adoption-rollback.md l.67 The unenforced ownership-transfer defect is parked "outside the plan", yet R1 depends on it and makes it worse. R1 acceptance asserts that ChangeOwner "stays" owner-only, and "owner-only actions are unchanged" would preserve the defect. Worse, any custom group granted Edit would inherit ownership transfer. The permission-update endpoints also accept owner-reserved activities with no guard, so a generalised every-activity dialog (WP11) would offer ChangeOwner, Delete and AssignPermissions as grantable. The UI copy and the user guide even describe transfer as an Administrator act. API/Controllers/ProjectController.cs:365–390 (PATCH under ProjectEditPolicy); :1303–1320 (UpdateProjectPermissions accepts any activity). MAIN/src/libs/project-management/SyRF.ProjectManagement.Core/Model/ProjectAggregate/Project.cs:855–883, 1406–1410. MAIN/src/libs/kernel/SyRF.SharedKernel/Enums/Activity.cs:65 (policy constant, never used). API/ResourceSecurity.json: Edit = Administrator group; ChangeOwner/AssignPermissions/Delete = owner. WEB/project/project-admin/project-members/project-members.component.ts:109–110. WEB/project/project-admin/project-options/project-options.component.html:208–226 (client-side disable only). MAIN/user-guide/projects/membership/members-groups.md:77, 82 Make server enforcement an R1(b) entry criterion and a G0 security triage item: an owner-only check on owner changes, and owner-reserved activities refused (or controlled by the PM2 envelope) in UpdateProjectPermission/UpdateStagePermission. Hide them in the dialog. Fix the copy and user guide in the same PR. Change R1's wording from "unchanged" to "enforced".
C-10 Major PKG/ui-coverage-comparison.md §2.3 l.100; PKG/contracts.md C10 l.305–309, C11 l.313–321 The export page undermines the claimed single disclosure policy. The retained page lets any ExportData holder choose Unblinded or IDs and click "UNMASK DATA", regardless of stage-owned blinding (BL1) and candidate isolation (VS1). C10 claims one policy across reads, exports, statistics and notifications, but nothing defines who may unblind an export, whether BL1 applies to exports, or how previous-version and as-of exports (R2/R5) separate candidates from gold for an exporter who isn't a reconciler. WEB/project/data-export/blinding-option-group/blinding-option-group.component.html:6–24; API/ResourceSecurity.json ExportData (Administrator group + owner) Add an export disclosure contract to C10/C11: an unblinding capability or an explicit mapping to ExportData, candidate vs gold separation, BL1 interplay, and an audit trail for unmasking. Add a UI validation before R2's previous-version export.
C-11 Major PKG/ui-coverage-comparison.md §1 asset C l.34; §2.1 l.75; §3 gaps #3 (l.137) and #14 (l.149) The comparison misses #2621 assets and wrongly declares two gaps uncovered. Asset C lists 4 of the 7 #2621 landing-page prototypes. It omits prisma-workflows (maps stages, profiles and rationale questions onto the PRISMA 2020 boxes, supports several versioned workflows per project, renders the diagram, "Export PRISMA diagram"), study-state (per-study screening-outcome version chains, including a ProfileRebound re-screen scenario) and dashboard. Gap #3 ("no asset shows the effect of a new profile version on existing decisions") and gap #14 (PRISMA report views) are therefore at least partly designed. The brief forbids misrepresenting coverage. PR2621/screening-profiles-prototype.html:1610–1620 ("Migration policy for stages where existing screening data exists": keep on old version / re-screen under new / archive stage). PR2621/study-state-prototype.html:27–42. PR2621/prisma-workflows-prototype.html:339, 682, 744 Re-inventory asset C and record a retain/revise/reject decision for each prototype. Examples: the per-stage migration policy must become per-profile under DP4; "archive stage" must be reconciled with LC1/PV2; PRISMA workflow mapping must be reconciled with FEAT-011 amendments A–F and C12. Update the uncovered list.
C-12 Major PKG/open-questions-and-assumptions.md §3 l.91–106; PKG/ui-coverage-comparison.md §3 l.132–151, l.141–142; PKG/integrated-plan.md §7 l.500–501, §9.7 l.559–561, R2 exit l.283–284 "Each gap needs design before its release" is not put into practice. U1–U12 cover about 7 of the 16 uncovered gaps. Nothing validates: reviewer understanding of autosave vs Save vs Complete vs current version/history (R2's own exit criterion); the forms page and composition; the minimal stage-binding UI; the history panel; VS1 accepted-answer display with exposure capture; DP3 eligibility questions and decision reasoning; DP2 correction from history; library browse (R1); assignment, expiry, release and RA5 flows; queries (R4b); as-of export; PRISMA views; outcome-measure and custom-schema authoring (O1); notification item views. U12 omits EW1, VS1, BL1, lifecycle mode and the versioned-settings publish preview. W1 schedules no R2 prototype even though R2 builds in W2. U10/U11 are tagged R3 in the open questions but R3b in the UI comparison. The cited lists Add one validation per uncovered gap and per new reviewer state, each tagged with its release. Put the R2 prototypes (U6, reviewer states, forms and binding) in W1. Add user-testing exit criteria for R3–R5 comparable to R2's.
C-13 Major PKG/ui-coverage-comparison.md l.94; PKG/integrated-plan.md R3 l.302–310, critical path l.332–334; PKG/open-questions A-02 l.115 R3 assumes the screening card can show profile eligibility questions, but screening isn't rendered by AF2. The decision card shows project criteria text and two equal-weight buttons. AF2 eligibility admits only Annotation and ScreeningAndAnnotation stages. Profile-owned question trees on screening-only steps need either an AF2 host/eligibility change (owned by the AF2 programme) or a new renderer. A-02 ("extend AF2, don't rebuild") doesn't cover this. WEB/shared/annotation/annotation-form-v2/annotation-form-v2-eligibility.ts:258–262; WEB/stage/stage-review/review-decision-card/review-decision-card.component.html:16–56 Add an explicit design and contract item (AF2 screening-step admission vs a dedicated renderer), an AF2 join at the G3 freeze, and a UI validation for DP3 reasoning.
C-14 Major PKG/integrated-plan.md §8 AF2 row l.526, R4 critical path l.379–381; PKG/ui-coverage-comparison.md l.97 R4's "reconciliation form session on AF2" needs an editable reconcile host that AF2 doesn't provide. AF2's binding rules make the reconcile host read-only by design, and stage-review and preview still fail closed on reconciliation. The extraction and Experiment carve-outs only lift in AF2 Phase 4 PR 9. §8 lists AF2 as a join only for "R1, before R2 UI". MAIN/src/services/web/CLAUDE.md, AF2 section (read-only mode "is a property of the host"; "the reconciler's own editable form stays on v1 until the carve-outs are lifted"); MAIN/docs/superpowers/plans/2026-08-10-af2-phase4-experiment-parity-hosts.md:50–52 Add AF2 joins: for R4, a new editable reconcile-host contract agreed with the AF2 owner; for R4c, PR 9 for extraction and outcome reconciliation. Put both in the windows.
C-15 Major PKG/ui-coverage-comparison.md l.94 ("Retain AF2, Dockview and v4 parity"); PKG/integrated-plan.md §8 l.526; absent from C5/C17 The Dockview layout contract isn't accounted for. Saved layouts are stored per reviewer per capability slot (screening, annotation, combined), and the API validates the allowed panel keys and one instance of each capability panel. A stage with several steps or forms (R3), a history panel (R2), the population chip (C1) and the reconciliation workspace all change the panel model. Without a contract change, these layouts would be refused or reset. MAIN/docs/architecture/dockview-layout-migration.md:17, 23; MAIN/.claude/rules/stage-review-layouts.md Add a layout-contract amendment to C17/L5: capability keys per step kind, new panel keys, and migration of saved version-2 layouts. Join with the layouts owner before the R2 UI.
C-16 Major PKG/ui-coverage-comparison.md §2.2 l.84, §2.3 l.96–97 "Retain v10 r2 / pool / 4a" imports settings that conflict with confirmed decisions. (1) Step-level "Who reconciles, per part" is a second source of truth beside C10 stage-scoped Reconcile grants, and leaves authority for the RX1 screening part undefined. (2) "Earlier gold standard … candidates never see it" conflicts with VS1, which lets candidates see gold by step policy. (3) The profile setting "Rationale for a reconciled decision: Always", with a blocking error, needs an explicit rule given RE1 makes explanations optional. (4) "EDIT RECONCILIATION reopens it" conflicts with GS1/DP2: changes after gold go through queries or a new snapshot. V10/RECONCILIATION.md:29–31, 84, 108 Record a disposition for each setting in the decision register. Prefer stage grants (with a per-part grant if needed) over step-level "who reconciles". Revise earlier-gold visibility under VS1. Decide whether decision rationale can be required. Replace EDIT RECONCILIATION with the query or new-snapshot route.
C-17 Major PKG/integrated-plan.md acceptance for R2 l.261–275, R3 l.322–331, R3b l.349–350, R5 l.397–399; §6 G1–G3 l.482–484; PKG/open-questions Q-03 l.38; PKG/ui-coverage IA l.157–164; PLAN/review-permission-matrix-proposal-2026-10-03.md l.71, 75, 86–89 The "capability ships with its feature" rule has no teeth. R2–R5 acceptance has no permission or negative tests for Publish, Manage/Approve stage lifecycle, View review work context, or View agreement statistics. Q-03 is "needed by R2", but only G5 lists it. The new views (Monitor/"Who is offered what", History & corrections, Agreement, PRISMA) have no capability mapping, and "Who is offered what" can reveal personal votes (OD5). In v10, Agreement lives inside the Reconcile page, so holders of the agreement capability alone have no navigation entry. The cited sections Add capability acceptance to each release (positive, negative, revocation and blinding cases). List the relevant Q-03 subsets at G1, G2 and G3. Map every new view to a capability. Give Agreement its own place in the navigation.
C-18 Major PKG/ui-coverage-comparison.md l.67, §4 l.153–164; PKG/integrated-plan.md R1(a) l.203–209, l.183–185, R3b l.344–347; PKG/migration-adoption-rollback.md §2 l.50–52; C17 Coexistence of legacy and canonical projects is not designed. Legacy projects stay legacy indefinitely and pilots are admitted per project, so navigation, overviews, settings, the question editor, screening settings vs profiles, the reviewer page and setup must all branch per project. Specific gaps: the proposed navigation drops the Studies and legacy Screening sections. R1(a) makes the legacy-API editor the default, which R2 must then turn into a dual-backend editor; it also contradicts the plan's own rule that every release ships default-off. A project that doesn't exist yet can't be on an allowlist, so the replacement wizard has no admission rule. No milestone makes the canonical path the default for new projects, so SET2's "retire the old wizard after parity" never triggers. The cited lines; WEB/project/project-nav/project-nav.component.ts:438–536 (current Studies and Screening sections) Add a coexistence section to C17: navigation per project mode, the editor's two modes, and legacy labels. Add an admission rule for new projects (by creator or by environment). Add a GA milestone (canonical by default for new projects) with criteria, placed between R4 and R6.
C-19 Major PKG/integrated-plan.md L5 l.166; W3/W4 l.502–503 L5 is a hidden serialization point. R2, R2b, R3, R4, C1 and O1, plus the AF2 programme's open parity PRs, all change the same large files under AF2's rule of one writer per worktree, with shared shell files integrated after the active owner. Yet W3 runs R2b, R3 and C1 reviewer work at the same time. WEB/stage/stage-review/stage-review.component.ts (2,216 lines); WEB/shared/annotation/annotation-form-v2/annotation-form-v2.store.ts (3,036 lines); annotation-form-v2.component.ts (2,478 lines); MAIN/src/services/web/CLAUDE.md, first AF2 rule Define AF2 extension points (step host, history panel, outdated and provenance markers, population context) as an early L5 deliverable agreed with the AF2 owner. Sequence the L5 consumers explicitly in the windows.
C-20 Minor PKG/integrated-plan.md §8 l.526; PKG/source-status-inventory.md §4 l.213–218 The "AF2 parity lands first" join can't be evaluated. Its list includes #3394 (which the inventory calls superseded by the Focus contract), #3292 (replaced by Dockview) and the stale #3017, alongside the conflicting #3546. No exit set is defined. The cited rows Name the parity PRs that must land, and record close or supersede decisions for the rest, with the AF2 owner.
C-21 Minor PKG/ui-coverage-comparison.md §4 l.153–164, §2.2 l.87; PKG/open-questions Q-13 l.32; C17 l.376–383 The proposed navigation has several inconsistencies. (a) "v10's Setup 1–6 order is kept inside Design" is wrong. v10's default navigation is Setup: Concepts → Entity types & questions → Outcome schemas → Forms → Profiles → Stages. The package reorders these and moves Stages out, which matches v10's alternate "library" mode. (b) Q-13 presents "Library" as v10's term, but that label belongs to the alternate mode. © Chris decided on 21 Sep to keep the "Project setup" checklist in the navigation. §4 omits it, while §2.2 keeps it. (d) Reconcile appears under both Review and Stages, and under RE4 a shared form's task would appear under several stages. (e) Neither Agreement nor General project settings has a place. (f) "Question library" wording (SET1, R1) still collides with Study Management's "Library". (g) The M3 navigation owner, who rebuilt the rail and the checklist footer in September, isn't listed as a join. (h) The move from category tabs to entity types (C1) isn't designed. V10/prototype/SyRF Prototype v10.dc.html:3274 (default nav mode "steps"), 3281–3292; /home/chris/workspace/syrf/handover/2026-09-21-stage-review-design/AGENT-BRIEF.md:25; WEB/project/project-overview/project-setup/project-setup.component.html:1–43; MAIN/docs/features/material-3-migration/navigation-plan.md:15–20; MAIN commit fce4ae8bc Correct the claim; include the Project setup footer explicitly; define one Reconcile entry and how it behaves for shared forms; place Agreement; choose a different term for the question library; add the M3 navigation owner as an L16 join; design the categories-to-entity-types transition.
C-22 Minor PKG/ui-coverage-comparison.md l.29, 69 The QM v2 publication wizard is mis-described and its vocabulary isn't reconciled. The package calls it a "five-step wizard" but lists four steps. The prototype reserves a step 4 for conflicting per-question decisions within one session, which was never prototyped. Its vocabulary (impact: does-not-affect/may-affect; handling: keep/map/re-answer) isn't mapped to the recovered requireReanswer/autoUpdate/doNothing. "Map answers to updated options" transforms data and isn't obviously the same as autoUpdate under FV3. MAIN/.local/qm-designer-handover/05-prototype/prototype.html:1836–1857, 2065–2067 Record the vocabulary mapping, decide whether option mapping is approved, and add the within-session conflict view to U6.
C-23 Minor PKG/ui-coverage-comparison.md l.94; PKG/integrated-plan.md R2 l.244–250 Destructive reviewer actions aren't addressed. v4's "Remove all annotations…" menu item and the hard session delete (listed in the inventory) remain. For canonical sessions they need to become an explicit versioned action, or be disabled. V10/reference/stage-review-page-handoff.md:73; WEB/shared/annotation/annotation-form-v2/annotation-form-persistence.ts (removeSession); PKG/source-status-inventory.md §2, sessions row Add an R2 MVP item: no hard delete for canonical sessions; replace it with an explicit versioned "clear" or a draft discard.
C-24 Minor PKG/integrated-plan.md R2 l.254–255 R2's scope for outcome data is unclear. OutcomeData is keyed by stage, so an extraction form bound to two stages breaks SF1 unless it is excluded or adapted. "Pilot extraction stages are annotation-only" doesn't say whether Experiment and outcome entry are in scope. MAIN/src/libs/project-management/SyRF.ProjectManagement.Core/Model/StudyAggregate/OutcomeData.cs:31; AnnotationOptions.cs:24 State that R2 excludes Experiment/outcome forms from multi-stage binding until O1/C14, or define the adapter.
C-25 Minor PKG/integrated-plan.md R2b l.286–294, R3b l.338–343; U4/U10 Fix (R2b) and lifecycle approval (R3b) aren't connected. Fix creates a current incomplete version. For a session pinned to a Completed stage, that is a change that may reopen the stage, which LC1 gates. Fix also needs a stage route for provenance and admission. R3b doesn't re-check the R2b flows. PLAN/review-form-owner-decisions-2026-10-02.md:470–474, 853–859 Add an R3b acceptance item covering Fix and outdated-answer flows under LC1. Add route choice and the approval wait to U4.
C-26 Minor PKG/open-questions U1 l.95; PKG/ui-coverage-comparison.md l.97 U1 doesn't define how agreement works with three or more candidates. It needs rules for agreement icons and prefill when answers are partial or blank (UA1 optional blanks; RE5 exact match "among the relevant candidates"; no majority). It must ensure a candidate selector never hides a disagreeing candidate, offer a keyboard alternative to drag-to-pair, and handle performance with N candidates on large forms. V10/RECONCILIATION.md:102–104, 136–137 Add these points to U1's acceptance criteria.
C-27 Minor PKG/integrated-plan.md l.269–272, 340–343, 529–531, 540 Several joins are timed inconsistently. The allocation join is placed at G3, but R2's acceptance already requires refusing proportional shares (A-09). R3b reuses ProgressiveBatchCompletion from #3939, which is open and not merged. #2986 (dormant server-side answer validation) overlaps R2's server-side Complete validation. The cited lines Move the allocation join to G1/G2. Make "#3939 merged, or its completion definition extracted" an R3b entry criterion. Change #2986's disposition to "harvest into R2".
C-28 Minor PKG/integrated-plan.md l.528, 537, 542–543; PKG/source-status-inventory.md l.224, 229–236 The PR snapshot is already stale. #3948 merged at 02:57Z, so main is now 9d74077d8. #2224, #2412 and #2469 are CONFLICTING but shown as "Open". #2224's author is another developer. #2469's stage-target pie change conflicts with SF2 and is partly superseded by #3776–#3795. Live gh pr view results Refresh the states, record ownership, and add dispositions for the stale PRs.
C-29 Minor PKG/integrated-plan.md R1 acceptance and R1b l.217–224; permission matrix l.103–108 R1b's audit and anti-escalation rules are underspecified. The delegation audit should reuse the authorization programme's authorizationAudit and its F1 audit reader, not an unnamed new store. Anti-escalation only says an editor can't add themselves to a privileged group. It must also cover editors who add others, and forbid granting owner-reserved activities to groups before R1b. AUTHZ/PLAN.md:109, 121 Reuse the existing audit; tighten the anti-escalation acceptance cases.
C-30 Minor PKG/integrated-plan.md R5 l.389–399, G7 l.488 As-of downloads are held back by PRISMA. EX1 as-of downloads for forms and gold don't depend on P1 or PRISMA, but G7 gates them behind P1, R3/R4, amendments A–F and the Q-04/Q-16 methods. The cited lines Ship as-of export (C11) as its own lane release after R2/R4a, with coverage labels.
C-31 Note PKG/source-status-inventory.md §7 l.303 R1 should absorb the members route guard typo. The project.editMembership guard typo is #3335's WP1d. Because the router ignores an undefined guard result, it is most likely a no-op rather than a lock-out; this is unverified, and the server still enforces the permission. WEB/project/project-admin/project-admin.routes.ts:36; WEB/project/project-nav/project-nav.component.ts:705 (editMemberships); AUTHZ/PLAN.md:106 Include the fix and a test in R1(b).
C-32 Note PKG/ui-coverage-comparison.md l.50 The "classification site not found" entry is misleading. A local source and build with git history exists. /home/chris/.codex/visualizations/2026/09/23/01a0cbec-0c32-7103-ab5a-bfc05665deb7/classification-site/dist/index.html (27 Sep, 23:43) Change the entry to "found, not reviewed", or review it.
C-33 Note PKG/README.md l.37; PKG/integrated-plan.md l.27; PKG/validation-evidence.md l.57, 79 The package links to files that don't exist yet: reviews/ and reviews/review-resolution-matrix.md. ls PKG Create them before running the final validation.

Verified as correct

  • New question editor: Design/Assign/Preview; seven hard-coded categories (WEB/core/state/entities/annotation-question/annotation-question.entity.ts:388–403); same-parent drag only ("You can only move questions with the same parent for now", WEB/project/project-admin/question-management/design/annotation-question-tree-drag-drop.feature.ts:622). The "Focused question" debug text ships at design.component.html:14. The route is guarded by the design permission, and newQuestionManagement only hides the navigation link, while the legacy "Question design" link is always shown.
  • Excluded specs: 17 question-management specs are excluded in MAIN/src/services/web/angular.json:186–202. Issue #3655's title says 18.
  • Preview mounts AF2 with a v1 fallback (WEB/project/project-admin/question-management/preview/stage-preview/stage-preview.component.html:62–83).
  • Stage settings page: Enable toggle, review settings, mock study filters, allocation, question selection, upload, and the mock "Under Construction" stage permissions (WEB/stage/stage-admin/stage-admin.component.html:1–61).
  • Reconcile route: read-only candidate cards in a 50/50 grid, no reconciler form, and no navigation links to it (stage-reconcile.component.html:18–46; WEB/core/state/ui/stage/stage-ui.selectors.ts:74–76).
  • PermissionsDialogComponent is a group × activity editor used only for chart visibility (screening and stage overviews). It saves through the owner-only AssignPermissions endpoints. The membership UI offers Administrator/Reviewer only, and CreateProjectGroupComponent is referenced nowhere outside its own files.
  • Setup checklist: the navigation-footer checklist shows an n/8 badge (project-setup.component.html:1–43), consistent with the 21 Sep decision.
  • Ownership transfer is unenforced on the server (re-verified as above). The UI disables the control client-side only.
  • Asset A (QM v2 prototype): SHA-256 032fe56e…a999a, 3,890 lines. A3 scaffolds are present in #2575's head tree under question-management-v2/{design, properties-panel/impact-mapping-panel, assign/publish-wizard, preview}. B1 has a three-step "Publish to stage" wizard and draft/changed/published lifecycle icons (MAIN/docs/features/redesign-prototype/v2/components-qm-v6.jsx:786–788, 2055–2083).
  • Review Prototype v4: the README is byte-identical to v10's reference copy (both SHA-256 0512327a…ab11), so the correction to COMPARISON.md line 107 is right. v4's footer copy ("Unsaved changes / All changes saved / Completed") confirms the package's warning about misleading save copy.
  • #3944 behaviour matches the package's description: every participant sees every post; replies notify all other participants; incomplete sessions are eligible candidates; threads are keyed by stage and owned by the reconciler; and picker and thread numbering differ.
  • Notification stack heads match the package table: all eight PRs are open; studyAttention requires notificationInbox in the controllers.
  • Environment flags: AF2 is on only in staging (/home/chris/workspace/cluster-gitops/syrf/environments/staging/web/values.yaml:58–59). AF2 eligibility excludes screening-only stages, and the reconcile host is read-only by rule.
  • "Library" naming clash is real: Study Management uses "Library" (WEB/project/project-nav/project-nav.component.ts:456). The proposed "Design" label aligns with the existing Design permission.
  • The "not found" list is otherwise honest: Review Prototype v3/v5 and the Figma file are absent and are not claimed as reviewed.

Missing coverage

  • Accessibility acceptance for the new surfaces: keyboard alternatives to drag-pairing, screen-reader meaning for candidate pills, agreement icons and the step strip, contrast of dashed autofill outlines in light and dark themes, and v10's 1440/925 px checks. AF2 Phase 3.4 set this precedent.
  • Reviewer progress lists keyed by stage (my-studies navigator, incomplete studies, the no-work page from #2412, StageReviewerProgressStore) under shared form sessions. A session saved through stage A must show consistently in stage B without double counting.
  • A terminology and copy contract, delivered before any R2 copy is written. v10's "Save draft" conflicts with SL2's immutable Save, and v4's "All changes saved" would mislead. Also needed: "Needs updating" vs "contains outdated annotations", "Collective Include", and one alias scheme across candidate cards, threads, history and exports (BL1).
  • Pilot operations UX: who admits a project to or removes it from a pilot allowlist, how, and what reviewers see when a pilot is rolled back to read-only.
  • Help and change communication per release: user-guide updates and an in-product "what changed" page (v10 r8), especially for the ownership wording and the move from screening settings to profiles.
  • Today's screening-reconciliation UI path and how it is retired under R4/RX1. Annotation reconciliation's read-only route is documented; the screening side isn't.
  • Rendering of review-workflow items in the inbox: action labels, deep links that respect RE4 task identity and BL1 aliases, and the "Related item unavailable" behaviour. This is joint with the notification programme and has no UI validation.
  • Narrow-screen behaviour for the reconciliation workspace and stage designer, and performance budgets for N-candidate reconciliation on large forms, since AF2's bounded rendering assumes one form instance.

Critical Files for Implementation

  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/integrated-plan.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/ui-coverage-comparison.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/notifications-integration.md
  • /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/open-questions-and-assumptions.md
  • /home/chris/workspace/syrf/main/src/services/api/SyRF.API.Endpoint/Controllers/ProjectController.cs