Allocation acceptance and completion evidence

This is the acceptance contract for the required continuation in STATUS.md, reconciled with the original #3202 handoff and design. Passing focused tests, merging a dormant slice, and accepting the live feature are different completion states. The existing default-off flag remains unchanged until a separately authorized rollout.

Required behavior and verification

Ledger / outcome	Observable acceptance, including failure paths	Verification and evidence required
Foundation: deterministic assignment	A study's stable bucket is identical across reloads; each bucket has exactly the configured review count of distinct reviewers. Slot shares sum to 10,000 basis points; caps/rounding support an equal three-way split without duplicate reviewers per bucket. Omitted/zero-share members get no new ordinary work.	StageWorkloadSharePlanTests, configuration and bucket-filter tests; include rounding, invalid totals, duplicate/inactive reviewers and invalid target cases. Do not equate a percentage of review slots with a percentage of studies.
1: consistent new-work enforcement	New ordinary next-study, direct GET and session PUT apply the same eligible-bucket policy with tracking both on and off. Out-of-share direct requests return 404 before usage/reservation/save side effects. Route/body stage and session mismatches are rejected when flagged. Screening, deletion and reconciliation retain existing behavior.	StageWorkloadShareEligibilityTests, ReviewControllerAllocationTests, SubmitAnnotationSessionAllocationTests, existing assignment tests; API-level denial and zero-side-effect assertions. #3211 merged as fdc79576c; retain its save-retry regressions in integration.
1: saved work survives	Own ordinary saved work in the same stage can resume outside current buckets; a PUT exemption requires the exact saved session ID and must still exist on each freshly loaded retry. Another reviewer's/stage's/session's data cannot grant access. Reconciliation remains unfiltered. Existing reservation resumption follows its existing next-study path; a reservation alone is not a direct-endpoint exemption.	Tests for completed/incomplete saved work, forged IDs, deleted saved sessions during a concurrent retry, stale allocation and bucket exhaustion with unfinished saved work. Preservation never bypasses ordinary project/stage authorization or reactivates a deactivated member.
Disabled/rollback behavior	Runtime flag off and unconfigured/disabled allocation retain legacy new-work behavior, including legacy submission identifier handling. Flag rollback hides the new visibility reads (404) and UI, but configuration GET and otherwise-valid disable remain available. Existing review activity still prevents changing/disabling persisted allocation. Stored buckets/indexes and saved work remain intact.	Existing StageWorkloadSharesControllerTests, enforcement/read-controller and UI flag tests; preview flag-on/off/on smoke with the same stored data. Distinguish runtime flag off, allocation disabled, stage disabled and stale allocation.
Configuration invariants	Only authorized designers configure an inactive annotation-only stage before any saved session or outstanding reservation exists. Invalid totals, duplicate/inactive members, incompatible modes and stale expected versions cannot publish. Reviews-per-study/modes stay locked while allocation is enabled. Legacy bucket preparation completes before publication; failed backfill/publish evicts stale cached state and does not partially publish.	Configuration/domain/controller and Mongo backfill tests; assert 400 versus version/activity 409 responses and no partial persistence. Backfill is project-scoped, idempotent and cannot be undone by a legacy loaded study save. Keep documented target-enforcement-off capacity limitations visible rather than promising exact realized shares.
2: reviewer visibility	Only a stage reviewer sees their own assigned page, stable bounded paging, assigned/completed/in-progress/remaining/startable counts and valid saved-work links. Loading, disabled, inactive, empty and paused states are distinct; paused is not misreported as complete. A shrinking last page remains navigable. Revoked permissions/stage changes cannot display late responses.	StageAllocationReadControllerTests, StudyRepositoryAllocationReadTests against MongoDB and allocation-progress Angular tests; authorized preview walkthrough with two distinct users. Verify paging limits/invalid parameters and no cross-user/project/stage disclosure.
3: administrator visibility	Only stage designers see per-reviewer slot shares, actual assigned/completed counts, progress and inactive-member identities. Zero activity is observable without claiming a time-based alert. Reviewer-only pagination neither cancels nor refetches the admin aggregate; explicit refresh updates both. Stale counts are identified as preserved work, not the original split.	Controller authorization tests and dual-role/admin-cancellation UI regressions; inspect as reviewer-only, designer-only and dual-role users. Counts must reconcile with the same controlled Mongo fixture and saved sessions used for the reviewer view.
⅔: count definitions	Count distinct studies, not duplicate sessions: assigned is allocated unexcluded work plus eligible own ordinary saved work; completed requires a completed own ordinary session; in-progress is saved without completion; remaining = assigned - completed. Saved excluded work respects hide-excluded. Available means currently startable new work, not remaining or a tracked reservation already held. Honor the runtime in-progress limit and legacy capacity-tally fallback; only actual incomplete saved sessions bypass the direct-opening limit. Inactive/stale stages offer no new startable work.	Mongo integration fixtures cover duplicate sessions, exclusion visibility, capacity (including legacy tallies), runtime in-progress limits, reservations, inactive stage, stale membership and pages; independently calculate fixture totals and compare both endpoints. No full-project browser download or one query per reviewer.
4: membership lifecycle	Deactivating a configured reviewer pauses new work predictably, shows actionable reviewer/admin guidance, preserves saved data and never silently redistributes shares. Recovery follows the existing immutable-after-start rule; no hidden rebalance. Deactivation also revokes live access/presence and invalidates active-aware caches/summaries; duplicate invitation and inactive-owner transfer cases must not restore access incorrectly.	Pause behavior is covered by enforcement/read/UI tests. Full lifecycle requires corrected #3048 regression/integration coverage and preview deactivation/reactivation/recovery exercise. This is not complete merely because paused-state UI is merged.
5: third-party stage eligibility	Configuration and eligible-reviewer listing faithfully evaluate each candidate's actual stage-review authorization across supported identity providers, stored roles and application-group claims. Reject inaccessible positive-share assignments without falsely rejecting authorized users; failed authority lookup cannot publish an unverifiable configuration.	Cross-provider authorization contract tests plus candidate listing/configuration API tests. The canonical out-of-request authority is currently missing; record this as unfinished, not satisfied by an empty-claims approximation or an admin warning.
6/7: editor save consistency	Effective reviews-per-study changes refresh validation without losing dirty shares; late GET/PATCH ordering cannot restore an older target. Concurrent stage/allocation saves and incompatible combined navigation SAVE cannot report success or navigate after partial failure. Provide a usable explicit resolve/save/discard path and preserve dirty data on failure.	#3212 component regressions for both response orders, pending writes, direct Review Settings Save, incompatible modes, stale responses after stage changes, save-token reuse and server rejection. Confirm the complete user workflow after integrating both PRs.
9: representative performance evidence	Measure next-study bucket selection and new reviewer/admin read queries on a documented representative study/reviewer/session distribution, including zero-work and stale cases. Record cold/warm latency, query plans/index use, documents/keys examined, server memory and scaling as reviewer count increases. No timeouts, oversized aggregation results or unbounded application-side materialization at the tested scale.	Reproducible synthetic/non-sensitive fixture, environment/image/index details and repeatable command/report. Compare enabled versus legacy baseline and the applicable service budget. The handoff supplies no numeric latency SLA: document that gap rather than inventing a passing threshold. Measurement remains required rollout evidence; memoization/materialization is conditional on results.

