OpenFUT/fifa17-recon/docs/priority-2026-08.md

OpenFUT priorities, August 2026

Written 2026-08-04. Supersedes the ordering implied by REBUILD_RESEARCH.md §14.

This document exists to answer one question: what is the next thing worth doing, and how would we know if it worked? Everything here is ordered by the cost of the measurement that would settle it, not by how important the outcome feels.

Two rules govern every entry:

• A hypothesis without a cheap way to disconfirm it is worth less than a measurement.
• Omission is safe; a wrong shape freezes the game. When a body's shape is unknown, the correct action is to send less, not to guess more.

Values that have not been confirmed against the decompiler or against live traffic are marked TODO/CONFIRM. Where I do not know something and cannot find out without running the game, the entry says so rather than reporting something adjacent.

---

1. What changed since the assessment brief was written

Three findings landed after the brief and they reorder the plan.

1a. The observation session ran, and did not produce the match shape

The combined session (play a match, then navigate to Seasons / Tournaments / FUT Champions with FUT_MODES still off) executed on 2026-08-03 under the stated constraints: one launch, zero config changes, pure observation. It returned three things, none of which was the target:

finding	evidence
Seasons refuses with zero requests to any layer	UTAS, Blaze and POW logs show only pings and one census subscription during the failure
squad/mode/draft/state exists and is answered wrongly	Real client (ProtoHttp) requested it; our generic /squad route returned a full active-squad object
Draft hung the client (process alive, no dump written)	Not a crash. Nothing has isolated the cause; the wrong body is the obvious suspect with exact timing, but it is not logged as the cause

The consequence for planning: both known routes into a match are blocked, so the /match request shape cannot be captured by observation alone any more. It now sits behind a fix rather than in front of one. That is a real demotion and it is why the match shape is no longer the next task.

squad/mode/draft/state is the fourth endpoint this project has found that is invisible to the binary's URL template table because the caller composes it by appending a suffix. The template table is a floor, not a ceiling. Treat it as such permanently.

1b. The User-Agent split

The request log records User-Agent, so real client traffic (ProtoHttp) can be separated from this project's own curl and python probes. Doing that changed the project's picture of itself materially:

endpoint	real client	our probes
/user/accountinfo	23	49
/clientdata/userHubData	13	2
/leaderboards/options	5	1
/season, /season/user	0	2
/tournament, /tournament/user	0	3
/champion	0	2
/match	0	2
/clubUser	0	93
/user/list	0	180

Endpoints this project had treated as exercised were exercised only by itself. /clubUser and /user/list in particular have 93 and 180 recorded hits and not one of them came from the game. Any claim of the form "the client asks for X" that predates this split is unsupported until re-checked with the filter on.

This has been propagated into OPENFUT_PROJECT_REPORT.md §5 and §6.

1c. The FutMoveCard retraction

This is the largest correction in the project's history and it is documented in full in REBUILD_RESEARCH.md §16 and in commit f488793.

The repo claimed FutMoveCard (0x180128600) had no skip handler and parsed only itemData and dreamSquads. It has two skip-handler call sites and parses seven atoms. The claim came from writing src[:4000] of a 6,193-character decompile and then searching the truncation. Both skip-handler sites and four of the seven atoms lay past the cut.

The cost was not the wrong fact. The cost was the inference built on it: "any extra key desyncs this parser, so the response body cannot be the problem, so the deciding factor is client-side state, not the wire." That premise directed seven consecutive attempts at Send to Club and it was wrong.

What the correct read gives us is a necessary condition that had never been satisfied:

PUT ut/%s/item returns per-item VERDICT records, not an acknowledgement.
  id(0x15c)         INT     -> record+0x00
  pile(0x226)       STRING  -> enum 0x180142650  (club=7, purchased=6, trade=5)
  success(0x2fa)    BOOL    -> record+0x0c,  initialised to '\0' per element
  reason(0x279)     STRING  -> "Destination Full" = 0xf
  dreamSquads(0xe9) INT array;  anything else -> skip handler

The completion handler raises EVENT_CARDS_MOVE_CARD_FAILURE when the record vector is empty or when record+0x0c != 1. Every body this project has ever returned from that endpoint, {} included, therefore reported the move as failed. Quick sell survives an identical {} because its callbacks read only the transport code and ignore the body. That is the whole asymmetry, and it was on the wire the entire time.

The correct shape is implemented and staged behind FUT_MOVE_BODY=ack. The default remains empty because sufficiency is untested: a necessary condition being satisfied does not prove there is no second one.

---

2. The next task

