Stage 4: upgrades, and a quartermaster to spend them at

Every level banks one choice. Choices queue, and are spent at an NPC in the
hub: walk to it, press E, take one of three weighted options. Seven upgrades,
all data — split shot, glass cannon, spread, sniper, doubleshot, poison,
eraser — and SimWorld gained no per-upgrade branch to run any of them.

The four ambiguities in the brief were settled with the user first, since
each changes what gets written:

  damage      base x (1 + sum additive) x product multiplicative. The flat
              +5% every upgrade carries, spread's -10%, doubleshot's -50%
              and glass cannon's +100% pool; sniper multiplies on top, so
              two snipers is 4x and not +200%.
  glass       half the LEVELLED maximum, multiplying if taken twice, so the
              price does not fade to a rounding error by level 15.
  poison      independent stacks, not a refresh.
  split       +/-45 degrees from the original heading.

Independent poison stacks sound expensive and are not: every dose lasts the
same number of ticks, so doses expire in the order they were added, the
pending expiries are a plain FIFO, and PoisonTrack only ever looks at its
front. O(1) per actor per tick however many are live.

Stats are derived from the upgrade list and never stored, the way level is
derived from experience -- a saved stat cannot disagree with the upgrades
that produced it. Upgrade riders (split charges, poison, erase chance) travel
on the bullet instead, because a shot in flight has to keep what it was fired
with rather than gaining Poison because the shooter just took it.

Two invariants this collided with, both now pinned:

  - bullet speed gained a ceiling. Wall collision samples once per tick, so
    anything over a tile per tick tunnels; two snipers asked for 2480 u/s
    against a 1920 threshold, and a tunnelling bullet looks like a bullet.
  - BULLET_INTEREST_RADIUS rose to 2900, because an upgraded player shot is
    now the longest-travelling bullet in the game. test_interest measured
    the worst case from static content, which upgrades quietly invalidated.

Choosing is intent checked three ways: a choice must be owed, the index must
name one of the three options the SERVER put on the table, and the player
must be standing at the NPC. The offer is rolled once and persisted, so
closing the screen is not a reroll and neither is a crash.

tools/diag_upgrades.tscn covers level -> banked choice -> refused in a
dungeon and refused across the room -> taken at the NPC -> new stats ->
on disk. Bots never walk to the quartermaster, so the smoke test cannot.

Known gap recorded in the roadmap: at PLAYER_BULLET_DAMAGE = 6, the +5% the
first upgrade carries rounds back to 6 and visibly does nothing. It comes out
right in aggregate, but the fix is a balance edit across content.gd and so is
the user's call.

check.sh clean, 357 tests, SMOKE PASS (18 assertions), all four diagnostics
green.

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

CLAUDE.md

@@ -26,13 +26,15 @@ non-zero on failure, so they gate like tests:
 godot --headless --path . res://tools/diag_prediction.tscn    # prediction gap; injects clock drift
 godot --headless --path . res://tools/diag_progression.tscn   # kill -> xp -> level -> death -> roster
 godot --headless --path . res://tools/diag_loot.tscn          # drop -> pick up -> persist -> use -> drop
+godot --headless --path . res://tools/diag_upgrades.tscn      # level -> choice -> taken at the NPC -> new stats
 godot --headless --path . --script tools/bench.gd             # sim cost per tick
 python3 tools/build_local_assets.py                           # rebuild the local-only bullet atlas
 ```
 
-`diag_progression` and `diag_loot` exist because the bot smoke test cannot cover
-either: bots are poor shots, so they rarely kill anything, which means they
-neither earn levels nor produce drops.
+`diag_progression`, `diag_loot` and `diag_upgrades` exist because the bot smoke
+test cannot cover any of them: bots are poor shots, so they rarely kill
+anything, which means they neither earn levels, produce drops, nor ever reach
+the quartermaster.
 
 Everything after `--` goes to `GameOpts.parse()`:
 
@@ -89,7 +91,7 @@ and `tests/integration/test_replica_parity.gd` pin this down.
 | Path | What lives there |
 | --- | --- |
 | `src/sim/` | The whole game as plain RefCounted objects. No nodes, no physics server, no rendering. |
-| `src/actors/` | Data-only `Resource` definitions: `EnemyDef`, `BossDef`, `ItemDef`, `LootDrop`, `DungeonDef`. Shapes, not instances. |
+| `src/actors/` | Data-only `Resource` definitions: `EnemyDef`, `BossDef`, `ItemDef`, `LootDrop`, `DungeonDef`, `UpgradeDef`. Shapes, not instances. |
 | `src/sim/patterns/` | Bullet emitters — the authoring surface for every enemy and boss. |
 | `src/sim/map_grid.gd` | Tile grid: collision, line of sight, chunk streaming. |
 | `src/sim/map_gen.gd` | Dungeon generation; `build()` is the only entry point. |
@@ -98,6 +100,7 @@ and `tests/integration/test_replica_parity.gd` pin this down.
 | `src/content/content.gd` | All enemies and bosses, defined in code. Source of truth. |
 | `src/content/items.gd` | All items, same idea. `Items.ORDER` is the wire format — append only. |
 | `src/content/dungeons.gd` | The kinds of run. `Dungeons.ORDER` is both a wire format and the hub's portal order. |
+| `src/content/upgrades.gd` | The seven upgrades and their draw weights. `Upgrades.ORDER` is a wire format. |
 | `src/net/` | Codec, `ServerRuntime`, `ClientRuntime`. |
 | `src/instances/` | Lobby hub and dungeon runs. |
 | `src/view/`, `src/ui/` | Read-only rendering. Never decides anything. |
@@ -158,8 +161,15 @@ ticks in milliseconds with no SceneTree.
   any client regenerate the whole dungeon. `MAP_STREAM_RADIUS` must stay wider
   than `FOG_VIEW_RADIUS`, or prediction runs on terrain the client lacks.
 - **Bullet speed must stay under one tile per tick.** Wall collision samples
-  position once per tick, so anything faster tunnels. Pinned by
+  position once per tick, so anything faster tunnels. Upgrades multiply bullet
+  speed, so `SimConfig.MAX_BULLET_SPEED` clamps the result — without it two
+  Snipers put shots through walls. Pinned by
   `test_bullet_speeds_stay_below_the_tunnelling_threshold`.
+- **A player's combat numbers are derived, never stored.** `PlayerStats.build()`
+  recomputes them from the character's upgrade ids every time, so a saved stat
+  cannot disagree with the upgrades that produced it. Upgrade *riders* (split
+  charges, poison, erase chance) travel on the bullet instead, because a shot
+  in flight must keep what it was fired with.
 - **Only `ServerRuntime` writes progression and persistence.** The simulation
   reads a player's level and max health, and moves items between the ground and
   a bag; it never grants experience, retires a character, or touches the store.