#setup

The build order for a fresh s&box project a coding agent can actually work in without corrupting itself on day one — skeleton, globals, compile gate, and the ownership discipline that keeps parallel agents from clobbering each other.

global using Sandbox + your razor namespace in Assembly.cs — without it, panels and game types don't resolve across the assembly.

Folders → sbproj → Assembly.cs → 4-object scene → green dotnet build → tagged logs on Play — then optional art tools.

.sbproj + Assets/Code/ProjectSettings/tools layout, 4-object scene + Bootstrap, dotnet build before anything else.

WASD as Forward/Backward/Left/Right feeds AnalogMove; new Input.config actions need an editor restart — dotnet build is not enough.

Standalone export hangs if PackageReferences still need sbox.game to resolve — don't accumulate cloud package deps casually.

Scene holds four GameObjects; Bootstrap OnStart builds the world in code — hotloads better, no scene/code drift.

Ident is org.package — two lowercase segments; keep Org local until real; never put TODO placeholders in Org or the editor won't boot.

Assets / Code / Editor / ProjectSettings / tools — the template every project follows.

If sbox-launcher.exe stays open during a Steam update, files vanish mid-install — validate via steam://validate/590830.

StartupScene is what Play loads; Org must be a valid lowercase ident — placeholders break editor bootstrap, not just publishing.

C# hotloads on alt-tab in ms; scene changes and new Input.config actions need Play/editor restart; failed compile keeps the last-good assembly.