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

A freshly-scaffolded project's Assembly.cs can be missing global using System. Transplanted code using Math/MathF fails with CS0103.

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.