Skip to content

Question management plan: the new question management, integrated

Status on 5 October 2026. This is a temporary planning document. Feature implementation is on hold (Chris, 5 October 2026) and G0 is not approved. Implementation, porting, PR closure, flag retirement and messages to the design session are not authorised by this plan. Every recommendation here is a recommendation, and anything without an owner decision ID is a PROPOSAL.

Updated 6 October 2026. Chris decided that new questions are required by default, with explicit reasons no value is provided configured per question (decided-amended), and that answer metadata is configurable per answer state (his direction) (decision register §1.17; RD §3.16). How clearing is recorded stays open (DQ-50); the naming was decided later that day (DQ-46, below). Custom reference questions are specified in the classification, populations and references specification (CPR §3.4) and arrive with lane C1 unless Chris decides otherwise (DQ-48). §3, §4.1 (M-23, M-24, M-30), §6.2, §6.5, §6.7, §6.11 and the abbreviations carry the changes.

Updated 6 October 2026 (design-handoff answers). In a Codex discussion Chris answered (decision register §1.18): one editor for Classic and converted projects, with the saving and assignment behaviour appropriate to each project mode and no versioned publication, draft or assignment semantics in unconverted projects (DQ-01, which answers QMI-04 in part; the legacy designer's retirement timing stays a recommendation); a compact question list or tree with the editor beside it on wide screens and a separate drill-in editor page on narrow screens, with no numeric breakpoint approved (DQ-02); automatic saving into the unpublished design draft, with save status, safe conflict handling and per-question discard, never publishing to reviewers (DQ-03); usable responsive phone layouts for design and admin screens with no feature removed and no formal phone acceptance gate (DQ-04); and the naming (DQ-46, decided-amended): "answer status" for the overall state, "reason no value is provided" for the configured reasons and "Other, please specify" as a value. §1, §3, §4.3, §6.2, §6.3, §6.5, §6.7, §6.9, §7.2, §7.3 and §9.4 carry the answers. Implementation remains on hold, and nothing here sends the design pack.

Why it exists. On 5 October 2026 Chris asked for the plans and specifications for the new question management to be integrated properly: salvageable work already carried out is reused and adapted to fit the other plans and specifications written that week, and it is included in the design prompt. This page is the single place to read question management end to end. It restates no rules. The specifications, contracts, versioning model and harvest map stay authoritative, and this page links to them.

Sources. Three read-only research passes on 5 October 2026, against origin/main at af2d8e960 (the merge of #4061):

  • an inventory of the question-management work already merged on main (items M-01 to M-35, §4);
  • an alignment of question management with the plans written this week (interactions X-01 to X-49, §7 and §8);
  • a coverage check of the design-prototype handoff for question-management surfaces (§3, QMP-08).

Their working notes are not kept in the repository, so this page restates what they found. Code claims marked "verified" were re-read on this branch on 5 October 2026. The rest are static readings from those passes; nothing was built or run.

Abbreviations. RD, UX, ACD, BC, SP, RS and, since 6 October 2026, CPR are the specifications (index). VM is the versioning model, DOM the delivery operating model and PI the programme integration. M-nn are §4's inventory items, X-nn §7's interactions, H-… the harvest map entries and T-… the implementation tracker rows. Paths: QM/ is src/services/web/src/app/project/project-admin/question-management/; AQD/ is src/services/web/src/app/project/project-admin/annotation-question-designer/; AF2/ is src/services/web/src/app/shared/annotation/annotation-form-v2/; PAG/ is src/libs/project-management/SyRF.ProjectManagement.Core/Model/ProjectAggregate/; API/ is src/services/api/SyRF.API.Endpoint/.

1. Summary in plain English

What the new question management is. Admins author questions as stable definitions with immutable versions. Options keep their identity when they are renamed, so answers keep their meaning. Annotation forms are composed from pinned question versions and own their requiredness and their standard reviewer target. Publishing a new form version shows its impact on existing work first. The publisher declares whether each change is compatible and whether answers may be mapped, and SyRF records generated session versions where the chosen treatment needs them. Several people can draft at once, see each other and never overwrite each other silently. Questions can be imported from a template file, with a preview that equals the result, or copied from the application-wide CAMARADES catalogue. Every legacy project's questions convert faithfully to version 1.

What is built already. More than the package said before this revision. main has:

  • the new Design, Assign and Preview editor (about 7.4k lines in 95 files, 23 merges, the latest #4023 on 4 October), still behind a flag that only hides its navigation link;
  • AF2, the reviewer form: the production-grade candidate renderer and the only renderer canonical forms will use;
  • live question counts from FEAT-024, answer-label authoring, a server placement validator, a server child-condition guard, a same-project copy and a 16-rule question corpus with fixtures;
  • the legacy designer and AF1, which are still the production defaults.

What is reused. The new editor becomes the two-mode designer: hardened on the legacy API in R1a, given a canonical design-draft mode in R2a, and given presence and publication in R2c. AF2 renders every canonical form. The counts become R2c's usage evidence. The rule corpus, placement validator, system-question code, Assign and copy are adapted. The dormant PRs feed the rest through the harvest map: #3934's import nearly unchanged, and QM v2's ideas, tests and several algorithms re-keyed to option IDs.

What is new. Question and form versions with immutable compatibility declarations; collaborative design drafts with base checks; publication with impact and generated session versions; the catalogue; the import-target port; the conversion of legacy questions.

What is not reused. QM v2's storage shapes, single mutable drafts, stage-keyed publishing, its migration that erases legacy data and its lossy rollback (harvest map §6). Native HTML5 drag. The legacy designer, once the new editor is the default entry (QMI-04: one editor for every project is decided by DQ-01; the retirement timing is open).

What stays on hold. Everything. No slice starts until Chris lifts the hold (T-HOLD), approves G0 (T-G0) and approves the slice's brief and gate. Four owner questions (QMI-01 to QMI-03 and QMI-05, §9), QMI-04's retirement timing and five brief-level confirmations are open. None of them blocks planning.

2. Authority and boundaries

ID What it fixes for question management Status Where
SF1, SF2 A form is the project-level evidence and requirement owner and owns its review target; one session per reviewer per Study and form across stages Owner ledger Decision register §1.1; RD §3.5
FV1 to FV4 Adding a question creates a new form version; publication checks sessions under every prior version; counting follows the admin's choice; an unnecessary update requirement can be revised later, with history Owner ledger Decision register §1.2; RD §4.8, §4.13
Q-20 Impact preview for admins; alerts to affected reviewers; in-form warnings for a reviewer's own edits; deduplicated notices Decided RD §4.8; UX §3.9, §3.10
Q-27 Readiness from current evidence; warn the actor before commit; never rewrite dependent work automatically Decided RD §4.5, §7
Q-34 The publisher declares compatibility and whether mapping applies; mapping writes attributable revisions Decided-amended RD §3.4, §4.8; VM §3.5, §8.9
D2-01 Publication may create attributable generated session versions Decided-amended RD §3.15
D2-02 Compatibility belongs to immutable question versions; a wrong declaration is corrected by guided rollback and republication Decided-amended RD §3.4, §4.13
D2-03 to D2-06 A data-type or multiplicity change is an incompatible version of the same question (D2-03); a stage binds the form identity (D2-04); the standard target is inside the form version and every other setting is classified (D2-05); system questions are versioned data (D2-06) D2-03, D2-04 and D2-06 are engineering contracts; D2-05 is Decided-amended in part RD-R30 to RD-R32; RD §3.5
D2-07, D2-08 Form-owned inactivity timeout and in-progress limit; one shared session and place across tabs and devices Decided RD §3.10, §3.11
D2-09 The second form's reconciler may revise a shared question's accepted answer as a new snapshot with provenance; an optional reason is prompted for; a query may be raised Decided-amended (5 October 2026) RD §4.14, RD-R37; T-OI-01
D2-10, D2-11 Publication active-work protection with measured limits; many drafts and one publication per form D2-10 brief item; D2-11 Decided RD §7, RD-R25, RD-R35
D2-15 One application-wide CAMARADES catalogue; versioned copies with provenance; publication requests Decided-amended ACD §3.4, §4.7, §4.8
D4-17 The outdated-answer mode is configurable: warn (the default) or block Decided-amended RS §5.8
OS-A01 Collaborative question drafts: presence, live updates, base checks, recoverable conflicts, attributed changes Owner amendment RD §3.7, §4.7, RD-R26; UX §3.8
OS-A04 Reconciled-answer hints with click-to-fill, never prefilled Owner amendment RS §3.6; RD §4.14
OS-A12 The standard reviewer target versions the form Owner amendment RD §3.5, RD-R12
Q-08, Q-09 Harvest the dormant QM v2 stack and #2224 rather than revive them Decided (3 October 2026) Harvest map §2
QD1, Q-13 A published question is never permanently deleted; "Library" stays with Study Management, the question area is "Design" and reusable items are "question templates" Decided (3 October 2026) Decision register §1.11
The hold Feature implementation is on hold (Chris, 5 October 2026) In force T-HOLD

Boundaries.

  • This plan records and links. It changes no owner decision. Where it corrects the package, it corrects facts and cites the evidence.
  • Proposals to plans owned by other sessions (the architecture-review follow-up plans and ADR-021) are listed in §8 for the owner or that session to apply. This change set edits no file outside this package except mkdocs.yml, which gains two navigation entries (this plan and the open questions before the design handoff).
  • The owner-session archive and the review archives under reviews/ are verbatim records and are not edited.
  • No secrets, clinical data or participant identifiers appear here. Scenario figures elsewhere in the package are synthetic.

3. The target model in one page

This is a tour. The rules live in the linked sections, and this page does not repeat them.

  • Questions. A question has a stable identity (QuestionRef with parent, entity type, definition owner and repeatable) and immutable content versions: wording, help, answer label, control and data type, options with stable option IDs, conditions and option filters in parent option IDs, response modes and metadata, a change record and the publisher's compatibility declaration. Rules: VM §3.1 to §3.8; RD §3.4; contracts C4. 6 October 2026: "response modes" are now reasons no value is provided (DQ-46, decided-amended): each version declares the ones it allows (the defaults Not reported, Not applicable and Unable to assess, custom reasons, and sets copied from catalogue templates such as SYRCLE), each with a stable identity, and its metadata fields (comment, unit, evidence quote with source location, reason), each hidden, allowed or required per answer state (RD-R50, RD-R52). "Other, please specify" is a value: the listed "Other" option plus its configured free text, kept with its option identity in versions and exports, never a reason and no longer a metadata field. A risk-of-bias "Unclear" stays an option.
  • Reference questions (6 October 2026, PROPOSAL). A question whose answer points at records of declared types, with a target contract as version content; today's five lookups become system reference contracts. Designers create them from lane C1 (CPR §3.4; DQ-48).
  • System questions are global versioned data pinned by form versions, with main's exact text at version 1 (VM §3.7; RD-R32).
  • Forms. A form version pins question versions with their ancestors, requiredness, minimum instance counts, the applicability graph, the renderability result, the standard target and the reconciliation policy. 6 October 2026: a newly pinned question is required by default; Optional sits under advanced settings with the warning "reviewers can skip this without saying why"; Complete needs a value or a reason no value is provided for every applicable required question, and Save never needs one (RD-R49, RD-R51). A stage binds the form identity. Rules: RD §3.5, RD-R12, RD-R31; VM §4; SP for stages.
  • Design drafts. Many named drafts per form or profile. Each edit is an appended change with a base revision. Presence shows who is viewing and editing and is never an audit record. Rules: RD §3.7, §4.7, RD-R25, RD-R26; UX §3.8. How presence crosses API pods is QMI-01. 6 October 2026 (DQ-03): accepted field changes save automatically into the unpublished design draft, with a clear save status, safe conflict handling and per-question discard controls; saving a design draft never publishes to reviewers.
  • Publication. Preview, declarations and treatments, a constant-work phase 1, a per-Study phase 2 with generated versions, and the impact manifest afterwards. One publication per form; guided correction for a wrong declaration. Rules: RD §3.8, §3.15, §4.8, §4.9, §4.13, §7; VM §8. Its P9 class is QMI-02. The shared impact preview is UX §3.9 and the reviewer alerts UX §3.10.
  • Rendering. AF2 renders canonical forms through VersionedAnnotationFormDataSource and never falls back to AF1 (VM §4.3; contracts C17; E44; T-UX-10).
  • Overlapping forms and shared accepted answers. RD §4.13 and §4.14; RS §5.8 for the outdated-answer mode.
  • Import and the catalogue. Import runs behind an import-target port: legacy apply in R1a and a canonical adapter that writes drafts in R2a (harvest map §5.4). Catalogue copies carry copiedFrom provenance and land in drafts (ACD §3.4, §4.7, §4.8).
  • Conversion. Every legacy project's questions become version 1 with their original IDs, counted as published, with conditions and filters kept and legacy-gap labels where history was never recorded (BC §3.2, §3.4). 6 October 2026: each converted form keeps today's per-question Optional flag as its requiredness (faithful conversion), and the redesign wizard offers to upgrade optional questions (BC-R49).
  • Design and naming. The question area is "Design › Questions and entity types", reusable items are "question templates", and the copy deck bans "question library" (Q-13; UI-11). The design-prototype handoff describes these surfaces for the design session, including its question-management changes and its copy-ready prompt. 6 October 2026: one editor serves Classic and converted projects (DQ-01); a compact question list or tree has the editor beside it on wide screens and a drill-in editor page on narrow screens, with the breakpoint left to design validation (DQ-02); design and admin screens have usable phone layouts with no feature removed and no formal phone gate (DQ-04). The answer words are "answer status", "reason no value is provided" ("no-value reason" in dense tables), "Other, please specify" and, as illustrative action wording only, "No value to enter"; "no-value answer", "blank", "response mode", "response option", "missing-data code" and "answer exception" are retired from user-facing language (DQ-46).

4. What exists today and what happens to it

4.1 The inventory of main

The inventory read main at af2d8e960; the local main differed from it only in statistics code and this package, so every question-management path read on disk equalled origin/main. Flag values came from the local cluster-gitops checkout at 352b59d5 (5 October 2026). Verdicts: Keep and evolve; Adapt; Bridge (stays until conversion or R7); Replace; Retire.

ID Item Verdict Target Release Tracker row
M-01 FEAT-020 legacy question reference set (docs/features/annotation-questions/) Bridge as the legacy reference and a conversion input; add a "describes the legacy model" banner BC §3.4; VM §3.1, §11 M0 banner; R6 T-BC-01; banner in T-RD-10
M-02 Rule corpus: annotation-question-rules.yaml (16 rules) and formal-specification.md; NQ005, CPA001 and CPA002 are not implemented Adapt into C4 composition and placement rules and BC dry-run findings; re-key CPA to option IDs; one code namespace RD §3.4, §3.5; VM §4.2; BC §4.2; AC-R2a-24 F1a, R2a T-RD-01, T-RD-02, T-BC-01
M-03 Placement fixtures (16 valid, 96 invalid; referenced by nothing) Adapt into a shared composition FX set run by the .NET validator now and the canonical validator in R2a VM §4.2; AC-R2a-24; AC-R1a-CONF F1a, R2a T-RD-01, T-RD-02
M-04 QM v2 and versioning design documents on main (FEAT-003, FEAT-001, qm-v2-context/) Replace: marked Superseded with pointers; qm-v2-context kept as an archive RD §3, §4; VM M0 T-RD-10
M-05 Extensibility architecture (Approved, 1 September) and the response-modes context Adapt into C4 version content and E37; amend decisions 1 and 7 VM §3.2, §3.4; E37; C4 F1a T-RD-01, T-RD-10
M-06 AF2 feature documents Keep remaining-delivery and accelerated-stage-review; adapt the README; retire the brief C17; VM §4.3 F1c T-UX-10
M-07 ADR-011, multi-option conditions on schema v0 Bridge for legacy writes until R7; conversion maps v0 option IDs VM §3.3, §11; BC §3.4 R6, R7 T-BC-01, T-BC-03
M-08 Live user guide for the question editors Bridge; updated in the R1a default-entry PR and again for R2a's canonical mode C17 R1a, R2a T-RD-12, T-RD-17
M-09 New editor: shell, routes, Design tab (QM/) Keep and evolve as C17's two-mode designer RD §3.4, §3.7, §4.7; C17; UX §3.8 R1a (legacy API); R2a (canonical mode); R2c (presence, publication) T-RD-12, T-RD-02, T-RD-05, T-UX-06
M-10 Assign tab and stage question sets (web and API, with the X-SyRF-Expected-Stage-Questions-SHA256 precondition) Bridge per-stage sets for legacy projects until conversion; Adapt into form composition for canonical projects RD-R31; VM §4.1, §4.2 R2a T-RD-02, T-BC-03
M-11 Preview tab (AF2 host when eligible, AF1 otherwise) Adapt: a pinned form version through the versioned data source; no AF1 fallback; R2c change markers VM §4.3; AC-R2a-38; AC-R2c-16 R2a, R2c T-RD-02, T-RD-05, T-RD-12
M-12 Live question counts and locks Keep and evolve the counts as R2c usage evidence; Bridge the lock for legacy projects only (the lock is display-only) RD §4.8 step 1; C8; RI §3.17 R2c T-RI-04, T-RD-05
M-13 Native HTML5 drag and the reposition endpoint Replace with pointer-based CDK drag and a keyboard alternative; remove the timing output AC-R1a-12; UX-R44 R1a T-RD-12
M-14 Dead and stub code (QM/hybrid-example/, console.log stubs) Retire hybrid-example and its spec; keep the live hybrid/ AC-R1a-07 R1a, or surface R0.5 first T-RD-12
M-15 Legacy designer (AQD/) and stage question selection Bridge until the new editor is the default entry, then Retire C17 R1a follow-on; at the latest R7 T-RD-17
M-16 AF2 (157 files, 47 specs, none excluded) Keep and evolve as the only canonical renderer VM §4.3; C17 (E44); AC-R2a-38 F1c, R2a T-UX-10, T-UX-03, T-RD-02
M-17 AF2 conditional display, parent filters and repeatable branches Adapt into the client half of the E23 evaluator; re-key to option IDs of pinned versions VM §3.4, §3.6; E23; AC-R2a-03 F1a, R2a T-RD-01, T-RD-02
M-18 AF1 and its rules Bridge for legacy stages, never a canonical fallback; Retire at AF2 slice 6 or R7, whichever is later VM §4.3; BC §10 phase 4 R7 T-BC-09
M-19 Core NgRx question state and HTTP client Bridge as the editor's legacy-API mode until R7; the canonical mode gets a new client and route-owned stores C17; C4; state plan R3.4 R2a, R7 T-RD-02, T-BC-09
M-20 Answer label (#2739, #2772) Keep and evolve as version presentation content VM §3.2, §3.5; BC §3.4 F1a T-RD-01, T-BC-01
M-21 Study presence (study-presence/) Adapt: design presence on the realtime v2 hub, visible only to design holders, never an audit record (X-02, QMI-01) UX §3.8; RD §3.7, RD-R26 R2c T-UX-06
M-22 Web test exclusions (17 question-management entries, 2 legacy designer, 10 AF1) Keep AC-R1a-07 for the question-management specs; delete hybrid-example's spec; the other entries follow M-15 and M-18 AC-R1a-07; AC-ALL-15 R1a T-RD-12
M-23 Embedded question model (PAG/AnnotationQuestion.cs, OptionInfo.cs) Bridge as the legacy writer until R7 and the conversion source; R0 refuses legacy question writes on canonical scopes. 6 October 2026: its per-question Optional flag becomes each converted form's requiredness (BC-R49); its label annotations and lookup answers convert under CPR §10.3 VM §3.3, §11; BC §3.4; CPR §10.3 R0, R2a, R6, R7 T-BC-01, T-BC-06, T-RD-02, T-BC-09
M-24 System questions built from code (18 GUIDs) Adapt into the global seed with a parity test; Bridge legacy reads until R7. 6 October 2026: the five lookup questions among them become system reference contracts with unchanged GUIDs (CPR-R21) VM §3.7; RD-R32; AC-R2a-23; CPR §3.4.8 F1a, R2a T-RD-01, T-RD-02, T-BC-01
M-25 Placement rules and validator (#2648, #2651) Adapt into the placement half of C4 composition validation with typed refusals; findings only in conversion VM §4.2; C18; BC §4.2 R1a (the legacy validator's typed 400, C4-T21); R2a T-RD-12, T-RD-02, T-BC-01
M-26 Child-condition guard on parent edits (#2697) Keep and evolve: the R1a warning explains it; R2a re-keys it to option IDs of pinned parents VM §4.2; AC-R1a-13; AC-R2a-24 R1a, R2a T-RD-12, T-RD-02
M-27 Question CRUD endpoints (reposition, upsert, copy, tally, delete) Bridge as the legacy-API mode; listed in R0's writer inventory and refused on canonical scopes; replaced by C4 commands Migration §4; C4 R0, R2a T-BC-01, T-BC-06, T-RD-02
M-28 Delete cascade (not atomic, #3088; no Audit.Version bump) Bridge for legacy projects; replaced by retire or leave-out (QD1) for canonical ones VM §3.8; AC-R2a-10 R0, R2a T-BC-06, T-RD-02
M-29 Same-project copy, single or recursive Adapt into the "duplicate" design-draft change kind with provenance; an input to copying from another project (ACD B5) ACD §3.4 R2a T-RD-02, T-AC-04
M-30 Save-path validation (structural only) Bridge legacy saves (#2986's wiring stays outside the programme, G0-D6); Adapt the relationship validator into conversion findings. 6 October 2026: its fixed lookup check (LookupTargetQuestionIds) is re-keyed to the system target contracts with the same accept and refuse results (CPR-R21, CPR-AE15) RD-R07; E23; BC §4.2; CPR §3.4.1, §3.4.8 F1a, R6 T-RD-14, T-BC-01, T-RD-02
M-31 Audit.Version and IAggregateWriteGuard (#3909) Keep and evolve: version CAS for heads; the write guard as R0's seam RD §3.1; C16 R0 T-BC-06
M-32 newQuestionManagement flag Adapt into the default-entry switch, then Retire under the flag retirement contract; never reused C17 R1a; R1a follow-on T-RD-12, T-RD-17
M-33 annotationFormV2 group Keep (AF2 programme); canonical routes admit through CanonicalEnrolment and per-project targeting Plan §5.11, §8 R0, R2a T-UX-03
M-34 materializedProjectStatisticsQuestionCounts Keep and evolve with M-12 Q-31; RI §3.17 R2c T-RI-04
M-35 Stale gitops keys (schemaV0MultiOptionConditionalParentAnswers, newStageSettings in production values) Retire through a gitops cleanup outside the programme None None None (follow-up 6, §10)

annotationQuestionImport exists only on #3934's branch (H-IMP-04); it is not on main.

4.2 Corrections to the package

These facts were wrong or missing in the package. Each says where this change set applies it.

  1. Neither editor saves filtered options. The legacy dialog collects them (create-question.component.html:282-320) and then writes parentFilter: null (create-question.component.ts:533, verified). The new editor also writes parentFilter: null (QM/design/design.store.ts:364, verified). Schema-v0 options (OptionInfo) cannot hold filters, and ParentFilter.Validate() has no caller, so any v1 filters stored today are unvalidated. Plan R1a's "absorbs the legacy editor's filtered-options authoring" and AC-R1a-06's parity were therefore empty. Applied: integrated plan R1a; AC-R1a-06 retired and replaced by AC-R1a-06r in acceptance criteria; T-RD-12; source and status inventory §1 item 19.
  2. The answered-question lock exists only in the UI. AnnotationQuestion.Update overwrites the wording, QuestionType, ControlType, Multiple, AnswerArray and options with no lock check (PAG/AnnotationQuestion.cs:217-238, verified). The Assign store says its lock "gates no edit" (QM/assign/assign.store.ts:226-229, verified). With the counts flag on, a loading or failed count shows Edit and Delete, because the node tests annotationCount === null (question-node.component.html:85-87, 135, verified). Applied: VM §3.1 and §15.1, where D2-03's "today's behaviour" is corrected; source-status §1 item 19 and §6; follow-up 1 (§10). RD-R39 proposes that the server enforce the lock in R1a's legacy API mode, refusing whatever the lock forbids (PROPOSAL, AC-R1a-15); the T-RD-12 brief confirms it. Canonical forms version instead of locking.
  3. The server already refuses edits that break child conditions. Project.ValidateReferencedChildConditions (PAG/Project.cs:533-591, verified), from #2697, refuses changing a referenced boolean parent's type and removing or renaming referenced options, keyed by value. H-TREE-01 read as if R2a introduced that rule. Applied: harvest map H-TREE-01; T-RD-12 (R1a's warning explains this refusal); AC-R1a-13; T-RD-02 (R2a re-keys it to option IDs, AC-R2a-24).
  4. The QM and AF2 flags are served at runtime by the API. newQuestionManagement is catalogued at API/RuntimeFeatureFlags/RuntimeFeatureFlagCatalog.cs:97 and the AF2 group at RuntimeFeatureFlagGroups.cs:29-31 (both verified); the browser takes the API's value. Preview's web-only newQuestionManagement: true has no effect, and "AF2 is on in staging" holds for the web values only. The effective staging value depends on a runtime override in staging that was not read. Applied: source-status §1 item 20 and §5; integrated plan §3.
  5. AF2 on main is not a scaffold. It is the production-grade candidate renderer (M-16). PR-D's scaffold is what the harvest map avoids. Applied: harvest map §1 and §6.3.
  6. Two Approved documents were missing from the conflict list. The extensibility architecture (M-05) is on main and Approved, not recovered, and its decisions 1 and 7 conflict with VM §3.4 and E37. FEAT-020 (M-01) presents the legacy model as the business logic. Applied: source-status §6; T-RD-01 and T-RD-10 amend them.
  7. AC-R1a-07 would restore a spec for dead code. hybrid-example is referenced nowhere; its spec is one of the 17 exclusions (angular.json:190, verified), and the count becomes 16 once surface R0.5 deletes HybridExampleComponent. Applied: AC-R1a-07; T-RD-12; harvest map §5.14.
  8. Four defects were unrecorded. Project.DeleteQuestion has no system-question guard (PAG/Project.cs:615-638); placement refusals throw InvalidOperationException, which production returns as a generic 500 (API/Program.cs:780-790, verified); copy skips placement validation; the reposition endpoint prints timings with Console.WriteLine (verified). Applied: source-status §7; §10; the generic 500 is fixed inside T-RD-12 (§10.1 item 3).
  9. The writer inventory and the conversion findings were incomplete. Reposition, copy, the tally refresh and the stage-question PUT also mutate legacy originals (M-27, M-10), beside edit and the delete cascade. Conversion should report stored v1 parent filters that name absent parent values, dangling conditions that predate M-26, and the 32 historical placement violations (M-02), all as findings, never refusals. Applied: T-BC-01; BC in the specifications pass.
  10. #3988's premise was wrong. It touches the Audit.SchemaVersion branches of the legacy question mapping, not Project.SystemQuestionVersion or E24 (X-12). Applied: integrated plan §8; DOM §15.2; PI §10.

4.3 Conflicts the inventory found, and their resolution

# Conflict Resolution Recorded in
C1 Presence placement: UX tied design presence to R1a and R2a; RD and the rollout plan put it in R2c R2c, because main's editor writes straight to the legacy model and has no draft record; rollout plan R-AMB-04 (a), PROPOSAL pending brief approval (X-06) Rollout plan §7.6; UX strategy §4.3; AC-R2c-34
C2 Legacy editor coexistence: the UX strategy kept the legacy editor for legacy projects; C17, plan R1a and the delivery operating model make the new editor the default entry C17 wins. 6 October 2026: DQ-01 decided one editor for both kinds of project, answering QMI-04 in part; the retirement timing stays open UX strategy §3.2; §9.4
C3 Assign: DH-C17 removes per-stage selection; H-WEB-09 composes forms with main's Assign Both hold: Assign has two modes, per-stage selection for classic projects and form composition for canonical ones Harvest map H-WEB-09; UX in the specifications pass
C4 RD-R26 and OS-A01 against the editor's direct, project-wide writes R2a reuses the UI and store structure only; every canonical write goes through design-draft changes T-RD-02
C5 ACD §3.4 and AC-R1a-08 against main: no DefinitionTemplate or catalogue storage; the copy records no provenance R1a needs the V2-16 storage decision before its legacy apply (ACD B5) T-AC-04; T-RD-11
C6 BC-R29, C16 and the BC fences against the legacy writers Each legacy writer (cascade, copy, reposition, stage-question PUT) is fenced or refused by R0 during a conversion window T-BC-01, T-BC-06

5. Dormant PRs

The harvest map holds every per-PR verdict, entry and closure note; this section only shows how they join the work on main. It places 131 entries from 13 open PRs: 6 Reuse, 41 Adapt, 35 Reference only and 49 Avoid, about 95 working days at a central estimate.

PRs Verdicts (harvest map §4) How they join main's work
QM v2 stack: #2572 (PR-A), #2573 (PR-B), #2574 (PR-C), #2575 (PR-D), umbrella #2461 PR-A 9 Adapt, 8 Reference only, 7 Avoid; PR-B 4, 4, 5; PR-C 8, 3, 11; PR-D 2, 9, 9; #2461 nothing harvested PR-A's composition validators are re-keyed and main's placement rules and corpus win (H-DOM-13 with M-02 and M-25). The system seed is checked against main's system questions (H-DOM-07 with M-24). PR-D's designer is a layout reference only, built inside main's editor (H-WEB-03, H-WEB-04 with M-09). PR-D's Assign is avoided because main's Assign becomes form composition (H-WEB-09 with M-10). PR-D's AF2 scaffold and presence code are superseded by main (H-WEB-13 with M-16; H-WEB-14 with M-21). Preview markers land in main's AF2-based preview (H-WEB-10 with M-11), and the post-publication alert is hosted in main's AF2 (H-WEB-11)
#3934 and #2781, question template import (G0-D12) #3934 mostly Reuse and Adapt into R1a; #2781's fixture and test cases adapted, its uploader avoided The dialog moves into the new editor's toolbar (H-IMP-05 with M-09); the legacy adapter joins R0's writer inventory beside M-27 (H-IMP-03)
#2387, child-question checks and assign tree (G0-D12) 2 Adapt, 1 Reference only, 5 Avoid The child-validity rule joins the server guard that already exists (H-TREE-01 with M-26); the signal-utility tests join main's signal.utils (H-TREE-07)
#2986, #2987, #2629, #2812 (G0-D6, G0-D7) Fixtures, rule codes and the response-mode contract adapted; the rest reference or avoid #2986's fixtures and codes join E23 with AF2's semantics fixtures (H-VAL-03 with M-17); #2812's response contract joins C4 and E37 with M-05's amendments (H-VAL-12, H-VAL-13)
#2224, custom project groups (G0-D5) Harvested into R1b and R1c Not question management

Closures: Chris answered G0-D5, G0-D6 and G0-D12 on 5 October 2026; G0-D4 and G0-D7 are unanswered. A PR closes only after its harvest slice merges, G0 passes and the hold is lifted. Nothing closes now.

6. Release path

Every release below waits for T-HOLD, T-G0 and its own brief and gate. Rows are in the implementation tracker; criteria in the acceptance criteria; the order in the rollout plan.

6.1 Before R1a: M0 and R0

  • What users get. Nothing visible.
  • Builds on. The harvest map and §4: M0's report records the harvest-and-avoid set and the merged work on main (M-01, M-04, M-05 pointers). R0 lists every legacy question writer in its inventory and refuses legacy question writes on canonical scopes (M-23, M-27, M-28, M-10), using IAggregateWriteGuard (M-31).
  • Rows. T-RD-10, T-RD-13, T-BC-01, T-BC-06.
  • Acceptance. AC-M0-03 (the legacy question writers and both document shapes), AC-M0-04; AC-R0-08.
  • Other plans. R0's consumer guards and any new PM handlers are written host-neutral under ADR-021 (X-17). Persistence PR-6 fixes the cascade's missing version bump first (X-15).

6.2 R1a: the hardened editor, import and the catalogue

  • What users get. The new editor on the legacy API with pointer and keyboard reordering, its specs back in CI, no debug output and zoneless-safe components; filtered-options authoring for schema-v1 projects with server validation and an explained refusal on schema-v0 projects; a warning that explains the server's child-condition refusal; template import with a preview equal to the result and a receipt; catalogue browse and copy (D2-15). The new editor becomes the default entry for every project: one editor for Classic and converted projects is decided (DQ-01, 6 October 2026), and in legacy API mode it shows no versions, drafts or publication.
  • Builds on. M-08, M-09, M-13, M-14, M-22, M-26, M-27, M-32; H-IMP-01 to H-IMP-09, H-IMP-12, H-TREE-01, H-TREE-02, H-TREE-07, H-WEB-18, H-DOM-24.
  • Rows. T-RD-11, T-RD-12, T-AC-04, then T-RD-16 for the closures.
  • Lookup rows (6 October 2026, PROPOSAL). R1a's import refuses lookup rows with a named reason until C1 (ACD-R41, CPR-R22); designers create reference questions only from C1.
  • Acceptance. AC-R1a-01 to AC-R1a-05, AC-R1a-06r, AC-R1a-07, AC-R1a-08, AC-R1a-10r, AC-R1a-12, AC-R1a-13, AC-R1a-15, AC-R1a-CONF (with C4-T21, C4-T22 and C17-T07).
  • Other plans. T-RD-12 lands after the frontend bug plan's PR-1 (the debugger; line), PR-2 (lint) and PR-8 (question write effects) and after surface R0.5, and before the state plan's R3.4 (X-08, X-27, X-28, X-11). The #3934 re-cut follows STJ's dual attributes and goldens (X-21), adds a golden per filter shape (X-22), enters the flag consumer manifest (X-40) and moves its embedded resource with the reader (X-29). G0-X9 places R1a-4 to R1a-6 under a gate.

6.3 R1a follow-on: retiring the legacy designer (T-RD-17)

  • What users get. One question editor. No route reaches the legacy designer or stage question selection; newQuestionManagement is retired; the user guide describes one editor.
  • Builds on. M-08, M-15, M-32; H-WEB-15 (the flag is never reused).
  • Rows. T-RD-17.
  • Acceptance. AC-R1a-14 (confirmed, pending-QMI-04: one editor is decided by DQ-01; the retirement timing still waits on QMI-04).
  • Entry. The F1c default-entry slice plus one staging soak (the recommendation; QMI-04's timing part is not answered). At the latest R7.
  • Other plans. The flag administration plan points newQuestionManagement at this row (§8).

6.4 R1b and R1c

  • What users get. No question-management screen changes. R1c's group grants decide who holds Design and Publish (C10). The catalogue administrator role is an application role that curates the catalogue only; copying into a project needs project Design (X-43).
  • Rows. T-AC-10, T-AC-11 (not question management).

6.5 F1a: definitions and contracts

  • What users get. Nothing visible; the contracts freeze.
  • Builds on. C4 with one composition rule-code namespace (FL, NQ, CPA, AQ) and the corpus and fixtures as an FX set (M-02, M-03); answer labels as version content (M-20); system seed parity against PAG/AnnotationQuestion.cs:396-592 (M-24); AF2's semantics fixtures in the E23 corpus (M-17); M-05's amendments; harvest map §5.2. 6 October 2026: the E37 payload contract also fixes the payload as a value (including "Other, please specify" with its text), a reason no value is provided or an explicit Unanswered marker, noValueReasonId (PROPOSAL; it replaces noValueAnswerId, DQ-46), the closed metadata field types and their per-state setting, and settles V-D3 (RD-R50, RD-R52, RD-R53; PROPOSAL where marked).
  • Rows. T-RD-01, T-BC-01, T-RD-14, T-RD-15.
  • Acceptance. AC-R2a-23 and AC-R2a-24 (fixtures); RD-AE29.
  • Other plans. X-ARCH-a: persistence PR-5 and PR-6 merged and switched on where canonical commits run, or canonical repositories carry their own architecture test (X-14); #3973. The answer payload is named apart from main's RoB-AI AnnotationAnswer, with an STJ custom discriminator converter, exact decimals and digests over explicit projections (X-20, X-23). E47 is built on persistence PR-10's outbox or the C19 ADR records why not (X-16). The P9 classes are recorded (QMI-02). Claim schema v2's presence-snapshot fields are agreed with realtime R1.3b (X-07).

6.6 F1c: the AF2 seams

  • What users get. Nothing visible; the seams are merged as code.
  • Builds on. M-06, M-16: the AF2 extension points and VersionedAnnotationFormDataSource (C17, E44); the copy deck (T-UX-02); the default-entry mode selection (C17).
  • Rows. T-UX-10, T-UX-02.
  • Acceptance. The exit is AC-R2a-38 with the integrated plan's R2a acceptance item 13 (a session pinned to v1 renders v1 through the versioned data source; no AF1 fallback); C17-T04 checks that the seams exist as merged code. The research notes cited "AC-R2a-13" for this seam; that ID is the support edit-mode criterion, not AF2.
  • Other plans. The AF2 owner agrees the seams; the stage-review layouts contract is amended at F1c (X-48).

6.7 R2a: the canonical editor and versioned forms

  • What users get. On admitted projects, the same editor in a canonical mode: single-editor design drafts with base checks and attributed changes (OS-A01, first part); form composition with ancestors added automatically (M-10); "duplicate" with provenance (M-29); composition validation including placement and child conditions re-keyed to option IDs (M-25, M-26); a preview of the pinned form version (M-11); system questions from the global seed (M-24); the canonical import adapter writing drafts. 6 October 2026: the editor offers reasons no value is provided and the metadata grid per question; form composition makes a new question Required by default, with Optional under advanced settings and its warning; the reviewer form offers an action that opens the reasons ("No value to enter", illustrative wording), asks for required metadata (for example a comment for Unable to assess), records "Other, please specify" with its text as a value, blocks Complete until every applicable required question has an answer, and lets the reviewer clear an answer back to unanswered (RD §3.16; DQ-46). Accepted field changes in the canonical editor save automatically into the unpublished design draft (DQ-03).
  • Builds on. M-09, M-10, M-11, M-16, M-17, M-19, M-24, M-25, M-26, M-29; harvest map §5.7 and H-IMP-02, H-IMP-03, H-IMP-06.
  • Rows. T-RD-02, T-UX-03, consuming T-UX-10.
  • Acceptance. AC-R2a-10, AC-R2a-14, AC-R2a-23, AC-R2a-24, AC-R2a-38, AC-R2a-58 to AC-R2a-61, AC-R2a-62 to AC-R2a-67 (6 October 2026), C17-T07, C5-T13, and the plan's R2a acceptance items 11, 13 and 14.
  • Other plans. Canonical DTOs after STJ R1 (join X-STJ); canonical web stores born to the state plan's R0.3 ADR (X-08, X-09); canonical enrolment requires the AF2 reviewer workspace group (X-34); writers call only the statistics seam interfaces (X-25); the backend bug plan's PR-10 reads the target through one effective-target seam (X-26).

6.8 F2: the publication contract

  • What users get. Nothing visible; the publication contract freezes.
  • Builds on. Harvest map §5.8; RD §3.15, §4.8.
  • Rows. T-RD-04.
  • Acceptance. RD-AE16, RD-AE26.
  • Other plans. The operation driver and watchdog are host-neutral: a lease scan, generation guards, no scheduled-message cancel, no IJobConsumer, Fault<T> or interface initialisers (X-17). The P9 class follows QMI-02.

6.9 R2c: publication with impact and collaborative drafts

  • What users get. Publication with an impact preview, compatibility declarations, option mapping, generated versions and in-form alerts; target-only publications; collaborative drafts with presence and live updates, saved automatically with a save status and per-question discard (DQ-03); history with a diff; one publication per form.
  • Builds on. M-09, M-11, M-12 (the counts as usage evidence), M-21; harvest map §5.9.
  • Rows. T-RD-05, T-UX-06, T-RI-04, T-AC-09.
  • Acceptance. AC-R2c-01 to AC-R2c-38, notably AC-R2c-14, AC-R2c-16, AC-R2c-27, AC-R2c-34, AC-R2c-35 and AC-R2c-36 to AC-R2c-38.
  • Other plans. Presence and live updates use the realtime v2 hub (X-02, X-04, X-05) and need the join X-RT; if v2 is late, R2c ships with base checks only and presence behind its flag, off (PROPOSAL, X-06). QMI-01 decides the cross-pod path and QMI-03 the statistics path for pilots. The frontend bug plan's PR-3 (#3976) lands first. Production enablement stays outside ADR-021's S3 and S4 windows (X-18).

6.10 R2d: overlapping forms and correction

  • What users get. Overlapping forms, Fix, FV4 generations, guided correction, the configurable outdated-answer mode, and D2-09's revision of shared accepted answers.
  • Rows. T-RD-06, T-RS-05.
  • Acceptance. AC-R2d-01 to AC-R2d-15r; AC-R4a-43 for the D2-09 shape.
  • Other plans. None beyond R2c's.

6.11 Conversion: staging trials, pilots and R6

  • What users get. Every legacy project's questions as version 1, with conditions and filters kept, findings for anything that cannot map, and system questions pinned.
  • Builds on. M-01, M-02, M-07, M-20, M-23, M-24, M-30; harvest map §5.10.
  • 6 October 2026. Converted forms keep each legacy question's Optional flag (BC-R49); legacy records with no value become Unanswered legacy revisions; label annotations and lookups convert under CPR §10.3 (T-CP-08). The later redesign wizard offers to upgrade optional questions (T-BC-10).
  • Rows. T-BC-01, T-BC-03, T-BC-06, T-BC-07, T-BC-08; T-CP-08 (6 October 2026).
  • Acceptance. BC-AE rows (BC-AE31 to BC-AE34 and BC-AE36 for questions; BC-AE35 for recovery naming the live scheduler store); the AC-R6 rows, notably AC-R6-04 and AC-R6-34.
  • Other plans. The inventory follows the surface plan's R5.0 census and plans for both v0 and v1 shapes unless surface R5 lands first (X-12, QMI-05). Waves avoid ADR-021's S4 window, and BC recovery step 5 names whichever scheduler store is live (X-17, X-18).

6.12 R7: retirement

  • What happens. The legacy writers retire: the embedded model's CRUD endpoints, the delete cascade, stage question sets, the tally, AF1, the NgRx question state and ADR-011's write path (M-07, M-10, M-12, M-18, M-19, M-23, M-27, M-28). T-RD-17 retires the legacy designer at the latest here.
  • Rows. T-BC-09, T-RD-17.
  • Acceptance. AC-R7-01 to AC-R7-03.
  • Other plans. Realtime R3.1 (v1 retirement) is independent of R7 but must not precede R2c's presence slice moving to v2.

7. Alignment with this week's plans

7.1 Plans read

The architecture review merged as #3961 (4d7807ec5, 5 October 2026, 01:54 BST). Its follow-up plans did not mention this programme, and the package's architecture rows predated the merge. The plans read were: the architecture review synthesis; ADR-021 (In-Review; v9 rejected on 3 October; Wolverine with one coordinated switch-over chosen on 4 October; target Q3 2027, PROPOSAL); the realtime server and realtime client plans; the state-management convergence plan; the surface-area reduction plan; the frontend and backend bug-fix plans; the persistence and messaging plan; the System.Text.Json migration plan; the build and CI plan; the statistics decision brief; and the AF2, Material 3, Study Management, flag, authority-transition and 2 to 3 October documents named in §8.

7.2 Interactions

Types: Dep dependency, Conf conflict, Ovl overlap, Seq sequencing, Opp reuse opportunity. "Where recorded" names the package section that carries the resolution. Rows that point at a specification, contract, consistency-model, domain-model or handoff section name where the change belongs; those documents are edited in the same change set by the specifications pass, and QMP-09 checks that they landed.

ID Plan Type Effect on question management Resolution Where recorded
X-01 Architecture review synthesis; ADR-021 Seq The package treated #3961 as a draft and X-ARCH-b as "#3986 decision"; the follow-up plans were absent Rows refreshed: #3961 merged; X-ARCH-b restated as ADR-021 with host-neutral guards and handlers; one row per follow-up plan Integrated plan §3, §5.11, §8; DOM §15; PI §10, §12
X-02 Realtime server §5 (hub contract v2) Dep, Conf Design presence was placed "on the existing hub" in a "group"; v2 uses topics, not groups Additive v2 items: SubscribeDesign, DesignPresenceChanged, DesignDraftChanged, topic design:{scope}; a client design group and channel RD §3.7, §4.7; UX §3.8; H-WEB-14; T-UX-06; §8
X-03 Realtime server backplane row and D4 Conf Presence held in one pod's connection state misses users on the other pods Owner question §9.1 (QMI-01); T-OI-02; RD §3.7 (PROPOSAL)
X-04 Realtime server §3, §4.1, §4.5 Opp A notify-then-fetch pipeline already exists ChangeFeedReader<DesignDraft> projecting {_id, scope, draftRevision}; hints never carry correctness RD §4.7; consistency model (C19 class c); §8
X-05 Realtime client §3.1; frontend PR-3 (#3976) Dep Presence and live updates fail silently without re-subscription "Live updates paused" maps to the client connection status; the page reloads the draft head on ResyncRequired or a new connection AC-R2c-34; UX §8; T-UX-06
X-06 Realtime server R1.3b, R2, R3.1 Seq, Conf Presence in R1a would sit on the v1 legacy editor that R3.1 deletes Close R-AMB-04 as (a); presence in R2c with the join X-RT; if v2 is late, presence ships flagged off Rollout plan §7.6 (PROPOSAL); AC-R2c-34; UX §10; §9.6
X-07 Realtime server R1.3a, R1.3b; DOM §11.1 Conf (risk) Claim v2 could change the presence snapshot type; "claim contract v2" collides with "hub contract v2" Project claim schema v2 additively into the snapshot before R1.3b pins it; R2b changes go into ReviewSessionCommands; rename to "claim schema v2" DOM §11.1; T-RD-03; §8; the package-wide rename is a later consistency pass
X-08 State plan R3.4, D4 Ovl, Seq R3.4 rewrites what T-RD-12 hardens and what R2a extends T-RD-12 first, then R3.4 (legacy only), then R2a's canonical stores born to the R0.3 ADR Rollout plan §4, §6; T-RD-12; §9.6; §8
X-09 State plan R5, rule 3 Opp The rules describe RD §4.7's client Signal forms per item, one debounce stream per item, no ngrx-forms; cited in the R2a brief T-RD-02
X-10 State plan R4 Seq The AF2 store split is the AF2 owner's call Aligned: #3989 only as stream C seam slices No change (DOM §11.3)
X-11 Surface R0.5 Ovl Deletes HybridExampleComponent, one of the 17 excluded specs 16 once R0.5 lands; R0.5 removes the angular.json line Harvest map §5.14; T-RD-12; AC-R1a-07
X-12 Surface S1, R5, D4 Conf (premise) The package said #3988 reaches E24 through SystemQuestionVersion Premise corrected; D4 rows proposed §9.5 (QMI-05); integrated plan §8; DOM §15.2; PI §10; T-BC-01
X-13 Surface R4.5; ADR-021 I10 Opp New messages would add to the migration debt Programme messages are concrete primitive records in PM.Contracts with STJ round-trip tests §8; F1a dependencies (§6.5)
X-14 Persistence PR-5, PR-6 (flags off) Dep Merged with the switch off gives canonical commits nothing X-ARCH-a is met when merged and switched on where canonical commits run; canonical repositories keep their own architecture test Integrated plan §5.11; PI §12
X-15 Persistence PR-6, criterion 6.1 Ovl The question-delete cascade is touched twice PR-6 first; R0's guard composes with it; T-BC-01 cites PR-6 T-BC-01; §10.2
X-16 Persistence PR-10 Ovl Two outbox stores from one template One durable-intent mechanism, or the C19 ADR records why not §9.7; consistency model; T-RD-01
X-17 ADR-021 §4, §1.1; S5 Dep The operation wording assumes MassTransit and Quartz Host-neutral driver and watchdog; BC step 5 names the live scheduler store RD §3.8; consistency model §7.2; BC §4.14; T-RD-04, T-BC-02; harvest map H-SVC-04, H-SVC-11, H-API-08
X-18 ADR-021 S2.10, S3, S4 Seq A drain empties queues but not Mongo-leased operations Runbooks quiesce programme operations; no R2c or R6 production step inside S3 or S4 Rollout plan §10; T-RD-05, T-BC-07, T-BC-08; §8
X-19 ADR-021 S0.10 Dep, Opp R2b moves the session timers R2b reuses S0.10's generation guard and never relies on a broker cancel T-RD-03
X-20 STJ §1.2, D2, D4 Conf (naming, wire) The payload name collides with RoB-AI AnnotationAnswer; [JsonPolymorphic] is banned until STJ R4 A distinct name (for example AnswerValue), an explicit kind with a custom converter, exact decimals, round-trip goldens RD (PROPOSAL); domain model; harvest map H-DOM-02; T-RD-01
X-21 STJ §12; C2 Seq STJ's coordination table omits the programme Programme rows in STJ §12; dual attributes and goldens in the #3934 re-cut; canonical DTOs STJ-first §8; T-RD-11; join X-STJ
X-22 STJ B1, PR-1.1 Conf (risk) Both edit the legacy question wire The claim step; whichever lands second updates golden 1.1.2; a golden per new filter shape T-RD-12; AC-R1a-06r
X-23 STJ D6, 0.1.5, 0.1.6 Opp Serializer-dependent digests are fragile Canonical digests over explicit versioned projections with a length-prefixed encoding T-RD-01
X-24 Statistics brief D1 Conf "No new scope" blocks the E72 families and canonical QuestionAnswers Owner question §9.3 (QMI-03); T-RD-05, T-RI-04
X-25 Statistics R2 Opp, Seq An assembly split during R2a would move the seam types Canonical writers reference only the seam interfaces T-RD-02
X-26 Backend PR-10 (#3979) Dep The target source changes for canonical stages One effective-target seam; R2a supplies the form version's target §8; T-RD-02
X-27 Frontend B15, PR-1; PR-2 Ovl A debugger; line in the drag-drop file that T-RD-12 rewrites PR-1 and PR-2 land first; T-RD-12 rebases and its restored specs pass lint T-RD-12; §10.2
X-28 Frontend B9, PR-8; B11, PR-10 Ovl Real defects in the legacy editor's write path Kept in the bug plan; T-RD-12 adds a double-submit regression spec; R3.4 later replaces the effects T-RD-12; §10.2
X-29 Build PR-12 to PR-17 Seq #3934 embeds a resource in the API project; DOM cited #3983 as an issue The reader moves with its resource; DOM's #3983 row points at build PR-12 to PR-15; new packages in Directory.Packages.props; regenerate after PR-16 Harvest map H-IMP-01; DOM §15.2; T-RD-11
X-30 AF2 README Conf (drift) Stage-owned question sets are still described Those sections marked superseded by RD and C4 §8; T-UX-10
X-31 AF2 STATUS slice 3A Opp Two lists of renderable features would drift One AF2 capability registry for publication renderability and import refusals RD §3.5; T-UX-10, T-RD-11
X-32 AF2 remaining-delivery 5A; comment contract Dep Entity order and comments must survive versioning Key 5A on C2 instance identity, stored outside session versions §8; T-RD-02
X-33 AF2 README category guidance Ovl RD's "guidance text" reads as conflicting with A-15 RD §3.5 cross-references A-15; BC maps category guidance to entity types RD §3.5; BC mapping
X-34 Flag administration; flag overhaul P7 Dep Canonical enrolment means nothing without AF2 on Enrolment requires the reviewer workspace group; P7 targeting keys on CanonicalEnrolment Rollout plan §6; T-RD-02
X-35 M3 technical plan, ledger row 81 Conf (dead wait) It waits on #2812, which will never merge Drop #2812 once G0-D7 is answered §9.6; §8
X-36 M3 waves 2 to 4 Ovl Two restyles of the same legacy screens T-UX-07 consumes the M3 waves; T-RD-12 touches no theme file T-UX-07
X-37 M3 job contract; Study Management status presenter Opp A ready-made status language Publication and conversion progress use the M3 job contract and a shared status chip UX §3.9; T-UX-06
X-38 M3 navigation plan, setup checklist Dep "Assign questions to a stage" has no canonical meaning Canonical variants under C17: "Compose a form", "Publish the form version", "Bind it to a stage" §8
X-39 Flag administration README:191 Conf (pending) newQuestionManagement waits on a product decision Owner question. 6 October 2026: answered in part (DQ-01, one editor for every project); the retirement timing is open §9.4 (QMI-04); T-RD-17; integrated plan R1a
X-40 Flag overhaul P1; catalog inventory Dep No flag decisions for import, the catalogue, design presence or publication Rollout plan §9 rows Rollout plan §9; §8
X-41 Queued-work ledger P9 Conf Phase 2 writes evidence but cannot roll back once the form head is committed Owner question §9.2 (QMI-02); T-RD-04; RD §3.8
X-42 Authority design; broker contract B1 Dep New job families and endpoints must meet these rules DelegatedWorkBinding with recheck for phase 1, catalogue copy and import apply; presence checked at subscribe and revocation-driven; scheduled destinations join the B1 regex RD §6; T-RD-04, T-RD-05, T-RD-11, T-AC-04
X-43 Application-claim consumer ledger Dep The catalogue administrator's limits were unstated ACD §3.4 cites the ledger; the role curates only ACD §3.4; T-AC-04
X-44 Permission matrix L71, L72 Conf (light) Blinding moved into the form version; no target-override row C10 notes it; the matrix gets a status note; the RD brief decides the target-override grant §9.6; §8
X-45 Guided-setup plan; FEAT-014 Ovl Two template aggregates for one job FEAT-014 superseded for question and form templates, or re-scoped to seeding through catalogue items ACD §3.4; domain model; §8; T-AC-04
X-46 Lifecycle and gold proposal L78 to L82 Conf (ambiguity) Q-04 dropped the project default without saying so RS §12 records that the project default is dropped §9.6; RS §12
X-47 Stage-step handoff; export investigation Conf (terminology) "Question-set versions" still appear in inputs agents read Status notes; a glossary entry "question set → form version" §8
X-48 Stage-review layouts contract Dep Already planned No change: the F1c amendment covers the new panels None needed
X-49 Architecture review appendix (SystemQuestionCreators mutable) Opp The seed parity source can change at runtime The parity slice reads a frozen copy; a hygiene PR makes the field read-only Harvest map §5.14; §10.2; T-RD-01

7.3 Sequencing implications

  1. Now, outside the hold, owned by the architecture-review session. These ship first and the programme rebases onto them: frontend PR-1, PR-2, PR-3 (#3976) and PR-8; persistence PR-1, PR-4, PR-5 with #3973, and PR-6; surface R0.5; STJ PR-0.1, PR-0.2 and PR-1.1; ADR-021 P1 and S0's generation guards. This plan neither schedules nor approves them.
  2. Before F1a freezes. X-ARCH-a met (merged and switched on in staging, or canonical architecture tests); E47 aligned with persistence PR-10 (X-16); the payload name and STJ converter rule (X-20); claim schema v2's presence-snapshot projection agreed with realtime R1.3b (X-07); the P9 classes recorded (QMI-02).
  3. R0 and R1a. R0's consumer guards host-neutral (X-17). T-RD-12 after frontend PR-1 and PR-8 and surface R0.5, and before state R3.4 (X-08). The T-RD-11 re-cut after STJ's dual attributes and the flag manifest (X-21, X-40). QMI-04's retirement timing settled in the R1a brief (its first part is decided, DQ-01). T-BC-01's inventory after the surface R5.0 census and persistence PR-6 (X-12, X-15).
  4. R2a. Canonical DTOs after STJ R1 (X-STJ); canonical web stores born to the state plan's R0.3 ADR; canonical enrolment requires the AF2 reviewer workspace group (X-34); writers use statistics seam interfaces only (X-25).
  5. R2b. Realtime R1.3a (ReviewSessionCommands) first; timers follow ADR-021 S0.10 (X-19).
  6. R2c. X-RT (STJ PR-2.1, realtime R1.3b, R2.1 and R2.2 in staging) for presence, otherwise presence ships flagged off and base checks still protect drafts; QMI-01 and QMI-03 answered; production enablement outside ADR-021's S3 and S4 windows (about July and August 2027, PROPOSAL in ADR-021).
  7. R6 and R7. Conversion waves avoid the S4 window; BC recovery names the live scheduler store; realtime R3.1 must not precede R2c's presence slice moving to v2.

8. Changes proposed to other plans

These documents belong to other sessions or programmes and are not edited by this change set. Each row is a proposal for the owner or that session to apply.

Document Proposed change From
Realtime server plan §5 reserves additive programme topics (design) with SubscribeDesign, DesignPresenceChanged and DesignDraftChanged; §8 adds a programme row; the D4 revisit note cites QMI-01; R1.3b agrees claim schema v2's snapshot fields (optional formId, kind, routeStep) before pinning them X-02, X-03, X-04, X-07
Realtime client plan §3.1 adds the design group and DesignPresenceChannel to the registry plan; §11 adds a programme row X-02, X-05
State-management convergence plan R3.4 excludes canonical stores and runs after T-RD-12; D4 adds the question-management editor X-08, X-09
Surface-area reduction plan R0.5 notes the angular.json exclusion line and T-RD-12; D4 adds AnnotationQuestion, Stage and Target rows collapsing to v0 after the R5.0 census (QMI-05); §8 adds this programme (#3934 re-cut, canonical collections) X-11, X-12, X-13
Persistence and messaging plan PR-6 notes the T-BC-01 dependency; PR-10 notes E47's reuse of its outbox X-14, X-15, X-16
ADR-021 S0 characterises programme operations if they exist by then; the S2.10 and S4 runbooks quiesce programme operations (stop new publications and conversions, let phase 2 finish or stall, resume by lease takeover); S0.10 is named as the R2b timer pattern; no R2c or R6 production step inside S3 or S4 X-17, X-18, X-19
System.Text.Json migration plan §12 adds the programme rows (#3934 re-cut, canonical DTOs, E72 digests); B1's golden 1.1.2 coordinates with R1a-5 through the claim step X-20 to X-23
Build and CI plan §8 adds the programme (S0-1's new projects; the #3934 reader's move with its embedded resource) X-29
Statistics decision brief D1 states either the E72 and canonical QuestionAnswers carve-out or the Q-31(b) path for R2c pilots (QMI-03) X-24, X-25
Backend bug-fix plan PR-10 reads the target through one effective-target seam that R2a can supply X-26
Frontend bug-fix plan No change; a coordination note that T-RD-12 rebases onto PR-1, PR-2 and PR-8 and adds a double-submit regression spec X-27, X-28
AF2 documents (README, STATUS, remaining delivery) README sections on versioned questions marked superseded by RD and C4; one capability registry for renderability; remaining-delivery 5A keyed on C2 instance identity X-30 to X-33
Material 3 (technical plan, navigation plan) Technical plan row 81 drops #2812 once G0-D7 is answered; the navigation plan's checklist gains the canonical variants X-35, X-36, X-38
Flags (administration, overhaul) The administration README points newQuestionManagement at QMI-04 and T-RD-17; the overhaul catalogue adds annotationQuestionImport with the #3934 re-cut; design presence requires realtimeHubV2 and realtimeClientV2 X-34, X-39, X-40
Queued-work ledger P9 rows for publication phase 1 and phase 2, baseline conversion, merge and unmerge staging, and stage pool sweeps, as Chris decides (QMI-02) X-41
Authority transition (design, broker contract, claim ledger) Note the new job families (publication phase 1, catalogue copy, import apply) and the presence subscription; scheduled destinations join the B1 regex; a catalogue administrator entry in the claim ledger X-42, X-43
FEAT-014 project templates A status note: superseded for question and form templates by the catalogue, or re-scoped to seeding through catalogue items (Chris may re-scope) X-45
2 to 3 October inputs (permission matrix, lifecycle and gold, stage-step handoff, export investigation, stage-step access policy) Status notes pointing at this package; the access-policy note SP §13 already asks for; the matrix notes blinding in the form version and the pending target-override grant X-44, X-46, X-47
Stage-review layouts contract No change; the F1c amendment already covers the new panels X-48

Documents on main that the programme amends later. These are not plans; their amendments ride in the programme's own PRs once the hold lifts: FEAT-020 gets a "describes the legacy model" banner (M-01, T-RD-10); FEAT-003, FEAT-001 and the QM v2 user-guide drafts are marked Superseded (M-04, T-RD-10); the extensibility architecture's decisions 1 and 7 and its status pointers are amended (M-05, T-RD-01, T-RD-10); the live user guide changes with the default entry and the canonical mode (M-08, T-RD-12, T-RD-17).

9. Owner questions

These five are outside the 89 repository decisions. Tracker row T-OI-02 groups them, and the owner-session integration §7 lists them as remaining inputs. Each can be answered independently. 6 October 2026: QMI-04 is answered in part (§9.4); the other four are open.

9.1 QMI-01: how design presence reaches users on other API pods (X-03)

  • Context. OS-A01 asks for design-page presence and live draft updates. RD §3.7 kept presence in connection state on the existing hub. Production runs 3 to 10 API pods with no SignalR backplane (realtime server plan, backplane row and D4). Study presence works because it is stored on the Study and every pod reads it from change streams. Presence held in one pod's connection state reaches only users connected to that pod.
  • Options.
  • (a) An ephemeral, TTL-bounded presence record (for example pmDesignPresence, refreshed by heartbeat, never an audit record), read by a realtime v2 change-feed reader and pushed on the design:{scope} topic.
  • (b) Per-pod fan-out through the message bus, as ProjectStatisticsChanged does.
  • © A Valkey backplane, which is D4's revisit trigger and a new hot-path dependency.
  • Recommendation. (a). It fits v2's notify-then-fetch model, keeps D4 (no backplane) intact and matches the owner's words: "presence is not a substitute for an audit record". RD §3.7's wording changes to "not an audit record; TTL-bounded" (PROPOSAL).
  • What it blocks. R2c's presence slice (T-RD-05, T-UX-06) and the collaborative-drafts part of F2's freeze. It does not block R2a's single-editor drafts.
  • Needed by. F2.

9.2 QMI-02: the P9 class of the new operation kinds (X-41)

  • Context. The queued-work ledger's P9 rule (Chris, 2 October 2026): data-changing jobs are atomic and roll back; tidy-up and consistency jobs finish; obligations exist only by approval. Publication phase 2 writes generated versions and cannot roll back once phase 1 has committed the form head (RD §3.8, §4.8).
  • Options.
  • (a) Phase 1 delegated and atomic, rechecking the publisher; phase 2 an approved system obligation that runs to completion, like screening-inclusion-consistency.v1; baseline conversion atomic, with routing rollback before the first canonical write.
  • (b) Phase 2 as a data-changing job that must roll back, which would mean deleting generated versions and contradicts RD-R23's history rules.
  • Recommendation. (a). Merge and unmerge staging (DM) and stage pool sweeps (C20) are to be classed the same way; Chris owns every family and adds the rows to the P9 table.
  • What it blocks. F1a's records of the P9 classes; F2 (T-RD-04); the conversion operation's class (T-BC-06, T-BC-07).
  • Needed by. F1a.

9.3 QMI-03: statistics scope for canonical projects (X-24)

  • Context. The statistics decision brief's D1 narrows activation: "no new scope" for the other families until the production pilot is accepted, with a review 8 weeks after. The package's D1-03 activates the families this plan uses; E72 adds the canonical families (FormVersionUsage, QuestionVersionAnswers), and R2c's preview reads usage evidence at the protected boundary (RD §4.8 step 1).
  • Options.
  • (a) Carve E72 and canonical QuestionAnswers out as programme scope (dark, staging, parity-audited) before GA.
  • (b) Serve R2c pilots by Q-31(b) authoritative counting at the protected boundary until the families activate.
  • © Wait for the brief's 8-week review.
  • Recommendation. (b) for R2c pilots; then (a) before GA, or activation at the 8-week review.
  • What it blocks. R2c's staging pilot (X-STATS-a) and production pilots (T-RD-05, T-RI-04).
  • Needed by. R2c's staging pilot.

9.4 QMI-04: the default editor and retiring the legacy designer (X-39, M-08)

  • Context. Two editors coexist and every default entry leads to the legacy designer. newQuestionManagement only hides the new editor's navigation link. The flag administration README keeps the flag "pending product decision". Plan R1a already proposes the new editor as the default entry once C17 defines its two modes; the UX strategy said legacy projects keep the legacy editor.
  • Options.
  • (a) The new editor becomes the default entry for every project (legacy API mode for legacy projects). The legacy designer, stage question selection and newQuestionManagement retire after R1a acceptance plus one staging soak (T-RD-17). The flag is never reused (H-WEB-15).
  • (b) Keep the legacy designer for legacy projects until R7.
  • Recommendation. (a). Two editors on the legacy API double the writer inventory and the test exclusions, the legacy dialog already loses filtered options, and the new editor is the one being maintained.
  • What it blocks. The F1c default-entry slice, T-RD-17, AC-R1a-14 and the user-guide update.
  • Needed by. The R1a brief.
  • Answered in part (Chris, 6 October 2026, DQ-01; decision register §1.18). "Approved, option (a): one editor with mode-appropriate capabilities. This does not silently introduce versioned publication, draft or assignment semantics into unconverted projects." The same refreshed editor therefore serves every project, Classic and converted, with the saving and assignment behaviour of its mode. The record does not address the retirement timing of the legacy designer, stage question selection and newQuestionManagement: option (a)'s "after R1a acceptance plus one staging soak" (and at the latest R7) stays the recommendation and is settled in the R1a brief. T-OI-02 records the partial answer; AC-R1a-14 is confirmed, pending-QMI-04.

9.5 QMI-05: v0 and v1 per type in the surface-area plan (X-12)

  • Context. The surface-area plan's D4 decides, per type, whether Audit.SchemaVersion branches collapse. It has no AnnotationQuestion, Stage or Target row, although AnnotationQuestion branches on Audit.SchemaVersion (AnnotationQuestion.cs:153-185, 262-271, 321-329). The package said #3988 reaches E24 through SystemQuestionVersion; it does not (AnnotationQuestion.cs:561-578 branches on Project.SystemQuestionVersion, which #3988 does not touch).
  • Proposal to the architecture-review plan (recorded, not decided here). D4 adds AnnotationQuestion, Stage and Target, each collapsing to v0 after the R5.0 census, so conversion reads one shape. The package's premise is corrected in this change set (integrated plan §8, DOM §15.2, PI §10).
  • Options. (a) Add the three rows. (b) Leave them out, and conversion handles both shapes indefinitely.
  • Recommendation. (a).
  • What it blocks. Nothing directly. Until it is answered, T-BC-01 plans for both shapes.
  • Owner. The architecture-review session decides D4, with Chris.

9.6 Brief-level confirmations

ID Confirmation Recommendation Brief
X-06 Close rollout plan R-AMB-04 (a), with the join X-RT; presence in R2c, its budget set at F2 T-RD-00, T-UX-00
X-08 Who migrates the question-management editor's state T-RD-12 first, then state R3.4 (legacy only), then R2a's canonical stores; add the editor to state-plan D4 T-RD-00 with the state-plan owner
X-35 The M3 ledger's wait on #2812 Drop it once G0-D7 is answered T-UX-00
X-44 The target-override grant missing from the permission matrix Decide in the RD brief (RD §6 proposes Publish or a separate adjust-targets grant) T-RD-00
X-46 The project-level gold completeness default Dropped by Q-04; RS §12 records it T-RS-00

9.7 Engineering decision

X-16: one durable-intent store. E47 builds its class (b) intents on persistence PR-10's IDomainEventOutbox and IDomainEventSink, or the C19 ADR records why the two stores stay separate. This is decided with the persistence plan's D3, with Chris aware. Brief: T-RD-01.

10. Follow-ups outside the programme

None of these blocks this plan. Each is a candidate for a follow-up issue that Chris can triage.

10.1 Follow-up issues from the inventory

# Finding Evidence Note
1 Edit and Delete show on an answered question while counts load or fail, because the node keys on annotationCount, not the lock question-node.component.html:85-87, 135 (verified) Reachable only where the counts flag is on (the staging pilot)
2 Project.DeleteQuestion has no system-question guard PAG/Project.cs:615-638 Static reading
3 Placement refusals return a generic 500; they should return 400 with ProblemDetails API/Program.cs:780-790 (verified) Moved into the programme on 5 October 2026: T-RD-12 makes the legacy validator's refusals a typed 400, because C4-T21 and RD-R41 require it in R1a. No longer a follow-up issue
4 The legacy dialog silently drops filtered options create-question.component.ts:533 (verified) A user-facing data-loss surprise today
5 ParentFilter.Validate() is never called Inventory static reading R1a's new authoring wires validation (AC-R1a-06r)
6 Stale gitops keys (M-35) cluster-gitops production values Cleanup in cluster-gitops
7 vitest.config.ts drift and the stale angular.json:205 path angular.json:205 names src/app/project/state/project-detail.effects.spec.ts, which does not exist (verified) Test-configuration hygiene

Six of the seven rows remain follow-ups; item 3 is now inside T-RD-12. The reposition endpoint's Console.WriteLine timings are also removed inside T-RD-12, and copy's skipped placement validation ends for canonical projects with R2a's "duplicate" change kind.

10.2 Items in other plans that ship first

These are owned by the architecture-review session and its follow-up plans. They are fixable now, outside this programme, and the programme rebases onto them.

  • Frontend bug plan PR-1 (B15: debugger; at annotation-question-tree-drag-drop.feature.ts:543, verified), PR-2 (ng lint in CI), PR-3 (#3976, SignalR re-subscription), PR-8 (B9: the question write effects move to exhaust or concat) and PR-10 (B11: the subscription leak in the legacy stage question selection).
  • Persistence PR-6: direct writes, including the question-delete cascade, bump Audit.Version.
  • Surface R0.5: deletes HybridExampleComponent and its angular.json exclusion.
  • A hygiene PR that makes SystemQuestionCreators read-only (X-49).

11. Acceptance criteria for this plan

Question management counts as integrated when all of these hold. Each names how to check it.

ID Criterion Verification
QMP-01 Every item M-01 to M-35 appears in §4.1 with a verdict, a target and a tracker row, or "None" with a follow-up number Count the §4.1 rows (35); every T- ID resolves in the tracker
QMP-02 Every harvest-map entry still has a target row or an Avoid reason; the count stays 131; each entry this change corrected carries a dated note Harvest map §9 totals; search the harvest map for "Corrected 5 October 2026"
QMP-03 Every interaction X-01 to X-49 appears in §7.2 with a resolution and a place where it is recorded Count the §7.2 rows (49)
QMP-04 Every tracker ID cited in this plan exists in the tracker Extract the T- IDs from this page and compare them with the tracker's ID column
QMP-05 The tracker holds T-RD-17, T-UX-10 and T-OI-02, its §4 counts add up to 119 rows, and every new row is On hold Recount the tracker table; read the new rows
QMP-06 QMI-01 to QMI-05 appear in §9, in T-OI-02 and in the owner-session integration §7 with the same recommendations Search the three documents for each QMI ID
QMP-07 No live text claims filtered-options parity with the legacy editor, a server-enforced answered-question lock, or that refusing D2-03 edits is today's behaviour Search the package for "same stored result as the legacy editor", "absorbs the legacy editor's filtered-options" and "which is today's behaviour"; only history notes may match
QMP-08 The design handoff covers the question-management surfaces: the question list or tree with child validity, the editor, conditional display and filtered options, import with preview and receipt, version history with a diff, collaborative drafts with presence, devices, Material 3 light and dark, and conversion labels; the held banner offers no "Mark compatible"; Apply anyway is limited to target-only publications that lower the target; the copy-ready prompt has a question-management block Read the handoff's question-management section, its §5.8 and DH-C41 entries and its copy-ready prompt
QMP-09 The RD, UX, ACD and BC specifications carry the adapted work and their §15 cites the M items and this plan Search each specification for question-management-plan.md and for M- IDs
QMP-10 Every change proposed to another plan names its document, its change and its interaction ID, and no file outside this package changed in this change set except mkdocs.yml (two navigation entries) Read §8; git diff --stat lists package files and mkdocs.yml only
QMP-11 Each release in §6 names its user outcome, the existing work it builds on, its tracker rows and its criteria, and every ID resolves Read §6; resolve the IDs
QMP-12 Nothing in this plan reads as approval to build rg -n -i 'authoris' on this file returns only statements that something is not authorised
QMP-13 The links on this page resolve under GitHub slug rules Run the package link check
QMP-14 The architecture-review rows in the integrated plan §8, DOM §15 and PI §10 say that #3961 merged (4d7807ec5) and that ADR-021 chose Wolverine with a single switch-over Read the three sections