fifa17-recon: club items crashed the client -- unestablished fields, and too wide a blast radius

The game hung and then crashed on the first equippables fetch. My fault twice over.

CAUSE, primary. I copied teamid, leagueid and value straight out of the fcc row as
extras. `value` appears elsewhere as an OBJECT member (displayGroup {"value": ...}),
and a scalar where an object is expected is the type-desync busy loop at 0x1801c7f1a
-- which presents exactly as "the game is taking its time" and then dies. Omission is
safe; an unestablished field is not. That is this project's own rule and I broke it
for three fields that were not needed to draw a card. All three are gone.

CAUSE, contributing. The last request before the crash was type=equippables&count=11
and we answered with 30 items spanning FIVE unverified cardsubtypeids at once: the
widest possible blast radius for a wrong shape, and it tells you nothing about which
subtype was wrong. equippables now answers [] until the subtypes are confirmed one
family at a time, and shelf() takes a families= filter so a test can serve exactly one.

Adds FUT_CLUBITEMS=probe:<family>, which serves one item per candidate subtype for a
single family, so the screen names the correct subtype instead of me guessing a third
time. Eight items, one family, one question.

The flag already defaulted off, so a plain restart cannot serve any of this.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW

fifa17-recon/tools/fut_clubitems.py

@@ -92,21 +92,34 @@ def _item(item_id, carddbid, cardassetid, subtype, extra=None):
     return it
 
 
-def shelf(next_id=CLUBITEM_ID_BASE):
-    """The starter club-item shelf, {family: [item]}."""
+def shelf(next_id=CLUBITEM_ID_BASE, families=None):
+    """The starter club-item shelf, {family: [item]}.
+
+    `families` limits which are built. The combined `equippables` view is what
+    crashed the client: 30 items across FIVE unverified subtypes in one response is
+    the widest possible blast radius for a wrong shape. One family at a time is the
+    only way to learn which subtype is wrong.
+    """
     out, nid = {}, next_id
     for name, table, art, _sid, _sname, subtype in FAMILIES:
+        if families is not None and name not in families:
+            out[name] = []
+            continue
         rows = _rows(table)
         picked = []
         for r in rows[:STARTER_N.get(name, 4)]:
             cid = r.get("carddbid")
             if not cid:
                 continue
-            extra = {}
-            for k in ("teamid", "leagueid", "value"):
-                if r.get(k):
-                    extra[k] = r[k]
-            picked.append(_item(nid, cid, r.get("cardassetid", art), subtype, extra))
+            # NO EXTRAS. An earlier version copied teamid/leagueid/value straight
+            # out of the fcc row and the game hung and then CRASHED on the first
+            # equippables fetch (2026-08-05). `value` is the prime suspect: it
+            # appears elsewhere as an OBJECT member (displayGroup {"value": ...}),
+            # and a scalar where an object is expected is the type-desync busy loop
+            # at 0x1801c7f1a, which reads exactly like "the game is taking its time"
+            # and then dies. Omission is safe; an unestablished field is not. None of
+            # the three was needed to draw a card.
+            picked.append(_item(nid, cid, r.get("cardassetid", art), subtype))
             nid += 1
         out[name] = picked
     return out