# SyRF integrated review planning: consolidated owner session

**Recorded:** 5 October 2026, Europe/London. Discussion spans 4–5 October.
**Status:** Owner decisions recorded; integration into the repository plan, dossier and status page requested. **Implementation remains on hold.**
**Destination:** Existing Claude Code session `claude-syrf-integrated-planning` on Juniper, tmux `claude:20.1`.

## Purpose and authority

Chris requests a complete handoff of this session's outputs, decisions, rationale and outstanding register entries. Integrate these into the existing plan and G0 dossier, update the status page, and produce a detailed feature specification, phased rollout plan, product-owner explanation and implementation-progress tracker. This is planning/documentation work. Do not start feature implementation, migrations, production activation, email delivery, PR closure or other previously gated actions merely because product recommendations have been approved.

This document is the current consolidation. The archived session outputs preserve chronology, examples, original recommendations and changes of mind. Later explicit owner decisions supersede earlier conflicting recommendations. Do not treat old question wording, historical counts, or an assistant's proposal as owner approval. If integration uncovers a material ambiguity, expose it once with options and a recommendation rather than inventing an answer.

The 74-entry session register now has **52 entries resolved, replaced, removed or explicitly deferred; 22 entries remain for alignment/brief/validation work**. This is the session register, not necessarily the complete repository decision universe. The older Claude status page says 89 owner decisions remain: reconcile the registers and retain every original mapping before publishing a new total. Do not simply replace 89 with 22. The condensed mapping originally covered 60 pending items and has historical counts in its introduction; this is not the current total. The latest approved decisions are collected below.

## Preserved outputs and source context

Archive these original Markdown outputs byte-for-byte with a checksum manifest:

- `syrf-remaining-planning-decisions.md`: 74 original entries, recommendations, recorded decisions and appended clarifications.
- `syrf-condensed-remaining-decisions.md`: 20 owner packages, carry-forward alignments, detailed-brief items and subsequent amendments.
- `syrf-stage-filters-and-steps.md`: terminology, examples, dynamic eligibility and audit-event requirements.
- `syrf-question-15-clarification.md`: earlier explanation, superseded by the stage-filter/step clarification.

Repository inputs previously consulted include `docs/planning/integrated-review-plan-2026-10/` (domain, contracts, versioning, consistency, migration, PRISMA, acceptance criteria, decision register and dossier), the owner ledger `docs/planning/review-form-owner-decisions-2026-10-02.md`, and feature plans for reconciliation, screening annotations/profiles, stage filtering, annotation versioning and deduplication. Also consult the unified annotation/classification research and stage-step access policy proposal. Re-check current source versions; referenced worktrees may no longer exist.

Juniper host was verified as `Juniper`; main checkout was clean at inspection, HEAD `5245941e9200110a9870fdaa01e470037e547851`. No implementation changes were made by this coordinator. The existing Claude session, not a new hidden CLI executor, is the requested recipient. Its inspected transcript shows the G0 dossier merged in PR #4013 and the status artifact at `https://claude.ai/artifact/LqQgFFmdnV5coh5nzbGpPY`. These are inspected historical facts, not approval to resume implementation. The current focus-lock script was unavailable in this inspection; no focus lock can be claimed for this coordinator.

## 1. Domain model, review work and versioning

