test(fifa17): add Python-oracle economy differential coverage

economy_differential.rs boots the REAL Python oracle (fifa17-recon/tools/
utas_server.py) as an isolated subprocess (env FUT_PROFILE/FUT_ACCOUNT_PATH/
FUT_PORT into a temp dir + loopback port; no production container/port/save;
killed on Drop) AND the real Rust stack (seeded in-process Core + a real Server
with EconomyServices), seeds a semantically-aligned fixture on both, and drives
16 ops through the REAL surfaces (oracle over HTTP; Rust via
Server::try_handle_economy on the off-runtime thread).

Result: 15 PARITY, 1 DIFFERENT-BY-DESIGN.
- PARITY: credits, userMassInfo economy, purchasegroup (pack70/sentinel/clean-v1
  incl. the real SessionStore capability handshake), Store BUY, POST /purchased
  open, GET /purchased reveal (VERIFIED: durable single-profile purchased pile
  on BOTH — the hypothesised per-SID cache does NOT exist, so PARITY not
  DIFFERENT-BY-DESIGN), quick-sell (both forms), move, match WIN (+400 byte
  shape), market list/query/cancel.
- DIFFERENT-BY-DESIGN: market second-buy. First buy debits buyNowPrice + closes
  on both. Rust's MarketStore is a crash-consistent single-debit ledger (second
  buy of a sold listing = no-op, pinned by assertion); the oracle's buyable
  market is a stateless PACK_POOL sample that re-debits on repeat. Compat impact
  NONE (buy-now is one-shot); Rust is a strict correctness improvement.

No Python source changes; no classifier changes. Deterministic (3 runs).

.gitignore

@@ -30,3 +30,9 @@ Thumbs.db
 
 # Frozen baseline archives / inspects / manifests
 /docker-backups/
+gate-evidence/
+
+# Raw Fire2 frame captures — forensic evidence, may contain session material.
+# Sanitize with `blaze-sanitize` before anything leaves this machine.
+*.ofcap
+captures/

Cargo.toml

@@ -0,0 +1,21 @@
+[workspace]
+resolver = "2"
+members = [
+    "openfut-core",
+    "openfut-protocol-blaze",
+    "openfut-adapter-fifa17",
+    "openfut-blaze-host",
+    "openfut-host-config",
+    "openfut-http",
+    "openfut-tls",
+    "openfut-redirector-host",
+    "openfut-roster-host",
+    "openfut-utas-host",
+    "openfut-identity",
+    "openfut-import-fifa17",
+    "openfut-bridge",
+    "openfut-launcher",
+    "openfut-launcher/openfut-hook",
+    "fifa-blaze/crates/blaze-proto",
+    "fifa-blaze/crates/server",
+]

OPENFUT_HANDOFF.md

