First pass at full refactor to 2.0 design

Restructures the game around the cyclical run loop from Game Design Doc V2:
5 waves = a cycle, 3 cycles = a phase, each phase ends in a boss.

- New TD.Gameplay.Waves: WaveGroup / PhaseDefinition / RunDefinition author the
  run as draggable weighted pools; RunState owns phase/cycle position, the drawn
  wave slots, and the per-slot enemy buff sets. WaveManager's flat wave array is
  gone -- it now only runs the encounter RunState points at.
- New TD.Gameplay.EnemyUpgrades: the post-wave enemy-buff vote, with public
  live-replicated ballots so the HUD can show who voted for what.
- Inter-wave flow is now strictly sequential: draft -> vote -> build, each stage
  ending early once every player has acted.
- Enemy abilities inverted from per-instance random rolls to deterministic,
  stacking per-wave-slot sets. Six cards ship: Split (reworked), Flight, Blink,
  No Bounty, Gold Theft, Double Up.
- Tower upgrades are a two-step tree: a draft pick unlocks a node, gold converts
  an already-placed tower in place.
- Boss encounters flag their enemies and drive a boss HP bar.
- Player cap reduced to 3 via MatchRules.MaxPlayers.
- GoldConfig is now keyed by global encounter number rather than wave index.

Compiles clean; NOT yet verified in-engine. Editor wiring still required --
see Docs/2.0_Setup_Checklist.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assets/_Project/Scripts/Core/EnemyAbilityKind.cs

@@ -8,9 +8,22 @@ namespace TD.Core
     /// </summary>
     public enum EnemyAbilityKind : byte
     {
-        /// <summary>No ability rolled. Never a real pool entry — only the sentinel value
-        /// <see cref="TD.Gameplay.EnemyAbility"/> reports before/absent a roll.</summary>
+        /// <summary>Sentinel for "no ability". Never a real pool entry.</summary>
         None = 0,
+
+        /// <summary>Dies into several smaller, faster copies of itself.</summary>
         SplitOnDeath = 1,
+
+        /// <summary>Grounded enemies take to the air, ignoring the maze entirely.</summary>
+        Flight = 2,
+
+        /// <summary>Teleports a short distance further along its path on a timer.</summary>
+        Blink = 3,
+
+        /// <summary>Grants no kill bounty.</summary>
+        NoBounty = 4,
+
+        /// <summary>Steals gold from the player whose zone it escaped, on top of the life cost.</summary>
+        GoldTheft = 5,
     }
 }

Assets/_Project/Scripts/Core/Enums.cs

@@ -68,8 +68,12 @@ namespace TD.Core
     /// </summary>
     /// <remarks>
     /// <c>None</c> is a sentinel value used in <c>OwnerGrid</c> to mark tiles not owned by any player zone.
-    /// Player1..Player9 cover the maximum supported player count. Maps using fewer players use a
-    /// contiguous prefix (e.g., a 3-player map uses Player1, Player2, Player3 only).
+    /// Maps use a contiguous prefix of the player values.
+    ///
+    /// <para><b>The enum runs to 9, but only <see cref="MatchRules.MaxPlayers"/> slots are ever
+    /// allocated.</b> Lobbies capped at 3 for the 2.0 design; the surplus values are kept because
+    /// they are baked into existing <c>LevelData</c> owner grids, and renumbering the enum would
+    /// force a re-bake of every map to no runtime benefit.</para>
     /// </remarks>
     /// <summary>
     /// Global phase of a match, driven by <c>MatchState</c>.
@@ -92,6 +96,28 @@ namespace TD.Core
         Defeat = 4,
     }
 