- Keep **Study** as the project's reviewable item. Forms, reviewer sessions and reviewer targets apply to Study/form and are shared across stages. A conference abstract and journal article may remain separate project Study items under the protocol for this rollout.
- A report is a source document; a citation/reference is its bibliographic reference/import record. Preserve original imports, identities, source and import time. Do not collapse two imported citations into one fabricated original. Prepare links to multiple source documents, but defer the full workflow for linking distinct reports to one investigation.
- Do not mandate a new database collection merely because citations are distinct domain records. Earlier language mixed domain identity and physical storage and confused the owner. Specify actual storage deliberately in the brief.
- One reviewer accessing the same Study/form through several stages or tabs uses one shared session and reserved place. Original route/stage provenance remains on submitted versions; stages do not own the shared review evidence.
- Autosave sends diffs, with base-version/concurrency checks; it preserves a recoverable draft and fully reconstructable history. It does not submit or replace the qualifying completed checkpoint by itself. Explicit Save creates a checkpoint, which may be incomplete; Complete creates a completed checkpoint after full validation.
- A completed session explicitly saved as incomplete can cease to qualify. Reconciliation readiness uses current applicable evidence at query time, or a cache that stays current. Existing accepted/dependent work is never silently rewritten.
- Warn the actor before commit about which dependent work is affected and how. Inform affected authors. Preserve exact historical inputs; optionally reconsider by creating new immutable result versions.
- The form's **standard reviewer target is part of its immutable published form version**. A standard-target change creates a new form version and uses the publication-impact process, even without question changes. This supersedes settings-only treatment.
- Study-specific target overrides have separate immutable history and apply to that Study/form across routes. No step-level reviewer-target override was approved. Distinguish target minimums from enforced capacity.
- Requests for additional reviews may specify people/groups and many Studies; raise the effective Study/form target explicitly and count qualifying reviewers once across routes. General statistics use the standard target and explain study-specific exceptions separately.
- Multiple drafts are allowed; one publication operation at a time with final state recheck. Question management needs authorized presence indicators, viewer/editor avatars, live updates across views, safe conflict handling, and actor/time audit stamps.
- Question compatibility/mapping guidance can suggest defaults, but an authorized publisher explicitly declares compatibility and whether mapping is appropriate. Preserve that declaration and mapping with actor/time. Invalid or mandatory re-review constraints cannot be bypassed.
- Screening profiles also have immutable versions. Detect affected decisions/outcomes and version mismatches before publication, show impacts and confirm the treatment with a final recheck. Preserve originals; required new screening remains pending until done.
- Retain earlier publication impact rules, concurrent-draft protections and explicit status transitions. Distinguish in-form alerts caused by the reviewer’s own edits from alerts to affected reviewers when an admin publishes changes.

## 2. Duplicate merge and unmerge

Chris requires one consolidated current Study after a duplicate merge, with enough history for an easy, fully reversible unmerge. Do not describe the solution merely as two active studies linked by an alias.

- Study parent is mutable: tombstone/current-state flag plus pointer to its current immutable version. Version and operation histories are immutable. "Historical" does not mean corrupt or deleted evidence.
- Merge produces consolidated current metadata/reference links and current review associations; originals are retained as historical inputs, not independently allocated/listed/counted in current totals. Keep a stored current evidence view/projection for efficient reads, with performance and consistency proved before freezing its design.
- Atomic final commit: validate current input versions, then activate the merged version, change parent pointers/tombstones and write the merge manifest/audit together. Failure leaves the originals current. Notifications and rebuildable statistics can follow reliably without exposing partial authoritative state.
- Conflict resolution precedes commit. Same-reviewer screening decisions or annotation sessions, and conflicting accepted results, use a reconciliation-like view. Agreeing compatible answers populate resolution controls; conflicts show inputs/evidence side by side. Resolve answers and complete/incomplete status together; completion still passes validation.
- The merging user can resolve conflicting candidate contributions directly or delegate to the original reviewer, who receives a task/notification identifying the duplicate merge and exact inputs. Record the actual resolver; do not imply that the candidate reviewer made an admin's choices. Unresolved conflicts remain visibly pending.
- Merge-created result provenance says it was created from exact source session/decision versions by a merge operation, with recorded choices, actor and time. Original route/stage provenance remains inspectable through inputs.
- Show conflicting reviewer-target settings and have the authorized merger confirm the resulting effective target. Count qualifying reviewers once.
- Warn the admin about active reviewers/reconcilers, interruptions, drafts, reservations and dependency changes before confirmation; recheck at commit. Preserve drafts and prevent stale saves overwriting new state.
- Unmerge is a new immutable action. Tombstone the historic consolidated state; restore current originals with links to merge/reversal. Do not erase the merge.
- Post-merge work can be carried forward to either restored Study or left only on the historical merged Study. No automatic copy to both. Preserve provenance and the unmerge decision. Warn about accepted results using changed inputs; keep existing result versions and optionally create replacements.
- Bibliography normally comes from the reference: with one reference and no override, display transparently. Study-level fields can hold selected reference values or manual overrides, taking precedence for displayed Study metadata. Each field retains value, reference/version source when applicable, decision actor/time and system rule/user confirmation where applicable. Source references stay unchanged.
- This is duplicate handling. Do not silently merge distinct investigations or distinct reports under the deferred report-grouping feature.

