Files
OpenFUT/openfut-adapter-fifa17
funman300 f6606accb3 feat(market): FIFA 5% transfer fee policy, host settle_sale capability, isolated staging harness
Core gains the generic settlement (gitlink 31ab4a6); the FIFA-specific parts live
here.

FEE (openfut-adapter-fifa17/src/fut/economy_policy.rs), beside pack_price and
match_reward_total because 5% is a game policy constant and Core must stay
game-neutral — Core only validates 0 <= fee <= gross and never computes a rate:

  TRANSFER_MARKET_FEE_PERCENT = 5
  transfer_market_fee(gross)  = floor(gross * 5 / 100), i128 intermediate
  seller_proceeds(gross)      = gross - fee

Integer only. Floating point is never used for coin settlement: 0.05 is not
representable in binary and a f64 round trip can create or destroy a coin at large
prices. Widening to i128 makes overflow unreachable for any i64 price, so no price
ceiling has to be assumed.

ROUNDING IS A CHOICE AND IT IS NOT CONFIRMED. The fee is floored, so the seller
keeps the fractional coin, chosen because it makes fee + proceeds == gross hold
exactly at every input — the property the accounting invariant rests on. The
discriminating case against flooring the seller's 95% instead is a gross of 150:
this rule pays 143, the alternative 142. Nothing in the corpus or the client binary
settles which the real server did (the client is only ever told the gross; no
tax/netPrice/sellerProceeds wire field exists). Pinned at 0/1/19/20/21/39/40/100/
150/200/1_000/15_000/15_000_000/i64::MAX plus a fee+proceeds==gross sweep.

HOST: CoreEconomy gains settle_sale + EconomySale/EconomySaleReceipt, implemented on
HttpCoreClient as POST /economy/settle-sale. Request field names were checked
against Core's actual SettleSaleRequest/SaleReceipt rather than assumed. Absent club
ids are OMITTED from the body (not null), which is what Core's Outside/active-club
defaults depend on, so a unit test pins that body shape. handle_market_buy is
deliberately untouched: the synthetic buy path has no counterparty, so minting there
is correct.

HARNESS: scripts/settlement-staging.py, stdlib only, drives a REAL Core over real
HTTP on an ephemeral port against a throwaway DB (production 8099/8199/18080 in a
hard deny-list checked in three places), seeds the canonical two-party fixture,
prints BEFORE/PURCHASE/AFTER with PASS-FAIL lines, cleans up in a finally. 31/31
pass. It found the rejection-precedence bug fixed in Core, and that Core's content
preflight aborts startup on an owned card whose CardDefinitionId no pack defines.

Gates: Core 194, adapter 217, host 127, harness 31/31, clippy clean, new code
fmt-clean. Nothing deployed; no production process, port or database was touched.
2026-08-18 00:51:37 +00:00
..

openfut-adapter-fifa17

The FIFA 17 game adapter. Everything true of FIFA 17 specifically lives here, so that neither OpenFUT Core nor the generic protocol crates have to know about it.

  openfut-protocol-blaze   generic Blaze: Fire2 framing, Heat2/TDF codec
           ▲
  openfut-adapter-fifa17   THIS: command tables, response bodies, dispatch order
           ▲
  OpenFUT Core             game-independent FUT domain (not yet wired)

Status

Surface Port State
Blaze / Fire2 RPC 42130 Implemented, byte-for-byte parity-tested
Redirector (HTTPS + XML) 42127 Python only
Nucleus OAuth stub 42131 Python only
LSX / Origin 4216 Python only
Roster XML 8081 Python only
UTAS / RS4 8099 Python only
POW / EASFC 8094 / 8080 Python only

Nothing here is wired into the running backend. The crate answers frames; it opens no socket, terminates no TLS and owns no runtime. The Python backend remains the live service and the behavioural oracle.

What the adapter owns, and what it must not

Owns: component/command/notification IDs, response body shapes, dispatch ordering, session identity, the fetchClientConfig tables.

Must not own: FUT domain state. Blaze is an auth/session/config protocol — no coins, packs, clubs or squads appear on this wire — so Session holds a session key, a locale, a service name, an auth code and a flag, and that is all. When UTAS is migrated that boundary will need active defending; here it comes free.

Parity

./check-parity.sh          # oracle freshness + byte-for-byte replay
./check-parity.sh --regen  # after an intentional oracle change

fixtures/blaze_transactions.jsonl holds 49 request→response(s) transactions produced by calling the real blaze_responder_v3b.dispatch(). They replay in order against a shared session per connection, so ordering-dependent behaviour is exercised rather than assumed: preAuth captures the locale that later ALOC fields echo, and login sets the auth code getAuthToken returns afterwards.

Comparison is byte-for-byte including frame count and order — a missing post-login notification or a reply where the oracle stays silent fails here.

The suite was mutation-tested: swapping two post-login notifications, flipping one enum deep inside AccountInfo, and hardcoding an address in utas_base()/nucleus_base() were each verified to turn it red. The third initially did not, because the config templating had made those helpers dead code; the table now templates on URL-level tokens so they are the single place a URL shape is defined.

Three behaviours that are easy to get wrong

  • Login answers with four frames, in order: reply, then UserAuthenticated, UserSessionExtendedDataUpdate, UserAdded.
  • An unimplemented RPC still gets an empty reply. Silence makes the client wait for a timeout; an empty reply lets every field fall back to a client-side default and the boot continues.
  • Non-request message types get nothing at all.

No error replies are emitted. msgType 3 exists, but the error-code placement is UNRESOLVED — three clean-room sources disagree between header[14:16], a metadata ERRC, and a payload CNTX/ERRC — so emitting one would be a guess on the wire.

The client config table

fixtures/client_config.json carries 227243 rows per CFID, generated from the Python oracle and templated on {utas_base}, {nucleus_base}, {pow_content_url}, {advertise}, {bind}, {pow_host}. It is reverse-engineered data, not logic, and deriving it mechanically removes a class of transcription typo no reviewer could catch. The generator does not take its own templating on trust: it substitutes real addresses back in and diffs against the oracle for every section before writing the file.

The table must be complete, not representative. The client resolves a per-call key (FUT_RS4_URL_<CALL>) before a per-module one, and any unresolved call falls back to a real, dead EA host — that is what produced "there has been an error connecting to FIFA 17 Ultimate Team" mid-session when only the boot subset was served.

Known defect reproduced deliberately

nucleusConnect and nucleusConnectTrusted are built from the bind address, not the advertised one. On the live split deployment that means the backend tells a client on another machine to reach Nucleus at http://0.0.0.0:42131, which it cannot. Verified against the running container, not inferred.

This is reproduced exactly, because it is what the only proven-working configuration does and changing it would break parity. It also implies the Nucleus stub is not actually reached in the current remote flow. Fixing it is a separate change that needs live validation — see the vault.

Configuration

Nothing is hardcoded. AdapterConfig carries Identity (persona, ids, email, namespace, entitlement group, …) and Endpoints (advertise, bind, POW hosts, telemetry/ticker/QoS ports). Default gives the project's synthetic offline identity on loopback; a remote deployment must override advertise.

Bind and advertise are deliberately distinct: an advertised URL must carry the address the client can reach, which on a two-machine deployment is not the address the server binds.