chore: delete every Forge handoff from builds - Windows test steps and results live on the engine wiki page that owns the feature; README and master plan point there

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018hSLRwirUk2NF4j1v2kH4Z
2026-10-19 03:09:33 +01:00
1 parent e16736c518
commit 6b7dab6242
@@ -1,62 +0,0 @@
 # Handoff → Forge (Ozan's Windows box): build Windows 4.7 + ship GodotSharp
 **Date:** 2026-06-19 · **From:** macOS 4.7 native-module migration · **For:** Windows build owner
 ## Why
 The engine moved to **Godot 4.7** and **Terrain3D + agent_skinned are now native engine modules**
 (compiled into the binary — no GDExtension `.framework`). macOS is done and shipped in this repo
 (`engine/macos-arm64/`). **Windows is still 4.6.5 with the GDExtension** and must be brought up to
 4.7 the same way, or Windows teammates can't run the new `ariki-game` (the game-side cutover removed
 the terrain GDExtension).
 ## The critical bit (don't skip)
 After the 4.7 build you **must regenerate GodotSharp and ship it next to the binary.** A native
 module changes the engine's class list; the C# bindings (`GodotSharp`) must be regenerated to
 include `Terrain3D` / `MultiSkinnedMeshInstance3D`, or the game throws
 `Wrapper class not found for type: Terrain3D` (terrain = water, animals frozen). The engine does
 **not** regenerate GodotSharp at runtime.
 ## Steps (Windows)
 1. **Sync engine source** to the current `tinqs/engine` `main` (single 4.7 snapshot, `4ba7b5b`).
   ```
   cd engine
   tinqs pull            # or: git fetch origin && git checkout main && git reset --hard origin/main
   ```
 2. **Build the editor**:
   ```
   scons platform=windows target=editor arch=x86_64 module_mono_enabled=yes
   scons platform=windows target=editor arch=x86_64 module_mono_enabled=yes windows_subsystem=console   # console binary
   ```
 3. **Regenerate the mono glue + GodotSharp assemblies** (this is the step that fixes the wrapper errors):
   ```
   bin\tinqs.windows.editor.x86_64.mono.exe --headless --generate-mono-glue modules\mono\glue
   python modules\mono\build_scripts\build_assemblies.py --godot-output-dir=bin --godot-platform=windows
   ```
   Confirm `bin\GodotSharp\Api\Debug\GodotSharp.dll` exists and that
   `modules\mono\glue\...\Generated\Constructors.cs` contains `Terrain3D` (grep it).
 4. **If you hit the same build errors I did** (already fixed in `main`, but for reference): a core
   module can't expose an editor-API type — `Terrain3D::set_plugin` must take `Object*` not
   `EditorPlugin*`; `Terrain3DAssetResource` must be `GDREGISTER_ABSTRACT_CLASS`; drop the redundant
   `Terrain3DRegion::duplicate` bind. These are already in `main` — a clean pull should have them.
 5. **Drop into this builds repo** (`engine/windows-x64/`):
   - `tinqs.windows.editor.x86_64.mono.exe` (+ `.console.exe`)
   - the whole `GodotSharp/` folder  ← **new requirement; was previously .gitignored**
 6. **Update `manifest.json`** windows-x64 block: version `4.7…`, `engine_commit` `4ba7b5b`, new
   sha256s, add `"godotsharp": "engine/windows-x64/GodotSharp"`, clear the "pending" note.
 7. `tinqs push`.
 ## Verify
 On a Windows machine with `ariki-game`: run the update-engine skill (`.agents/skills/update-engine`,
 Windows path), launch `game.sh run`. Healthy = terrain renders, animals animate, **0**
 `Wrapper class not found`, no `.NET assemblies not found`.
 ## Notes
 - `.gitattributes` already LFS-tracks `engine/**`, so the binary + GodotSharp go to LFS automatically.
 - The macOS side in this repo is the reference for exactly what the layout should look like.
 - Game-side cutover (GDExtension removal, `project.godot`→4.7) is committed on `ariki-game` `main`
  (held pending team sync) — Windows teammates need this engine before that lands for them.