RESOLVED 2026-08-04, the same day this was written. The launch happened and it worked: five cards sent to the club, session survived, no logout, cards persisted. FUT_MOVE_BODY=ack and FUT_PACK_AUTOCLUB=0 are now the defaults. Full account in REBUILD_RESEARCH.md §17. The section below is left as written, because the reasoning that put this first is the part worth reusing, not the outcome.

One correction it earned: the pre-launch instruction to leave FUT_PACK_AUTOCLUB=1 alone was wrong. Autoclub empties the pending pile at purchase time, so the reveal screen has nothing to assign and the client never sends the request. The first attempt produced no PUT /item at all. A workaround that suppresses a request suppresses the evidence for the bug it works around.

The next task is now §3.2, the MY CLUB counter.

One launch. Set FUT_MOVE_BODY=ack. Buy a pack, reveal it, press Send to Club.

Everything about this is cheap. One flag, one existing menu path, one binary outcome observable without any instrumentation: either the session survives or the client returns to the main menu with the FUT connection error.

It is first for four reasons:

1. It is the only open problem where the decompiler has produced a verified necessary condition that has never been satisfied. Every other open item is a hypothesis.
2. The failure it targets is the single largest user-visible defect. The current workaround (deposit pack contents straight into the club and keep the pending pile empty) makes the reveal screen show nothing to assign.
3. It disconfirms cheaply in both directions. If the session survives, Send to Club is fixed and seven attempts' worth of client-state theorising is closed. If it still fails, we have eliminated the wire as a sufficient explanation while keeping the necessary condition satisfied, which is a genuinely narrower position than before.
4. It carries no freeze risk that the current default does not already carry. The response is a three-field flat record vector against a deserializer whose full atom set is now known, with two confirmed skip handlers.

Pre-launch checks

• FUT_MOVE_BODY=ack, everything else at its default. In particular leave FUT_PACK_AUTOCLUB=1 alone; the ack path was written for that configuration.
• Confirm the running server is the new code. Query PUT /item with a scratch profile and check the response is a record vector, not {}. A silent restart failure has already cost this project one live test and one pack.
• Back up the profile with fut_admin.py --backup first.

What to record

• Whether the session survives, verbatim error text if not.
• Whether the card actually appears in MY CLUB afterwards.
• Whether ut/delete/auth follows (the logout that has accompanied every previous failure).
• The exact request body the client sent, filtered to ProtoHttp.

Do not

• Do not change a second flag in the same launch. If ack fails while something else is also different, the result explains nothing.
• Do not fix anything else noticed during the session.
• Do not run a probe against the server while the client is running; the User-Agent table above is the reason.

---

3. The measurement queue

Ordered by cost of the measurement, cheapest first. Each entry states what would disconfirm it, because an entry that cannot be disconfirmed does not belong on this list.

3.1 Send to Club under FUT_MOVE_BODY=ack

Covered in §2. Cost: one launch, one flag. Status: run, and it worked. Both flags are now defaults. The measurement cost one pack and about four minutes.

Worth noting against the "what could make this plan wrong" section below: the outcome was the good one, but §7's warning still stands unchanged for everything else. This result does not make the rest of the queue more likely to be right; it makes the method more likely to be right.

3.2 The MY CLUB counter, GET /club/stats/<mode>

The hub tab bar reads MY CLUB 0 while the club holds 99 items and renders all of them correctly when opened. Eliminated already: the item list itself, pileSizeClientData (a 16-entry probe with uniquely identifiable values changed nothing), and lazy loading.

The counter is server-supplied by GET /club/stats/<mode>, whose response class is FutStickerBookStats2 (0x180130150), body shape {"stat":[{contextId, contextValue, type, typeValue}]}. The factory wipes the map before parsing, which is why the current {} route is not neutral: it actively clears the counter every poll. The paired list endpoint FutStickerBookSearch has no count atom at all, and that asymmetry is the reason the list can be right while the number is zero.

Cost: one flag, one glance at the hub. Disconfirmed by: the counter staying at 0 with a populated stat set.

TODO/CONFIRM: which contextId and type values correspond to the club bucket. The enum has been read but the mapping to the specific tab has not been verified against a screen. A reviewer flagged that the current plan probably populates the wrong bucket for the screens actually opened, and that is unresolved. Expect to need a second iteration varying only the ids.

Also worth taking for free during any launch that reaches the hub: ACTIVE SQUAD in the same tab bar reads 11/23 correctly. Whatever differs between that counter and the club one is a direct lead and it costs nothing to look at both side by side.

