Allocation delivery continuation

This continues the authoritative STATUS.md recovered from Claude Code session 18d15a4e-a819-4155-832a-260bc27aa8c6, "PR 2991 review and approach study allocation". Implementation and PR shipping are authorized; feature activation is not implicitly authorized. The user prefers deployment-run migrations over extending runtime schema-version branches; membership-first compatibility/migration implementation is authorized after the current allocation PRs ship, but live database execution remains gated. The acceptance contract maps the complete ledger to observable behavior and required verification evidence.

Required slices and dependency order

Slice	Acceptance boundary	Dependency / current work
Direct endpoint enforcement	Ordinary direct reads and saves honor the same allocation as next-study; saved-work exception cannot bypass new-work enforcement	PR #3211 merged, including review-driven retry-boundary hardening
Reviewer visibility	Own assigned studies, bounded paging, saved-work links, assigned/completed/in-progress/remaining counts, clear enabled/paused states	Depends on enforcement; read API and stage overview UI implemented and integrated for validation
Administrator visibility	Configured slot share versus actual assigned/completed counts and progress; stale membership identities visible only to stage designers	Shares read queries with reviewer view; no new dashboard framework
Editor consistency	Persisted reviews-per-study reflected without discarding unsaved shares; combined dirty saves cannot navigate away after partial persistence	Independent PR #3212, addressing #3095
Membership lifecycle	Useful pause visibility now; membership recovery mutations need the requested deployment-run migration design and a corrected #3048	Membership-first implementation authorized after current PRs ship; live execution/activation gated
Third-party stage authorization	Faithful validation that each configured reviewer can open the stage	Canonical out-of-request, cross-provider group resolver remains unavailable; do not approximate with empty claims
Rollout validation	Test a two-reviewer split, out-of-share denials, saved resumption, stale membership, reconciliation and rollback	After required UI/enforcement merge, separately authorize preview activation; staging/production remain separate

Independent editor work ships separately. Backend and UI use separate worktrees while being built and are integrated into one usable visibility PR, based on the enforcement work. Merges use dependency order. Cleanup must not stash, merge into, or remove another active writer's worktree; synchronize this stream's worktrees at agreed clean checkpoints.

Read model semantics

• New reads use the existing default-off proportionalStudyAllocation flag and server stage policies: reviewers can read their own page; stage designers can read team progress.
• assignedCount counts distinct studies in the reviewer's allocated unexcluded bucket set, plus preserved own ordinary saved sessions in the same stage. Saved excluded studies obey the stage's hide-excluded setting. Multiple sessions do not inflate study counts.
• completedCount counts those studies with a completed own ordinary session; inProgressCount counts saved work without a completed session; remainingCount = assignedCount - completedCount.
• availableCount is currently startable new work under the existing capacity and runtime in-progress-limit guards; a tracked reservation already held by the reviewer is resumable, not new work. Legacy tallies use the atomic guard's candidate-count fallback. Direct links at the in-progress limit retain only the actual incomplete-session exception. Availability is not interchangeable with remaining work. Configuration percentages are shares of review slots, not percentages of studies.
• Stale configuration has no new assigned buckets; preserved saved work stays visible. The UI says paused, never that all work has been completed, and warns that the displayed counts no longer describe the original split. Shares are never redistributed automatically.
• Lists are bounded and deterministically ordered; counts are calculated in MongoDB, not by downloading a whole project into the browser or issuing a query per reviewer.
• Counts are snapshots refreshed on navigation or explicitly. Direct opening/saving still revalidates access. This slice adds no live event stream, materialized collection or migration.

Validation

• Core, controller and repository regression coverage for allocation, exclusions, duplicate saved sessions, stale state, capacity, pagination and flag/authorization boundaries.
• Angular tests for reviewer/admin permission separation, loading/error/empty/paused states, saved links, bounded pagination and discarded stale responses after stage/permission changes.
• Generated OpenAPI/client consistency, focused lint, theme-migration contract, web build, relevant full suites and documentation validation. Record baseline failures explicitly.
• Review and CI gates for each PR before merge; no claim of live-environment verification from local tests alone.

Local validation evidence

Local visibility validation (2026-09-05): full web suite 4,747 passed across 351 files, including 27 allocation UI cases after review-driven request separation; production Angular build and generated-code validation passed. The full integrated API suite passed 1,246 tests, including PR #3211's later save-retry hardening and runtime-limit propagation; core passed 2,116 tests / one existing skipped, and 25 allocation repository cases passed against isolated MongoDB 8. Focused changed-file ESLint, Prettier and the Material migration-boundary check also passed. Live browser/environment validation is not claimed by these checks.

Decisions that remain explicit

1. Membership migration: the recovered handoff reserved schema-0 compatibility versus schema-1 migration to the user. On 2026-09-05 the user instead selected a membership-first transition away from runtime schema branching toward explicit migrations automatically applied to the deployment's environment database. Implementation is authorized after the current allocation PRs ship, not live execution of an unspecified migration. Existing migration/deployment machinery, old/new writer compatibility, idempotence, locking, rollback and exact database binding must be established first. #3048 is also conflicting and has unresolved live-stream/cache/ reinvitation/owner-transfer concerns; its current implementation must not simply be merged.
2. Authorization authority: Identity stores application groups, but its admin user endpoint does not expose a canonical resolver usable across current identity providers. Current request authorization also combines token claims and stored investigator roles. A service must preserve those semantics before configuring another person's stage access can be validated reliably. Current administrator guidance requires verifying actual stage access.
3. Activation: no environment flags, credentials, runtime overrides or production data are changed by these delivery PRs. Preview/staging/production activation remains an explicit gate.

Required performance evidence and progressive enhancements

Representative production-scale query measurement is required rollout evidence (ledger 9), including the new reviewer/admin reads. The handoff specifies no numeric latency budget; record results and that gap rather than inventing a passing threshold. Plan memoization is a conditional optimization informed by those results. History-aware rebalancing is a later capability; the initial release retains fixed shares after review starts. Reserve/onboarding policy awaits specified review-slot semantics. Co-allocation optimization and a broader dashboard remain explicitly deferred until usage demonstrates value. None is silently folded into the initial visibility PR.