## 3. Stage pool, reviewer pool, steps and history

The owner corrected a major ambiguity: there is **no separate incoming dependency gate into a stage**. Q-15's earlier two-policy choice is superseded.

1. A **stage study filter** defines the stage's Study pool. It may combine clauses on screening-profile outcomes and reconciled answers to specified annotation questions using AND/OR groups.
2. A **reviewer study pool within a stage** is a subset of that stage's current pool, restricted by the reviewer's allocation/assignment and current availability/eligibility. Optional browsing can show this pool when enabled.
3. Partitioning, allocation, capacity, availability and configured step rules determine whether/when actual work is offered. Matching the stage filter does not imply review is needed or has occurred.
4. Steps may contain screening, annotation or both; dependencies between steps and exclusion-stop rules govern progression within the stage. Applicable project-wide evidence can already satisfy these activities even if collected through another stage.

- By default a reviewer may progress after their own Include while the collective result is pending. A stage setting can require collective Include first. "Pending" does not mean ignoring an eventual Exclude; configured exclusion-stop rules remain enforced.
- New combined steps default to stopping additional screening once the profile's sufficiency rules are met; a designer can explicitly allow extra screening. Annotation may still be needed independently. Legacy stages have no existing steps: map actual behavior through the opt-in wizard rather than inventing legacy step settings.
- Independent annotation stays independent unless a dependency is configured. A collectively excluded Study with an applicable terminal exclusion rule may never be offered in the stage, even though it remains in the filter-defined pool. Already-sufficient forms/profiles need no duplicate work.
- Saved work may be completed after screening exclusion by default; a step setting can prevent it while preserving drafts. After any filter-driven departure, already-started work may also continue by default with an authorized configurable restriction. It does not re-enter either current pool or permit new reviews. Present permitted continuation separately as saved work.
- A dynamic reviewer pool removes studies that become unavailable. Retain assignment and availability history and reasons. Browsing never grants broader rights.
- Browsing preserves blinding: other reviewers' candidate contributions remain hidden. Applicable reconciled screening decisions and annotation data may be visible under configured disclosure rules.
- A valid result can make its own Study stop matching the stage filter. Accept the valid result, recalculate membership, preserve the cause/evidence and stop new offers. Leaving the pool never erases the evidence that caused departure.
- Automatic stage completion follows remaining-work rules; manually/static-completed stages remain complete even if more work appears. Show impact before relevant admin changes; manual reopening is a separate authorized action. Merge changes review evidence, not stage membership/status directly.

### Structured historical justification

This is a firm owner requirement, not an optional inference from current settings. Admins must be able to explain why a Study was available, reviewed, not reviewed, or no longer available, without assuming the platform failed.

- Current pools remain query-time/current-evidence views. Relevant current screening outcome, reconciled-answer or filter changes trigger **targeted** reevaluation of dependent filters, not every draft against every stage.
- Record initial tracking membership, subsequent entries/departures and re-entry with their causes and exact filter/evidence versions. A filter edit must find newly matching as well as departing studies.
- Record actual review-start eligibility and route, filter/version, matched clauses, source outcome/answer versions, allocations and availability rules, actor and time. Distinguish pool membership, offered work, started review and completion.
- Immutable queryable events include project, Study, stage/step where applicable, reviewer/actor, event type, effective and recorded time, causal operation, source versions, before/after state and structured reasons/clause evaluations. Design ordered/idempotent processing and current-read consistency; do not admit using stale projections.
- Queries must find all distinct studies ever entering/exiting a stage pool and individual episodes/reasons. Re-entry must not double-count distinct studies. Absence of a record must not invent a non-review reason.
- PRISMA priority is actual review through the stage and its contemporary eligibility justification. Ever-eligible/no-review pool history is separately available for audit. Filter failure is not automatically a screening exclusion. Honest baseline coverage is required; pre-tracking history cannot be fabricated.

