OpenFUT/docs/evidence/FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md

# 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.