Fill the rack yourself, and roll barrels out that fill it

The rack had five hardcoded slots where the index WAS the weapon, spelled out in
five places: SLOTS, slotStock, WDESC, drawRack's three parallel arrays,
deliverTin's w+1, and bare wsel === 1|2|3 / G.weapon === 4 tests across five
files. config.WEAPONS is the one table now, G.rack holds up to four {id, n} in
the order you GATHERED them, and slot 0 stays BALL. Everything reads through
slotId/slotStock/slotEntry, so nothing else knows how the rack is stored.

A fifth weapon is always allowed, per Oliver: it rides slot 0 as G.temp until
spent, then slot 0 goes back to the infinite ball. A barrel arms on the spot and
is spent quickly, so refusing it would mean a barrel you shot did nothing. And a
spent weapon LEAVES its slot -- with gathered slots, an exhausted weapon holding
one is a quarter of the rack you can never pick up into. (The old rack kept its
empties dimmed, which was right when a slot meant "BOMB goes here".)

Four new weapons, and they are all the ONE existing pellet loop. firePellet(w)
stamps the WEAPONS row onto the round -- r, dmg, hp, pierce, boom, ignite, col,
speed, life -- so the beacon cannon, flamethrower, laser and rocket needed no new
array and no new update; the break after the first body was the only thing making
a pellet single-target. All four go through the same isBoss branch, which is why
none can silently no-op on a boss the way three of five once did. Measured:
gun/beacon/laser/rocket reach past 16 m, the flamer is a ~6 m cone that ignites.

G.mgT stays the mode timer for all of them, so the eighteen !(G.mgT > 0) guards
across five files did not have to change. kind:'burst' auto-fires at its own rate
for len seconds; kind:'shot' holds the same braced stance and fires one per tap.

The barrels reuse the ball machine's shape: a rolling, shootable non-body. All
three of the registrations that fail silently are done -- blocksClear (loot must
not gate the hand-clear), the contact guard (furniture cannot eat you), and
hitR/GORE_MUL/zombieH. It scores nothing.

The pink had to become procedural. The chroma key deletes every pixel where red
and blue both beat green by 40, so a magenta drum and a magenta laser pistol both
came back as hollow outlines -- 19% and 15% solid against 50-56% for the icons in
other colours. The drum is grey steel with hazard chevrons and every bit of its
pink is the halo drawBarrel paints; the laser went electric blue. Both are solid
now (92% and 58%), and the rule is written down in HANDOFF.

tinTriples 3 -> 10 as asked, and the four dead TUNE ammo constants are gone --
nothing read them once the table landed, which is a panel value you can tune all
day for no effect.

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

HANDOFF.md

@@ -438,6 +438,16 @@ Clear the intro first: `document.getElementById('intro')?.remove()`.
    only when `ref_only` is unused — with `ref_only` set, list the throwaway as an extra sprite
    (`p_pull0`) and delete the PNG afterwards.
 
+15. **NOTHING IN A SPRITE MAY BE PINK, MAGENTA, VIOLET OR PURPLE.** The chroma key does not merely
+   match the corner colour, it deletes every pixel where red AND blue both beat green by 40
+   (`_key.py`: `min(r, b) > g + 40`, and `_fine.py` de-fringes the key twice). So a "vivid magenta
+   drum" and a "magenta laser pistol with a violet coil" both came back as hollow outlines — 19% and
+   15% solid pixels against 50-56% for the icons drawn in other colours. Measure `alpha > 128` as a
+   fraction of the box if a sprite looks thin; that is the whole diagnosis. **Pink can only ever be
+   PROCEDURAL** — the weapon barrel is grey steel with yellow chevrons in its PNG, and every bit of
+   its pink is the halo `drawBarrel` paints around it, which never goes near the keyer. State the
+   forbidden colours in the prompt explicitly; "make it pink" is a request the pipeline cannot fill.
+
 Known generator quirks, all still true:
 - It sometimes ignores the magenta (harmless — the key uses the corner colour).
 - It draws near-identical animation frames unless you describe strongly contrasted poses.
@@ -450,6 +460,42 @@ Known generator quirks, all still true:
 - **Colour-match any regenerated frame** of an existing pair before shipping: fit a per-channel
   linear map onto the original's mean and sd, then verify with a mean-difference number.
 
+## Session log: a rack you fill yourself, and barrels that fill it (2026-08-03)
+
+The second half of the same ask. **The rack no longer has fixed slots.** It used to be five hardcoded
+positions where the index WAS the weapon — `SLOTS`, `slotStock`, `WDESC`, `drawRack`'s three parallel
+arrays, `deliverTin`'s `w + 1`, and bare `wsel === 1|2|3` / `G.weapon === 4` tests in five files. Now
+`config.WEAPONS` is the single table, `G.rack` holds up to four `{id, n}` in the order you GATHERED
+them, and slot 0 is BALL. Read it through `slotId` / `slotStock` / `slotEntry` and nothing else needs
+to know how it is stored.
+
+**A fifth weapon is always allowed** (Oliver's rule): it rides slot 0 as `G.temp` until spent, then
+slot 0 goes back to being the infinite ball. A barrel arms on the spot and is spent quickly, so
+refusing it would mean a barrel you shot did nothing. **A spent weapon LEAVES its slot** — with
+gathered slots, an exhausted weapon sitting in one is a quarter of the rack you can never pick up
+into. (The old rack kept empty slots dimmed, which was right when a slot meant "BOMB goes here".)
+
+**Four new weapons, and they are all the one pellet loop.** `firePellet(w)` stamps the WEAPONS row
+onto the round — `r`, `dmg`, `hp`, `pierce`, `boom`, `ignite`, `col`, `speed`, `life` — so the beacon
+cannon, flamethrower, laser and rocket needed no new array and no new update. The `break` after the
+first body was the only thing making a pellet single-target. Every one of them goes through the same
+`isBoss` branch, which is why none can silently no-op on a boss the way three of five once did.
+Measured: gun/beacon/laser/rocket reach 16 m+, the flamer is a deliberate ~6 m cone that ignites.
+
+**`G.mgT` stayed the mode timer for all of them**, which is why the eighteen `!(G.mgT > 0)` guards
+across five files did not have to change. `kind:'burst'` auto-fires at its own rate for `len`
+seconds; `kind:'shot'` (laser 10, rocket 3) holds the same braced stance and fires one per TAP.
+
+**The barrels** are the ball machine's shape reused: a rolling, shootable non-body. Three
+registrations are silent if forgotten and all three are done — `blocksClear` (a barrel must NOT gate
+the hand-clear; it is optional loot), the contact-kill guard (furniture cannot eat you), and
+`hitR`/`GORE_MUL`/`zombieH`. It scores nothing.
+
+**The pink is procedural, and it has to be** — see pipeline note 15. A magenta drum and a magenta
+laser pistol were both eaten by the chroma key.
+
+`TUNE.tinTriples` 3 -> 10, as asked.
+
 ## Session log: the roster grows — moving bosses, six of them, three new bodies (2026-08-03)
 
 Oliver asked for five things. This is the first half: **enemies first, weapons second**, his call, so