ea92057e531608883b9b1c3151f09a675cbe357b
13 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 funman300
|
cb32fe9b84 |
docs(market): close Gap 2 and freeze the transfer-list lifecycle as known-good
Return to Club is durable across a full FUT exit/re-entry — the last claim the forSale promotion could only make server-side. Same disposable card as Gap 1 (75 ST, res 212188, wire 100000178, tradeId 1000000178), after the 1h auction expired NATURALLY. No timestamp was mutated in either gap; a read-only sampler watched the whole hour (55 samples), because `expires` is derived from created_at + duration and watching is the only honest way to see expiry: active expires 3175 -> counting down -> expired expires 0, itemState forSale (absent) total 0 <- Return to Club itemState stayed forSale across active -> expired, the one state change Fix B had never been watched through live. The host log then shows the coupled transition and TWO session boundaries: route=move-items wire=100000178 pile=club auction_cancelled=1 route=auth-delete route=auth ... sid_opened=true (fresh session, x2) route=hub clubPlayers=1966 auctionCount=0 route=club total=1986 emitted=1966 auction_cancelled=1 is cancel_active_for_core_item firing, so pile membership and auction lifecycle cannot disagree. Two independent fresh sessions each rebuilt the state from durable storage and the operator confirmed the card was still in My Club; one boundary was the requirement. 18/18 server checks pass IDENTICALLY before and after re-entry: /tradePile total 0, counts all zero, tradeId -> closed with expires 0 (still resolves, correctly terminal), /club 1966 with itemState free, 0 duplicate ids, market store cancelled with 0 active and 0 reserved, coins 29,843,976 unchanged throughout. No code change was required for EITHER gap. Both tests existed to find out whether the promoted implementation was already correct on paths it had not been exercised on, and it was. Also freezes the full CLUB -> list -> active -> expired -> Return to Club -> CLUB lifecycle as the reference baseline, with the eight invariants it pins, so a future change that alters any line is a regression until proven otherwise. Explicitly NOT established: the SOLD path, /tradePile/counts semantics, the AVM1 gate. |
||
|
funman300
|
0a007f4941 |
docs(market): close Gap 1 — active seller row under forSale is live-confirmed
The one claim the Fix B promotion left open: no active listing existed during
that session, so only the expired path had been exercised.
Closed with a disposable card (75 ST, res 212188, wire id 100000178 — one of
three identical copies, not in the squad) listed through the real FIFA 17 client
at 150/200 for 1h, so expiry arrives naturally. No timestamp touched.
Wire: itemState=forSale, tradeState=active, 12 atoms, prices intact, expires
3562 -> 3556 over a 6s sample (live clock), /trade/status coherent, counts
{count:1, selling:1}, coins unchanged, zero inactive rows (Fix A intact).
The decisive evidence is client-side, not ours: a read-only /proc/<pid>/mem
decode of the live trade-pile auction record returned
itemState=5(forSale)
on the very field that read -1(<unrecognised>) under listFS. Direct A/B on the
only changed field, taken from the client's own memory.
Operator confirmed the row renders under LISTED ITEMS with correct prices, a
counting-down timer, normal art, and correctly non-actionable while active.
No code change required — the promoted implementation was already correct on the
active path. Claim boundary unchanged: this proves the client DECODES the token
and says nothing about the Flash action-gate term.
|
||
|
funman300
|
0c4aee6164 |
market: promote forSale — live-confirmed on the expired path
Operator drove the expired row 1000000155 (res 158023, 93 RW) in FIFA 17 with the candidate deployed: the row was still actionable, Return to Club was offered, and it worked — "the card is back in my club". Server-verified durable afterwards, which is what a fresh session reconstructs: /tradePile total 0 with zero rows, /tradePile/counts all zero, the card present in /club (1965 -> 1966 items, itemState "free"), zero duplicate ids, no stale active listing anywhere in the store (both rows cancelled), and the ended auction projecting as `closed` (4) on /trade/status. Fix A intact: zero `inactive` rows. So `listFS` -> `forSale` is protocol-correct AND behaviour-preserving on the path that matters, and `listFS` is gone from production serialization. Also worth recording what the result rules out: CARD_OFFERSTATE is NOT a gate term that requires -1. Every actionable row we had ever seen carried itemState -1, which looked like a possible client rule; it was a coincidence of our own invalid token. An expired row decoding CARD_OFFERSTATE = 5 stayed actionable. Deliberately NOT claimed: anything about the Flash action gate itself. STATE and the RESERVEDPRICE/MAX_CREDITS pair are untouched and still confounded, so the gate remains Category C / STRONGLY SUPPORTED / not proven, and AVM1 disassembly of tradepile.isInActiveAuction is still the separate next investigation. One gap left open honestly: no ACTIVE seller row existed during the session, so active-row rendering under `forSale` is unverified. /transfermarket has always emitted `forSale` on active rows, so it is expected-safe, but it has not been seen. |
||
|
funman300
|
a57f4930f0 |
market: emit FIFA 17's own forSale itemState, not the oracle's listFS
Single-field protocol-correctness fix, deployed as a candidate for a live A/B. `itemData.itemState: "listFS"` on the seller's own auction rows is not a FIFA 17 token at all: zero occurrences in `CardsDLL_Win64_retail.dll` (md5 4de3493131d7d2ff7f8b360c5ac9b655), zero in 4.26 GiB of live client memory, and it decodes to -1 through `FUN_180166660` — so the client was handed an unrecognised `CARD_OFFERSTATE`. FIFA 17's value for an item offered for sale is `forSale` (5), from the 12-row table at 0x180229cc0. Changed only where the invalid token was emitted: `handle_market_query` (GET …/tradePile) and `handle_market_status` (GET …/trade/status). The market search path already emitted `forSale` and is untouched — which is also why the risk here was lower than it looked: the client has been decoding `forSale` on a live route all along, and only the seller's own pile carried the bad value. Wire A/B on the same expired row: EXACTLY one field differs. tradeId, tradeState, expires, startingBid, buyNowPrice, currentBid, bidState, sellerName, sellerEstablished, watched, coinsProcessed, the twelve-atom count and the whole itemData card are byte-identical; coins unchanged at 29,843,976; Fix A's zero `inactive` rows intact. The differential asserted PARITY on this field and therefore passed while BOTH sides were wrong — the exact mechanism by which the defect survived every run. `market query tradePile` is now DIFFERENT-BY-DESIGN, pinning oracle == "listFS" and rust == "forSale" so the divergence cannot silently close again. Where the FIFA 17 binary contradicts the Python oracle, the binary wins. Gates: 126 host tests, 214 adapter tests, fmt clean, clippy clean. NOT claimed: that this preserves the list -> expire -> Return-to-Club lifecycle. That needs an operator FIFA 17 session and has NOT been observed yet. Also not claimed: anything about the Flash action gate — `CARD_OFFERSTATE` is one of three still-confounded candidates and this change does not test it. Revert is one line if the live test fails. |
||
|
funman300
|
f9ca901a50 |
market: stop advertising unlisted pile members as tradeState:"inactive"
RE of the FUT front-end closed the question the Actions-panel investigation left open, and the answer retracts Q2 rather than completing it. `tradeState` reaches exactly ONE native branch in CardsDLL — `cmp …,0x4` at `0x18013e619`, "is it closed?" — and `inactive`(2) and `expired`(3) take the same edge, producing bit-identical `flagA`/`flagB` (exhaustive 22-site census of `[reg+0x88]` reads across the PE; confirmed live, both classes read glow=0 inbox=0). The value is then handed to the movie verbatim as the Flash property `STATE`, and the action gate lives in the APT/ActionScript FUT front-end: the trade-pile class partitions rows with `getCardsInAuction`/`isInActiveAuction` (traces `initPile() - IN AUCTION:` / `- NOT IN AUCTION:`) and only auction rows reach `PreCheckCardOptions` -> `handleTradeCardAction`. A non-auction row renders and can never be acted on, which is exactly what the operator saw. So the rows were never usable. "LIVE-CONFIRMED" established that they RENDER, which is not the same claim, and I treated it as if it were. The corpus said this before any of it was built — `plan-2026-08-06-transfer-market.md:731-733`: "`inactive` decodes but no client path treats it specially; do not emit it." The earlier note explaining that the warning "was written about the PRESENTATION function" was motivated reasoning. This also fires the corpus's own pre-registered falsifier E3 (:368-373). Removed: the `inactive` projection from `GET …/tradePile` and `…/trade/status`, `UnlistedCandidate`, `resolve_unlisted_pile`, `unlisted_record`, `Server::resolve_trade_pile`, and the two helpers that existed only to feed them (`MarketStore::blocking_core_items`, `Fifa17IdentityResolver::wire_for_owned_id`). Unlisted trade-pile membership is now internal state with no wire expression. Nothing is stranded: `/club` excludes only items with an ACTIVE listing, so an unlisted pile member stays visible in the club, which is where the client can act on it. Verified live after deploy — `/tradePile` total 7 -> 1 with zero `inactive` rows, `/trade/status` resolving only the real auction, coins unchanged at 29,843,976, and all six former rows present in `/club` (1965 items). Tests: 126 pass, fmt + clippy clean. Two guards replace the three tests that pinned the old behaviour: `the_trade_pile_advertises_only_real_auctions` and `trade_status_answers_only_about_real_auctions`. NOT fixed here, deliberately: `itemData.itemState: "listFS"` is not a FIFA 17 token (0 occurrences in CardsDLL md5 4de3493131d7d2ff7f8b360c5ac9b655, 0 in 4.26 GiB of process memory, decodes to -1; the real value is `forSale` = 5, and the Python oracle emits `listFS` too — which is why the differential never caught it). `CARD_OFFERSTATE` is one of three unresolved action-gate candidates and every actionable row observed carried -1, so that change ships alone with its own live A/B. |
||
|
funman300
|
11c028e6eb |
fix(market): /trade/status must resolve the unlisted ids /tradePile advertises
Explains and fixes the Phase C partial failure WITHOUT changing a single wire field. The operator saw a difference between the one-item probe (Time Remaining "-") and the generalized rows (Time Remaining "Expired"). Cause: route coverage, not encoding. /tradePile advertised the unlisted tradeIds while ISVIEWTRADE (GET .../trade/status) resolved ids from the market store only -- and an unlisted pile member has no listing row, so the poll returned an empty auctionInfo. Observed live as `route=market-status requested=1 returned=0` repeating for the row the operator had selected, while that same id was present in /tradePile. The client polls status for the row it displays and degrades it when the answer is empty, which is also why no actions were offered. The probe showed "-" only because the client had not yet polled that id (logs of the time show only tradeIds=1000000097). So expires, tradeState, itemData.itemState and pile were all innocent. Nothing was guessed and no field changed: both routes now share one pile enumeration (Server::resolve_trade_pile), so an id advertised by /tradePile always resolves on /trade/status. The corpus predicted exactly this -- tradeId must resolve across /transfermarket, /tradePile, /watchList AND /trade/status; we had stability but not coverage. Same defect class as the original empty-trade/status bug. Status still answers only the ids actually asked about, and a real auction always wins over an inactive row for the same tradeId. Regression test covers all four cases. Records the downgraded conclusion: "inactive" is a CONFIRMED section/lifecycle discriminator; whether the full actionable contract is now complete is the operator's next test. itemState/pile recovery was queued on the assumption the encoding was incomplete -- neither was touched, and both remain the next candidates if actions are still absent. 342 tests pass, 0 failed, clippy clean. Verified live: the six inactive ids went from returned=0 to returned=6. |
||
|
funman300
|
b6398c44e6 |
docs: record the LIVE-CONFIRMED inactive UI contract and the expired->Club transition
Operator confirmed in the real client that a tradeState "inactive" row lands under the right-hand TRANSFER LIST section and renders Start Price 0 with Buy Now, Current Bid and Time Remaining all absent, while an active row in the same body continued to render separately under LISTED ITEMS. That is the Q2 representation confirmed live, with the token itself dumped from the client's own string table rather than guessed. Records the observed wire->UI contract as a table plus a fixture (inactive-row-live-confirmed.json), and names the regression tests that pin it, including the two guards that the row is never emitted for an item outside the trade pile and never duplicates a real auction. Also records the expired->Club coupled transition verified server-side: the listing went to `cancelled`, the pile went to `club`, /tradePile dropped the item, /club regained it, and clubPlayers went 1964 -> 1965. That is durable store state rather than a client-local view, so it survives a session boundary by construction; tagged pending the operator's final exit/re-enter confirmation. Adds the counts observation table. `count` currently tracks AUCTION entries and not total Transfer List membership; semantics deliberately left unchanged until the full state set has been observed. No behaviour change in this commit. |
||
|
funman300
|
2e97ff1461 |
docs+tools: dump the CardsDLL route table; narrow Q2 to one candidate by elimination
Re-entry discriminator came back a CONFIRMED BUG: an unlisted transfer-list item does not survive a fresh FUT session, so our representation cannot reconstruct trade-pile membership. Evidence acquisition per instruction, corpus and PE first, no guessing. Adds route_table_dump.py: static read-only dump of CardsDLL's route table from the on-disk PE, resolving VA->file offset through the real section table instead of assuming a single .text mapping. Output preserved as evidence. It settles "is /tradePile the only relevant route?" -- the table holds 45 routes plus 3 empty admin slots, and row 30 `ut/%s/tradePile` is the ONLY trade-pile route. There is no trade-pile items route. That plus three existing PE facts narrows the representation to exactly one candidate by ELIMINATION rather than choice: the route carries only twelve-atom auction records; `pile` (0x226) has no arm in the item deserializer so membership is conferred by the owning list and cannot be added as a field; of the twelve atoms only tradeState expresses lifecycle; and tradeState's closed vocabulary (active=1 inactive=2 expired=3 closed=4) has exactly one value not already spoken for. So an unlisted item can only be an auctionInfo record with tradeState "inactive". Tagged INFERRED-BY-ELIMINATION, not CONFIRMED: the remaining unknown is whether the Flash Transfer List RENDERS such a record in the unlisted section. Records the acceptance test (survive a full FUT reload) and the revised invariant that a transition is complete only when a fresh session reconstructs the same visible state. No behaviour change in this commit. |
||
|
funman300
|
7f37b37be3 |
docs: capture the unlisted transfer-list state and model the pile/auction boundary
Q2 measured, not guessed. The operator moved a card Club -> Transfer List without listing it (PUT /item, no POST /auctionhouse) and the state was captured read-only. Finding: we do not represent the unlisted state on the wire AT ALL. Such an item is byte-identical to a club item -- itemState `free`, no `pile` field emitted, still returned in /club and counted in clubPlayers -- while an actively-listed item is correctly excluded from /club and present in tradePile. Only the host's own pile store knows the difference. Trade pile held 6 items: 1 listed, 5 unlisted. The FIFA 17 ENCODING of that state stays UNKNOWN on purpose: returned itemData.pile is numeric with an unrecovered mapping, and tradeState is a closed table walk where an unrecognised bidState is silently swallowed as `none`, so a wrong enum produces a plausible-looking but wrong UI. The corpus warns `inactive` decodes but no client path treats it specially. One client-only discriminator is recorded instead. Also models the domain boundary both limbo bugs came from: pile membership and auction lifecycle are separate facts requiring coordinated transitions. States the testable invariant -- an item must never be simultaneously excluded from /club and absent from /tradePile -- with the two ways it was reachable and the commits that closed each. |
||
|
funman300
|
4e31fb98a2 |
fix(market): returning an item to the club ends its auction; close the panel probe
CLOSES the active-own-auction Actions-panel investigation. Live client plus the RE corpus plus historical FUT behaviour all agree: an active auction is COMMITTED until sale or expiry and is not seller-actionable, while an expired unsold item becomes actionable (relist / return to club). Every observation fits that lifecycle -- active+frozen expires was non-selectable, expired was selectable and relisted fine, relisting made it active and non-selectable again, and the client never emits a cancel. Documented with confidence tags, and the dead ends are named so they are not retried: MAY_BE_REMOVED is a constant 1, and the eight-flag array is the CLUB-CARD menu with no auction-cancellation flag in it. Implements the return-to-club transition that closure exposes. A pile move to `club` now cancels any ACTIVE listing on that item, because the auction that put the card in the pile has to end with it. Otherwise the pile reads `club` while the row stays `active`, so the card is filtered out of /club (exclusion keys on active listings) AND still rendered in the Transfer List: the move appears to do nothing. This is the same limbo class as the earlier pile-vs-listing bug, found by reasoning about the transition rather than by another live failure. Scoped to `active` only: a `reserved` row is mid-sale and a `sold` row is already gone, so cancelling either would let one card be both sold and returned. Two tests cover exactly that boundary. 338 tests pass, 0 failed, clippy clean. |
||
|
funman300
|
6cc22e5cc5 |
docs: freeze the known-good auction state and mark tradeOwner DISPROVEN
Records the live-client resolution so the market shape is now a fixture rather than folklore, and so a future agent cannot burn deployments on tradeOwner again. Confidence notes updated: tradeOwner remains FIFA17-HISTORICAL (it does exist in the FIFA 17-era API) but "required by FIFA17.exe Transfer List Actions" is now DISPROVEN for this client path -- it is not among the twelve atoms the client's auctionInfo deserializer reads, and it was implemented, deployed, observed inert and removed. The real blockers are recorded as CONFIRMED live-client findings: trade/status polling is load-bearing, `expires` must EVOLVE with wall-clock time (a frozen value is structurally valid and behaviourally broken), and relist must persist through the PK conflict that FIFA's re-sent ISStart necessarily causes. Freezes the known-good bodies under docs/evidence/market-lifecycle-2026-08-17/ with a machine-checkable countdown proof (_index.json._countdown_proof records expires decrementing, frozen:false) rather than asserting the clock in prose. States the general rule this cost us: a response can pass differential parity and render perfectly while still being wrong, because FIFA expects an evolving server-side state machine, not a static object that resembles one. |
||
|
funman300
|
dcbef721f2 |
docs+tools: measure the FIFA 17 market gate bytes in the live client
Adds trade_gate_probe.py (read-only: /proc/<pid>/mem O_RDONLY + pread, slide proven
against the on-disk FNV prologue), extending gate_byte_probe.py to vtable slot
+0x270 exactly as the transfer-market analysis asked for.
Measured: IS_TRADING_ENABLED=1 (was 0 in the Python era), TRADE_PILE_SIZE=100
(was 0), watchListSize=50 (was 0), with four controls reading 1. So every
CardsDLL-supplied input that analysis named as a market blocker is now OPEN, which
the Rust host achieves by construction -- it emits userInfo.feature as {} so the
kill switch at 0x180174f19 never arms, and it already sends pileSizeClientData
keys 2 and 4.
This narrows the Actions-panel question to the exe-side UI script term, and rules
out ownership fields, the gate bytes, the cancel route and the state vocabularies
as candidates -- each on measured or PE-derived evidence rather than inference.
|
||
|
funman300
|
bf9ae20367 |
docs: FIFA 17 transfer-market wire findings with confidence tags
Records the auction-record field set, route spellings, pile encoding and the four open UNKNOWNs so future agents neither reopen settled questions nor re-guess enum values. Each claim tagged CONFIRMED / FIFA17-HISTORICAL / INFERRED / UNKNOWN. Captures the key methodological lesson: oracle parity is necessary but NOT sufficient for a flow the oracle itself never served -- our auction record matched the oracle key-for-key while both omitted the FIFA 17 ownership fields. |