fifa17-recon: the real quick-sell table, and the grouping bug is not in our layer

Multi-agent pass over the store subsystem, 11 agents, findings run through three
adversarial verifiers. Full writeup in docs/plan-2026-08-05-store-subsystem.md.

THE REAL DISCARD TABLE IS RECOVERED. quick_sell() paid an invented rating tier
(600/300/150/50) that was wrong for every single card. The real table is
fcc_discardcoins in the client's own game DB, 141 rows keyed (cardtype, level, rare),
read out of the running client and verified 22/22 against live items:

    value = round_half_up(rating * price / 100)
    level    = 3 if rating >= 75, 2 if 65..74, else 1   (0x180141e8a..0x180141ea3,
               derived from rating, NOT a wire field)
    cardtype = FUN_1800d8330(cardsubtypeid), decoded from its jump table and checked
               across every subtype 0..599 with zero disagreements

A 94-rated gold rare is 752, not 600. A 76 rare is 608, not 150. A 55 bronze is 17,
not 50.

This also closes a disagreement nobody had noticed: the CLIENT already computes and
displays the correct value locally whenever our discardValue (atom 0xd7) is 0 or
absent. FUN_18013fe00 stores our value at item +0x38 and the guard at 0x180141025
skips the local computation when it is non-zero. So the screen has been showing the
real number while the server paid a made-up one, on every quick sell ever made.

Verified beyond what the report claimed, because a missing table row pays ZERO and
that would be a regression the old flat tier could not produce: across all 236 items
in the live profile, 230 map to cardtype 1 and 6 to cardtype 6, and NOT ONE would pay
0 coins. Table reproduces at 141 rows and the worked example lands exactly.

ZERO WIRE CHANGE, FUT_DISCARD_TABLE default off. Nothing new is sent; only the coin
figure the server credits moves. This is the patch worth defaulting on after one
in-game check, which is simply quick-selling a card and seeing the coins paid match
the value the card was already displaying.

THE GROUPING BUG IS NOT IN CARDSDLL, and the fix ranked first would have wasted a
launch. Live in the running client all three display groups own exactly the right
pack, there is exactly one copy of each pack record in 4 GiB, and nothing we send is
mis-parsed. The parsed model is correct and the Scaleform layer picks the wrong pack
when turning a tile click into a category id. displayGroupAssetId is served as 1/5/6
while the screen's category field reads 3, and group tiles carry a hardcoded
CATEGORY_ID of 0. Confirmed by direct read: ordinal 3, assetId 6, i.e. Premium, while
the last click was Gold.

The heap map that made this possible, all scoped to one pid: display-group vector
control block, 3 elements of 0x108; group record fields at +0x00 sortPriority,
+0x04 displayGroupAssetId, +0x40 a one-element pack vector; inner pack record 0x1a8
with packType at +0x38, ids at +0x70/+0xac, price at +0xa0, quantities at +0xc0..+0xd0.

extPrice SHOULD BE DELETED, not corrected. Both sub-parsers read only
externalPriceId; amount and currency are discarded. Sending the key at all creates an
"mtx" currency row that switches on a real-money price line the client can never fill
offline, which is the literal "or %1s" on every tile.

A WORRY NOBODY HAD RAISED, and I confirmed it from our own logs: the client has sent
packId 6 on every purchase it has ever made, four for four tonight and six for six
across history. We have never observed a successful buy of anything but Premium Gold.

Also settled: FUT_STORE_DISPLAYGROUP=0 is the right resting state, argued from
mechanism rather than from history; FUT_USERINFO=packs stays off because the
unopened-pack counter is client-mutable and the flag ladder silently drops squadList;
POST /user is a latent hard freeze that has never fired because the client never
issues that POST.

Honest coverage: the ActionScript layer is unread by everyone and every remaining
store mystery lives there.

Live: 439 contract checks pass, market suite passes, both flags off.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fifa17-recon/tools/utas_server.py

@@ -800,6 +800,11 @@ MOVE_BODY = os.environ.get("FUT_MOVE_BODY", "ack")
 # "unknown", so the live-proven value is now on. See _pack_body.
 STORE_DISPLAYGROUP = os.environ.get("FUT_STORE_DISPLAYGROUP", "1") == "1"
 
+# FUT_STORE_GROUPID: give each pack a DISTINCT displayGroupAssetId so the grouped
+# layout that FUT_STORE_DISPLAYGROUP switched on has something to separate packs by.
+# Default off. See the long note at the send site in _pack_body.
+STORE_GROUPID = os.environ.get("FUT_STORE_GROUPID", "0") == "1"
+
 
 # FUT_QUICKSELL: serve the SINGLE-CARD quick sell, which we have never served.
 #
@@ -2626,6 +2631,31 @@ def _pack_body(p, idx):
         # for exactly that reason, and the live test buys a pack to prove the buy path
         # still works.
         body["displayGroup"] = {"value": p["name"]}
+        # FUT_STORE_GROUPID. The risk flagged above ACTUALLY HAPPENED, live 2026-08-05:
+        # sending displayGroup did switch the store to a grouped render path, all three
+        # packs collapsed into ONE group, and drilling into any of the three group tiles
+        # rendered the same single Premium Gold pack. Two of three packs became
+        # unbuyable. Cosmetic tile names were bought with two thirds of the store.
+        #
+        # displayGroupAssetId (0xda) is the obvious thing to group BY, and it is real:
+        # case 0xda in 0x18013af30 calls the INT getter 0x1801c79d0 and lands in the
+        # 0x158-byte pack record at +0x30 (the record is copy-constructed out of the
+        # stack frame at the tail of the deser, via FUN_1801340e0 / FUN_180132180).
+        # Omitting it presumably leaves every pack on the same default, hence one group.
+        #
+        # This is a hypothesis with a mechanism, not a proven fix. The consumer that
+        # builds group membership was NOT located: it is reached from the packed
+        # FIFA17.exe side and chasing it costs far more than the live test does.
+        # Type fidelity is not the risk here (a scalar into an INT getter is the safe
+        # direction; the freeze that started all this came from sending displayGroup as
+        # an ARRAY where a flat object was expected), so the cheap experiment is sound.
+        #
+        # Default OFF until a launch shows three separately buyable tiles.
+        # If it does NOT work, the correct fallback is FUT_STORE_DISPLAYGROUP=0, which
+        # restores the ungrouped layout: tiles read "unknown" but all three are buyable.
+        # Ugly and working beats pretty and unbuyable.
+        if STORE_GROUPID:
+            body["displayGroupAssetId"] = p["id"]
     return body