# Prototype foundation setup **AI rebuild branch, 13 October 2026:** `codex/enemy-ai-rebuild` is a teardown checkpoint. Enemies are passive damageable entities; old pack, weighted-positioning, cover-grace and specialist attack workflows are retired. Do not run historical AI acceptance launchers or treat previous AI passes as proof for this branch. See the [removal record](superpowers/plans/2026-10-13-enemy-ai-removal.md) for current verification and limits. Preserve manual terrain and navigation. For task orientation, start with [the current brief](PROJECT_PLAN.md) and [AGENTS.md](../AGENTS.md). Use [the agent workflow](AGENT_WORKFLOW.md) for design experiments, risk/review selection and prototype promotion; this document owns Editor/session/build setup and [TESTING.md](TESTING.md) owns exact verification. Consult [historical decisions/evidence](PROJECT_HISTORY.md) only when relevant. ## Project and tools Open `E:\IndieGameProject\ProjectI` in Unity **6000.6.4f1**. Do not accept an automatic Editor/package upgrade. The project uses the template's PC URP quality profile and the package versions pinned in `Packages/manifest.json` / `packages-lock.json`. The connected Unity MCP Editor tools were verified for this project. Unity CLI1.0.0-beta.12 is now available on PATH; the Editor menus below remain supported. When several Editors are open, explicitly target `--project-path E:\IndieGameProject\ProjectI` and confirm the project/version/play state before changes. Git and Git LFS are installed; the local repository uses `prototype-foundation`. For a connected Editor, `unity status --format json --non-interactive` lists active projects. `unity command eval '' --project-path 'E:\IndieGameProject\ProjectI' --format json --non-interactive` runs supported Editor APIs. Use statement blocks without using directives. For long builds, eval's second positional argument is its timeout in milliseconds; for example `unity command eval 'ProjectI.Editor.PrototypeFoundationBuilder.BuildWindows(); return "Built";' 120000 --timeout 150 --project-path 'E:\IndieGameProject\ProjectI' --format json --non-interactive`. Verify the returned result and fresh `Builds/Prototype/build-result.txt`. Do not edit scene/prefab/data YAML directly. Package roles: URP renders the arena; Input System reads keyboard/mouse; Test Framework runs rule tests; NGO replicates players/run state; Transport supplies networking; Multiplayer Services composes anonymous authentication and private online connections. Multiplayer Center/Quickstart, Play Mode, and Tools support setup/testing. Existing AI Assistant/Inference, Pipeline, IDE integrations, Version Control, Timeline, uGUI, Visual Scripting, and built-in modules were retained; the foundation does not introduce gameplay dependence on those optional template/editor facilities. ## Open, regenerate, test, build Choose checks with [the testing procedure](TESTING.md) and [complete fixture/harness catalogue](TEST_CATALOGUE.md). Full runner calls retain full-assembly meaning; focused requests and immutable evidence are documented there. Prose-only edits need no Unity run. Current normal gameplay entry is MainMenu into manually authored Verdant Relay; the arena steps below are a deliberate legacy fixture workflow. Preserve authored layout before any rebuild/bake. 1. Let package resolution and compilation finish; inspect the Console for errors. 2. Open `Assets/_Project/Scenes/PrototypeArena.unity`. 3. For the existing combat scene, use **ProjectI > Combat > Add or update combat sandbox** to add missing setup while preserving layout/tuning. **ProjectI > Foundation > Create or rebuild arena** replaces the generated arena layout/prefab; preserve manual changes before using it and reapply combat setup afterward. The original sample scene remains available. 4. Run `ProjectI.Foundation.EditModeTests` in **Window > General > Test Runner > EditMode**. `FoundationTestRunner.RunEditMode(label)` also exports reports to `TestResults/` through the Editor API. 5. Choose **ProjectI > Foundation > Build Windows prototype**. The development build goes to `Builds/Prototype/ProjectI.exe`, and the build summary to `Builds/Prototype/build-result.txt`. 6. Launch that executable. To share it, copy the **entire** `Builds/Prototype` folder, including its data directory and DLLs. The executable alone is insufficient. Builds and test results are ignored by Git. The baseline sample-scene build is retained under `Builds/Baseline/`. Template packages produce shader/build warnings; verify actual build success and errors in the report instead of treating warning count as success/failure. ## Online prerequisites and spending The project is already linked to a Unity cloud project. Anonymous authentication and online multiplayer connectivity must be enabled for that project. The user confirmed free-tier operation with no paid billing. Do not add a payment method or enable a paid plan to bypass a service error. See `NETWORKING_DECISION.md` for dependencies, current limits, and source links. If hosting fails, read the menu error and the player log. Check internet connectivity, project linking, service setup, free-tier limits, and that every participant uses the same build. A failed operation should return to the menu and allow retry. If cloud cleanup failed during an outage, reconnecting retries that cleanup before creating another game. ## Controls and session flow - **Host a private game** creates a game and displays a join code; **Copy join code** copies it. - A friend enters that code and chooses **Join a friend**. Four total players includes the host. - **Explore arena** captures the mouse. **WASD** moves, mouse aims, **Shift** sprints, **Space** jumps, and **Escape** toggles the menu/cursor. - Players may practice combat and select builds before the run starts. The host chooses **Start run and close joining** to stop new admissions and lock builds. See [combat controls and tuning](COMBAT_SETUP.md) and [combat validation](COMBAT_VALIDATION.md). - **Leave game** returns to the menu and removes that player's object. If the host leaves or its connection is lost, other players return to the menu; there is no host migration. ## Separate-network acceptance test Use the current build on two PCs on different internet connections. For the four-player pass, use four independently controlled players, with at least one client outside the host's network. Record observations in `PROTOTYPE_VALIDATION.md`. 1. PC A hosts; PC B joins using the displayed code. Verify both show **2/4 players**. 2. Both choose Explore arena. Move/look independently, sprint/jump, collide with the floor/obstacles/boundaries, and watch the other player move. Each player's camera must remain independent. 3. PC B leaves. Verify it returns to the menu and its body disappears on A. Rejoin and verify a distinct spawn. 4. Repeat with four players; verify all four see the same roster and the other three bodies, with separate starting positions. 5. Have the host start the run. Have a client leave and try rejoining; joining must be rejected **despite a free slot**. 6. End/recreate the game, then test host leave and an abrupt host application exit. Remaining clients must return to menu after connection loss detection and be able to host/join a fresh game. 7. Try an incorrect code, then a valid code. Verify an understandable error and a successful retry. 8. Join, leave, then host on the same application instance. Also have the other host leave normally, then host immediately on the surviving client and invite another player. Repeat after a kick/disconnect and after leaving a started run. Use the latest build on all peers. 9. Report player count, which PCs used separate networks, the build used, and any input/collision/jitter/disconnect problems. A local multi-process test does not replace these checks. ## Developer integration checks From PowerShell at the project root: ```powershell & .\Tools\Test-Foundation.ps1 # Focused leave/kick/remote-host-deletion rehost regression: & .\Tools\Test-Foundation.ps1 -LifecycleRegressionOnly ``` This explicitly launches hidden headless development players through the real online service, each with a distinct anonymous authentication profile. It checks connection/replication, four-player capacity, ownership/camera/listener counts, movement replication, leave/despawn/spawn reuse, closed admission with a free slot, host loss, and retries. It records reports and logs in a unique `TestResults/foundation-*` directory and stops only its own launched processes. These are automated built-player integration checks, not human control/feel or separate-network validation. Diagnostic `--probe-*` / `--auto-*` actions run only in Editor/development builds and only when explicitly requested on the command line. ## Verdant Relay first-stage iteration Open `Assets/_Project/Scenes/MainMenu.unity` for the normal ready/loadout flow; starting a run loads Verdant Relay. The saved `VerdantRelay.unity` scene is the user-authored first stage, and the Windows development executable is `Builds/Prototype/ProjectI.exe`. Legacy arena scenes remain direct development fixtures and later-stage fallbacks. **ProjectI > Levels > Configure hand-authored Verdant infrastructure** repairs setup-owned bindings and bakes navigation against the actual manual terrain. It preserves meshes, colliders, materials, lighting and ProBuilder authoring. Review and save the scene afterward; future terrain edits require another bake and validation. The current Verdant Normal navigation uses an Editor-only map-specific profile at `Assets/_Project/Editor/NavigationProfiles/Verdant Normal.asset`: built climb.25m, voxel.05m and height detail, while the global Normal climb remains.75m. After deliberate terrain edits, use **ProjectI > Levels > Rebuild Verdant Normal navigation profile** for this surface, then rerun affected movement/admission checks. Builds validate saved data and geometry; they never rebake. A standard Normal surface/infrastructure bake uses the global climb and invalidates this profile. Preserve the saved Large and dedicated Splinter Child surfaces/data unless their separate changes are deliberately in scope. `Tools/Test-EncounterPolish.ps1 -VerdantInitial -DelayMs 75 -JitterMs 15 -LossPercent 1` exercises the new first-stage full-run fixture. Without `-VerdantInitial`, that script retains its legacy entry. Use current reports in `TestResults` and the Pack AI implementation ledger for build identity and remaining acceptance.