Adoption journey record — store add-on to first native build

Recorded 2026-09-26 on the macOS recording host (Apple silicon, macOS 26, Godot 4.8.dev6.official.8898c2b3d, SDK gododin-devx-2026-09-26.1). This is the acceptance record the onboarding findings ask for: the commands run, the manually edited files, the setup steps, and the first-success experience — with the friction against the gdext/Rust Tools ambition named explicitly rather than papered over.

Steps that were executed

1. Pack the store ZIP from maintained source

   sh

   tools/release/pack_store_zip.sh --project-root <gododin-checkout> \
     --release-from-lock --out /tmp/store-pack/gododin-editor-addon.zip
   # GODODIN_STORE_ADDON_INVENTORY_VERIFIED files=5
   # GODODIN_STORE_ZIP_PACKED release=gododin-devx-2026-09-26.1 bytes=15253
   #   sha256=9649c926f9bec81152893481f8ba904d80be47176553ed24f7a1f6b08f0cdfc5

   Two consecutive packs are byte-identical (cmp).

2. Install into a clean ordinary Godot project. Unzip; addons/gododin/ lands where the engine expects it. Enable Project Settings → Plugins → Gododin Build and Recovery. (In the automated verification this enabling was recorded the same way the editor records it — the additive editor_plugins/enabled project setting — and the file inventory was compared before/after to prove nothing else in the project changed.)

3. Open the editor ordinarily — no Gododin launcher environment, no --headless, no CLI child:

   sh

   /absolute/Godot_4.8-dev6.app/Contents/MacOS/Godot --path /absolute/clean_project

   Observed in the session log: GODODIN_SETUP_DOCK_READY release=gododin-devx-2026-09-26.1, no script errors. The Gododin dock shows its release, an SDK executable field with a file picker, and Connect/Check actions. --headless, --import, --export, and --quit-style sessions stay fully inert (verified separately: the dock is never created there, so build/export subprocesses never become interactive sessions).

4. Connect and validate run on public CLI paths — click-verified. The dock's Connect invokes <sdk>/bin/gododin init --project-root <root> --project-key <key>; Check invokes <sdk>/bin/gododin sdk validate --project-lock <lock> --sdk-root <sdk> and reports add-on/SDK release mismatch explicitly. The setup dock gate (repository: fixtures/setup_dock/README.md) presses these real buttons inside a live ordinary editor (GODODIN_SETUP_DOCK_PASS connect=1 repeat_guard=1 validate=1), and its first run caught two real add-on defects that shell-level checks could never see: the dock passed ProjectSettings.globalize_path("res://") with its trailing slash, which the CLI's canonical-root admission refuses, so Connect could never succeed; and the check flow parsed the SDK release from captured child stdout, which OS.execute does not reliably return on this engine/host. Both are fixed: every CLI invocation uses the trimmed canonical root, and the dock reads the SDK release and the lock-mismatch relation from the SDK's own files instead of parsed stdout.

5. First native build and the ordinary loop (CLI-first journey, unchanged by the store path):

   sh

   <sdk>/bin/gododin build  --project-root <root> --profile debug
   <sdk>/bin/gododin editor --project-root <root>      # live reload session
   <sdk>/bin/gododin run    --project-root <root> --headless \
       --env MY_GAME_SEED=7 -- --players 2 --demo
   # GODODIN_RUN_IDENTITY engine_target=4.8.0 engine_sha256=… native_profile=debug
   #   build_id=… source_revision=… publication=… sdk_release=gododin-devx-2026-09-26.1
   # GAME_SEED=7   GAME_USER_ARGS=["--players", "2", "--demo"]
   # GODODIN_RUN_PASS target=4.8.0 build_id=… owners=0

   The launcher matrix verified this release: --scene/--script selection, script exit status propagated as the CLI's own (exit 7 observed), --quit-after bounding a non-quitting MainLoop, --profile release, --last-known-good with its profile-mismatch refusal, and the reserved-name --env refusals. Debug and release exports remain the SDK's gododin export path with their existing evidence.

Manual steps a consumer performs

1. Install the add-on from the store (one click in the engine's AssetLib / store browser, or unzip into the project).
2. Enable it in Project Settings → Plugins.
3. Install a Gododin SDK release once (external download with a checksum; the add-on never downloads anything).
4. Select the SDK's bin/gododin in the dock; Connect; reopen through gododin editor for the live build/reload workflow.

Everything after step 4 is the same CLI-first journey an SDK-first user has, which is deliberate: the store path and the documented getting-started path converge on one adoption flow and one ownership model (addons/gododin is owned by the same inventory in both channels).

Friction against the stated ambition (honest list)

• A separate SDK download remains the biggest step. gdext leans on Cargo: cargo add godot has no installer at all. Gododin needs an immutable SDK (compiler included) installed and selected. Mitigation, not parity: one checksum-verified download, explicit selection, validation with actionable mismatch reporting — but it is still a second artifact a Rust user does not need.
• The engine pin is a dev snapshot. Gododin targets exactly 4.8-dev6; a consumer on Godot 4.x stable cannot adopt this entry today. gdext tracks stable releases. Until the target advances to a stable, this alone makes the journeys non-comparable for most consumers.
• The dock's relocation/upgrade recovery is guidance, not buttons. Connect, repeated-connect guarding, and Check connection are click-verified in a live editor (the setup dock gate), and gododin attach re-links a moved SDK while gododin attach --adopt-lock adopts a new same-engine SDK release (previous lock preserved under .gododin/previous-lock.toml, engine-target changes refused); the Check-connection message names these commands when it meets a mismatch. The dock itself offers no dedicated relocate/upgrade button yet.
• Single qualified host. macOS arm64 only, this release. Windows/Linux are active main-line targets but make no listing claim until their gates pass.
• What does reach parity or better, with evidence rather than buttons: the ownership contract (identical inventory across store and CLI channels, so store-install then SDK-upgrade cannot conflict), inert-by-default editor sessions, untouched adoption of existing games, and the launcher's identity report and exit-status contract for application tests.