3.3 Route squad/mode/draft/state away from the generic /squad handler

Not a measurement, a fix; it is here because it is the cheapest thing that could unblock a route into a match. Right now that endpoint receives a full active-squad object: 23 slots, nested itemData, the 33-integer custom string. The recovered FutGetDraftCurrentState schema wants roundsInfo plus a state enum (CAPTAIN_DRAFT, PLAYER_DRAFT, READY_FOR_MATCH). Feeding that parser a squad object is a textbook type-desync candidate and the timing of the hang matches.

Per the omission rule, the first version should route it to a minimal body, not a guessed-complete one. Behind a flag.

Disconfirmed by: Draft still hanging at the same point with the correct minimal body. That would be genuinely informative, because it would mean the hang is not the response.

3.4 FUT_ACCOUNTINFO=1

The real client requests /user/accountinfo 23 times and we return {}. It is the highest-traffic endpoint we deliberately stub, and after the User-Agent split it is one of only three endpoints with meaningful real-client traffic that we do not serve properly.

Risk: medium, and honestly stated. This is a populated body on a path the client genuinely parses, which is the exact class of change that broke the store and broke pack opening. One flag, one launch, revert on any freeze.

3.5 Seasons

Currently unactionable from the server side and I will not pretend otherwise. The client raised "There was a problem communicating with the FIFA Ultimate Team servers" without contacting any server. UTAS, Blaze and POW logs are all clean for that window. POW is eliminated (the same failure occurs with POW fully disabled and with it enabled).

This is the third time FIFA's error text has described a network failure that did not occur. The strings are generic session-error text, not diagnostics; stop reading them as evidence about the network.

I cannot tell what gates Seasons without instrumenting the running client. The decision logic is in the Denuvo-packed executable, whose code exists only in a live process. The only avenue that would produce evidence is the live-memory probe pattern (/proc/PID/mem, the PE maps flat at 0x140000000), used read-only against the FUT state machine while the menu is open. That is a real session of work, not a cheap measurement, and it should not be started until §2 through §3.4 are done.

3.6 The /match request and response shape

Still uncaptured. /match has never been requested by the real client. _match_result() falls back to draw because the score fields are unknown; the reward path has never executed against a real match.

This is now blocked behind §3.3 or §3.5, since both routes into a match are refusing. It is not a task, it is the payoff of one.

3.7 Store tiles reading "unknown"

Diagnosed, not fixed, and deliberately parked. The "unknown" string is an unconditional default in a string constructor: the field is never written. The store renders display groups, and displayGroup is parsed recursively by the same element parser. Sending it populated froze the store, so it sits behind FUT_STORE_GROUPS, default off.

Fixing it properly requires working out the display group's own field set rather than copying the pack's, which is decompiler work with no cheap live measurement attached. It is cosmetic; packs are buyable and openable. Park it.

---

4. The Rust port

4.1 Timing: after, not now

The port should happen after the core loop is live-proven, and the argument that leads is the match result shape.

_match_result() currently falls back to draw because nobody knows which fields carry the score. That is not a detail of the match endpoint; it is the shape of the data the reward economy consumes. Porting an economy whose input schema is a placeholder means porting the placeholder, then porting the correction. The Python is where cheap schema iteration happens: a wrong guess costs a restart, not a recompile and a type refactor.

The same argument applies to Send to Club, to draft state, and to club stats. Three of the four items in §3 will change a response schema. Freeze the schemas, then port.

4.2 The contract suite can certify a port

test_fut_contract.py (452 lines, 380 checks) was decoupled from the Python implementation this cycle. It now imports json only, manipulates no sys.path, and reaches the server over HTTP with FUT_TEST_BASE and FUT_TEST_PERSONA_ID configurable by environment.

That means it is an implementation-independent conformance suite. A Rust server that passes all 380 checks is wire-compatible with the Python one to the extent the suite covers, and the suite's checks are type assertions against the reversed schemas, which is exactly the property that matters here (a scalar where an object belongs is what freezes the game). This is the single most valuable de-risking asset the port has, and it now exists.

test_match_rewards.py (51 pure unit checks) is not portable in the same way; it tests Python functions directly. Its 51 assertions would need re-expression against the ported economy.

4.3 How much of openfut-core survives: measured

The proposed narrowing was "core owns ownership and economy, keyed by opaque integer item ids; core knows nothing about card identity." That boundary is correct, and every per-item prediction made about it held up:

