sots-engine/docs/L3-predictions.md

Lane L3 — predictions, written before the build (method rule 2)

Lane L3 owns VM144 (sots-re-win10-144, re@192.168.10.144, a ZFS clone of VM140). Target: manufacture a workload in which the trade-route vector and/or the spy-program vector is non-empty, then measure whether the four RNG-bearing tail callees draw.

Instrument: watch.mode=cont, a third mode on lane W3's watchpoint module. Same single arming detour (StrategyServer::ApplyAllTurnCommands, RVA 0x0038f6a0), same VEH, same canary, same hit format. Two differences from tshn:

1. it arms all four debug slots on the two containers — _Myfirst and _Mylast of each — so an allocation (_Myfirst moves from 0) and a push_back (_Mylast moves) are separable;
2. it re-arms and re-logs every End Turn instead of only the first. Lane W3 printed one count from one turn of one save; this workload is a game played across many turns, and the question "did the container grow on turn N" needs a line per turn.

---

What the static reading says the workload is (before any run)

Read out of sots.exe, TechTree/MasterTechList.tech, Data/Strategy/StrategyVars.txt, Species/*/sections/*.shipsection and the repo's own catalogs. This is the part three previous lanes did not have, and it changes the cost estimate by an order of magnitude.

Trade routes

• The gate is the tech CCC_FTLEcon (id 10026) — it sets ServerPlayer+0xff (CnTrd) unless the player is RebAI (ghidra/addresses.json:1510, tech-effects.md:64).
• Cost: CCC_ROOT → CCC_FTLBrdB (RP 4,000) → CCC_FTLEcon (RP 18,000). Zuul cannot research it (Zuul:0 in the availability line) — so the workload must not be Zuul.
• StrategyServer_RegisterTradeSystems 0x007adc80 registers, for every owned system whose owner has CnTrd, ServerSystem::NumTradeRoutesSupported 0x00819d20 route slots, and that function is ceil(civ/REQ_CIV) + ceil(imp/REQ_IMP) with a floor of 1.
• Therefore the population thresholds in StrategyVars.txt (TRADE_ROUTE_REQ_CIVPOPULATION 200000000, TRADE_ROUTE_REQ_IMPPOPULATION 500000000) are not a hard gate — they scale the count, and the minimum is 1 per owned system.
• TRADE_SECTOR_SIZE 10.0 — routes live inside a trade sector, so the endpoints have to be near each other.
• A trade station (DNStationTrade, station type 4) adds STATION_TRADE_NUMROUTES 2 and STATION_BONUS_TRADE_INCOME 0.25. It is a bonus, not a prerequisite.

Prediction T1. The premise carried in tail-probes.md §3.2 and repeated in the L3 brief — "trade income needs trade-station construction plus its tech" — is wrong about the station. CCC_FTLEcon plus two owned systems inside one trade sector is sufficient to make the trade-route vector non-empty. No trade station is needed.

Falsifier: a game with CCC_FTLEcon researched, ≥2 owned systems within 10 units, and trade routes … count=0 still logged after several End Turns.

Prediction T2. The vector fills during turn processing, not at the moment the tech completes, so the first non-zero count appears on the End Turn after the one that finished CCC_FTLEcon.

Spy programs

Nobody had a click path. The static reading gives one.

• Species/<race>/sections/_Spy.shipsection — entity_class "SpyShip", section_type mission, nodesign 1, spy 1, cost 20000, and requires CCC_SpyBm + requires IND_SlvgTech.
• The spy tender — the "ship a spy can dock with" in Can't build spy: Fleet does not have a ship spy can dock with. — is the section carrying spytender. In this image that is exactly one section per race: CRRepairandSalvage (Cruiser Repair & Salvage mission section, requires IND_SlvgTech, cost 60,000). Nothing in the UI says "tender".
• Tech cost: IND_OrbFound → IND_CruisCon (16,000) → IND_SlvgTech (12,000) for the tender and half the spy; CCC_ROOT → CCC_FTLBrdB (4,000) → CCC_SpyBm (12,000) for the other half. CCC_FTLBrdB is shared with the trade chain.
• The action path is the Special menu on the fleet panel ((229,464) at 1024×768): SHIPACTION_BUILDSPY / DEPLOYSPY / PICKUPSPY, backed by Game::BuildSpyDialog, Game::DeploySpyDialog, Game::PickupSpyDialog and the Game::CanBuildSpy functor.
• The engine's own refusal strings enumerate the preconditions exactly: build — own system, player has ability, fleet has a tender, tender not already carrying; deploy — not your own system, no enemy fleet present, and Can't deploy spy: Spy requires an asteroid belt to hide. (SPYSHIP_NEARBY_ASTEROID_RANGE 500.0; STARMAP_ASTEROIDBELT_ODDS 25 %).

Prediction S1. ServerSpyManager's vector is the spy-craft list, and it grows at Build Spy, not at Deploy — the Game::SpyCraft record has atto (attached-to) and tdep (turn deployed) fields, which only make sense if the object exists while still docked. If S1 holds, the spy half of this workload needs no second empire at all.

Falsifier: Build Spy succeeds (the fleet shows a docked spy) and the next End Turn still logs spy programs … count=0. That would move the growth point to Deploy and make an enemy colony with an asteroid belt mandatory.

Prediction S2. The trapped write to the spy vector's _Mylast will have an eip inside ServerSpyManager and an ebpret inside the turn-command applier, not inside a UI class — because the debug registers are armed on the turn thread only (ArmCurrentThread(GetCurrentThread())), and SOTS is lockstep: the UI issues a command and the server applies it. If the write instead happens on the UI thread, no trap will be taken at all and the count line is the only evidence. This is the rule-20 trap in this instrument: a zero trap count with a rising count line means wrong thread, not no write.

Getting there without twenty turns of play

The Custom game-setup screen (GAMESETUPFE_BTN_CUSTOM) exposes GAMESETUP_INITCOLONIES, GAMESETUP_INITSAVINGS, GAMESETUP_INITTECHS, GAMESETUP_MONEY_RESEARCHMOD, GAMESETUP_MONEY_INCOMEMOD, GAMESETUP_SYSTEM_DISTANCE, GAMESETUP_SYSTEM_SIZE, GAMESETUP_SYSTEM_SUITABILITY. All of it is stock: no data file is modified, no save is edited, so the resulting save is a legitimate corpus member.

Prediction W1. With initial colonies, initial savings, initial techs and the research modifier at maximum on a small close-packed map, both tech chains are reachable inside ~10 End Turns rather than the "tens of 30–60 s End Turns" the brief budgets.

---

Instrument predictions

Prediction I1 (control, rule 19). watch=on watch.mode=cont is byte-neutral: one End Turn from ref-turn2.sav reproduces the determinism oracle — (Autosave EndTurn).sav bb4fd9ac89f41e3b…, (Autosave).sav 978041acd168b56e… — exactly as watch=off does. The two configs differ in one key.

Prediction I2. On ref-turn2.sav the new mode reproduces lane W3's numbers: both managers non-null, all six pointers zero, both counts 0, zero traps. If it does not, the mode is wrong and nothing measured with it later counts.

Prediction I3. The canary self-test passes on every turn, not just the first — the delta form of the counter is new in this mode and is itself a thing that can be wrong.

---

What would make this lane's result worthless

• Counting a container from the wrong base. S is the ApplyAllTurnCommands this; every StrategyServer_off_* is in the S+4 frame (lane-t.json:172). A wrong base yields a plausible-looking zero.
• Reporting "0 traps" when the writer ran on another thread (S2).
• Producing a save whose non-empty container came from a modified data file. Nothing in this lane modifies sots.gob or any loose data file; if that ever changes it must be recorded in the save's provenance line.