Gododin developer experience and integration completion plan

The 2026-10-19 Godot-first decision extends DX-1/DX-5/DX-10: setup, normal opening, Play and authored-preset Export are available through Godot, backed by the same CLI. The active workflow record owns its implementation and evidence; the earlier delivery notes below retain their recorded publication scope.

Status: in execution. Delivered through the gododin-devx-2026-09-26.3 CLI/SDK reseat (macOS recording host, 2026-09-26): DX-1's public gododin run launcher contract and installer gates, DX-10's store listing material, DX-2's engine-owner cleanup (generic owned_ref_release, the verified PREDELETE release authority with Host notification routing, named adapter result vocabularies, explicit by-name scene bindings), and DX-3's MultiMesh_Stream submission owner with the Boid Flock (3D) and Bunny Mark (2D) migration. The follow-up gododin-devx-2026-09-26.4 reseat (same host and day) fixed the facade's colors-layout allocation defect and migrated Rewind Lab's three streams and the MultiMesh fixture onto MultiMesh_Stream; the final gododin-devx-2026-09-26.5 reseat added the Windows/Linux notification adapters and re-attached and rebuilt the installed consumers. The per-package rows below carry the delivered bounds and evidence.

What is left, in order. Everything below is blocked on one or more engine runs except where noted; the recording host's engine window is the gate.