@@ -1,22 +0,0 @@
 # Forge: Windows build of engine e64890fd
 Mac published `e64890fd` (`4.7.2.stable.mono.custom_build.e64890fd3`); the game pins `4.7.2@e64890fd3`.
 Windows at `4fde0e94d` is locked out by the pin until this lands.
 What changed since `4fde0e94`:
 - Apple-only: the render thread drains an autorelease pool each flush (`rendering_server_default.cpp`, `#if __APPLE__`). No Windows effect.
 - `RENDERING_INFO_GPU_CULL_MERGEABLE_DRAWS_IN_FRAME` (new enum, value 13) — GodotSharp must be regenerated.
 - Metal `draw_indirect_count`: null scratch errors loudly. No Windows effect.
 Steps (same flags as the `windows-x64` manifest block, Vulkan only — no D3D12 work):
 1. `git checkout e64890fd`, build the editor, `--version` must print `custom_build.e64890fd3`.
 2. `--generate-mono-glue` + `build_assemblies.py` (Api + Tools).
 3. Smoke: host a world, 0 `Wrapper class not found`; `env gpucull status` shows `(N mergeable)`.
 4. Publish `engine/windows-x64/` + manifest + README rows, `tinqs push`.
 ## 2026-10-18 Windows side done (Forge/ZCode)
 Windows published `e64890fd3` (built at `e64890fd3b` — same hash as the Mac and the pin). Whole GodotSharp
 published (Api + Tools, new enum baked in). Headless game boot clean, 0 binding errors. Step 3's in-world bit
 (host a world, 0 wrapper errors, `env gpucull status` showing `(N mergeable)`) still owed — same list as the
 G2 handoff: multimesh_cull_pool oracle on D3D12, --gpu-validation (Graphics Tools), gpucull census.