divergence	prediction	verdict
int item id / assetId / resourceId	deleted from core	confirmed
numeric nation / league / teamid	deleted from core	confirmed
rareflag / cardsubtypeid vs the Hero/Icon enum	deleted from core	confirmed
33-int formation array, kicktakers, personaId	slots relational in core, encoded by bridge	confirmed
the pile model	genuine work, survives	confirmed

Under narrowing the clearly-deleted identity surface is models/card.rs (62 lines), models/chemistry_style.rs (26), services/card_db.rs (52) and routes/cards.rs (173), so 313 lines, plus the identity-dependent parts of squad.rs chemistry and sbc.rs validation. About 10 percent deleted outright. On that framing, narrowing looks survivable.

Narrowing is not what guts core. FIFA 17 relevance is. Mapping each core service against the 45-template FIFA 17 URL table, six services model features that have no FIFA 17 endpoint at all:

service	lines
achievement	215
objective	175
event	172
checkin	133
upgrades	125
notification	49
total	869

These are modern live-service concepts. FIFA 17 has no achievements endpoint, no events, no notifications, no daily check-in, no card upgrades. objective is not merely unmapped: this project searched the binary and found no FutGetObjectives class exists, which is why the hub's Manager Tasks tile has no known feed.

Those 869 lines are identity-free, so the narrowing boundary keeps every one of them. They survive perfectly and are worth nothing here.

The integration suite reclassifies the same way:

	tests
target features with no FIFA 17 endpoint	26
assert identity or presentation being deleted	14
ownership and economy, survive	61

An earlier assessment in this project reported "81 of 101 survive" and used it to argue the suite was an asset. The number was right and the implication was wrong: 26 of those 81 test features this game does not have. The real figure is 61 of 101, about 60 percent.

To name that plainly: core's reusability was argued before its FIFA 17 relevance was measured, and the 6,707-line total was doing persuasive work it had not earned. Reusing existing code is attractive partly because it exists and represents effort already spent, and that is not a technical reason.

Conclusion. Reuse openfut-core for its scaffolding (migrations, pool, app wiring, error model) and for the 61 relevant tests, not for its service layer. What genuinely transfers is the economy services that have a real FIFA 17 endpoint (club, market, pack, match_service, profile, squad storage, statistics), roughly 1,400 lines. Writing a FIFA-17-shaped core fresh against the existing scaffolding is comparable effort to adapting the current one, and adapting carries a specific risk: dragging 869 lines of live-service machinery along because deleting working code feels wasteful.

TODO/CONFIRM: season, fut_champs, draft and sbc (1,013 lines) do have FIFA 17 endpoints but materially different schemas, and none has ever been exercised live. Whether their logic survives is unknown and cannot be settled until §3 produces live traffic for them.

TODO/CONFIRM: the pile model's cost. It needs a migration adding a pile column to owned items, a move operation enforcing the "never in two piles" invariant, and per-pile queries. I will not estimate lines without reading the ownership tables properly.

4.4 The Python side of the port is cleaner than expected

utas_server.py holds 48 handler functions. Twenty touch STORE.*, and only 44 lines in total reference it. State access is shallow and concentrated rather than smeared through serialization, so an HTTP seam between a Rust core and the existing Python wire layer is viable. This would be an incremental extraction, not a rewrite.

The wire and protocol layers (Blaze, LSX, POW, roster, seed schema; 3,083 lines) should be ported last or not at all. They are working, they are protocol-shaped rather than logic-shaped, and they are the least likely part of the system to change.

---

5. Standing requirements

These are not tasks with a completion date; they are rules that apply to future work.

The User-Agent filter is the default. Every capture and analysis tool must filter to ProtoHttp by default and require an explicit flag to include this project's own probes. The unfiltered view has already produced at least one wrong picture of what the client asks for. Implemented in futlog.py; any new analysis tool must do the same.

Every risky change ships behind a flag whose default is the live-proven value. This convention exists because two working screens were broken by shipping corrections on by default: FUT_STORE_GROUPS froze the store, and FUT_STORE_FIELDS stopped packs opening.

"The parser reads X" is not "changing X is safe." That inference is what broke pack opening.

Never conclude an absence from a truncated or unverified-length extraction. The FutMoveCard retraction and the earlier Memory.getBytes bytearray scan (which silently read nothing and returned zero hits) are the same failure. Assert that the searched region covers the whole function before reporting that something does not appear in it.

Verify against the decompiler and against live traffic, not against the notes. ENDPOINT_MAP.md has been wrong repeatedly: it claimed FutMoveCard parses chemistry (it does not), called seven store pack fields skipped no-ops (all are parsed), and gave price-object keys as amount/currency when the parsers read externalPriceId.

