July 18, 2026

Route variety and completion celebration

A test-player report that Solo frequently returned the same route was reproduced against the active release bundle. The selector itself used secrets.choice, exhausted unseen rounds before a repeat, and avoided back-to-back repeats whenever alternatives existed. The real cause was the published pool: each exact category exposed two Easy routes but only one Normal and one Hard route, while the setup intentionally remembered the player's filters. Sports & Games on Normal or Hard therefore repeated the same route on every request even though Any category behaved correctly.

All 100 generated candidates already passed the same endpoint, label, category, distance, time, relationship, opening-choice, and provenance gates. Publication policy v3 now makes the complete validated pool playable: every category contains four Easy, four Normal, and two Hard routes. The selector also reads history across filter changes for the active guest and graph, while its cycle logic ignores routes outside the current filters. Switching between Any category and one topic can no longer make an already-seen route appear fresh.

The smoke fixture and immutable real-data bundle were rebuilt offline without new Wikidata or Commons requests. The verified local bundle wikidata-2026-07-18-round-variety-v1 has graph build ID bcef5c35ef4725305ba3e71124f0925383fdebd26e0c70d33c9af9f0253b62d1, 100 unique published routes, and a locked per-category Easy/Normal/Hard distribution of 4/4/2. ADR 0008 records why redistributing the former 40 routes or changing only the chooser could not fix every exact filter.

Reaching the target now starts a finite 72-piece confetti rain immediately on the authoritative completion response. The keyed presentation component survives the 300ms transition to the result page without replaying for the same session, ignores pointer input and assistive technology, uses only design-token colors, remains below drawers and dialogs, and is removed visually for both the system and in-app reduced-motion settings. Solo browser coverage locks animation, one-shot session identity, viewport containment, and both reduction paths; the shared Daily and Multiplayer completion flows assert the same celebration layer.

Compose acceptance rebuilt the API and Caddy client at http://localhost against graph build bcef5c35ef4725305ba3e71124f0925383fdebd26e0c70d33c9af9f0253b62d1. One fresh guest received four distinct Sports & Games Normal routes before the first repeat and 12 distinct Any-category Normal routes in 12 requests, with zero immediate repeats. A real 1440×900 Lionel Messi → Tour de France completion showed the full rain above the result page; at 412×915 the document and viewport widths matched, all 72 pieces remained pointer-transparent, and the in-app reduced-motion setting computed both the layer and its animation to none. Focused Solo, Daily, and Multiplayer browser checks passed on desktop and mobile, followed by the complete 32-flow browser suite with two workers. The full quality gate passes 139 web tests, 349 Python tests, both Remotion composition checks, formatting, lint, type checking, file and color policy checks, and the strict documentation build.

Submission packaging

The official OpenAI Build Week overview, rules, FAQ, judging criteria, and current Devpost media requirements were rechecked before drafting the submission. The current gate requires a working Codex and GPT-5.6 project, one track, an English story, a public narrated YouTube demo no longer than three minutes, a testable licensed repository, and the /feedback Session ID from the primary build task.

Local Codex task metadata confirms that the root Implement Webwoven game task and its specialized implementation agents ran on GPT-5.6 Sol. The task predates the first repository commit by roughly two hours; the committed implementation begins after the submission period opened. The submission copy distinguishes the pre-existing concept brief from the working code and documents where Codex accelerated delivery, where the creator retained decisions, and why AI remains outside the production gameplay loop.

The prepared package includes a concise Education-track story, direct judge testing instructions, a sub-three-minute narrated demo, built-with tags, final compliance checklist, a 3:2 gallery thumbnail, and desktop/mobile gallery images. The story leads with the player problem and visible product experience before the architecture, while retaining verifiable atlas, test, provenance, and production claims.

Voiceover and video production

The approved voiceover uses 372 words of plain English across eight short paragraphs. Its measured MP3 duration is 148.767313 seconds. It explicitly explains the working game, Codex acceleration, GPT-5.6 Sol's role, the creator's final decisions, and the no-runtime-AI boundary.

The transcript was checked against the audio and corrected at apps/demo-video/public/captions/voiceover.srt. The final SRT has 35 sequential, non-overlapping cues and ends at 148.700 seconds. Its timing already follows the spoken pauses, so only transcript spelling, capitalization, hyphenation, and punctuation needed correction.

The matching storyboard has now been implemented in apps/demo-video with Remotion 4. It provides a 151-second WebwovenDemo composition and a 24-second WebwovenTeaser composition, both at 1920×1080 and 30 fps. The demo contains 4,530 frames and its scene ranges are Hook 0–11.3 seconds, Start 11.3–26.4, Explain 26.4–50.1, Modes 50.1–66.5, Codex 66.5–95.3, Iteration 95.3–117.2, Trust 117.2–138.1, and Close 138.1–151.0. The final picture holds for 2.23 seconds after the narration ends.