## 4. Reconciliation, hints, blinding and screening

- Single qualifying candidate at an effective target of one can produce an automatic immutable accepted result with **Single annotator** authority, exact evidence and system-rule provenance. It is not human reconciliation or independent verification.
- Second-person verification uses the **same reconciliation mechanism**, with one qualifying candidate and required human reconciliation. Configure automatic target-one acceptance versus human checking; do not create a separate verification engine/session type.
- A new target/form policy may require a corresponding new result version; preserve history. Raising the target does not manufacture missing reviewers. Automatic acceptance of multiple agreeing candidates has not been separately approved.
- No existing reconciliation database records are assumed: the owner says the feature has not been fully implemented. Remove the hypothetical mandatory "legacy authority unknown" backfill. Validate unexpected records during migration rather than inventing them.
- Completeness follows required questions, with the agreed form override. A blank candidate comparison is **not assessed**, not disagreement or a ban on reconciliation. Unknown/Not reported are actual answers, distinct from blank.
- Annotation form owns reconciliation identity blinding; screening profile owns blinding for its manual decision/annotation reconciliation. Default blinded. Stages do not independently redefine it.
- Candidate ordering must not reveal identity through submission chronology. Hide identity-revealing timestamps; use unpredictable presentation and context-local labels without stable reviewer continuity across Studies. Real attribution remains in protected audit history.
- Show applicable reconciled annotation responses as labeled hints by default, with provenance consistent with blinding. Form can disable them; a step may hide them but cannot enable a form-disabled hint. No automatic prefilling. Explicit reviewer click-to-fill only when applicable; record exposure/copy provenance and never count this as independent evidence automatically.
- Form owns inactivity timeout and per-reviewer in-progress limits across routes/tabs. One inactive tab must not release the shared place while another connection remains active. Expiration preserves drafts. Unstarted reconciliation-assignment expiry is optional/configurable, not an imposed seven-day expiry.
- Outdated-answer handling is configurable: allow completion with warning by default, or require flagged answers addressed first. Neither bypasses validation, permissions, applicability or mandatory publication/re-review treatment. Config ownership/precedence must be detailed consistently with shared sessions.
- Screening profiles can route ties to another screening review **or a separate adjudication step**, configurable alongside screening-annotation reconciliation. Adjudication may be assigned to an authorized member/group; actual individual resolver is recorded. Pending adjudication is not a definite outcome.
- Unsure is configurable per profile, enabled in the proposed title/abstract template. It can mean not-excluded for availability without counting as definite Include. Extra-review/adjudication handling is bounded/configurable: Include–Unsure–Include yields sufficient Include under the chosen rule; Include–Unsure–Exclude or Unsure goes to adjudication. Complete the transition table, thresholds and all-Unsure behavior in the brief.
- Optional screening discussion begins after submitted independent decisions reveal a conflict. Record initial observations and exposure; corrections create new versions. Independent agreement uses pre-exposure observations; current outcomes use applicable current decisions. Disabled/unresolved discussion uses the configured extra-review/adjudication fallback.
- Multiple screening annotation questions and reason/agreement rules are configurable. A primary exclusion reason is template/reporting guidance, not a platform limit. Count distinct excluded studies separately from overlapping reason categories; document diagram-compatible configurations.

## 5. Migration, training, optional research features and external data

### Universal baseline conversion (R4)

Chris chooses one eventual writable engine, not permanent parallel legacy/new implementations or leaving completed projects indefinitely outside the new structures.