Clean-room only. Wire format is learned from the game's own binaries. No EA source.

Closed 2026-08-04: the two .rdata addresses flagged as wrong during review never reached any document. They existed only in an agent's recon report. The reviewer's corrected values, kept here because they are verified and useful: RS4:FutGetClubInfoServerResponse is at 0x180221a38 (not 0x180220e38) and RS4:FutStickerBookSearchServerResponse is at 0x180221e48 (not 0x180221248).

Implemented 2026-08-04: the User-Agent filter is now the default in futlog.py, which replaces the previous one-off log summariser. It caught an overstatement in the same session it was written: see REBUILD_RESEARCH.md §18.

---

6. Flags: current defaults and their justification

flag	default	why
FUT_MASSINFO	full	live-proven; boot-critical
FUT_USERINFO	roster	live-proven; packs and full are untested rungs
FUT_PACK_AUTOCLUB	0	the workaround is retired; it emptied the pending pile and suppressed the move request entirely
FUT_MOVE_BODY	ack	live-proven 2026-08-04; empty, full and dreamsquads all report the move as failed
FUT_MARKET	sample	live-proven
FUT_MODES	off	changes /season, whose array-root freeze risk cannot fire unless the client asks, and it has never asked
FUT_ACCOUNTINFO	off	queued at §3.4
FUT_SQUAD_LIST	off	live-proven off
FUT_PILESIZES	off	probe showed no effect on the counter
FUT_STORE_GROUPS	off	froze the store
FUT_STORE_FIELDS	off	stopped packs opening
FUT_CLUB_RENAME	off	clubNameChangeAllowed: true crashes the client at FIFA17.exe+0x71b8651; a contract check guards this
FUT_CLUB_IDENTITY	off	the real client has never requested those paths (0 of 93, 0 of 180)

Do not enable the bottom five without a new reason. "To see what happens" is not one.

---

7. What could make this plan wrong

The plan's ordering rests on assumptions that could each fail, and it is worth stating how each failure would show itself.

The ack could satisfy a necessary condition and still fail. This is the most likely bad outcome and it is not a refutation of the analysis; EVENT_CARDS_MOVE_CARD_FAILURE firing on an empty or success != 1 vector is confirmed, but nothing establishes it is the only gate. If ack fails, the next question is whether the failure event still fires (which would mean a second wire condition) or whether the client fails somewhere else entirely (which would revive, on much narrower grounds, the client-state line the retraction closed). The plan should not treat a negative ack result as "back to square one."

The retraction may not be the last one. Every atom table and schema in this repo was produced by the same extraction tooling that produced the false FutMoveCard claim. The specific bug (a truncated decompile) has been identified, but the general risk (an absence inferred from an incomplete search) applies to every "this class does not parse X" statement in ENDPOINT_MAP.md. Any of them could be wrong in the same direction. Treat every negative claim in the docs as weaker than the corresponding positive claim.

Seasons might be gated by something no server can supply. If the gate is an entitlement check, a persona attribute or a Blaze session property evaluated entirely inside the packed executable, then no amount of response-shape work reaches it and §3.5's live-probe session is the only path. It is also possible that path shows the gate is unreachable, in which case Seasons is out of scope and the match loop has to be reached through Draft or not at all.

The draft-state hang might not be the response body. The timing is suggestive and the type-desync mechanism is plausible, but nothing has isolated it. If a correct minimal body still hangs, §3.3 does not unblock the match shape and §3.6 stays blocked behind §3.5, which is the expensive branch.

The port conclusion assumes the narrowed core is the right architecture at all. The measurement in §4.3 answers "how much of core survives narrowing", not "is a Rust core the right destination". The Python is working, live-proven on the paths that matter, and cheap to iterate. If schema churn continues at the current rate through the whole of §3, the honest answer might be that the port should be deferred again rather than scheduled. The trigger to revisit is: schemas stop changing for a full cycle of live sessions.

The User-Agent finding might understate the problem rather than overstate it. The split distinguishes ProtoHttp from our probes, but it does not prove every ProtoHttp request was made by the screen we assumed. Attributing requests to specific menu actions still rests on timing correlation, which is weaker evidence than the User-Agent field itself.

Some of this game has never been opened. Large parts of the FUT surface (SBCs, most of the store, tournaments, leaderboards, champions) have never been navigated to by a human in this project. Endpoints reading "0 client requests" mean "never visited", not "never wanted". The next unvisited screen could produce a fifth suffix-endpoint surprise and reorder everything below §2.