1. Engine-run evidence for delivered work is current through the gododin-devx-2026-09-26.10 closure (2026-09-27): the Cavern and setup-dock evidence refreezes, the slime zero-owner runs, the multimesh installed/readback/qualification/baseline campaigns, the editor-agent conformance probe, and both tiers are green against .9.
2. DX-3 is engine-qualified (2026-09-27) and closed: the qualification falsified the template's scene-side RID-invalidation claim, the corrected facade reseated the SDK as .6, and resize/rebind, invalid layout, resource replacement, failure rollback, scene removal and reload proofs, the distinct readback run, the measurement and the interpolation check all executed against that closure; re-executed green on .10.
3. DX-0 residuals that are not engine-gated in full: end-to-end timing comparisons beyond the recorded multimesh baseline (their editor legs share the engine window). The Windows notification adapter's runtime proof landed on the owner's host (2026-09-28, mode=notification arriving through the reload gate after two kernel-contract fixes); the Linux proof still rides that platform's real-host gates.
4. DX-4 is delivered as ADR 0069 through the .10 reseat (2026-09-27) with fixtures/authored_values (repository: fixtures/authored_values/) as its fixture. DX-5 is delivered (2026-09-28, examples/ripple_pond (repository: examples/ripple_pond/), Windows journey). DX-6 is in progress: CL-1, Cavern Lab's playable slice, CL-2, the integration loop (explicit accepted-grid identity, native classification of scene-authored candidates into pickup/exit placement, Shape-mode mask refinement, baked-grid classification), and CL-3, durable authoring (saved masks and markers, undoable authoring, deliberate Resource sharing, applied settings, the responsive supervised bake panel, and the exported bake-play consumer), and CL-4 (the integrated close: visible mask/candidate editing, focus-safe HUD, explicit scenario restart, the native editor reload journey with unsaved Godot work preserved, and executed debug/release exports), are delivered (2026-09-28/29, Windows journeys), and EX-BOID is implemented (2026-09-29, Windows host; its gameplay execution evidence awaits the SDK reseat that carries the Windows call-inventory discovery fix -- see the platform record's fourteenth entry), EX-BUNNY is implemented (2026-09-29, Windows host; same reseat bound for its three-arm execution evidence), and EX-SLIME is implemented (2026-09-29, Windows host; the kernel, its four new Odin tests, and the masked named workload executed here, with the engine-side control riding the same reseat), and EX-VOXEL is implemented (2026-09-29; its regeneration and evidence additionally wait for the voxel subsystem's Windows threading port — platform record, fourteenth entry), and DX-7 and DX-8 are delivered (2026-09-29, Windows host). DX-9 is delivered too (2026-09-29, Windows host), closing the queue. The named execution bounds then executed the same day (fifteenth platform entry): the Windows call-inventory discovery fix landed in both scans and reseated machine-locally, the voxel worker ported to core:thread with its contracts intact, and every facade project's engine gates ran through the public CLI — boid integration, voxel eval/probe and offline eval, bunny preset, slime 120k-agent headless eval, and the DX-9 GPU comparison bitwise-validated on Forward+ (16 steps, 0 mismatched cells, zero leaked RIDs). Recording-host refreeze state (2026-10-03, macOS, against gododin-dev7-2026-10-03.1): four of the five named harness legs executed and passed — bunny preset, boid integration, slime gpu, voxel eval+probe (details in the DX-6 row). The Cavern harness passes every non-export stage on the official dev7 editor; its two bake-export legs and the freeze/contract/tier chain that follows them are blocked on the dev7 export-template authority in the sealed SDK lock, and the real SDK reseat window remains owner-side.

This plan covers the improvements identified while building the external clock consumer, unfinished editor/data efficiency work, the existing example integration plan, and the additional examples needed to demonstrate Gododin's practical value. The live continuation prompt is 2026-09-26-devx-continuation-handoff.md; its original execution prompt is archived at archive/2026-09-26-devx-and-integration-handoff.md.

Authority and boundaries

The implementation plan retains product phases and C1–C5 verification policy. This document owns the order and completion ledger for the work below; it does not replace the requirements of the linked plans.

Godot keeps scenes, Resources, editor, renderer and shaders, ordinary gameplay orchestration, and export. Pure subsystems remain ordinary Odin. Helpers may own recurring foreign lifetime and batching work; this is not authorization for a Gododin ECS, renderer, job system, scripting language, or benchmark framework. Keep manual/raw escape hatches and idiomatic records, procedures and explicit allocators. Record focused ADRs when implementation changes an accepted contract.

Product priority: a solid core, then an excellent developer experience

The owner's direction, clarified on 2026-09-26, is the governing priority: once the core is correct, efficient and covers the engine API, Gododin's main investment is developer experience. A developer should write idiomatic Odin that feels useful inside Godot, with little installation, setup, integration, build or deployment administration. Native performance is a foundation; compelling everyday use is the product.

Establish core readiness from the generated coverage/resolution reports, real bulk/lifetime behavior and affected qualifications. Complete metadata-determined engine API coverage must remain complete, with explicit resolutions for actual metadata gaps. The narrower authored-value matrix is separate and grows with real consumers. Do not turn “solid core” into an indefinite rewrite or postpone all consumer improvements until every optional helper exists.

Apply these acceptance questions to every package:

• Does normal game code stay ordinary Odin, with readable data flow and explicit ownership, rather than acquiring a Gododin object model or registration layer?
• Can a consumer install, adopt, edit, test, update and export through public tools without copying locks/manifests, setting private runtime variables, maintaining duplicate declarations, or understanding contributor release choreography?
• Is repeated setup or lifetime ceremony eliminated at its owning layer, with meaningful costs and failure modes still visible? Removing boilerplate must not merely hide an allocation, copy, synchronization point or lifetime hazard.
• Do Godot scenes, Inspector/Resources, native diagnostics, navigation, reload and export form one understandable workflow? Can a normal failure be repaired from the diagnostic and the short guide rather than a tour of the ADR history?
• Does a runnable example demonstrate why the combination is enjoyable and useful, while leaving GDScript welcome for the work it suits?

Record a before/after consumer journey in DX-5/DX-10: required commands and hand-edited configuration, duplicated facts, handwritten bridge/cleanup code, first-success time, edit-to-result time, and recovery from a broken edit or relocated/upgraded SDK. Use these observations to remove actual friction; do not optimize an arbitrary line-count target or add infrastructure merely to measure it. After the foundation gate, prioritize the public workflow and compelling examples over speculative low-level features or marginal microbenchmark improvements.

Reconciled starting state

“Implemented,” “available in the selected immutable SDK,” and “qualified on this artifact and host” are separate facts. Existing receipts keep the identities and measurements they actually recorded.

The editor after-record is 2026-09-20-macos-arm64-after-note.json (repository: fixtures/efficiency/evidence/2026-09-20-macos-arm64-after-note.json). It demonstrates structural reductions and explicitly does not establish a whole-product speedup. The readback failure below is a recorded observation, not a defect reproduced during this documentation audit.

Platform follow-up from the owner: the Windows/Linux verification was performed the previous weekend on the owner's Windows PC and its Linux WSL installation; the results or source may still be uncommitted there. Recover those records first, preserve WSL/display/backend scope and reuse valid evidence. This record recovery must not stall independent DevX packages.

Execution order and progress

Use coherent batches, with focused checks while editing and publication at useful consumer boundaries. Package owners below are existing source areas, not new services or teams. Update each row with implementation, publication and evidence links as work proceeds; a checked box alone is not a completion record.

DX-0's macOS publication must close before claiming its efficiency work delivered. Do not hold all locally executable work for unavailable Windows/Linux machines. Record their precise remaining commands and prerequisites in the desktop workstream; do not mark their gates passed or the full product complete.

DX-0 — Finish efficiency and establish the actual baseline

Owners: controlprotocol/, watcher/, editor_agent.odin (repository: cmd/gododin/editor_agent.odin), editor/addons/gododin/, existing build/cache and release owners, fixtures/efficiency/ (repository: fixtures/efficiency/), fixtures/multimesh_stream/ (repository: fixtures/multimesh_stream/). Requirements: BLD-001–009, BLD-ITER, BLD-RLD, NAT-BULK; detailed acceptance remains in the efficiency plan.

1. Read current source, accepted publication and SDK identities. Reconcile the owner's Windows/Linux verification with the desktop inventory: recover logs, receipts and any unmerged source, map each executed gate to its artifact, and update status before scheduling work. A missing checkout record is not evidence that verification never occurred. Revalidate macOS after the shared Linux build-path edits if no matching run is already recorded. Do not rerun an obsolete engine to reproduce historical receipts.
2. Reproduce and resolve, or record an already-landed resolution of, the readback fixture's recorded BUILD_IMAGE_CALL_INVENTORY_UNKNOWN for its MultiMeshInstance3D cast installer. Fix the owning generation/inventory path, not generated output or an allowlist bypass. Run the existing readback harness with the active compiler/engine; retain all-float oracle checks, engine-copy and native-verify timings, allocations and foreign-call counts separately.
3. Finish native source-notification adapters on available hosts, with reported polling fallback. Prove overflow/loss recovery by a full reconciliation, atomic saves, deletion/rename, coalescing and shutdown. Windows/Linux adapter and runtime work follows the desktop plan rather than disappearing from this ledger when macOS passes.
4. Measure the remaining verification costs under the linked receipt/lock plan. The existing 59.9 s / 29.1 s phase totals include generation, tests and other work; they do not isolate hashing or prove a proposed redesign will help. Record a measured decision to retain the policy, or an ADR and implementation with before/after evidence. Preserve trust-boundary authentication, generated output checks, fail-closed run/export and historical provenance either way.
5. Publish a coherent new source closure and immutable SDK through the existing release process. The 2026-09-20 record says the sealed CLI predates the added source closure; do not “fix” this by weakening authentication or overwriting an accepted SDK. Rerun quick/locked and the affected installed-consumer gates.
6. Complete the original failure matrix: partial/saturated pipes, child exit and restart, queued cancellation, rapid/superseded edits, failed edit and repair, corrupt cache/catalog, addon disable/re-enable, watcher loss, retained unsaved scene/Resource edits, property restoration, and teardown with work outstanding.
7. Retain reproducible idle-editor, save-to-observed and game-restart comparisons for small and large projects. Report p50/p95, repetitions, noise, CPU and process launches; distinguish codec/census microbenchmarks from complete workflow timings. Preserve or explain any regression.

Local closure: packages 6 and 7 have matching measured and installed evidence for the available host, and packages 1–5 have not been redone unnecessarily. Record each unexecuted notification/platform residual under its real-host gate. Keep the efficiency plan in progress until those required residuals also close; assigning a pending gate elsewhere does not make it complete.

DX-1 — Make installation, integration, runs and deployment ordinary workflows

Owners: runtime commands (repository: cmd/gododin/runtime_commands.odin), lifecycle commands (repository: cmd/gododin/lifecycle_commands.odin), command parsing, initialization/attachment, runtime selection, export/package delivery, installed-consumer fixtures, getting-started and CLI help. Requirements: NAT-INT, BLD-CFG, BLD-DEV, BLD-VAL, EXP and ADR 0063.

Make the supported consumer journey short and repeatable. Finish the existing delivery/CLI work with its platform owner, rather than designing a second installer. Generate owned directories and ignored local configuration from explicit tool/SDK selection; stop requiring users to hand-copy canonical paths, lock facts or release metadata. Keep machine-local facts separate from portable game configuration. A fresh install, existing-game adoption, SDK relocation and upgrade should each have one documented public flow with actionable diagnostics.

Keep inspection and advanced controls available, but make authenticated defaults do the routine work. Export should use the accepted profile/target and existing Godot packaging path, with clear template/toolchain discovery or setup guidance. The normal game developer should not perform a contributor SDK reseat to update their game. Any change to discovery/authority policy requires its focused ADR; do not bypass validation to shorten the instructions.

Current gododin run accepts a scene and the explicit last-known-good override; its normal path builds debug unconditionally. gododin test runs repository qualification tiers and refuses installed-authority projects. The clock consumer therefore wrote its own publication copying, manifest inspection and image identity environment setup to run application tests.

Extend the existing launcher, with one reviewed CLI contract, to support:

• explicit native build profile, selected scene or project script, and headless application runs;
• a clear separation between admitted engine launch options and application arguments; do not allow forwarded options to replace the authenticated executable, project path, selected publication or required identity checks;
• observable exit status and stdout/stderr suitable for a consumer's own tests;
• an inspectable identity report covering engine, native profile, publication and SDK, without making callers parse private manifests or set Host variables.

Decide exact syntax in implementation; these are requirements, not commands already accepted by the CLI. A native release profile does not turn the editor executable into an exported release engine: identify both in measurements. Keep repository qualification distinct from application testing; a public launch path is enough if it composes cleanly with ordinary test scripts.

The launcher contract above is implemented and verified (2026-09-26, macOS recording host): gododin run --project-root <root> [--profile <debug|release>] [--scene <path> | --script <path>] [--headless] [--quit-after <frames>] [--env NAME=VALUE]... [--last-known-good] [-- application-args...], with the identity line, exit-status propagation, and reserved-name env refusals described in the status table. The engine's own -- user-argument classification is the separation guarantee, so no Gododin-side parser has to admit or reject engine options.

Store onboarding entry (incorporated follow-up)

The Asset Store onboarding findings are incorporated into DX-1 (primary owner), DX-5 and DX-10; its detailed requirements and acceptance criteria remain authoritative there. The incremental DX-1 scope: one add-on/SDK installation contract that makes the existing SDK installation path the store add-on's supported connect route (resolve file ownership, version matching and migration in the existing owners — editor_verify_addon/editor_install_workspace and the SDK's add-on publication — with no second updater; record a focused ADR if accepted ownership, discovery or update contracts change); an editor entry journey that is useful in an ordinarily opened editor before any SDK is connected (preserving the GODODIN_EDITOR_MODE guard so import/export subprocesses never become interactive build sessions), validates a selected SDK and engine through shared public tooling, and adopts the project through the existing owners; and a repeatable store-ZIP packaging path over maintained source with the required addons/ layout, license, guide, and no dangling .gdextension references. Store discovery/installation precedes the DX-5 tutorial's first step. Actual store submission and acceptance are recorded separately and never claimed from packaging success.

