# 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](../plans/2026-09-26-asset-store-onboarding.md) 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 \ --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 `/bin/gododin init --project-root --project-key `; Check invokes `/bin/gododin sdk validate --project-lock --sdk-root ` and reports add-on/SDK release mismatch explicitly. The [setup dock gate](../../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 /bin/gododin build --project-root --profile debug /bin/gododin editor --project-root # live reload session /bin/gododin run --project-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.