Roadmap: from test kit to agent suite

Where this kit goes next, agreed through question rounds with its one user. Each step is one pull request (or a few small ones); the pull requests and CHANGELOG.md are the record of what was built. This page keeps only what is still open.

Status

Still open from phases 1 and 2:

• Schedule the monthly kit-review as a Claude scheduled task. The skill exists and files its proposals as issues in this repository (nobody has to answer it); nothing runs it yet.
• Schedule the weekly review on the owner's machine: Friday night, Athens time, after the canary.
• A lesson from a game reaching the kit as a merged pull request through /retro.
• The canary's open issue #89: gdUnit4.test.adapter 3.1.1 does not pass. (Its green path has run too: version bump #88.)
• A first real /game run on Breakout Roguelike: a confirmed GDD, a plan/STATUS.md the owner agrees with, and a board that matches it.

Still open from the issue pass of 2026-11-09 (#230, #231, #221 and #212 in part; the issues hold the measurements):

• -TimeoutSec and a partial result for status and plan (#230). detect, plan and status are several times faster on a large game (4,500 files: 9.1 to 1.7 s, 15 to 2 s, 21 to 4 s), but a command that still takes too long is not cut short: there is no time limit and no partial result with a field that says what was skipped.
• Under stretch aspect keep, shot -Resolution cannot show another shape (#212). The engine renders the base size with bars, so doctor warns about such targets in docs/STYLE.md and look fails them with shot-size instead of judging them. Left undone: drawing the bars into a picture of the requested size (the colour and scale could not be checked against a real window, where a screen grab of the virtual display came back black), and naming files by resolution (the look skill already uses one folder per resolution, and a new name would stop old -Baseline folders matching).
• flows on macOS still writes to the real user:// folder. On Linux and Windows the flows run with a throwaway user folder (XDG_DATA_HOME, APPDATA); the macOS location was not moved. The engine's own "Handle is not initialized" lines that the report classifies as warnings were matched against the pattern in Common.ps1 but never reproduced locally.

0.1.0: the first Hyperdot release

Agreed in a question round with the owner on 2026-10-22. The kit becomes Hyperdot, a Godot-specific game development interface, and ships its first tagged release once these steps are done, in this order. Each step is one or more pull requests. On 2026-10-23 the owner chose to number it 0.1.0, a fresh start for the new name (plugin.json had 0.4.0), instead of 1.0: see Versions.

1. Sanity check. Every self-test, both examples, doctor and plan on both, the Windows job; an inventory of the commands, skills, docs and library files, with what is dead, stale or contradictory.
2. Cleanup. Merge or cut overlapping skills and docs (focused skills beat many big ones); clear finished roadmap items; fix stale counts. Done so far: five skill merges (55 to 50), this page cut to what is open, and docs/strategies.md folded into What was decided.
3. Rename, clean break. Done in code: plugin hyperdot, ci/godot/hyperdot.ps1, HYPERDOT_* variables, the [hyperdot] log prefix, the hyperdot/1 JSON schema, .godot/hyperdot-history.jsonl, ~/.hyperdot, and examples/csharp (was examples/breakout, whose name clashed with Breakout Roguelike). No aliases; error codes keep their names. Old state moves once: the history file, the GUT stamp and ~/.godot-ci on any run; a game's workflow file and plugin entry on init. The owner renamed the repository from nick-vas/Godot_TestSuite to nick-vas/hyperdot.
4. Fixes and features from the question round (the notes below).
5. Benchmark. Evals with 3 runs per arm (the first run where all four cases can run commands), the token benchmark (costs money: confirm first) and bench on the C# example. Done for the token benchmark, with the Hyperdot label (label.md): an adversarial review of every area (62 findings: 59 fixed with regression tests), a grader that cannot be fooled, sessions that cannot read the test, and the 0.1.0 rating from 192 sessions.
6. Retro over all of the above: retro.md.
7. Release 0.1.0: changelog, version, tag v0.1.0; create and keep a moving v1 tag with release.yml (dispatch it: ci.md; init and the docs already write @v1; the tags v0.1.0 and v1 exist, so this step is done), a start-here page for working on a game (first use: Breakout Roguelike, nick-vas/BreakoutTheBreakout, in a new chat with the kit cloned beside it), and the GitHub Pages site (added to 0.1.0 by the owner on 2026-10-26; the owner turns on Pages with GitHub Actions as its source).

Versions

Semantic Versioning. The public interface is the commands and flags, the -Json output (schema hyperdot/1), the error codes, the environment variables, the workflow inputs and the files init writes.

• 0.x while Hyperdot is used on its first real game: anything may change; a breaking change bumps the minor (0.1 to 0.2), a fix the patch. Each release is a tag v0.x.y and a CHANGELOG section.
• 1.0.0-beta.n, then 1.0.0-rc.n once all of these hold: a vertical slice of Breakout Roguelike was built with Hyperdot; about four weeks passed without a breaking change to the commands, the JSON or the error codes; the live GitHub Project run passes; the evals pass three runs in a row.
• 1.0.0: from then on a breaking change needs 2.0.

Notes from the question round: none left for 0.1.0. Note 6 (an eval grader was wrong for three runs before anyone looked) is tests/Test-EvalGraders.ps1 for the graders that need no model; note 11 waits until after 0.1.0 (To do). Checking the model graders the same way needs a model call per check, and is not built.

GitHub Projects

• Live run. tests/Test-ProjectSync.ps1 -Live (the Project sync workflow) waits for the repository secret HYPERDOT_PROJECT_TOKEN (a personal access token with the project scope) and has not been run against GitHub: the session that built it could reach neither the Projects API nor the gh project manual, so the calls follow the help text of gh 2.89 (gh project --help). The stand-in run passes in the self-test.
• Board view. The CLI cannot create or edit a project's views, so the owner sets the Board view to group by Column once.

The six bugs the connector test found (list names as columns, cards added on the board, boardColumn, removing a task, ARI card ids) are fixed and pass against the mock; the live run should also cover importing a card and archiving a removed task's card, which only the mock has seen.

What was decided

Principles that keep it future-proof

1. Facts in the CLI, judgement in Claude. Anything that can be computed (tests, gates, git stats, bench numbers) is a hyperdot.ps1 command with -Json output. Anything that needs judgement (is this feature done, is this screen readable) is a skill, slash command or subagent that reads that JSON. The CLI survives model changes; the skills are cheap to rewrite.
2. Ship as a Claude Code plugin. Skills, subagents and the Stop hook load from this repository as a plugin and are updated with /plugin update. The game keeps only what is about the game: AGENTS.md, docs/GDD.md, docs/decisions/, plan/, its tests.
3. Every claim is checked. The skill validator checks that quoted commands, flags, codes and versions exist. New content follows the same rule: a lesson cites its evidence, a pattern cites the Godot API it uses, a version is tested.
4. Upkeep budget. The validator fails a SKILL.md at 16 KB (warns from 15.5 KB), a description over 1,024 characters and the AGENTS.md template over 4 KB; detail goes to side files in the skill's folder, whose kit commands it checks too. There is no limit on the total: the 53 skills come to about 580 KB with their side files, but only the descriptions (about 9.6 KB) load into every session. A new skill that shares a trigger with an old one is merged into it instead; every command has a self-test; a feature nobody used for three months is proposed for removal.
5. The owner sees the reasoning. Plans, assessments and decisions are written to files in the game repository and mirrored to the GitHub Project, not left in a chat transcript.

To do

What was left open by the research passes (docs/studio-lessons.md, docs/valve.md, docs/art.md, docs/audio.md and the other topic pages), grouped by what it waits for. Done items are in CHANGELOG.md.

Typography sources not read (docs/typography.md)

The typography skill rests on Practical Typography because these could not be read from the build environment on 2026-11-02. Each needs the owner: paste the text, save the pages and attach them, or allow the host.

• Google Fonts Knowledge (anatomy, classification, readability, variable fonts). A script-rendered app whose script was blocked in transit (ERR_BLOCKED_BY_ORB); the likeliest fix is allowing www.gstatic.com for the session, or saving the articles as text. The owner agreed on 2026-11-03 to allow www.gstatic.com in the environment's network settings; read the articles in the first session that has it.
• Letterform Archive toolkit, AIGA, TypeThursday. Bot checks (403, 403, 429): paste or attach the pages you want read.
• thinkingwithtype.com, historyoftype.com. No connection (closed after ten seconds; 502). They may be down or denied; the list called the second "free" and that is unconfirmed.

CI supply chain (found in the review of the CI configuration)

• Move the web job back to ubuntu-latest. It runs on ubuntu-24.04 since ubuntu-latest became 26.04: there the Vulkan validation layer reports Godot 4.7.2's own host-access barriers (vkCmdPipelineBarrier(), srcAccessMask VK_ACCESS_2_HOST_READ_BIT not supported by VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT, with no VUID) in a clean shot, and Test-GpuValidation.ps1 fails on it (the clean export -Run is not affected). To do: find out whether newer Godot or the layer fixes it, or whether the check should ignore these messages by text (HYPERDOT_IGNORE_ERRORS matches a VUID, and these carry none), then move the job back.
• Windows and macOS image versions in the input hash. Get-InputHash.ps1 -RunnerByJob takes a label for the jobs that run elsewhere (windows-latest, set in self-test.yml), which does not move when the hosted image does. Reading ImageVersion on those runners needs a step on them (the exports inside csharp run in godot.yml): to do, if the cache ever skips those jobs (stage 1 or later).
• try of the canary has no token, so Update-Versions.ps1 and Update-AddonStatus.ps1 call the GitHub API without one (60 requests an hour per address on a hosted runner). If the weekly run hits that limit, give try a token with contents: read only, as the one exception.

CI history needed to demote more self-test jobs

• Which self-test jobs may move to the nightly run: the history is collected (29 October 2026), the decision is the owner's. docs/ci.md ("Demoting more to the nightly run") has the table: all 842 runs of self-test.yml from 5 to 28 October, every job and step read, runs and failures by pull request, main and branch push, flaky failures, the 20 that appeared only after merge, and runner-minutes, with a recommendation (the field test, the error-code step and a few display-bound steps of measure may move; lint, init, local-windows, the reusable-workflow jobs, web, coverage and the pairs' sample stay). Nothing was demoted. What remains: (1) the owner's decision, then the change to self-test.yml and Test-SelectJobs.ps1; (2) the history is 23 days, not the 60 the criterion asks for, and one day (22 October) holds half the failures: collect again on about 4 December 2026 (the method is in docs/ci.md; the collector was a throwaway script and is not in the repository); (3) "zero failures in runs that included its files" was not shown, as it needs each run's changed files; (4) failure logs were not read, so flaky is only "passed on a re-run of the same commit" (7 runs were re-run).

After 0.1.0

• A complete mid run of the staged programme: done (2026-10-27 to 2026-11-03). All six configurations ran, 122 to 135 of 135 sessions each; the results, the costs, the sessions lost and what they taught are in benchmark/PLAN.md ("The complete mid tier"), and cost-model.json and the mid ceiling (now $180) follow them. What remains: the game-making label rating (the label tool reads the tool and game programmes; it does not rate the staged one yet, which is stage 7 of the plan), and the sessions that did not run (Opus 7, Opus with the plugin 13, Haiku 5, Haiku with the plugin 3). continue_run now takes several run ids, so they can be finished without repeating the rest.
• Run Opus in the staged programme: done (see above). Opus costs about 3 times Sonnet per task and 4 times per milestone, not the 2.2 times estimated.
• Why CI and the owner's PC disagree (question round note 11). No quick way to see why a run passes on one and fails on the other; the idea is to compare the two runs' -Json results side by side. Postponed by the owner on 2026-10-26 until after the 0.1.0 release.
• README adoption: what remains (the owner's adoption review, 2026-10-27). The README now leads with the problem and the evidence, has a quick start with the right script path, a choose-your-path section, Core against Advanced and a table of what Hyperdot adds on top of the test frameworks it runs. Two parts need material from the owner: a short demo recording (an agent changes code, a test fails, the agent fixes it, the tests pass, the export succeeds), and a write-up "things AI agents break in Godot" built from real failures Hyperdot caught. Social proof (users, runs) waits for real numbers; none is invented.
• Measurements postponed: done, except the game-making label rating (above).
• A cache keyed by a hash of the inputs, for CI (same origin; telemetry exists now, and reports the hit rates of this cache once it exists, from the same history). A job's inputs (the project files it reads, the Godot version, the kit version) are hashed, and a job whose hash has already passed is skipped, where Select-Jobs.ps1 now selects by the paths a change touches. Open question first: a result may be reused only for tests that do not flake on runners (the C# soak's memory growth has failed there twice), so each job needs a note on whether its result is deterministic. Design written, awaiting the owner's decision: ci-cache.md (the key, where results live, a verdict per job, the risks, a staged plan from measurement only, and the questions for the owner). Stage 0 is built (the owner's go of 2026-10-27, measure only, nothing skipped): after about two weeks of runs, read the cache-observations artifacts (hit rate by job, event and run_attempt; runner-minutes from the jobs' durations) and put the numbers to the owner with questions 2 to 6 of the page.

From the label and the adversarial review (2026-10-23)

• Sonnet over its word limits. (Measured on 2026-11-03 over all six configurations: Opus is over on 72% of tasks, by 29 words on average; the plugin cuts the share to 40% for Opus and to 4% for Sonnet. The owner kept the limit as it is.) All but one of Sonnet's failed benchmark answers are 10 to 30% over the limit their prompt states, which puts it in class F where Haiku is D. Whether a line in AGENTS.md ("keep to a stated length") changes that is a question for the next benchmark run, not a reason to change the grader.
• The plugin on Hyperdot's own code. Loading it adds tokens to every session and helps none of the tool programme's tasks (its skills are about games). The game programme (benchmark/game-benchmark.json, built from evals/) now rates what the plugin is for; each version gets a tool class and a game-making class.
• The staged game programme. The pilot (five tasks on one prototype) is too easy to tell configurations apart. benchmark/PLAN.md holds the owner's decisions and the design: ten genres, four stages each (prototype, alpha, beta, release candidate), GDScript and C#, everyday tasks and milestone runs as two results, grading from hard checks to a pinned model judge and human review, min/mid/max tiers, a private field test, and sessions isolated as a separate user.
• Grading runs the session's code as the runner (open). After a session, Exit-IsolatedSession (benchmark/Isolation.ps1) takes the game back for the runner user, and Test-GameResult and Invoke-GameSuite (benchmark/GameProgramme.ps1) then run the kit's test on it: Godot loads the game's own autoloads, scenes and scripts, so whatever the session wrote in them runs with the runner's privileges, outside the isolation. Such code can read everything the runner can (the checkout including benchmark/ and the hidden tests, the runner's credentials and home, the grader's other game copies) and can write to the runner's files, so it could read the answers or change a later result. The session itself is contained; the grading step is not. Proposed design: a second unprivileged grading user made like the session user (useradd, no shell), to which the game copy is handed over for grading (chown, mode 700) together with a copy of the hidden tests and the kit without benchmark/; the runner starts hyperdot.ps1 test through runuser or sudo as that user with the same narrow environment, reads the JUnit and TRX files it leaves in a results folder it can write, and then stops that user's processes and takes the copy back, as Exit-IsolatedSession does for the session. Mutants and kit-command checks (doctor, export -Run) run the same way. Until then the benchmark's isolation is a protection of the tests from the session's commands, not from its code.
• Hold-out tasks. The verification procedure could also run tasks that are not in the published spec, as market surveillance may test beyond the declared programme. That needs a private spec, and somewhere private to keep it.
• The last two binding errors as JSON. A flag left without its value (-Project as the last word) and a value of the wrong type (-Retry abc) are still refused by PowerShell before hyperdot.ps1 runs, so -Json prints nothing. Catching them needs a process in front of the script. Measured on pwsh 7.6 (2026-10-29), with a launcher script whose only line is try { & real.ps1 @args } catch { ... }: it catches both errors (ParameterBindingException for the missing value, ParameterBindingArgumentTransformationException for the type), and forwards -Flag value, -Switch, -List a,b, a value with a space and a leading -Json exactly as a direct call does; it breaks the colon form of a switch (-Run:$false and -Run:$true arrive as a parameter and a stray positional value, A positional parameter cannot be found that accepts argument 'False'). Fixing that means re-parsing the command line (abbreviated names, positions, array values, -GameArgs values that start with dashes), and hyperdot.ps1 is the file help, doctor, the tests and every workflow read the parameter block from. The type case alone could be fixed by declaring the 23 [int] and [double] parameters as strings and converting them after Assert-KitArguments, but not the missing value. Left as it is: two mistakes agents rarely make, against an entry point everything depends on.
• gdUnit4 skipping two tests on Windows, sometimes. Self-test run 39930228730 (local-windows, the C# example with -Coverage): "gdUnit4 found 28 tests but ran 26", so the kit's guard failed the run, as it should; the next run on the same kit code ran all 28. The log does not say which two, and a "CLR: Assert failure ... after the .NET runtime thread state has been destroyed" follows. Needs a Windows machine: run the suite in a loop and keep the TRX files.

Kit features not built

• Add-on archived flags. Godot Jolt's, PerfBullets' and py4godot's archived in ci/godot/addons-status.json are still null: on 2026-10-29 GitHub's API and repository pages answered 403 in the sandbox that checked the release zips (the folders inside them are confirmed, docs/addons.md). The canary's first run with API access fills them in; or run gh api repos/<owner>/<repo> --jq .archived for each from a machine that can. Godot-PerfBullets has no release, so no zip is checked for it until it gets one (the canary reports that).

• A field test on someone else's game. doctor, test and export on OpenLiberty (MIT, Godot 4.7, GDScript, no tests), the C# template, Maaack's template and Crystal Bit's template named in docs/awesome-lists.md would show what the kit says about real code. Needs a machine with Godot; the owner decides.

• The rest of the awesome lists. The five lists left (learn-gamedev, game datasets, game engine development, a11y, gametalks) were read by section and keyword, not every line; docs/awesome-lists.md names three gametalks as candidates for docs/gdc and the leads whose pages were not opened.

• -GpuValidation beyond Vulkan on Linux. Tested with Mesa's lavapipe under Xvfb only. Not run: a real GPU, Windows (Vulkan SDK layer), D3D12 (Godot's debug-layer messages are read by the same pattern as Vulkan's debug-utils ones, from the source, never seen in a log) and Metal; on D3D12 and Metal layerLoaded is null because their logs do not say.

• CI: the GitLab template (ci/gitlab/hyperdot.gitlab-ci.yml) has never run on GitLab: no GitLab project or runner was reachable from the sandbox that wrote it. Run it once on a GitLab project (a copy of examples/gdscript and of examples/csharp) and fix what breaks. A container image with Godot and its templates already in it was not built: the .NET 8 SDK image GitLab jobs use already has git and .NET, PowerShell 7.6 and Godot are cached downloads, and an image with the .NET build's templates would weigh about 2.1 GB more (1.9 GB of templates and 222 MB of Godot unpacked, 4.7.2) and need a registry and a canary job to keep it current. init writes @v1; the tag itself is created at the 0.1.0 release (step 7 above).

In the example game (the C# example):

• GamePlatform.Start() is not called by Main yet (the example's BreakoutProgress is not wired into the scene either); the Steam backend itself is built (-p:Steam=true, see docs/steam.md).

In the skills:

• xr was written (OpenXR: the player's body, locomotion and comfort, hands, throwing from the peak hand speed, one-controller play, passthrough) with a headless fixture (tests/Test-Xr.ps1); what the fixture cannot check is in "Not run or measured here". Still to write for it: hand-tracked grabbing and physics hands, XR UI (a viewport on a quad, OpenXRCompositionLayerQuad), render models, and a seated-play section.

• Dialogue Manager 4 is the kit's dialogue tool (the owner's choice, 2026-10-29; the comparison with Yarn Spinner, godot-ink, Dialogic and inkgd, read from their repositories, is in dialogue-tools.md). Still to do: build it in a copy of the C# example on 4.7.2, import a .dialogue file and play one conversation headless, and turn that into a kit check that plays every .dialogue file. The session's permission check refused to build third-party add-on code, so the owner has to allow it or run it.

• A flow test that the credits screen is reachable from the main menu stays game-specific; the skill tells games to add one.

Not run or measured here (hardware, platforms, runners)

• On a real runner: setup and an export on macos-latest (tested only as names and paths), a signed Android, Windows and macOS export through the workflow's secrets, the LFS and Gradle caches, and environment: left empty.
• Headless Blender export in CI (Blender not installed); Godot's Texture Atlas importer headless (wrote no atlas, once hung; cause unknown).
• Forward+ and Mobile numbers (particles, LODs, batching, post-processing) and GPU profiling (--gpu-profile): no Vulkan or GPU here, everything used Compatibility.
• audio -Mix on Windows (tested on Linux under Xvfb).
• aseprite-mcp against a real Aseprite on Windows (checked with a stand-in; it writes its Lua scripts in the system's code page).
• Real power-loss testing of SaveStore (needs a VM or dm-log-writes); directory sync on macOS after a rename.
• force_right_to_left_layout_direction in an exported game.
• Controller names per OS, steam_input_index on a Steam Deck, SDL3's pad limit on Windows.
• Why Godot 4.7.2's headless editor (--headless --editor --quit-after N) aborts at exit about one run in three, with no plugin and an empty project (Parameter "singleton" is null in EditorNode::is_cmdline_mode, exit 134): worth a minimal reproduction for an upstream report; tests/Test-ReportPins.ps1 allows exactly that abort.
• Why a process that registered a C# Logger hangs at exit under coverlet (Godot 4.7.2 mono): no engine symbols; worth a minimal reproduction for an upstream report.
• An 8-hour soak on a schedule (GitHub jobs stop at 6 hours); latency in soak (tc ... netem missing here; a lag-simulating MultiplayerPeerExtension was prototyped, not shipped).
• Sentry's add-on end to end (its binaries could not be downloaded).
• Floats on Arm64 and across operating systems, and Godot physics across machines: a matrix job printing a replay checksum on Windows, Linux and macOS would answer it.
• Unloading C# mods from a collectible load context (the skill tells games to restart instead).
• The C# forms of the suspend and controller-loss tests (they compile; only GDScript was run); how much the import cache saves on a large project.
• The C# example's Steam backend (SteamworksApi) on a real client: achievements and stats shown in the overlay, leaderboard upload and callbacks (FindOrCreateLeaderboard, UploadLeaderboardScore), RestartAppIfNecessary with your App ID, an exported build's natives in data_<name>_<platform>/; only the no-client path ran.
• Steam on the real client: achievements, Cloud conflicts, overlay, glyphs, keyboards, DLC, relaunch; branch deployment and anonymous dedicated-server downloads; GodotSteam 4.23.2 on macOS; SteamDeck=1, OS.GetDistributionName(), gamescope focus events and sleep on a Deck.
• Steam Workshop, mod.io, Easy Anti-Cheat and BattlEye in a Godot game (need accounts and keys).
• Whether an export template lists only the components it compiles in (Engine.get_copyright_info()); credits lists every component.
• Phones and browsers: export -Run of Android on an emulator (GitHub's runners have KVM); Android checks after export (aapt2 target API, zipalign -P 16, signature, .a and .pdb files); iOS exports; audio unlock in Safari and WebKit; two fingers on two Buttons and touch on a device; a rotation on a device against the flow's resize.
• Desktop export -Run of release builds, which may hide script errors as the web release build does.
• Add-on feature flags for macOS with one architecture and Web with variant/extensions_support on; Dialogue Manager in a C# game exported without opening the editor.
• XR (xr): everything that needs a headset. Tracking quality and latency, optical hand tracking and controller-inferred hands on any runtime, passthrough and the blend modes on a Quest or a see-through device, refresh-rate changes and the physics rate match, foveation, the OpenXR vendors plugin and the Android export, SteamVR and Monado, whether the comfort numbers of xr_math.gd (snap angle 30, vignette 0.35 and its hold and opening times, the blackout gap) suit players, and whether Godot XR Tools 4.6.0 loads on Godot 4.7.2 (its README table was read, the add-on was not run). The headless fixture covers the names, the no-headset rig, a tracker standing in for a controller and the numbers' shape.

Sources and answers out of reach

Pasting a source, allowing a host or answering a question is enough for each.

• Marc LeBlanc's eight kinds of fun (www.8kindsoffun.com): the site's TLS certificate has expired. Optional.
• Bohemia's wiki (community.bistudio.com): a Cloudflare challenge. Optional: "DayZ:Central Economy Configuration" and "Arma Reforger:Multiplayer Scripting".
• The full Iassenev interview on A-Life (AIGameDev, archived): web.archive.org rate-limited this server.
• Lars Lidén's "Artificial Stupidity: The Art of Intentional Mistakes" (AI Game Programming Wisdom 2): the author's copy (lars.liden.cc) has a self-signed certificate and web.archive.org reset the connection, so game-ai/mistakes.md rests on two papers that cite it and quotes nothing from the chapter. Pasting it would let the other points be checked.
• FMOD: the Skill Tree course (needs a sign-in) and the licence and credit terms (a JavaScript-only page).
• Sonniss's bundle licence (License.pdf) and Freesound's FAQ: both returned 403.
• Epic and GOG cloud-save conflicts (404 and 500); PlayStation and Nintendo save rules, TRC and Lotcheck (under NDA).
• Valve: the networking articles and developer wiki ("Cabal process"), the Left 4 Dead and Team Fortress 2 commentary transcripts, Game Developer November 2005 ("Scaling the Cabal") and the Xperf deck (images; needs OCR); the Overwatch and Sea of Thieves GDC talks.
• EUR-Lex, gdpr-info.eu, cnil.fr, fcc.gov and ecfr.gov (the CVAA's games waiver and grandfathering for legal section 7).
• Steam's partner pages (no app yet): the short description limit, capsule formats and size caps, whether a trailer is required for review, custom EULA setup, whether Steam wants a game privacy policy; a trailer's container, length and minimum size; whether Valve's 9 px means the font size or the letters' height.
• IARC's questions (only inside a store's portal): then a ratings.json answers file with a plan gate.
• Next Fest registration deadlines per edition, and whose public holidays count in the release timeline.
• GodotSteam's licence, the Steamworks SDK redistribution terms, GOG's asset specs and build tool, Google Play App Signing, Azure Artifact Signing eligibility (needs the owner's account).
• itch.io's SharedArrayBuffer checkbox (only secondary sources).
• Kenney's PlayStation shoulder and right-stick picture names: the pack listing was cut off (PromptGlyphs returns text).
• xr: docs.godotengine.org, combineoverwiki.net (the Half-Life: Alyx commentary) and roadtovr.com did not resolve from the session that wrote it (a host outside its allowed network). The manual was read from the godot-docs repository instead; the Alyx quotes are the ones docs/valve.md section 7 already holds, not re-read. Allowing those hosts would let a later pass re-check the quotes and read the XR pages of the stable manual. Not looked for: Valve's, Meta's and Sony's own VR comfort guidelines and any GDC VR talks beyond the commentary.
• W4 Games' support for Godot 4.7 (4.4 to 4.6 in October 2026): check before a console port.
• COPPA amendment dates and the Belgian loot box report (only secondary sources); which rating bodies charge per region; the licence wording of older tabletop SRDs (3.5 under OGL 1.0a); WIPO publication 959 (Mastering the Game).
• For the owner's lawyer: whether crash reports may rest on legitimate interest, access requests with random ids, and whether a store's DRM counts as a "technological measure" under CC BY.