Done: an unrelated installed consumer installs/adopts with tool-generated local setup, survives SDK relocation/upgrade through public commands, exports both profiles, builds/runs both profiles and executes a script test through public commands, propagates a deliberate failure, forwards arguments correctly, and preserves profile isolation, stale-build refusal and explicit last-known-good semantics. Scene/script paths are captured and validated. The adoption example uses it; the external clock's private launcher can be removed when that consumer adopts the new SDK. No sibling checkout is a test dependency.

DX-2 — Centralize engine-owner cleanup and useful diagnostics

Owners: authored lifecycle/catalog/bridge and Host owners, handwritten typed runtime/helper sources, Slime adapter, native components and lifecycle fixtures. Requirements: NAT-HOST, NAT-KIT, NAT-THR.

The generated godot.Owned_Ref(T) and older core/render owners currently lead consumers to repeat release choreography. Authored deinit has no Godot call capability; current examples arrange an explicit capability-bearing shutdown before CPU cleanup. Preserve that authority boundary.

• Provide one appropriate generic owned-reference release path, with explicit last-reference destruction, null/repeated release behavior, failure retention and owner clearing. Reuse the metadata-derived typed operations; avoid adding another parallel handle hierarchy.
• Establish a reusable lifecycle path for engine-owned resources on normal close, scene removal, editor reconstruction/reload and partial initialization. First verify which supported Godot callback has valid authority at each point; add generated lifecycle support only where existing callbacks cannot fulfill the contract. Keep CPU-only deinit partial-safe and do not invent engine authority in a destructor or retain a callback capability.
• Migrate at least Slime and one staged-rendering consumer. Eliminate mandatory ad hoc GDScript cleanup where the supported lifecycle can own it; document any unavoidable explicit shutdown and make omission diagnosable.
• Replace opaque adapter integer failures with named errors and operation context while keeping hot paths cheap. Use already-admitted enums where sufficient; String signal work belongs to DX-4. Replace incidental child-index dependencies with explicit validated bindings where the scene requires them. These last two issues include consumer design choices, not only SDK defects.