@@ -0,0 +1,265 @@
+# OpenFUT — project handoff
+
+Self-contained briefing for an assistant with **no access to this repo or machine**.
+Everything needed to understand the project and reason about its open problems is here.
+
+---
+
+## 1. What this is
+
+**OpenFUT** is a clean-room, fully offline re-implementation of the server backend for
+**FIFA 17 Ultimate Team (FUT)**. EA's servers for FIFA 17 are long dead. The goal is to
+make the retail game's FUT mode fully playable again — open packs, build squads, use the
+transfer market, play matches and earn rewards — by emulating every server the client
+talks to, on localhost.
+
+Nothing is decompiled *into* the project. The game's binaries are read to learn the
+**wire format** (which JSON keys, of which types, each response must contain), and the
+servers are written from scratch in Python against that spec.
+
+The client is unmodified retail FIFA 17 running under Wine/Proton on Linux.
+
+---
+
+## 2. Architecture — four independent servers
+
+FIFA 17 does not talk to one backend. It talks to four, on different protocols, and all
+four must be satisfied in sequence before FUT loads.
+
+```
+FIFA 17 (Wine/Proton)
+  │
+  ├─ LSX / Origin      :4216    XML over TCP. Local Origin client emulation.
+  │                             Login, entitlements, persona.
+  ├─ Blaze              :42127 redirector (TLS) → :42130 game server, :42131 nucleus
+  │                             EA's binary "Fire2/TDF" RPC protocol. Session, auth,
+  │                             and — critically — the CLIENT-CONFIG STORE.
+  ├─ UTAS / RS4         :8099   The FUT REST API. JSON over HTTP. ~45 endpoints.
+  │                             Club, squads, packs, market, matches. The bulk of it.
+  └─ POW / EASFC        :8094 (+ :8080 content)   A third HTTP API, discovered late.
+                                Online status bar, level, EASFC credits, catalogue.
+```
+
+Plus two helpers: a **roster** server (:8081) serving a roster-update XML the FUT
+loading screen blocks on, and **autopatch**, which patches the running process's
+ProtoSSL certificate verification so the client accepts our self-signed TLS.
+
+### How the client is redirected
+
+Three mechanisms, in decreasing order of preference:
+
+1. **Blaze client-config keys** — the cleanest. Blaze serves a key/value config store
+   and the client reads its own service URLs from it. `FUT_RS4_APIURL_<MODULE>` and
+   `FUT_RS4_URL_<CALL>` point the FUT API at `127.0.0.1:8099`; `FIFA_POW_URL` points
+   the EASFC layer at `127.0.0.1:8094`. **No root, no DNS games.**
+2. **`/etc/hosts`** — for hosts baked into the binary (`easw.easports.com`,
+   `gosredirector.ea.com`).
+3. **iptables DNAT** — for a hardcoded IP (`159.153.51.20` → the Blaze redirector).
+
+---
+
+## 3. The wire format, and why it is unforgiving
+
+FUT responses are JSON, but the client does **not** use a general JSON object model. Each
+response class has a hand-written SAX-style deserializer that walks tokens and dispatches
+on a **hashed key id** (an "atom"). This has three consequences that dominate the project:
+
+**Atoms.** Every JSON key name maps to a 16-bit atom id via FNV-1a. There is a recovered
+table of ~900 (id → name). A response is really "which atoms does deserializer X read,
+and of what type".
+
+**Type fidelity is fatal.** Feeding a scalar where the parser expects an object or array
+does not error — it **desyncs the token reader and the game hard-freezes** in a busy loop
+at `0x1801c7f1a`. This is the single most common way to break the game, and it has bitten
+this project repeatedly. Arrays must be arrays; nested objects must be objects.
+
+**Unknown keys are usually skipped safely** — most deserializers route an unrecognised
+atom to a value-skip handler (`FUN_180135ff0`), so extra fields are inert. This document
+previously named `FutMoveCard` (`0x180128600`) as an exception with no skip handler at
+all. **That was wrong**, and the retraction is in §5a: it has two skip-handler call sites
+and parses seven atoms. No deserializer in this project is currently known to lack one.
+Treat any future "this class has no skip handler" claim as unproven until the search is
+shown to have covered the whole function.
+
+### Working method
+
+For any endpoint: find the response class's deserializer, extract the atom ids it
+compares against, map them to names, note the getter used for each (int / string / bool /
+nested), and build the minimal body. Omit nested members unless their shape is known —
+omission is skip-safe, a wrong shape freezes the game.
+
+---
+
+## 4. What works today (live-verified)
+
+| Area | Status |
+|---|---|
+| Boot to the FUT hub | ✅ |
+| Club identity, coins, W/D/L record | ✅ |
+| Active squad — renders 11 real players, chemistry links | ✅ |
+| Squad building — `PUT /squad/<id>` fires, persists across relaunch | ✅ |
+| Squad roster ("MY SQUADS") | ✅ |
+| Transfer market — browse, bid, buy-now, sell, watchlist | ✅ |
+| Packs — buy, reveal, Send to Club | ✅ (the workaround is retired, see §5a) |
+| Quick sell — destroys cards, credits coins | ✅ |
+| Match loop — create/ready/play/destroy + coin rewards | ✅ implemented, **never played in-game** |
+| Online/EASFC status bar (no "servers unreachable") | ✅ when enabled |
+| Seasons / tournaments / leaderboards / champions | ⚠️ routed with reversed schemas, never live-tested |
+
+Current save state: 99 club items, 8,400 coins, 0-0-0 record.
+
+**Design convention:** every risky change ships behind an environment flag, default set
+to whatever is live-proven (`FUT_MASSINFO`, `FUT_USERINFO`, `FUT_MODES`,
+`FUT_PACK_AUTOCLUB`, `FUT_POW`, `FUT_STORE_GROUPS`, …). This exists because two working
+screens were broken by shipping "corrections" on by default.
+
+---
+
+## 5. Open problems
+
+### 5a. "Send to Club" kills the FUT session — SOLVED 2026-08-04
+
+Opening a pack shows the cards correctly; choosing **Send to Club** used to produce
+*"there has been an error connecting to FIFA 17 Ultimate Team"* and a logout, seven
+attempts running. The cards always moved server-side; only the acknowledgement was
+rejected.
+
+The cause was the response body. `PUT ut/%s/item` returns per-item **verdict** records,
+not an acknowledgement, and the completion handler raises
+`EVENT_CARDS_MOVE_CARD_FAILURE` when the record vector is empty or when `success != 1`.
+Every body the project returned, `{}` included, reported the move as failed. The fix is
+the real shape:
+
+```json
+{"itemData":[{"id":100000125,"pile":"club","success":true}, ...]}
+```
+
+Live: five cards to the club, session survived, cards persisted, no `ut/delete/auth`.
+The autoclub workaround is retired.
+
+Two corrections this closed, both worth carrying forward:
+
+- The repo's claim that this deserializer had **no skip handler** and parsed only two
+  keys was false. It came from searching a truncated decompile. It implied the body
+  could not be at fault, which is what sent seven attempts after client-side state.
+  Never conclude an absence from a truncated or unverified-length extraction.
+- The quick-sell asymmetry was not evidence of client state. Quick sell's callbacks
+  read only the transport status code and never touch the body.
+
+### 5b. "MY CLUB" counter always reads 0 — UNSOLVED
+
+The hub tab bar shows `MY CLUB  0` despite the club holding 99 items.
+
+**Eliminated by live test:**
+- **Not the item list** — the user opened MY CLUB, the client fetched the club and
+  **displayed all 99 players correctly**, and the counter still read 0.
+- **Not `pileSizeClientData`** — the massinfo member that carries pile sizes as
+  `{"entries":[{"key":int,"value":int}]}`. A probe sent 16 entries with uniquely
+  identifiable values; the counter stayed 0.
+- **Not lazy loading** — the club endpoint was fetched 6 times that session.
+
+**Unexplored contrast:** the `ACTIVE SQUAD` tab in the same bar correctly shows `11/23`.
+So some counters work. Whatever differs between that one and the club one is likely the
+answer.
+
+### 5c. Store tiles render "unknown" — DIAGNOSED, NOT FIXED
+
+Pack tiles show `unknown` with zero item counts. The `"unknown"` string is an
+unconditional **default** in a string constructor — the field simply never gets written.
+The store renders *display groups*, and `displayGroup` is parsed **recursively by the same
+element parser**. Sending it populated **froze the store** (the type-desync busy loop), so
+it is behind a flag, default off. Doing it properly needs the group's own field set worked
+out rather than a self-referential copy of the pack.
+
+### 5d. Seasons and Draft refuse — UNSOLVED, and not obviously server-side
+
+Selecting **single-player Seasons** raises *"There was a problem communicating with the
+FIFA Ultimate Team servers"* while making **zero requests to any layer**. UTAS, Blaze and
+POW logs show only pings and one census subscription across the whole failure window. No
+response can be wrong because no request was made. POW is eliminated (same failure with it
+enabled and disabled).
+
+**Online Draft** hangs the client rather than crashing it (process alive, no dump). The
+one suspicious thing on the wire is `GET ut/%s/squad/mode/draft/state`, which our generic
+`/squad` route answers with a full active-squad object: 23 slots, nested `itemData`, a
+33-integer formation string. The real class wants `roundsInfo` plus a state enum, so this
+is a textbook type-desync candidate and the timing matches. **Nothing has isolated it**;
+it is a suspect, not a cause.
+
+Both matter beyond themselves, because they are the only two routes into a match, and the
+`/match` request shape has therefore never been captured.
+
+---
+
+## 6. Notable reverse-engineering findings
+
+- **Class → deserializer resolution.** A response class's name literal is preceded by a
+  **4-byte header**, and the constructing factory's `lea` points at *the header*, not the
+  text. Lookups must use `name_address - 4`. Six attempts failed on this off-by-four;
+  four of them returned zero results and nearly got recorded as "this class has no
+  deserializer".
+- **The request-template table is a floor, not a ceiling.** Several real endpoints are
+  built by the caller appending a suffix and therefore never appear in the binary's URL
+  table: `squad/list`, `user/club`, `club/stats/*`, `clientdata/<key>`. Only live traffic
+  reveals them. This has caught the project three separate times.
+- **The documentation lies.** The project's own `ENDPOINT_MAP.md` (~1,360 lines, ~100
+  reversed structs) has been wrong repeatedly: it claimed `FutMoveCard` parses
+  `chemistry` (it does not); it called seven store pack fields "skipped no-ops" (all are
+  parsed); it gave price-object keys as `amount`/`currency` (the parsers read
+  `externalPriceId`). **Verify against the decompiler before relying on any row.**
+- **The online layer was hiding in an unpacked DLL.** "EA FC servers are unreachable"
+  comes from a third HTTP API implemented in a *loose, unpacked, string-rich* library —
+  not the packed executable, and not any layer previously emulated. It is redirectable
+  purely through the Blaze config store.
+- **The main executable is Denuvo-packed.** Its code exists only in a live process. Live
+  memory is readable via `/proc/PID/mem` (the PE is mapped flat), which is how a crash
+  site was disassembled. Any logic living there cannot be reversed statically.
+
+---
+
+## 7. Tooling built
+
+- A **PyGhidra harness** with helpers for decompiling, xrefs, vtables, byte scanning and
+  class→deserializer resolution. (Ghidra's Java/OSGi scripting is broken on this machine;
+  PyGhidra bypasses it entirely.)
+- A **minidump reader** — exception record, fault-time registers, module map, and a stack
+  walk that recovers a usable backtrace.
+- A **live code grabber** that reads and disassembles unpacked code out of a running
+  process.
+- A **read-only live probe** pattern for polling client model state while playing.
+- **Two test suites**: 380 live contract checks (freeze-safety: asserts every response
+  field's type against the reversed schema) and 51 pure unit checks for match rewards.
+- A **traffic-replay audit** that diffs current responses against a known-good session —
+  this is what proves a change did not alter what the client sees.
+
+---
+
+## 8. Documentation in-repo
+
+| File | Contents |
+|---|---|
+| `ENDPOINT_MAP.md` | ~100 reversed response structs, atoms, types, freeze risks |
+| `FUT_RESPONSE_REBUILD_PLAN.md` | Squad family, massinfo, the service-layer call graph |
+| `REBUILD_RESEARCH.md` | Complete API surface, gap analysis, POW layer, and every eliminated hypothesis with its evidence |
+| `CARD_SYSTEM.md` | How card identity resolves locally from the game's own database |
+| `REPACK_INTEL.md` | Origin/LSX emulation notes |
+
+---
+
+## 9. Where help would be most valuable
+
+1. **The MY CLUB counter (§5b).** Given the client demonstrably *has* the items and
+   *renders* them, what else could a tab counter read from? Note that a sibling counter in
+   the same bar works correctly.
+2. **Seasons refusing with zero requests to any server (§5d).** The client raises a
+   "problem communicating with the FIFA Ultimate Team servers" without contacting
+   anything. Nothing on the wire can be wrong because nothing went on the wire.
+3. **Whether the remaining problems are fixable server-side at all**, or whether the
+   deciding logic lives in the Denuvo-packed executable and only live instrumentation can
+   settle it. Note that this question was asked about `Send to Club` too, and there the
+   answer turned out to be a plain wire fix, so treat "it must be client-side" as a
+   hypothesis needing evidence rather than a fallback explanation.
+
+Useful framing: this project's failures have almost always come from proposing a fix
+before testing the assumption under it. Hypotheses that come with a cheap way to
+disconfirm them are worth far more than plausible ones.

OPENFUT_PROJECT_REPORT.md

@@ -0,0 +1,313 @@
+# OpenFUT — Project Report
+
+**Goal:** make FIFA 17 Ultimate Team fully playable offline, forever, by re-implementing
+every server the game talks to.
+
+**Status:** FUT boots, loads, and is playable. Packs, squads, the transfer market, coins
+and progression all work. Two cosmetic/flow problems remain open.
+
+**Timeline:** 2026-06-25 → 2026-08-04 · 44 commits · ~12,900 lines of Python across 39
+tools · ~3,600 lines of reverse-engineering documentation.
+
+---
+
+## 1. What the project is
+
+EA shut down FIFA 17's servers years ago, which kills Ultimate Team — the mode is entirely
+server-driven. Your club, squads, packs, market and progression all live server-side, so
+without a backend the mode is dead even though the game still installs and runs.
+
+OpenFUT replaces that backend with local servers. The game is **unmodified retail
+FIFA 17** running under Wine/Proton on Linux; nothing is patched into the game except a
+single runtime tweak so it accepts our TLS certificate.
+
+This is **clean-room work**. No EA code is copied or redistributed. The game's own
+binaries are read to learn the *wire format* — which JSON keys, of which types, each
+response must carry — and the servers are written from scratch against that specification.
+
+---
+
+## 2. Project history
+
+The project changed target twice before finding its footing. That arc matters, because
+each pivot was driven by hitting a hard wall.
+
+**Phase 1 — FIFA 23 (June 2026).** Began as an offline FUT backend for FIFA 23: a Rust
+core (`openfut-core`, Axum + SQLite), a protocol bridge (`openfut-bridge`), and a GUI
+launcher. All three built and passed tests. The architecture was sound but the client
+never got far enough to exercise it.
+
+**Phase 2 — the FIFA 23 wall.** FIFA 23 refused to go online at all. Extensive reverse
+engineering of the connection state machine, live-memory probing, and forcing the
+"go online" gate directly all failed — the client's internal coherence checks were the
+wall, not any single flag. Documented as a dead end rather than fought.
+
+**Phase 3 — the FIFA 17 pivot (late July).** FIFA 17 turned out to be a far better target:
+its network library is **unprotected and fully symboled**, exposing 979 RPC names. The
+insight was to crack FIFA 17 first and port the understanding back.
+
+That worked, quickly:
+- **TLS pinning defeated** — the client's certificate verification is patched at runtime
+  in memory, so a self-signed cert is accepted.
+- **Origin/LSX emulation** — the local Origin client protocol was reverse engineered,
+  including the repack's own crypto layer, beating "log in to Origin" and
+  "title version outdated".
+- **Blaze cracked end to end** — EA's binary RPC protocol: redirector, second-hop
+  handshake, and the encoded pre-auth exchange. This was the big one.
+- **Full FUT API mapped** — ~100 response structures reverse engineered to field level.
+
+**Phase 4 — building the FUT backend (August).** With the protocol understood, the work
+became making FUT actually *play*: card rendering, packs, the store, the transfer market,
+squads, and match rewards. This is where the project stands.
+
+---
+
+## 3. Architecture
+
+FIFA 17 does not talk to one backend. It talks to **four**, on different protocols, and
+all four must be satisfied in sequence before FUT loads.
+
+```
+FIFA 17 (Wine/Proton)
+  │
+  ├─ LSX / Origin     :4216    XML/TCP — local Origin client emulation
+  │                            login, entitlements, persona
+  ├─ Blaze            :42127 redirector (TLS) → :42130 game, :42131 nucleus
+  │                            EA's binary Fire2/TDF RPC
+  │                            session, auth, and the CLIENT-CONFIG STORE
+  ├─ UTAS / RS4       :8099    the FUT REST API — JSON/HTTP, ~45 endpoints
+  │                            club, squads, packs, market, matches
+  └─ POW / EASFC      :8094    a third HTTP API (+ :8080 content)
+                               online status, level, credits, catalogue
+```
+
+Plus **roster** (:8081), serving an XML file the FUT loading screen blocks on, and
+**autopatch**, which patches certificate verification in the running process.
+
+### Redirection, in order of preference
+
+1. **Blaze client-config keys** — the client reads its own service URLs from a key/value
+   store that Blaze serves. Pointing FUT and EASFC at localhost needs **no root and no
+   DNS manipulation**. This is the clean mechanism and most redirection uses it.
+2. **`/etc/hosts`** — for hostnames baked into the binary.
+3. **iptables DNAT** — for one hardcoded IP address.
+
+---
+
+## 4. The wire format — and why it is unforgiving
+
+FUT responses are JSON, but the client does not use a general JSON object model. Each
+response class has a hand-written SAX-style deserializer that walks tokens and dispatches
+on a **hashed key id** ("atom"). Three consequences dominate the project:
+
+**Atoms.** Every JSON key maps to a 16-bit id via FNV-1a. A recovered table of ~900
+id→name pairs is the Rosetta stone. A response spec is really "which atoms does this
+deserializer read, of what type".
+
+**Type fidelity is fatal.** A scalar where an object or array is expected does not error —
+it **desyncs the reader and hard-freezes the game** in a busy loop. This is the primary
+failure mode of the entire project.
+
+**Unknown keys are usually skipped — but not always.** Most deserializers route
+unrecognised atoms to a skip handler, making extra fields inert. At least one does not,
+so any unexpected key desyncs it.
+
+**Working method:** locate the deserializer, extract its atom set and per-atom getter
+types, build the minimal body, and omit nested members whose shape isn't known — omission
+is safe, a wrong shape freezes the game.
+
+---
+
+## 5. What works
+
+| Capability | State |
+|---|---|
+| Boot: Origin → Blaze → FUT hub | ✅ |
+| Club identity, coins, W/D/L record | ✅ |
+| Active squad — 11 real players, ratings, chemistry | ✅ |
+| Squad building — saves and survives relaunch | ✅ |
+| Squad roster ("MY SQUADS") | ✅ |
+| Transfer market — browse, bid, buy-now, list, watchlist | ✅ |
+| Store — buy packs | ✅ |
+| Packs — cards land in the club | ✅ via workaround (§6a) |
+| Quick sell — credits coins | ✅ |
+| Match loop — create/ready/play/destroy + rewards | ⚠️ built, **never requested by the client** (see below) |
+| Online/EASFC status bar | ✅ when enabled |
+| Seasons, tournaments, leaderboards, champions | ⚠️ routed, **never requested by the client** (see below) |
+| Card identity (names, faces, ratings) | ✅ resolves from the game's own local database |
+
+### "Untested" is two different things, and the difference matters
+
+The server log records the User-Agent of every request. The real client identifies as
+`ProtoHttp`; this project's own curl and Python probes do not. Separating them shows that
+several endpoints previously filed as "built but untested" have in fact **never been
+requested by the game at all**, and everything recorded against them was self-inflicted
+traffic:
+
+| endpoint | client requests | project probes |
+|---|---|---|
+| `/leaderboards/options` | 5 | 1 |
+| `/clientdata/userHubData` | 13 | 2 |
+| `/user/accountinfo` | 23 | 49 |
+| `/season`, `/season/user` | **0** | 2 |
+| `/tournament`, `/tournament/user` | **0** | 3 |
+| `/leaderboards` (bare) | **0** | 2 |
+| `/champion` | **0** | 2 |
+| `/match` | **0** | 2 |
+| `/clubUser` | **0** | 93 |
+| `/user/list` | **0** | 180 |
+| `/sbs` (SBC), `/draft/mode` | **0** | 0 |
+
+`/clubUser` and `/user/list` are the starkest: 273 requests between them, none from the
+game. Work was done on both on the assumption the client wanted them.
+
+A zero in the client column does **not** mean the client never wants that endpoint. In
+most cases it means **nobody has navigated to that part of the game yet**. It does mean no
+claim about those endpoints has been tested against the client, and any analysis that does
+not apply this filter is misleading by default.
+
+**Requirement:** every capture and analysis tool in this project should apply the
+User-Agent split by default rather than as an afterthought.
+
+**Design convention.** Every risky change ships behind an environment flag whose default
+is whatever is live-proven. This exists because shipping "corrections" on by default broke
+two working screens — once freezing the store outright.
+
+---
+
+## 6. Open problems
+
+### 6a. "Send to Club" ends the FUT session — SOLVED 2026-08-04
+
+Opening a pack displayed the cards correctly, but choosing **Send to Club** produced
+*"there has been an error connecting to FIFA 17 Ultimate Team"* and a logout, seven
+attempts running. The cards always moved correctly server-side; only the
+acknowledgement was rejected.
+
+**It was the response body all along.** `PUT ut/%s/item` does not parse an
+acknowledgement, it builds per-item **verdict** records, and the completion handler
+raises `EVENT_CARDS_MOVE_CARD_FAILURE` when the record vector is empty or when
+`success != 1`. Every body this project returned, `{}` included, therefore told the
+client the move had failed, and the client ended the FUT session because that is what
+that event does. Serving the real shape fixed it in one launch:
+
+```json
+{"itemData":[{"id":100000125,"pile":"club","success":true}, ...]}
+```
+
+Live result: five cards sent to the club, session survived, cards persisted, no
+`ut/delete/auth` logout. Both flags are now defaults and the autoclub workaround is
+retired.
+
+**Why it took seven attempts,** which is the part worth keeping: the project had
+recorded that this deserializer had *no skip handler* and parsed only two keys. That
+was false, produced by searching a **truncated** decompile (the first 4,000 characters
+of a 6,193-character function). It implied "the body cannot be the problem", which is
+what redirected the investigation to client-side state. The quick-sell asymmetry that
+seemed to confirm it has a mundane explanation: quick sell's callbacks read only the
+transport status code and never touch the body, so its tolerance of `{}` said nothing
+about this endpoint.
+
+The general lesson, now a standing rule: **never conclude an absence from a truncated
+or unverified-length extraction**, and treat every negative claim in the endpoint docs
+as weaker than the corresponding positive one.
+
+### 6b. "MY CLUB" counter reads 0
+
+The hub shows `MY CLUB 0` despite 99 items. Not the item list (the client *displays* all
+99), not the pile-size data (a 16-entry probe changed nothing), not lazy loading (fetched
+6 times). Unexplored: the neighbouring `ACTIVE SQUAD` counter works correctly — the
+difference between them is likely the answer.
+
+### 6c. Store tiles read "unknown"
+
+`"unknown"` is an unconditional default in a string constructor — the field is never
+written. The store renders *display groups*, and that member is parsed recursively by the
+same parser; sending it populated **froze the store**, so it is flagged off pending a
+correct group schema.
+
+### 6d. Large parts of the game have never been opened
+
+Distinct from 6a to 6c, which are things that misbehave. Per the User-Agent table in
+section 5, entire modes have never issued a single client request: Seasons, Tournaments,
+FUT Champions, Draft, SBC, and the match loop itself. Their endpoints are routed and their
+schemas are reversed, but no claim about any of them has been tested against the game.
+
+This is not a bug list. It is unmeasured surface, and it is the cheapest information
+available to the project because most of it costs nothing but navigating menus. It is
+recorded here because "routed from a reversed schema" reads like a stronger claim than it
+is, and section 7 warns that this project's notes have described things differently from
+what is true.
+
+*A multi-agent investigation into 6a and 6b is currently running.*
+
+---
+
+## 7. Notable findings
+
+- **Class → deserializer resolution.** A response class's name literal is preceded by a
+  4-byte header and the factory points at *the header*. Six attempts failed on that
+  off-by-four; four returned nothing and were nearly recorded as "no deserializer exists".
+- **The URL table is a floor, not a ceiling.** Several real endpoints are built by
+  appending a suffix at the call site and never appear in the binary's template table.
+  Only live traffic reveals them — this caught the project three separate times.
+- **The project's own documentation has been wrong repeatedly** — fields described as
+  inert turned out to be parsed, and documented key names didn't match the parsers.
+  Verify against the decompiler, not the notes.
+- **The online layer was hiding in plain sight.** "EA FC servers unreachable" comes from a
+  third HTTP API in a *loose, unpacked, string-rich* library — not the protected
+  executable, and not any previously emulated layer. Redirectable purely by config.
+- **The main executable is Denuvo-packed**, so its code exists only in a live process.
+  Live memory is readable, which is how a crash site was disassembled — but logic living
+  there cannot be reverse engineered statically.
+
+---
+
+## 8. Tooling and quality
+
+- **PyGhidra harness** with decompile / xref / vtable / byte-scan / class-resolution
+  helpers (Ghidra's own Java scripting is broken on this machine).
+- **Minidump reader** — exception record, fault-time registers, module map, stack walk.
+- **Live code grabber** — reads and disassembles unpacked code from a running process.
+- **Read-only live model probes** for watching client state while playing.
+- **Test suites:** 380 live contract checks (type/freeze safety per reversed schema) plus
+  51 pure unit checks. Both green.
+- **Traffic-replay audit** — diffs current responses against a known-good session to prove
+  a change didn't alter what the client sees.
+- **~3,600 lines of RE documentation** across six files, including every eliminated
+  hypothesis with its supporting evidence.
+
+---
+
+## 9. Roadmap
+
+**Immediate (free, no code):** play a match — the reward loop is built and unit-tested but
+has never run in-game. Enable the game-mode endpoints and see whether four more modes
+light up.
+
+**Near term:** close the two open problems, most likely via live instrumentation rather
+than more static analysis. Implement SBC and Draft (schemas already recovered). Fix the
+store display groups properly.
+
+**Longer term:** the stated destination is porting this into the Rust `openfut-core`
+behind a FIFA-17 bridge. Everything currently lives in Python prototypes; the
+documentation is now good enough to write the port against.
+
+---
+
+## 10. Honest assessment
+
+**What went well.** The FIFA 17 pivot was the decisive call — recognising that an
+unprotected binary was worth more than persisting against a hardened one. Blaze, Origin
+and the FUT API were all cracked end to end. The freeze-safety test suite has repeatedly
+caught regressions before they reached the game.
+
+**What went badly.** Progress has been slowest where fixes were proposed before the
+assumption under them was tested. Both open problems absorbed many attempts built on
+plausible but unverified theories; several were disproved in a single measurement that
+could have been taken first. Two working screens were broken by shipping unverified
+"corrections" on by default — which is precisely why the flag convention exists now.
+
+**The most reliable technique** has been comparing a working case against a failing one:
+diffing live traffic against a known-good session, and contrasting a succeeding endpoint
+with its failing sibling. That has produced more answers than any amount of decompilation.

SECURITY_AUDIT_REPORT.json

@@ -0,0 +1,340 @@
+{
+  "metadata": {
+    "reportDate": "2026-07-28",
+    "codebaseName": "OpenFUT",
+    "version": "0.1.0",
+    "submodulesCovered": [
+      "openfut-core",
+      "openfut-bridge",
+      "openfut-launcher"
+    ],
+    "language": "Rust",
+    "framework": "Axum + SQLite"
+  },
+  "vulnerabilities": [
+    {
+      "severity": "critical",
+      "category": "authentication",
+      "file": "openfut-core/src/services/profile.rs",
+      "line": 8,
+      "cwe": "CWE-287",
+      "title": "Missing Authentication on All Endpoints",
+      "description": "No authentication or authorization checks on any API endpoint. The system uses single-profile design with get_active_profile() returning the first row (LIMIT 1) without any token validation, session management, or per-user isolation. In a networked context, any HTTP client can access all endpoints without credentials.",
+      "impact": "Complete compromise of data confidentiality and integrity. Any attacker can view, modify, or delete all user data without authentication.",
+      "exploitPath": "curl http://127.0.0.1:8080/clubs - accesses club data without any auth headers or tokens",
+      "recommendation": "Implement stateless JWT tokens or session-based authentication. Add middleware to validate tokens on all endpoints. Implement per-user authorization checks in services."
+    },
+    {
+      "severity": "critical",
+      "category": "injection",
+      "file": "openfut-core/src/routes/auth.rs",
+      "line": 87,
+      "cwe": "CWE-89",
+      "title": "SQL Injection via String Interpolation",
+      "description": "SQL table names are interpolated using string formatting: sqlx::query(&format!(\"DELETE FROM {table}\")). Although currently hardcoded in a loop, this violates parameterized query principles and creates a risk if the table list ever becomes user-controlled or the pattern is copied elsewhere.",
+      "impact": "Potential remote code execution via database manipulation. If extended to user input, attackers could modify arbitrary tables or drop the database.",
+      "exploitPath": "Currently mitigated by hardcoded table names, but the pattern is dangerous and violates secure coding practices.",
+      "recommendation": "Use SQLx's dynamic query builders or identifier types that properly escape table/column names. Replace format! string interpolation with sqlx::query_builder for dynamic identifiers."
+    },
+    {
+      "severity": "high",
+      "category": "configuration",
+      "file": "openfut-bridge/src/proxy.rs",
+      "line": 44,
+      "cwe": "CWE-295",
+      "title": "TLS Certificate Validation Disabled",
+      "description": "HTTP client explicitly disables TLS certificate validation: .danger_accept_invalid_certs(true). This bypasses all certificate pinning, expiration, and hostname verification, making the bridge vulnerable to man-in-the-middle attacks.",
+      "impact": "Attacker positioned between bridge and upstream can intercept, modify, or read all traffic. Compromises confidentiality and integrity of requests to Core and external services.",
+      "exploitPath": "MITM attack between openfut-bridge and openfut-core or upstream services. ARP spoofing on localhost subnet would redirect traffic.",
+      "recommendation": "Remove .danger_accept_invalid_certs(true) in production. If testing requires it, gate behind a development-only environment variable with strong warning. Use proper certificate management (CA bundles, cert pinning)."
+    },
+    {
+      "severity": "high",
+      "category": "dos",
+      "file": "openfut-core/src/services/season.rs",
+      "line": 23,
+      "cwe": "CWE-248",
+      "title": "Unguarded expect() Causes Denial of Service",
+      "description": "Multiple unchecked expect() calls that will panic and crash the server if database queries fail or return unexpected results: Ok(fetch(pool, profile_id).await?.expect(\"just inserted\"))",
+      "impact": "Denial of service. A single database inconsistency or race condition crashes the entire server, making the application unavailable.",
+      "exploitPath": "Trigger race conditions during concurrent requests (e.g., rapid profile deletion + season fetch). Database corruption or migration failure crashes the service immediately.",
+      "recommendation": "Replace expect() with proper error handling (Result types, error logging, graceful degradation). Handle database query failures without panicking. Add integration tests for race conditions."
+    },
+    {
+      "severity": "high",
+      "category": "dos",
+      "file": "openfut-core/src/services/season.rs",
+      "line": 69,
+      "cwe": "CWE-248",
+      "title": "Unguarded expect() in season fetch",
+      "description": "let season = fetch(pool, profile_id).await?.expect(\"season must exist\"); Panics if season is not found.",
+      "impact": "Server crash on missing or deleted season records.",
+      "exploitPath": "Delete a season via concurrent requests, then call /seasons endpoint. Server panics.",
+      "recommendation": "Return proper error (AppError::NotFound) instead of panicking."
+    },
+    {
+      "severity": "high",
+      "category": "dos",
+      "file": "openfut-core/src/services/season.rs",
+      "line": 144,
+      "cwe": "CWE-248",
+      "title": "Unguarded expect() in season update",
+      "description": "let updated = fetch(pool, profile_id).await?.expect(\"season must exist\");",
+      "impact": "Server crash on concurrent season modifications.",
+      "exploitPath": "Rapid concurrent season updates that fail race conditions.",
+      "recommendation": "Handle missing records gracefully."
+    },
+    {
+      "severity": "high",
+      "category": "cors",
+      "file": "openfut-core/src/app.rs",
+      "line": 257,
+      "cwe": "CWE-346",
+      "title": "Permissive CORS Configuration Allows All Origins",
+      "description": ".layer(CorsLayer::permissive()) enables CORS for all origins (*), methods, and headers. Any website can make cross-origin requests to the API and access/modify data.",
+      "impact": "Cross-site request forgery (CSRF) attacks. Malicious websites can issue API requests on behalf of users. Data exfiltration via JavaScript from any origin.",
+      "exploitPath": "Attacker website:\n  <img src=\"http://127.0.0.1:8080/clubs\" />\n  Fetch API calls to delete profiles, modify squads, etc.",
+      "recommendation": "Restrict CORS to specific origins (e.g., localhost:3000 for web UI, or the game process if exposed). Use CorsLayer::very_restrictive() as default and explicitly allowlist origins."
+    },
+    {
+      "severity": "high",
+      "category": "dos",
+      "file": "openfut-bridge/src/proxy.rs",
+      "line": 47,
+      "cwe": "CWE-248",
+      "title": "HTTP Client Construction Panic",
+      "description": ".expect(\"failed to build HTTP client\") will panic if the HTTP client fails to initialize, crashing the entire proxy service on startup.",
+      "impact": "Service unavailability. Bridge cannot start if HTTP client configuration is invalid.",
+      "exploitPath": "Invalid system configuration or missing TLS libraries causes HTTP client build to fail, crashing bridge during startup.",
+      "recommendation": "Return Result<ProxyState, Error> from new() and handle construction errors. Use anyhow::Context for better error messages."
+    },
+    {
+      "severity": "medium",
+      "category": "information-disclosure",
+      "file": "openfut-core/src/error.rs",
+      "line": 54,
+      "cwe": "CWE-209",
+      "title": "Error Messages Leak Implementation Details",
+      "description": "JSON parsing errors are returned directly to clients: format!(\"json parse error: {e}\"). Exposes serde_json parser internals and syntax details useful for crafting attacks.",
+      "impact": "Information disclosure. Attackers learn the JSON parser implementation and can tailor payloads to bypass validation or find parser-specific quirks.",
+      "exploitPath": "Send malformed JSON to any endpoint. Response includes parser error details (e.g., 'expected `,` at line 2 col 5') that aid in crafting exploits.",
+      "recommendation": "Return generic error message to clients: 'invalid request format'. Log detailed errors internally with tracing for debugging."
+    },
+    {
+      "severity": "medium",
+      "category": "information-disclosure",
+      "file": "openfut-core/src/error.rs",
+      "line": 40,
+      "cwe": "CWE-215",
+      "title": "Database Errors Logged with Full Details",
+      "description": "Database errors are logged with full SQL/query details: tracing::error!(\"Database error: {e}\"). If logs are exposed or compromised, schema, query patterns, and data structure are revealed.",
+      "impact": "Information disclosure in logs. Compromised log files expose database schema and query logic useful for SQL injection or data exfiltration planning.",
+      "exploitPath": "Access server logs (via log aggregation service, file access, etc.) and extract database schema and query patterns.",
+      "recommendation": "Log only error type and ID to clients. Sanitize logs before exporting. Use structured logging with field masking for queries."
+    },
+    {
+      "severity": "medium",
+      "category": "input-validation",
+      "file": "openfut-core/src/routes/auth.rs",
+      "line": 17,
+      "cwe": "CWE-1025",
+      "title": "Hardcoded Default Credentials",
+      "description": "Default username 'Player 1' is hardcoded with no unique identifier enforcement. Multiple profiles can be created with identical usernames, and weak defaults are used.",
+      "impact": "Weak account creation, potential for account confusion or conflicts. No strong identity guarantees.",
+      "exploitPath": "Multiple users create profiles with default 'Player 1' username. No way to distinguish profiles programmatically.",
+      "recommendation": "Require explicit username on profile creation. Use UUIDs as primary identifiers. Validate username uniqueness and minimum length."
+    },
+    {
+      "severity": "medium",
+      "category": "input-validation",
+      "file": "openfut-core/src/services/",
+      "line": 0,
+      "cwe": "CWE-400",
+      "title": "Missing Input Length Validation",
+      "description": "No maximum length checks on string fields (usernames, club names, squad names, etc.). Large inputs can cause database bloat, memory exhaustion, or DoS.",
+      "impact": "Denial of service via large payloads. Database bloat. Memory exhaustion. While DefaultBodyLimit::max(256KB) provides some protection, field-level validation is missing.",
+      "exploitPath": "POST /auth/local with username = 256KB string. Database receives bloated data. Repeated calls exhaust storage.",
+      "recommendation": "Add input validation for all user-submitted strings. Set maximum lengths (e.g., username: 50 chars, club name: 100 chars). Validate at route handler level."
+    },
+    {
+      "severity": "medium",
+      "category": "configuration",
+      "file": "openfut-core/src/db.rs",
+      "line": 13,
+      "cwe": "CWE-315",
+      "title": "Unencrypted SQLite Database on Disk",
+      "description": "SQLite database file (openfut.db) is stored unencrypted on disk. All user data, profiles, squads, cards, etc., are readable by anyone with filesystem access.",
+      "impact": "Data breach if server filesystem is compromised. No protection against:local file access, stolen backups, forensic recovery.",
+      "exploitPath": "Attacker gains filesystem access (compromised server, stolen disk). Reads openfut.db directly. All game data is readable without authentication.",
+      "recommendation": "Use SQLite encryption (e.g., sqlcipher crate) or migrate to PostgreSQL with TLS. Implement file-level encryption. Use restrictive filesystem permissions (0600)."
+    },
+    {
+      "severity": "medium",
+      "category": "rate-limiting",
+      "file": "openfut-core/src/app.rs",
+      "line": 0,
+      "cwe": "CWE-770",
+      "title": "No Rate Limiting on Endpoints",
+      "description": "No per-IP or per-user rate limiting. Endpoints like POST /auth/reset can be called repeatedly without restriction, allowing attackers to repeatedly wipe all data.",
+      "impact": "Denial of service and data destruction. Attacker can spam /auth/reset to destroy user data or exhaust server resources.",
+      "exploitPath": "for i in 1..1000: POST /auth/reset with confirm='reset'. All data wiped repeatedly.",
+      "recommendation": "Implement rate limiting middleware using tower_governor or similar. Add per-IP limits (e.g., 10 requests/min) and per-endpoint limits. Use exponential backoff."
+    },
+    {
+      "severity": "low",
+      "category": "audit-logging",
+      "file": "openfut-core/src/services/",
+      "line": 0,
+      "cwe": "CWE-778",
+      "title": "Missing Audit Logging",
+      "description": "No audit trail of user actions (profile creation, data deletion, squad modifications). Cannot detect unauthorized access, data tampering, or compliance violations.",
+      "impact": "Incident response and forensics are impossible. Cannot determine who did what and when. Compliance risks (GDPR, etc.).",
+      "exploitPath": "Attacker deletes all profiles, modifies squads. No audit log shows what happened or who did it.",
+      "recommendation": "Add audit logging for all data mutations. Log: timestamp, user (profile) ID, action, resource affected, before/after state. Store in separate immutable table."
+    },
+    {
+      "severity": "low",
+      "category": "dependencies",
+      "file": "openfut-bridge/Cargo.toml",
+      "line": 0,
+      "cwe": "CWE-1035",
+      "title": "Older Dependency Versions (reqwest, rustls)",
+      "description": "openfut-bridge uses reqwest 0.11 (latest is 0.12) and rustls 0.21 (latest is 0.23). Intentional for version matching, but creates a larger surface area for known CVEs.",
+      "impact": "Potential vulnerabilities in older dependencies. Delayed access to security patches.",
+      "exploitPath": "Known CVE in reqwest 0.11 or rustls 0.21 could be exploited. Combined with danger_accept_invalid_certs, TLS bypass becomes easier.",
+      "recommendation": "Upgrade dependencies to latest versions when possible. Monitor CVE databases (CVE, RustSec) for the versions in use. Pin versions and set up automated dependency updates."
+    },
+    {
+      "severity": "low",
+      "category": "error-handling",
+      "file": "openfut-core/src/app.rs",
+      "line": 256,
+      "cwe": "CWE-248",
+      "title": "Body Size Limit Without Per-Field Validation",
+      "description": "DefaultBodyLimit::max(256KB) limits the entire request body, but individual fields are not validated. A single large field can consume most of the limit.",
+      "impact": "Mild DoS. Large field values cause database bloat. Not a critical issue due to body limit, but field-level validation would be better.",
+      "exploitPath": "POST /auth/local with 250KB club_name field. Database receives bloated data.",
+      "recommendation": "Add per-field validation in addition to body limits. Validate and sanitize fields before database insertion."
+    }
+  ],
+  "riskScore": 82,
+  "riskCategory": "CRITICAL",
+  "riskSummary": "OpenFUT has critical security issues that would make it unsafe for production or networked deployment. The most severe are the complete absence of authentication/authorization and the SQL injection pattern in the auth.rs module. The system is designed as single-player (single-profile) with no multi-tenant isolation, which is dangerous if exposed to the network.",
+  "recommendations": [
+    {
+      "priority": "CRITICAL",
+      "area": "Authentication & Authorization",
+      "recommendation": "Implement JWT-based or session-based authentication on all endpoints. Add middleware to validate auth tokens on every request. Implement per-profile authorization checks. Currently any HTTP client can access all endpoints.",
+      "effort": "High",
+      "impact": "Blocks all data breaches from unauthenticated access"
+    },
+    {
+      "priority": "CRITICAL",
+      "area": "SQL Injection Prevention",
+      "recommendation": "Replace sqlx::query(&format!(...)) in auth.rs:87 with proper parameterized identifiers. Use sqlx::query_builder for dynamic table/column names instead of string interpolation.",
+      "effort": "Low",
+      "impact": "Prevents SQL injection even if pattern is copied to user input"
+    },
+    {
+      "priority": "HIGH",
+      "area": "TLS & Transport Security",
+      "recommendation": "Remove .danger_accept_invalid_certs(true) from proxy.rs:44. If development requires it, gate behind an environment variable (e.g., DEV_SKIP_TLS_VERIFICATION) with strong warnings in logs.",
+      "effort": "Low",
+      "impact": "Prevents MITM attacks on bridge-to-core communication"
+    },
+    {
+      "priority": "HIGH",
+      "area": "Error Handling",
+      "recommendation": "Replace all expect() calls with proper Result handling. Use anyhow::Context or custom error types. Add logging for debugging but return generic errors to clients.",
+      "effort": "Medium",
+      "impact": "Prevents DoS via server panics"
+    },
+    {
+      "priority": "HIGH",
+      "area": "CORS",
+      "recommendation": "Replace CorsLayer::permissive() with CorsLayer::very_restrictive() or explicit allowlist. For single-player use, restrict to localhost and the game process only.",
+      "effort": "Low",
+      "impact": "Prevents CSRF and cross-origin attacks"
+    },
+    {
+      "priority": "HIGH",
+      "area": "Rate Limiting",
+      "recommendation": "Add per-IP rate limiting using tower_governor or similar. Implement limits on destructive endpoints (e.g., POST /auth/reset: 1 request per hour per IP).",
+      "effort": "Medium",
+      "impact": "Prevents DoS and repeated data destruction"
+    },
+    {
+      "priority": "MEDIUM",
+      "area": "Input Validation",
+      "recommendation": "Add maximum length validation for all string fields (username, club_name, squad_name, etc.). Enforce at route handler level. Example: username max 50 chars, club_name max 100 chars.",
+      "effort": "Medium",
+      "impact": "Prevents database bloat and data validation failures"
+    },
+    {
+      "priority": "MEDIUM",
+      "area": "Data Encryption",
+      "recommendation": "Use SQLite encryption (sqlcipher) or migrate to PostgreSQL with TLS. Set restrictive filesystem permissions (0600) on openfut.db.",
+      "effort": "High",
+      "impact": "Protects data at rest from filesystem access"
+    },
+    {
+      "priority": "MEDIUM",
+      "area": "Error Message Handling",
+      "recommendation": "Return generic error messages to clients. Log detailed errors internally. Example: client sees 'invalid request', server logs 'JSON parse error: expected `,` at line 2'.",
+      "effort": "Low",
+      "impact": "Reduces information disclosure"
+    },
+    {
+      "priority": "MEDIUM",
+      "area": "Audit Logging",
+      "recommendation": "Add audit trail for all data mutations (create, update, delete). Log timestamp, profile ID, action, resource, and before/after state. Store in immutable audit_log table.",
+      "effort": "Medium",
+      "impact": "Enables incident response and forensics"
+    },
+    {
+      "priority": "LOW",
+      "area": "Dependency Management",
+      "recommendation": "Upgrade reqwest to 0.12 and rustls to 0.23 when possible. Set up Dependabot or RustSec monitoring for CVEs. Regularly audit dependencies.",
+      "effort": "Low",
+      "impact": "Reduces attack surface from known CVEs"
+    },
+    {
+      "priority": "LOW",
+      "area": "Default Values",
+      "recommendation": "Remove hardcoded default username 'Player 1'. Require explicit username on profile creation. Use UUIDs for profile identification.",
+      "effort": "Low",
+      "impact": "Improves account identity and prevents confusion"
+    }
+  ],
+  "securityDesignNotes": {
+    "intendedUse": "OpenFUT is designed for single-player offline use. Single-profile design is intentional for local FIFA 23 emulation.",
+    "deploymentContext": "Localhost only (127.0.0.1:8080). Not intended for networked or multi-user deployment.",
+    "implicationForSecurity": "Many security issues (no auth, permissive CORS) are acceptable for localhost-only use. However, the code structure lacks security boundaries, so if ever exposed to the network, it would be completely unsecured. Recommend adding security gates now rather than retrofitting later.",
+    "suggestedDefensiveApproach": "Even for single-player use, add security layers (basic auth, CORS restrictions, rate limiting) to prevent accidental misuse if deployed in an unsafe context."
+  },
+  "positiveFindingsAndStrengths": [
+    "✓ SQLx is used throughout with parameterized queries (except auth.rs:87)",
+    "✓ Foreign key constraints are enforced in SQLite",
+    "✓ UUIDs are used for entity IDs instead of sequential IDs (reduces enumeration attacks)",
+    "✓ Request body size is limited to 256KB (prevents large payload DoS)",
+    "✓ Concurrency is limited to 256 concurrent requests",
+    "✓ Sensitive tokens (X-UT-SID, X-UT-PHISHING-TOKEN) are stripped from captures",
+    "✓ Logging is structured using tracing crate (good for audit trails)",
+    "✓ Services layer properly encapsulates database access"
+  ],
+  "testingRecommendations": [
+    "Add integration tests for authentication bypass (attempt to access endpoints without tokens)",
+    "Test SQL injection payloads in auth.rs:87 pattern (if table names become dynamic)",
+    "Test CORS with cross-origin requests from external origins",
+    "Test rate limiting with rapid concurrent requests to /auth/reset",
+    "Test input validation with oversized strings (100MB+ usernames)",
+    "Test panic handling with corrupted database state",
+    "Test TLS MITM scenarios (certificate pinning validation)",
+    "Add fuzz testing for JSON parsing to find edge cases"
+  ],
+  "complianceNotes": {
+    "gdpr": "No explicit data handling policy. If user data is processed, GDPR requires consent, data retention limits, and audit trails. Not currently implemented.",
+    "dataProtection": "Unencrypted database at rest violates most data protection frameworks.",
+    "logging": "Audit logging is missing, violating compliance requirements."
+  }
+}

docs/CARD_TAXONOMY.md

@@ -0,0 +1,142 @@
+# FIFA 17 FUT — Card Taxonomy (single source of truth)
+
+Status: verified 2026-08-12. This document supersedes every earlier scattered
+taxonomy claim in the repo (see "Superseded taxonomy" at the bottom).
+
+Evidence labels: **OBSERVED** = read directly from a shipped table or decompiled
+function; **INFERRED** = derived from OBSERVED facts; **HYPOTHESIS** = plausible,
+not yet proven. `UNKNOWN` is a valid answer and is stated as such.
+
+## Provenance
+
+- Authoritative tables: `10.10.0.105:/home/alex/Documents/OpenFUT/fifa17-recon/data/tables/`,
+  copied byte-identical into this repo at `fifa17-recon/data/tables/`.
+  SHA-256 manifest + verification: `docs/evidence/fifa17-recon/table-hashes.sha256`
+  (36 files: 31 `fcc_*.json` + 5 staff tables; combined hash-of-hashes
+  `10f239add919089354d8dbff873fc9737b0a0f80f6ac41b1aa2a096c0ec8d331`).
+- Each table file is a DECODED dump `{table, source, rowcount, schema[], rows[]}`;
+  card instances are in `rows[]`, one object per card. Row counts and id ranges
+  below were re-extracted from the in-repo `.120` copies.
+- Semantic (subtype→kind) labels are decompiler-derived, carried in
+  `fifa17-recon/tools/fut_consumables.py` (`BY_SUBTYPE`, `_DOC`), generated by
+  `tools/build_consumables.py` from `FUN_1800d8330`, `FUN_18013f4d0`,
+  `FUN_1801bfac0`, `FUN_1801aa230`, `FUN_180048780` + the fcc tables.
+- Staff family selection: `fifa17-recon/docs/CARD_SYSTEM.md` (2026-08-04/05 blocks)
+  and `fifa17-recon/tools/fut_staff.py` / `fut_coaches.py`.
+
+## Family selector (OBSERVED, binary)
+
+Before registering an item, `FUN_180141660` merges the client's local DB. It
+switches on record `+0x4c` (`cardtype`), which `FUN_1800d8330` derives from JSON
+atom `0x6c cardsubtypeid` alone:
+
+```
+cardsubtypeid 0..3 -> cardtype 1   players
+              4    -> cardtype 2   managercards
+              5    -> cardtype 3   headcoachcards
+              6    -> cardtype 10  gkcoachcards
+              7    -> cardtype 5   physiocards
+              8    -> cardtype 4   fitnesscoachcards
+              0x1e,0x1f,0x91..0x96,0xe7..0xe9,0xec -> cardtype 9  club items + misc
+              absent (default 342) -> cardtype 0   no merge
+```
+
+Key: `carddbid == resourceId` for non-player families (queried RAW, no mask);
+players are queried by `playerid = resourceId & 0xffffff` (atom `0x287`), and
+`assetId` (atom `0x23`) is never read by the merge.
+
+## Consumable & staff families — evidence table (OBSERVED, `.120` tables)
+
+| Family | Table | Rows | carddbid range | cardsubtype set | cardassetid (ART) |
+|---|---|---|---|---|---|
+| Contracts | `fcc_contractcards.json` | 13 | 5001001–5001013 | {201, 202} | {7, 8} |
+| Fitness + Healing | `fcc_healingcards.json` | 27 | 5002001–5002030 | {211,212,213,215,216,217,218,219,220} | {9, 10} |
+| Training (6 sub-families) | `fcc_trainingcards.json` | 143 | 5003001–5003159 | 51-57, 61-67, 91-110, 121-136, 250-273, 300-340 | {1,3,32,34,35,50,51} |
+| Misc | `fcc_misccards.json` | 42 | 5004001–5004042 | {231, 232, 233, 236} | {43, 44, 45, 46} |
+| Badges | `fcc_badgecards.json` | 656 | 6000000–6000656 | (none in row) | {39} |
+| Stadiums | `fcc_stadium.json` | 78 | 6200000–6200077 | (none in row) | {36} |
+| Kits | `fcc_kitcards.json` | 1482 | 6300000–6400654 | (none in row) | {35} |
+| League logos | `fcc_leaguelogos.json` | 44 | 8010000–8010044 | (none in row) | {40} |
+| League logo stickers | `fcc_leaguelogostickers.json` | 39 | 8010000–8010039 | (none in row) | {40} |
+| Balls | `fcc_balls.json` | 42 | 8120194–8120236 | (none in row) | {37} |
+| Managers | `managercards.json` | 417 | 1000001–1001552 | (staff; by cardsubtypeid 4) | (assetid col) |
+| Head coaches | `headcoachcards.json` | 124 | 2000004–2000328 | (staff; subtype 5) | — |
+| GK coaches | `gkcoachcards.json` | 121 | 9000001–9000324 | (staff; subtype 6) | — |
+| Physios | `physiocards.json` | 51 | 4000002–4000259 | (staff; subtype 7) | — |
+| Fitness coaches | `fitnesscoachcards.json` | 115 | 3000019–3000328 | (staff; subtype 8) | — |
+
+Notes:
+- **Contracts (5001xxx)** — 201 = player_contract, 202 = manager_contract
+  (OBSERVED, `BY_SUBTYPE`).
+- **Fitness + Healing (5002xxx)** — subtype **214 is a valid enum value but ships
+  ZERO rows** (OBSERVED: 214 absent from `rows[]`). Enum split (OBSERVED,
+  `BY_SUBTYPE`): healing = 211-218, player_fitness = 219, squad_fitness = 220.
+  The `+0x58 rareflag == 1` trap flips subtype 219 to squad-fitness.
+- **Training (5003xxx)** — SIX sub-families, all OBSERVED in `rows[]` and labelled
+  in `BY_SUBTYPE`:
+  - `gk_training` 51-57 (7)
+  - `player_training` 61-67 (7)
+  - `position_mod` 91-110 (20)
+  - `formation_mod` 121-136 (16)
+  - chem/play styles 250-273 (24): `player_playstyle` 250-268 (19) +
+    `gk_playstyle` 269-273 (5)
+  - `manager_league` 300-**341** in the client enum (42), but the shipped table
+    contains only 300-340 (41 rows) — 341 is defined, not shipped.
+  - Client enum also defines vestigial/unshipped ranges NOT in the table:
+    `manager_formation_mod` 71-86, and `DEAD_ZONE`
+    58-60,68-70,87-90,111-120,203-210 (28). These have no rows.
+- **Misc (5004xxx)** — subtypes {231,232,233,236}; cardassetid ART 43-46.
+  cardsubtype 231 = 0xe7 anchors the 0xe7..0xe9 block to misc via `FUN_1800d8330`.
+- **Club items (badges/stadiums/kits/logos/balls)** carry no `cardsubtype` in the
+  row; they are keyed by `carddbid` range and distinguished on the wire by ART
+  `cardassetid` (badges 39, stadium 36, kits 35, logos 40, balls 37). **Kits live
+  at 6300000–6400654 and are NOT badges** (badges are 6000xxx). The client-side
+  subtype→family map (which of 0x1e,0x1f,0x91..0x96 is ball vs stadium vs badge vs
+  kit) is **UNKNOWN** — it is in none of the dumped tables and cardtype 9 has no
+  miss-fill arm (see `CARD_SYSTEM.md`, "Club items", 2026-08-05).
+
+## Staff — subtype/cardtype selectors (OBSERVED, binary)
+
+| cardsubtypeid | cardtype | Family | Table | Rows | carddbid range |
+|---|---|---|---|---|---|
+| 4 | 2 | Manager | `managercards.json` | 417 | 1000001–1001552 |
+| 5 | 3 | Head coach | `headcoachcards.json` | 124 | 2000004–2000328 |
+| 6 | 10 | GK coach | `gkcoachcards.json` | 121 | 9000001–9000324 |
+| 7 | 5 | Physio | `physiocards.json` | 51 | 4000002–4000259 |
+| 8 | 4 | Fitness coach | `fitnesscoachcards.json` | 115 | 3000019–3000328 |
+
+`cardsubtypeid -> rec+0x50` is the only family selector; `FUN_1800d8330` maps it to
+`rec+0x4c cardtype`. Manager merge = `FUN_1801356c0` (queries `managercards` by
+`carddbid` raw); coach merges live in the respective tables (`fut_coaches.py`).
+All five render live with real photos/bonuses, zero "DB Error" (CARD_SYSTEM.md,
+2026-08-05).
+
+## Players (context, out of taxonomy scope here)
+
+Players use cardsubtypeid 0..3 -> cardtype 1; merged by `playerid = resourceId &
+0xffffff` against the local `players` table. Identity/name/nation/team come from
+the client DB; rating/position/attributes come from our item JSON. See
+`CARD_SYSTEM.md` and the migration work in `openfut-adapter-fifa17`.
+
+## Superseded taxonomy (report only — no other files edited)
+
+The earlier working taxonomy (in prior agent-session notes / long-term memory, and
+partially in the original `TablesTaxonomy` scout output) got four things wrong.
+Corrected here:
+
+1. **Chemistry / play styles are 250-273, NOT 91-136.** 91-110 = `position_mod`,
+   121-136 = `formation_mod`. (OBSERVED in `fcc_trainingcards` + `BY_SUBTYPE`.)
+2. **6300xxx/6400xxx are KITS, not badges.** Badges are 6000xxx. (OBSERVED.)
+3. **5004xxx misc cards exist** (subtypes 231/232/233/236, ART 43-46). Previously
+   omitted. (OBSERVED, `fcc_misccards`.)
+4. **8010xxx league logos exist** (+ stickers), ART 40. Previously omitted.
+   (OBSERVED, `fcc_leaguelogos`.)
+
+**Repo blast-radius of the superseded values: NONE.** A repo-wide grep
+(`docs/`, `openfut-adapter-fifa17/`, `openfut-core/`, `fifa17-recon/`) for the wrong
+claims (`91-136` chem styles; `6300/6400xxx` as badges) returns zero hits.
+`fifa17-recon/docs/CARD_SYSTEM.md` and `plan-2026-08-06-card-subsystem.md` already
+use the correct `250..273` for chem styles and the correct staff subtypes 4-8;
+`CARD_SYSTEM.md` is a mechanism log, not a taxonomy, and asserts none of the wrong
+ranges. The superseded values therefore live only in non-repo agent memory, which
+should be corrected to point at this document.

docs/PROJECT_STATE.md

@@ -0,0 +1,192 @@
+# OpenFUT — Project State
+
+> **Canonical source:** `../OpenFUT-Vault/06 Agent Memory/Project State.md`
+> This file is a mirror. If the two disagree, the vault wins. Update the vault first.
+
+Factual snapshot. Prefer this over the stale root `README.md`/`CLAUDE.md` status tables (FIFA 23).
+Last compiled from repository evidence during context initialization.
+
+## Working
+
+- **FIFA 17 offline FUT stack, end-to-end.** Proven 2026-08-01: auth → Blaze login → device-trust →
+  the FUT hub. Brought up by `fifa17-recon/tools/openfut-fut.sh start`. Evidence: `FUT-RUNBOOK.md`,
+  `fifa17-recon/README.md`, the five responder scripts, gate-ladder troubleshooting table.
+- **ProtoSSL cert-pin defeat** — two live `/proc/PID/mem` patches (`autopatch.py`), VAs stable
+  across launches. gdb-verified which gate was the wall.
+- **LSX / Origin layer** — crypto handshake reversed byte-exact and confirmed against the repack's
+  own emu disassembly (`docs/REPACK_INTEL.md`); Origin login gates cleared.
+- **Blaze redirector + Fire2/Heat2** — both hops defeated; preAuth/login/personas answered.
+- **UTAS/RS4 FUT API** — `ut/auth` + boot calls + device-trust reach the hub with hand-authored JSON.
+- **Persistent FIFA 17 account selection** — the launcher synchronizes one configured EA persona to
+  the Python backend before starting LSX/FIFA. LSX, Blaze, POW/EASFC, and UTAS then share that
+  identity, while FUT coins, inventory, squads, progression, and unopened packs persist in an
+  isolated save beneath `fifa17-recon/docker/state/accounts/<persona-id>/`. The POW level/XP/funds
+  shown in FIFA's general account bar are account-scoped but remain distinct from FUT club coins.
+  A reversible server test on 2026-08-09 verified profile switching, POW values, a 400-coin pack
+  debit, five awarded items, and restoration of the original profile.
+- **Account-scoped FUT security compatibility** — launcher account synchronization initializes a
+  persisted `securityQuestion` verification record in that persona's FIFA 17 profile. The UTAS
+  PHISHING handler returns the complete CardsDLL trusted-console response (`changed`, `exists`,
+  `locked`, `trusted`), accepts only well-formed legacy setup/validate requests under `X-UT-SID`,
+  and never stores or logs the client-transformed answer. This is server-side emulation; the hook
+  and launcher do not contain an answer or add UI automation. Automated contract coverage is in
+  `fifa17-recon/docker/ctx/tools/test_security_question.py`; live first/repeat-launch acceptance is
+  partially complete: the first launch entered FUT without a security dialog on 2026-08-09; a
+  second fresh-process FUT entry is still required to close persistence acceptance.
+- **Safe responder diagnostics** — ordinary LSX logs redact challenge/session/auth-code attributes;
+  ordinary Blaze logs redact auth/session keys and no longer emit raw Fire2 hex, decoded TDF, or
+  config values. Forensic Blaze capture remains available only with the explicit
+  `OPENFUT_BLAZE_DUMP_FRAMES=1` opt-in. LSX and Blaze self-tests cover the new defaults.
+- **OpenFUT Core** — Rust FUT economy backend, feature-complete for its scope and tested: profiles,
+  clubs, coins, packs, cards, squads, chemistry styles, SBCs, objectives, matches, market (NPC),
+  draft, FUT Champs, seasons, statistics, achievements, events, daily check-in, division
+  leaderboard, market trade history. 13 migrations. Integration suite (`tests/integration_test.rs`,
+  96 test fns) runs against in-memory SQLite; CI (fmt/clippy/build/test) green on `openfut-core`.
+
+## Partially implemented
+
+- **FIFA 17 FUT hub depth** — reaching the hub is proven, but how much of FUT is fully navigable
+  beyond it (playing matches, pack opening, SBC submission through the *game* UI vs. spinner/error
+  states) is not documented as complete. The runbook's gate ladder lists failure modes still
+  guarded against. Treat "past the hub" as unverified.
+- **Pack opening through the game UI** — proven live on 2026-08-09 with the recovered CAGE test
+  profile: purchase, reveal, item assignment/quick-sell, wallet refresh, and return from the reveal
+  all completed. The Python transaction path also passes its 446-check contract suite. FIFA's
+  hardcoded post-reveal `mypacks` return is supported by a short-lived active grace record for every
+  opened pack; it is excluded from unopened-pack counts and retired at the next hub request.
+- **FIFA 17 FUT match lifecycle** — CardsDLL static analysis and isolated responder tests now cover
+  CREATE→READY→PLAY→END. Bare `/match` requests carrying body `matchId` are classified as PLAY
+  instead of accidentally allocating another match; READY returns the verified scalar `matchId`
+  and `opponentPersonaId` fields; END persists W/D/L, matches played, and coin rewards per account.
+  The implementation is deployed and `test_match_lifecycle.py` passes, but no football match has
+  started or completed in FIFA yet. The READY opponent `items` contract and client mode-entry gate
+  remain unresolved; `FUT_MODES` therefore stays off by default.
+- **Core ↔ emulation integration** — the two halves exist and wiring has **started**. First
+  slice (2026-08-11): the My Squad owned-player search. `openfut-core` gained a semantic,
+  game-independent owned-inventory query (`services::inventory::{OwnedItemQuery, apply_query}`
+  + a `Quality` tier) that filters (AND) → orders deterministically → paginates, wired into
+  `GET /collection`; `openfut-adapter-fifa17::fut::owned_query` parses the FIFA17 `/club` wire
+  query and resolves numeric league/nation/team ids → semantic names (unknown id = hard error,
+  no raw-id passthrough). Intentional fix, not parity: Python applies only `league`+`team` and
+  ignores `level`/`rare`/`position`/`nation`/`start`/`count` (the request-amplification bug);
+  Core applies all proven filters and paginates. `rare=SP` semantics UNKNOWN, unimplemented.
+  Slice 2 (2026-08-11): `openfut-utas-host` — the first live UTAS host. Serves `GET …/club`
+  from Core through the adapter and reverse-proxies every other UTAS route verbatim to the
+  Python oracle (`utas_server.py`); plaintext HTTP/1.1 keep-alive, classify-before-execute,
+  no python-fallback after a Core error. `CoreAccess` is a host-owned boundary (the adapter
+  stays transport-agnostic). 11 host + 22 adapter tests; 10/10 mutations killed; fmt/clippy
+  clean. Slice 3 (2026-08-11, `3ef3bc3`): the real `Fifa17IdentityResolver` — catalog
+  (card id → real asset id) + persistent `openfut-identity` store (owned instance →
+  stable/reversible wire int) + wire-id policy, replacing all placeholders (one
+  production path). Wire-id namespace is globally monotonic within `(fifa17, owned-item)`,
+  not per-account (Core owned ids are UUIDs → unambiguous reverse). Slice 4 (2026-08-11,
+  core `36abd4b`): a curated 32-card real FIFA17 dev content pack
+  (`data/games/fifa17/dev/cards.json`, ids `fifa17_<asset>`), loaded only via opt-in
+  `Config.dev_content_games`; `seed-dev` grants a `game_id=fifa17` profile+club real
+  `OwnedCard`s (no FIFA wire ids — the resolver mints those at request time), idempotent,
+  default content untouched. Slice 5 (2026-08-11, `5276dd2`): the host sends
+  `X-OpenFUT-Game: fifa17` so `/club` resolves the all-mapped fifa17 profile —
+  **composition proven live** over HTTP (real Core+host, no FIFA client): FIFA wire query
+  → real `resourceId`s (catalog) + stable/reversible wire `id`s (store); 33 renderable,
+  gold=22, Premier League=18, pagination page1=11/page2=7/overlap=0 (clean paging, no
+  drops). **The only remaining gate is the live retail FIFA A/B** (no FIFA client in the
+  build env; runbook `openfut-utas-host/README.md`). See the vault UTAS Endpoint Map +
+  Known Issues (incl. "identity resolution is NOT authorization" for later mutations).
+  **Slice 6 (2026-08-11): `/club` RUNTIME VALIDATED on retail FIFA 17** — operator-assisted
+  live A/B (`.105` client → `.120` backend via a source-scoped NAT redirect into a staged
+  `36abd4b` Core + `openfut-utas-host`). Every checkpoint passed on the real client:
+  transport, per-route Python fallback, Python-negative `/club`, Core `X-OpenFUT-Game`
+  scoping, real card + persistent owned-item identity (incl. the two-copy fixture),
+  no-filter/Gold/position/nation/league/team/combined-AND filtering, retail pagination
+  with no amplification, card selection, identity stability across relaunch, Python
+  rollback, and Rust re-enable (identity store byte-identical across the cycle, 0
+  reallocation). Live findings: the retail client steps `start += 10` with `count=11`
+  (sometimes bulk `count=100`) — Core honours `offset` and terminates; the My Club UI
+  nests team under league; the "~1900" club counter is Python `userMassInfo`, not `/club`.
+  Remaining is operational only (promote the staged stack to a durable deployment).
+- **Slice 7 (2026-08-12): FUT squad authority (read + write) RUNTIME VALIDATED on retail FIFA 17.**
+  Staged operator-assisted A/B (`.105` retail client → `.120`, source-scoped utas switch
+  `:8099→:8199` into `openfut-utas-host` over a staged `615c5fd` Core seeded by `seed-dev` with the
+  dev 33-card inventory). FIFA itself consumed the Rust squad path end-to-end: FUT boot served
+  `RUST_OVERLAY userMassInfo` (squad overlay) and the squad screen rendered the dev XI; a controlled
+  in-game squad edit issued `PUT …/squad/0` → host `squad-replace` → Core → `{"id":0}`; an in-game
+  formation change f442→f433 persisted to Core (canonical fingerprint changed, `position_index`
+  remapped 0–10); a FULL FIFA relaunch cold-fetched and rendered the persisted f433 squad (no client
+  cache). Reversibility proven on the exact client path by log presence, not response data (both
+  backends coincidentally hold the same dev squad — the Python oracle `fifa17_profile.json` was
+  seeded from the same `squad_put_f442.json` capture): disarmed `.105:8099` reached Python (absent
+  from host log), re-armed reached Rust (`route=club limit=Some(9)` present); the persistent identity
+  store survived the cycle with 0 reallocation. Non-migrated routes (`/ut/auth`, `account/sync`,
+  `accountinfo`, `settings`, `hub`, store txn) correctly Python-fallback. NEW startup requirement:
+  the Core server loads dev card defs only for games in env `OPENFUT_DEV_CONTENT_GAMES` (comma-sep);
+  omitting `fifa17` makes `get_collection` silently drop every owned card (empty `/collection`,
+  "no squad") despite a successful seed — MUST become a deployment/preflight assertion. Preceded the
+  same day by a staged two-process parity gate (real Core+host over HTTP, no FIFA) confirming byte-
+  shape parity of `userMassInfo.squad` vs the captured oracle. Next milestone: real-data Core
+  import / profile strategy → production Rust UTAS. Blaze deferred.
+- **Slice 8 (2026-08-12): REAL-DATA staged retail A/B PASS (import + club + squad).** The real FIFA 17
+  profile was imported into a staged Core via the two-store protocol (`openfut-import-fifa17 --apply`:
+  generic transactional Core import + `openfut-identity` seeding, idempotent), then FIFA itself
+  consumed it end-to-end over the source-scoped utas switch (`.105`→`.120:8199`). Imported population
+  1949 of 1962 player instances (13 Legend/special assets deferred as unnameable — 9 NoName + the 4
+  copies of `169193`), every original Python wire id preserved (set-equal, 0 minted/dropped), each
+  owned instance an opaque Core UUID. On the retail client: real club rendered (1949, not the 33-card
+  dev XI); `/club` pagination clean (paged==full, no loop/overlap/drop); the `Special` quality filter
+  returned only specials (1665, 0 base leaked) and paginated the filtered set; a squad edit persisted
+  to Core (canonical + opaque extension atomically, fingerprint recomputed) and survived a full cold
+  relaunch; rollback→Python→Rust re-enable proven on the exact client path (disarm reached Python,
+  re-arm returned the imported club + edited squad; identity store 0 reallocation). Three real-data
+  fidelity gaps the base-only dev fixture had hidden were found on the live client and fixed:
+  (1) `e187cd4` versioned `resourceId` — `shape_item` emitted the base assetId as `resourceId`,
+  collapsing every special onto its base card art; `Fifa17Identity` now carries the versioned
+  `resource_id`. (2) `626c972` observed `rareflag` — `shape_item` hardcoded `rareflag=1`, so all
+  specials rendered as basic rare; `rareflag` now flows through the FIFA catalog and onto the wire
+  (wire distribution == source exactly). (3) `6f16a23` `rare=SP` Special filter — previously a no-op
+  ("semantics UNKNOWN"), now grounded as `rareflag > 1` and applied host-side (Core has no rareflag).
+  Also `44fcf24`: nation/league/team proven to be INSTANCE metadata (not definition identity — the 4
+  copies of `169193` are identical but for club), so the definition-consistency gate now compares
+  identity only (no `--defer-conflict` needed; no majority-vote). PRODUCTION NOT READY: the 13 deferred
+  Legends are unnameable from the `.120` client dump (absent/placeholder in `players.json`; DLC/Legends
+  name tables empty) — honest names require the FIFA 17 Legends locale data from the `.105` client.
+  Next: resolve the 13 names → re-import to 1962/0 → full-fidelity gate → gitlink reconcile →
+  production Rust UTAS.
+
+## Stubbed / planned
+
+- **`fifa-blaze`** (Rust) — Milestone 1 capture stub only. Two TLS listeners that log packets; no
+  FIFA 23 component/command handlers. Its own README says IDs are unknown. Superseded in practice by
+  the Python FIFA 17 responders, kept as the intended FIFA 23 implementation surface.
+- **`openfut-launcher` legacy controls** — core/bridge and FIFA 23 setup controls belong to a
+  superseded plan. The launcher now also owns the live FIFA 17 client flow: server/hook config,
+  account synchronization, local LSX, privileged autopatch, and game launch.
+- **`tools/`** (file-watch-diff, squad-injector, exporters) — helpers for the FLE-Lua-bridge idea in
+  `docs/direction.md`. Not part of the live FIFA 17 path.
+- **`docs/foundational-xi-injection-test.md`** — a planned (not executed) test procedure for the FLE
+  bridge route.
+
+## Stubbed / blocked (FIFA 23 lineage)
+
+- **`openfut-bridge`** — in-process `version.dll` hook on ProtoSSL. Git history: injection works but
+  the effort hit an "architectural wall" (async event-driven gate, not a poll). Superseded first by
+  the FLE-bridge pivot, then by the FIFA 17 route. Its `CLAUDE.md` task list is historical.
+
+## Unknown / requires investigation
+
+- Whether the FIFA 17 hub supports actually **playing a FUT match** offline and getting results back.
+- Whether FUT actions beyond the now-verified pack reveal/assignment flow (submit SBC, transfer
+  market buy/sell, matches) round-trip correctly through `utas_server.py`.
+- The exact division of FUT state ownership once Core is wired in (who is source of truth).
+- Degree of FIFA 23 wire-format identity — asserted ("identical wire format") but the FIFA 23 client
+  has not been re-tested against these responders in this repo's evidence.
+
+## Known technical debt / hazards
+
+- **Root docs are stale.** `README.md`, `CLAUDE.md`, `openfut-bridge/CLAUDE.md` all describe FIFA 23
+  as the target and mark FIFA 23 integration as the open item — they predate the FIFA 17 success.
+- **All host state is volatile** across reboot except the `/etc/hosts` line — re-run
+  `openfut-fut.sh start`. Requires `ptrace_scope=0` + root arming (security-relevant).
+- **Whole stack rides on EAAC staying neutralized** and game updates being off; a client update can
+  break the memory patches (VAs) and cert bypass.
+- **`fifa17-recon/tools/lsx_responder_v2.py` is currently modified in the working tree** (uncommitted).
+- `33068179` / `CAGE` remains the responder fallback, but the launcher now blocks one-button launch
+  until an explicit persona is configured and synchronized across LSX, Blaze, POW, and UTAS.

docs/evidence/FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md

@@ -0,0 +1,443 @@
+# FIFA 17 — Empty "My Packs" Client Contract (store/purchasegroup)
+
+> **STATUS (2026-08-13): ROOT CAUSE ESTABLISHED; P2 backend compatibility workaround
+> IMPLEMENTED.** Root cause: FIFA 17's Store/Scaleform path resolves the `mypacks`
+> category even with zero unopened packs, and CardsDLL `FUN_1800147f0` assumes the
+> resolved group is non-null (crash if absent). Backend decision: **P2** — emit an
+> **active** non-openable synthetic `mypacks` placeholder (id 65534) when
+> `unopenedPackIds == []` (`fifa17-recon/tools/utas_server.py` `store_catalog`; tests
+> `fifa17-recon/tools/test_empty_mypacks.py`). Crash-safe + economy-safe; known UX
+> limitations (fake tile, click-dialog, Browse→My-Packs nav quirk) are Scaleform-driven
+> and require the client-side fix in `docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md`.
+> This is a FIFA-17-specific compatibility shim, NOT an EA-authentic representation,
+> and is confined to the FIFA-17 adapter/backend (NOT OpenFUT Core).
+
+Evidence labels: **OBSERVED** (runtime capture / crash dump / already-decompiled RE
+quoted in-repo), **INFERRED**, **HYPOTHESIS**, **UNKNOWN**. No server behavior is
+changed by this document; it is analysis only.
+
+Binaries (hashes verified 2026-08-13 on `.105`):
+`CardsDLL_Win64_retail.dll` SHA-256 `4706a881ae1fc7b5769fd810b25a868d29d2b16a8e65a7513436327ef645573c`
+(load base in the crash dump `0x00006FFFFC120000`; RE-space base `0x180000000`).
+`FIFA17.exe` SHA-256 `29c31cef12b0c3c2a7305220617c7b4fa139ab76b8c857851bdbe88987962899` (packed).
+
+## 1. Question
+
+How must the server represent an account that owns **zero unopened packs** in
+`GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true` so that FIFA 17 neither
+(a) crashes nor (b) shows "The pack you've selected is currently not available",
+**without granting the user a real/openable pack** and without breaking the normal
+bronze/gold/special store? The current OpenFUT answer (a synthetic inactive `mypacks`
+sentinel) only downgrades a crash to a dialog; it is not the correct contract.
+
+## 2. Established experimental behavior (OBSERVED)
+
+Profile-state ladder, all with normal packs 1/5/6/7 unchanged:
+
+| profile `unopenedPackIds` | `mypacks` group in response | client outcome |
+|---|---|---|
+| `[]` (baseline) | one **inactive** sentinel pack `65534`, empty description | "pack not available" dialog → FUT Hub |
+| `[70]` (Exp A) | one **active** real owned pack `70` | **store works**; My Packs visible |
+| `[]` + sentinel suppressed (Exp B) | **no `mypacks` group at all** | **client CRASH** |
+
+Captures: `store_purchasegroup_capture_2026-08-12.json` (baseline),
+`…_mypacks70_2026-08-12.json` (A), `…_empty_no_sentinel_2026-08-12.json` (B).
+Details in `STORE_TILE_6C.md` §14-§15.
+
+## 3. Existing RE evidence (from `docs/plan-2026-08-05-store-subsystem.md`, decompiled)
+
+All addresses RE-space (CardsDLL base `0x180000000`):
+- **`FUN_18013af30`** — per-element pack deser; each `purchase[]` entry → a `0x158`
+  wire record. `displayGroup.value`(atom 0x377) → record `+0x00` (ctor default the
+  literal `"unknown"`). `displayGroup.priority`(0x250) → `+0x34`.
+  (store-subsystem §"wire record", :996.)
+- **`FUN_1800150d0`** — group builder. Walks `purchase[]` in array order; for each
+  pack, finds-or-creates a `0x108` display group by **exact strcmp of
+  `displayGroup.value` against `group+0x70`** (`FUN_180014380`). New group
+  (`FUN_180012950`): `+0x00` = 1-based ordinal (groups-so-far+1), `+0x100` =
+  priority, **`+0x104` = (value == "mypacks")**, `+0x40` = vector of `0x1a8` tile
+  models. Pack→tile via `FUN_18002c3c0`. (:152-161, :1042-1049.)
+- **`FUN_1800147f0`** — group **resolver/renderer**, called as
+  `FUN_1800147f0(model, screen+0x290, dataProvider, 0, 0)` from `FUN_18007dab0`.
+  `screen+0x290 == 0` → "list the group tiles" (`FUN_180014610`); **any other value
+  → `FUN_180014420`, which exact-matches `group+0x00` (the ordinal) and returns NULL
+  on a miss, after which `FUN_1800147f0` dereferences `[RAX+0x40]` with NO guard**
+  ("checked in raw disassembly … a real absence"). **"The only legal category values
+  are 0 and the ordinals 1..N."** (:163-169, :1051-1054.)
+- **`FUN_180014580`** — the six-tab bar: switch 0..5 over the hardcoded lowercase
+  literals `mypacks, points, bronze, silver, gold, special`. `FUN_18007e5e0` gives
+  each panel a `PANEL_ID` = the matching group's ordinal, **or HIDES the panel** if no
+  matching group; `FUN_18007df60` publishes `MYPACK_/…/SPECIAL_CATEGORY_ID`.
+  (:202-206, :1058-1062.)
+
+## 4. Store parser code path (OBSERVED, decompiled)
+
+```
+HTTP 200 {"purchase":[...]}                    (server: store_catalog / _pack_body)
+  → per-element deser FUN_18013af30            → 0x158 wire records
+  → FUN_1800150d0                              → 0x108 display groups (by displayGroup.value),
+                                                 tiles (0x1a8, FUN_18002c3c0) into group+0x40
+  → render FUN_18007dab0 → FUN_1800147f0(model, screen+0x290, …)
+        screen+0x290 == 0     → FUN_180014610  list this group's tiles
+        screen+0x290 == N>0   → FUN_180014420  exact-match ordinal; NULL on miss
+                                → [RAX+0x40] dereference  (NO NULL GUARD)  ← crash site
+```
+
+## 5. My Packs group construction (OBSERVED)
+
+A `mypacks` group exists **iff at least one `purchase[]` entry carries
+`displayGroup.value == "mypacks"`** (the group is derived from packs; there is no
+independent group object on the wire). Its ordinal is its 1-based creation position
+in array order; `group+0x104` is set because the value is `"mypacks"`; its tiles live
+in `group+0x40`. Consequently the server **cannot** emit an "empty `mypacks` group"
+via `purchase[]` — removing the pack removes the group entirely.
+
+## 6. Default / selected group logic (partly UNKNOWN)
+
+- `FUN_1800147f0` resolves whatever category ordinal it is handed via `screen+0x290`;
+  legal values are `0` (list tiles) and `1..N` (existing ordinals). A value that is
+  not an existing ordinal (e.g. `-1` for a hidden/absent panel) → `FUN_180014420`
+  NULL → crash. (OBSERVED via §8 crash + RE.)
+- **Whether the store defaults to / auto-resolves the `mypacks` category on open, and
+  why it does so even when the unopened count is 0, is UNKNOWN** — the store-screen
+  controller and default-tab selection are Scaleform/packed-FIFA17.exe
+  ("Which tile the movie thinks you clicked | CLIENT | Scaleform, unread",
+  store-subsystem :695). Experiment B proves that in this configuration the client
+  DID resolve a `mypacks` ordinal that did not exist (it crashed), so the store is
+  reaching the My Packs category with zero owned packs. Root of "why" = UNKNOWN.
+
+## 7. Pack availability predicate (UNKNOWN)
+
+The predicate that turns the baseline inactive sentinel into "pack not available"
+(while active pack 70 passes) is **in the packed FIFA17.exe and unread**
+(`plan-2026-08-05-pack-opening.md:553`: `state/saleType/quantity/purchaseLimit/
+purchaseCount/start/end` are parsed and copied to the tile, "the predicate that greys
+a tile is in the packed exe and unread"). Candidate deciding fields, from the
+baseline↔A diff (INFERRED, unproven): **`state` (`inactive`→`active`)** and/or
+**`unopened` (`false`→`true`)**. The exact field is **UNKNOWN**.
+
+## 8. Experiment B crash analysis (OBSERVED)
+
+Minidump `CrashDump_…18.21.08…dmp` (the only crash in the hour; minute `:21` matches
+the `00:21:07` store request; SHA-256 `fbddda18…`), parsed:
+- Exception: **`0xC0000005` ACCESS_VIOLATION**, access type **READ**, **faulting VA
+  `0x0000000000000048`**.
+- Faulting instruction: **`CardsDLL_Win64_retail.dll + 0x14882`** → RE-space
+  **`0x180014882`** = **`0x92` bytes into `FUN_1800147f0`** (entry `0x1800147f0`).
+- Interpretation (OBSERVED crash ⋂ decompiled RE): the group pointer returned by
+  `FUN_180014420` was **NULL** (no `mypacks` group present with `unopenedPackIds==[]`
+  and the sentinel suppressed), and `FUN_1800147f0` dereferenced `[NULL+0x48]` → read
+  of address `0x48` → access violation. This is exactly the "no null guard" branch
+  the RE flagged (RE said `[RAX+0x40]`; the actual faulting offset is `+0x48`, same
+  member region — the group struct's `+0x40` vector accessed via a `+0x48` field).
+- Note: the pre-built Ghidra project and `/tmp/fut/cardsdll.dll` were absent on `.105`
+  (tmp cleared); confirmation used the OBSERVED crash dump + the previously-decompiled
+  RE rather than a fresh (expensive) re-analysis. CardsDLL is unpacked, so this code
+  is statically readable if a fresh project is ever needed.
+
+## 9. Empty My Packs client contract (the answer, as far as evidence allows)
+
+- **The client has NO guard for a missing selected group.** If the store resolves the
+  `mypacks` category and no `mypacks` group exists, it null-derefs and crashes.
+  (OBSERVED.)
+- **A `mypacks` group can only exist if a `purchase[]` entry carries
+  `displayGroup.value=="mypacks"`.** (OBSERVED.) There is no wire representation of an
+  "empty group."
+- **If the `mypacks` group's selected pack is not a valid/active pack, the client
+  shows "pack not available".** (OBSERVED baseline vs A; deciding field UNKNOWN, §7.)
+- Therefore, under the *current* client behavior, a zero-unopened-packs account is
+  only cleanly handled when the `mypacks` group contains a **valid active pack**
+  (Exp A). Whether an active-but-non-openable placeholder would also satisfy the
+  availability predicate is **UNKNOWN** (depends on §7).
+- **The correct retail-EA representation of zero unopened packs is UNKNOWN.** It is
+  NOT "omit the group" (crash) and NOT "inactive placeholder" (dialog). It is most
+  likely one of: (i) the retail store does not auto-select My Packs when the unopened
+  count is 0 (a client/Scaleform decision, possibly gated by a count the server sets),
+  or (ii) retail sends a `mypacks` entry the client treats as an empty-but-valid state
+  via a field we have not identified. Neither is established.
+
+## 10. Candidate server representations
+
+| # | Candidate | Client evidence | Expected behavior | Confidence | Safe to test? |
+|---|---|---|---|---|---|
+| A | No `mypacks` pack, no `mypacks` group | Exp B crash (`0x180014882`, `[NULL+0x48]`) | **CRASH** | OBSERVED | Already tested — reject |
+| B | `mypacks` group present but zero packs | Not representable via `purchase[]` (groups derive from packs, `FUN_1800150d0`) | UNKNOWN | INFERRED-not-representable | No server mechanism |
+| C | Inactive placeholder pack (current sentinel) | Baseline dialog | "pack not available" → Hub | OBSERVED | Already tested — reject |
+| C′ | **Active** placeholder pack, id absent from `PACK_CATALOG` (so open/buy handlers reject it) | Exp A shows an *active* mypacks pack works; sentinel id 65534 is already rejected by open/buy (not in `PACK_CATALOG`) | Group resolves (no crash); MIGHT pass availability (no dialog) while remaining non-openable → no free pack | HYPOTHESIS | Yes — code change, restart; economy-safe (non-openable) |
+| D | Hide My Packs when unopened count == 0 | `FUN_18007e5e0` hides a panel with no group, but the store still resolved `mypacks` at count 0 (Exp B crash) | Hiding via absence CRASHES; a client count-gate is Scaleform/unknown | UNKNOWN | Not server-controllable as far as known |
+| E | Different default category when count == 0 | Default-tab selection is Scaleform/packed | UNKNOWN | UNKNOWN | Not server-controllable as far as known |
+| F | A count/quantities field (e.g. `ut/v2/store` `FutStorePackQuantities`, or `userInfo.unopenedPacks`) that suppresses the My Packs auto-select | eligibility gate exists (`ENDPOINT_MAP.md:60`); relationship to My Packs default UNKNOWN | UNKNOWN | HYPOTHESIS | Read-only RE first |
+
+## 11. Recommended next controlled experiment
+
+**Experiment C′ (economy-safe placeholder).** Keep `unopenedPackIds == []`; change the
+synthetic sentinel `65534` ONLY in `state` (and, if needed, `unopened`) so the
+`mypacks` group's single tile is **active** — but leave its id `65534` **absent from
+`PACK_CATALOG`** so `store_buy`/`open_pack`/`consume_unopened_pack` still reject it
+(no pack can be opened → **no free pack, no economy change**). Observe whether the
+store then opens without the "pack not available" dialog (would identify `state` as
+the availability field and give an economy-safe fix), or still shows the dialog
+(implicating another field / packed predicate).
+- Requires a temporary code change to `store_catalog` (sentinel construction) →
+  restart. Same experiment discipline as Experiment B (patch container copy, capture,
+  revert, restart). Economy-safe because the placeholder remains non-openable.
+- If C′ still fails, escalate to read-only RE of the availability predicate / the
+  count-gated default-tab hypothesis (candidate F) before any further change.
+
+## 12. Open questions
+
+1. Exact field that flips the sentinel from "pack not available" to acceptable
+   (`state`? `unopened`? another). UNKNOWN — packed predicate. (Exp C′ targets this.)
+2. Why does the store resolve/select `mypacks` with zero owned packs? Is there a
+   server-settable count that would stop it? UNKNOWN — Scaleform/packed.
+3. Does retail FIFA 17 ever present an empty My Packs, and how? No capture on record.
+4. Is an active-but-non-openable placeholder (C′) accepted by the availability
+   predicate? HYPOTHESIS — untested.
+
+---
+
+## Permanent-fix requirements (Phase 11 — REPORT ONLY, not implemented)
+
+A correct permanent fix MUST satisfy ALL of:
+- Zero unopened packs must **NOT** grant the user a free pack.
+- No synthetic **openable** reward may be created (any placeholder must be rejected by
+  `store_buy`/`open_pack`/`consume_unopened_pack`).
+- Client must **not crash** (a resolvable `mypacks` group must exist, OR the client
+  must be kept from resolving `mypacks` when empty).
+- Client must **not** show "The pack you've selected is currently not available".
+- Normal Bronze/Gold/Special store categories must still work unchanged.
+- When a genuine unopened pack exists, My Packs must continue to work (Exp A).
+- Profile/economy semantics must remain correct (no coins/nextItemId/inventory drift).
+
+Nothing implemented. The evidence favours investigating an **economy-safe active
+placeholder (C′)** and/or the **count-gated My-Packs default (F)**; it explicitly does
+NOT support "grant pack 70 whenever My Packs is empty".
+
+---
+
+## UPDATE after Experiment C′ (2026-08-13) — active non-openable placeholder tested
+
+Executed C′: sentinel 65534 `state "inactive"→"active"` only; `unopenedPackIds==[]`;
+65534 kept out of `PACK_CATALOG`. Full record in `STORE_TILE_6C.md` §16. Capture:
+`store_purchasegroup_capture_active_placeholder_2026-08-12.json` (C′-vs-baseline JSON
+diff = only `65534.state`).
+
+**Resolves §7 (availability predicate), partially:** `state` **DOES participate**
+(OBSERVED). `state:"active"` removed the "pack not available" dialog while the group's
+existence still prevented the crash. So the earlier §7 "deciding field UNKNOWN" is
+updated: **`state` (inactive vs active) is (at least) a deciding field** for the
+dialog. `unopened` was NOT varied and remains untested. The full predicate may still
+involve other fields, but `state` alone flips dialog→no-dialog.
+
+**Updated candidate table verdict:**
+- **C′ (active placeholder, non-openable): SUPPORTED with UX caveats — best option so
+  far, but NOT adopted.** No crash, no dialog, store usable, and **no automatic
+  transaction/open for 65534** (only a routine boot `TRANSACTIONCANCEL` no-op).
+  Caveats (OBSERVED): (1) the placeholder renders as a **visible empty pack tile**
+  ("0 items, 0 bronze, 0 rares", no cover) that a user could try to open (server-safe:
+  opening 65534 → no-op `{}`/stale `last_pack`, no value — §16.1); (2) **navigation
+  gate**: from the Store "Browse Packs" entry the Bronze/Gold/Special categories are
+  not reachable until "My Packs" is opened first (not present with a genuine owned
+  pack, Exp A).
+- A (real active pack 70): works cleanly but grants a real openable pack → economy
+  risk; rejected as the permanent fix.
+- Candidate **F (count-gated My-Packs default)** gains weight: C′'s visible-empty-tile
+  and Browse-Packs navigation gate suggest the client is being pushed to resolve/enter
+  My Packs when it should not with zero packs. If a server-settable count (e.g.
+  `userInfo.unopenedPacks` / `ut/v2/store` quantities) suppresses the My-Packs
+  default/tile, that could remove both the crash risk and the empty-tile artifact
+  without any placeholder. UNTESTED.
+
+**Permanent fix: still NOT established.** Even though C′ is the first
+crash-free/dialog-free representation, the empty-tile UX + navigation gate + the
+untested "explicit placeholder selection" behavior bar adoption. Required next steps
+(design/authorize separately): (a) controlled test of explicitly focusing/opening the
+active placeholder; (b) investigate candidate F (count-gated My-Packs) to avoid a fake
+tile entirely. Do NOT adopt `state:"active"` or "grant pack 70" as the fix on current
+evidence.
+
+---
+
+# Candidate F — Count-Gated My Packs Navigation (READ-ONLY investigation, 2026-08-13)
+
+Question: can the server make FIFA decide **not** to resolve/default into My Packs
+when the account owns zero unopened packs (avoiding any placeholder)?
+
+## 1. Server-sent unopened-pack signals (inventory, OBSERVED code)
+| field / endpoint | source | value source | when sent | client consumer | conf |
+|---|---|---|---|---|---|
+| `userInfo.unopenedPacks.recoveredPacks` (via `userMassInfo`) | `utas_server.py:409-414` | `len(unopenedPackIds)` | boot massinfo; only if count>0 **or** `_UI∈{packs,full}` (default `_UI=roster` → omitted at 0) | hub unopened-pack model / My Packs badge (`FUN…vtbl[0x4e0]`, pack-opening RE) | OBSERVED (code) |
+| `/user/credits` `.unopenedPacks.recoveredPacks` | `utas_server.py:3542-3545` | `len(unopenedPackIds)` | on credits fetch; **only if count>0** | My Packs badge / CentralUnclaimedPack hub tile | OBSERVED (code+capture) |
+| `/hub` body | `utas_server.py:1449-1453` | — | hub load | — (**no pack count present**) | OBSERVED |
+| profile `unopenedPackIds` | `fut_store.py` | account state | internal | not wire-visible directly | OBSERVED |
+`pileSize`/`store quantities` (`ut/v2/store` `FutStorePackQuantities`) exist as an
+eligibility gate (`ENDPOINT_MAP.md:60`) but were **never requested** in any capture
+(8h logs); they carry a store-open `result`, not a My-Packs count.
+
+## 2. Pre-store request sequence (OBSERVED, captures)
+Boot → `accountinfo → /ut/auth → settings → phishing → match/reset → userMassInfo →
+PUT store/transaction/0 (TRANSACTIONCANCEL→{}) → /hub → clientdata → /user/credits →
+GET /store/purchasegroup/all`. The only pack-count-bearing responses **before**
+`purchasegroup` are `userMassInfo`(userInfo) and `/user/credits`.
+
+## 3. Baseline([]) vs Experiment A([70]) pre-store diff (OBSERVED, captures)
+The single profile change `[] → [70]` altered exactly one pre-store wire signal:
+- `/user/credits`: **`[]` → no `unopenedPacks` member** (C′ capture, all 3 fetches:
+  `{"credits":…,"currencies":[…]}`); **`[70]` → `"unopenedPacks":{"preOrderPacks":0,
+  "recoveredPacks":1}`** (A capture line 25). OBSERVED.
+- `userInfo.unopenedPacks`: same pattern (present at `[70]`, omitted at `[]` with
+  `_UI=roster`). INFERRED from code; A-capture credits corroborates.
+- **No other pre-store field changed.**
+
+Candidate signal:
+```
+Candidate:                 unopenedPacks.recoveredPacks (count)
+Endpoint:                  /user/credits  and  userMassInfo(userInfo)
+Baseline([]) value:        ABSENT (i.e. zero)
+Experiment A([70]) value:  {preOrderPacks:0, recoveredPacks:1}
+Source:                    utas_server.py:3542-3545 / :409-414 (= len(unopenedPackIds))
+Client-visible before purchasegroup?:  YES
+Confidence:                OBSERVED that it differs; its CONTROL over My-Packs nav = see §9
+```
+**Key point: this count is already CORRECT** — it reports zero (absent) when the
+account is empty. OpenFUT is **not** misreporting a nonzero pack count.
+
+## 4. Navigation / client call path (OBSERVED, decompiled RE)
+`FUN_18007dab0 → FUN_1800147f0(model, screen+0x290, …)`. `screen+0x290==0` lists
+group tiles; else `FUN_180014420` exact-matches the group ordinal (NULL on miss →
+`[NULL+0x48]` crash). `screen+0x290` is written in exactly two CardsDLL sites: the
+screen ctor `FUN_18007d1a0` writes `0`, and **`FUN_18007e7f0` case `0x7551` copies
+the Flash movie message field `CATEGORY_ID` verbatim** into it
+(store-subsystem :172-175, :1055-1056). So the resolved category is chosen by the
+**Scaleform movie**, not by any server response field.
+
+## 5. `GOTO_STORE_MYPACK` analysis (OBSERVED, RE)
+`GOTO_STORE_MYPACK` is the **destination of the hub `CentralUnclaimedPack` tile**
+(tile type 0x1c); "Nothing in the chain issues a request, and no request could
+exist" (pack-opening :888-890). Whether that HUB tile appears is gated by the
+unopened-pack count in the hub model (`model+0x20950`) — i.e. the count DOES control
+the *hub unclaimed-pack tile*, but the operator reached the store via **Browse Packs**
+/ the store screen, whose category resolution is the movie-driven `CATEGORY_ID` path
+(§4), not `GOTO_STORE_MYPACK`. `GOTO_STORE_MYPACK` is a UI navigation command,
+**not** a server-state-gated store-category selector.
+
+## 6. Candidate count/flag fields — verdict per field
+- `unopenedPacks.recoveredPacks`: correct at 0 when empty; controls the hub badge /
+  CentralUnclaimedPack tile, **not** the store's category resolver. Not a viable gate
+  for the store My-Packs entry.
+- No other server field feeds `screen+0x290` (RE §4: only ctor-0 and movie
+  `CATEGORY_ID`).
+
+## 7. EA-capture evidence
+No EA-origin `purchasegroup`/`credits` capture for a zero-unopened-packs account
+exists in the repo (all captures are OpenFUT-generated). EA count semantics for empty
+My Packs remain **UNKNOWN**.
+
+## 8. Where My Packs selection occurs (OBSERVED)
+**Before** `purchasegroup` parsing decides content, the **Scaleform movie** decides
+which category to resolve and writes it to `screen+0x290` (§4). The server's role is
+limited to which groups EXIST in `purchase[]`. Therefore the sentinel is compensating
+for a **movie-side** decision to resolve My Packs; it is not fixing an incorrect
+server count (the count is already correct).
+
+## 9. Candidate F verdict — **F3 (CONTRADICTED)** (with an F4 residue)
+My Packs selection is **not** controlled by server-sent unopened-pack state:
+- OBSERVED: the server count is correctly zero/absent when empty, yet the store still
+  resolved My Packs (baseline dialog, Exp-B crash). A correct zero signal did not stop
+  it.
+- OBSERVED (RE): `screen+0x290` (the resolved category) comes from the movie's
+  `CATEGORY_ID`, with no server-field input; default is 0.
+Residue (F4): the movie's internal logic for *why* it asks for My Packs on store open
+is in packed Scaleform and is not statically readable — but no server lever into it
+has been found. **Conclusion: there is no server-controlled count/flag that makes FIFA
+skip resolving My Packs; the server can only ensure the `mypacks` group exists.** The
+"clean count-gated fix" is therefore **not achievable server-side**.
+
+## 10. Proposed next experiment
+Because F is contradicted, a count experiment is NOT recommended (the count is already
+correct and does not gate the store). No single-variable server signal will make FIFA
+enter Browse Packs instead of My Packs. The realistic next step is the previously
+deferred **explicit active-placeholder selection test**: with the C′ active
+non-openable placeholder in place (sentinel 65534 at baseline otherwise), have the
+operator explicitly focus/open the empty My-Packs tile and observe (server-safe per
+§16.1 — opening 65534 is a no-op — but UX/navigation behavior unknown). That
+characterizes the best available server-side option (C′) before any adoption.
+- Would it change profile state? No (`unopenedPackIds=[]`).
+- Would it change purchasegroup/sentinel behavior? Only `state:"active"` (as C′),
+  reverted after.
+- Code change? Yes (same one-line C′ patch). Restart? Yes. (Not authorized here.)
+If explicit selection proves unsafe/ugly, the remaining options are all **client-side
+/ out-of-scope** (the decision is in the Scaleform movie), or accepting C′ with its
+documented UX artifacts.
+
+**Candidate F does NOT provide the hoped-for clean fix. The active non-openable
+placeholder (C′) remains the best server-side representation; its empty-tile and
+Browse-Packs navigation artifacts are movie-driven and not server-fixable.**
+
+---
+
+# Explicit Active-Placeholder Selection Test — FINAL backend-side result (2026-08-13)
+
+With the C′ active placeholder in place (`unopenedPackIds=[]`, 65534 active/mypacks/
+∉PACK_CATALOG), the operator explicitly opened the empty My-Packs tile once. Full
+record in `STORE_TILE_6C.md` §17.
+- **Outcome: S1 — pure client-side rejection.** Dialog **"This pack is no longer
+  available"** → back to My Packs → Hub; **no crash**, navigation stays usable.
+- **No server request** on selection (no `/store/transaction`, no `/purchased/items`,
+  no 65534 reference); the verdict is client-side. (OBSERVED)
+- **Zero economy/profile mutation:** coins/items/nextItemId/`unopenedPackIds`/
+  `last_pack` all unchanged; profile byte-identical (`39bb3e83…`); 65534 not
+  persisted. (OBSERVED)
+
+**Active-placeholder verdict: MARGINALLY ACCEPTABLE** — crash-safe + economy-safe +
+navigable, but with user-visible defects (empty fake tile; "no longer available" on
+explicit click; Browse-Packs nav gate). It is a *strict improvement* over the current
+inactive-sentinel baseline (which errors on store OPEN and bounces to Hub).
+
+**Backend-side question is now fully answered.** The complete zero-unopened-packs
+ladder:
+```
+no mypacks group        -> CardsDLL null-deref CRASH        (unsafe)
+inactive placeholder    -> "pack not available" on store open -> Hub  (baseline)
+active placeholder       -> store loads; empty tile; "no longer available" only on
+                            explicit click; recoverable; economy-safe   (best backend option)
+real active owned pack   -> fully correct UI  (but grants a real openable pack — economy risk)
+```
+
+**Permanent-fix recommendation: P2.** The active non-openable placeholder is the best
+*safe* backend-only option, but a fully *clean* zero-pack experience is **not**
+achievable server-side (Candidate F CONTRADICTED — the My-Packs resolution is
+Scaleform/movie-driven). Recommend: adopt the active placeholder as an optional
+backend compatibility mode (safe, strictly better than baseline) AND pursue a
+client-side fix (hide the fake tile / stop the forced My-Packs resolution) for the
+fully clean result. **Not implemented.** Do NOT grant a real pack.
+
+---
+
+## Client resolver-guard experiment (2026-08-13) — RESULT F3 (crash, confounded)
+
+A client-side `autopatch.py` memory guard (CardsDLL `0x180014858` `JNZ`→`JG`, routing
+category `<0` to list-all/Browse) was tested against the exact no-sentinel server condition
+(sentinel 65534 suppressed; `GET /store/purchasegroup` ids `[1,5,6,7]`, no mypacks group).
+The client **crashed at the identical resolver site `0x180014882`** (`[NULL+0x48]`), because
+it presented a **positive** My-Packs ordinal (crash is in the `>0` resolve branch), not the
+`-1` the guard diverts. **Confound:** FIFA was not relaunched after the backend flip, so it
+reused stale (sentinel-present) tab state. So the negative-only guard is **insufficient for a
+positive stale/invalid ordinal**, and the fresh-client case is **not yet decided** (needs a
+clean re-test: fresh launch with backend already no-sentinel). Backend P2 sentinel was
+restored immediately (mandatory rollback). Full record + candidate stronger guard:
+`docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md` PART III.
+
+## Fresh-process no-sentinel retest (2026-08-13) — RESULT R1 (SUCCESS)
+
+Re-ran the above cleanly: backend entered no-sentinel mode **while FIFA was closed**, then a
+**fresh** FIFA (pid 553220, new autopatch 552999, guard `85 ff 7f 0f` enforced) launched and
+opened the Store. The genuine no-sentinel `/store/purchasegroup` (ids `[1,5,6,7]`, no 65534/
+mypacks) is **byte-identical** to the F3 capture, so the only changed variable is client
+process lifetime. Outcome: **no crash, no dialog, Store opens on Browse Packs, packs
+navigable** (cosmetics only: no tabs / no cover art / "0 items" — pre-existing). A fresh
+client publishes category `-1` for the absent group, which `JNZ→JG` routes to Browse/list-all
+with no NULL deref. **This confirms F3 was stale-positive-ordinal contamination, and proves
+Strategy A (resolver guard) on the tested build.** Backend P2 sentinel restored immediately
+(`f416e71e…`, `state=active`) and remains production default. Full record:
+`docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md` PART IV.

docs/evidence/STORE_TILE_6C.md

@@ -0,0 +1,924 @@
+# Store Tile Investigation (bug 6c)
+
+Status: **ROOT CAUSE ESTABLISHED — P2 compatibility workaround IMPLEMENTED**
+(2026-08-13). Full investigation complete (§1-§17); backend fix landed in
+`fifa17-recon/tools/utas_server.py` `store_catalog` with regression tests in
+`fifa17-recon/tools/test_empty_mypacks.py`. The store-tiles flags are unchanged
+(`FUT_STORE_DISPLAYGROUP=ON`, `FUT_STORE_GROUPID=OFF`) and the profile is unchanged.
+
+## RESOLUTION (2026-08-13)
+
+**ROOT CAUSE (bug 6c):** FIFA 17's Store/Scaleform path RESOLVES the `mypacks`
+category even when the account owns zero unopened packs (the category is chosen
+client-side from the movie's `CATEGORY_ID` → `screen+0x290`; no server field gates
+it — Candidate F CONTRADICTED). CardsDLL `FUN_1800147f0` then dereferences the
+resolved group with NO null guard, so an absent `mypacks` group crashes the client
+(`CardsDLL_Win64_retail.dll+0x14882`, `[NULL+0x48]` — minidump-confirmed, §8).
+
+**BACKEND RESULT / DECISION — P2 (compatibility workaround):** emit a synthetic,
+**active**, non-openable `mypacks` placeholder (id 65534, absent from `PACK_CATALOG`)
+only when `unopenedPackIds == []`. This is crash-safe AND economy-safe (explicit
+selection is rejected client-side with "This pack is no longer available", sends no
+backend request, and mutates nothing — §17). It is a FIFA-17 client-compatibility
+shim, **NOT** an EA-authentic empty-My-Packs representation, and is confined to the
+FIFA-17 adapter/backend layer (NOT OpenFUT Core).
+
+**KNOWN UX LIMITATIONS (unfixable server-side):** a fake empty "0 items" tile; an
+explicit-selection dialog "This pack is no longer available"; and a Browse-Packs →
+My-Packs navigation quirk. These are Scaleform/movie-driven.
+
+**CLEAN CLIENT FIX:** still unresolved; belongs to client-side work —
+`docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md`.
+
+Evidence labels: **OBSERVED** (running code / `docker inspect` / live log / minidump /
+table), **INFERRED**, **HYPOTHESIS**, **UNKNOWN**.
+
+### Hypotheses
+
+- **H1 (original — subtype/definition):** *Store tiles render "unknown" because the
+  server emits definitions whose type/subtype the client cannot map (prime suspects
+  5004xxx misc {231,232,233,236}, 8010xxx league logos, FCC↔wire subtype gaps).*
+  **Verdict: CONTRADICTED by static store-handler evidence.** The `/store/purchasegroup`
+  handler emits PACK definitions only — no `cardsubtypeid`/`carddbid`/`cardassetid`
+  anywhere in the response (§2). Those subtype families belong to the separate
+  **club-item / consumable / equippable** paths (`fut_clubitems.py`, `fut_consumables`,
+  `/club?type=`), which are OUT OF SCOPE for this store-tile task. History preserved
+  in §3.3 and §8; not investigated further here.
+- **H2 (revised — displayGroup token):** **HYPOTHESIS (under runtime test).** *The
+  "unknown" FUT Store tile is caused by one or more pack entries whose
+  `displayGroup.value` token is not one of the six categories FIFA 17 can render:*
+  `mypacks, points, bronze, silver, gold, special`. Tested against a real capture in
+  §4-§8.
+
+---
+## Runtime capture plan (Phase 2) — OBSERVED
+
+- **Backend container:** `openfut-fut-backend` (logs on stdout via `log()`,
+  `utas_server.py:59-62`; each request logs `"<VERB> <path>"` at `:3732`, and the
+  response line `"  -> <code> <body[:200]>"` at `:3754` — **response body truncated
+  to 200 bytes**, so the full JSON body is NOT in the log).
+- **Endpoint / path matcher:** `GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true`
+  (OBSERVED historically in the log; route regex `/store/purchasegroup`,
+  `utas_server.py:1215`).
+- **Capture marker (UTC, set immediately before the manual test):**
+  `2026-08-12T23:54:01Z` (saved to `/tmp/store_capture_marker.txt`; 0 log lines
+  after it at set-time → clean boundary).
+- **Log command to isolate the manual action:**
+  `docker logs --since 2026-08-12T23:54:01Z --timestamps openfut-fut-backend`
+  then locate the first `GET .../store/purchasegroup` line after the marker plus its
+  following headers and `-> 200 {"purchase"...` line.
+- **Full-body recovery (because the log truncates at 200 bytes):** the response is a
+  deterministic pure function — `store_catalog()` (`:3408`) over static `PACK_CATALOG`
+  (`fut_store.py:820`) + live `STORE.unopened_packs()` (from `/state` profile) under
+  fixed flags (`STORE_DISPLAYGROUP=ON`, `STORE_GROUPID=OFF`, `FUT_PRICE_PROBE=OFF`).
+  Plan: reconstruct the exact body from the running `/app` code + live `/state`
+  profile, then **verify** its `json.dumps(...)[:200]` byte-for-byte equals the genuine
+  logged 200-byte prefix. Match ⇒ the reconstruction IS the sent body. No request is
+  synthesized, replayed, or curl'd; the genuine log line is the ground-truth anchor.
+
+
+## 1. Method
+
+### Environment (OBSERVED)
+- Running on `10.10.0.120` (dev-lxc). Client is `10.10.0.105`.
+- Backend under test: Docker container `openfut-fut-backend`
+  (image `openfut-fut-backend:dev`), `Up 7 hours`, entrypoint `/app/entrypoint.sh`.
+  - `docker inspect openfut-fut-backend`: only mount is
+    `/home/alex/OpenFUT/fifa17-recon/docker/state -> /state (rw)`; container ENV
+    contains **no `FUT_STORE_*`** vars.
+  - `entrypoint.sh` launches `python3 -u utas_server.py` from `/app/tools` with extra
+    env `FUT_TRADING=1 FUT_PILESIZES=1 FUT_TRADEABLE=1 FUT_DISCARD_TABLE=1
+    FUT_DISCARD_SEND=1` — again **no `FUT_STORE_*`**.
+- The running store code is `/app/tools/utas_server.py`. Extracted read-only via
+  `docker cp openfut-fut-backend:/app/tools /tmp/app-tools` and confirmed
+  **byte-identical** (`sha256`) to the repo copy
+  `fifa17-recon/tools/utas_server.py` (both 3765 lines) and
+  `fifa17-recon/tools/fut_clubitems.py`. All line references below are to the repo
+  paths and equal the running code.
+
+### Commands (exact)
+```
+docker ps --format '{{.Names}}\t{{.Image}}\t{{.Command}}\t{{.Status}}'
+docker inspect openfut-fut-backend --format '...CMD/ENTRYPOINT/MOUNTS/ENV...'
+docker exec openfut-fut-backend cat /app/entrypoint.sh
+docker cp openfut-fut-backend:/app/tools /tmp/app-tools
+docker cp openfut-fut-backend:/app/data  /tmp/app-data
+diff /tmp/app-tools/utas_server.py fifa17-recon/tools/utas_server.py   # identical
+diff /tmp/app-tools/fut_clubitems.py fifa17-recon/tools/fut_clubitems.py # identical
+```
+
+### Manual test sequence
+NOT executed. The manual FIFA-client store capture (2D/2E) was never reached
+because the investigation blocked at 2C before any flag could be enabled. No
+request was synthesized, replayed, or simulated.
+
+---
+
+## 2. Store handler code path (2A) — OBSERVED
+
+Request → response for the store tile screen:
+
+1. **Endpoint.** `GET ut/<sku>/store/purchasegroup/...` — `FutStoreGetPackTypes`
+   (client deser root `0x1801234e0`). (`utas_server.py:3408-3409` docstring.)
+   - Route table entry: `(re.compile(r"/store/purchasegroup"), lambda m,h:
+     store_catalog(h))` at `utas_server.py:1215`.
+   - Sibling store routes: `/store/transaction -> store_buy(h)` (`:1216`, the BUY);
+     bare `/store(\?|$) -> (200,{"result":"SUCCESS"})` eligibility gate (`:1221`).
+2. **Handler.** `store_catalog(h)` (`utas_server.py:3408-3447`).
+   - Iterates `PACK_CATALOG` (non-`ownedOnly` packs) → `_pack_body(p, idx)`.
+   - Appends owned unopened packs from `visible_unopened_packs()` →
+     `STORE.unopened_packs()` + `_OPENED_PACK_GRACE` (`:51-52`, `:3423-3427`).
+   - If no owned packs, appends one inactive `mypacks` sentinel (id 65534) so
+     `GOTO_STORE_MYPACK` resolves (`:3428-3446`).
+   - Returns `200, {"purchase": [<pack bodies>], "timestamp": 1596326400}`
+     (`:3447`).
+3. **Definition construction.** `_pack_body(p, idx, owned=False)`
+   (`utas_server.py:3268-3405`). Emitted keys (OBSERVED, `:3293-3328`):
+   `assetId`(=`p["id"]`), `id`(=`p["id"]`), `packType`, `description`(=`p["name"]`),
+   `state`, `saleType`, `limitType`, `quantity`, `purchaseLimit`, `purchaseCount`,
+   `isPremium`, `sortPriority`, `currencies`, `extPrice`, `packContentInfo`
+   (`bronze/silver/gold/rare/itemQuantity`), `unopened`, and one of:
+   - owned pack → `displayGroup = {"value":"mypacks","priority":idx}` (`:3336`);
+   - else if `STORE_DISPLAYGROUP` → `displayGroup = {"value": category}` where
+     `category ∈ {special, gold, silver, bronze}` chosen from
+     `p["specialChance"]`/`p["gold"]` (`:3337`,`:3373-3379`), and if `STORE_GROUPID`
+     also `displayGroupAssetId = p["id"]` (`:3403-3404`).
+4. **Data source(s).**
+   - `PACK_CATALOG` — a hardcoded list of 3 pack dicts
+     (`{id,name,price,count,gold,tiers,specialChance}`) at `fut_store.py:820-841`.
+     There is NO card table read in this path.
+   - `STORE = Store()` (`fut_store.py:843`), backed by the profile JSON
+     (`unopened_packs()` reads `unopenedPackIds`, `fut_store.py:619-621`).
+5. **Serialization → HTTP.** The dict is JSON-encoded by the server's response
+   writer and returned as the HTTP body.
+
+### Fields 5 (`cardsubtypeid`/`carddbid`/`cardassetid`) — OBSERVED
+**None of `cardsubtypeid`, `carddbid`, or `cardassetid` appear anywhere in the
+store-tile (`purchasegroup`) response.** `_pack_body` (`:3293-3405`) emits only the
+pack keys listed above; `assetId`/`id` are the PACK id `p["id"]` (e.g. 1, 5), not a
+card asset id. The store catalog emits PACKS, never card definitions. (Grep of
+`_pack_body` and `store_catalog` for those three field names returns zero hits.)
+
+### Families the store handler can emit
+Only **packs** (`PACK_CATALOG`: "Bronze Pack" id 1, "Gold Pack" id 5, and the third
+catalog entry) plus owned reward packs and the `mypacks` sentinel. It cannot emit
+any card family (players, staff, consumables, club items).
+
+### Filtering / transformation
+- `normal = [p for p in PACK_CATALOG if not p.get("ownedOnly")]` (`:3421`).
+- `_pack_body` maps a pack to a category token via `specialChance>=1.0 -> special`,
+  else `gold -> gold`, `p.get("silver") -> silver`, else `bronze` (`:3373-3379`).
+- The tile caption/category is `displayGroup.value`; `description` carries the
+  per-pack title.
+
+---
+
+## 3. Wire subtype coverage (2B)
+
+### 3.1 Store path
+The store-tile path emits **no `cardsubtypeid`** at all (see §2). So for the store
+tile, "is `cardsubtypeid` the raw FCC subtype, the wire category, transformed, or
+something else?" → **not present** (N/A). The store tile is selected by
+`displayGroup.value` (a category-token STRING), not by any card subtype.
+
+Per `_pack_body:3367-3372` (citing `FUN_180014580`/`FUN_180014df0`): FIFA 17's
+StoreFront resolves exactly **six hard-coded category tokens** —
+`mypacks, points, bronze, silver, gold, special`. Any other `displayGroup.value`
+(e.g. a raw pack title) creates an "unsupported pseudo-category". The documented
+cause of "unknown" store tiles is therefore a **`displayGroup` category-token**
+issue on packs (absent group, or a non-canonical token), NOT a card type/subtype.
+
+### 3.2 Club-item path (the only place wire subtypes live) — `fut_clubitems.py`
+Club items are served on the **`/club?type=` route** (`utas_server.py:2250`,
+`handle_club`), gated by `FUT_CLUBITEMS`, NOT by the store route. Current `FAMILIES`
+(`fut_clubitems.py:61-67`), format `(family, table, art id, stat id, stat name,
+UNVERIFIED cardsubtypeid)`:
+
+| wire subtype | mapped family | table | art id | source | confidence |
+|---|---|---|---|---|---|
+| 9  | kits        | fcc_kitcards.json  | 35 | `fut_clubitems.py:65` | HYPOTHESIS (marked "UNVERIFIED", `:49`,`:30-32`) |
+| 10 | stadia      | fcc_stadium.json   | 36 | `fut_clubitems.py:63` | HYPOTHESIS ("UNVERIFIED") |
+| 11 | badges      | fcc_badgecards.json| 39 | `fut_clubitems.py:64` | HYPOTHESIS ("UNVERIFIED") |
+| 30 | balls       | fcc_balls.json     | 37 | `fut_clubitems.py:62` | HYPOTHESIS ("UNVERIFIED") |
+| 31 | leaguelogos | fcc_leaguelogos.json| 40| `fut_clubitems.py:66` | HYPOTHESIS ("UNVERIFIED") |
+
+- The prior recorded mapping (9=kits,10=stadia,11=badges,30=balls,31=logos) is
+  **confirmed present in current code** — but the code itself marks every one
+  "UNVERIFIED cardsubtypeid" and states the binary assigns family↔subtype **nowhere**
+  in the 149 dumped tables; cardtype-9 admits the set `{30,31,145,146,147,148,149,150}`
+  (`fut_clubitems.py:26-28`, `:73`). So these are server-chosen HYPOTHESIS values.
+- In the club-item wire item (`_item:88-119`), `cardsubtypeid` (`:97`) is a
+  **server-assigned wire-category constant** (9/10/11/30/31), NOT the raw FCC
+  subtype: the club-item fcc tables carry **no `cardsubtype` column at all** (Task 1:
+  badges/stadium/kit/logos/balls have empty subtype sets). `resourceId`/`assetId`
+  = `carddbid`, and `cardassetid` = the family ART id (`:94-96`). So for club items:
+  **`cardsubtypeid` = wire category (server constant), `carddbid`/`cardassetid` =
+  real fcc columns.**
+- By contrast, consumables (`fut_store._item` / `fut_consumables`) DO carry the raw
+  FCC subtype (51..341) as `cardsubtypeid`.
+
+### 3.3 Task-1 families vs wire-subtype coverage
+Families that the **store handler** can map to a wire subtype: **none** — the store
+handler emits packs, which have no card subtype (by design).
+
+Families for which a **club-item** wire subtype exists (HYPOTHESIS-grade):
+kits(9), stadia(10), badges(11), balls(30), leaguelogos(31).
+
+Task-1 card families with **no wire subtype mapping anywhere in the server**:
+- **5001xxx contracts, 5002xxx fitness/healing, 5003xxx training** — served as
+  consumables carrying their raw FCC subtype; these are consumable overlays, not
+  store tiles, and not part of any store/club-item wire-category map.
+- **5004xxx misc {231,232,233,236}** — **no wire subtype mapping found** in
+  `fut_clubitems.py` or the store path. (Grep: no `misc` family, no {231,232,233,236}
+  wire assignment.) They exist only as raw FCC subtypes in consumable data.
+- **8010xxx league logos/stickers** — mapped in the **club-item** path as wire
+  subtype **31** (`fut_clubitems.py:66`), HYPOTHESIS-grade. `fcc_leaguelogostickers`
+  (39 rows) is NOT wired in `FAMILIES` (only `fcc_leaguelogos`, 44 rows).
+- **6000xxx badges, 6200xxx stadiums, 6300/6400xxx kits, 8120xxx balls** — mapped in
+  the club-item path (11/10/9/30), HYPOTHESIS-grade.
+- **staff (managers/coaches, subtypes 4-8)** — served by `fut_staff` on `/club?type=
+  manager`, not a store tile.
+
+Note none of these belong to the **store-tile** (`purchasegroup`) response.
+
+---
+
+## 2C flag investigation — BLOCKED
+
+### Store-tiles flags located (OBSERVED)
+Two, both in `utas_server.py`, both module-level constants read **once at import**:
+
+| flag | env var | line (read) | consumed | default | current running value |
+|---|---|---|---|---|---|
+| `STORE_DISPLAYGROUP` | `FUT_STORE_DISPLAYGROUP` | `:975` | `_pack_body:3337` | `"1"` → **ON** | **ON** (no env override) |
+| `STORE_GROUPID` | `FUT_STORE_GROUPID` | `:980` | `_pack_body:3403` | `"0"` → **OFF** | **OFF** (no env override) |
+
+- `:975` `STORE_DISPLAYGROUP = os.environ.get("FUT_STORE_DISPLAYGROUP", "1") == "1"`
+- `:980` `STORE_GROUPID       = os.environ.get("FUT_STORE_GROUPID", "0") == "1"`
+
+**Current values (recorded before any change; nothing was changed):**
+- `FUT_STORE_DISPLAYGROUP`: unset in container env → default `"1"` →
+  `STORE_DISPLAYGROUP = True` (**ON**). (INFERRED from OBSERVED env dump + OBSERVED
+  code default.)
+- `FUT_STORE_GROUPID`: unset in container env → default `"0"` →
+  `STORE_GROUPID = False` (**OFF**). This is the flag "expected to be OFF".
+
+The related club-item flag `FUT_CLUBITEMS` (`:1647-1648`) is likewise unset →
+`CLUBITEMS = False` (club items not currently served), also a module-level import
+constant.
+
+### Dynamic evaluation? NO (OBSERVED)
+- All three flags are top-level `os.environ.get(...)` assignments evaluated at
+  module import (`:975`, `:980`, `:1647`); `_pack_body` reads the resulting module
+  **constants** (`:3337`, `:3403`), never `os.environ` at request time.
+- Repo-wide there is **no** `importlib.reload`, no `signal`/`SIGHUP` handler, and no
+  per-request environ re-read for these flags. (The only runtime-refreshable feature
+  is `FUT_ID_SWEEP`, which re-reads a *file* `SWEEP_FILE`, `:1965-1966` — unrelated.)
+- `:3250` documents the intended workflow explicitly:
+  `# Enable for the test with:  FUT_PRICE_PROBE=1 ./openfut-fut.sh restart`.
+
+### Restart conflict → STOP
+Changing either store flag requires either setting a container env var (→
+`docker` recreate = restart) or editing the module (→ re-import = restart). Both
+violate the no-restart / no-redeploy / no-recreate constraint. Therefore:
+
+```
+TASK 2 BLOCKED AT 2C:
+Flag requires restart, conflicting with no-restart constraint.
+```
+
+No flag was enabled. 2D/2E (manual client capture + definition analysis) NOT
+started. No client request generated, replayed, or simulated.
+
+---
+
+## 4. Captured request and response (Phase 3) — OBSERVED
+
+Real client action (operator opened the FUT Store on `.105`, 2026-08-12). Only one
+`/store/purchasegroup` request occurred after the capture marker
+`2026-08-12T23:54:01Z`, so attribution is unambiguous (only the operator drives the
+client). Log via `docker logs --since 2026-08-12T23:54:01Z --timestamps openfut-fut-backend`.
+
+- **Request:** `23:54:43  GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true`
+  (Host `10.10.0.120:8099`, `User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)`,
+  `X-UT-SID` present). Preceded at 23:54:43 by `GET /ut/game/fifa17/user/credits`
+  → `200 {"credits": 29876776, ...}`.
+- **Response:** `200`. The server log truncates the body to 200 bytes
+  (`utas_server.py:3754`, `raw[:200]`), genuine prefix:
+  `{"purchase": [{"assetId": 1, "id": 1, "packType": "BRONZE", "description": "Bronze Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount`
+- **Full body recovered** by running the exact running-container code
+  (`docker exec openfut-fut-backend python3 -c "import utas_server as u; u.store_catalog(None)"`)
+  over the live `/state` profile, under the live flags (confirmed in-process:
+  `STORE_DISPLAYGROUP=True`, `STORE_GROUPID=False`). Its `json.dumps(...)[:200]`
+  equals the genuine logged 200-byte prefix **byte-for-byte** (verified MATCH), so the
+  reconstruction IS the sent body (deterministic pure function + verified prefix). No
+  request was synthesized, replayed, or curl'd. Full body (2841 bytes) preserved
+  verbatim at `docs/evidence/store_purchasegroup_capture_2026-08-12.json`.
+- **Operator-reported client behavior:** on opening the store, an error dialog
+  appeared — *"The pack you've selected is currently not available. Please select a
+  different pack or try again later."* — and clicking OK returned to the FUT hub. No
+  tiles were browsable; **no "unknown" tiles were reported**. There was **no**
+  `PUT /store/transaction` (no buy) and **no server error** (server answered `200`).
+
+## 5. Definition analysis (Phase 4/5) — OBSERVED
+
+`purchase[]` = 5 entries (`timestamp` 1596326400). No `cardsubtypeid`/`carddbid`/
+`cardassetid` in any entry (packs, not cards).
+
+| idx | id | assetId | packType | description | displayGroup.value | priority | state | dgAssetId | classification |
+|---|---|---|---|---|---|---|---|---|---|
+| 0 | 1 | 1 | BRONZE | Bronze Pack | `bronze` | — | active | absent | KNOWN TOKEN |
+| 1 | 5 | 5 | GOLD | Gold Pack | `gold` | — | active | absent | KNOWN TOKEN |
+| 2 | 6 | 6 | GOLD | Premium Gold | `gold` | — | active | absent | KNOWN TOKEN |
+| 3 | 7 | 7 | GOLD | Special Players Pack | `special` | — | active | absent | KNOWN TOKEN |
+| 4 | 65534 | 65534 | GOLD | "" (empty) | `mypacks` | 1 | **inactive** | absent | KNOWN TOKEN |
+
+Per-pack fields (idx 0-3 identical shape): `saleType:"promo"`, `limitType:"NONE"`,
+`quantity:0`, `purchaseLimit:0`, `purchaseCount:0`, `isPremium:false`,
+`currencies:[{"name":"coins","funds":<price>,"finalFunds":<price>}]`,
+`extPrice:{finalPrice/originalPrice:{amount:<price/100>,currency:"mtx"}}`,
+`packContentInfo:{...tier quantities...}`, `unopened:false`. Prices: Bronze 400,
+Gold 5000, Premium Gold 15000, Special Players 25000. The sentinel (idx 4) drops
+`currencies`/`extPrice`, has empty description, `state:"inactive"`.
+
+**Unique `displayGroup.value` set emitted: `{bronze, gold, special, mypacks}`.**
+Compared to the six client renderer tokens `{mypacks, points, bronze, silver, gold,
+special}` (`FUN_180014580`/`FUN_180014df0`, `plan-2026-08-05-store-subsystem.md:202-206`):
+**every emitted token is a KNOWN token; the set outside the renderer categories is
+EMPTY.**
+
+## 6. Unmapped definitions / suspect tokens found — OBSERVED
+
+None. Zero SUSPECT/UNKNOWN `displayGroup.value` tokens; zero card definitions;
+zero `cardsubtypeid`/`carddbid`/`cardassetid`. The only anomalous element is the
+**inactive, empty-description `mypacks` sentinel** (idx 4), emitted by
+`store_catalog:3428-3446` **only when the profile owns zero unopened packs**
+(OBSERVED: profile `unopenedPackIds == []`).
+
+## 7. Client-side evidence (Phase 7) — existing RE only
+
+No new Ghidra run. Existing decompiler evidence already bounds the answer and shows
+new static analysis would be unproductive:
+- **The parser is not the gate** (`OPENCODE_ENDPOINT_PROMPT.md:118-120`): per-pack
+  epilogue `0x18013badc` pushes every parsed pack unconditionally — no drop predicate
+  in the parse path. So a `200` with clean JSON cannot be rejected by the deserializer.
+- **Store-level "not available"** (`FUT_CatalogNotAvailable`, msg `0x7550`) comes from
+  downstream client gates (`OPENCODE_ENDPOINT_PROMPT.md:120-131`): (1) resolution
+  `GetSystemMetrics` ≤1024×768, (2) store-data-model load status `0x180013cf0`,
+  (3) Blaze purchase-config flags `IS_STORE_ENABLED/IS_COIN_PURCHASABLE/...` (these
+  are already served, `blaze_responder_v3b.py:708-719`).
+- **Per-pack tile-availability predicate is in the PACKED FIFA17.exe and UNREAD**
+  (`plan-2026-08-05-pack-opening.md:553`): fields `state/saleType/quantity/
+  purchaseLimit/purchaseCount/start/end` are parsed and copied to the tile, but the
+  predicate that greys/blocks a tile "is in the packed exe and unread." Whether
+  `purchaseLimit`+`purchaseCount` greys a tile is explicitly an OPEN question
+  (`:644-645`). Static Ghidra on the packed exe cannot read it (decrypts only in live
+  memory); resolving it requires a live-memory experiment on the running FIFA process,
+  which is out of scope (must not touch FIFA).
+- The exact operator string *"The pack you've selected is currently not available"*
+  is **not present** anywhere in the recon corpus (docs/tools); the documented
+  store/pack error strings are `FUT_CatalogNotAvailable` and
+  `CARDS_CB_ERR_PACK_NOT_IN_DIME` (a server-returnable code). UNKNOWN loc key.
+
+## 8. Assessment (Phase 8) — runtime verdict
+
+- **H1 (subtype/definition): CONTRADICTED.** The captured response contains no card
+  definitions and no `cardsubtypeid`/`carddbid`/`cardassetid` (OBSERVED §4-§5).
+- **H2 (unknown `displayGroup.value` token): CONTRADICTED.** Every emitted token is a
+  KNOWN renderer category (`bronze/gold/special/mypacks`); the unsupported-token set
+  is EMPTY (OBSERVED §5). The store-tile "unknown" mechanism is NOT reproduced under
+  the current config (`STORE_DISPLAYGROUP=ON`).
+
+Answering the Phase-8 questions:
+1. **Unsupported `displayGroup.value` in the response?** No — all four tokens
+   (`bronze/gold/special/mypacks`) are recognized. (OBSERVED)
+2. **Which pack got it?** None. (OBSERVED)
+3. **Correspond to an unknown tile in FIFA?** No unknown tile was reported; the
+   observed symptom was a *"pack not available"* dialog, not an unknown tile. (OBSERVED)
+4. **Where does the backend assign the token?** `_pack_body:3373-3379` maps each pack
+   to `special/gold/silver/bronze` from `specialChance`/`gold`; owned/sentinel →
+   `mypacks` (`:3336`). All canonical. (OBSERVED)
+5. **Is `displayGroup.value` sufficient to explain the bug?** No. The response is
+   clean; the failure is a downstream client/packed-exe gate, not a token. (INFERRED)
+6. **Is the server emitting a value FIFA demonstrably cannot understand?** No.
+   (OBSERVED)
+7. **Narrowest likely fix (REPORT ONLY — not implemented):** The single anomalous,
+   server-controllable element is the **inactive empty `mypacks` sentinel** emitted
+   when `unopenedPackIds == []` (`store_catalog:3428-3446`). Leading HYPOTHESIS: with
+   no owned packs, the store's My-Packs group contains only this inactive pack, and
+   the client's (packed-exe) selection/availability path lands on it →
+   *"the pack you've selected is currently not available"* → back to hub. Narrowest
+   candidate fixes to TEST (each needs a controlled change, hence a future
+   restart-gated experiment — do NOT implement now):
+   (a) suppress the sentinel when there are no owned packs and instead let the store
+       land on a real active category (bronze/gold/special); or
+   (b) if My-Packs must resolve, make the sentinel non-selectable rather than an
+       `inactive` pack in the group.
+   Cheaper-to-eliminate CLIENT-side cause to check first (existing RE, no server
+   change): FIFA display resolution must be **>1024×768** on `.105`
+   (`OPENCODE_ENDPOINT_PROMPT.md:122-124`).
+
+**Overall runtime verdict: CONTRADICTED** — neither H1 nor H2 reproduces; the
+"unknown store tile" hypothesis is not the live failure. The live failure is a
+distinct *pack-availability* error whose trigger is in the packed FIFA17.exe and
+cannot be pinned from the (clean) server response alone.
+
+## 9. Open questions
+1. What exactly raises *"The pack you've selected is currently not available"*? The
+   loc key is unknown and the predicate is in the packed exe (unread). Resolving it
+   needs a controlled field/flag experiment or live-memory RE (both currently gated).
+2. Does the store, with `unopenedPackIds == []`, land on / auto-select the inactive
+   `mypacks` sentinel? (HYPOTHESIS §8.7; unproven without client-side observation.)
+3. Did the store render tiles successfully in earlier sessions when the profile
+   owned unopened packs (e.g. the 21:54-21:57 pack-opening burst)? If so, the
+   presence/absence of owned packs (sentinel) is implicated. (UNKNOWN — earlier logs
+   truncate the body; not proven.)
+4. Does `purchaseLimit:0`/`purchaseCount:0` grey a tile? Existing RE lists this as an
+   OPEN question; would need a controlled experiment. (UNKNOWN)
+5. Is bug 6c ("unknown tile") a stale symptom from before `STORE_DISPLAYGROUP` became
+   the default `ON`? Under the current config no unknown tile reproduces.
+
+---
+
+## H3 — EMPTY MY-PACKS SENTINEL (HYPOTHESIS)
+
+When the profile owns zero unopened packs (`unopenedPackIds == []`), OpenFUT emits
+synthetic **inactive** pack id **65534** in the `mypacks` display group
+(`store_catalog:3428-3446`). The FIFA 17 store may treat this object as a selectable
+pack whose availability predicate fails, producing *"The pack you've selected is
+currently not available"* and returning the user to the FUT Hub before any
+`/store/transaction`. **Status: HYPOTHESIS (untested).**
+
+## 10. Resolution check (Phase 1) — OBSERVED
+
+Read-only inspection of `.105` (FIFA pid 529227, not touched):
+- Desktop/monitor: **2560x1440** — DRM connectors `card1-DP-2` and `card1-HDMI-A-1`
+  both `connected`, native mode 2560x1440; compositor KDE `kwin_wayland` (no gamescope).
+- FIFA render config: `…/Games/umu/fifa17/pfx/drive_c/users/steamuser/Documents/FIFA 17/settings/overrideAutodetect.lua`
+  → `ResolutionWidth = 1280`, `ResolutionHeight = 720`, `FullscreenEnabled = 0` (windowed).
+- Session: Wayland (`WAYLAND_DISPLAY=wayland-0`), FIFA via XWayland (`DISPLAY=:0`,
+  `XAUTHORITY=/run/pressure-vessel/Xauthority` inside the game namespace).
+
+**Is FIFA rendering above 1024x768? YES (1280x720).**
+**Resolution hypothesis eliminated for this reproduction.**
+
+## 11. Sentinel 65534 provenance (Phase 3)
+
+1. **Basis:** **OpenFUT INVENTION** (OBSERVED). `65534` (0xFFFE) appears nowhere in
+   any EA capture or recon note — repo-wide it exists only in `utas_server.py`
+   (`store_catalog:3435-3446`) and this evidence set. The author's comment
+   (`:3428-3434`) states it is a workaround: "Retain an inactive zero-item sentinel so
+   the [`mypacks`] destination resolves… Its id is deliberately absent from
+   PACK_CATALOG." It is a compatibility guess, not captured behavior.
+2. **Known-good EA capture of EMPTY My Packs:** **UNKNOWN** — none found. All recon
+   My-Packs analysis is client-side RE (`FUN_1800150d0` filters
+   `displayGroup.value=="mypacks"`, `plan-2026-08-05-pack-opening.md:34-36,893-895`);
+   no EA server response for an empty My Packs state is on record.
+3. **Known-good response with ≥1 unopened pack:** **UNKNOWN** for EA. OpenFUT's own
+   seed grants reward pack id 70 (`_new_profile` `unopenedPackIds:[70]`,
+   `fut_store.py:360`), but that is an OpenFUT synthetic grant, not an EA capture.
+4. **Evidence FIFA EXPECTS a sentinel/placeholder:** **NO / UNKNOWN.** Recon shows My
+   Packs is a client-side filter over the ordinary catalogue; the "empty-category
+   dialog over the wrong tab" concern behind the sentinel is the author's HYPOTHESIS,
+   not decompiler-confirmed. No evidence FIFA requires a placeholder object.
+5. **Evidence for the `inactive` representation:** **UNKNOWN / HYPOTHESIS.** The claim
+   "state != active keeps it out of the visible row list" (`:3432`) is an unverified
+   author assumption; no RE shows `state:"inactive"` hides a pack from selection. If
+   FIFA does NOT hide it, the sole `mypacks` entry is a selectable inactive pack —
+   exactly the H3 failure mode.
+
+## 12. Empty vs non-empty My Packs behavior (Phase 2) — OBSERVED (code) / captured
+
+`store_catalog(h)` (`utas_server.py:3421-3447`):
+- Always emits the 4 non-`ownedOnly` catalogue packs (ids 1,5,6,7) via `_pack_body`.
+- For each id in `visible_unopened_packs()` (= `STORE.unopened_packs()` +
+  `_OPENED_PACK_GRACE`) that resolves in `PACK_CATALOG`, appends `_pack_body(owned,
+  idx, owned=True)`.
+- **Only when `unopened_packs()` is empty (`if not owned_ids`)** appends the inactive
+  sentinel (`:3428-3446`).
+
+Sentinel 65534 vs a normal active pack (Bronze, idx 0), field-by-field (from the
+captured body):
+
+| field | sentinel 65534 | Bronze Pack (active) |
+|---|---|---|
+| id | 65534 | 1 |
+| assetId | 65534 | 1 |
+| packType | GOLD | BRONZE |
+| description | "" (empty) | "Bronze Pack" |
+| state | **inactive** | active |
+| saleType | promo | promo |
+| limitType | NONE | NONE |
+| quantity | 0 | 0 |
+| purchaseLimit | 0 | 0 |
+| purchaseCount | 0 | 0 |
+| isPremium | false | false |
+| sortPriority | 1 | 1 |
+| currencies | **ABSENT** (popped) | `[{coins,400,400}]` |
+| extPrice | **ABSENT** (popped) | `{mtx 4/4}` |
+| packContentInfo | all-zero quantities | bronze 5 / item 5 |
+| unopened | false | false |
+| displayGroup.value | **mypacks** | bronze |
+| displayGroup.priority | 1 | ABSENT |
+| displayGroupAssetId | ABSENT | ABSENT |
+
+**What changes when `unopenedPackIds` is non-empty (e.g. `[70]`):** the sentinel is
+NOT emitted; instead pack 70 (Reward Special Players Pack, `ownedOnly`) appears via
+the owned branch of `_pack_body` (`:3335-3336`): `displayGroup={"value":"mypacks",
+"priority":idx}`, `state:"active"` (default), `unopened:true`, `currencies`/`extPrice`
+popped. i.e. the `mypacks` group would hold a genuine **active** owned pack instead of
+the inactive sentinel.
+
+## 13. Proposed controlled experiments (Phase 5) — DESIGN ONLY, NOT EXECUTED
+
+### Existing grant mechanism (Phase 4)
+- **Supported profile-only method: YES** — `Store.grant_unopened_pack(pack_id)`
+  (`fut_store.py:635-643`): validates the id is in `PACK_CATALOG`, appends to
+  `unopenedPackIds`, persists; reverts via `consume_unopened_pack` (`:623-633`).
+  Modifies **only** profile state; cleanly reversible.
+- **BUT restart IS required to take effect.** `Store.load()` caches `self._p`
+  (`:370-372`); **no route calls `grant_unopened_pack` or `select_account`**, and
+  `select_account` only re-reads on a persona *change*. So an out-of-process grant or
+  a raw profile-file edit writes disk but the **running server keeps serving its
+  cached `unopenedPackIds`** until the process reloads. There is no SIGHUP/reload
+  endpoint. Therefore any profile change needs a container restart to be observed.
+
+### Experiment A — Non-empty My Packs (PREFERRED; least invasive)
+- **State change:** set the profile's `unopenedPackIds` to `[70]` (edit
+  `…/state/accounts/33068179/fifa17_profile.json`, or call
+  `STORE.grant_unopened_pack(70)`), **store code/config unchanged**.
+- **Restart required?** **YES** — profile cache (above). Profile-only; no code edit.
+- **Rollback:** set `unopenedPackIds` back to `[]` (or `consume_unopened_pack(70)`),
+  restart. (Also restore `nextItemId`/coins only if a pack is actually opened — the
+  grant alone touches only `unopenedPackIds`.)
+- **Expected `purchasegroup` difference:** sentinel 65534 GONE; instead one active
+  pack id 70 in the `mypacks` group (`state:active`, `unopened:true`); hub/credits
+  report `recoveredPacks:1`.
+- **Expected client observation:** if H3 is correct, the immediate *"pack not
+  available"* dialog should NOT fire (or behavior changes) and My Packs should show a
+  real pack. If the dialog still fires identically, H3 is weakened and the cause is
+  elsewhere (packed-exe predicate / another field).
+
+### Experiment B — Suppress the empty sentinel (only if A is inconclusive)
+- **Change:** in `store_catalog` (`:3428-3446`), when `unopened_packs()` is empty, do
+  NOT append pack 65534 (emit no `mypacks` entry). **Code change ⇒ restart. NOT
+  authorized.** Narrowest patch: guard/remove the `if not owned_ids:` sentinel block.
+- **Purpose:** distinguishes "the inactive sentinel is selected and fails" (A already
+  tests the inverse) from "an absent `mypacks` group causes a different failure"
+  (the original author's stated fear at `:3429-3431`).
+
+### Experiment C — Alternate sentinel representation (design only)
+- If evidence later shows FIFA expects an empty `mypacks` group represented
+  differently (e.g. present-but-not-a-pack, or `state` other than `inactive`), adjust
+  the sentinel shape. **DESIGN ONLY; DO NOT IMPLEMENT.** No current evidence specifies
+  the correct empty-group representation (see §11.4-11.5).
+
+Note: both A and B require a restart (A for the profile cache, B for the code). A is
+strictly less invasive (profile-only, clean rollback, no code change) and is the
+preferred next experiment. Neither is authorized yet.
+
+---
+
+## 14. Experiment A — Non-empty My Packs (EXECUTED 2026-08-13) — OBSERVED
+
+Authorized controlled test of H3: change ONLY the profile's `unopenedPackIds`
+(`[] → [70]`), restart the FUT backend once, capture a genuine FIFA store request,
+then roll back. No store code/config/flags/PACK_CATALOG/pack-70/sentinel-code
+changed; FIFA not modified/restarted; operator drove the client.
+
+### 14.1 Baseline profile state
+- Path: `fifa17-recon/docker/state/accounts/33068179/fifa17_profile.json` (persona
+  33068179/CAGE; proven live: `STORE.path` in-process = `/state/accounts/33068179/
+  fifa17_profile.json`, coins 29876776 matching the live `/user/credits`).
+- `unopenedPackIds == []`. Original SHA-256
+  `39bb3e833fa55287d8516815ba3a717b41c0f0c7a7c41d20503f3a55c65cc6e7`. Backup:
+  `/tmp/fifa17_profile.33068179.ORIG.20260813T001228Z.json` (same hash).
+
+### 14.2 State change
+- Narrow anchored edit of line 97070 only: ` "unopenedPackIds": [],` →
+  ` "unopenedPackIds": [70],`. Diff vs backup = exactly one line; semantic diff =
+  only key `unopenedPackIds` (`[] → [70]`), all other 24 keys identical. Modified
+  SHA-256 `2b5760baa265f320904de2d23fd6ab374733efe74cb0756c3be39c083bce4ac8`.
+  (Used the direct edit rather than `grant_unopened_pack(70)` to avoid whole-file
+  reserialization; net semantic effect is identical.)
+
+### 14.3 Restart
+- `docker restart openfut-fut-backend` (Pid 1398009→1548312, StartedAt
+  2026-08-12T16:40:52Z → 2026-08-13T00:13:54Z). Bridge/Core and Rust hosts untouched.
+  This container bundles blaze/roster/utas/pow (per `entrypoint.sh`); all rebound.
+- Post-restart in-process check: `STORE.load()['unopenedPackIds'] == [70]`;
+  `store_catalog(None)` → pack 70 present, sentinel 65534 absent.
+
+### 14.4 Genuine FIFA capture
+- Marker `2026-08-13T00:14:24Z`. Single request after it (unambiguous):
+  `00:14:58  GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true → 200`.
+  **No `/store/transaction`, no `/purchased/items`** in the window (pack 70 not opened).
+- Full body recovered from the running code over the live [70] profile; its
+  `[:200]` matches the genuine logged 200-byte prefix byte-for-byte (verified MATCH).
+  Preserved at `docs/evidence/store_purchasegroup_capture_mypacks70_2026-08-12.json`.
+
+### 14.5 Client-observed behavior (operator report)
+1. Store remains open: **YES**.
+2. "The pack you've selected is currently not available": **NO (gone)**.
+3. My Packs category / unopened reward pack visible: **YES**.
+4. Returned to FUT Hub: yes (normal navigation; not forced by an error dialog).
+
+### 14.6 Response diff (baseline 2026-08-12 vs experiment)
+Only difference across all 5 entries:
+- **Removed:** id `65534` (`state:inactive`, `displayGroup:mypacks`, `description:""`).
+- **Added:** id `70` (`state:active`, `displayGroup:mypacks`,
+  `description:"Reward Special Players Pack"`, `unopened:true`).
+- Packs 1/5/6/7 byte-identical. Classification: **all EXPECTED FROM UNOPENED PACK
+  STATE; nothing UNEXPECTED.**
+
+### 14.7 H3 assessment — **SUPPORTED**
+65534 disappeared AND pack 70 replaced it as a real My Packs entry AND the
+"pack not available" / store-exit behavior disappeared → per the pre-registered
+criterion, **H3 is strongly SUPPORTED**. The failure is tied to the My Packs group
+content when the profile owns zero unopened packs.
+
+Sub-hypothesis resolution:
+- **H3c (failure unrelated to My Packs): RULED OUT.** A My-Packs-only profile change
+  (no store code/config change) eliminated the failure.
+- **H3a (the inactive sentinel object itself is the trigger) vs H3b (empty My Packs
+  state generally is the trigger): NOT DISTINGUISHED by Experiment A.** The change
+  simultaneously (i) removed the inactive sentinel and (ii) supplied a real active
+  owned pack. Either "presence of the inactive/empty sentinel" or "absence of any
+  real owned pack" could be the cause. Distinguishing them requires Experiment B
+  (empty `unopenedPackIds` AND suppress the sentinel so `mypacks` has no entry): if
+  that also fixes it → H3a (sentinel object was the problem); if it re-breaks or
+  changes → H3b (empty My Packs itself is the problem). Experiment B is a code change
+  (restart-gated) and remains unauthorized.
+
+### 14.8 Rollback verification
+- Profile restored from backup → SHA-256 `39bb3e83…` == original (byte-identical);
+  `unopenedPackIds == []`. Disk was unmutated during the test (still `2b5760ba…`
+  before rollback → store reads don't persist; pack 70 never opened).
+- `docker restart openfut-fut-backend` (Pid 1549503, StartedAt 2026-08-13T00:16:56Z).
+  Post-restart in-process: `unopenedPackIds == []`, sentinel 65534 present again,
+  pack 70 absent → runtime baseline restored. Bridge/Core untouched.
+
+**H3 status: SUPPORTED (H3c ruled out; H3a vs H3b open).** No permanent fix
+implemented.
+
+---
+
+## 15. Experiment B — Empty My Packs Without Sentinel (EXECUTED 2026-08-13) — OBSERVED
+
+### 15.1 Purpose
+Distinguish **H3a** (the synthetic inactive sentinel 65534 itself is the trigger)
+from **H3b** (FIFA cannot tolerate an empty My Packs state even without a sentinel).
+Hold `unopenedPackIds == []` constant; change ONLY: sentinel 65534 emitted →
+suppressed. Authorized TEMPORARY code change, reverted after test.
+
+### 15.2 Baseline
+Profile `unopenedPackIds == []` (SHA-256 `39bb3e83…`, unchanged throughout). Running
+code before patch = `c89d43ea…` (host repo == container copy). Sentinel 65534 emitted.
+
+### 15.3 Temporary patch — **TEMPORARY EXPERIMENT B PATCH, NOT A PERMANENT FIX**
+Applied to the **container** copy `/app/tools/utas_server.py` only (the container
+mounts `/state`, not `/app`; host repo `fifa17-recon/tools/utas_server.py` was NOT
+edited — its git diff stayed empty). Single line, `store_catalog` (line 3428):
+```
+-    if not owned_ids:
++    if False:  # TEMP EXPERIMENT B PATCH -- suppress synthetic sentinel 65534 (NOT A PERMANENT FIX)
+```
+Semantic effect: when `unopened_packs()` is empty, append nothing (no sentinel, no
+replacement object). Normal packs 1/5/6/7 (appended earlier) unchanged. Diff vs the
+backed-up original = exactly this one line. Patched code SHA-256 `5bb8fca9…`.
+
+### 15.4 Restart verification
+`docker restart openfut-fut-backend` (Pid 1549503→1551026, StartedAt
+2026-08-13T00:20:45Z). The writable-layer edit survived the restart; running
+`/app/tools/utas_server.py` = `5bb8fca9…` (patched). In-process: `unopenedPackIds ==
+[]`; `store_catalog` → 4 packs {1,5,6,7}, **no 65534, no 70, no `mypacks` entry**.
+Flags unchanged (`DISPLAYGROUP=ON`, `GROUPID=OFF`). Bridge/Core/Rust untouched.
+
+### 15.5 Genuine FIFA capture
+Marker `2026-08-13T00:20:55Z`. Request sequence (operator opened the store):
+`00:21:05 GET /hub` → `00:21:07 GET /user/credits` → `00:21:07 GET
+/store/purchasegroup/all?ppInfo=true → 200`. **No `/store/transaction`; no further
+requests** (client crashed after receiving the store body). Full body recovered from
+the running patched code; `[:200]` matches the genuine logged prefix byte-for-byte
+(verified MATCH). Preserved at
+`docs/evidence/store_purchasegroup_capture_empty_no_sentinel_2026-08-12.json`
+(4 packs {1,5,6,7}, no `mypacks` group).
+
+### 15.6 Client behavior (operator report)
+**The game CRASHED** on opening the store. Not the baseline dialog; a hard crash. No
+`/store/transaction` was issued.
+
+### 15.7 Three-way response comparison
+| capture | ids present | `mypacks` group entry | client outcome |
+|---|---|---|---|
+| Baseline (`…_2026-08-12.json`) | 1,5,6,7,**65534** | 65534 `inactive`, desc "" | "pack not available" dialog → Hub |
+| Exp A (`…_mypacks70_…json`) | 1,5,6,7,**70** | 70 `active`, "Reward Special Players Pack" | **works** — store open, My Packs visible |
+| Exp B (`…_empty_no_sentinel_…json`) | 1,5,6,7 | **none** | **CRASH** |
+Normal packs {1,5,6,7} identical across all three.
+
+### 15.8 H3a / H3b verdict
+- **H3a (sentinel object itself is the trigger): CONTRADICTED.** Removing the
+  sentinel did NOT restore the store; it produced a *worse* outcome (crash). If the
+  sentinel object were the sole cause, its removal would yield a working store (it
+  did not).
+- **H3b (FIFA cannot tolerate an empty My Packs state): SUPPORTED.** Only Exp A — a
+  real **active** owned pack in `mypacks` — worked. Both the inactive sentinel
+  (graceful "pack not available" dialog) and the total absence of any `mypacks` entry
+  (crash) fail. The sentinel is a **load-bearing workaround** that *downgrades* the
+  failure from a crash to a dialog but does not fix it.
+- **Pre-registered-rule nuance:** Exp B produced a *distinct* failure (crash), which
+  the pre-registered rules classify as **B3 (different failure)** rather than the
+  exact B2 dialog. Documented as such: the crash is a THIRD failure mode. It still
+  resolves the question — it rules out H3a and supports H3b — but the specific
+  outcome (crash, not the same dialog) is stronger than B2 anticipated. Not forced
+  into a clean binary beyond what the evidence shows.
+
+**Does FIFA tolerate an empty My Packs without the sentinel? NO — it crashes.**
+
+### 15.9 Rollback verification
+- Container `/app/tools/utas_server.py` restored from backup → SHA-256 `c89d43ea…`
+  == pre-experiment (byte-identical); the `if False:` patch fully removed.
+- `docker restart openfut-fut-backend` (final Pid 1551901,
+  StartedAt 2026-08-13T00:22:04Z). In-process: `unopenedPackIds == []`, sentinel
+  65534 emitted again, pack 70 absent; `DISPLAYGROUP=ON`, `GROUPID=OFF`.
+- Host repo `fifa17-recon/tools/utas_server.py` never edited (git diff empty, SHA-256
+  `c89d43ea…`). Profile unchanged (`39bb3e83…`). Bridge/Core/Rust untouched.
+
+### 15.10 Likely permanent fix (REPORT ONLY — not implemented)
+Evidence: the store's `mypacks` group must contain a **valid, active, openable owned
+pack**; both an inactive sentinel and an absent group fail (dialog / crash). The only
+working configuration observed is a genuine active owned pack (Exp A). Candidate
+directions (report only, each needs design + authorization):
+1. Ensure the profile always owns ≥1 legitimate active unopened pack while the store
+   is shown (e.g. keep a real reward pack such as id 70 granted), so `mypacks` is
+   never empty — this matches the only known-working state but changes economy state
+   and needs a lifecycle policy (what happens after the user opens it).
+2. Change what `store_catalog` advertises so FIFA never lands on / requires a
+   `mypacks` group when there are zero owned packs (client-compatible empty-store
+   representation) — the correct representation is UNKNOWN; neither current option
+   (inactive sentinel / no group) is it, so this needs new client-side RE before
+   implementation.
+Recommendation: do NOT simply delete the sentinel (Exp B proves that crashes). No fix
+implemented.
+
+**H3 status: SUPPORTED. H3a CONTRADICTED, H3b SUPPORTED (Exp B crash = third failure
+mode; empty My Packs is the root problem). Sentinel is a load-bearing workaround.**
+
+---
+
+## 16. Experiment C′ — Active Non-Openable Placeholder (EXECUTED 2026-08-13) — OBSERVED
+
+Question: can the required `mypacks` group be kept structurally valid with an
+**active** placeholder that stays impossible to open/purchase? Change exactly one
+field of sentinel 65534: `state "inactive" → "active"`. Profile untouched
+(`unopenedPackIds==[]`); 65534 kept absent from `PACK_CATALOG`.
+
+### 16.1 Server-side safety proof (OBSERVED, code)
+65534 cannot grant value regardless of `state` — pack resolution is by
+`pack_by_id(id)` over `PACK_CATALOG` (ids 1,5,6,7,70), independent of the display
+`state`:
+- `store_buy` (PUT `/store/transaction`, `:3460-3465`): `pack_by_id(65534)=None` →
+  `if not pack: return 200, {}` (no `open_pack`, no coin change).
+- `purchased_items` (POST, `:3494-3496`): `pack_by_id(65534)=None` →
+  `return 200, {"itemData": STORE.last_pack()}` (stale prior items only; no new
+  grant, no `open_pack`, no `consume_unopened_pack`).
+- `open_pack`/`consume_unopened_pack` are unreachable for 65534 (pack resolves to
+  None first). Precondition PASSED.
+
+### 16.2 Baseline / patch
+Baseline: profile `39bb3e83…`, code `c89d43ea…` (host==container), sentinel
+`inactive`/`mypacks`, 65534∉catalog, flags `DISPLAYGROUP=ON`/`GROUPID=OFF`.
+Temporary container-only patch (host repo untouched), line 3444:
+`empty["state"] = "inactive"` → `empty["state"] = "active"`. Diff vs original = this
+one line; patched code `e1a4e1dc…`. **TEMPORARY EXPERIMENT C′ PATCH — NOT A PERMANENT
+FIX.**
+
+### 16.3 Restart / runtime
+`docker restart openfut-fut-backend` (Pid 1556305, StartedAt 00:38:51Z). Running code
+`e1a4e1dc…`; `unopenedPackIds==[]`; sentinel `65534 state=active unopened=False
+dg=mypacks desc=""`; 65534∉catalog; normal packs 1/5/6/7 active; 70 absent; flags
+unchanged.
+
+### 16.4 Genuine FIFA capture
+Marker `2026-08-13T00:38:53Z`. FIFA relaunched (Exp-B crash had closed it) → booted to
+hub. Three genuine store fetches: `00:39:44`, `00:40:26`, `00:41:23`
+(`GET /store/purchasegroup/all?ppInfo=true → 200`), reconstructed body prefix-matches
+the logged 200-byte prefix (verified). Saved
+`docs/evidence/store_purchasegroup_capture_active_placeholder_2026-08-12.json`.
+C′-vs-baseline full JSON diff = **only** `65534.state: "inactive" → "active"`.
+
+### 16.5 UI observation (operator report)
+1. **No crash** (game launched to hub).
+2. **No "pack not available" dialog.**
+3. Store remains open.
+4. My Packs tab **not shown while inside the Store (Browse Packs)**.
+5. Via the FUT-hub **My Packs** menu: **one pack tile with no cover, "0 items, 0
+   bronze, 0 rares"** (the placeholder renders as a visible empty pack).
+6. Navigation: from the hub **My Packs** menu → Bronze/Gold/Special reachable; but
+   from the **Browse Packs** (Store) entry, Bronze/Gold/Special are **not reachable
+   until My Packs is opened first**.
+
+### 16.6 Passive request sequence (OBSERVED)
+Boot: `.../accountinfo → /ut/auth → settings → phishing → match/reset → userMassInfo
+→ PUT store/transaction/0 → hub …`. The single `/store/transaction` is the routine
+**boot** call with body `{"state":"TRANSACTIONCANCEL"}` → `200 {}` (no packId), fired
+at 00:39:39 **before** any store fetch. Across all three store opens: **no
+`/store/transaction`, no `/purchased`, and no request referencing 65534.** The active
+placeholder did NOT cause FIFA to auto-submit any transaction/open.
+
+### 16.7 Availability result / verdict
+**Result C1 (strong positive) — ACTIVE PLACEHOLDER HYPOTHESIS SUPPORTED, with UX
+caveats.** `state` participates materially: with `state:"active"` the group exists
+(no crash, as in baseline) AND the availability path is satisfied (no
+"pack not available" dialog, unlike baseline). So **C2 is refuted** — `state` is a
+deciding field for the dialog. But it is **not a clean permanent fix**:
+- the placeholder renders as a **visible empty pack tile** ("0 items"), i.e. a fake
+  pack a user could try to open (server-safe: opening → no-op `{}` / stale
+  `last_pack`, but confusing UX);
+- **navigation caveat #6**: from Browse Packs the other categories are gated behind
+  opening My Packs first — an UNEXPECTED behavior not present with a genuine owned
+  pack (Exp A).
+
+### 16.8 Rollback verification
+Container code restored from backup → `c89d43ea…` (== host, == pre-experiment); the
+`state` change removed. `docker restart` (Pid 1557831, StartedAt 00:43:04Z).
+In-process: `unopenedPackIds==[]`, sentinel `state=inactive`, 65534∉catalog, 70
+absent, flags `DISPLAYGROUP=ON`/`GROUPID=OFF`. Host repo `utas_server.py` never edited
+(`c89d43ea…`, git diff empty). Profile `39bb3e83…` unchanged. Bridge/Core untouched.
+
+### 16.9 Implications for the client contract
+`state:"active"` satisfies the pack-availability predicate (no dialog) while the
+group's existence prevents the crash — so an active non-openable placeholder is the
+first representation that neither crashes nor shows the dialog. However it exposes a
+**visible empty "pack"** and a **Browse-Packs navigation gate** (#5/#6), so it is NOT
+adopted. **Permanent fix NOT established.** Open follow-ups: (a) what happens if the
+user explicitly selects/opens the active placeholder (a later controlled test —
+server-safe per §16.1 but UX-unknown); (b) whether a count-gated My-Packs default or a
+representation that avoids rendering a fake tile can remove the empty-tile/navigation
+artifacts. Do NOT adopt `state:"active"` as the fix on this evidence alone.
+
+---
+
+## 17. Explicit Active-Placeholder Selection Test (EXECUTED 2026-08-13) — OBSERVED
+
+**Purpose:** with the C′ active placeholder in place, characterize what happens when
+the user *explicitly opens* the empty 65534 My-Packs tile (the last open backend-side
+question).
+
+**Server safety proof (re-confirmed, code `c89d43ea`):** `pack_by_id(65534)=None`;
+65534∉PACK_CATALOG∉unopenedPackIds. `store_buy`→`200 {}`; `purchased_items`→
+`200 {"itemData": last_pack}` (stale). No inventory/coin/profile mutation possible.
+
+**Temporary C′ state:** container-only one-line patch `65534.state "inactive"→"active"`
+(patched `e1a4e1dc…`), restart (Pid 1560774). `unopenedPackIds=[]`, 65534
+active/mypacks/∉catalog, normal packs unchanged, flags ON/OFF, host code + profile
+unchanged. Marker `2026-08-13T00:53:09Z`.
+
+**Manual selection behavior (operator report):** opened FUT → My Packs → the empty
+placeholder tile visible → selected/opened it ONCE:
+1. Dialog: **YES**. 2. Exact text: **"This pack is no longer available"**.
+3. Stays in My Packs: yes. 4. After closing the dialog → returns to My Packs.
+5. Then navigates back to the FUT Hub successfully. 6. **No crash.** 7. No spinner.
+8. **Navigation remains fully usable afterward.**
+
+**Genuine request sequence (OBSERVED, marker `00:53:09Z`):** boot (`…/auth →
+userMassInfo → PUT store/transaction/0 {"state":"TRANSACTIONCANCEL"}→200 {} → hub →
+credits → purchasegroup`) then navigation (`hub→credits→purchasegroup` ×2 for the
+store/My-Packs views). **The explicit tile selection generated NO server request** —
+no `/store/transaction`, no `/purchased/items`, and NO reference to 65534 anywhere.
+The "no longer available" verdict is rendered **client-side**.
+
+**Result class: S1 — pure client-side rejection.**
+
+**Post-test profile/economy integrity (OBSERVED):** coins 29876776, nextItemId
+100004837, items 1995, purchased 0, `unopenedPackIds` `[]`, `last_pack` empty — ALL
+unchanged vs pre-test; 65534 not persisted in items or unopenedPackIds; profile
+SHA-256 `39bb3e83…` byte-identical. **Zero mutation.**
+
+**UX assessment:** crash-safe ✓, economy-safe ✓ (no request even sent), navigation
+recoverable ✓. Blemishes: a **visible empty "0 items" tile**, a **"This pack is no
+longer available" dialog on explicit click**, and (from §16.5) the **Browse-Packs
+navigation gate** (must open My Packs first). Notably this is a *strict improvement*
+over the inactive-sentinel baseline, which throws "pack not available" immediately on
+STORE OPEN and bounces to the Hub; the active placeholder only errors if the user
+deliberately clicks the empty tile, and recovers cleanly.
+
+**Active-placeholder verdict: MARGINALLY ACCEPTABLE.** Safe (crash + economy) and
+usable, but visibly imperfect (fake tile + click-dialog + browse nav gate). Not
+UNACCEPTABLE (no crash/economy risk, recoverable); not fully ACCEPTABLE (user-visible
+defects).
+
+**Permanent-fix decision: P2.** The active sentinel technically works and is safe, but
+its UX is poor and — per Candidate F (CONTRADICTED) — **no backend-only *clean*
+solution exists** (the store's My-Packs resolution is Scaleform/movie-driven, not
+server-gated). Recommendation: keep the active placeholder as an optional/temporary
+backend compatibility mode (strictly better than the current inactive-sentinel
+baseline) and pursue a **client-side** fix for a fully clean zero-pack experience
+(hiding the fake tile / suppressing the forced My-Packs resolution). NOT implemented.
+
+**Rollback verification:** container code restored to `c89d43ea…` (== host, ==
+pre-experiment), sentinel back to `inactive`; `docker restart` (Pid 1562665, StartedAt
+00:59:04Z); `unopenedPackIds=[]`, 65534 inactive/∉catalog, 70 absent, flags ON/OFF;
+host `utas_server.py` never edited; profile `39bb3e83…` unchanged. Bridge/Core
+untouched.
+

docs/evidence/fifa17-recon/table-hashes.sha256

@@ -0,0 +1,44 @@
+# FIFA 17 card-table provenance manifest
+# Source (authoritative): 10.10.0.105:/home/alex/Documents/OpenFUT/fifa17-recon/data/tables/
+# Dest   (this repo):      fifa17-recon/data/tables/
+# Verified 2026-08-12: source and dest byte-identical (sha256), order-independent.
+# Combined hash-of-hashes: 10f239add919089354d8dbff873fc9737b0a0f80f6ac41b1aa2a096c0ec8d331
+# 31 fcc_*.json + 5 staff tables = 36 files. Files are DECODED tables:
+#   each carries {table, source, rowcount, schema[], rows[]}; card instances live in rows[].
+#
+0d1c9af7ae654c3e4363f18bb89bad03a0631056d36425c84b9a680fa989618c  fcc_managerbonusvalues.json
+0e5d5309cd1d9322476f8047fc6eaf4a88f4f19211b8ea01fe4d28ddd3733134  fcc_healingcards.json
+1da80e390169ebb8ee8a6543e14b1191d9151f675797f01e23628f6c24d434c5  fcc_misccards.json
+2212b0ee8d962f0fb6bd346bee35fff6566e22539e397cc2e42bb6efd4dc3ad3  fcc_textposvalues_hd.json
+2a8e22ddb000b2c08f1a3e5eb47bc56ecf43f733ce6e7519498d332e4f439746  headcoachcards.json
+3a323e1c0688a4068ccd21be0c9d8e88a875ab10ce2158d3aed79fc14e65f0fb  fcc_chemlinkcalc.json
+4a60bc4c0d8cb8d2b903e152a3dd5302348753568630818fde059b2de41f82ab  fcc_leaguelogos.json
+5304114078200da4564d33612c955598f12a44bdf52f18274184b98922229b8b  fcc_GrandStandPlayers.json
+5503291e381fee5008120615cd6d30a732b97636d4694a88f943eb14cb992741  fcc_leaguelogostickers.json
+550739c124ca915fb294954afe3d9d04fb7d1faf2b0c96930b2dcdb1bfe7ac8f  fcc_formationcardspositions_kc.json
+5a5aabec1d40ffa21b8effb84f79e4b788cb42352aa592d71d95eba1db0d209e  fcc_trainingcards.json
+6476e396f166905857d2ada4f12cc37645ca42efdca121e8e74270fbf7422336  managercards.json
+6546f602024973e20d04522a857c6c243473a177cab5b3be8400390651a42fab  fcc_navcoords_hd.json
+6b0209647383e4e940d2af2c3bbb2185a4aac7ac0e799fe6b50ae52e7625710d  fcc_contractcards.json
+6c52c83aafd9d9d3406e21c656762ac5cc0ba4522002f424e5593430bc5190f5  physiocards.json
+765687d7f1e5c6c989adf45b174a0fdab0f65597c83132304b53b9f859c02586  fcc_stadium.json
+79e50b07eecc47a0edf4d2a87782e904785e653937698cc712258a82fdf8b079  fcc_formationcardspositions_hd.json
+7d36e0fbb9349eabd4267215bacbe29d78ff621deeb8cab3380dcac72c535eb9  fcc_preferredformationcalcmid.json
+8122a4070901662fac97f675a3e4194dd5fd7e02194fdab204989af42676e268  fitnesscoachcards.json
+828f8b90241672b9f62a9bbd3cb219a1d3bd8856bd160cc46284f2958e08f7d4  fcc_discardcoins.json
+852bb82ed373881373d8610e6f4f2ca4406bac13da4bda9d6abba693d7cafc56  fcc_myclubscategories.json
+974dcbbe6a46c02dc97c77df6c270c9a7f09ba23bee23005ecf95fd114ee66a7  gkcoachcards.json
+9aa4b3b3f226202b21d2e9f96a1508ecce56abba64372099e090df101fce5eeb  fcc_nationcalc.json
+9b6797991520c05f7448b28e66d160f96afc73eefd661ed8272b0a093b6ba89f  fcc_kitcards.json
+9e8e6595fa8d3bcf963eb25bd9f9ea5d131aa92ed0e7e4ae3089adf5e1d55927  fcc_preferredformationcalcst.json
+a4e8ac2ba0a6db45f1f59fe384fbd39a8cee8fb72a72f846e52daca44f1c7ff9  fcc_myclubs.json
+bbf405e3a63b6fd03da1237b8b118764c57a40c797faf85d1e4691a1c95a840e  fcc_balls.json
+ca1184bd85cff3308af0104077feda4357ef483fae6335fa964922eea4e94330  fcc_navcoords_kc.json
+ca3e4ab0f7892aac7473b774de4699c067c54647ca4a82cdd5fd1108c56ed894  fcc_badgecards.json
+ccdda8ad0a15f73a056fa336abde8739b346d12b78cb8adbea0f0677487bb598  fcc_preferredpositioncalc.json
+dbf95bddd456137e4b90a44bdd1f637458f4846ecd5c3ba6747d3f069c3f590f  fcc_textposvalues_kc.json
+dd8c2c860b18d999877c37e0f63dac64ef7bb57bff5a2173960cde71242f9a34  fcc_bonusvalues.json
+df5b997b153941a5bb760ad5bb0fb23dc16cf8612b300559be23ac929b55eec6  fcc_leagues.json
+e4619db324a7848639a8ba53f513cf3ea153eeaf698de05d71e56c319b3cc424  fcc_coinrewards.json
+e6b1ca3ecb7c3923d77e73bda2e6c3f9794b9158354d566112f7979b33b4422c  fcc_preferredformationcalcgk.json
+f54814d61b72dd2b6186e9e414df4fbfbdbea1732da6a4622f001a1ff03bc12a  fcc_preferredformationcalcback.json

docs/evidence/store_purchasegroup_capture_2026-08-12.json

@@ -0,0 +1,199 @@
+{
+  "purchase": [
+    {
+      "assetId": 1,
+      "id": 1,
+      "packType": "BRONZE",
+      "description": "Bronze Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 400,
+          "finalFunds": 400
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 5,
+        "silverQuantity": 0,
+        "goldQuantity": 0,
+        "rareQuantity": 0,
+        "itemQuantity": 5
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "bronze"
+      }
+    },
+    {
+      "assetId": 5,
+      "id": 5,
+      "packType": "GOLD",
+      "description": "Gold Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 2,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 5000,
+          "finalFunds": 5000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 7,
+        "rareQuantity": 7,
+        "itemQuantity": 7
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 6,
+      "id": 6,
+      "packType": "GOLD",
+      "description": "Premium Gold",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 3,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 15000,
+          "finalFunds": 15000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 7,
+      "id": 7,
+      "packType": "GOLD",
+      "description": "Special Players Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 4,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 25000,
+          "finalFunds": 25000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "special"
+      }
+    },
+    {
+      "assetId": 65534,
+      "id": 65534,
+      "packType": "GOLD",
+      "description": "",
+      "state": "inactive",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 0,
+        "rareQuantity": 0,
+        "itemQuantity": 0
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "mypacks",
+        "priority": 1
+      }
+    }
+  ],
+  "timestamp": 1596326400
+}

docs/evidence/store_purchasegroup_capture_active_placeholder_2026-08-12.json

@@ -0,0 +1,199 @@
+{
+  "purchase": [
+    {
+      "assetId": 1,
+      "id": 1,
+      "packType": "BRONZE",
+      "description": "Bronze Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 400,
+          "finalFunds": 400
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 5,
+        "silverQuantity": 0,
+        "goldQuantity": 0,
+        "rareQuantity": 0,
+        "itemQuantity": 5
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "bronze"
+      }
+    },
+    {
+      "assetId": 5,
+      "id": 5,
+      "packType": "GOLD",
+      "description": "Gold Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 2,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 5000,
+          "finalFunds": 5000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 7,
+        "rareQuantity": 7,
+        "itemQuantity": 7
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 6,
+      "id": 6,
+      "packType": "GOLD",
+      "description": "Premium Gold",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 3,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 15000,
+          "finalFunds": 15000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 7,
+      "id": 7,
+      "packType": "GOLD",
+      "description": "Special Players Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 4,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 25000,
+          "finalFunds": 25000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "special"
+      }
+    },
+    {
+      "assetId": 65534,
+      "id": 65534,
+      "packType": "GOLD",
+      "description": "",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 0,
+        "rareQuantity": 0,
+        "itemQuantity": 0
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "mypacks",
+        "priority": 1
+      }
+    }
+  ],
+  "timestamp": 1596326400
+}