- Begin with opt-in trials in staging, then production pilots; after demonstrated parity, convert **all remaining projects**, including completed/inactive projects, to a faithful baseline in the new domain/data structures.
- Preserve existing functionality and workflow semantics; conversion is not automatic protocol redesign. Map legacy stage annotation work to forms/steps and screening to appropriate profiles/steps with explicit reviewable mappings.
- Represent genuinely uncollected history explicitly: not recorded in legacy, current snapshot only, unknown author/time/definition where actually missing, and unvalidated legacy completion. Do not fabricate versions, reviews, votes or reconciliation results.
- Later allow an in-engine wizard to rearrange baseline stages/steps/forms/profiles, including multiple steps in one stage or across stages. Use versioned publication/impact rules and explicit admin confirmation.
- Specify complete writer/reader scope, manifests, dry runs, semantic parity, exports/statistics/permission comparisons, large-project performance, retry/recovery and containment. Projects with unresolved conversion issues need remediation toward the universal target, not lossy forced conversion.
- After canonical new writes, prefer forward recovery/containment; do not flatten history into legacy. Retirement of legacy writers requires its own verified milestone. No migration execution is authorized now.

### Training and inference

- Training steps are important: admins set versioned reference/gold answers; score screening/annotation attempts using versioned rules or evaluate manually; record pass/fail, feedback and attempts.
- Configured passing can admit a reviewer to a permitted project group with reviewing access. Allow configured retry policies after failure. Preserve assessor/system attribution and actual admission decisions; no hidden privilege expansion.
- Training evidence is separate from live reviewer targets, accepted results and PRISMA counts. Explicit promotion, if supported, is separate.
- Experimental-group inference/classification starts **beta, off by default, explicit project-designer opt-in**. It enhances ordinary annotation/reconciliation, not a new parallel reviewer workflow.
- Derive explainable suggestions only from the current reviewer's own authorized snapshot or a pinned accepted Study result. Never mix unreconciled reviewers' assertions. Preserve reported answers; do not invent animal counts. Recompute/retire derived conclusions when exact inputs/rules change and preserve their history.
- Optional accepted-answer branching between steps is **outside MVP**. Reconciled-answer clauses in stage filters remain in scope.

### Reporting, methods and imports

- Label units: imported references, source documents and project reviewable Study items. Distinguish actual review from pool membership. Updated-review diagrams can include explicitly supplied previous-review counts; frozen reports remain immutable and missing information disclosed.
- Retain versioned search strategy/date/platform/limits/round and protocol amendments. Eligibility-changing publication needs the relevant amendment record.
- Full-text retrieval uses attributable Sought/Retrieved/NotRetrieved actions/reasons; a PDF presence may suggest but not silently confirm the action.
- Deliver planned exports/codebooks and estimated-value provenance. Graph digitization and external annotation-answer imports keep their staged scope; do not infer approval to activate all importers now.
- External **AI-model-generated screening decisions** are explicitly supported in the plan. No fake human login. Identify machine source separately from importing user.
- Project stores versioned AI screening model metadata; profile pins model configuration/policy; decisions reference exact model/profile/run versions, source/actor/time, training-set context, thresholds/confidence when available and explicit missing metadata.
- Profile can count AI as a contributing vote or sole required screener. Reruns produce versions, not independent extra voters. Human training labels are not independent validation of that model.
- Model Unsure can route to human adjudication, including sole-model screening. Preserve original AI output and exact lineage. Accepted imported evidence must use current eligibility/publication/history rules.

## 6. UX, access, catalogue, communications and deletion

