report

2026-10-31T12:07:34 - Actual private API diagnostic: bounded causal analysis and driver assessment

The diagnostic genuinely failed at13 players during UI readiness, before any solves. Its actual XML error message is Malformed rendered command version. The earlier Unknown pending command classification came from an adjacent quoted source line, and is retracted. The observed roster had already fallen from13 to12 by the penultimate ready completion. This supports investigating the sequential ready driver's interaction with the five-second sole-holdout rule. It does not establish a unique cause of the original15-player game acknowledgement timeout or the earlier11-player actionability failure.

This is same-family read-only source/evidence support, NOT HV, implementation, release acceptance or a done-state claim. Own Codex-20261031T142951Z-plugin-session / req-20261031T164022Z-private-debug-causal-analysis. Parent Codex-20261027T100516Z-plugin-session / req-20261031T142639Z-release-resume. Root owns the actual diagnostic run1d683e40-74a2-40e5-9770-2faf6c0cd2a3, unit wordpairs-private-api-1d683e40.service, invocation648c586d08db4c57bfc6ead1a58f3629, started11:37:41 on source0e8d31a638e4db63e96302ca60fa7512c6accc96 and existing HRbAGnW8umu6_uv6PN3Yw build. This analysis did not launch or rerun anything.

Verified native facts and the classification correction

Backup's fixed allowlist reports11 passed cases2..12, one failed13, two skipped14/15 in the fourteen-case diagnostic JUnit4A61194181A77ED8433E5E69B87872FF8BC6300615BFCDDFA1FE489DB0BCD121. There is no fresh strict/four-preparation result from this live-only diagnostic. The initial native-api-extract/summary.json label unknown-pending-command was based on finding a source constant anywhere in the error text. I initially treated that label as the actual exception too early and explicitly withdrew it when the source chain and exact-message distinction were examined. That original artifact and this correction are both retained.

The definitive native-error-classification-v2/classification.json EEF65DFCC71632113D1F21D3A22F6C5DEA5A059517A1AAEB8AB1030B62DEB0DE identifies one XML error node, type AssertionError, with an exact34-character message attribute Malformed rendered command version. The2096-character inner text quotes source lines11..16, including the unrelated Unknown pending command constant at13. Therefore pending presence, a pending enum, and an unknown-pending exception are NOT established by that snippet. Root and backup caught the distinction; my final causal conclusions use the actual message attribute. This is a general evidence lesson: a stack/code-frame context match is not error provenance.

Actual13 readiness and roster facts

The identity-free derivative game13-identity-free-observation.json CCE83BC20FFE3D9622C20E140BD885B3BFD43D59111A69F41331356A07EAD4D0 has phase UI readiness, zero solves, thirteen prepared records with roster13/version12, and twelve ready records for indices0..11. The first eleven completed ready records keep roster13 and advance response versions13..23. Index11's completed ready record reports response24 but roster12. Its captured acknowledgement at attempt2 first has rendered25/busytrue/pendingdisabled/waiting and later rendered36/busyfalse/pendingabsent/acknowledged. Body-failure count is zero. These observations have no per-transition timestamp.

The next sequential actor would be index12 by source/order inference. The failed actor is not explicitly logged at the rejection. The exact invalid rendered version, its attribute absence versus malformed value, the lost actor and the server holdout deadline are not captured by these derivatives. All thirteen post-failure body flags show open/connected pages and no room-pending-control, Mark ready, denial or account-changed text. Those late text observations have no enabled-state or mutation timing and cannot reconstruct the failing read. They also do not establish that every page still had the original player role or roster at that instant.

Source+record inference only: index11's first attempt appears to have been uncertain rather than a successful-body acknowledgement or a known409 retirement, because attempt2 is recorded, there are no attempt1 retirement/acknowledgement rows, and body-failure count is zero. The exact first response status is not in the identity-free extract. Do not relabel this as a measured500, lost response or committed replay without actual status evidence.

Primary-source chain

tests/browser/readiness-barrier.ts first owns all concurrent page preparations with Promise.allSettled, rejects failed preparation only after all started preparations settle, then awaits every ready callback serially. Matrix preparation verifies live status, full roster, enabled Mark ready, same-context API actor/role and initial alias before any ready callbacks start. The phase changes to UI readiness only inside the later ready callback. That callback awaits commitUi's fresh room guard, captured manual UI request/body, current sender acknowledgement, and a roster observation before the next actor's callback is invoked.

