Build artifacts for the Tinqs stack — engine editor binaries (+ their GodotSharp C# bindings). Binaries and GodotSharp are stored via Git LFS (see .gitattributes). Source lives in tinqs/engine, tinqs/ariki-game, tinqs/ariki-sim. See manifest.json for exact versions.

Use tinqs pull / tinqs push, never raw git — these are LFS-heavy.

Installing / updating the engine

Don't copy files by hand — run the update-engine skill (it lives in the game repo, which everyone has): tinqs.com/tinqs/ariki-game · .agents/skills/update-engine. Hand it to your agent; it tinqs pulls ariki-game + builds, installs the binary + GodotSharp into ../engine/bin/, wipes stale caches, and verifies. Covers macOS + Windows.

⚠️ The one rule: binary + GodotSharp are a MATCHED PAIR

Each engine binary ships with a GodotSharp/ folder (Godot's C# bindings) generated from that exact engine build. You must install them together and replace any old GodotSharp.

The engine does NOT regenerate GodotSharp at runtime. If it's missing you get a .NET assemblies not found dialog pointing at engine/bin/GodotSharp/Api/Debug.
A stale GodotSharp (from an older engine) against a newer binary throws Wrapper class not found for type: Terrain3D → terrain renders as water, animals don't animate.

This matters now because Terrain3D and agent_skinned are native engine modules (no separate addons/terrain_3d GDExtension .framework). Built-in module classes need their wrappers baked into GodotSharp, so GodotSharp had to be regenerated — and must ship here alongside the binary.

Current contents

Platform	Engine	Terrain3D	GodotSharp shipped?
`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.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/`)

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

Long-term: CI (Gitea Actions) builds on push and publishes here / to S3 — docs/ai/plans/build-pipeline-architecture-2026-06-07.md.