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 14:35 BST). Only this front matter and note were added. Line numbers refer to the package as it stood when the reviewer read it. Resolutions are in the round-2 resolution matrix.

Review DS: delivery strategy and implementation efficiency

The plan's scope, contracts and acceptance criteria are thorough. On delivery it is not approvable yet: it is written for several staffed teams with independent owners, but SyRF is delivered by one approver (you) and a fast agent workforce. Engineering throughput is not the constraint. The plan implies roughly 150–210 PRs (my estimate); main currently merges about 15 PRs a day on average and up to 46. The real constraints have no budget in the plan:

  • your gates, decisions and screen acceptances;
  • Juniper, which is both the CI host and the agent host;
  • Bramble's limited exclusive time;
  • paused or external programmes;
  • a second programme-level roadmap (the architecture review, #3961), launched on 3 October and missing from the plan.

Path legend (absolute roots): - PKG = /home/chris/workspace/syrf/pr/pr3617.research-screening-as-specialised-annotation-gxgahs/docs/planning/integrated-review-plan-2026-10/ - MAIN = /home/chris/workspace/syrf/main/. It was at 0f5c61073 when this review started and moved to de3e98c59 (two merges) while it ran. - ARCH = /home/chris/workspace/syrf/pr/pr3961.awesome-wozniak-anqdaa/docs/planning/

1. Verdict

Not approvable in this dimension: 2 Blockers, 17 Majors, 6 Minors. The parallel windows assume a capacity that does not exist, and the critical path leaves out the true bottleneck. The five most important changes:

  1. Adopt an explicit single-approver operating model (DS-01, DS-13, DS-16):
  2. authorise implementation per freeze gate, not per PR;
  3. give you one dossier per gate;
  4. set a decision calendar tied to the gates;
  5. use fresh-context agent verifiers in place of "programme owner" self-sign-off;
  6. name a standing tester panel.
  7. Reconcile with the architecture-review roadmap before G0 (DS-02). The persistence soundness fixes (#3985, #3973) and the ProjectStatistics activate-or-freeze decision (#3987) should become F1 prerequisites. The duplicate #3964/#3969 needs resolving now.
  8. Add enabling work and split F1 (DS-06, DS-08, DS-10):
  9. an S0 scaffolding release;
  10. an M0 walking skeleton that measures the cost of the canonical commit first;
  11. split F1 so R0 can start on the engine contracts alone;
  12. build R0's writer refusal on the existing IAggregateWriteGuard choke point.
  13. Replace the windows with a dependency-driven ready queue under WIP limits (DS-04, DS-05, DS-15):
  14. stop R4a waiting for R3a;
  15. build the per-project admissions you already approved (Q-25) as plan-owned slices, so production pilots and the reconciler form arrive early.
  16. Make the work agent-sized and visible (DS-07, DS-09, DS-17, DS-18):
  17. slice briefs, plus a definition of ready and done;
  18. a hot-file and generated-file protocol;
  19. the ledger and package merged to main;
  20. a live STATUS ledger with a weekly digest for you.

2. Findings

ID Severity Location Finding Evidence Recommended change
DS-01 Blocker PKG/integrated-plan.md §4 l.223–226; §6.1 G0 l.800, F1 l.801; §6.2 item 9 l.833; §12 l.1101. PKG/open-questions-and-assumptions.md A-10 l.193, A-24 l.206. PKG/acceptance-criteria.md AC-ALL-13 l.61, UI-8 l.81 The plan assumes independent lane owners and parallel teams ("sequencing assumes parallel teams can be staffed"). In reality you approve everything and agents do the work. So "lane owners named" (G0's exit evidence) has no defined meaning. The five owner sign-offs at F1 would be you signing off your own agents' work. Every gate, question batch, ADR, prototype, screen acceptance and per-PR authorisation lands on you. Nobody has counted this load, so the parallel windows can't be achieved and the stated critical path leaves out the real bottleneck. gh pr list --state all --limit 400: all 400 PRs since 8 Sep are by chrissena. Merges per day ranged 0–46, with zero on 6 of 27 days. ARCH/architecture-review-2026-10-synthesis.md l.20: "one maintainer and a large agent workforce: about 1,250 PRs in two months". Your load under the plan (my count): 12 freeze gates, 27 ship gates plus GA, 29 open questions (Batch B 14, Batch C 15), ~17 contract ADRs plus release ADRs, U1–U29, a UI-8 preview acceptance per new screen, and per-PR authorisation (§12 l.1101) on ~150–210 PRs. Replace A-10 with an operating model in which you are the single accountable approver:
• A "lane owner" is a stream brief plus a stream-lead agent session.
• A "programme-owner sign-off" is a fresh-context agent checklist run against that programme's rules file (e.g. MAIN/.claude/rules/materialized-stats.md, stage-review-layouts.md), with you reviewing exceptions only.
• G0's exit becomes "operating model, stream briefs and decision calendar approved".
• Authorise implementation per freeze gate (Q3).
• Each gate's asks go into one dossier: decisions with recommendations, an AC evidence matrix, exceptions.
• Add a budget for your load per window.
DS-02 Blocker PKG/integrated-plan.md §8 l.968–998, §10 l.1036–1058. PKG/contracts.md C1 (Study version bump, E35 receipts). PKG/open-questions-and-assumptions.md E24 l.126, E35 l.137 A second programme-level plan started on 3 Oct: the architecture review (#3961), with issues #3972–#3990 and owner decisions already taken. It is missing from §8 and the risk register. Its premise conflicts with this plan's. It competes for the same approver, agents, CI and files, and several of its items change foundations that F1 freezes. The first collision has already happened. ARCH/architecture-review-2026-10-synthesis.md:
• l.38: "highest-leverage work is… to remove surface area, not to add features".
• l.47: #3969 "duplicates #3964 from the integrated-review plan; owner to pick one".
• l.60–68: persistence unsound (singleton unit of work, shared mutable cache, version bumped before the write, upserts, fire-and-forget events).
• l.80 and #3987: ProjectStatistics "activate or freeze".
• l.152 and #3988: one v0/v1 migration.
• l.157–160 and #3989: AF2 store and stage-review flagged as god files.
• l.176: MassTransit v8 support ends Dec 2026.
Checked in the repo: MAIN/.claude/rules/repository-cache.md l.15–16 (same mutable instance for 2 s; process-wide singleton unit of work); MAIN/src/libs/kernel/SyRF.SharedKernel/BaseClasses/Audit.cs l.28–34 (Version++ in OnSaving, before the write). The package never mentions RepositoryCache, unit of work, upserts or MassTransit (grep).		 Produce one integrated roadmap before G0:
• Make #3985 and #3973 F1a prerequisites, or require the engine to use isolated reads and non-upsert saves, enforced by an architecture test.
• Decide #3987 before F1a (E35) and F2 (C8).
• Fold v0/v1 retirement into E24, or defer it until after R2a.
• Run the #3989 AF2-store work as L5 seam slices.
• Decide MassTransit (#3986) before R0 guards PM consumers.
• Add the programme to §8 with joins, and its platform risks to §10 (silently reverted flag overrides #3975; fail-open checks, fixed in #3971).
DS-03 Major PKG/integrated-plan.md §6.4 l.912–926; graph l.892–895; §5.11 l.735–748. PKG/acceptance-criteria.md AC-GA-01 l.386, AC-GA-05 l.390 The "GA chain" is shorter than the real one:
• GA needs R2d, R3c and R3d (graph) and every production prerequisite (AC-GA-05). §6.4's chain lists none of them.
• That hides X-BATCH, R3d's dependency on R1a (the #3934 rebase), X-STATS-b (currently a provisional fail) and X-ELIG (programme paused).
• "R0 deploy and soak" has no environment or duration.		 MAIN/docs/features/materialized-project-statistics/STATUS.md:
• l.364: transactional path "FAIL on an idle host… 46% to 1,283%"; fold path "PROVISIONAL FAIL".
• l.401: the idle-host rerun is pending.
• l.410–411: the 7-day soak (#3952) has not started; #3510 blocks any production pilot.
PKG/source-status-inventory.md l.299 (#3742 has 0 files), l.291 (#3939: 63 files, conflicting).		 Publish the true GA path as the maximum of:
• the internal chain including R2d, R3c and R3d;
• X-STATS-b and #3987;
• X-ELIG;
• AF2 production admission;
• E6;
• your gate throughput.
Name the binding constraint. Define R0 soak per environment: one staging rehearsal; then one production promotion cycle plus N days with no deserialisation errors before any production canonical write. At F3, decide X-BATCH as "extract the completion definition".
DS-04 Major PKG/integrated-plan.md §5.11 l.737–740; §6.4 l.925. PKG/open-questions-and-assumptions.md Q-25 l.52 (answered §1 l.38) You approved per-project admission routes (Q-25) for AF2, the redesigned shell and eligibility. The plan still lists them as external joins owned by "the AF2 programme", with no slice and no window. Until they are built, no R2–R4 release reaches a production user before GA. The "fastest user value" claim also counts R1a, which "stays behind its flags" (l.312), with no step scheduled to turn it on. MAIN/docs/features/annotation-form-v2/remaining-delivery.md l.38–41: no production activation; a release decision and a stability interval are needed. The AF2 gate is a pure-function input (MAIN/src/services/web/src/app/shared/annotation/annotation-form-v2/annotation-form-v2-eligibility.ts l.59–60), so admission is a small change. newQuestionManagement is off in staging and unset in production (PKG/source-status-inventory.md §5). Add plan-owned slices that read R0's admission service:
• AF2 per-project admission (R0 or R2a);
• stage-review shell per-project admission (R2a);
• eligibility per-project admission (R3a).
Give every release a "production enablement" step with its own evidence, including turning R1a's editor on by default. The environment-wide enablement of these flags stays a GA prerequisite.
DS-05 Major PKG/integrated-plan.md §7 l.930–945 (W3 l.939, W4 l.940, W5 l.941), compared with §1 l.79, graph l.864–865 and the §5.8 table The windows bring back dependencies that the graph and the review resolutions removed:
• R4a, "the largest visible gap", is built in W3 but can only ship in W4, which starts after R2b, R2c and R3a have shipped. Its real dependencies are F4 and R2b.
• Likewise R2d and AL1 wait for R3a (W4); C2, P2, R4b and R5a wait for R3b (W5).		 §7 l.930–931: "Each window starts when its condition holds; items with their own condition (in brackets) start once it also holds." None of these items has a bracket. Resolution matrix C-03: "R4a ships after R2b and F4". Use a dependency-driven ready queue: a release starts when its graph predecessors and freezes hold, and ships when its gate passes. Keep the windows only as an illustrative timeline. At minimum add brackets: R4a [F4, R2b], R2d [R2c], AL1 [F-A, R2b], C2 [C1, Q-18], P2 [P1; R3b for the reviewed part], R4b [R4a], R5a [F6a, R4a].
DS-06 Major PKG/integrated-plan.md §6.1 F1 l.801; R0 critical path l.300–301; W1 l.937 F1 is a single mega-gate on the GA path. It bundles the engine contracts, compatibility, storage, receipts, permission catalogue, export disclosure, IA and copy, AF2 extension points, the Dockview amendment, five sign-offs and a Q-03 subset. R0 needs only the inventory, C16 and the storage basics (l.300), yet it waits for all of F1 (W1 starts at "F1 frozen"). The F1 row; R0 critical path; W1. Split F1:
• F1a: C1, C2, C3, C5, C16, E15/E20/E21/E25/E27/E35 and the inventory. Gates R0 and the R2a backend.
• F1b: C10 catalogue and export disclosure, C11 versions. Gates R2a exports.
• F1c: C17 IA and copy, AF2 seams merged as code, the Dockview amendment. Gates R2a UI.
Move the Q-03 catalogue subset into the G0 batch.
DS-07 Major PKG/integrated-plan.md §5 (the release is the smallest unit), §7 rule 3 l.962–963. PKG/acceptance-criteria.md §2 Agents have nothing smaller than a release to pick up:
• no slice breakdown or slice dependency graph;
• no definition of ready or done;
• no slice brief and no PR-body convention.
R2a, R3a, R4a and P2 are each roughly 8–14 PRs with an internal order. The package (~434 KB) plus the inputs it defers to (~691 KB) can't fit in an implementing session's context, so agents will re-derive scope and drift.		 The repo's own precedent, the FEAT-024 async fold:
• slices with an explicit dependency graph (MAIN/docs/features/materialized-project-statistics/async-point-fold-design.md l.1886–1892);
• "Mandatory test shapes (… red-first)" (l.555);
• a slice/PR/state table (STATUS.md l.372–387);
• slices 0–7 delivered in about 3 days.
MAIN/docs/planning/ai-development-readiness-analysis.md l.229–244 (one self-contained spec per phase), l.343–346 (≤500-line sub-tasks); the package doesn't reference it. MAIN/.github/pull_request_template.md is generic. Sizes measured with du -cb.		 At each freeze, require a release brief in the async-fold format: slice table (scope, files, dependencies, red-first test shapes, AC IDs, flag or admission, docs) plus a dependency graph. Add a per-slice agent brief of about 300 lines or fewer: decision IDs with one line each, contract and fake versions, invariants touched, allowed and forbidden files, "stop and ask" triggers.
Definition of ready: brief written, contract or fake frozen, fixtures available, hot-file lease free, no competing claim, decisions answered (or "until answered" behaviour stated).
Definition of done: AC IDs evidenced in the PR body, CI and review green on the exact head, docs updated, flag decision stated, STATUS row updated.
Add a programme section to the PR template.
DS-08 Major PKG/integrated-plan.md §5.1 l.259–273; §12 item 4 l.1096. PKG/acceptance-criteria.md methods C/B l.35–36, AC-ALL-09 l.57, AC-R2a-19 l.172; §6 l.427–460 The enabling work that the parallel lanes depend on is missing:
• a walking skeleton;
• a cross-language fixture harness (E23 needs the same fixtures in xUnit and Vitest);
• a decided home for fakes, including TypeScript fakes behind AF2's persistence port;
• a benchmark harness with a recorded baseline (AC-R2a-19's "today's session-submit p95" exists nowhere);
• seed scaffolding.
M0 runs "in a scratch worktree", yet F1 needs M0's conformance suite and fakes merged. The riskiest assumption, the cost of the canonical commit, isn't tested first, even though FEAT-024 alone already misses its write-overhead gate by 46–1,283%.		 Existing benchmarks cover screening only (ProjectScreeningWriteBenchmark*.cs, ProjectScreeningReadBenchmark.cs under MAIN/src/libs/project-management/SyRF.ProjectManagement.Mongo.Data.Tests/ProjectStatistics/); a reusable env-gated harness exists (BenchmarkEnvironment.cs). Seeds must be "achievable through normal application workflows" (MAIN/docs/platform/enhanced-database-seeding.md l.38–42). STATUS.md l.364. MAIN/CLAUDE.md: scratch/ worktrees are disposable. Add S0 programme scaffolding in W0, alongside M0, as about 6–8 PRs:
• canonical module skeleton (new controllers, explicit DI module);
• fixture harness, with PRISMA fixtures 1–8 as data;
• a session-submit benchmark arm run on today's main to record the baseline;
• seed builder hooks;
• the STATUS ledger and templates.
Make M0 a walking skeleton. Spike code may be thrown away, but the conformance suite, fakes and ADR merge. Route one form through engine → CAS → Study projection → FEAT-024 pending entry (transactional and fold) → draft → dark AF2 adapter → export, measured against go/no-go thresholds before F1a.
DS-09 Major PKG/integrated-plan.md §7 l.947–954 (L5 order), rule 3 l.962; §10 l.1051 The conflict model covers only the AF2 and stage-review files and relies on a fixed landing order. The repo's hottest shared files are elsewhere, and every API or flag PR in this programme will touch them. The fixed L5 order makes ready work wait. The extension points are "agreed" at F1, not merged code. Non-merge commits since 2026-09-03:
• .generated-checksums.json 141
• swagger.json 105
• api-client.generated.ts 104
• ReviewController.cs 55 (1,707 lines)
• env-mapping.yaml 47 (co-changes 12+ generated files)
• stage-review.component.ts 47
• StudyRepository.cs 42
• AF2 component 42, AF2 store 34
MAIN/docs/how-to/work-with-generated-files.md.		 Add a hot-file register:
• Never hand-merge generated files: take main's copies, re-run the generators, commit.
• Put new canonical code in new files (controllers, services, stores) and reach AF2 through its ports.
• A single shell-writer stream lands AF2 and stage-review seams first; then "first ready lands, the later one rebases".
• Register programme flags (or stream kill switches) once in S0, and use R0 admission data for per-release enablement.
DS-10 Major PKG/integrated-plan.md R0 MVP 2 l.283–288; PKG/acceptance-criteria.md AC-R0-02 l.99 R0 plans an ownership check inside "every legacy writer", which means about 15 in-place edits in files under heavy churn. Writers added later (notifications, batches, bulk PDF) would bypass it unless someone remembers. The repo already has a proven choke point, and a build-failing test, for exactly this shape. MAIN/.claude/rules/bulk-study-locks.md l.15 (GetWriteFilter adds the registered IAggregateWriteGuard) and l.28 (StudyWriteLockArchitectureTests fails the build on an unguarded write); #3909 used this to make every study write honour bulk-update locks. In the C16 ADR, implement the refusal as a second registered IAggregateWriteGuard. Back it with an ownership marker written atomically with the CanonicalOwnership record, plus project-wide guards modelled on ThrowIfBulkUpdateInProgressAsync. Extend the architecture test. Make N-1 tolerance an automated CI test against canonical fixture documents.
DS-11 Major PKG/integrated-plan.md §6.2 items 4 and 6, l.824–829. PKG/acceptance-criteria.md AC-ALL-04 l.52, methods R and S l.37–38 All 27 releases get the same nine-item gate, including an image-rollback rehearsal and user testing, even releases with no persisted data (R1b) or tiny scope (R1d, AL1, R4c, R5c). Staging redeploys on every merge to main, so each staging image rollback means pausing promotion for every programme, and staging acceptance runs on a moving build. MAIN/CLAUDE.md ("Staging promotion is automatic"). MAIN/docs/how-to/production-promotion-and-notifications.md l.34–36, l.68–70. Main moved twice during this review. Use gate weight classes:
• Heavy (R0, R2a, R3a, R4a, P2, O2, R6): staging rehearsal in an agreed promotion-pause window, CI run:e2e-full, user testing.
• Standard: automated N-1 test plus a rehearsal on a preview environment.
• Light: flags-off and legacy-unchanged checks, capability tests, docs.
Run acceptance on a pinned PR preview, or record the staging versions in the acceptance note.
DS-12 Major PKG/integrated-plan.md §9 item 4 l.1009–1010. PKG/acceptance-criteria.md B l.36, AC-ALL-09 l.57, AC-M0-02 l.90, AC-R2a-19 l.172, AC-R2c-06 l.194, AC-R4a-13 l.278 The plan treats Bramble as unlimited, exclusive benchmark and soak capacity. Bramble's guest VM is a CI E2E listener that runs both functional shards. It also hosts FEAT-024's pending idle-host gate (b) rerun and the 7-day soak. Gate (b) feeds X-STATS-b, which is on this plan's own critical path. AC-ALL-09 adds a benchmark to every release. MAIN/docs/how-to/juniper-runner-routing.md l.122. MAIN/docs/platform/e2e-testing-infrastructure/performance-plan.md l.140–143, l.160–161 (an exclusive window is needed; still open). STATUS.md l.401, l.410. MAIN/docs/features/materialized-project-statistics/phase2c-staging-proof-runbook.md l.1059–1062. Keep a Bramble calendar of exclusive windows, with FEAT-024's gate (b) rerun first. Limit B criteria to named hot paths (Save/Complete, publication, pool selection, reconcile load, export), with baselines captured once in S0. Run benchmarks in batched windows.
DS-13 Major PKG/acceptance-criteria.md AC-ALL-13 l.61; PKG/integrated-plan.md §7 l.956–966 Review means "a passing Claude review on the exact head", nothing more:
• no supervision tiers for engine and CAS, migrations, authorization and blinding, flags and admission, or contracts;
• no fresh-context verification at ship gates;
• /claude-review runs only on non-draft PRs targeting the default branch, so stacked PRs can't be reviewed until retargeted.
Reviews default to Sonnet and never re-run automatically.		 MAIN/.github/workflows/README.md l.318 (opus alias), l.340 (default-branch eligibility), l.342 (no automatic re-review), at de3e98c59. juniper-runner-routing.md l.198 (60-minute review job on the shared pool). Readiness analysis l.307–319. Notification stack 8 deep with #3965 on top (PKG/source-status-inventory.md l.295). Two tiers:
• Supervised: /claude-review opus plus a fresh-context verifier (pr-deep-analysis or cross-review) plus you reading the summary.
• Delegated: default /claude-review.
Stack depth of 2 at most; retarget to main before review. A ship-gate verifier maps every AC ID to evidence and checks invariants 1–12 across the release's PRs.
DS-14 Major PKG/integrated-plan.md §7 rule 2 l.960–961, §9 l.1002–1013 No CI or agent-host budget:
• 12 shared listeners run PR tests, the 22–23-minute .NET lane and 60-minute reviews;
• E2E has two listeners;
• agent sessions share Juniper with the CI runners.
The plan adds conformance suites on every contract PR, PRISMA fixture reruns and per-endpoint capability matrices.		 juniper-runner-routing.md l.41, l.115, l.122, l.198. gh run list --workflow pr-tests.yml: 27–44 minutes (runs 37110558952, 37103622407); run 37112268597 took about 4 h (cause UNVERIFIED). This review ran on host Juniper (48 CPUs) with load average 43.53 and 81 users. STATUS.md l.697–699: "Juniper, the CI runner host… loaded". Publish a CI budget:
• conformance in a path-filtered project with a ≤5-minute target;
• E2E per spec locally, CI smoke on review-flow PRs, run:e2e-full once per heavy release;
• benchmarks gated by environment variable;
• pushes batched; Opus only for the supervised tier.
Track CI queue time. Cap concurrent sessions on Juniper and move full local suites to Bramble windows.
DS-15 Major PKG/integrated-plan.md §7 W1–W5 l.937–941; §10 l.1050–1052 No WIP limits. Each window schedules roughly 10–12 concurrent items, while integration and acceptance capacity is one person. The package's own inventory shows what that produces: about 20 in-scope PRs are conflicting or stale and now need "harvest and close". PKG/source-status-inventory.md §4 l.280–309: conflicting or stale #3546, #3394, #3292, #3017, #3288, #3939, #3934, #2781, #3746, #3327, #2224, #2412, #2387, #2461, #2572–#2575, #2621, #2469, #3617. Per stream: at most 2 releases in build and 1 in acceptance; programme-wide, at most 3 in acceptance. Finish before starting. At the weekly review, rebase or close conflicting PRs older than N days, with a harvest note.
DS-16 Major PKG/acceptance-criteria.md PE-05 l.409, UT tasks l.411–425, S l.38, UI-8 l.81. PKG/integrated-plan.md §5.4 l.443–446, §9 items 6–8 and 11 Human acceptance capacity is unplanned:
• PE-05 needs at least 4 of 5 testers per task across 11 releases, so 55 or more sessions;
• every release needs signed staging acceptance;
• U1–U29 must happen before building;
• you accept each new screen.
No tester is named and there is no schedule.		 The cited criteria. "CAMARADES testers" appear unnamed (PKG/acceptance-criteria.md l.456). Name a standing panel at G0. Batch sessions across neighbouring releases. Run the U-validations in W0 and W1. Hold a weekly screen review from UI-7 screenshots, with preview checks only for new screens. Define "materially changed".
DS-17 Major PKG/README.md l.93–95. PKG/integrated-plan.md §8 l.998, §12 l.1085–1101. PKG/decision-register.md l.179–181. PKG/source-status-inventory.md l.391 The authority agents must follow (the package, the owner ledger and the research) exists only as untracked files in a worktree whose PR has been conflicting since 24 Sep. Agents start from main, so they can't see it. docs/planning/ is "temporary; delete when complete", the wrong home for a contract that will last months. The register expects the ledger to be updated separately, which invites drift. §12 never schedules merging any of this. git status in the PR3617 worktree: package, ledger and 15 research files untracked. gh pr view 3617: CONFLICTING, updated 2026-09-24. MAIN/CLAUDE.md docs map. Make "commit and merge the ledger, package and inputs" step 0 of §12. As contracts freeze, promote them to docs/decisions/ ADRs and docs/features/<programme>/ specs. Keep one append-only ledger on main; record each new decision in the PR that implements it, with the register as a cross-reference.
DS-18 Major PKG/README.md l.97–100; whole package There is no live progress mechanism: no status ledger, no issue per slice, no metrics, no digest. The states in the package are snapshots the package itself says go stale. You can't see what is blocked on you without asking. README l.97–100. Working precedent: FEAT-024 STATUS.md l.372–387. GitHub issues are in active use (#3952, #3972–#3990). Create docs/features/<programme>/STATUS.md, updated as part of every slice's definition of done. Open one issue per slice with programme, release and stream labels. Send a weekly gh digest:
• gates and decisions waiting on you, with their age;
• PRs waiting for /approve;
• red CI and CI queue time;
• external joins (RAG), Bramble windows, WIP;
• AC coverage.
DS-19 Major PKG/integrated-plan.md §7 rule 3 l.962–963 The coordination rules don't prevent two sessions doing the same work: "one writer per worktree" doesn't stop duplicates. It has already happened on the plan's first deliverable. Worktree hygiene isn't planned either. #3964 (created 06:07Z, 0 files) and #3969 (created 06:13Z, +418, from the architecture review) are the same fix; ARCH synthesis l.47. Both must keep seed ownership election working, which calls ChangeProjectOwnership (MAIN/src/libs/project-management/SyRF.ProjectManagement.Core/Model/ProjectAggregate/Project.cs l.944–958). 195 PR worktrees, 127 with node_modules at ~1.3 GB each; disk 79% used. Add a claim step to the definition of ready: an issue is assigned before any worktree exists, open PRs touching the same paths are searched, and the claim goes in STATUS. Run post-merge cleanup within 24 h; prune merged or closed worktrees older than 14 days. Resolve #3964/#3969 (Q7).
DS-20 Minor PKG/integrated-plan.md R1a l.305–319, §8 l.989; PKG/domain-model.md l.80 R1a builds import on the legacy API; R2a then needs the same "apply" path on canonical definitions. The large #3934/#2781 work gets plumbed twice. R1a MVP; #3934 is +6,192 lines and conflicting. Design an import-target port with legacy and canonical adapters. Ship browse and preview first; make canonical apply an R2a slice.
DS-21 Minor PKG/integrated-plan.md R2a l.387–391; PKG/domain-model.md l.81; C6 frozen at F3 R2a writes a "minimal stage settings version" before C6 freezes. Unless the envelope is designed for steps, R2a pilot data will need migrating at R3a. Cited rows. The plan already did the equivalent for populations in C2. Freeze the StageSettingsVersion envelope at F1a: bindings, a step list with one implicit step, policy slots. Leave only the step semantics for F3.
DS-22 Minor PKG/integrated-plan.md R4a l.604; F4 l.804 R4a's MVP includes "#3944 conversations aligned to Q-10". That is #3965, on top of an unmerged 8-PR stack whose base conflicts with main. This contradicts "notifications are never a release dependency". PKG/source-status-inventory.md l.295; #3965's base branch (gh pr view). Take it out of R4a's gate. Keep conversations disabled until #3965 merges, as its own join.
DS-23 Minor PKG/integrated-plan.md §7 rule 3 l.962 "Small PRs" is undefined. Recent PRs often run to 2–6k additions, which hurts bot-review quality and widens conflict windows. Splitting too finely would multiply your approvals instead. #3949 +5,918; #3895 +5,743; #3934 +6,192; #3939 +3,233 over 63 files. Readiness analysis l.343–346. Size PRs by slice: about 800 changed lines or fewer of non-generated, non-test code, with exceptions declared. Put refactors and seams in separate PRs. Put decision ADRs in docs-only PRs.
DS-24 Minor PKG/integrated-plan.md l.292–293, l.714–715; PKG/source-status-inventory.md l.389 Around 40 ADRs (17 contract ADRs plus one per release) written by parallel PRs that each pick "the next free number" will collide; the repo already has duplicate ADR numbers. PKG/source-status-inventory.md l.389 (ADR-008 duplicated; next free ADR-021). MAIN/docs/decisions ends at ADR-020. Reserve an ADR block in STATUS. Record minimum rollback images in one C16 compatibility ledger. Use the template at MAIN/docs/README.md l.406.
DS-25 Minor PKG/integrated-plan.md §6.2 item 8 l.832; PKG/acceptance-criteria.md AC-ALL-06 l.54 The rule to update the public user guide in the same PR would document features that stay dark for months. MAIN/CLAUDE.md docs map: help.syrf.org.uk is public, and the [TARGET - Phase N] marker convention exists. Engineering docs go in the same PR. User-guide pages are drafted under target markers and published at production enablement (Q8).

3. Improvements

  1. Revised critical path (proposal).
  2. G0, one sitting:
    • approve the plan and a joint roadmap with #3961;
    • give #3987 a direction;
    • pick #3964 or #3969;
    • name the tester panel;
    • give the Q-03 catalogue subset;
    • authorise S0, M0 and R1b.
  3. W0, in parallel:
    • S0 scaffolding;
    • M0 walking skeleton;

    • 3985 and #3973;

    • R1b;
    • U1, U13–U15 and U19 prototypes.
  4. Engine and R2a: F1a → R0 (guard and automated N-1 test) → R0 in staging plus one rehearsal → R0 in production for one cycle. F1b and F1c run in parallel with R0. Then R2a backend and R2a UI (on merged seams) → staging acceptance → AF2 per-project admission → opt-in production pilot.
  5. After R2a, three branches:
    • R2b → R4a once F4 is frozen (the reconciler form, not tied to R3a);
    • R2c once F2 is frozen → R2d;
    • R3a once F3 is frozen (eligibility absorbed, X-BATCH decided) → R3b once F5 is frozen → R4p, R3c, R3d.
  6. GA = max(R2d, R3c, R3d, R4p) plus production prerequisites.
  7. Binding constraints, in likely order: your gate and decision throughput; X-STATS-b with #3987; X-ELIG; tester availability. Engineering is not among them.
  8. Five delivery streams instead of 18 lanes. Each stream has a brief, a stream-lead session, implementer sessions per slice, and fresh verifier sessions. L8, L15 and L17 become cross-cutting roles.
  9. A: engine and definitions (L0, L1, L2, L13).
  10. B: workflow, profiles and operations (L3, L4, L7).
  11. C: reviewer workspace and admin UX (L5, L16). Sole writer of the shell files.
  12. D: reconciliation, history and notifications (L6, L11, L14).
  13. E: PRISMA, classification and outcomes (L9, L10, L12).
  14. Your control protocol:
  15. decision batches tied to gates, with "needed by" dates (split Batch B into F2, F3 and F5 sets), run with batch-grill;
  16. per-gate implementation authorisation;
  17. one dossier per gate;
  18. a weekly 30-minute review of the digest, dossiers and screens.
  19. When agents stop and ask:
    • an owner decision is missing;
    • a contract change is needed;
    • an invariant conflicts;
    • a production or data action is needed.
  20. Early-value track:
  21. the surviving ownership PR and R1b;
  22. quick wins from the inventory's §7 defects, if you triage them in: the flagged OnlyCompleted export fix (currently parked in R5a), the reconcile-payload identity leak, export unmasking;
  23. R2a opt-in production pilots;
  24. R4a straight after R2b.
  25. Fail fast and re-plan.
  26. M0 go/no-go thresholds, set at G0 from the S0 baseline:
    • canonical Save/Complete p95 against AC-R2a-19, with FEAT-024 pending entries in the mode production will use;
    • transaction duration well inside MongoDB's 60 s default lifetime;
    • document-size headroom.
  27. Re-plan at every freeze gate, or when any of these happens:
    • an external join misses its date;

    • 3987 is decided "freeze";

    • WIP stays over its limit for two weeks;
    • a decision waiting on you is older than 10 days.
  28. Budget table (my estimate; refine in the release briefs):
Family PRs Review tier E2E in CI
S0 and M0 8–12 Supervised None
R0 4–6 Supervised Smoke
R1a–R1d 10–16 Delegated (authz: supervised) Smoke
R2a–R2d 23–33 Engine and publication: supervised Full at R2a and R2c
R3a–R3d 22–31 Admission and decisions: supervised Full at R3a
R4a–R4c 19–27 Gold and queries: supervised Full at R4a
R5a–R5c 9–13 Export and disclosure: supervised Smoke
P1, P2 13–19 Dedup and merge: supervised, plus parity suite Full at P2
C1, C2, O1, O2, AL1 21–29 O2: supervised Smoke
ADRs and docs 20–25 You read them None
  1. Reuse existing tools rather than inventing process:
  2. wt and start-work, ship-pr, post-merge-cleanup, handover, to-issues;
  3. phased-rollout for each release's planning phase, but with progressive dark merges rather than holding every PR;
  4. FEAT-024's BenchmarkEnvironment pattern;
  5. the IAggregateWriteGuard and architecture-test pattern;
  6. the catalogue-coverage test pattern (#3882).

4. Questions for Chris

  1. Programme precedence: how should this plan and the architecture-review roadmap (#3961) share capacity? Recommendation:
  2. Architecture-review Phase 0 security fixes continue as they are.

  3. 3985 and #3973 become F1a prerequisites.

  4. 3987 is decided before F1a.

  5. v0/v1 retirement is folded into E24 or deferred until after R2a.

  6. 3989 runs only as L5 seam work until R3a ships.

  7. 3986 is decided before R0.

  8. #3987, and what PS1 means for GA: if ProjectStatistics is frozen or late, may GA use authoritative counting under the protected boundary, which Q-31(b) currently allows for named pilots only? Recommendation: activate the families this plan uses, on a date. If you choose freeze, extend Q-31(b) to GA under the same boundary and the "never treat missing as zero" rule, recorded as a new decision.
  9. Implementation authorisation per freeze gate instead of per PR (§12 l.1101)? Recommendation: yes. You approve each gate's dossier, including its slice list. Merges keep your /approve, batched daily. You keep all product decisions, production enablement and adoption waves.
  10. Production pilots before GA (A-23 is still an assumption)? Recommendation: yes, for new projects whose creators opt in. Conditions: R2a passes staging acceptance, R0 has completed a production soak, and AF2 per-project admission is built.
  11. Eligibility programme: finish its remaining slices (S4-B tooling, S5 browser consumption, S6a) inside R3a, or keep it paused? Recommendation: absorb them into R3a's slice list at F3, using per-project admission for pilots. Environment-wide enablement stays a GA prerequisite.
  12. Who are the testers? Recommendation: five named CAMARADES reviewers and administrators, with monthly batched sessions, and PE-05 kept at 4 of 5.
  13. #3964 or #3969? Recommendation: keep #3964's scope (owner-reserved grants, UI and user guide), port #3969's code and tests into it, close #3969, and add a regression test for seed ownership election.
  14. Public user guide for dark features? Recommendation: draft pages under target markers in the implementing PR, and publish them at production enablement together with the "what changed" page.

5. Coverage gaps

  • No CI runs or benchmarks were executed. I saw Juniper's load only once, and never observed Bramble's actual schedule or load.
  • Architecture-review claims were checked only for the repository cache, Audit.cs and the issue texts; the rest is UNVERIFIED.
  • I read the ledger only where it bears on delivery. UI and data-contract content belongs to the other reviewers.
  • Unverified:
  • whether Codex sessions can use the Claude Code skills I cite;
  • whether ZenHub is in active use;
  • whether pr-tests.yml cancels superseded runs;
  • why one PR run took about 4 hours.
  • Not assessed: Let's Encrypt and preview-environment capacity at UI-8 volumes; the timeline impact of MassTransit's end of support.
  • The PR estimates and your touchpoint counts are mine, not measured.

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/acceptance-criteria.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/pr/pr3961.awesome-wozniak-anqdaa/docs/planning/architecture-review-2026-10-synthesis.md
  • /home/chris/workspace/syrf/main/.claude/rules/bulk-study-locks.md