Membership migration acceptance

The user selected membership first, then other storage fields on 2026-09-05. Implement the compatibility/migration/contract sequence after the current allocation PRs ship; this does not authorize live migration execution or a global schema-version switch.

• Before adopting canonical activity reads, validate raw layout semantics: schema-0 Registrations with missing activity is active; schema-1+ Memberships with missing activity is inactive. Preserve explicit supported Boolean states. Schema-0 explicit false, malformed fields, unsupported versions and contradictory layouts stop for resolution. Explicitly initialize new memberships active without changing historical defaults.
• Retire/drain all incompatible readers and writers, including background/seed/restore/admin jobs and in-flight requests; block incompatible rollback/restart. Preserve unrelated storage layouts, allocation configuration, annotations and audit/concurrency semantics.
• Missing-only raw backfill updates are bounded, resumable and guarded by source version, atomic version increments and enforced ownership fencing. Concurrent project edits retry from fresh data. Repeated execution is a no-op after invariant verification.
• Wrong target, changed checksum, lost ownership or invalid data stops the dependent rollout. Bind receipts to the actual database and an independently expected deployment/restore incarnation: a receipt copied in a snapshot cannot prove readiness.
• Cover empty, mock, snapshot, existing/preserved databases and staging/production deployment paths. Drain/reset cached state before activation. Test cancellation/resume, competing jobs, concurrent writes, restored receipts and refused incompatible rollback against isolated MongoDB and deployment rendering/readiness checks, then the separately authorized preview environment.