+    /// <summary>
+    /// Which step of the between-encounters sequence is currently running. Replicated by
+    /// <c>WaveManager</c> so every HUD can label the shared countdown correctly.
+    /// </summary>
+    /// <remarks>
+    /// These run strictly in order and never overlap: players take their personal draft, then vote
+    /// on the buff for the wave they just cleared, then build. The build timer deliberately does
+    /// NOT run concurrently with the choices — "after all players have chosen" only means
+    /// something if it isn't racing a clock players also want to spend on their maze.
+    /// </remarks>
+    public enum InterWaveStage : byte
+    {
+        /// <summary>No inter-wave step running — a wave is spawning or being fought.</summary>
+        None = 0,
+        /// <summary>Players are picking their personal draft reward.</summary>
+        Draft = 1,
+        /// <summary>Players are voting on the buff for the wave they just cleared.</summary>
+        Vote = 2,
+        /// <summary>Build countdown before the next wave spawns.</summary>
+        Build = 3,
+    }
+
     /// <summary>
     /// Stable identifier per race. Values 1-16 reserve slots for the planned
     /// 16-race grid in the lobby; only races with a corresponding

Assets/_Project/Scripts/Core/MatchRules.cs

@@ -0,0 +1,26 @@
+// Assets/_Project/Scripts/Core/MatchRules.cs
+namespace TD.Core
+{
+    /// <summary>
+    /// Match-wide constants that several unrelated systems have to agree on.
+    /// </summary>
+    public static class MatchRules
+    {
+        /// <summary>
+        /// Maximum players in one lobby.
+        /// </summary>
+        /// <remarks>
+        /// <b>Reduced from 9 to 3 for the 2.0 design</b> as a deliberate scope cut: three players
+        /// is enough for the shared-lives and shared-vote mechanics to matter, and it shrinks map
+        /// authoring, balance surface, and network load all at once.
+        ///
+        /// <para><b>Why <see cref="PlayerSlot"/> still runs to 9.</b> Shrinking the enum would
+        /// invalidate the owner grids baked into existing <c>LevelData</c> assets and force a
+        /// re-bake of every map, for no runtime benefit — the extra values are simply never
+        /// allocated. Slot allocation caps here instead, which is the only place that decides who
+        /// gets a slot at all. Per-slot arrays stay sized to the enum, so they hold a few unused
+        /// entries; that is intentional and costs nothing.</para>
+        /// </remarks>
+        public const int MaxPlayers = 3;
+    }
+}

Assets/_Project/Scripts/Core/MatchRules.cs.meta

@@ -0,0 +1,2 @@
+fileFormatVersion: 2
+guid: ac169573e8a2fd046a3ebac7d2e03c8c

Assets/_Project/Scripts/Core/PoolWeightAttribute.cs

@@ -0,0 +1,35 @@
+// Assets/_Project/Scripts/Core/PoolWeightAttribute.cs
+using UnityEngine;
+
+namespace TD.Core
+{
+    /// <summary>
+    /// Marks a float field as a 0–1 <b>relative</b> draw weight inside an authored pool. The
+    /// inspector renders it as a slider and, when the value is zero, shows a warning directly
+    /// beneath explaining that the entry can never be drawn.
+    /// </summary>
+    /// <remarks>
+    /// <b>Relative, not absolute.</b> Weights are normalized against the summed weight of the
+    /// candidate set at draw time, so entries at equal weight are equally likely and an entry at
+    /// 0.5 is half as likely as one at 1.0. This is why every weight field defaults to 1 —
+    /// adding an entry to a pool then never silently re-weights the entries already in it.
+    ///
+    /// <para><b>The warning is advisory.</b> Muting an entry while tuning is a legitimate
+    /// workflow, so the drawer never clamps the value or blocks the edit. It exists because a
+    /// zero-weight entry is otherwise indistinguishable, in play, from one that simply hasn't come
+    /// up yet — the failure is silent, so the authoring surface has to be loud.</para>
+    /// </remarks>
+    public class PoolWeightAttribute : PropertyAttribute
+    {
+        /// <summary>
+        /// Noun used in the zero-weight warning ("this <c>wave</c> can never be drawn"). Keep it
+        /// singular and lowercase.
+        /// </summary>
+        public readonly string Noun;
+
+        public PoolWeightAttribute(string noun = "entry")
+        {
+            Noun = string.IsNullOrWhiteSpace(noun) ? "entry" : noun;
+        }
+    }
+}

Assets/_Project/Scripts/Core/PoolWeightAttribute.cs.meta

@@ -0,0 +1,2 @@
+fileFormatVersion: 2
+guid: e171856d7a8fe194f97091853672c19d