fifa17-recon: SOLVED "Send to Club" -- it was the response body all along

Live 2026-08-04 with FUT_MOVE_BODY=ack and FUT_PACK_AUTOCLUB=0. Bought a bronze pack,
opened it, chose Send to Club. The session SURVIVED, the five cards persisted into the
club pile, and there was no ut/delete/auth logout -- the logout that accompanied all
seven previous attempts.

  11:15:48 PUT /item
    req {"itemData":[{"id":100000125,"pile":"club","swap":0,"tradeId":0}, ... x5]}
    res {"itemData":[{"id":100000125,"pile":"club","success":true}, ... x5]}
  11:15:49 GET /user/credits      session alive
  11:15:51 GET /hub               no error dialog
  11:16:06 GET /club?year=2017... MY CLUB opened

PUT ut/%s/item never was an ack endpoint. It builds per-item VERDICT records, and the
completion handler raises EVENT_CARDS_MOVE_CARD_FAILURE when the vector is empty or
success != 1. Every body this project ever returned, {} included, told the client the
move had FAILED, and the client ended the FUT session because that is what that event
does. We were failing our own move.

Defaults flipped: FUT_MOVE_BODY empty -> ack, FUT_PACK_AUTOCLUB 1 -> 0. The autoclub
workaround is retired.

New intel, captured for the first time because the client had never got this far: the
request carries `swap` and `tradeId` beside id/pile. We ignore both and the move
succeeded, so neither is load-bearing for a pending-to-club move.

PROCESS, and this is the part worth keeping. The FIRST attempt at this test produced
no PUT /item at all: FUT_PACK_AUTOCLUB=1 had already emptied the pending pile at
purchase time, so the reveal screen had nothing to assign and the client never issued
the request. The workaround for the bug was hiding the bug. Before testing a fix,
check the configuration still lets the client make the call the fix is for.

Two self-inflicted incidents, both recorded in REBUILD_RESEARCH S17:
- Restarting the server to inject a flag WHILE FIFA was running produced the exact
  "error connecting to FIFA 17 Ultimate Team" dialog this project spent weeks chasing,
  from a plain connection refusal during the ~30s window. Restart only at the main
  menu, and check the log for ProtoHttp requests before blaming a response.
- pgrep -f matched the invoking shell twice, killing it before the restart, because
  the same command contained the literal script name in a later clause.

Docs updated: REBUILD_RESEARCH S17 (the solve), priority-2026-08 S2/S3.1/S6 (next task
is now the MY CLUB counter), PROJECT_REPORT 6a, HANDOFF 5a plus the stale "FutMoveCard
has no skip handler" claim in S3 and a new 5d for Seasons/Draft.

380 + 51 checks green.

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

OPENFUT_PROJECT_REPORT.md

@@ -177,24 +177,40 @@ two working screens — once freezing the store outright.
 
 ## 6. Open problems
 
-### 6a. "Send to Club" ends the FUT session
+### 6a. "Send to Club" ends the FUT session — SOLVED 2026-08-04
 
-Opening a pack displays the cards correctly. Choosing **Send to Club** produces *"there
-has been an error connecting to FIFA 17 Ultimate Team"* and a logout. The cards **do**
-move correctly server-side; only the acknowledgement is rejected.
+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.
 
-Eliminated by live test: the response body (a bare `{}` fails identically), a missing
-field, unknown-key desync, a network failure (zero external connections during a
-failure — that error string is FIFA's *generic* session error), missing service URLs,
-the online layer, the reveal screen's exit path, and the club not being loaded.
+**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:
 
-**The asymmetry:** quick sell and move receive an *identical* bare `{}` from the same
-server. Quick sell succeeds. Move ends the session. The deciding factor is client-side
-state, not the wire.
+```json
+{"itemData":[{"id":100000125,"pile":"club","success":true}, ...]}
+```
 
-**Workaround:** pack contents are deposited straight into the club at open time, so the
-client is never offered a move. Packs are fully usable; the reveal screen just doesn't
-offer assignment.
+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