src/domain/lobby.ts defines HOLDOUT_MS=5000. Exactly one remaining unready player creates that deadline; when it expires in a room larger than two the holdout is removed and countdown locks the remaining roster. The serial driver's penultimate callback can therefore consume the last actor's entire holdout window while waiting for its own network/read/render/acknowledgement completion. The observed13-to12 roster change before the final callback supports this class of failure. It does not by itself identify the server job, exact actor, clock interval or origin of the delay. Presence/reconnect behavior and other legitimate room changes are not excluded solely by a roster count; exact source/record correlation remains missing.

RoomScreen's success path differs from GamePanel. RoomScreen retires pre-command reads on response.ok or a known below500 response by incrementing sequence and clearing fetching/refreshAgain. Successful ready clears pending and awaits fresh refresh before clearing busy. Known409 clears pending and throws without awaiting refresh, except special discovery-player-join handling; notifications and safety refresh may still reconcile it. GamePanel's known409 path does await refresh, while its successful command may await a coalesced refresh that returns early. These are different lifecycle paths; the older game handoff analysis must not be pasted onto this room-readiness failure.

In RoomScreen a refresh401/403/404 clears room. The section remains mounted while data-room-version becomes absent if room is null. readCommandUi then returns the actual attribute value and commandUiState rejects a missing/nondecimal/unsafe version with the verified message. A seat-loss/access response followed by that render is therefore a source-supported explanation. The exact access response and rejected snapshot were not retained in this derivative, so it remains an explanation consistent with the data, not a proved server404 sequence or a reason to weaken the guard.

Locator artifact counterfactual

readCommandUi uses the requested scoped panel and requires count exactly one. Its pending test is exact textContent.trim equality with Retry pending room request or Retry pending game request, not a prefix or regex. GamePanel is a sibling outside the room section in current RoomScreen markup. An exact own-room retry button that exists but is hidden is classified disabled intentionally. Only RoomSession.command assigns its pending ref; the presence heartbeat has a separate local retry and never assigns it. A DOM render may lag a changed ref, and the reader has no explicit actor/page identity, but there is no source basis for assuming broad text matching or cross-scope matching caused this failure. In fact the actual native message does not prove any pending match occurred.

If a reader discrimination check is approved, use the SAME real readCommandUi/classifier seam on isolated dual-panel DOM fixtures. A valid room panel with a missing/malformed sibling game version, external retry button, paragraph hint, or prefix/suffix retry text must still read the room's valid version and absent pending state. Exact own-room enabled/disabled/hidden pending controls must retain their specified classification and fresh rejection. Own-room missing/malformed version must reject; a sibling malformed version must not. Duplicate own panels and duplicate exact pending controls must fail. Negative providers that select the other panel, broaden text equality or replace missing versions with zero must be rejected. Existing malformed and unknown-pending cases already cover parts of this; extend rather than claim an unexecuted new oracle passed. This proposed fixture check would distinguish reader artifacts from a real rendered transient, not recover the lost live timing.

What native API timing does and does not establish

The safe parser retained28,787 boundary events. It explicitly excluded11,628 ambiguous equal-method overlap events from pairing and reports8,039 unique nonoverlap outer intervals plus1,081 unmatched ends. Native API boundary strings print method names, not call/page/actor/command IDs. Stdout's88 round markers are untimestamped; they cannot be aligned exactly with stderr timestamps by line number or buffering order. No invented FIFO/LIFO pairing is valid for overlapping equal methods. The raw streams were not read by this analysis, and no duplicate parser was written.

The maximum uniquely paired count span is8113ms and evaluate span7587ms. These show long outer browser/driver API spans occurred somewhere in this diagnostic. They do not attribute either span to the failed actor, a particular preparation/acknowledgement, the final room read, or the original15 case. Locator.evaluate includes attached-selector lookup, element evaluation and disposal, so its duration is not pure browser JavaScript time. count uses protocol queryCount with kNoTimeout. Neither is the click actionability stability loop. Current evidence therefore does not discriminate repeated fast stale15 acknowledgement probes from one long15 probe: the new run failed earlier at another case/phase, and the boundary labels lack the required correlation.

The installed pollMatcher awaits the entire actual callback outside the matcher-result catch; pollAgainstDeadline races that callback but does not cancel it. waitCommandState drains every started probe and preserves failures. The original15 rendered2 acknowledgement could have arrived during a deadline race or drain and remains a failed native gate. Nothing in this diagnostic licenses changing that outcome to pass.

Resource limits

The qualified-sampled-rows.json676DA959FEC6903007A63DBDFF14B43412FCB559BDB52187672463CCFF081276 shows three sampled transactionid ShareLock waits at11:42:21.563,11:42:39.563 and11:44:51.550 with query ages0.472,2.592 and0.834ms. Nine idle-in-transaction samples have transaction ages0.205..24.843ms. These are point samples, not continuous wait/statement durations. They have no command/case identity. They do not prove a sustained SQL stall, nor exclude a transient wait or application/pool queue between samples.