- Prototype step selector, one form area in annotation workspace. Large/complex forms must support full annotation on **phones, tablets and desktops at launch**, with accessibility/touch/virtual scrolling/diff autosave and whole-form validation. Francesca's largest project is an explicit acceptance case, not excluded solely for size.
- Status labels must distinguish **Draft auto-saved**, explicit **Version checkpoint saved** and completion. Exact wording may evolve; meaning cannot blur draft recovery and submitted checkpoints.
- PWA exploration is **beyond MVP**, including possible caching of allocated studies. Existing manifests/mobile metadata do not establish a full PWA implementation. Installability, updates, protected-data caching, authentication and real offline synchronization require design; no offline writes authorized.
- Refresh existing/legacy screens and as many compatible new features as possible, without changing existing review-workflow semantics before confirmed conversion/redesign.
- Provide project My work, cross-project access/tab and global badge even when notifications are muted; show pending admin changes. Use the agreed tester panel, consent-based timing telemetry without answer content, and defer the full global landing page.
- Ordinary account deletion disables access; submitted named attribution remains. Joining terms should explain contribution retention. A separate identity-erasure process was not decided here; do not claim legal sufficiency without appropriate review.
- Catalogue MVP: one application-wide CAMARADES catalogue, administered by appropriately system-permissioned users. Future catalogues may have distinct permissions. Authorized direct entry/project sharing creates versioned copies with source/version/sharer provenance; project/catalogue edits do not silently overwrite copies. Other users may request catalogue publication.
- Reviewers cannot unilaterally withdraw submitted contributions by leaving/deactivating. Admins may explicitly exclude a member's contributions from current use by form, screening profile, stage or project, including from membership-disable workflow. Membership disable alone preserves validity. Preserve immutable history/attribution; reason/actor/time and impact previews are required. Stage scope needs actual provenance rather than pretending shared sessions belong to stages. Dependent results are preserved with notification/explicit reconsideration.
- Informative email may include project/study context and titles. Aliases/content respect recipient permission and blinding; answers/free text are configurable, not universally omitted. Check rights at delivery. Per-project mute preserves in-app notices. Reconciliation conversations remain permissioned audit records/export, outside candidate-answer exports and agreement statistics.
- Ordinary project deletion is reversible: hide from normal lists, block review/editing, stop allocations/notifications, release reservations and retain drafts/data/history. Authorized restoration via restricted deleted-projects view. Audit deletion/restoration; recheck capacity/eligibility rather than resurrect stale reservations. **Permanent physical erasure is a separate unapproved policy.**
- Active-work impact previews apply broadly to admin actions affecting reviewers. Explicit Apply anyway can release incompatible reservations after a capacity reduction, while preserving drafts. It cannot bypass permissions or legal configurations.

## 7. All 22 remaining session-register entries

These are not 22 new owner questionnaires. Preserve IDs and assign them to brief/evidence work; bring only genuine scientific/product choices back to Chris.

| ID | Remaining treatment |
|---|---|
| Q-23 | Align reporting-unit distinction and deferred report/investigation grouping. |
| D4-08 | Specify prepared multi-source links, Study-owned work and deferred distinct-report grouping. |
| D3-17 | Specify capacity vs targets, defaults and audited reservation effects. |
| D3-18 | Align form-owned timeout/limit/shared connection rules; remove obsolete stage-derived rules. |
| D4-06 | Methodologist verification of SYRCLE/CAMARADES/ARRIVE templates and applicability. |
| D2-10 | Tested publication active-work protection, measured pause/operation limits. |
| D2-13 | Isolated point-in-time recovery specification and rehearsal with manifests/evidence checks. |
| Q-17 | Obtain scientific event-count field/meaning specification from Chris/methodologists. |
| Q-16 | Denominators, percent agreement and statistical review of multi-rater formulas. |
| D4-12 | Screening agreement methods using initial independent observations/profile granularity. |
| D4-21 | ASySD parity/performance methodology; F1 ≥0.99 and 80k citations under one hour are proposals, not approved/achieved. |
| D3-01 | Visual roles/themes, dark-mode/staging checks and baselines. |
| D3-02 | Design review checkpoints and risky-screen previews. |
| D3-09 | Paused eligibility programme alignment with owner step/filter/preserved-work rules. |
| D3-10 | Authoritative source-pinned progress stats and protected pilots; production readiness remains provisional. |
| D3-11 | Rebuildable agreement projection with source watermark and measured budget, separate from progress stats. |
| D3-13 | Allocation/batch contracts, denominators, performance and distinct structured activity events. |
| D3-16 | Shared-form capacity/load/statistics pilot before broad rollout. |
| D3-19 | Annotation reservation after personal Include, preserving screening if capacity unavailable. |
| D3-20 | Active counts/own place vs authorized Monitor identities, respecting blinding. |
| D3-21 | Notification environment/family/pilot gates, test email sink and delivery pause. |
| D3-23 | Consistent notice resolution/unread counts with retained history. |

