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

.agents/handoffs/forge-windows-4.7.md

@@ -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.

.agents/handoffs/forge-windows-e64890fd.md

@@ -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.

.agents/handoffs/forge-windows-g2-4fde0e94.md

@@ -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.

.agents/handoffs/forge-windows-gpu-diet-r0-p5.md

@@ -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).

.agents/handoffs/forge-windows-parallel-replay.md

@@ -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.

.agents/handoffs/forge-windows-render-bench-2026-10-05.md

@@ -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`.

.agents/handoffs/forge-windows-sscs-9dcc5d45.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`).

.agents/handoffs/forge-windows-static-shadow-cache.md

@@ -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`.

.agents/wiki/master-plan.md

@@ -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 —
-  see `.agents/handoffs/forge-windows-4.7.md`.
+- Windows x64: engine 4.7, built on Forge, GodotSharp shipped.
 
 ## 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).