Harvest audit brief (read-only)

The brief given to the five read-only harvest audits on 5 October 2026. Saved verbatim as evidence for the harvest map. Feature implementation is on hold; nothing was ported, rebased or closed.

Why

On 3 October 2026 Chris decided:

• Q-08: harvest the dormant Question Management v2 (QM v2) stack rather than revive it. The recorded recommendation was to audit the domain and services against the new contracts, port what fits into small new PRs, and close the stack once it has been harvested.
• Q-09: harvest #2224's API shape and tests into R1c.

The integrated review plan was then rewritten by an owner session on 4–5 October 2026. Nine specifications now define the target model. The plan's only harvest table so far is versioning-model.md §12.6, which covers versioning alone and predates the owner session.

Your job is a read-only audit of the PRs assigned to you against the current specifications. It feeds a harvest map that says, for each reusable piece, whether to reuse it as is, adapt it, keep it as reference only, or avoid it. Each entry says where the piece goes (specification section, contract, release and tracker row), what adaptation the owner-session decisions require, and what it costs.

SyRF feature implementation is ON HOLD. Nothing is ported, rebased, merged or closed. This audit only reads.

Hard rules

• Read only.
• No git checkout or git switch, no worktree add, no commits, no stash.
• No git fetch; the refs below are already fetched.
• No gh write commands: no comments, edits, closes or reviews.
• How to run commands.
• Use git -C <W> show|diff|log|ls-tree|grep|merge-base … and read-only gh pr view or gh api GETs.
• Use absolute paths. Do not use cd in compound commands.
• Searching. In this shell, grep is aliased to rg, so grep -E fails. Use rg, or git -C <W> grep -n -E … <ref> -- <path>.
• Data. No secrets, tokens, clinical data or participant identifiers in your output.
• Scope. Be efficient. Large PRs (600 files) are mostly generated clients, migrations of snapshots or main merges. Use file lists to find the domain, service, migration, API and UI pieces, then read those.

Locations

• Worktree on current main (read the specifications here): W=/home/chris/workspace/syrf/pr/pr4061.planning-qm-v2-and-dormant-pr-harvest-map-e2ujxx
• Package: PKG=$W/docs/planning/integrated-review-plan-2026-10
• PR heads are fetched as refs/remotes/audit/pr<N>:

PR	Head	Base	Size	Note
#2461	1ca9f5def	main	738 files	DO-NOT-MERGE umbrella; the original combined QM v2 R1
#2572 (PR-A)	af5136696	main	67 files	Domain foundation; conflicting with main
#2573 (PR-B)	271290115	feat/qm-v2-a-domain	8 files	Admin decision framework domain services
#2574 (PR-C)	1b93cbbc4	feat/qm-v2-b-admin-services	604 files	Migration, ADR-009 cutover, API
#2575 (PR-D)	098330759	feat/qm-v2-c-migration-cutover	544 files	Web scaffolds and docs
#2224	fff8385ac	main	47 files	Custom project groups, by nurikarakaya, who has left
#3934	9d6c596cf	main	42 files	Question template import through the UI (updated 2 Oct)
#2781	2d8b071b0	main	19 files	Guarded annotation question import foundation (Python tooling)
#2387	c81426c44	main	46 files	QM child question visualisation and assign tree
#2986	1c6799b00	main	8 files	Validate current-schema answers before persistence
#2987	efd4b96ba	main	1 file	Schema and profile architecture ADR
#2629	d761ca442	main	1 file	FEAT-027 annotation validation scoping
#2812	1c3869224	main	39 files	Response-mode gate contract

Known facts from an earlier analysis (2 August 2026)

Verify these before relying on them.

• The stack is internally out of sync. B, C and D are based on PR-A's original squash 36190433d; A's tip has about 51 later commits (renames, VersionHistory<T>, init-only fields, a validator split) that B, C and D never absorbed. Each branch merged main independently, so GitHub's diffs for B, C and D show spurious deletions. To isolate a layer's own work, compare it with its parent layer's head, use git merge-base, or use the GitHub file list (gh api repos/camaradesuk/syrf/pulls/<N>/files --paginate).
• PR-C embeds all 75 source files of the unmerged #2467 (SignalR active-reviewer tracking). It also duplicates the ADR-009 Application-layer extraction that main landed in #2543. Active-reviewer tracking, claims and presence have since merged on main by a different route.
• Semantic conflicts with main that git does not flag:

• 2635's duplicate-annotation-Id guard;

• 2648 (a Study nested under a custom Study parent is rejected by the v2

  CandidateProjectQuestionSetValidator, AQ009);

• 2651's anchor and non-anchor system-question split, against v2's parentQuestion.System

  heuristic.

• Defects found:
• C: the system-question v2 documents use globally hard-coded GUIDs as _id in a shared collection, so only one project can ever migrate. The migration is not transactional, not idempotent and has no caller.
• B: SessionTransitionService never rebases answers onto the target type or shape; StageTransitionJob has no failure state.
• D: the publish wizard throws NullInjectorError; withUndoRedo does nothing; autosave clobbers options[]; admin decisions are silently discarded.
• PR-A's ADR-010 collides with main's ADR-010.
• Template import toolchain. The working uploader, which performed real production uploads in August, lives outside the repo. #2781's branch copy is hardened but fails closed, pending an "Annotation Extensibility" follow-up (answerLabel field survival, atomic rollback). #3934 is a UI path for template import, updated on 2 October.

What to read in the package (current main)

• PKG/specifications/README.md: the entity map and how the nine specifications fit together.
• The specification for your area:
• RD spec-review-domain-and-versioning.md: questions, forms, versions, drafts, publication, targets.
• SP spec-stage-pools-steps-and-history.md: stage study filter, steps, history; this replaces stage transitions.
• BC spec-baseline-conversion.md: universal faithful conversion of every project.
• UX spec-ux-devices-and-work-discovery.md and design-prototype-handoff.md: screens.
• ACD spec-access-communications-and-deletion.md: catalogue and permissions.
• RS spec-reconciliation-and-screening.md: reconciliation and profiles.
• PKG/versioning-model.md §12.6: the existing harvest-and-avoid table. Extend or correct it; don't just repeat it.
• PKG/contracts.md:
• C1 (annotation identity and revisions);
• C2 (context);
• C4 (definitions, versions, publication);
• C5 (sessions and drafts);
• C8 (statistics);
• C10 (permissions);
• C14 (outcome schemas);
• C16 (compatibility and rollback).
• PKG/domain-model.md: entity names.
• PKG/implementation-tracker.md: existing tracker row IDs. Propose new rows only where none fits.
• PKG/acceptance-criteria.md:
• AC-M0-04 (the QM v2 harvest table at M0);
• AC-R1c-12 (#2224);
• the R1a, R2a and R2c sections.
• PKG/integrated-plan.md §8 table: the programme and PR dispositions. Also the release sections for M0, R1a, R1c, R2a and R2c.
• PKG/decision-register.md §5: the QM v2 requirement crosswalk.
• PKG/g0-dossier.md: G0-D4 to G0-D7, the PR dispositions, which are not authorised during the hold.

Verdicts

Verdict	Meaning
Reuse	Port as is, or with renames only, into a small new PR
Adapt	The logic or tests are valuable but must change to fit the specifications; say what changes
Reference only	Useful as design input, test cases or copy, but not ported as code
Avoid	Contradicts a decision or rule, is defective, or has been superseded by main; say why

Effort: S (one day or less), M (1–3 days) or L (more than 3 days), for the port or adaptation including tests.

Output

Write one markdown file to the path given in your task: no front matter, about 150–400 lines. Sections:

1. Scope and state. What each PR contains by area, its real size once generated files are excluded, how it relates to its base, and its conflicts and drift with main, with evidence.
2. Harvest entries. A table with these columns: | ID | PR | Component (type or file at SHA) | What it does | Verdict | Why (rule IDs, decisions) | Target (spec §, contract, release, tracker row) | Adaptation needed | Tests to carry | Effort | Evidence (path:line @ short SHA) |. Use IDs H-<area>-nn with the prefix given in your task. Group by component, not file by file.
3. Defects not to carry over. Confirmed or refuted from the known facts, plus any new ones, with evidence.
4. Superseded by main since the PR was written, with evidence (main path or PR number).
5. Closure-note draft per PR: 2–4 sentences on what was harvested and where it went. For #2224, credit its author.
6. Proposed tracker rows: suggested ID, scope, release, dependencies, acceptance evidence. Prefer attaching to existing rows (for example T-RD-01, T-RD-02, T-RD-05, T-BC-01, T-AC-04).
7. Owner-level questions, only if genuinely needed (usually none).

Finally, report in under 15 lines: the file path, entry counts by verdict, and the three most important findings.