Additional boundaries remain explicit: permanent physical erasure is not approved; multi-candidate automatic agreement acceptance is not approved; exact PRISMA mapping, statistical methods and scientific event definitions need specialist input. Do not mark these done merely because the product batch is closed.

## 8. Integration work requested from Claude

1. Read this consolidation and every archived output; resolve older conflicting text using final owner decisions. Map all 74 session IDs and condensed packages into the larger repository ledger without silently losing or approving an item.
2. Produce a coverage matrix: owner decision → specification section → contract/domain entity → acceptance criterion → workstream/release/gate → progress tracker row. Include superseded wording and rationale.
3. Update integrated-plan, domain/contract/versioning/consistency/migration/PRISMA/UX/methodology/acceptance documents, owner ledger and G0 dossier as appropriate. Identify all amendments caused by target versioning, consolidated reversible merge, baseline migration, stage pools and AI imports.
4. Create detailed specification(s): entity/storage model, version identities/pointers, transactions and derived views, read/write lifecycle, authorization/blinding, active-work impacts, failure/recovery, user flows, rollout/adoption and measurable acceptance evidence. Illustrate entities and what loads/writes when in plain English; the owner found vague policy names confusing.
5. Produce a product-owner guide that separates baseline/MVP, later opt-in beta, deferred enhancements and specialist decisions. Explain practical examples rather than implementation jargon.
6. Produce a detailed rollout/dependency plan and durable progress tracker suitable for eventual implementation. Each row needs scope, owner, dependencies, brief approval, implementation authorization, PR/status, evidence and blockers. Never equate approved product design with work started, gate passed or production enabled.
7. Update the **existing** status artifact and dossier to reflect these decisions and the implementation hold. Preserve existing answers/data and historical counts; reconcile totals, do not reset the answering database. Keep frozen/report audit history intact.
8. Validate cross-document consistency, IDs/anchors/nav and traceability. Report residual questions and proposed thresholds without restarting the giant questionnaire. Use repository-required isolated `pr/pr<number>.<slug>/` worktrees for tracked changes; keep main clean. Follow existing docs validation and review gates. No unrelated programme changes or dormant-PR closure in this request.
9. Return exact updated paths, validation results, decision counts with scope, residual owner inputs, dossier/status links and a short plain-English progress summary. Do not report implementation as authorized.

## 9. Relevant existing memories and delivery caveats

Inspect current memory/source rather than assume it is fresh: `integrated-review-plan-2026-10-status.md`, `plans-need-acceptance-criteria.md`, `new-ui-material3.md`, `validate-docs-skip-indexes.md`, `feat024-materialized-stats-status.md`, `stage-review-redesign-status.md`, `qm-v2-stack-status.md`, `review-eligibility-implementation-status.md`, `proportional-allocation-program-status.md`, `syrf-worktree-location.md`, `no-production-promotion-without-approval.md`. These are under `/home/chris/.claude/projects/-home-chris-workspace-syrf/memory/` at inspection.

The inspected Claude recap reports FEAT-024 write latency still failed on an idle-host rerun. This session did not validate or fix that benchmark. Staging/prod dates remain conditional; do not turn a suggested following-week production target into a commitment. Existing tester scope is retained, not expanded by this handoff. No fresh production database interrogation occurred here.

## Resume request

Integrate this owner-session bundle into the SyRF integrated-review plan, dossier and existing status page; produce detailed specifications, rollout plan, product-owner guide and progress tracking. Keep feature implementation on hold. Reconcile all final decisions and outstanding IDs before making counts or approval claims, and expose only genuine unresolved inputs.