Backup's terminal observation5F6EEEEC records combined process CPU/RSS, not independent Next attribution, and excludes external database/Realtime CPU. This analysis's initial read of that large derivative was truncated, so it is not claimed as a full read or full resource recertification. The resource claims here are limited to the completely read qualified sampled rows and the derivative's stated scope. No host saturation, browser main-thread or pool-checkout cause is established. Private permission metadata corrections are separately owned operational work, not evidence of a game cause. Native logging adds I/O overhead and changes timing.

Assessment of the proposed final-two ready driver change, NOT implemented

Starting the final two ready callbacks concurrently after all preparations is a minimal way to remove the controller's artificial dependency on the penultimate actor's full acknowledgement before the final actor can begin. Keep earlier ready callbacks serial, all actual UI commands and existing conflict/pending/body/acknowledgement checks, and both final callbacks owned with allSettled even when a callback throws synchronously. Apply the pair rule to two-player cases too. An earlier serial failure must stop all later callbacks, including the final pair. No sleeps, longer budgets, forced clicks, skipped guards, altered holdout/presence rules or product changes follow from this assessment.

This changes driver scheduling, not the product's holdout contract. Both final callbacks can still be delayed by their own fresh probes or optimistic-version conflict retirement beyond five seconds. Therefore it removes one known controller ordering hazard without guaranteeing every room will start or explaining the older11/15 failures. A later native full-range pass and all existing required gates would still be necessary, and would not retroactively erase failed diagnostics.

Before changing the coordinator, extend its existing contract and establish the green mock gate with wrong-provider rejection controls. Preserve every current all-preparation ownership and identity test. The old readiness-rejection case currently expects serial calls[0,1]; under a final pair it must distinguish an earlier-serial rejection from a final-pair rejection rather than silently weaken failure semantics.

Use an actual callback-entry barrier: hold the first final callback on a deferred operation, wait until it has really entered, yield one deterministic event-loop checkpoint, and verify that the second final callback entered before releasing the first. Always release and drain in finally, so a wrong serial provider rejects after ownership is retired instead of hanging the test. This must discriminate a provider that waits for the first acknowledgement before launching the second. A separate test holds a final sibling while the first final callback throws synchronously or rejects asynchronously and proves the coordinator remains pending until the sibling settles. An earlier serial rejection must prove no later serial/final callback was launched. Include two-player and fifteen-player boundaries, exact callback identity/order, no readiness before all preparations, and the current synchronous preparation failure controls.

Negative providers should include serial-final scheduling, fire-and-forget final callbacks, short-circuiting synchronous map invocation that never starts the sibling, all-ready-at-once scheduling, and returning before a rejected callback's started sibling drains. Preserve the existing single-failure provenance; explicitly lock how multiple failures are reported in the approved contract rather than introduce an unstated aggregation change. Bind the SAME cases and interaction assertions to the real coordinator after the mock gate. No new tests, mock runs, source edits or requirement/status updates were performed by this analysis. Root is reading the current plan/requirements before any implementation authorization.

Remaining gaps and evidence boundaries

The actual rejected version and exact failed actor/read timestamp are absent. The sole-holdout job/deadline/removed identity is inferred, not correlated. The penultimate first response status and individual refresh timings are absent. Native API boundaries lack actor/probe IDs and cross-stream timing alignment. SQL snapshots lack checkout/event-loop/request phases. These gaps prevent a unique root-cause declaration or a product patch based solely on this run. The existing optional rejected callback would be the smallest source seam for an explicitly approved future sanitized rejection snapshot; adding it would still need the plan's test-first sequence.

The original full failed9/1/4 at11, isolated11 diagnostic pass, observed full13/1/0 at15 and current diagnostic11/1/2 at13 are separate runs. Original Claude6 FAIL/UNKNOWN, exact old client-audit gap, dated source/document corrections and deployment/package/submission dependencies remain preserved. No tests/builds/reruns/models/HV/providers/browser/app/test/configuration/requirements/status/Git changes or guard changes were executed here.

Accuracy99 percent for the corrected, source-pinned bounded report: the actual native message and safe readiness/resource facts are distinguished from inference; the initial snippet-classification error is retained explicitly. Completeness96 percent for causal identification: relevant source and verified derivatives support a minimal driver assessment, but the specified timing/identity gaps prevent unique attribution. This is not a hostile OverallVerdict or permission to mark the game complete.