Done: success, partial failure, repeated shutdown, scene removal and native editor reload have zero-owner evidence. A refused release retains an identifiable owner for safe recovery; it never silently loses ownership or calls Godot after its authority/lifetime ends. Document the short normal pattern and its failure rules.

DX-3 — A deep helper for retained MultiMesh submission

Owners: handwritten rendering helper layer and its generation/policy integration, current staging owner, Bunny, Boid, Rewind and the MultiMesh fixture. Requirements: NAT-KIT, NAT-BULK.

Factor the repeated acquire/configure/capacity/write/publish/submit/replace/retire sequence into one owner. Support the 2D and 3D layouts and optional instance data actually used by these consumers; validate stride, length, capacity and renderer conditions against the exact engine. Keep scene-owned mesh/RID borrowing distinct from resources the helper owns. A write view has an explicit validity interval.

Safety is the central acceptance condition: returning from multimesh_set_buffer does not prove the engine released submitted storage. The currently documented retained-write path needs direct render-thread submission, disabled physics interpolation and a non-retaining renderer path; per-instance access can introduce a CPU cache. Publication sequence numbers do not drain a server queue or wait for GPU completion.

Make that supported fast-path contract explicit and checked where observable. For other configurations provide an explicitly selected safe copying path or a clear refusal; qualify the engine's retention/completion rules before reuse. Rotating a fixed number of buffers alone is not a lifetime proof. Keep copies, allocations, synchronization and thread transitions visible in names/docs.