Integrated delivery, ownership and rollout

1. One writer per worktree. Enforcement owner ships #3211; editor owner ships #3212; integrated read-API/UI owner ships #3213. The parent owns acceptance/remaining-ledger review and subsequent membership work. Exchange committed changes at clean checkpoints; never stash, reset, sync or remove another active writer's worktree. No implementation in main.
2. Dependency order. #3211 must merge before #3213. #3212 is independent but must be integrated with visibility before declaring the editor-to-reviewer workflow accepted. Membership implementation follows these slices; deployment follows compatible-reader/writer retirement, migration verification and corrected lifecycle behavior. Do not blindly merge the old #3048 or stale #3202 documents over the updated ledger.
3. Shipping gates. Each exact candidate head has all required CI complete/green, active independent review covering that current head, active review threads resolved, no outstanding change request, accurate metadata and a clean tracking worktree; use the authorized ship-pr merge-commit workflow without bypassing coverage, hooks or policy. A review fix restarts the relevant validation/CI and independent review gates. Administrative /approve does not replace a substantive current-head review.
4. Post-merge integration. Verify merged SHAs/contents on one owned clean checkpoint, regenerated OpenAPI/client consistency, full API/core/web regressions and production web build appropriate to the combined changes. Re-run the focused editor/enforcement/visibility cases together; report existing skips/baseline failures separately. Remove only this stream's retired clean worktrees after checking for active writers; retain evidence and user work.
5. Preview acceptance. Record environment/database identity, image/commit, both relevant flags and stage configuration. Two real test identities configure and exercise a split; compare next-study, direct access and attempted forged/out-of-share writes; verify saved resumption, completion/counts, exhausted buckets, exclusions/capacity, stale membership, reconciliation and designer-only data. Check failure/retry paths and actual browser behavior, not only mocked API responses. Do not use real production reviewer data for this fixture.
6. Rollout and rollback. Keep flags default-off until explicitly authorized. Preview evidence and representative performance results precede staged activation; staging then production are separate environment steps. Verify flag rollback restores legacy selection without data loss and preserves permitted configuration read/disable. Database rollback must never run an incompatible writer or reactivate members. Record recovery instructions and outcomes.
7. Completion ledger. Record each required outcome as implemented, locally validated, merged, environment-validated or blocked, with PR/SHA, command/result and evidence location. Do not mark full feature delivery complete while lifecycle, faithful authorization, representative performance or required rollout evidence remains outstanding.

Current evidence and actual gaps

Enforcement #3211 is merged. Visibility #3213 and editor #3212 are undergoing review/shipping. Integrated local evidence before the latest UI review fixes: API 1,244 passed; core 2,116 passed / one existing skipped; isolated Mongo allocation reads 13 passed; web 4,742 passed; production web build, generated-code, focused lint/theme and docs checks passed. Per-PR follow-up results supersede these snapshots; they do not constitute live acceptance.

Still missing: completed membership migration/lifecycle implementation, canonical third-party authorization, representative performance report, combined post-merge validation and authorized preview/staging/production acceptance. The numeric performance budget is not specified in the source handoff. No feature flags, live database records or deployment settings were changed by this acceptance audit.

Progressive enhancements

Ledger 8 (memoization) is a conditional optimization, not a substitute for measurement. Ledger 10 (history-aware rebalancing) remains a later capability; immutable-after-start allocation is the required current behavior. Ledger 11 (reserve/onboarding) awaits specified review-slot semantics. Ledger 12 (co-allocation optimization and a broader dashboard) requires evidence of user value. None is silently added to the current delivery boundary.