fifa17-recon: REFUTED -- the CardsDb map is not empty offline

CARD_SYSTEM.md has claimed since it was written that offline the CardsDb map is EMPTY,
every lookup misses, and the view-model reads every rendered field from the resolved
record and NEVER from our item JSON. A live pack open falsifies both halves.

One bronze pack, five cards. Two rendered as real players with names, club badges and
national flags. Three rendered blank: rating 50, position RWB, every attribute 1. Our
pool contains no rating 50, no RWB and no all-ones attributes, so the blank is the
client default.

The two that resolved match our item JSON field for field:
  (232517, 62, RB, nation 36, league 19, team 175, [72,44,58,60,62,61])
    -> SILVA, 62 RB, Wolfsburg badge, Norway flag, 72 PAC 44 SHO 58 PAS 60 DRI 62 DEF
  (235066, 60, GK, nation 34, league 31, team 48, [62,63,33,61,17,62])
    -> NOWAK, 60 GK, 62/61 63/17 33/62

Those attribute numbers were invented by hand this afternoon. They cannot have come
from a database.

So: stats come from our JSON, name/badge/flag come from the client keyed by assetId,
and an assetId the client does not know collapses the WHOLE card to the blank, which
is why a bad id looks like a rendering failure rather than a lookup failure.

THE CONSEQUENCE IS THAT THE PLANNED WORK IS UNNECESSARY. This document recommended
populating the map by driving the insert, hand-building a red-black tree node, or
patching the resolve miss path, all of which write to a live process. None of it is
needed. The rule is: use asset ids that exist in the client database. fut_cards.py has
18 verified ids and 61 structural placeholders, and the placeholders are the blanks.
The remaining work is a DATA problem, not a code-injection problem.

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

fifa17-recon/docs/CARD_SYSTEM.md

@@ -139,3 +139,58 @@ and validates A. No such tool exists yet.
 - `fifadrive.sh` (screen capture) + `vgamepad.py` (virtual pad) for headless
   drive/observe — note keyboard XTEST does NOT reach FIFA; the gamepad is unverified
   in-game.
+
+---
+
+## REFUTED 2026-08-04: the CardsDb map is NOT empty offline
+
+This document has claimed since it was written that "**Offline that map is EMPTY**, so
+every lookup misses and a default blank record is emitted -> generic card", and that
+the view-model reads every rendered field from the resolved record and "NEVER from our
+item JSON". A live pack open falsifies both halves.
+
+### The observation
+
+One bronze pack, five cards. Two rendered as real players with names, club badges and
+national flags. Three rendered as blanks: rating 50, position RWB, every attribute 1,
+no name. Nothing in our pool has rating 50, position RWB or all-ones attributes, so the
+blank is the client's default record, exactly as this document describes.
+
+The two that resolved match OUR ITEM JSON field for field:
+
+| we sent | screen showed |
+|---|---|
+| `(232517, 62, RB, nation 36, league 19, team 175, [72,44,58,60,62,61])` | SILVA, 62 RB, Wolfsburg badge, Norway flag, 72 PAC / 44 SHO / 58 PAS / 60 DRI / 62 DEF / 61 PHY |
+| `(235066, 60, GK, nation 34, league 31, team 48, [62,63,33,61,17,62])` | NOWAK, 60 GK, 62/61, 63/17, 33/62 |
+
+Those attribute numbers were invented by hand. They cannot have come from a database.
+
+### What this means
+
+- The map HAS entries offline. Some asset ids resolve.
+- Rating, position, nation, league, team and the six attributes come from **our item
+  JSON** for a card that resolves.
+- Name, club badge and national flag come from the **client's own data**, keyed by
+  assetId.
+- When the assetId is NOT in the client's data, the whole card collapses to the blank
+  default, which is why a bad id looks like a rendering failure rather than a lookup
+  failure.
+
+### The consequence, which is much cheaper than what this document proposed
+
+The recommended plan here was to populate the client's map by driving its insert, hand
+building a red-black tree node, or patching the resolve miss-path, all of which write
+to a live process. **None of that is needed to get real cards.** The rule is simply:
+
+> Use asset ids that exist in the client's database. Valid id gives a real card.
+> Invalid id gives the blank.
+
+`fut_cards.py` currently carries 18 verified ids and 61 structural placeholders, and
+the placeholders are what produce the blanks. Two of them (232517, 235066) happen to be
+real, which is why the pack was a mix. The remaining work is therefore a DATA problem,
+getting the real id list out of `dbdata.dll`, and not a code-injection problem.
+
+`TODO/CONFIRM`: whether a resolved card's rating truly comes from our JSON or whether
+the client's record happens to agree. The attributes settle it (they were invented) but
+rating specifically has not been isolated. Send a deliberately wrong rating for a known
+good id and look.