The scenes open on the node map and use the current product setup, route explanation, Single-player, Daily, live Multiplayer, Codex, architecture, mobile, provenance, and trust-boundary evidence. The review commands are:

pnpm --filter @webwoven/demo-video render:teaser:quick
pnpm --filter @webwoven/demo-video render:demo:quick
pnpm --filter @webwoven/demo-video render:demo:narrated:quick

The corrected teaser preview is available at output/webwoven-teaser-preview.mp4; the full preview command writes output/webwoven-build-week-demo-preview.mp4. The narrated review command writes output/webwoven-build-week-demo-narrated-preview.mp4, and the final narrated delivery is produced with pnpm --filter @webwoven/demo-video render:demo:narrated at output/webwoven-build-week-demo-narrated.mp4.

The final narrated demo is public at https://youtu.be/TzIuJh-kdGc. Its 1280x720 upload artwork is versioned at docs/assets/submission/youtube-thumbnail.png, and the primary /feedback Session ID recorded for the Devpost form is 019f5c2a-d9b1-7e11-b671-5868c93b8241.

Compose acceptance at http://localhost was rebuilt before capture. A fresh 1920×1080 Solo recording follows the real Lionel Messi → Rosario → Argentina → UNESCO → France → Tour de France route from the active graph. The Remotion asset set also includes current captures of the Single-player setup, Daily result board, a live two-player Multiplayer map, the mobile route preview, and the current node map. This replaces the earlier teaser footage that predated the latest interface.

The approved MP3 is integrated through the composition's optional voiceoverFile prop. The narrated render scripts supply audio/voiceover.mp3, while the picture-only review scripts leave the prop empty. Scene boundaries were aligned to the measured paragraph starts, and all Remotion sequences use bounded durationInFrames values so earlier scenes and media unmount cleanly.

Public production readiness was rechecked through https://www.webwoven.org/health/ready and https://www.webwoven.org/health/graph; both report the active graph build 15ce21a4a7c4229dc9069372a2c5ab0fdbd57ab2c90e0139e952337f969e00fe as healthy.

The final submission gate passed after packaging: 139 web tests, 348 Python tests, all type and lint checks, both Remotion composition checks, the strict documentation build, and 32 desktop and mobile Playwright flows. The project owner confirmed individual entrant eligibility, approved the public video, selected the final YouTube thumbnail, and authorized repository publication and a fully populated Devpost draft without the final submit action.

The selected YouTube thumbnail is owner-supplied external promotional artwork rather than a Webwoven product capture. Its exact external generation chain was not retained, so the screenshot ledger records that limitation, its content hash, the recognizable synthetic Messi likeness, and the owner's final responsibility for personality and platform-rights review. The separate Devpost thumbnail and gallery remain current product captures with the existing attribution trail.

A real Devpost draft was saved at https://devpost.com/software/webwoven. It records the project as an Individual entry from Germany in the Education track. The overview, story, built-with tags, live URL, public repository URL, public YouTube demo, judge instructions, and primary /feedback Session ID are saved. The public repository, live product, and embedded video were reachable during the final check.

The saved draft renders correctly on desktop. At a 412x915 viewport, Devpost's narrow layout clips the embedded YouTube player horizontally, while the project copy and links remain readable. This is part of the Devpost preview layout rather than the submitted project.

Chrome local-file access is now enabled. The Devpost thumbnail and two gallery images remain intentionally paused until the final route-variety and celebration changes are verified. No Devpost terms, rights declarations, or final submit action were accepted. The remaining owner actions are to review the final repository and live build, complete the rights and terms declarations, and submit after the media upload and final desktop/mobile preview check.

Route-variety release and Devpost media

The route-variety and completion-celebration milestone shipped from commit e63b1bbda5672e3bb87798508d5705a8905f6b5d. The complete gate passes 139 web tests, 349 Python tests, both Remotion composition checks, the strict documentation build, and all 32 desktop/mobile Playwright flows. Production now points to the immutable release and graph bundle for build bcef5c35ef4725305ba3e71124f0925383fdebd26e0c70d33c9af9f0253b62d1; both public health endpoints report that build as healthy.

The Devpost draft uses the current product-map screenshot as its thumbnail, plus the captioned desktop frontispiece and mobile route preview. The synthetic Messi artwork remains YouTube-only and is not used on Devpost. The public preview exposes the video and both gallery images as a three-item carousel, and the project story now reports 100 validated, published routes and the 349-test Python gate. It also records that the brief architecture card in the already-published video shows the earlier 40-route release. The final desktop and 412x915 preview checks found no page-level horizontal overflow. No Devpost terms, rights declarations, or final submit action were accepted; those remain owner-only actions.

Full mobile label rows and complete frontier follow

