give the runtime code assemblies, a build entry point, and fix two names

No project code is in Assembly-CSharp any more. Five assemblies: Core (no
dependencies), Locomotion.Math, Skills, Game (everything else under Scripts),
and StarterAssets.

Game is one assembly rather than one per area, which is what the plan assumed.
Measuring the dependency graph first found three cycles, all through UI —
CharacterPanelView reaches into Dialogue, PlayerControlLock into Player, and
UILayerBootstrap into Cinematics — plus two edges a using-scan cannot see,
because NPCStandIn is in the global namespace. Assemblies cannot be circular, so
splitting further means relocating those three files. That is a code-movement
task, not an asmdef task, and nothing needs it yet.

StarterAssets had to get an assembly of its own. It had none, so it lived in
Assembly-CSharp, and an asmdef assembly cannot reference the predefined
assemblies — four runtime files use it, and all four would have stopped
compiling.

The payoff is immediate: BootstrapTests no longer needs reflection to reach
NPCStandIn and CinemachineFollowsPlayer, which is exactly why Phase 3 wanted
this.

Assets/Editor/PlayerBuild.cs is the headless build entry point. It reads the
enabled scenes, asserts Bootstrap is scene 0 because the player opens scene 0 on
launch, honours the -buildOutput the CLI forwards from -o, and calls
EditorApplication.Exit(1) on anything short of Succeeded — without which Unity
exits 0 on a build that produced nothing and CI goes green on it. Verified end to
end: a 172MB .app in about two minutes.

Two renames, both different from what the plan described. DialougueSkillComparison.cs
contains a class called SkillFunctions — the filename never matched the type, so
it is now SkillFunctions.cs. The two .yarn files with spaces in their names lost
the spaces rather than becoming kebab-case, which would have made them
inconsistent with Bartender.yarn and SC101.yarn; spaces were the actual problem.
Both renames preserved their .meta GUIDs, and the yarnproject graph keys and the
two character sheets were updated.

EditMode 42/42, PlayMode 5/5, YarnCheck 9 files / 35 nodes, make build green.

Co-Authored-By: Claude Opus 5 <[email protected]>

CLAUDE.md

@@ -166,11 +166,21 @@ the legacy desktop player flags — and builds whatever scenes `EditorBuildSetti
 `--profile <name>` selects a profile from `Assets/Settings/Build Profiles` (the profile defines
 the target). `-l/--log-file` overrides the log path; the log streams to console unless `--no-tail`.
 
-**No build script exists yet.** When one is added, put it at `Assets/Editor/BuildPipeline.cs` and
-call `--execute-method NightclubArcadia.Editor.BuildPipeline.BuildMacOS`. The CLI forwards the
-output path as `-buildOutput` and **your method is responsible for honouring it**. A build method
-must call `EditorApplication.Exit(1)` on failure, or Unity exits 0 and CI reports a green build
-that produced nothing.
+`make build` uses the entry point below, which is the form to prefer:
+
+```bash
+"$UNITY_CLI" build "$UNITY_PROJECT" --no-banner --target StandaloneOSX \
+  --execute-method NightclubArcadia.EditorTools.PlayerBuild.BuildMacOS \
+  -o "$PWD/build/NightclubArcadia.app"
+```
+
+`Assets/Editor/PlayerBuild.cs` reads the enabled scenes from the build settings, asserts
+`Bootstrap.unity` is scene 0 (the player opens scene 0 on launch), honours the `-buildOutput`
+the CLI forwards from `-o`, inspects the `BuildReport`, and calls `EditorApplication.Exit(1)` on
+anything short of `Succeeded`. Without that last part Unity exits 0 on a build that produced
+nothing and CI reports green. `BuildWindows` and `BuildLinux` are there too.
+
+Verified: a full macOS build takes about two minutes and produces a ~172MB `.app`.
 
 ### 3.4 Run an arbitrary Editor method
 
@@ -377,11 +387,6 @@ It is a tripwire, not a proof.
 `Assets/Tests/PlayMode/BootstrapTests.cs`. Verifies the scene split at runtime — the thing no
 EditMode test can see, because none of the runtime resolution has happened yet.
 
-Two of its checks reach their types by name through reflection. `NPCStandIn` and
-`NightclubArcadia.Cinematics` live in `Assembly-CSharp`, and an asmdef test assembly cannot
-reference the predefined assemblies — only the reverse. Giving the runtime code its own asmdefs
-removes the need; until then the reflection is confined to those two tests.
-
 ### 5.3 Voice-sheet sync
 
 ```bash
@@ -432,9 +437,20 @@ should not be — see `docs/restructure-plan.md`.
   `UI.HUD`, `UI.Menu`, `Cinematics`, `Interaction`, `Player`, `Player.Math`.
   **Exception:** `NPCStandIn.cs` sits in the global namespace. That is a scaffold tell, not a
   convention to copy — new runtime types always get a namespace.
-- Assembly definitions exist for `NightclubArcadia.Skills` and `NightclubArcadia.Locomotion.Math`
-  only. Camera, Player, UI, Dialogue, NPCs and Interaction all currently compile into the
-  default `Assembly-CSharp`. Widening asmdef coverage is planned, not done.
+- **Assemblies.** No project code is in `Assembly-CSharp` any more:
+
+  | Assembly | Covers | Depends on |
+  |---|---|---|
+  | `NightclubArcadia.Core` | `Scripts/Core` | nothing |
+  | `NightclubArcadia.Locomotion.Math` | `Scripts/Player/Math` | nothing |
+  | `NightclubArcadia.Skills` | `Scripts/Skills` | Yarn, TMP, uGUI |
+  | `NightclubArcadia.Game` | the rest of `Scripts` | Core, Skills, Math, StarterAssets, packages |
+  | `StarterAssets` | vendored template code | Input System |
+
+  `Game` is one assembly rather than one per area because the areas are genuinely cyclic:
+  UI ↔ Dialogue, UI ↔ Player and UI ↔ Camera, via `UILayerBootstrap`, `PlayerControlLock` and
+  `CharacterPanelView`. Splitting further means moving those three, not just adding asmdefs.
+  The `.asmdef` at `Scripts/` covers everything beneath it except folders with their own.
 - Comments in this codebase carry *decision history* — why a flag is written at the bottom of a
   node rather than the top, why four voices in SC-101 breaks the three-voice cap on purpose.
   Match that density. Do not strip such comments as "noise"; they are the design record.
@@ -465,9 +481,10 @@ should not be — see `docs/restructure-plan.md`.
    mesh. `ResetPath`, `isStopped` and `SetDestination` all log errors in that state. Guard on
    `agent.isOnNavMesh`, not just a null check.
 
-4. **An asmdef assembly cannot reference `Assembly-CSharp`.** Only the reverse. Most runtime code
-   here has no asmdef, so a test assembly cannot see `NPCStandIn` or `NightclubArcadia.Cinematics`
-   directly — hence the reflection in `BootstrapTests`. Adding per-area asmdefs removes this.
+4. **An asmdef assembly cannot reference `Assembly-CSharp`.** Only the reverse. This is why
+   giving the runtime code assemblies had to include `StarterAssets`, which had none and which
+   four runtime files use — without that, everything referencing it would have stopped compiling.
+   Keep it in mind before adding loose scripts outside an asmdef folder.
 
 5. **`unity run` reserves `-batchmode`, `-nographics`, `-quit`, `-logFile`.** Passing any of them
    after `--` is a hard error, and its output does not reach stdout — read `Logs/Editor.log` (§3.4).