docs/evidence/store_purchasegroup_capture_client_guard_no_sentinel_2026-08-13.json

@@ -0,0 +1 @@
+{"purchase": [{"assetId": 1, "id": 1, "packType": "BRONZE", "description": "Bronze Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 1, "currencies": [{"name": "coins", "funds": 400, "finalFunds": 400}], "extPrice": {"finalPrice": {"amount": 4, "currency": "mtx"}, "originalPrice": {"amount": 4, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 5, "silverQuantity": 0, "goldQuantity": 0, "rareQuantity": 0, "itemQuantity": 5}, "unopened": false, "displayGroup": {"value": "bronze"}}, {"assetId": 5, "id": 5, "packType": "GOLD", "description": "Gold Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 2, "currencies": [{"name": "coins", "funds": 5000, "finalFunds": 5000}], "extPrice": {"finalPrice": {"amount": 50, "currency": "mtx"}, "originalPrice": {"amount": 50, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 7, "rareQuantity": 7, "itemQuantity": 7}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 6, "id": 6, "packType": "GOLD", "description": "Premium Gold", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 3, "currencies": [{"name": "coins", "funds": 15000, "finalFunds": 15000}], "extPrice": {"finalPrice": {"amount": 150, "currency": "mtx"}, "originalPrice": {"amount": 150, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 7, "id": 7, "packType": "GOLD", "description": "Special Players Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 4, "currencies": [{"name": "coins", "funds": 25000, "finalFunds": 25000}], "extPrice": {"finalPrice": {"amount": 250, "currency": "mtx"}, "originalPrice": {"amount": 250, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "special"}}], "timestamp": 1596326400}

docs/evidence/store_purchasegroup_capture_empty_no_sentinel_2026-08-12.json

@@ -0,0 +1,173 @@
+{
+  "purchase": [
+    {
+      "assetId": 1,
+      "id": 1,
+      "packType": "BRONZE",
+      "description": "Bronze Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 400,
+          "finalFunds": 400
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 5,
+        "silverQuantity": 0,
+        "goldQuantity": 0,
+        "rareQuantity": 0,
+        "itemQuantity": 5
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "bronze"
+      }
+    },
+    {
+      "assetId": 5,
+      "id": 5,
+      "packType": "GOLD",
+      "description": "Gold Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 2,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 5000,
+          "finalFunds": 5000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 7,
+        "rareQuantity": 7,
+        "itemQuantity": 7
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 6,
+      "id": 6,
+      "packType": "GOLD",
+      "description": "Premium Gold",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 3,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 15000,
+          "finalFunds": 15000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 7,
+      "id": 7,
+      "packType": "GOLD",
+      "description": "Special Players Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 4,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 25000,
+          "finalFunds": 25000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "special"
+      }
+    }
+  ],
+  "timestamp": 1596326400
+}

docs/evidence/store_purchasegroup_capture_freshretest_no_sentinel_2026-08-13.json

@@ -0,0 +1 @@
+{"purchase": [{"assetId": 1, "id": 1, "packType": "BRONZE", "description": "Bronze Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 1, "currencies": [{"name": "coins", "funds": 400, "finalFunds": 400}], "extPrice": {"finalPrice": {"amount": 4, "currency": "mtx"}, "originalPrice": {"amount": 4, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 5, "silverQuantity": 0, "goldQuantity": 0, "rareQuantity": 0, "itemQuantity": 5}, "unopened": false, "displayGroup": {"value": "bronze"}}, {"assetId": 5, "id": 5, "packType": "GOLD", "description": "Gold Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 2, "currencies": [{"name": "coins", "funds": 5000, "finalFunds": 5000}], "extPrice": {"finalPrice": {"amount": 50, "currency": "mtx"}, "originalPrice": {"amount": 50, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 7, "rareQuantity": 7, "itemQuantity": 7}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 6, "id": 6, "packType": "GOLD", "description": "Premium Gold", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 3, "currencies": [{"name": "coins", "funds": 15000, "finalFunds": 15000}], "extPrice": {"finalPrice": {"amount": 150, "currency": "mtx"}, "originalPrice": {"amount": 150, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 7, "id": 7, "packType": "GOLD", "description": "Special Players Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 4, "currencies": [{"name": "coins", "funds": 25000, "finalFunds": 25000}], "extPrice": {"finalPrice": {"amount": 250, "currency": "mtx"}, "originalPrice": {"amount": 250, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "special"}}], "timestamp": 1596326400}

docs/evidence/store_purchasegroup_capture_mypacks70_2026-08-12.json

@@ -0,0 +1,199 @@
+{
+  "purchase": [
+    {
+      "assetId": 1,
+      "id": 1,
+      "packType": "BRONZE",
+      "description": "Bronze Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 400,
+          "finalFunds": 400
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 4,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 5,
+        "silverQuantity": 0,
+        "goldQuantity": 0,
+        "rareQuantity": 0,
+        "itemQuantity": 5
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "bronze"
+      }
+    },
+    {
+      "assetId": 5,
+      "id": 5,
+      "packType": "GOLD",
+      "description": "Gold Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 2,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 5000,
+          "finalFunds": 5000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 50,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 7,
+        "rareQuantity": 7,
+        "itemQuantity": 7
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 6,
+      "id": 6,
+      "packType": "GOLD",
+      "description": "Premium Gold",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 3,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 15000,
+          "finalFunds": 15000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 150,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "gold"
+      }
+    },
+    {
+      "assetId": 7,
+      "id": 7,
+      "packType": "GOLD",
+      "description": "Special Players Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 4,
+      "currencies": [
+        {
+          "name": "coins",
+          "funds": 25000,
+          "finalFunds": 25000
+        }
+      ],
+      "extPrice": {
+        "finalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        },
+        "originalPrice": {
+          "amount": 250,
+          "currency": "mtx"
+        }
+      },
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": false,
+      "displayGroup": {
+        "value": "special"
+      }
+    },
+    {
+      "assetId": 70,
+      "id": 70,
+      "packType": "GOLD",
+      "description": "Reward Special Players Pack",
+      "state": "active",
+      "saleType": "promo",
+      "limitType": "NONE",
+      "quantity": 0,
+      "purchaseLimit": 0,
+      "purchaseCount": 0,
+      "isPremium": false,
+      "sortPriority": 1,
+      "packContentInfo": {
+        "bronzeQuantity": 0,
+        "silverQuantity": 0,
+        "goldQuantity": 11,
+        "rareQuantity": 11,
+        "itemQuantity": 11
+      },
+      "unopened": true,
+      "displayGroup": {
+        "value": "mypacks",
+        "priority": 1
+      }
+    }
+  ],
+  "timestamp": 1596326400
+}

docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md

@@ -0,0 +1,523 @@
+# FIFA 17 — Clean Empty-My-Packs client fix (DESIGN / RESEARCH ONLY)
+
+Status: **design only — no client binary/movie changes made.** This is the client-side
+follow-up to bug 6c. The backend already ships a compatibility workaround (P2, active
+non-openable sentinel 65534; see `docs/evidence/STORE_TILE_6C.md` §17 and
+`FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md`). This plan describes what a *client-side*
+fix would need to change so the backend shim can eventually become unnecessary for
+patched clients.
+
+Do NOT patch the executable, DLLs, or Scaleform movies in this task.
+
+## 1. Established client-side evidence
+
+Binary: `CardsDLL_Win64_retail.dll`
+SHA-256 `4706a881ae1fc7b5769fd810b25a868d29d2b16a8e65a7513436327ef645573c`
+(dump load base `0x00006FFFFC120000`; RE-space base `0x180000000`). `FIFA17.exe`
+(`29c31cef…`) is Denuvo-packed (decrypts only in live memory).
+
+Store category pipeline (all decompiled; see `docs/plan-2026-08-05-store-subsystem.md`):
+- `FUN_1800150d0` — builds display groups from `purchase[]`; a `mypacks` group exists
+  iff some pack has `displayGroup.value=="mypacks"`. `group+0x104=(value=="mypacks")`,
+  tiles in `group+0x40`, ordinal in `group+0x00` (1-based creation order).
+- `FUN_18007dab0` → `FUN_1800147f0(model, screen+0x290, …)` — renders/resolves a
+  category. `screen+0x290==0` lists group tiles (`FUN_180014610`); otherwise
+  `FUN_180014420` exact-matches the ordinal and **returns NULL on a miss**, after
+  which `FUN_1800147f0` dereferences `[RAX+0x48]` with **no null guard** →
+  **crash at `0x180014882`** (`ACCESS_VIOLATION` read of `0x48`, minidump-confirmed).
+- `screen+0x290` is written in exactly two CardsDLL sites: ctor `FUN_18007d1a0`
+  writes `0`; **`FUN_18007e7f0` case `0x7551` copies the Flash movie message field
+  `CATEGORY_ID` verbatim** into it. So the category is chosen by the Scaleform movie.
+- `FUN_18007e5e0` binds the six store tabs (`FUN_180014580`: `mypacks, points, bronze,
+  silver, gold, special`) to `PANEL_ID` = matching group ordinal, or hides the panel.
+- Unopened-pack count signals (server, already correct at 0 when empty):
+  `userInfo.unopenedPacks.recoveredPacks` and `/user/credits .unopenedPacks`. The hub
+  `CentralUnclaimedPack` tile (destination `GOTO_STORE_MYPACK`) is gated by this count
+  in the hub model (`model+0x20950`). **Candidate F (a server count gating the STORE's
+  My-Packs resolution) was CONTRADICTED**: the count is correct at 0 yet the store
+  still resolves My Packs, because the decision is movie-side.
+
+## 2. Desired clean client behavior
+
+```
+unopened-pack count == 0:
+    Store defaults to Browse Packs (e.g. a real category such as bronze/gold)
+    My Packs is NOT selected/resolved
+    no synthetic placeholder tile is required from the server
+unopened-pack count  > 0:
+    existing My Packs behavior unchanged
+```
+
+## 3. Candidate insertion points (ranked)
+
+Ranking favors fixing the UX (not merely preventing the crash) and the smallest,
+lowest-risk change that achieves it.
+
+### Rank 1 (preferred, best UX) — Scaleform / category-selection layer
+Prevent the movie from emitting `CATEGORY_ID == mypacks` (and from defaulting the
+store into My Packs) when the unopened-pack count is 0; default to Browse Packs
+instead.
+- **Where:** the FUT Store Scaleform movie / ActionScript (`StoreFront`,
+  `CATEGORY_ID`/`ACTION_GET_PACKLIST`, `GOTO_STORE_MYPACK`), which the packed exe hosts
+  and which reads the hub model (it already knows the count for the
+  `CentralUnclaimedPack` tile).
+- **Behavior changed:** the store's initial/selected category when empty.
+- **Scope:** movie asset edit (client-side), no native-code patch.
+- **Risk:** medium — Scaleform RE/editing is fiddly; must find where the default
+  `CATEGORY_ID` is chosen and gate it on the count without breaking the count>0 path.
+- **Compatibility:** per-client asset change; does not touch protocol or other clients.
+- **Fixes UX or just crash?** **UX** — no fake tile, correct default; the crash also
+  disappears because `mypacks` is never resolved when absent.
+- **Evidence:** `screen+0x290 ← CATEGORY_ID` (`FUN_18007e7f0` case `0x7551`); count
+  already available client-side (hub model / `unopenedPacks`).
+
+### Rank 2 — Native Store resolver fallback (CardsDLL)
+Make `FUN_1800147f0`/`FUN_180014420` fall back to a safe category (e.g. list-tiles
+`N==0`, or the first existing group) when the requested ordinal misses, instead of
+dereferencing NULL.
+- **Behavior changed:** category-miss handling for ALL categories, not just mypacks.
+- **Scope:** small, localized CardsDLL binary patch near `0x180014420`/`0x180014882`.
+- **Risk:** medium — alters native store behavior globally; could mask other
+  legitimate misses; the movie may still believe it is in My Packs (empty/odd view).
+- **Compatibility:** binary patch to the shipped DLL (client-side).
+- **Fixes UX or just crash?** Crash + partial UX (no crash, but the empty-My-Packs
+  view may still be awkward).
+- **Evidence:** the no-guard deref at `0x180014882`; `FUN_180014420` returns NULL on
+  miss.
+
+### Rank 3 (cheapest, crash-only) — CardsDLL null guard
+Insert a null check before the `[RAX+0x48]` dereference in `FUN_1800147f0` (a single
+`TEST/JZ` around the deref) so a NULL group is skipped/returned safely.
+- **Behavior changed:** only the crash path.
+- **Scope:** minimal (a few bytes) binary patch at `~0x180014882`.
+- **Risk:** low — smallest change; but purely crash-prevention. With no `mypacks`
+  group the resulting empty view is unverified (could be a blank/empty-category state).
+- **Compatibility:** binary patch (client-side).
+- **Fixes UX or just crash?** Crash only.
+- **Evidence:** minidump faulting instruction `CardsDLL+0x14882`, `[NULL+0x48]`.
+
+## 4. Recommended long-term outcome
+
+Rank 1 (Scaleform default-category gating) is the clean fix: with count 0 the store
+opens on Browse Packs, no `mypacks` resolution, no fake tile — and the **backend
+sentinel 65534 can be dropped for patched clients** (the server would simply omit the
+`mypacks` group when empty, which is safe once the client no longer resolves it).
+Rank 3 (null guard) is a cheap universal crash-safety net that could ship alongside.
+Until a client-side fix exists, the backend P2 sentinel remains the required
+compatibility behavior for unpatched retail clients.
+
+## 5. Open questions / next research (no execution here)
+- Locate the Store movie's default/initial `CATEGORY_ID` selection and confirm it can
+  read the unopened count (Rank 1 feasibility).
+- Confirm, via a guarded-resolver experiment, what the empty-My-Packs view degrades to
+  if the `mypacks` group is simply absent + a null guard is present (Rank 2/3).
+- Determine whether the Browse-Packs→My-Packs navigation gate (observed with the
+  active sentinel) also resolves under Rank 1.
+
+---
+
+# PART II — Native client-fix design (RE-backed, 2026-08-13)
+
+Investigation-and-design phase (no client binary/movie changed, no backend changed,
+no new live Store experiment). CardsDLL was re-analysed in Ghidra on `.105`; the
+in-repo decompiled addresses were reconfirmed against a freshly-built project. Every
+claim below is labelled **ESTABLISHED** (read from this build's binary / crash dump),
+**PROPOSED** (design, not yet implemented), or **UNKNOWN**.
+
+## 6. Binary + environment verification (ESTABLISHED)
+
+Hashes re-verified on `.105` (`/mnt/games/FIFA 17/`) — identical to the recorded RE:
+- `CardsDLL_Win64_retail.dll` SHA-256 `4706a881ae1fc7b5769fd810b25a868d29d2b16a8e65a7513436327ef645573c`,
+  size 3179952, PE `TimeDateStamp` 1497050156 (2017-06-09T23:15:56Z), `SizeOfImage`
+  `0x31d000`, image base `0x180000000` (RE-space). **Unpacked → statically analysable.**
+- `FIFA17.exe` SHA-256 `29c31cef12b0c3c2a7305220617c7b4fa139ab76b8c857851bdbe88987962899`,
+  size 224639408, **Denuvo-packed** → the Scaleform/StoreFront ActionScript that
+  *decides* to emit `CATEGORY_ID` is NOT statically readable. This is why a
+  pure-Scaleform edit (old "Rank 1") is not the practical vehicle; the fix is taken
+  at the readable native boundary in CardsDLL instead.
+- Ghidra project rebuilt at `.105:/tmp/ghidra_fut/cardsdll` (headless import+analysis
+  succeeded). Tooling: `fifa17-recon/tools/ghidra_env.py` run under `~/.venv`
+  (`PYTHONPATH=/opt/ghidra/Ghidra/Features/PyGhidra/pypkg/src:/usr/lib/python3.14/site-packages`;
+  `jpype1` reinstalled offline from pip cache). RVAs below = static VA − `0x180000000`.
+
+## 7. Category-selection path (ESTABLISHED — decompiled this build)
+
+Store message dispatch `FUN_18007d880` (RVA `0x7d880`) routes Flash message ids:
+`0x753f → FUN_18007dab0` (render), `0x278a → FUN_18007df60` (publish category ids),
+and the input handler `FUN_18007e7f0` (RVA `0x7e7f0`) case **`0x7551`** copies the
+movie field `CATEGORY_ID` verbatim into `screen+0x290` (the only non-ctor writer;
+ctor `FUN_18007d1a0` writes 0).
+
+**Store render `FUN_18007dab0` (RVA `0x7dab0`), decompiled verbatim, is the decision
+point:**
+```c
+iVar1 = *(int *)(param_1 + 0x290);      // requested CATEGORY_ID (screen+0x290)
+iVar6 = FUN_180014580(store, 1);        // the *points* category id  (see tab map)
+if (iVar1 == iVar6) {                   // requested category is POINTS (real-money)
+    if (region_check() == 0) { post "REGION_MISMATCH"; return; }
+    if (FUN_180014de0(store) != 0) return;      // points group present → handled
+    FUN_180014b60(store, dp);           // else points render
+} else {
+    FUN_1800147f0(store, iVar1, dp, 0, 0);      // EVERY other category, incl. My Packs
+}
+```
+- `param_1` (RCX) = the store-screen object; `+0x290` is the requested category.
+- **Tab→id map `FUN_180014580(store, n)` (RVA `0x14580`): `0=mypacks, 1=points,
+  2=bronze, 3=silver, 4=gold, 5=special`.** Each returns the group's **1-based
+  ordinal** (via caption compare `FUN_180014380`) or **`-1`** if that group is absent.
+  So category ids are DYNAMIC ordinals, not fixed constants. The tab publisher
+  `FUN_18007df60` pushes `MYPACK_/BRONZE_/…_CATEGORY_ID` to the movie from these
+  lookups; the movie echoes one back as `CATEGORY_ID`.
+- The **points** tab is the only one special-cased (commerce/region gate). **My Packs
+  is NOT special-cased — it falls into the `else` and is resolved by
+  `FUN_1800147f0`.**
+
+**Resolver `FUN_1800147f0` (RVA `0x147f0`) — the crash (ESTABLISHED, instruction
+level):**
+```
+0x14856: 85 ff            TEST EDI,EDI          ; EDI = category ordinal (param_2)
+0x14858: 75 0f            JNZ 0x14869           ; ==0 → list-all (Browse), else resolve
+0x1485a: … CALL 0x14610                          ; FUN_180014610 list ALL group tiles
+0x14867: eb 29            JMP 0x14892
+0x14869: 8b d7            MOV EDX,EDI
+0x1486b: e8 …  CALL 0x14420                       ; FUN_180014420(store, ordinal) → RAX (group|NULL)
+0x14870: 48 8d 50 40      LEA RDX,[RAX + 0x40]    ; RDX = group+0x40  (=0x40 when RAX=NULL)
+0x14878: 48 3b c2         CMP RAX,RDX
+0x1487b: 74 15            JZ 0x14892
+0x14882: 4c 8b 42 08      MOV R8,[RDX + 0x8]      ; <-- FAULT: read [0x40+0x8]=0x48 when NULL
+0x14886: 48 8b 12         MOV RDX,[RDX]           ; [0x40]
+```
+`FUN_180014420` (RVA `0x14420`) exact-matches `group+0x00` (ordinal), stride `0x108`,
+**returns NULL on a miss, with no guard in the caller** → faulting read of VA `0x48`
+at `0x180014882`. This is byte-for-byte the Experiment-B minidump
+(`0xC0000005` READ `0x48` at `CardsDLL+0x14882`).
+- `param_2 == 0` → `FUN_180014610` lists **all** group tiles = the safe "Browse Packs"
+  view. `param_2 == existing ordinal` → resolves. `param_2 == a non-existent ordinal`
+  (e.g. `-1`, which `MYPACK_CATEGORY_ID` becomes when the group is absent) → NULL → crash.
+
+**Why it crashes with zero packs (ESTABLISHED):** with `unopenedPackIds==[]` and no
+sentinel, no `mypacks` group exists, so `FUN_180014580(store,0) = -1`,
+`MYPACK_CATEGORY_ID = -1`, the movie still selects My Packs and echoes `CATEGORY_ID =
+-1`, and `FUN_1800147f0(store, -1, …)` → `FUN_180014420(-1)=NULL` → crash. The active
+sentinel (65534) works only because it makes a real `mypacks` ordinal exist to resolve.
+
+## 8. Zero-pack state client-side (ESTABLISHED)
+
+The client already holds the correct unopened-pack count in a **data-manager
+singleton** (the same one the store resolver uses):
+- Obtain: `seed = FUN_1800d7170()` then `FUN_180009c80(&p, seed)` → `p` (release with
+  `p->vtbl[0x08](p)`). This exact accessor already runs inside `FUN_180014420` and
+  `FUN_1800147f0`, so any store-category hook can reach it.
+- **Read count: `p->vtbl[0x4d8](p)` → int. Write: `p->vtbl[0x4e0](p, n)`.** Confirmed
+  in `FUN_180019780`, which reads slot `0x4d8`, adds the number of set booleans in a
+  pack response, and writes slot `0x4e0` (it also fetches `FutGetPurchasedItems`).
+- Representation: plain `int`; **0 = no unopened packs**, `>0` = count. Lifetime: the
+  singleton persists for the session; updated on pack acquire/open.
+- No dedicated "hasUnopenedPacks" boolean helper was found; `count != 0` is the
+  predicate. (The hub `CentralUnclaimedPack` tile is gated by this same count via
+  `model+0x20950`, written by `FUN_18010cdc0`/`FUN_18011e120` — the hub mirror, not the
+  store gate.)
+
+## 9. Implementation vehicle (ESTABLISHED — reuse, do not build a new loader)
+
+OpenFUT **already ships a client hook framework**: `openfut-launcher/openfut-hook`
+(`crate-type=["cdylib"]`) builds **`version.dll`**, a proxy DLL placed in the game dir
+(`/mnt/games/FIFA 17/version.dll`, present & active; log `~/.wine/drive_c/openfut_hook.log`).
+- Load path: Wine/Windows loads `version.dll` from the app dir at process start →
+  `DllMain(DLL_PROCESS_ATTACH)` → `install_hooks()`.
+- Existing hooks (`lib.rs`): `getaddrinfo` (IAT via `iat::resolve`), `connect`
+  (inline detour), `WSAConnect`, `WSAIoctl`/ConnectEx, origin_spy registry/mutex,
+  crypt32 `CertVerifyCertificateChainPolicy`, **and in-memory byte-patching of the
+  loaded (packed) main exe + EAWebKit** (`ssl_patch`: `GetModuleHandleA` → scan for a
+  unique prologue → `VirtualProtect`+`copy_nonoverlapping`).
+- Inline-hook primitive (`connect_hook`): `write_hook(target, dest)` lays a 14-byte
+  `FF 25 00000000 <abs64>` JMP; `restore_original` restores saved bytes
+  (unhook → call real → rehook, avoiding trampoline relocation).
+- Config: `openfut.cfg` beside the DLL (`host`/ports today; a `store_mypacks_fix`
+  flag would be added there).
+- **Suitability for the Store fix: direct.** The DLL is in-process with full access
+  to the loaded `CardsDLL_Win64_retail.dll`; the store fix is a NEW module
+  (`store_hook.rs`) installed from `install_hooks`, reusing the `ssl_patch`
+  signature-scan and the `connect_hook` inline-detour patterns. No new loader, no ASI,
+  no separate injector.
+
+## 10. Three strategies re-evaluated against the RE (Task 4)
+
+### A. Category-selection redirect — **PREFERRED** (best UX, native, targeted)
+Hook `FUN_18007dab0` (RVA `0x7dab0`) at entry; before the original runs, redirect a
+zero-pack My-Packs request to Browse Packs:
+```
+cat        = *(int*)(store + 0x290)
+mypacks_id = FUN_180014580(store, 0)         // -1 when the group is absent
+if (cat == mypacks_id) {                     // movie asked for My Packs (incl. cat==-1==id)
+    if (unopened_count() == 0)               // singleton vtbl[0x4d8]
+        *(int*)(store + 0x290) = 0;          // 0 = FUN_180014610 list-all = Browse Packs
+}
+// then call the original FUN_18007dab0(store)
+```
+- Uses the real count? **Yes** (singleton `vtbl[0x4d8]`). Removes the fake 65534 tile?
+  **Yes** (server can omit the group). Removes the click-dialog? **Yes** (no placeholder
+  to click). Removes the Browse→My-Packs nav gate? **Yes** (store lands on Browse, not
+  an empty My-Packs). Preserves count>0? **Yes** (`cat==mypacks_id` with count>0 is left
+  untouched → normal My Packs). Affects other categories? **No** (`cat!=mypacks_id`
+  path is unmodified; points/bronze/… unchanged).
+- Prevents the crash as a side effect (My Packs is never resolved when its group is
+  absent). This is the old "Rank 1" INTENT, implemented at the readable native boundary
+  instead of in packed Scaleform.
+
+### B. Resolver fallback — acceptable safety net, less targeted
+In `FUN_1800147f0` (or right after the `CALL 0x14420` at RVA `0x1486b`): if the
+resolved group is NULL, fall back to list-all (`param_2=0`) instead of dereferencing.
+- Prevents crash? **Yes.** Fixes default nav / removes fake tile? **Partially** — the
+  movie still believes it is in My Packs, so the view may be an empty/odd My-Packs
+  rather than a clean Browse. Leaves other lookups unchanged? **It changes miss-handling
+  for ALL categories** — a generic NULL fallback that could mask a genuine
+  missing-category protocol bug. Higher risk than A for that reason; keep as a
+  belt-and-braces guard, not the primary UX fix. The resolver does NOT know *why*
+  `mypacks` is missing, which is exactly the concern the task flags.
+
+### C. Null-guard only — weakest (crash-only)
+Insert `TEST RAX,RAX; JZ 0x14892` immediately after `CALL 0x14420` (RVA `0x1486b`),
+before `LEA RDX,[RAX+0x40]`. Needs a trampoline (no inline slack).
+- Converts the crash into whatever an empty tile-vector renders (unverified; likely a
+  blank/empty category). Does **not** remove the fake tile or fix the default category;
+  the sentinel would still be needed for acceptable UX. Verified as expected-weakest.
+
+## 11. Concrete hook target for strategy A (Task 6, PROPOSED)
+```
+module:            CardsDLL_Win64_retail.dll   (GetModuleHandleA)
+function:          FUN_18007dab0  (store render / message 0x753f)
+RVA:               0x7dab0   (static VA 0x18007dab0)
+calling conv:      Microsoft x64 fastcall; single arg store-screen ptr in RCX
+screen offset:     store+0x290 = requested CATEGORY_ID (int)
+helpers to call:   FUN_180014580 (RVA 0x14580)  tab→ordinal, arg0=RCX store, arg1=EDX index(0=mypacks)
+                   count singleton: FUN_1800d7170 (0xd7370-seed) + FUN_180009c80 (0x9c80), read vtbl[0x4d8]
+redirect target:   set store+0x290 = 0  (FUN_180014610 list-all → Browse Packs)
+original behavior: zero packs → resolves absent mypacks ordinal → FUN_180014420 NULL → crash at 0x14882
+desired behavior:  zero packs + mypacks requested → store+0x290 forced to 0 → Browse Packs; no crash/dialog/tile
+```
+Hook mechanics (reuse `connect_hook`): lay a 14-byte `FF 25` JMP at `base+0x7dab0` to a
+Rust `hooked_store_render(store)`; inside: apply the redirect, unhook, call real
+`FUN_18007dab0(store)`, rehook, return its value. Intercepting only the entry means the
+minimum interception is the 14 JMP bytes; the first instructions of `FUN_18007dab0`
+(`MOV RAX,RSP; MOV [RAX+8],RCX; PUSH …`) are a standard prologue safe to save/restore.
+Alt insertion point (earlier): `FUN_18007e7f0` case `0x7551`, where `CATEGORY_ID` is
+written to `screen+0x290` — redirect there instead of at render. Entry-hook of
+`FUN_18007dab0` is preferred (single, well-typed arg; runs once per store render).
+
+Thread/context: the store screen runs on the client's UI/update thread; the hook reads
+one int and (rarely) writes one int on the same object the callee immediately reads —
+no new synchronization needed. Called for categories other than My Packs? The FUNCTION
+is, but the redirect body only fires when `cat==mypacks_id`, so other tabs are
+untouched.
+
+## 12. Version / build safety (Task 7, PROPOSED)
+FIFA17-specific compat code MUST validate the client before hooking, and MUST no-op on
+any other build (the same `version.dll` is also used for FIFA23):
+1. **Module gate:** only proceed if `GetModuleHandleA("CardsDLL_Win64_retail.dll")`
+   resolves (FIFA23 has no such module → auto-skip).
+2. **Build gate (both, belt-and-braces):**
+   - Exact hash/PE gate: on-disk SHA-256 == `4706a881…`, or PE `SizeOfImage==0x31d000`
+     && `TimeDateStamp==1497050156` (cheap in-memory check).
+   - Signature scan + validation: locate `FUN_18007dab0` by a unique prologue/byte
+     window rather than trusting the RVA, and assert the known bytes at the branch
+     (`85 ff 75 0f` region) and at the resolver `CALL 0x14420` site match before
+     installing. Recommend **both**: hash to reject the wrong game fast, signature to
+     confirm the exact patch site.
+3. **Failure behavior:** any check fails (unknown/updated build) → **do NOT patch**,
+   log, and leave the **backend P2 active-sentinel (65534) as the fallback**. Never
+   patch or crash an unrecognised build.
+
+## 13. First controlled client experiment (Task 8, PROPOSED — not executed here)
+Goal: prove a patched client sends zero-pack Store entry to Browse Packs with **no**
+active placeholder.
+- Build `openfut-hook` with strategy-A `store_hook`, gated behind `openfut.cfg`
+  `store_mypacks_fix=1` (opt-in; default off preserves today's behavior).
+- Test profile: `unopenedPackIds == []`.
+- Sequence (each variable changed alone; operator drives FIFA; read-only capture):
+  1. Deploy patched `version.dll`; confirm `openfut_hook.log` shows the store hook
+     installed + build gate PASSED.
+  2. **Backend test mode (LATER, separately authorized — NOT in this task):** switch the
+     backend to *empty-no-sentinel* (the Exp-B config that crashed the UNPATCHED client)
+     so the patched client must handle a genuinely-absent `mypacks` group.
+  3. Operator opens Store. **Predicted (patched + zero packs + no sentinel):** Store
+     opens, defaults to Browse Packs, no `mypacks` resolve, **no crash, no dialog, no
+     fake tile**.
+  4. Set `unopenedPackIds=[70]`; reopen. **Predicted:** My Packs works normally
+     (hook body skipped because count>0).
+  5. Revert backend to the active sentinel.
+- **Backend change eventually required for this experiment: YES** — a controlled
+  empty-no-sentinel test mode to force the absent group. It is NOT performed in this
+  phase and MUST be separately authorized (same experiment discipline: patch the
+  container copy, capture, revert, restart; never synthesize a client request).
+- **Client rollback:** flip `store_mypacks_fix=0` (hook not installed) or restore the
+  original `version.dll`; the game reverts to depending on the backend sentinel. No FIFA
+  binaries/movies/config are modified on disk — the hook is in-memory only, so rollback
+  is a file/flag swap.
+
+## 14. Interaction with the backend 65534 fallback (ESTABLISHED + PROPOSED)
+- **Keep the backend sentinel deployed** until strategy A is implemented AND verified.
+  It remains the required behavior for unpatched retail clients and for any client whose
+  build gate fails.
+- Once strategy A is verified, the server MAY, **for patched clients only**, omit the
+  `mypacks` group when empty (the safe representation the client will then handle) —
+  but only behind explicit detection/opt-in; do NOT drop the sentinel globally, since
+  unpatched clients still crash without it.
+
+## 15. ESTABLISHED / PROPOSED / UNKNOWN summary
+- **ESTABLISHED:** binary hashes/build; the full native category path and addresses
+  (`FUN_18007d880/18007dab0/18007e7f0/1800147f0/180014420/180014580/180014610`); the
+  instruction-level crash (`0x14882`, `[NULL+0x48]`); tab→ordinal map; that My Packs is
+  not special-cased and funnels through `FUN_1800147f0`; the unopened-count singleton
+  and its `vtbl[0x4d8]/[0x4e0]` accessors, reachable from store code; the
+  `openfut-hook`/`version.dll` vehicle and its hook/patch primitives.
+- **PROPOSED (not implemented):** the strategy-A entry hook and its redirect logic; the
+  build-guard scheme; the opt-in config flag; the first experiment and its backend
+  test-mode requirement; the per-patched-client server relaxation.
+- **UNKNOWN:** exactly why the packed Scaleform movie selects My Packs on store open
+  (Denuvo-packed, unread) — not needed for strategy A, which intercepts the native
+  result; the precise rendered appearance of `category==0` list-all in this empty
+  configuration (to be observed in the experiment); whether any non-store path also
+  drives `screen+0x290` to a My-Packs ordinal (none found; `FUN_18007e7f0` case `0x7551`
+  and the ctor are the only writers).
+
+---
+
+# PART III — Final no-sentinel resolver experiment (2026-08-13) — RESULT F3 (CRASH), CONFOUNDED
+
+Vehicle change: the resolver guard was implemented as an **`autopatch.py` memory patch**
+(the live FIFA-17 client-patch mechanism), NOT the `version.dll` proxy — Proton loads its
+builtin `version.dll`, so the earlier `store_hook`/`version.dll` prototype was inert and
+has been rolled back. Guard: at CardsDLL `0x180014858`, `JNZ 0x14869` (`75 0f`) →
+`JG 0x14869` (`7f 0f`), orig-verified; routes category `< 0` (and `== 0`) to the safe
+list-all/Browse path (`FUN_180014610`), category `> 0` to the existing resolver.
+`TEST EDI,EDI` at `0x180014856` is the flag source (OF cleared ⇒ `JG` = signed `> 0`).
+
+## Setup (verified)
+- CLIENT: guard active/enforced — live bytes `85 ff 7f 0f` at `0x180014856` (FIFA pid 547843,
+  autopatch pid 547621; log `ENFORCED guarded store patch @ … (JNZ->JG)`, orig `75 0f` matched).
+- BACKEND: sentinel 65534 suppressed by a one-line `if not owned_ids:` → `if False:` in the
+  container copy only (committed source `f42279f` untouched; backup `/tmp/utas_server.EXP_ORIG.py`).
+  Genuine `GET /store/purchasegroup` (02:44:39Z) → ids `[1,5,6,7]`, **no 65534, no mypacks group**,
+  normal packs unchanged (evidence: `docs/evidence/store_purchasegroup_capture_client_guard_no_sentinel_2026-08-13.json`).
+- PROFILE: `unopenedPackIds=[]`, coins 29,876,776, sha `39bb3e83…` — unchanged throughout.
+
+## Result — F3 (CRASH)
+Minidump `CrashDump_2026.08.12_20.44.40.302.dmp` (preserved `/tmp/expF_crash.dmp`, sha `4dcb0cb7…`):
+`0xC0000005` READ of VA `0x48` at `ExceptionAddress 0x6ffffc224882` → **RE `0x180014882`** —
+the **identical** resolver crash instruction as Experiment B (`FUN_1800147f0`,
+`MOV R8,[RDX+0x8]` with the group ptr NULL).
+
+**Mechanism (decisive):** `0x14882` lives in the *resolve* branch, which the guard's `JG`
+reaches **only when category `> 0`**. Since the guard was verified in place, the client
+presented a **positive** My-Packs ordinal that no longer resolves (no mypacks group) →
+`FUN_180014420` returned NULL → crash. The guard's design assumption — *absent mypacks ⇒
+category `-1`* — did NOT hold on this path.
+
+## Confound (uncontrolled variable)
+FIFA was **not relaunched** after the backend flipped to no-sentinel; the client carried
+**stale store/tab state** from the sentinel-present safe stage, where the mypacks group
+existed at a *positive* ordinal `N` (`MYPACK_CATEGORY_ID = N`). Reopening the Store reused
+that stale positive ordinal rather than the `-1` a **fresh** launch publishes
+(`FUN_18007df60 → FUN_180014580(store,0) = -1` when absent). So the intended clean A/B (client
+only ever sees the no-sentinel response) was not achieved — the category that reached the
+resolver was a stale `>0`, exactly the case the negative-only guard does not divert.
+
+## Conclusion / strategy status
+- **The guard as-written does NOT handle a positive, now-invalid My-Packs ordinal** — proven
+  by this crash. Diverting only `category < 0` is insufficient when the client presents a
+  stale/positive ordinal for an absent group.
+- **Not falsified for the fresh-client case.** Whether a fresh no-sentinel launch presents
+  `-1` (guard diverts → Browse, no crash) or still a positive ordinal is **UNKNOWN** and needs
+  a **clean re-test**: launch FIFA fresh with the backend already in no-sentinel mode so the
+  client never sees a mypacks group. That is the proper equivalent of Experiment B.
+- **Candidate stronger guard** (design only, not implemented): divert to list-all when the
+  resolved group is NULL for *any* category (guard `FUN_180014420`'s NULL return at the
+  `0x14870`/`0x14882` site), not merely when `category < 0`. This covers the positive-invalid
+  ordinal too, at the cost of being a generic miss-fallback (the higher-risk Rank-2 behavior).
+  Do NOT implement without authorization and a clean re-test first.
+
+**Strategy A / resolver guard status: NOT PROVEN.** Crash-guard installs and is build-validated
+and dormant-safe with the sentinel present, but the first no-sentinel test CRASHED at the
+resolver via a positive stale ordinal (confounded by no relaunch). Backend P2 active-sentinel
+was restored immediately (mandatory rollback; source `f416e71e…`, sentinel `state=active`),
+and remains the production safety net. Guard left in `autopatch.py` (dormant) pending the
+clean re-test decision; `autopatch.py.pre-storeguard.bak` available to remove it.
+
+---
+
+# PART IV — Fresh-process no-sentinel retest (2026-08-13) — RESULT R1 (SUCCESS)
+
+Corrects PART III's confound. This time the mandatory ordering was enforced: the backend
+entered no-sentinel mode **while FIFA was closed**, then FIFA launched **fresh** (new pid,
+new autopatch) so the process never saw a sentinel-present Store response.
+
+## Setup (verified, clean A/B)
+- BACKEND set no-sentinel at 02:55:09Z with FIFA down; genuine `GET /store/purchasegroup`
+  (02:58:45Z) served to the fresh client = ids `[1,5,6,7]`, **no 65534, no mypacks group**,
+  packs 1/5/6/7 present. This body is **byte-identical** to the PART III (F3) no-sentinel
+  capture — the ONLY changed variable vs F3 is the client process lifetime.
+  Evidence: `docs/evidence/store_purchasegroup_capture_freshretest_no_sentinel_2026-08-13.json`.
+- CLIENT: NEW FIFA pid 553220, NEW autopatch pid 552999; guard ENFORCED (orig `75 0f`
+  matched → `85 ff 7f 0f` = `TEST EDI,EDI; JG`). Process never saw a sentinel response
+  (0 purchasegroup responses containing 65534 after the no-sentinel restart).
+- PROFILE unchanged throughout (`39bb3e83…`, `[]`, coins 29,876,776).
+
+## Result — R1 (operator-observed)
+- **No crash** (FIFA 553220 alive after the test; no new minidump), **no dialog**, **Store
+  stays open**, opens on **Browse Packs**, Bronze/Gold/Special packs visible and navigable.
+- Cosmetic-only imperfections (pre-existing, NOT caused by the guard): the six-tab bar is
+  unbound (no tabs), packs render without cover art, and tiles show "0 items". These match
+  the known store tab-bind / list-all rendering quirks (`plan-2026-08-05-store-subsystem.md`
+  §2.1) and are independent of the resolver guard.
+
+## Causal conclusion (decisive A/B)
+```
+server response (no sentinel, no mypacks group)  ==  byte-identical across F3 and R1
+client original JNZ  + this response  -> CRASH 0x180014882            (Experiment B)
+client JG (stale positive ordinal)    -> CRASH 0x180014882            (PART III F3, contaminated)
+client JG (FRESH, category = -1)       -> NO CRASH, Browse Packs        (PART IV R1)  ✅
+```
+A **fresh** client publishes `MYPACK_CATEGORY_ID = FUN_180014580(store,0) = -1` for the absent
+group; the movie echoes `-1`; `TEST EDI,EDI; JG` does **not** take the resolve branch, so the
+client runs the list-all/Browse path (`FUN_180014610`) — no `FUN_180014420(NULL)` deref, no
+crash. **PART III's F3 is confirmed as stale-positive-ordinal contamination** (FIFA not
+relaunched across the sentinel→no-sentinel flip), not a guard failure.
+
+## Strategy status
+**Strategy A / resolver guard: PROVEN ON THE TESTED FIFA 17 BUILD** (CardsDLL
+`4706a881…`) for the clean process-lifetime case — it safely routes the absent My-Packs
+category to Browse Packs with no crash and no dialog, needing **no** backend sentinel. Scope
+caveats: (1) tested build only; (2) the negative-only guard does NOT cover a stale/positive
+invalid ordinal (PART III) — only arises if the client's Store state predates a sentinel→
+no-sentinel change within one process, which does not happen on a normal launch; a NULL-return
+guard at `FUN_180014420` would additionally cover that, deferred/not implemented; (3) UX still
+has the pre-existing no-tabs/no-art/"0 items" cosmetics.
+
+Backend P2 active-sentinel was restored immediately after capture (mandatory rollback; source
+`f416e71e…`, sentinel `state=active`) and **remains production default**. The clean UX is only
+safe to serve when the server knows the client is patched — see PART II §12 rollout options
+(recommend B: suppress the sentinel only when client patch-capability is known; keep the
+sentinel universal by default). Guard retained in `autopatch.py` (dormant with the sentinel).
+
+## INVARIANT — empty-My-Packs capability MUST be session-stable
+
+F3 vs R1 establish a hard operational invariant for any deployment (sentinel or client
+guard): **the server MUST NOT switch a running FIFA client between sentinel-present and
+sentinel-absent for the My Packs group within a single FIFA process lifetime.**
+
+Rationale: the client resolves and caches the My-Packs group **ordinal** (positive when a
+group — real or sentinel — is present; `-1` when absent) from the `purchasegroup` response
+seen at Store-subsystem init. The resolver guard only reclassifies the ordinal *sign*
+(`≤0` → Browse). If a client that already cached a **positive** ordinal later receives a
+no-sentinel topology, the stale positive ordinal still takes the resolve branch and
+`FUN_180014420` returns NULL → crash at `0x180014882` (exactly F3). A **fresh** process that
+only ever sees the no-sentinel topology caches `-1` and is routed to Browse safely (R1).
+
+Practical rules:
+- Choose the My-Packs representation (sentinel-present vs sentinel-absent) **before** a client
+  starts its session, and hold it for that session.
+- The future patch-capability handshake (PART II §12) MUST therefore be decided at
+  login/session start, not toggled mid-session.
+- A NULL-return guard at `FUN_180014420` (deferred) is the only thing that would make a
+  mid-session flip crash-safe; until then, session stability is mandatory.

docs/plans/FIFA17_PATCHED_CLIENT_CAPABILITY.md

@@ -0,0 +1,358 @@
+# FIFA 17 — verified patched-client capability negotiation
+
+Goal: let the FIFA 17 backend suppress the synthetic My-Packs sentinel (id 65534)
+**only when the current FIFA process has positively verified that the CardsDLL
+resolver guard is active** (JNZ→JG at RVA `0x14858`). Unpatched / unsupported /
+unknown / failed-patch clients keep receiving the existing P2 active sentinel.
+
+Core principle: **the capability is not "this launcher supports the patch"; it is
+"the resolver guard was verified in *this particular FIFA process*."**
+
+This document is the design + the cross-component contract. It is deliberately
+additive: the P2 active-sentinel path (`docs/evidence/FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md`)
+remains the default and the universal fallback.
+
+---
+
+## 1. Architecture inventory (as-built, verified by reading the code)
+
+Data flow today (launch of one FIFA process):
+
+```
+LauncherApp::launch_game (openfut-launcher/src/app.rs:450)
+  -> account_sync::sync           POST /openfut/account/sync  (:8099)   [REQUIRED; launch is gated on it]
+  -> ensure_local_services()      spawn LSX, then autopatch.py --launcher-pid <launcher_pid>
+  -> game_launch::launch          umu-run FIFA17.exe (grandchild; launcher never learns FIFA PID)
+FIFA process
+  -> autopatch.py                 self-discovers FIFA by comm=='FIFA17.exe'; patches /proc/<pid>/mem each tick
+  -> FIFA -> backend              POST /ut/auth (login) ; GET /store/purchasegroup ; ...  (:8099)
+```
+
+Facts that shape the design:
+
+- **Launcher ↔ autopatch IPC = one-way stdout only.** `local_services::spawn`
+  (openfut-launcher/src/local_services.rs:279-296) pipes autopatch stdout/stderr
+  into the launcher `LogBuffer` line-by-line as `[autopatch] <line>`. There is no
+  socket / named pipe / status-file readback. `--launcher-pid` is the *launcher's*
+  own pid (local_services.rs:66), used for liveness, not to identify FIFA.
+- **Launcher ↔ backend = exactly one control call:** `account_sync::sync`
+  (openfut-launcher/src/account_sync.rs:43) — a tiny stdlib-HTTP `POST
+  /openfut/account/sync` on `openfut_account_sync_port` (default 8099), sent once
+  per launch, *before* FIFA starts, and **launch is blocked unless it succeeds**
+  (utas_server.py:1204). This is the reliable per-FIFA-process session boundary.
+- **Backend is single-account, stateless-per-request, threaded.** `SID` is a fixed
+  module constant shared by all clients (utas_server.py:32); account identity is one
+  global `ACCOUNT` singleton. There is **no per-session identity** in requests. The
+  only per-connection discriminator available at every handler is
+  `self.client_address[0]` (peer IP), currently unused. Server is
+  `ThreadingHTTPServer` (utas_server.py:3784); module is import-safe (server under
+  `if __name__ == "__main__"`).
+- **No bridge/proxy in the FIFA-17 path.** FIFA reaches the Python backend's
+  published `:8099` directly (client-side DNAT/hosts redirect); the openfut-bridge is
+  legacy FIFA-23. Docker's iptables DNAT preserves the source IP for external LAN
+  clients. The launcher and FIFA run on the **same** client machine, so the backend
+  observes them under the **same** peer IP regardless of NAT.
+
+## 2. Capability transport — options and choice
+
+Ranked against the as-built architecture:
+
+**autopatch → launcher (chosen: structured stdout line).**
+1. **Structured stdout line (CHOSEN).** Reuses the existing one-way pipe the
+   launcher already reads. It is *live* (only the current autopatch child's stdout),
+   inherently child-bound, and carries **zero stale-file risk** — a previous
+   launch's capability cannot leak because nothing is persisted. Smallest possible
+   change. Format is a machine-readable token (§4).
+2. Status file in `$XDG_RUNTIME_DIR` keyed by launcher-pid+FIFA-pid+version+timestamp
+   — works but needs explicit staleness handling and cleanup; more moving parts.
+3. Unix-domain socket — most capable but overkill; there is no bidirectional need.
+
+**launcher → backend (chosen: sibling HTTP endpoint on the account-sync port).**
+- A. **Existing session-init channel (CHOSEN).** Add `POST /openfut/fifa17/capability`
+  next to the existing `/openfut/account/sync` (same port 8099, same tiny stdlib-HTTP
+  client). It cannot ride *inside* account_sync because the capability is only known
+  *after* autopatch verifies (which happens after account_sync + FIFA start), so it is
+  a separate, later call — but on the same proven transport.
+- B. Blaze/login metadata — rejected: no OpenFUT-owned field is available without
+  risking a field FIFA depends on, and Blaze runs in a separate responder.
+- C. New local IPC + backend side-channel — unnecessary; A already exists.
+- D. Server-wide "assume patched" config — dev/testing fallback only; cannot
+  distinguish patched vs unpatched clients, so never the production mechanism.
+
+## 3. The capability (name + version + VERIFIED semantics)
+
+- Name: **`fifa17.empty_mypacks_resolver`**, integer version, current **`1`**.
+- **VERIFIED (v1) means, for THIS FIFA process:** the CardsDLL tested build was
+  recognised AND the live bytes at RVA `0x14858` are `7f 0f` (`JG`) **after
+  autopatch enforcement** — i.e. `guarded_action` returned `"patch"` (was `75 0f`,
+  written, re-read as `7f 0f`) **or** `"noop"` (already `7f 0f`).
+- It explicitly does **NOT** mean any of: "autopatch.py contains the guard code",
+  "the launcher build is new enough", or "a config flag is set". The signal
+  represents **observed runtime enforcement on the specific process**, nothing less.
+
+## 4. autopatch verification state + emitted line
+
+Per-FIFA-pid guard status (fail-closed; never loosens the existing byte guard):
+
+| state | meaning |
+|---|---|
+| `NOT_ATTEMPTED` | CardsDLL not yet mapped / guard not evaluated for this pid |
+| `VERIFIED` | live bytes == `7f 0f` after enforcement (from `patch` or `noop`) |
+| `UNSUPPORTED_BUILD` | live bytes are neither the known original nor patched (`guarded_action` → `skip`) |
+| `WRITE_FAILED` | `/proc/<pid>/mem` write raised |
+| `VERIFY_FAILED` | post-write re-read != `7f 0f` |
+
+Only `VERIFIED` advertises capability. On transition to `VERIFIED`, autopatch emits
+**once per FIFA pid** on stdout:
+
+```
+[store-guard] verified capability fifa17.empty_mypacks_resolver=1 fifa_pid=<pid>
+```
+
+Any non-verified terminal state emits an explicit, non-advertising status line, e.g.:
+
+```
+[store-guard] guard status=UNSUPPORTED_BUILD fifa_pid=<pid> (no capability advertised)
+```
+
+## 5. Launcher per-process capability state
+
+```rust
+pub struct Fifa17ClientCapabilities { pub empty_mypacks_resolver: Option<u32> }
+```
+
+- Starts **UNKNOWN** (`None`) at each launch.
+- Becomes `Some(1)` when the launcher parses a valid capability line from the
+  **current** autopatch child's stdout (`parse_capability_line`).
+- **Discarded** when autopatch stops / FIFA exits / launcher exits / next launch. It
+  is never persisted and never reused for a later FIFA process — staleness is
+  structurally impossible.
+
+On first `Some(v)`, the launcher registers the capability with the backend (§6) once.
+
+## 6. Launcher → backend registration + binding
+
+`POST /openfut/fifa17/capability` (port = `openfut_account_sync_port`, 8099), body:
+
+```json
+{"capability":"empty_mypacks_resolver","version":1,"personaId":<id>,"fifaPid":<pid>}
+```
+
+- **Binding key = source IP** (`self.client_address[0]`). The registration arrives
+  from the client machine's IP; FIFA's `/store/purchasegroup` requests arrive from
+  the **same** IP (same machine). `personaId`/`fifaPid` are for logging only (the
+  backend is single-account, so persona cannot discriminate clients).
+- Concurrency: distinct client machines → distinct peer IPs → independent decisions
+  (no global state). Two FIFA processes on **one** machine share an IP — an accepted
+  limitation (the backend is single-account anyway); documented in §Trust.
+
+## 7. Backend session-stable decision
+
+Per-IP record (guarded by a lock; threaded server):
+
+```
+_FIFA17_STORE[ip] = {"resolver": Option[int], "mode": Option[str]}   # mode: None|"sentinel"|"clean-v1"
+```
+
+- **Reset (session boundary):** `/openfut/account/sync` from `ip` sets
+  `{resolver: None, mode: None}`. This is the launcher's required per-launch call, so
+  every new FIFA process starts from a clean, unfrozen record — no cross-process leak.
+- **Register:** `/openfut/fifa17/capability` from `ip` sets `resolver = version`. If
+  `mode` is already frozen, it is logged as late and **ignored for this session**.
+- **Freeze point = first `/store/purchasegroup`** from `ip` (§9): if `mode is None`,
+  set `mode = "clean-v1"` iff `resolver == 1` else `"sentinel"`, and log once.
+  Thereafter `mode` is immutable for the session.
+- **Default / fail-closed:** an IP with no record (no account-sync, no capability),
+  an unknown resolver version, a late capability, or a disappeared capability all
+  resolve to (or remain) `"sentinel"`.
+
+## 8. Freeze point rationale
+
+Freeze at **first `/store/purchasegroup`**, not at login/account-sync. account-sync
+fires *before* FIFA starts and *before* autopatch can verify, so freezing there would
+always be `sentinel`. First Store request is the earliest moment at which a genuine
+capability can already be registered (autopatch verifies at process start; the user
+opens the Store later), while still being a single, well-defined topology commit for
+the session. Once Store topology is served, it must not change (the F3 experiment
+proved a mid-session flip can leave a stale positive ordinal that crashes even the
+sign-only guard — see `FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md` PART III/IV and the
+SESSION-STABLE invariant).
+
+## 9. Store behaviour (additive switch)
+
+At `store_catalog`, only the zero-owned-packs branch changes:
+
+```
+if not owned_ids:
+    if fifa17_empty_mypacks_mode(client_ip) == "clean-v1":
+        pass                      # patched client: emit NO mypacks group; guard routes -1 to Browse
+    else:
+        <append active 65534 sentinel exactly as today>   # P2 fallback (unchanged)
+```
+
+Untouched: real owned-pack rendering, `PACK_CATALOG`, pack 70, normal packs 1/5/6/7,
+profile state, all store env flags. Default remains sentinel. This lives in the FIFA-17
+Python backend only — **never** in game-independent OpenFUT Core.
+
+| client | zero packs | real unopened pack |
+|---|---|---|
+| verified v1 | **no sentinel** (clean) | genuine My Packs, no sentinel |
+| no / unknown capability | **active 65534 sentinel** | genuine My Packs, no sentinel |
+
+## 10. Trust model (Task 14)
+
+This is **not** anti-cheat / attestation. OpenFUT assumes the user controls the
+launcher/client machine and the server is a private preservation environment. The
+verification exists to prevent *accidents*: a stale capability, an unsupported
+CardsDLL build, a failed autopatch, the wrong process, or an unpatched client
+receiving no sentinel and crashing. No signatures / PKI / remote attestation.
+
+Isolation across *distinct client machines* relies on the backend observing distinct
+peer IPs (source-IP-preserving publish; Docker's default for external LAN via iptables
+DNAT). Two FIFA processes on one machine cannot be distinguished by IP — accepted,
+since the backend is single-account. The single-client production case is unaffected
+by NAT because launcher and FIFA share one IP.
+
+## 11. Fail-closed matrix (Task 15) — every failure ⇒ sentinel
+
+autopatch missing / not run · guard `UNSUPPORTED_BUILD` / `WRITE_FAILED` /
+`VERIFY_FAILED` · launcher cannot parse the line · registration POST fails ·
+account-sync never called · unknown capability version · capability arrives after
+freeze · capability disappears after a sentinel freeze — **all resolve to the active
+65534 sentinel.** Asserted by tests (matrix A–J) and this document.
+
+## 12. P2 retained (Task 16)
+
+The active-sentinel implementation is **not** removed. It is the else-branch of the
+switch and the universal default for unpatched clients, unsupported builds, failed
+patches, unknown launchers, and late capabilities. The clean path is purely additive.
+
+---
+
+## 13. Session binding (hardening — supersedes the per-IP prototype)
+
+**History.** The first implementation keyed the backend capability/store-mode by
+**source IP alone** (§7 as originally written). That was rejected before deployment:
+two FIFA processes that share a source IP — concurrent, or a relaunch — would share
+the key, so an *unverified* process could inherit a *verified* one's `clean-v1`
+topology and crash on the empty-My-Packs resolver. Source IP is now **auxiliary only**
+(logging, a fail-closed sid/ip sanity check, and the pending hand-off key). This
+history is retained deliberately; do not treat per-IP as the design.
+
+**Authoritative key = the per-login UTAS session id (`X-UT-SID`).** `/ut/auth` now
+mints a fresh unique SID per login (was a shared constant `OPENFUT-SID-…0001`); the
+client echoes it on every later call, and it is **live-confirmed present on real
+`/store/purchasegroup` requests**. The SID uniquely identifies one FIFA process/login:
+a relaunch re-auths → new SID; two concurrent logins → two SIDs. The legacy constant
+is still accepted by the retired security-question gate only, and is **never** used to
+grant `clean-v1`. A store request whose SID was opened on a different source IP is
+fail-closed to sentinel (sid/ip sanity check).
+
+**Why not persona alone:** the backend is single-account, so `personaId` cannot
+distinguish two sessions, and a relaunch keeps the same persona — persona alone would
+leak a prior session's mode. Persona is used only (with IP) to key the pending hand-off.
+
+### State machine (per session, keyed by SID)
+```
+Capability : Unknown | ResolverV1
+StoreMode  : Unfrozen | Sentinel | CleanV1
+
+/ut/auth (new SID)         : Capability=Unknown, StoreMode=Unfrozen, record {ip,persona}
+                             + consume any pending (ip,persona)  -> Capability=ResolverV1
+capability registered      : bind to the one live Unfrozen/Unbound session for (ip,persona)
+                             -> Capability=ResolverV1 ; else stage single-use pending ;
+                             else (a session exists but is frozen/ambiguous) -> ignored-late
+first /store/purchasegroup : Unfrozen + ResolverV1 -> freeze CleanV1
+                             Unfrozen + otherwise   -> freeze Sentinel   (consume pending first)
+late capability            : StoreMode already frozen -> unchanged (ignored-late, not staged)
+capability lost/cleared    : after a CleanV1 freeze -> stays CleanV1 (mode is cached)
+session idle > TTL / reaped: session discarded (a later store with that SID -> Sentinel)
+```
+
+### Registration order + pending hand-off
+The verified capability is known only after the FIFA process exists, CardsDLL is
+loaded, and autopatch confirms the JG bytes — which may land before or after
+`/ut/auth`, but reliably before the user opens the Store. The launcher cannot know
+the SID, so its registration is matched to a session by (source_ip, persona) as a
+**single-use, short-TTL pending** (`FIFA17_PENDING_TTL = 120s`) that is consumed by
+exactly one session, at whichever of these happens first for that session: its
+`/ut/auth` (pending predates login), the registration itself (session already live —
+bound directly), or its first store request (lazy). If the Store is reached before a
+capability binds, the session freezes **Sentinel** (fail-closed); a later capability
+does not change it.
+
+### Session cleanup (Task 10)
+- **creation:** at `/ut/auth`.
+- **last activity:** bumped on every `/store/purchasegroup` for the session.
+- **freeze:** first `/store/purchasegroup`.
+- **expiry:** lazy sweep on every session op removes sessions idle for
+  `FIFA17_SESSION_TTL = 3600s` and pendings older than `FIFA17_PENDING_TTL`. Explicit
+  Blaze/UTAS teardown is not reliably observable at this handler, so a conservative
+  activity-based TTL is used instead. Reaping only removes *expired* entries and never
+  affects another live session from the same IP/persona (keyed by distinct SIDs).
+
+### Residual limitation (documented, fail-closed)
+FIFA carries no launcher-controllable per-process token, so two **simultaneous** logins
+from the **same (ip, persona)** cannot be disambiguated at the instant a capability is
+registered while *both* are Unfrozen/Unbound. That ambiguous case resolves to
+`ignored-late` → **both freeze Sentinel** (safe: an unverified process is never granted
+clean). The normal one-launcher-per-FIFA and sequential-relaunch flows bind correctly
+(proven by matrix K/L/M). This is a UX conservativeness, never a safety hole.
+
+---
+
+## 14. Deployment candidate & controlled A/B (overnight reconciliation 2026-08-13)
+
+**Launcher lineage reconciliation.** The two divergent launcher histories (merge
+base `87241ac`) were reconciled by a real merge — **not** a rebase/squash/rewrite —
+in a clean worktree:
+- `feat/launcher-arming` `13339c1` (client arming + FIFA-17 capability reporting)
+- `feat/sbc-hook-tracing` `958ff24` (openfut-hook SBC request tracing / RE probes)
+
+Merged commit **`ca7ce26`** on branch `integration/fifa17-launcher-capability-sbc`
+retains **both** ancestors (`git merge-base --is-ancestor` true for both `958ff24`
+and `13339c1`). The only conflict was `src/process.rs` (launcher-arming deleted it +
+dropped `mod process`; SBC only incidentally tidied it) — resolved **keep-deleted**
+(orphan module; the SBC feature lives entirely in `openfut-hook/*`). The two features
+are in disjoint crates/processes (launcher-crate Rust host vs `openfut-hook` Windows
+DLL) and share no stdout readers, child handles, or lifecycle — no integration code
+was needed.
+
+**Gitlink status — DEFERRED (morning blocker).** The superproject gitlink still
+records the pre-reconciliation `958ff24`. It was **not** bumped to `ca7ce26` because
+the live submodule checkout carries uncommitted `openfut-hook/*` WIP that overlaps the
+merged hook content; a non-destructive `git checkout ca7ce26` is refused ("local
+changes would be overwritten"), and no `-f`/`reset`/`clean` is permitted. The user
+must first reconcile that WIP against the merged `openfut-hook`, then the gitlink can
+bump. Preservation artifact: `/tmp/openfut-launcher-overnight-tracked.patch`
+(sha256 `8e65de2c…`).
+
+**Validated deployment-candidate tuple** (reproducible from git except the deferred
+gitlink):
+```
+superproject HEAD        a82407c  (backend per-session + docs)
+  backend guard          b0d5e04  fix(fifa17): guard missing store category resolution
+  client proof           fc29c2e  docs(fifa17): record no-sentinel client resolver proof
+  autopatch report       1c396dd  feat(fifa17): report verified client patch capability
+  backend negotiate      b25761e  feat(fifa17): negotiate clean empty My Packs mode
+  session binding        805d754  fix(fifa17): isolate patched-client capability per session
+launcher merged HEAD     ca7ce26  merge: reconcile launcher capability and SBC tracing
+  (ancestors 13339c1 capability + 958ff24 SBC)
+launcher gitlink (super) 958ff24  <-- to become ca7ce26 once WIP reconciled
+```
+Local build artifacts (NOT deployed): launcher `target/release/openfut-launcher`
+(sha256 `a390c61d…`); backend image `openfut-fut-backend:candidate-overnight`
+(`84d280be…`, ships `utas_server.py` `33e0ef3…`). Live `:dev` image and the running
+container were left untouched.
+
+### Controlled A/B sequence (execute only in a later authorized deploy task)
+**A — patched client:** fresh FIFA process → autopatch verifies the JG guard →
+launcher parses the verified line and registers → `/ut/auth` mints a fresh `X-UT-SID`
+→ capability binds to that SID → first `/store/purchasegroup` freezes `clean-v1` →
+backend omits 65534 → Store opens on Browse Packs, no crash.
+**B — unpatched client, same machine/IP, NEW session:** new `X-UT-SID`, no verified
+capability → first store freezes `sentinel` → backend emits active 65534 → no crash.
+Proves same-IP isolation + fail-closed fallback.
+**C — failed patch (optional):** autopatch reports `UNSUPPORTED_BUILD`/`VERIFY_FAILED`
+→ launcher never registers → `sentinel`.
+Production remains the P2 active-sentinel universal default until this A/B passes.

fifa17-recon/.dockerignore

@@ -0,0 +1,16 @@
+# Keep the authoritative-tree build context lean: only tools/ and data/ runtime
+# files (plus the Dockerfile's own entrypoint/manifest) are needed in-image.
+.git
+.gitignore
+artifacts
+captures
+futmem
+staging
+docs
+FUT-RUNBOOK.md
+README.md
+data/memdump
+**/__pycache__
+*.pyc
+*.pem
+*.key

fifa17-recon/.gitignore

@@ -9,3 +9,5 @@
 *.log
 __pycache__/
 captures/
+staging/
+tools/fifa17_profile.json

fifa17-recon/data/memdump/.gitignore

@@ -0,0 +1,4 @@
+# Raw /proc/PID/mem captures: regenerate with tools/db_dump.py, never commit.
+# One of these directories reached 2.3GB.
+data/memdump/*.bin
+data/memdump/*.raw