The tab was empty because we answered the wrong question. The client asks
GET club/stats/consumables 41 times a session; we replied with the PLAYER stat set
(players 205, playersGold 189 ...), which that panel does not read. Confirmed on
screen: seven categories present and selectable, every one reading 0.
Now appends 14 consumables* rows counted from the SHELF. The shelf, not STORE.items():
the consumables we serve are a synthetic overlay never granted into the save, so
counting the store gives fourteen zeros, which on screen is byte-identical to failure
and would have made the experiment unreadable. Counts match the independently derived
expectation exactly: 126 total, 21 healing, 7 player contracts, 21 player training,
3 player fitness, 20 position, 21 GK training, 6 manager contracts, 19 playstyle.
Safe by construction: the vocabulary is an ATOM switch (FUN_18012fd40, 40 arms,
default return 0), so an unrecognised name is inert rather than fatal, and the rows
are APPENDED -- the player, nation and league rows that drive the working screens are
untouched. Zero rows unless FUT_CONSUMABLES is armed.
Default ON because answering the consumables panel with player counts is wrong by
inspection rather than a judgement call. FUT_CONSUM_STATS=0 reverts.
439 + 414 checks green.
The open question this sets up: whether a non-zero count makes the client request an
item list at all. If it does, the log names the route and /consumables/%s is settled
for free. If the numbers move and no request follows, the panel renders from counts
alone and the 126-item shelf was never needed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
funman300
2f8a6512db