Release15 Completion Plan

Finish the guest game and admin release with10 players

1 November 2026 stopped-work record

The operator stopped product release work and deleted the recurring progress timer. The deadline report and supporting evidence record the exact-source local success, incomplete hostile reviews, subsequent staging migration/status fix and unfinished hosted release. This document's earlier checkpoints remain dated history. Later documentation refresh, wiki publication and Git synchronization do not resume product development, tests, reviews or deployment, and do not establish contest submission or requirement satisfaction.

Current operator authorization:31October2026, "Set max players to10". This supersedes the earlier15/25-player current release targets. Preserve those original plans, requirements snapshots and failed/passing receipts as dated history. The separate25-observer limit remains. QBrain is authoritative; docs/evidence/release10/qbrain-before.json preserves the full19-record pre-amendment state and qbrain-update-receipt.json records the atomic current-scope amendment/readback. Changed criteria remain unsatisfied pending fresh exact-source validation and independent review. This canonical filename stays unchanged for existing links. CAP15-LEGACY is a stable historical criterion ID whose current text now specifies10-player compatibility. No extra approval question is needed for this explicit implementation request.

Intended result and scope

Guests can create and join rooms with2 through10 players, play eight synchronized rounds through the actual browser UI, and see the same final ranking. Continue the existing guest-only public game, fixed-owner GitHub admin authentication, admin-only PWA, private historical member profiles, content moderation and word/hint administration, whitespace and invitation-copy corrections. Complete the current-source verification, requirements/documentation publication, independent review, staging verification and production deployment. The operator's latest30October reviewer amendment selects Cline with model Beam at High effort until Monday,2November2026; it supersedes the earlier Cursor/Grok and Claude Opus selections for this interval. The latest instruction specifies no exact expiration hour. Do not revive the retired public authentication, public installation or role-delegation features.

Capacity and compatibility contract

1. New room capacities are integral numbers2 through10. The UI states the same range and preserves its existing creation default4. Public rules metadata is2.8 dated31October2026; historical2.7/30October receipts remain unchanged. Server domain validation and forward database safeguards reject larger newly created rooms and new match rosters. Preserve the existing25-observer limit and permissions.
2. Existing running matches, including historical larger rosters, remain readable, replayable and finishable. Existing members can leave. Preserve every historical room, match and result; no deletion, forced eviction or destructive backfill.
3. A legacy waiting/countdown room with more than10 players does not start an oversized new match or admit another player above10. Its UI explains the changed capacity and keeps Leave available. Membership/readiness deadlines must not silently remove players to force compliance. A legacy room with at most10 players may start an allowed match; compute its effective available capacity safely.
4. Existing migration files001..013 remain byte-identical. Add new forward014 insert/update safeguards that allow unchanged historical capacities and existing match updates. Test the distinction between new inserts and historical updates against real PostgreSQL.

Traceability: FR-ROOMACCESS-001#AC-01/02/24/CAP15-LEGACY, FR-LOBBYLIFECYCLE-003#AC-01/02/24, FR-ANCHORSELECTION-007#AC-04, FR-CATEGORIES-005#AC-04, TR-ROOM-CODES-010, TR-ANCHOR-RANDOMNESS-013, TR-FREETIER-OPERATION-021#DEC-20, TR-MULTIPLAYER-INTEGRATION-034#TR-34-C01, TR-ROOM-SYNCRECOVERY-038#LIVE-07; mapped existing TEST records retain IDs. The reduced service matrix is9 games,54 player participations and432 accepted round solves. The maximum audience is10 players plus25 observers (35 total).

Implementation and test sequence

###1. Capacity contract and tests before production edits

Write the actual boundary/legacy assertions with independent correct and intentionally incorrect providers before modifying the implementation. Record the green mock gate, every rejected negative control and source hashes. Cases cover all9 allowed capacities,1/11/15/25/fraction/string rejection, random anchor endpoints, new11-player match rejection, concurrent final-seat admission, observer25, legacy waiting/countdown/playing behavior and truthful UI notices. Bind the same expectations to the production code. Source changes remain localized to existing room/match/lobby/application projections, room creation/display and a new migration. Run the code-verification hook immediately after each TypeScript source edit.

