Skip to content

Integrated review programme planning package

Temporary planning package for Chris's review. Planning is not implementation approval. Chris authorised comprehensive implementation planning and independent adversarial review on 3 October 2026, and later asked for progress to be committed and pushed on this PR branch. No runtime code, migration, deployment, notification or flag change was made by the planning work. It was prepared by Claude Code on the Opus 5.5 model (claude-opus-5-5), with read-only research, review and verification sub-agents (Opus and Fable) and drafting sub-agents whose output the orchestrating session reviewed and merged.

Start here

  • What the programme delivers and how: integrated plan §1.
  • What Chris needs to decide next: Batch D1 is answered, so G0 now needs the tester names (D1-06), a date for #3987's activation (D1-03), the Q-03 catalogue subset and Chris's approval of the package; then Batch D2 before F1a (62 of Batch D's 71 questions remain open), and Batches B and C by gate.
  • How the plan was challenged: two rounds of independent adversarial review, every finding resolved in a matrix (round 1, round 2).

Read in this order

  1. Integrated implementation plan: destination, invariants, streams and lanes, small releases (S0, R0, R1a–R1d, R2a–R2d, R3a–R3d, R4a/R4p/R4b/R4c, R5a/R5b/R5c), lane releases (P1, P2, C1, C2, O1, O2, AL1, X1), the GA milestone, adoption (R6) and retirement (R7); freeze and ship gates; ready queue; programme integration; risks.
  2. Acceptance criteria: numbered, testable criteria for every release with source and status, merge and activation criteria, release tiers, the Material 3 UI standard and UX metrics, pilot criteria and user-testing rubrics, test data, fixtures, invariants and contract conformance test IDs, and traceability with the acceptance tooling.
  3. Delivery operating model: one approver and an agent workforce; streams, gates and authorisation, S0 and the M0 walking skeleton, WIP limits, review tiers, CI budget, definitions of ready and done.
  4. Versioning model: the rulebook for questions, forms, profiles, sessions, drafts, publication, reconciliation and exports under versioning.
  5. Consistency model: concurrency rules, the commit protocol, idempotency, ownership markers, fences, durable effects, ordering and as-of, the consistency matrix.
  6. Domain model and new aggregates: bounded contexts and context map, today's and new aggregates, events, commands, policies, value objects, glossary.
  7. Programme integration: current state of allocation and pool partitioning, progressive batches, review eligibility, active reviewer tracking and claims, materialised statistics, notifications, authorization and the architecture review, with strategically recommended changes and the external joins.
  8. UX strategy: research plan, UX metrics, reviewer efficiency, copy deck, design system of record, accessibility, change management and design QA.
  9. Methodology coverage: the plan measured against a high-quality systematic review, with methodology additions as proposals.
  10. PRISMA and deduplication amendments: amendments A–O to FEAT-011 and FEAT-012.
  11. Contracts: the nineteen shared contracts (C1–C19).
  12. Open questions and assumptions: decisions for Chris by batch, engineering items E1–E99, UI validations U1–U45, assumptions A-01 to A-40.
  13. Decision register: confirmed decisions with placement, superseded wording, dispositions of earlier drafts, the v10 and QM v2 crosswalks.
  14. Source and status inventory: verified implementation on main, open PRs, documents, flags, conflicting documents and defects found.
  15. UI coverage comparison, notifications integration and migration, adoption and rollback.
  16. Reviews: round 1 (A, B, C, matrix); round 2 (thirteen reviews, verifiers V2 and V3, the resolution brief that "brief §n" references in the documents point to, and the matrix, all in reviews/round-2/).
  17. Validation evidence.

Review outcome in brief

Round 1. Three independent read-only reviewers raised 102 findings, including four Blockers. Every finding was resolved, turned into a question for Chris or recorded as a labelled assumption, and a fresh-context verifier's 20 further issues were fixed.

Round 2. At Chris's request, thirteen independent Fable and Opus reviewers covered the versioning model (twice), data consistency, domain-driven design, acceptance criteria, the past year's planning, whole-application UI and UX, delivery, systematic-review methodology, and the in-flight allocation, reviewer-tracking, statistics and notification programmes; a verifier checked the three documents added after round 1. They raised 362 findings, including 12 Blockers. All are resolved in the package or turned into Batch D questions with recommendations; none was rejected. The six new documents above and the rewritten contracts, plan and acceptance criteria are the result. A fresh-context verifier (V3) then read the whole package: it confirmed all 12 Blocker resolutions and found 33 cross-document drift findings (no Blockers), all of which were fixed. Details: round-2 resolution matrix.

Chris's decisions so far (3 October 2026)

  • Fix ownership transfer now, in #3964 rather than the duplicate #3969 (D1-01); make the #3944 conversation changes (#3965). #3964 merged on 3 October 2026 (85e6facf7) and #3969 was closed.
  • Batch A answered (pilots on new and seeded projects; harvest QM v2 and #2224; naming and group authority as recommended), plus Q-25, Q-31 and Q-06a, with ASySD and outside-SyRF counts added. Q-25's tracking line rested on a false premise and is corrected (D3-16).
  • New and updated screens must be consistent, modern and Material 3; the plan must carry well-defined acceptance criteria; a published question is never permanently deleted.
  • Batch D1 approved as recommended (D1-02 to D1-09): precedence with the architecture review, activate ProjectStatistics, authorisation per freeze gate, merge this package to main as a docs-only PR, the tester panel's shape, production opt-in pilots before GA, the write-path gate, and the notification merge order.

These are recorded in the decision register §1.11 to §1.13.

Inputs and authority

  • The handoff package (outside the repository, unchanged): /home/chris/.codex/visualizations/2026/09/23/01a0cbec-0c32-7103-ab5a-bfc05665deb7/syrf-v10-review-2026-10-02/ (PLANNING-BRIEF.md, COMPARISON.md, prior-plans/, the original v10 source pack under source/design_handoff_syrf_v10/, evidence manifests and logs).
  • The owner ledger and the 2–3 October research and proposals are committed in this branch's docs/planning/.
  • Authority order: the owner decision ledger first, then recovered baselines, then proposals. Earlier drafts marked "UNAPPROVED PRELIMINARY MATERIAL" are inputs only. See precedence rules.

Package boundaries

  • This package was merged to main on 3 October 2026 (PR #3617, merge commit f5318074d) under D1-05; later changes go through ordinary docs PRs.
  • Lifetime (PROPOSAL). This is a temporary planning package (docs/planning/ is deleted when complete). As each contract freezes, its text is promoted into an ADR in docs/decisions/ or a feature spec in docs/features/, and the package section points there. Once the GA milestone ships, the package moves to docs/planning/_archive/; it is deleted when R7 (retirement) ships, keeping the owner ledger's append-only copy on main. The archive stop is a deliberate exception to delete-when-complete: adoption (R6) and retirement (R7) still cite its rationale after GA.
  • Live PR and programme states are a snapshot from 3 October 2026 (see programme integration §1) and must be rechecked before any implementation decision.