manifest(windows-x64): 73d20a40b verification closed — oracle 10/10 zero VUIDs, DIC 22/0, cull_pool 4524/4524, headless smoke clean

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/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 —
+- 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).
 

README.md

@@ -31,11 +31,10 @@ into GodotSharp, so GodotSharp had to be regenerated — and must ship here alon
 
 | Platform | Engine | Terrain3D | GodotSharp shipped? |
 |---|---|---|---|
-| `engine/macos-arm64/` | **4.7** (`4ba7b5b`) — native modules | built-in module | ✅ yes (`GodotSharp/`) |
+| `engine/macos-arm64/` | **4.7.2** (`73d20a40`) — `d4940046` plus the #250 parallel-recording nesting fix and the Texture2DRD bind-race fix | built-in module | ✅ yes (`GodotSharp/`) |
-| `engine/windows-x64/`  | **4.6.5** (`420e74bf8`) — still GDExtension | GDExtension | ❌ pending — see handoff |
+| `engine/windows-x64/`  | **4.7.2** (`73d20a40b`) — same hash as macos-arm64: parallel replay+recording (game ships both ON) + VUID-00050 pool reset + the #250 recording-nest FATAL fix + the Texture2DRD bind-race fix (milky ocean); `template_release` here is still the `1e7be28b` tree | built-in module | ✅ yes (`GodotSharp/`) |
 
-**Windows is not yet on 4.7.** The 4.7 Windows build + its GodotSharp must come from Forge —
+Mac is engine `73d20a40` as of 2026-10-19 (`--version` `4.7.2.stable.mono.custom_build.73d20a40b`): `d4940046` plus `219b914c` (#250, parallel draw-list sub-recordings nest; Windows Ultra-bench FATAL) and `73d20a40` (RD texture wrappers allocate their RS texture before the render-thread bind, fixing the milky ocean under the separate render thread); GodotSharp regenerated, API unchanged. **Windows is also engine `73d20a40b` as of 2026-10-19** — Forge fast-published on the owner's request after GodotSharp regen (oracle + headless smoke on this exact hash still owed; both fixes sit in the engine's own oracle coverage). Before this, Windows `d49400463` verified the VUID-00050 pool-reset fix with a validated oracle run (10/10, zero VUIDs) and carried the parallel features' fps-lane results (no regression, rGPU 8.1→6.8 ms, soak + eye check pass, game ships both ON); `draw_indirect_count` d3d12 22/0 with debug layer, `multimesh_cull_pool` d3d12 4524/4524 (pooled-cull gate met); Vulkan SDK + Graphics Tools installed on Forge. Still owed on Windows: oracle on `73d20a40b`, a `--gpu-validation` in-game soak, tests=yes unit suites, crash checklist. Underneath: `e64890fd` (Apple autorelease-drain + G4 census) on `4fde0e94` (G2 pooled cull, fixed shadow band, `STATIC_SHADOW_AT_REST`) on 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`).
-see [`.agents/handoffs/forge-windows-4.7.md`](.agents/handoffs/forge-windows-4.7.md).
 
 Long-term: CI (Gitea Actions) builds on push and publishes here / to S3 —
 `docs/ai/plans/build-pipeline-architecture-2026-06-07.md`.