Done: migrate at least two existing consumers, including 2D and 3D, without changing their algorithm or render workload. Prove resize/rebind, invalid layout, resource replacement, failure rollback, scene removal and reload. Use a distinct validation run for readback/getters so instrumentation does not silently enable a retaining CPU cache in the timed fast path. Measure API calls, allocation/copy costs and output correctness; retain direct generated/raw access.

Delivered (2026-09-26, macOS recording host). The facade template gains MultiMesh_Stream — open/write/publish/submit/resize/ retire_pending/close/owned plus the MultiMesh_Layout pair (2D and 3D transform, optional colors; custom data is refused as an unexercised layout). The RID stays a scene-owned borrow the kit never frees; submit refuses a submit with no new publication and names a scene-side RID invalidation (rid_valid) before the engine call; resize runs create-first and keeps a refusing retirement reachable; close retires pending and active stores and touches nothing else. The staged store's retention constraints stay caller constraints, per the existing staging contract. Eight facade unit tests cover the cycle, the open refusals, and the resize adoption through the fake API, which now records the allocate call's transform format and color/custom-data flags. Migrated consumers: Boid Flock (3D transform-only, setup/submit/set_count/ shutdown/verify) and Bunny Mark (2D transform-only, same set) — no algorithm or workload change.

Completed with the gododin-devx-2026-09-26.4 reseat (2026-09-26, same host): the migration exposed a real facade defect — open and resize passed layout.colors into the engine allocate call's custom_data_format slot while hardwiring color_format to false, so a colors layout would have allocated an 8-float server buffer under a 12-float staged stride (harmless for the transform-only flock/bunny, invisible to the original unit tests, caught by the vendored 4.8-dev6 extension_api.json argument order). The template now passes layout.colors to color_format and never custom data; the fake API records the format and both flags, and the open/resize/cycle tests assert them. Rewind Lab's three streams (Boxes, Circles, Statics — all 2D transform+color) and the MultiMesh fixture's Stream_Field (3D transform-only) migrated onto MultiMesh_Stream with their algorithm, workload, and observable behavior unchanged: setup/submit/submit_statics/ verify/shutdown/set_capacity go through the stream owner, the per-mesh retiring staging slots collapse into the stream's own pending retirement, and the GDScript drivers' pass sentinels are untouched. All five render consumers (flock, bunny, slime, rewind_lab, multimesh fixture) generate, check, and build accepted through the .5 CLI; rewind_lab's offline subsystem and eval harnesses pass. Delivered through the gododin-devx-2026-09-26.4 reseat (facade fix and migrations, 247 members) and superseded as the final closure by the .5 reseat (adapters added, 249 members, manifest 51e099a6…); seven installed projects re-attached and five rebuilt accepted at .5. Engine-qualified (2026-09-27, same host, re-executed against the final gododin-devx-2026-09-26.8 closure). The qualification's first engine run caught a real facade-contract error: the template claimed submit names a scene-side RID invalidation (rid_valid) before the engine call, but the engine's RID.is_valid() is only a non-zero id check — a resource the scene frees keeps its non-zero RID, so the resource-replacement scenario's submit reached the server, which rejected it with its own Multimesh not found diagnostic and no-oped the write while the staged store stayed intact. The template now states the engine truth: the pre-call refusal covers zero or unset RID handles, scene RID liveness stays a caller constraint like the staged store's retention constraints, and close plus a fresh open is the named recovery. The facade was regenerated (GODODIN_RENDER_POLICY_WRITE_PASS, receipt 9483aa66…), the locked-tier sentinel re-pinned, and the SDK reseated (the addon reload fix and the adopted-staging fix later joined it as .8: prebuilt CLI gododin-devx-2026-09-26.3, sha ce1df5c3…; SDK manifest 57b00e67…, lock edddbf08…, distribution 81daf97f…); seven installed projects re-attached and five render consumers rebuilt accepted at every step. Executed on .6: the installed current run and both executed exports pass (GODODIN_MULTIMESH_INSTALLED_PASS current_run=installed exports=2; resize 1000→10000 adopted at 194 µs with both windows verifying bitwise), which also qualifies the retention rule observably — 600+ submissions rewrite the same staged store every frame and the post-window getter verify still matches the last frame, so the engine's consumption is a copy and no render-thread retention aliased the caller's store. The distinct readback campaign (validated in its own process so no instrumentation can enable a retaining CPU cache in the timed path) measured engine-copy p50 1818 µs against native borrowed-view verify p50 255 µs over 200 rounds at 4000 instances with a stable digest and zero owners at .8. The observable qualification legs all pass in one dedicated run: staged_submit_verify; failure_rollback (the out-of-range resize refuses −2, the live pair is untouched, the next submit and verify succeed); resource_replacement (the stale RID is the engine's logged no-op, close+reopen binds the replacement and recovers); scene_removal_reload (cooperative shutdown retires the owner, the node is destroyed, the class re-instantiates through ClassDB and a fresh setup submits and verifies); physics_interpolation (the staged path verifies bitwise with interpolation enabled, then the mode is restored for the fast-path contract) — final zero-owner shutdown. Measurement at .8: staged submit 41.1 µs at capacity 1000 and 155.5 µs at 10000 against the per-instance GDScript baseline's 202.9 µs and 1407.8 µs on the same host and run shape (debug profile, windowed Forward+/Metal, one host, uncapped; the bracket includes the producer fill, which dominates at 10000). No DX-3-specific residual remains; the package 6/7 failure matrix and the Windows/Linux real-host proofs stay recorded under DX-0.

DX-4 — Expand authored values where normal consumers need them

Owners: authored resolver, catalog/bridge/Host wire conversions, existing value fixtures, Native PRD and generated documentation. Requirements: NAT-DEV-002/003, property/signal ownership and precision requirements.

Generated engine-call coverage is already broad. The gap is types admitted in authored methods, properties and signals, not a need for another binding layer.

Signatures agreed (2026-09-27, macOS recording host), from the surveyed admission surface: the authored resolver (tools/cataloggen/project_authoring.odin) today admits bool/i64/f64/String plus admitted enums and bit-sets in property fields, the same scalars/enums/flags plus borrowed class pointers in signal payloads, and the method surface adds object borrows, owned references, engine-object borrows, Packed_Bytes, Vector3, Packed_Float32, and Packed_Vector3 (Type_Kind in tools/cataloggen/contracts.odin). The next consumers establish four admissions, in this order: (1) Vector2 in method parameters and returns, signal payload fields, and property fields — DX-8's map positions and RL-4's contact events; (2) Packed_I64 result and query forms — DX-8's stable identifiers returned in batch results, mirroring the existing Packed_Float32 ownership shape (engine allocation, owned result, borrowed query); (3) String signal payload fields — the coarse completion/failure events RL-4, EX-VOXEL, and DX-8 need, lifting ADR 0050 decision 10's refusal with those consumers as the fixtures (borrowed for the emit, retained by no one); (4) nothing further — Color/transform/RID authored-member forms stay refused until a consumer establishes the need, and generated API access already covers them where that suffices. The implementation belongs to the next SDK reseat window; this paragraph is the agreement it generates against, and each admitted cell still records type, member position, direction, precision/range, nullability, owner, borrow duration, copying and release with its fixture evidence.

Agree the next consumers' signatures first, then implement a coherent matrix:

1. Common 2D values, starting with Vector2, in the method/configuration/event positions the adoption and logistics examples need.
2. Packed numeric query/results, starting with float and vector buffers and integer identifiers where the batch query uses them. Account for engine allocation/copying; result ownership is not an input callback borrow.
3. String event payloads for useful coarse completion/failure feedback.
4. Color/transform and engine resource/RID binding forms only where those consumers establish a concrete need. Preserve safe generated API access where an authored-member form is not needed; do not promise every built-in in every position.

For each admitted cell record type, member position, direction, precision/range, nullability, owner, borrow duration, copying and release. Property persistence, reload restoration and signal payload lifetimes need their own evidence. Rejected forms keep source-located diagnostics. Workers own snapshots, never engine borrows.

Done: the matrix, implementation, docs and actual consumers agree; tests exercise empty/large data, invalid inputs, mutation/detachment, callback exit, property save/reopen, signal delivery and cleanup. Pure algorithms still accept plain Odin records/slices. Flat GPU data remains a good representation for bulk hot loops.

DX-5 — A small existing-game adoption example

Owners: a new compact project under examples/, existing initializer/installed consumer harness, getting-started and example index. Requirements: BLD-DEV, NAT-DOC, NAT-INT.

Use the clock experiment, or an equally small scene, to teach one complete incremental adoption: start with a working Godot game, keep its scene/rendering and optimized GDScript baseline, move one substantial batch operation to a pure Odin package, and bind it through a small native class. A procedural source/bake asset path should retain its attribution and reproducible settings if imported from the clock. Do not require machine-local sibling folders or duplicate the whole six-implementation comparison inside this SDK.

DX-5 begins from store-shaped installation per the onboarding follow-up: the tutorial's first step is installing and enabling the add-on in an ordinarily opened editor, not a manual setup guide.

Show saved native settings, useful errors, one intentionally broken edit and repair, native editor reload, explicit game restart, public application tests and debug/release exports. Document file responsibilities and the remaining adapter cost. Reuse DX-1–DX-4 where their mechanisms fit; do not add artificial APIs to show every feature.

Done: an unrelated directory and immutable SDK reproduce the tutorial without private image variables, publication copying or contributor fixtures. Code samples are the actual runnable sources. The before/after comparison holds scene, algorithm, shaders and rendering constant and makes no unmeasured speedup claim.

DX-6 — Finish the already-planned examples

The original integration plan owns all detailed acceptance, ownership and responsiveness conditions. Implement its packages; existing worker, baking and demo receipts do not close these new behaviors.

Preserve bounded requests/results, latest-result publication, grid/collision consistency, safe physics-frame commit, and the original 128² playable preset. Retain large computational workloads in the Lab rather than creating a giant playable physics world. The original latency/frame budgets are acceptance targets, not existing measurements. Rewind's interleaving and determinism limits remain explicit; RL-6 is optional, and this plan does not promote it to required.

Done: each package has its original acceptance evidence and updated example README. The suite demonstrates results affecting ordinary Godot gameplay and authoring, not just a native benchmark with a display.

DX-7 — Maintain fair GDScript/native performance comparisons

Owners: Bunny/Boid/adoption baselines, existing eval harnesses and READMEs.

Bunny's canonical GDScript path uses sprites; Boid's uses per-instance transform updates. They are useful architecture comparisons but cannot alone isolate the benefit of Odin with the same rendering path. Preserve their lessons and add maintained optimized GDScript bulk baselines.

• Bunny should expose GDScript per-node, native per-node, GDScript bulk and native bulk with shared assets/settings. Boid and the adoption example need matched GDScript/native bulk arms with equivalent algorithms and data flow.
• Match population, seed, fixed step, algorithm, precision contract, buffer layout, shader/triangle work, culling, draw path and render settings. If Godot representation imposes a cost, count it rather than inventing a workaround on only one arm. Validate results against a stated exact or tolerance-based oracle.
• Keep kernel, language boundary, staging/submission, engine rendering and presentation waits separate. Count foreign calls, allocations and copied bytes. Recheck retained-storage constraints when adding diagnostic readback.
• Record actual framebuffer dimensions, renderer/backend, AA, VSync/FPS cap, window focus, engine executable, native profile, SDK/artifact, hardware and warm-up. Run repeated uncapped capacity tests and useful capped 60/120 Hz efficiency tests; report frame-time distributions, CPU and GPU data where available. Do not equate CPU process time with latency or infer energy from FPS.

Done: committed harnesses reproduce the maintained comparisons, correctness checks precede timing, and documentation distinguishes language/FFI gains from algorithm/rendering gains. Historical receipts remain historical; measure new arms before ranking them. No assumption that a larger game necessarily widens Gododin's advantage.

DX-8 — A compact logistics or tactical simulation

Owners: a new example and its pure subsystem, with existing tools/helpers.

Build one small complete loop: a Godot map with selectable workers, job sources and delivery destinations; Odin owns routing, job assignment, inventory and fixed simulation ticks. Godot owns map authoring, input, selection, UI, animation and presentation. Use explicit stable IDs, batches/snapshots and coarse events; avoid an engine call or signal per agent per tick.

Start single-threaded. Add cancellable background routing only if measured responsiveness warrants it, through existing ownership rules. A modest playable preset, pause/step/reset, saved settings and inspectable queues are enough. Include a GDScript oracle or matched small reference workload for algorithm correctness, not an arbitrarily weak performance strawman.

Done: native decisions visibly affect the Godot game, deterministic replay for the stated environment or a precise numerical contract is tested, queues/capacity and cleanup are bounded, and native editor reload plus exported play work. This demonstrates CPU-authoritative gameplay that cannot be replaced by merely moving the display transform to a shader; it introduces no reusable game framework.

DX-9 — Extend Slime with a CPU/GPU comparison

Owners: existing Slime example, Godot shader/RenderingDevice resources and its measurement harness. This is a separate increment after EX-SLIME. The older integration plan correctly excludes a GPU rewrite from its bounded mask lesson.

Add an explicitly selected GPU simulation variant alongside the native CPU variant. Share nutrient input, population, seed policy, step rate, grid size and presentation. Keep shader source in Godot's shader language/resources; Odin may own measured preparation or dispatch choreography without becoming a renderer.

State numerical/algorithm differences before comparing: parallel deposits, reduction order or races may change the model. Use a deterministic or tolerance-bounded validation workload with a defensible contract. If equivalence cannot be maintained, label the variant a different model and do not call its FPS a language speedup.

Measure simulation, upload, dispatch, presentation and any CPU query/readback. Show a GPU-resident visual mode and, if gameplay needs CPU results, its explicit readback cadence/cost. Keep that cost visible rather than timing only the asynchronous dispatch. Declare the renderer/capability requirement and handle unsupported configurations; qualify each claimed path with actual rendering.

Done: the example answers when CPU ownership is useful, when GPU residency wins, and what transfers cost, with inspected output and reproducible capped/uncapped measurements. It promises no cross-platform bitwise GPU determinism.

DX-10 — Close the integrated product and documentation loop

Owners: current release, installed-consumer, editor/render/export fixtures, standing docs/skills and the qualification audit.

• Publish coherent immutable SDKs at the consumer milestones using current release tooling. Qualify affected installed workflows and matching exports under C1–C5; do not create a second gate system or repack for every small edit.
• Verify the store deliverable with its selected SDK per the onboarding follow-up: the exact add-on ZIP exercised through a clean editor, listing material and disclosures prepared from the implemented artifact, and actual submission/acceptance recorded as separate events.
• Keep the short user path, CLI help, Native PRD admission table, helper lifetime reference, example READMEs, API design and the Gododin skills aligned with implemented behavior. Add runnable snippet coverage where it prevents actual consumer drift; do not mirror prose in low-value tests.
• Execute the compact usage documentation plan for the public guide, consolidating overlapping instructions as each chapter is written. That plan owns chapter structure and explanatory diagram work; this package retains publication and qualification ownership.
• Repeat the DX-5 installation-to-export journey from a clean consumer directory and report the DevX observations defined above. Remove remaining avoidable setup/administrative code at its proper owner; do not declare success merely because a maintainer who knows the private artifacts can make the demo run.
• Link evidence from this ledger and the old plans. Close completed packages individually; retain precise real-host residuals under the desktop plan. Native, editor, reload, renderer, installed SDK and export qualifications are separate. C5 still requires clean-machine release evidence.
• Preserve historical measurements and actual artifact provenance. New source, renderer or SDK identity needs the applicable fresh proof; a lock reseat is not itself a rerun of every old measurement.

Full completion requires DX-0–DX-9 delivered with their named evidence, standing docs and installed consumer experience consistent, and all required qualification gates passed. “Locally complete with platform work remaining” is an honest interim status, not full plan/product completion; list each open gate explicitly. The final report must list measured gains and limits, commands run, publication identity, remaining host-specific work and where to resume.

Documentation reconciliation delivered with this plan

The 2026-09-26 documentation pass corrects stale claims about deferred editor reload, pending dev6 integration, completed phase coverage and the example count. It distinguishes generated engine API coverage from authored value admission, and pure worker ownership from callback authority. The original efficiency, example and Rewind plans keep their requirements and historical observations; their current status and next-session routing point here.

These changes provide no new runtime, performance or support evidence. The next implementation session must establish its own current baseline and update this ledger as each work package actually closes.