Current capacity test entrypoints are documented in testing. Keep Run-Capacity15MockGate.ps1 and Run-Capacity15SqlPublicMockGate.ps1 unchanged as historical producers, reproducible only with their matching pinned historical source, not current tests. Use the four current application/UI test entries and two independent fixture files linked there, plus Run-Capacity10SqlMockGate.ps1 and Run-Capacity10FixtureMockGate.ps1 for their respective mock boundaries. Preserve the original40-case chronology and later42-case post-implementation shrink-to-limit extension as distinct dated evidence; fresh whole-source gates remain required.

###2. User-facing propagation and whole-source verification

Update public landing/rules and current release documentation, preserving historical receipts as history. Update live/service fixture ranges and explicit expected matrix totals. Correct evidence scripts' stale denominators from actual results, while continuing to reject zero tests, failures, skips and provenance mismatches. Preserve the existing known chronology exceptions; later passing controls do not rewrite their order.

Run scripts/Run-ReviewFullValidation.ps1 -ReportDirectory <fresh-directory> for typecheck, lint, all unit/component/contract tests, disposable PostgreSQL integration, production build and all active browser cases. Run scripts/Run-ReviewPowerShellEvidence.ps1 -ReportDirectory <fresh-directory>. Supplement the full runner with tests/integration/run-phase1.ps1 -Realtime -ReportDirectory <fresh-directory> because the ordinary PostgreSQL lane excludes the actual Realtime suite. Test against a committed frozen source state and compare source manifests before/after. Do not label a dirty run as exact-commit evidence. The earlier full-suite receipts predate current changes and remain historical.

###3. Actual multiplayer browser validation

Run scripts/run-local-ui-integration.ps1 -PlayerCounts 2,3,4,5,6,7,8,9,10 -MaxMinutes 90 in a separately owned local runtime. Use the actual UI for readiness, category selection and answers, actual private Realtime and TLS PostgreSQL, at most two simultaneous answer UIs and explicit condition-based synchronization. Preserve individual results immediately before a subsequent run can overwrite fixed-name report files. Require every game to finish eight rounds with correct UI totals/rankings and truthful cleanup. Also run the strict private-push case for observer/reconnect/renewal behavior. Local results do not prove hosted or physical-phone behavior.

31October2026 readiness-driver proposal, currently deferred under the10-player amendment: root will decide whether to activate this after the hosting mock state is known. If activated, all actor preparations must settle successfully before any Ready action. Keep earlier Ready callbacks serial, then start the final two callbacks together and own both until they settle, including synchronous failures. This removes the controller's dependency on the penultimate actor's full acknowledgement before allowing the final actor to act during the specified five-second holdout window. It does not guarantee either actor meets that window. Preserve every actor's actual UI action, identity/payload checks, conflict retirement, acknowledgement, roster checks, unchanged assertion bounds and cleanup. Do not change product deadlines or treat this correction as a fix for the separate earlier15-player gameplay acknowledgement failure.

If root activates that deferred correction, before changing the helper extend the independent readiness contract and correct/wrong providers to prove delayed penultimate acknowledgement permits final callback entry, earlier callbacks remain serial, both final callbacks drain after failure, synchronous failure cannot prevent ownership of the sibling, preparation failure launches no Ready actions, and2/10-player boundaries retain actor identity. Capture a green mock gate with rejected negative controls, then bind the same cases to the helper. Trace this harness correction to FR-LOBBYLIFECYCLE-003#AC-31/32, TR-ROOM-SYNCRECOVERY-038#LIVE-07 and TEST-ROOMSYNC-139#LIVE-07; it adds no product behavior or requirement satisfaction claim. Retain the failed diagnostic and its corrected native-message classification in classification.json. The observed13-player roster loss is consistent with holdout removal; the exact removed actor/deadline event was not retained, so that causal inference remains qualified.

###4. Requirements, documentation and evidence reconciliation

Read authoritative records/mappings back, associate current exact-source tests and criteria, export the supported QBrain wiki and publish intended pages to https://github.com/sharpninja/wordpairs.wiki.git while preserving unrelated pages. Follow the existing refresh-docs workflow. Address round6's evidence-provenance and documentation-drift findings across the entire chain, including committed producers, parent/producer run IDs, report hashes, README and deployment plan. Preserve raw receipts privately when they contain credential-bearing context; commit only verified safe exports. Do not publish credentials, private session files or historical marker content.

###5. Cline and Beam High independent hostile review