@@ -1,31 +0,0 @@
 # Forge (Windows) — rebuild engine main at 4fde0e94 (G2 pooled GPU cull + static shadow fixes)
 Mac `engine/macos-arm64` is engine `4fde0e94` (2026-10-18, `4.7.2.stable.mono.custom_build.4fde0e94d`). Windows is
 `9dcc5d458`. **The game pins `4.7.2@4fde0e94d`** (owner's call: publish Mac-only while Windows sleeps), and
 `shaders/tree_wind.gdshader` uses the new `STATIC_SHADOW_AT_REST` built-in, so a 9dcc5d45 engine both hits the
 mismatch dialog and fails that shader. Rebuild before anything else on Windows.
 ## Build
 `tinqs pull` the engine and `git checkout 4fde0e94` (later main commits may be docs or G4 work; build the pinned hash).
 Flags from the `windows-x64` manifest block. Regenerate GodotSharp from that binary (`--generate-mono-glue
 modules/mono/glue`, `build_assemblies.py --godot-output-dir=bin --godot-platform=windows`) and publish the WHOLE
 `bin/GodotSharp` (`Api/` and `Tools/`).
 ## New since 9dcc5d45 (not compiled on Windows yet)
 - G2 pooled GPU cull: `servers/rendering/gpu_cull_arena.h`, `renderer_rd/shaders/effects/multimesh_cull.glsl`,
  `renderer_rd/effects/multimesh_cull.*`, `storage_rd/mesh_storage.*`, `forward_clustered/render_forward_clustered.cpp`.
  Three shared storage arenas (each < 512 MiB, the D3D12 raw-buffer limit); no buffer device address.
  Switch `rendering/occlusion_culling/gpu_cull_pooled` / `RenderingServer.multimesh_gpu_cull_set_pooled`, default off.
 - Fixed shadow LOD band for gpu-culled MultiMeshes (`gpu_cull_shadow_fixed_band`, `multimesh_set_gpu_shadow_band`), default off.
 - `STATIC_SHADOW_AT_REST` shader built-in, true only in static shadow tile passes when
  `rendering/lights_and_shadows/directional_shadow/static_casters_at_rest` is on; default off.
 ## Checks
 1. Oracle `bash tests/gpu_oracle/multimesh_cull_pool/run.sh <exe> d3d12` (Mac Metal: 4524/4524). This gates making
   pool the default. Also re-run `tests/gpu_oracle/draw_indirect_count/run.sh <exe> d3d12` (expect 22/2 as before).
 2. Game in-world on the new pair: `tree_wind` compiles (no `Unknown identifier STATIC_SHADOW_AT_REST`).
   `env gpucull status`; then the G0/G1 profile (`.agents/handoffs/2026-10-18-windows-g0-render-thread-profile.md`
   in ariki-game) with states `"pool off=gpucull:pool off" "pool on=gpucull:pool on"`. Mac result: cull dispatches
   258/422/464 → 2, fps +1/0/+1, render CPU −0.3 ms at the village; Windows records those dispatches on its render
   thread, so expect a larger gain there. Report the table.
 3. Publish windows-x64 here (binary + console binary + complete GodotSharp, sha256s, manifest note, CRLF), push.
@@ -1,48 +0,0 @@
 # Forge (Windows) — rebuild engine main at 0ec39c95 (GPU diet + R0 P5)
 Mac `engine/macos-arm64` is engine `0ec39c95` (2026-10-17). Windows is still `1e7be28b1`. The game pins `4.7.2`
 without a hash until Windows carries the same commit; then pin `4.7.2@0ec39c95` in ariki-game `project.godot`.
 ## Build
 `tinqs pull` the engine, then the `windows-x64` manifest flags (MSVC, `platform=windows target=editor
 module_mono_enabled=yes`), regenerate GodotSharp from that binary, publish binary + console binary + GodotSharp here
 with sha256s, note in `manifest.json`.
 ## New and NOT yet compiled on Windows (no toolchain on the Mac)
 - `platform/windows/crash_report_windows.{h,cpp}`, `crash_handler_windows_seh.cpp` / `_signal.cpp` (MiniDumpWriteDump,
  pre-started writer thread, unhandled-exception filter), `os_windows_stack_sampling.cpp` (freeze watchdog stack walk),
  dbghelp/psapi linked in every target (`detect.py`, `SCsub`).
 - `drivers/d3d12/rendering_device_driver_d3d12.{h,cpp}`: GetDeviceRemovedReason + DRED on device removal.
 - Verification checklist: engine `.agents/wiki/crash-freeze-and-error-reporting.md` (8 steps: main-thread crash,
  worker-thread crash, stack overflow, native freeze, C# freeze, D3D12 TDR via `dxcap -forcetdr --gpu-breadcrumbs`,
  `--disable-crash-handler` writes nothing, release template build links dbghelp).
 ## Bench after the build (the pacer box)
 ariki-game `.agents/plans/gpu-frame-diet-ui-opaque-prepass-2026-10-17.md` and `render-thread-diet-2026-10-17.md`:
 run the Jungle/Main stands with `--gpu-profile`; the RENDER CPU PROFILE block now prints `_draw wall` and
 `end_frame (graph replay + submit)` — the split of the 12.6 ms render-thread floor that Phase 0 asked for.
 ## Next: both platforms to 7fb81364 (crash-report review fixes)
 Engine main is `7fb81364` (`a040761b` + `7fb81364` on top of `0ec39c95`): freeze-report note/context read under a lock,
 debugger pauses never count as stall time, macOS sidecar `thread_id`, one first-wins atomic claims a Windows crash.
 No API change — GodotSharp is unchanged. Mac has built `7fb81364` (Kraken, `4.7.2.stable.mono.custom_build.7fb81364b`)
 but does NOT publish it yet: the game pins `4.7.2@0ec39c954`, so a lone Mac publish would lock every Mac out.
 Windows (Forge):
 1. Build `7fb81364` with the manifest flags. The Windows files changed here were NOT compiled on the Mac:
   `platform/windows/crash_handler_windows_seh.cpp`, `platform/windows/crash_report_windows.{h,cpp}` — if they fail,
   write the error here.
 2. If you have a `tests=yes` build: `--test --test-case="*CrashReport*,*FreezeDetector*,*FreezeWatchdog*,*AgentLog*"`.
 3. Publish windows-x64 `7fb81364`, then tell Kraken: Mac publishes its `7fb81364` binary and the pin moves to
   `4.7.2@7fb81364b` in the same game push.
 ## 2026-10-17 Windows side done (Forge/ZCode)
 Windows published `7fb81364` (builds `871000b`): both crash files compiled clean, editor target only,
 GodotSharp regenerated from the binary (byte-identical bindings, as expected — no API change).
 No `tests=yes` build on this box, so the `*CrashReport*/*FreezeDetector*/*FreezeWatchdog*/*AgentLog*`
 test cases did NOT run here — still owed. Headless game boot on the new binary: clean, 0 binding errors.
 Game pin is version-only `4.7.2` as of ariki-game `main` — Kraken: publish your `7fb81364` binary, then
 flip the pin to `4.7.2@7fb81364b` in the same game push (both platforms will carry it).
@@ -1,129 +0,0 @@
 # Forge: Windows A/B of parallel draw-list replay + recording (engine a967d12b)
 Why: Windows sits at 45–50 fps with the RTX 5080 idle. The render thread is the limiter (10–13 ms wall, `end_frame`
 replay + submit 3.8–4.8 ms). The NVIDIA/WDDM driver path is paid serially on that thread for every `vkCmd*`.
 Engine `06ecc5df` can cut large draw lists into chunks and record them into secondary command buffers on worker
 threads (Vulkan only, **default off**). Design + Mac results: engine `.agents/wiki/parallel-draw-replay.md`.
 Since then the engine also does **parallel recording** (Forward+ splits a pass's render list over worker threads, each
 recording its own slice of the draw list; every driver; default off) — `gpucull record on|off|status`. It attacks the
 other half of the render thread (Godot's per-draw bookkeeping before the driver). Same page, § Parallel recording.
 Nothing is published or pinned for this yet. This is a test build on Forge only.
 ## 1. Build + oracle (Vulkan, Khronos layer)
 1. `git checkout a967d12b` in the engine (replay + recording), build the Windows editor with the `windows-x64` manifest flags.
   GodotSharp regen is not needed for the test: the game reaches the new API through `Call`.
 2. With the Vulkan SDK's validation layer available (`--gpu-validation` turns it on):
   `bash tests/gpu_oracle/parallel_draw_replay/run.sh <tinqs.windows.editor.x86_64.mono.exe> vulkan`
   Expect `ORACLE: 10 passed, 0 failed`, exit 0, **zero `VUID` / validation lines** in the output. Paste the
   output back.
 ## 2. In-game A/B (box otherwise idle, one engine, nothing else running)
 Laptop setup first, and write the settings into the report (each one alone can move fps 8–15 %):
 - Plugged in; Windows power mode **Best performance**; the maker's performance/turbo profile.
 - **MUX switch on dGPU only** (Ultimate / Discrete mode in the maker's app; needs a reboot). In hybrid mode
  every frame is copied through the AMD integrated GPU to the panel. If the laptop has no MUX, say so.
 - Record the CPU name (`Get-CimInstance Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors`).
  On a Ryzen AI 9 HX 370-class chip only 4 cores are full-speed; note in Process Explorer (Threads) which cores the
  engine's busiest threads sit on.
 The game pins `4.7.2@e64890fd3`; skip the pin for this test build:
 ```bash
 TINQS_ENGINE_SKIP_CHECK=1 GAME_ARGS=--gpu-profile GAME_RES=1600x900 bash tools/game.sh run
 READY_TIMEOUT=400 bash tools/game.sh ready
 curl -s -X POST 127.0.0.1:4328/command -d '{"command":"host_game"}'   # if it stops at the menu
 # wait until in the world with fps settled (~50 s+), then:
 curl -s -X POST 127.0.0.1:4328/command -d '{"command":"gpucull","value":"replay status"}'   # supported True
 LOG="$APPDATA/Tinqs/app_userdata/Ariki/logs/godot.log"
 OUT=.game-cli/replay-windows-$(date +%Y%m%d-%H%M)
 ARIKI_API=http://127.0.0.1:4328 python tools/render_thread_profile.py --log "$LOG" \
  --poses tools/render_thread_poses.json --out "$OUT" --blocks 8 \
  --states "both off=gpucull:replay off;gpucull:record off" "replay=gpucull:replay on;gpucull:record off" \
           "record=gpucull:replay off;gpucull:record on" "both on=gpucull:replay on;gpucull:record on" \
  --restore "gpucull:replay off;gpucull:record off"
 ```
 Also take three `curl -s 127.0.0.1:4328/mainthread` reads with replay off and with replay on (from `e3582841a`).
 They show which thread paces the frame.
 Also: `curl -s -X POST 127.0.0.1:4328/command -d '{"command":"occlusion","value":"off"}'` vs `on` at the spawn pose
 (5 `/perf` reads each) — the 1.2–1.3 ms "Update Occlusion Buffer" label decides whether CPU occlusion culling earns its
 cost now that vegetation is GPU-culled.
 Also, after the run above (it can be its own run if the first one has already started), GPU depth-pyramid
 occlusion for the gpu-culled vegetation (`rendering/occlusion_culling/gpu_hzb`, default off). It costs the render
 thread nothing. On the Mac it cut kept plants by 16 % and GPU time by ~2 ms; it has never been measured on Windows:
 ```bash
 OUT=.game-cli/hzb-windows-$(date +%Y%m%d-%H%M)
 ARIKI_API=http://127.0.0.1:4328 python tools/render_thread_profile.py --log "$LOG" \
  --poses tools/render_thread_poses.json --out "$OUT" --blocks 8 \
  --states "hzb off=gpucull:hzb off" "hzb on=gpucull:hzb on" \
  --restore "gpucull:hzb off"
 ```
 Eye check with `hzb on`: turn the camera fast past a hill and a house. Plants must not pop in a frame late or
 vanish while visible.
 Control, its own launch after the runs above: rendering on the main thread (`--render-thread safe`) instead of the
 project's separate render thread. A frame should cost max(main, render) with the separate thread and main + render
 without it; Windows reads ~22 ms against a ~11 ms `_draw` wall, which looks like main + render.
 ```bash
 TINQS_ENGINE_SKIP_CHECK=1 GAME_ARGS="--gpu-profile --render-thread safe" GAME_RES=1600x900 bash tools/game.sh run
 # same ready / host_game / settle as above, then the 4-state profile again with OUT=.game-cli/safe-windows-$(date +%Y%m%d-%H%M)
 ```
 Plus three `/mainthread` reads with the separate thread (default launch) and three with `safe`, all with
 replay + record off. Report `mainWorkMs`, `tailAndRenderSyncMs`, `verdict` p50/p95 for each. If `safe` costs about
 the same frame time as `separate`, the separate thread is not overlapping anything on Windows.
 Report per pose and state: frame ms, `_draw` wall, `end_frame`, render-CPU labels, fps p25, `/perf
 gpucullCounters.parallelReplay` (lists / chunks), pixel diff vs the A/A floor, and the full `results.json`.
 ## 3. Soak + eye check
 `gpucull replay on`, walk 10 minutes (shore, inland, village, a tree felling), with `--gpu-validation` on a second run:
 no device lost, no `PARALLEL-REPLAY-BUG`, no validation errors. Eye check where tree/rock shadows fall on open sand.
 A stepped shadow edge was seen in one Mac capture and is probably a static-tile boundary; compare replay off vs on
 at the same spot.
 ## Decision rule
 Default flips on (`rendering/rendering_device/parallel_draw_replay/enabled=true` in the game's `project.godot`,
 then publish + pin) only if: oracle clean, soak clean, and frame time / `end_frame` drop at all 3 poses.
 `gpu_hzb` flips on (game `project.godot`) if frame time and render-GPU ms do not rise at any pose and the eye check
 is clean.
 ## 2026-10-19 Engine-side test results on Forge (ZCode) — build a967d12bf, NOT published (test-only per this handoff)
 Tooling note: Vulkan SDK + Khronos validation layer and the D3D12 debug layer (Graphics Tools) are now
 INSTALLED on Forge (admin install, C:\VulkanSDK) — the "--gpu-validation owed" notes in the manifest are
 resolved from here on.
 1. parallel_draw_replay oracle, vulkan, --gpu-validation (RTX 5080): **ORACLE: 10 passed, 0 failed, exit 0**
   (replay 64x8/8x32/120x2/16x3, record 96x8/8x32/200x2, record+replay 16x5, inline-again — all pixel-identical,
   real chunk splits up to 160 chunks).
   **VUID FINDING (not zero-VUID as this handoff expected):** 10x VUID-vkBeginCommandBuffer-commandBuffer-00050
   ("commandBuffer must be in the initial state … pool must have VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT").
   They fire in the FIRST parallel state (after the inline reference, before its PASS) and hit the duplicate limit.
   Control: 120 frames of the same project, validation on, feature OFF → 0 VUIDs. So the parallel path re-begins
   secondary command buffers from pools without the RESET bit — spec-UB that the current NVIDIA driver tolerates
   (and MoltenVK runs never flagged). Benign today, but a candidate fix is the pool flag or explicit
   vkResetCommandBuffer per chunk reuse. Pixel identity is unaffected.
 2. draw_indirect_count oracle, d3d12, debug layer ON (run.sh): **22 passed, 0 failed, exit 0**, with the expected
   `ORACLE SKIP base-instance cases: D3D12 shaders see base instance 0` line and zero D3D12 ERROR lines — this now
   matches the wiki Windows checklist exactly (the earlier 22/2 was the no-debug-layer run where the cases ran
   instead of skipping). Old "owed" item closed.
 3. multimesh_cull_pool oracle, d3d12, debug layer ON: **4524 passed, 0 failed, exit 0**, zero D3D12 ERROR lines —
   full parity with Mac Metal (4524/4524). The "base-instance gap may bite pooled draws" concern did NOT
   materialize; per the G2 handoff this un-gates making pool the default. Old "owed" item closed.
 Still owed on Windows: the in-game A/Bs of this handoff (replay/record 4-state + occlusion on/off at the spawn
 pose, render_thread_profile.py tables), the 10-minute replay soak + shadow-edge eye check, the tests=yes unit
 suites (CrashReport/FreezeDetector/FreezeWatchdog/AgentLog/GpuCullArena/StaticShadow), and the 8-step crash
 checklist. Publishing windows-x64 a967d12b + the default flip remain Ozan's call after the VUID finding.
@@ -1,12 +0,0 @@
 # Forge (Windows) — rebuild pair from engine main ≥ 615e852f, re-judge the render verdicts, pin (2026-10-05)
 macOS pair `615e852f` (code `c76f2ecc`) is published here. Windows is still `b1bc0aef` (2026-09-28).
 1. Build the Windows editor + console pair from `tinqs/engine` main with the `windows-x64` manifest flags
   (`platform=windows target=editor arch=x86_64 module_mono_enabled=yes d3d12=yes angle=yes accesskit=yes`),
   regenerate GodotSharp from that exact binary, smoke (0 wrapper errors), publish here, update `manifest.json` +
   `README.md`.
 2. Then pin `tinqs/required_engine_build="4.7.2@<hash7+>"` in `ariki-game/project.godot` (both platforms on the same commit).
 3. Re-judge on Windows what the Mac measured (frame GPU-bound on M1): static shadow cache default (now OFF on Apple
   silicon game-side, ON elsewhere — keep ON on Windows only if `inverted` ≥ `cache_off` fps), GPU veg bands, HLOD.
   Full recipe + numbers: `ariki-game/.agents/handoffs/2026-10-05-forge-windows-render-bench-handover.md`.
@@ -1,56 +0,0 @@
 # Forge (Windows) — rebuild engine main at 9dcc5d45 (SSCS + hero combine + shadow fixes + indirect count)
 Mac `engine/macos-arm64` is engine `9dcc5d45` (2026-10-18, `4.7.2.stable.mono.custom_build.9dcc5d458`). Windows is
 still `7fb81364b`. **The game already pins `4.7.2@9dcc5d458`** (owner's call: publish Mac-only), so every Windows
 engine is refused with the mismatch dialog until this is published. `TINQS_ENGINE_SKIP_CHECK=1` runs the old engine
 meanwhile, but the sun then shows shadow acne (the game's sun bias 0.014 expects the #124348 bias fix).
 ## Build
 `tinqs pull` the engine (main is `91b11b70` = `9dcc5d45` + docs only), build with the `windows-x64` manifest flags
 (`platform=windows target=editor module_mono_enabled=yes -j32`). The `--version` hash will read `91b11b70…` unless
 you `git checkout 9dcc5d45` first; either is fine (docs-only difference) — record what you built in the manifest.
 Regenerate GodotSharp from that binary: `--generate-mono-glue modules/mono/glue`, then `build_assemblies.py
 --godot-output-dir=bin --godot-platform=windows`. Publish the WHOLE `bin/GodotSharp` (`Api/` AND `Tools/`;
 `Tools/` is always written to `bin/GodotSharp/Tools`, a scratch output dir has no `Tools/` and the editor `--import`
 then fails with "Dependency resolution failed for GodotTools.dll").
 ## New since 7fb81364 (none of it compiled on Windows yet)
 - `298bc2a6` `RenderingDevice.draw_list_draw_indirect_count`: D3D12 native path (`drivers/d3d12/rendering_device_driver_d3d12.cpp`).
 - `2ce4f359` screen-space contact shadows for directional lights (compute shader `screen_space_contact_shadows.glsl`,
  binding 39 in the Forward+ scene shader, `DirectionalLightData::sscs_index` at byte 64).
 - `bb1f12e4` tight directional caster culling on each cascade's real frustum (upstream #121775).
 - `5df5c8df` hero shadow min-combine (`RenderingServer.instance_light_directional_set_hero_shadow_spot`).
 - `9dcc5d45` depth bias = `MAX(shadow_blur, 1)` scale (upstream #124348).
 ## Checks
 1. Oracle: `bash tests/gpu_oracle/draw_indirect_count/run.sh <tinqs.windows.editor.x86_64.mono.exe> d3d12` from Git Bash.
   Expect `ORACLE: 22 passed, 0 failed`, a `SKIP base-instance` line, exit 0 (engine wiki `draw-indirect-count.md`
   § Windows checklist; Mac/Metal was 24/24). Also the Vulkan driver if the game runs Vulkan there: `… run.sh <exe> vulkan`.
 2. Game in-world on the new pair (pin satisfied):
   - `env herocombine` status reports `mode combine (engine combine yes)`; the hero's spot shadow merges with the sun's.
   - `env contactshadow on` → contact shadows under feet/grass; `--gpu-profile` shows `SSCS Main` / `Process SSCS`
     (Mac M1 Max ≈ 0.43 ms at the beach); `env contactshadow length 0|2`, `blur 0` change it live; `off` restores.
   - Sun shadows: no acne stripes, feet keep contact on bright sand (bias 0.014 x MAX(0.35, 1)).
 3. Publish windows-x64 here (binary + console binary + complete GodotSharp, sha256s, manifest note, CRLF), push.
 ## 2026-10-18 Windows side done (Forge/ZCode)
 Windows published `9dcc5d458` (built at `9dcc5d458f` — docs-only commits excluded so both platforms + the pin
 share one hash). Whole `GodotSharp` published (Api + Tools). Headless game boot: clean, 0 binding errors.
 - Oracle `draw_indirect_count` d3d12 (RTX 5080): **22 passed, 2 failed** — the 2 base-instance cases, the
  documented D3D12 gap (expected-fail per draw-indirect-count.md; got `[0]`/`[0,1]` where `first_instance` is
  ignored). They RAN rather than SKIPped — the skip gate seems D3D12-absent; same result either way.
 - `--gpu-validation` could NOT run: D3D12 debug layer is not installed on Forge (`_initialize_debug_layers`
  → ERR_QUERY_FAILED → context fell back to Vulkan, which then reports SUPPORTS_DRAW_INDIRECT_COUNT false —
  the capability bit only exists on Metal/D3D12 in this fork). Install Graphics Tools for the validation pass.
 - In-world checks (herocombine / contactshadow / SSCS profile / sun acne at bias 0.014): still owed here.
 ## 2026-10-18 Windows moved to engine main 4fde0e94d (G2 pooled cull) — Kraken note
 Engine main gained `4fde0e94d7` (G2 pooled cull) after the 9dcc5d45 pair. Forge rebuilt it (8 min incremental)
 and published windows-x64 `4fde0e94d`: GodotSharp regenerated (MultimeshGpuCullSetPooled /
 MultimeshGpuCullSetShadowFixedBand / MultimeshSetGpuShadowBand present), headless game boot clean.
 Game pin relaxed to version-only `4.7.2` (a lone Windows publish must not lock Mac out — same protocol as
 7fb81364). **Kraken: publish your `4fde0e94d` macos-arm64 build, then flip the pin to `4.7.2@4fde0e94d` in the
 same game push.** Owed on Windows: `tests/gpu_oracle/multimesh_cull_pool` (D3D12 base-instance gap may bite the
 pooled draws) and the in-world gpucull census (`multimesh_get_cull_command_offset`).
@@ -1,34 +0,0 @@
 # Handoff → Forge (Ozan's Windows box): rebuild windows-x64 with the static shadow cache (2026-09-28)
 **From:** Fable orchestrator on the Mac · **Why:** `tinqs/engine` main gained the directional static shadow cache
 (Part 1) and the stepped-sun crossfade (Part 2) — Forward+ renderer, new project settings, six+four
 `RenderingServer` methods, a second depth atlas. The game (`ariki-game` ≥ 19490e358) calls the new methods by
 name and degrades loudly on an engine without them, so Windows teammates keep working on the old binary but get
 no cache. Rollout plan: `ariki-game/.agents/handoffs/2026-09-28-static-shadow-cache-rollout.md`.
 ## Steps (mirror of `forge-windows-4.7.md`, same toolchain as the fec9847 build)
 1. `cd engine && tinqs pull` → `git log --oneline -1` must show the Part 2 commit named in the rollout plan.
 2. Build (the flags recorded in `manifest.json` for fec9847):
   ```
   scons platform=windows target=editor arch=x86_64 module_mono_enabled=yes d3d12=yes angle=yes accesskit=yes
   scons platform=windows target=editor arch=x86_64 module_mono_enabled=yes d3d12=yes angle=yes accesskit=yes windows_subsystem=console
   ```
 3. Regenerate glue + GodotSharp (matched-pair law — do not skip even though no C# binding is *required* by the
   compiler; the manifest promises the pair):
   ```
   bin\tinqs.windows.editor.x86_64.mono.exe --headless --generate-mono-glue modules\mono\glue
   python modules\mono\build_scripts\build_assemblies.py --godot-output-dir=bin --godot-platform=windows
   ```
 4. Copy into this repo: `engine/windows-x64/tinqs.windows.editor.x86_64.mono.exe`, `...mono.console.exe`, and the
   whole `GodotSharp/` (replace, never merge).
 5. `manifest.json` → `engine.windows-x64`: `version` (from `--version`), `engine_commit`, both sha256s, `built_on`,
   `built_by`, `note` ("static shadow cache Part 1 + Part 2; GodotSharp regenerated"). Leave `macos-arm64` alone.
 6. `tinqs push` (LFS).
 ## Verify
 On a Windows `ariki-game` checkout: run the `update-engine` skill, `game.sh run`, host a world, then
 `POST /command {"command":"env","key":"staticshadow","value":"on"}` — the log must NOT print
 `[STATIC-SHADOW] engine without the cache`, and `GET /perf` must show `staticShadow` with `enabled: true`.
 Terrain renders, animals animate, 0 `Wrapper class not found`.
@@ -7,12 +7,10 @@ Tinqs/Ariki stack, plus `manifest.json` tracking exact shipped versions. Source
 `tinqs/engine`, `tinqs/ariki-game`, `tinqs/ariki-sim` — this repo only holds built output.
 - macOS arm64: engine 4.7, native Terrain3D module, GodotSharp shipped.
- Windows x64: engine 4.6.5 (pre-4.7), GDExtension Terrain3D, 4.7 upgrade pending Forge —
+- Windows x64: engine 4.7, built on Forge, GodotSharp shipped.
  see `.agents/handoffs/forge-windows-4.7.md`.
 ## In flight
 - Windows 4.7 engine build + matching GodotSharp (blocked on Forge machine — see handoff).
 - Longer-term: CI (Gitea Actions) building on push and publishing here / to S3 — tracked in
  `docs/ai/plans/build-pipeline-architecture-2026-06-07.md` (hub repo, not here).
@@ -34,7 +34,7 @@ into GodotSharp, so GodotSharp had to be regenerated — and must ship here alon
 | `engine/macos-arm64/` | **4.7.2** (`a967d12b`) — `e64890fd` plus parallel draw-list replay (Vulkan secondary command buffers) and parallel draw-list recording (Forward+ render lists over worker threads, every driver) | built-in module | ✅ yes (`GodotSharp/`) |
 | `engine/windows-x64/`  | **4.7.2** (`a967d12bf`) — same hash as macos-arm64: `e64890fd` plus parallel draw-list replay + recording (both default off; oracle 10/10, one VUID finding recorded); `template_release` here is still the `1e7be28b` tree | built-in module | ✅ yes (`GodotSharp/`) |
-Mac is engine `a967d12b` as of 2026-10-19 (`--version` `4.7.2.stable.mono.custom_build.a967d12bf`): `e64890fd` plus parallel draw-list replay (Vulkan only) and parallel draw-list recording (every driver), both engine-default off and turned on by the game; GodotSharp regenerated; oracle `parallel_draw_replay` Vulkan 10/10, Metal 5/5 (`engine/.agents/wiki/parallel-draw-replay.md`). **Windows is also engine `a967d12bf` as of 2026-10-19** — Forge ran the engine-side tests before publishing (`.agents/handoffs/forge-windows-parallel-replay.md`): replay+record oracle Vulkan with validation **10/10 exit 0** but **10× VUID-vkBeginCommandBuffer-00050** in the first parallel state (secondary command buffers re-begun from pools without `RESET_COMMAND_BUFFER_BIT`; feature-off control = 0 VUIDs; NVIDIA tolerates it, MoltenVK never flagged — engine-owner fix owed); `draw_indirect_count` d3d12 with the newly installed debug layer **22/0 + expected SKIP line** (the old 22/2 was the no-layer run where base-instance ran instead of skipping); `multimesh_cull_pool` d3d12 **4524/4524** — parity with Mac, un-gating pooled-cull default per the G2 handoff. Vulkan SDK + Graphics Tools are now installed on Forge, closing the "--gpu-validation owed" notes. Still owed: the parallel handoff's in-game A/Bs (replay/record 4-state + occlusion on/off), 10-min soak + shadow-edge eye check, tests=yes unit suites, crash checklist. Before this, Mac was engine `e64890fd` as of 2026-10-18: `4fde0e94` plus the Apple autorelease-drain fix (Mach-port leak, flat at ~640 ports now) and the G4 mergeable-draw census. Underneath, `4fde0e94` added G2 pooled GPU cull (`env gpucull pool`), fixed shadow LOD band (`env gpucull shadowband`) and `STATIC_SHADOW_AT_REST` (`env gpucull staticrest`; the game's `tree_wind.gdshader` uses it); all default off. Underneath is the `9dcc5d458` pair (SSCS contact shadows, hero shadow min-combine, upstream 4.8 shadow fixes #121775/#124348 with the game sun bias 0.014, `draw_list_draw_indirect_count`).
+Mac is engine `a967d12b` as of 2026-10-19 (`--version` `4.7.2.stable.mono.custom_build.a967d12bf`): `e64890fd` plus parallel draw-list replay (Vulkan only) and parallel draw-list recording (every driver), both engine-default off and turned on by the game; GodotSharp regenerated; oracle `parallel_draw_replay` Vulkan 10/10, Metal 5/5 (`engine/.agents/wiki/parallel-draw-replay.md`). **Windows is also engine `a967d12bf` as of 2026-10-19** — Forge ran the engine-side tests before publishing (engine `.agents/wiki/parallel-draw-replay.md` § Windows (Forge)): replay+record oracle Vulkan with validation **10/10 exit 0** but **10× VUID-vkBeginCommandBuffer-00050** in the first parallel state (secondary command buffers re-begun from pools without `RESET_COMMAND_BUFFER_BIT`; feature-off control = 0 VUIDs; NVIDIA tolerates it, MoltenVK never flagged — engine-owner fix owed); `draw_indirect_count` d3d12 with the newly installed debug layer **22/0 + expected SKIP line** (the old 22/2 was the no-layer run where base-instance ran instead of skipping); `multimesh_cull_pool` d3d12 **4524/4524** — parity with Mac. Vulkan SDK + Graphics Tools are now installed on Forge, closing the "--gpu-validation owed" notes. Still owed (same wiki section): the in-game A/Bs (replay/record 4-state + occlusion on/off), 10-min soak + shadow-edge eye check, tests=yes unit suites, crash checklist. Before this, Mac was engine `e64890fd` as of 2026-10-18: `4fde0e94` plus the Apple autorelease-drain fix (Mach-port leak, flat at ~640 ports now) and the G4 mergeable-draw census. Underneath, `4fde0e94` added G2 pooled GPU cull (`env gpucull pool`), fixed shadow LOD band (`env gpucull shadowband`) and `STATIC_SHADOW_AT_REST` (`env gpucull staticrest`; the game's `tree_wind.gdshader` uses it); all default off. Underneath is the `9dcc5d458` pair (SSCS contact shadows, hero shadow min-combine, upstream 4.8 shadow fixes #121775/#124348 with the game sun bias 0.014, `draw_list_draw_indirect_count`).
 Long-term: CI (Gitea Actions) builds on push and publishes here / to S3 —
 `docs/ai/plans/build-pipeline-architecture-2026-06-07.md`.