Phone choice names now wrap in full with no line clamp or ellipsis. A small presentation observer measures each label's natural wrapped line count, while the pure phone projection groups choices in two-node rows and uses the tallest measured count for both labels. A shorter neighbor is vertically centered in the shared label block. Only the following gap for that row grows, so three- and four-line entity names remain readable without colliding with the next row or adding uniform empty space throughout the map. Measurements are presentation state only; they do not change node identity, navigation, scoring, or the server snapshot.

After the second activation confirms a phone move, camera fitting now includes the inline Back target, current node, every new compact choice, and the dead-end state when present. This replaces the former first-two-choice focus bound. The same board update that responds to measured row height also triggers camera fitting, so the complete new decision remains visible without a manual swipe.

Focused browser regressions run at 320×568 and 390×844 with the production label doctor honoris causa from the University of Lyon. They lock a one-line/four-line row, equal row heights, vertical centering, full text geometry, a following non-overlapping row, and the absence of clamp or ellipsis. A six-node camera fixture fails against the former first-two selector and passes with the complete frontier bound. Canonical Compose acceptance at http://localhost used the real Eleanor Roosevelt → United Nations move: all six new choices, the current node, and Back target fit inside the 390×844 map viewport at 66% zoom, with complete labels, no node overlap, no document scroll, and no horizontal overflow.

The final gate passes 140 web tests, 349 Python tests, both Remotion composition checks, formatting, lint, type checking, file and color policy checks, and the strict documentation build. All 38 desktop/mobile Playwright flows pass with two workers. The Caddy client was rebuilt once more after that gate, and the canonical Compose acceptance repeated the same six-choice move against the final compiled assets.

Multiplayer Lobby continuity and authoritative deadlines

The multiplayer surface now uses Lobby consistently in player-facing creation, join, code, invite, and error copy while retaining the established /api/v1/rooms wire resource. After Lobby creation on a phone, the new code header is brought back into view instead of leaving the host at the bottom of the setup form. A host-only Share control beside that code calls the native Web Share API from the original user gesture, falls back to clipboard or a selectable URL, and produces the canonical /lobby/{CODE}/join deep link. Opening it in an existing Webwoven window requests a rate-limited minimal preview, names the inviting host, and asks for confirmation before joining or reopening the Lobby. The preview deliberately omits the route, roster, sessions, and progress.

Multiplayer timing now has one server-owned command boundary. Every participant session starts at the Lobby's countdown_ends_at, and authorization accepts the first move at that instant even if the persisted room or browser is still waiting for race.started. The first finisher opens a visible 30-second grace countdown. Remaining players may continue strictly until grace_ends_at; when it passes, their unfinished sessions become expired, the room advances to results, and late commands cannot leave a player trapped in an active game. WebSocket waits wake at the next countdown, grace, or rematch deadline rather than relying on a later move or arbitrary refresh.

The active-game chrome was reduced around that lifecycle. Time, Moves, the complete permanent Target, Score, and Back occupy the dark HUD on desktop and mobile; the Par field is removed. Phones also remove the separate Round active identity row and replace the full multiplayer roster with a compact player/finish summary or grace timer. Desktop and tablet retain individual abstract player progress without revealing anyone's current node or route.

Results now open a 30-second same-Lobby rematch vote. Resolution occurs when every active player has answered or the deadline passes. Two or more yes votes keep the Lobby code, select a fresh eligible round, assign new synchronized sessions, and return the accepted players to countdown; no-voters and non-voters become inactive, with host ownership transferred when necessary. Fewer than two yes votes closes the Lobby with not_enough_players and presents a clear next step instead of restarting the entire creation flow.

Focused API and domain regressions cover minimal invite previews, invite rate limiting, the exact countdown command boundary, grace-expiry session cleanup, deadline-driven WebSocket transitions, same-code rematches, inactive non-voters, and insufficient-vote closure. Web unit and browser coverage locks canonical native-share fallbacks, deep-link routing, grace timing, and the compact mobile Multiplayer HUD with a complete Target and no Par field. The strict documentation build passes.

Multiplayer and Lobby language

The player-facing product no longer asks people to understand Relay. The home card stays Multiplayer; setup, invitations, room codes, and persistent groups are Lobbies; active play uses game, race, and round. Every visible heading, button, result label, settings note, accessible label, and API error follows that vocabulary. Internal relay mode values, API resource names, analytics values, and class names remain stable so the terminology change does not break stored sessions or clients.

New navigation and shared invitations use /lobby, /lobby/{CODE}, and /lobby/{CODE}/join. Existing /relay links remain valid aliases and are canonicalized in place, so an already-open Webwoven window can keep working without exposing the retired term in new links. Unit and browser tests cover canonical link generation, legacy URL compatibility, and the complete Multiplayer/Lobby copy across desktop and phone layouts.