Before launch, produce a source-pinned holistic self-review: user outcomes, authority/privacy, lifecycle, concurrency, boundary and legacy behavior, traceability, docs and deployed-artifact claims. Supply full TRX files for every unit test and the scoped integration/browser lanes, with native reports, run IDs, hashes, host, source revision and commands. Verify the launcher checks this evidence and the self-review before running.

Use Cline with model Beam at High effort, verifying the supported model identifier and runtime receipt before making a model claim. The reviewer uses its documented matching QBrain plugin identity and reviews read-only without building or running tests. Save request JSONL, the complete response stream, periodic progress entries and final full verdict; the reviewer logs its own turn and proves the entire verdict was persisted. No review timeout or size cap; terminate only after more than30 minutes without any stream update. Address findings contextually and inspect sibling paths, not merely the cited lines. Report every FAIL and UNKNOWN. Only AGREE with accuracy and completeness each at least98% permits tracked done claims. The latest historical Claude round6 remains DISAGREE97/95 until superseded by an actual new result. The temporary reviewer selection applies until Monday,2November2026, without an invented exact-hour cutoff.

###6. Staging then production

Inspect current provider state and existing migration history through the connected provider tools. Preserve the selected topology: wordpairs is staging and wordpairs-j9jf production, each a separate production-target Vercel project and isolated Supabase database. Deploy exactly the reviewed commit; prevent automatic Git integration from skipping staging. Apply pending forward migrations to staging, verify privacy/capacity/schema and real multiplayer behavior, then apply the same migrations and reviewed code to production. Use only existing authorized free-tier resources. Do not run destructive acceptance fixtures against production.

Verify live public guest-only behavior, lack of public install controls, privileged-link exclusion, clipboard invitation handling, real private push/deadline progression and the admin sign-in/manifest boundaries. A fixture-only GitHub OAuth result or Chromium installability result does not prove live consent, standalone phone cookie continuity or OS installation. Keep any unavoidable physical-user observation explicit rather than asserting it happened. Retain all submission/HV evidence and update the current release record with actual source and endpoint evidence.

Exit criteria

The10-player cap is enforced consistently, existing data survives, every supported count completes the required real browser game, the applicable suites report zero failures/skips, QBrain/docs/wiki match, and the currently selected independent reviewer reaches98/98 AGREE. Finish staging before production and report exactly which hosted behaviors were observed. No test count, local pass or deployment URL alone establishes completion of the game or its review.

##1November2026 shipment authorization

The operator explicitly directed: "I need you to get it wrapped up with the bugs. As long as it's not breaking the UI, just push it". For this bug-fix shipment, proceed using the existing exact-source UI regression evidence without waiting for another hostile-review acceptance. This is a shipment-specific exception to the Step5 review prerequisite and the review portion of the exit criteria, not an accepted hostile verdict or a requirement-satisfaction claim. Preserve all previous reviews, including the latest Cline/Beam DISAGREE with accuracy70 and completeness55, and their complete receipts.

Keep the staging-first rollout, forward-only migrations, existing-data preservation, guest/admin separation,10-player cap and honest hosted verification. A required provider reauthentication remains an external action; publishing Git changes does not establish a live deployment. The operational empty-pending-migration status correction changes no application UI behavior.

##31October2026 hosting catalog corrective increment

Read-only hosted preparation found that the current hosting planner's filename suffix filter excluded the digit in existing 014_capacity10.sql. Local SQL harnesses loaded all SQL files, while the hosted catalog omitted014. This disconnect must be corrected before a new frozen candidate or hosted migration status/apply. Existing TR-SCHEMA-PROVISIONING-023#TR-23-C01/02 and TEST-SCHEMAPROVISIONING-123#TR-23-C01/02 cover this bug; no new product requirement or satisfaction state is introduced.

The corrective plan preserves six history-case objectives, adds two direct catalog cases and independent omission/invalid-name controls, and requires their green mock gate before the minimal suffix-class correction. The existing six TypeScript hosting-plan cases also need their later-extension expectations to include014 and independent mock discrimination before that production edit. Planner report expectations become8mock/8real and the PowerShell evidence wrapper50 total cases. Preserve all prior native receipts and001..014 SQL bytes. Root owns the subsequent frozen whole-source gate, independent HV and staging/production checks; the earlier007 evidence does not establish the corrected source or hosted outcome.