Investigate Fuel save load hang after command bridge ready

[Ustice]

Investigate Fuel save load hang after command bridge ready

Context

This issue was created from the 2026-06-01 coordinator live-QA run after #64 closed and #44/#65/#66 became blocked by the same load/command environment failure.

#64 proved the updated launch/deploy path can still reach a loaded, command-responsive game and pass qa-fixture-readiness stored-goods at commit cdbd3cfd. Immediately afterward, the #44 retry with accepted commit b2728418 deployed cleanly but could not reach a fair live proof because Timberborn stayed on the Loading screen after Continue.

Observed Failure

Artifact root:

• /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun

Important evidence:

• Deploy passed: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/commands/01-deploy-44.txt
• Duplicate launch TTL was respected on first retry: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/commands/02-guarded-launch-from-main.txt
• Second launch reached Startup Mods, Experimental Mode, and Continue, then timed out waiting for loaded-save: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/commands/03-guarded-launch-after-cooldown.txt
• Screenshot stayed on Loading: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/current-screen-after-bridge-ready-timeout.png
• Command probes timed out waiting for a fresh outbox:
  • /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/commands/04-status-after-launch-timeout.txt
  • /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/commands/05-status-after-extra-load-wait.txt
  • /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/commands/06-status-after-bridge-ready-log.txt
• command-inbox.txt updated, but command-outbox.txt remained stale from the prior Make persistence stored-goods fixture-readiness prove item loss #64 run.
• Fresh copied log: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/Player.log
• Focused scan: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/Player-focused-scan.txt
• Player.log reached wildfire_command_bridge_ready, but the UI stayed on Loading and the bridge did not consume follow-up commands.
• Normal quit hung; the controller terminated the stuck Timberborn process.

Impact

This blocks fair live QA for:

• Gate Slow Reactable Wildfire Tuning #44 slow-reactable proof at b2728418
• Make persistence crop fixture-readiness prove crop loss #65 crop fixture-readiness live retry at 69d9f90b85e194618ebb101f01e7fe825bdbeaaf
• Make persistence tainted-washout fixture-readiness prove washout #66 tainted-washout fixture-readiness live retry at 2efaf7089774deff479688f62e7d0ea42bcb4363

Acceptance Criteria

• Explain why the UI can remain on Loading while Player.log reaches wildfire_command_bridge_ready.
• Determine whether this is a save/load hang, stale command-file state, command bridge lifecycle issue, mod interaction, or helper detection bug.
• Provide a repeatable recovery path or fix so a Live QA Controller can get a fair loaded-save command response without manual relaunch churn.
• Preserve diagnostics in /tmp/wildfire-qa or issue comments.
• Do not hide product proof failures behind this issue; once the load/command path is fair, route Gate Slow Reactable Wildfire Tuning #44/Make persistence crop fixture-readiness prove crop loss #65/Make persistence tainted-washout fixture-readiness prove washout #66 back to their narrow QA gates.

Suggested First Checks

• Compare Make persistence stored-goods fixture-readiness prove item loss #64 pass artifact root /tmp/wildfire-qa/live-controller-20260601/twf-64-cdbd3cfd-overlap-rerun with the Gate Slow Reactable Wildfire Tuning #44 blocked artifact root.
• Inspect command-inbox.txt / command-outbox.txt lifecycle and whether outbox cleanup is needed between deploys.
• Inspect the latest autosave selected by the helper: Fuel/2026-05-31 23h41m, Day 7-5.autosave.timber.
• Check for load-completion tokens after wildfire_command_bridge_ready and whether the helper should treat that log token differently from UI loaded-save detection.

[Ustice]

Coordinator assignment packet prepared, but background thread dispatch is currently blocked because the Codex thread connector returns No handler registered for create_thread in this coordinator thread.

Worker allocation is ready:

• Worktree: ~/repos/wildfire-worktrees/worker-81-load-command-hang
• Branch: codex/worker/81-load-command-hang
• Base/head: main at 7ebd114c (Use app-name launch for Timberborn startup)
• Context file: ~/repos/wildfire-worktrees/worker-81-load-command-hang/CONTEXT.md
• Cleanup owner: coordinator

Assignment summary:

• Use the Worker role flow (kanban/roles/worker.md).
• Start read-only by comparing the Make persistence stored-goods fixture-readiness prove item loss #64 passing artifacts and Gate Slow Reactable Wildfire Tuning #44 blocked artifacts.
• Do not launch Timberborn unless there is a concrete diagnostic reason and a single guarded launch can be guaranteed.
• Do not use ps | rg; use exact process matching.
• Keep Gate Slow Reactable Wildfire Tuning #44/Make persistence crop fixture-readiness prove crop loss #65/Make persistence tainted-washout fixture-readiness prove washout #66 product proof logic out of scope. The goal is to restore or explain the fair load/command path.

Key evidence:

• Make persistence stored-goods fixture-readiness prove item loss #64 passing comparison: /tmp/wildfire-qa/live-controller-20260601/twf-64-cdbd3cfd-overlap-rerun
• Gate Slow Reactable Wildfire Tuning #44 blocked run: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun
• Fresh Gate Slow Reactable Wildfire Tuning #44 log copy: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/Player.log
• Gate Slow Reactable Wildfire Tuning #44 focused scan: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun/Player-focused-scan.txt

Expected worker output:

• Update Investigate Fuel save load hang after command bridge ready #81 with notes/evidence.
• If script/code changes are needed, keep them narrow and add deterministic tests where practical.
• Verification should include git diff --check, focused tests/typecheck for changed scripts, and exact evidence paths.
• Final report should include Process Feedback.

[Ustice]

Read-only artifact comparison update from the coordinator lane. No Timberborn relaunch and no code edits were performed.

Comparison target:

• Make persistence stored-goods fixture-readiness prove item loss #64 pass loaded save: ~/Documents/Timberborn/ExperimentalSaves/Fuel/2026-05-31 23h36m, Day 7-5.autosave.timber
• Gate Slow Reactable Wildfire Tuning #44 block selected newer latest save: ~/Documents/Timberborn/ExperimentalSaves/Fuel/2026-05-31 23h41m, Day 7-5.autosave.timber
• Make persistence stored-goods fixture-readiness prove item loss #64 pass artifact root: /tmp/wildfire-qa/live-controller-20260601/twf-64-cdbd3cfd-overlap-rerun
• Gate Slow Reactable Wildfire Tuning #44 block artifact root: /tmp/wildfire-qa/live-controller-20260601/twf-44-b2728418-natural-target-rerun

Findings so far:

• Both autosaves are valid zip files with valid world.json, the same mod metadata, and the same top-level save structure.
• Both contain 1917 entities and 45 singletons. Component totals differ by two: MovementAnimator and Walker are 4 in the 23h36 save and 3 in the 23h41 save.
• Wildfire runtime snapshot record counts changed from 1711 ASH / 1675 BURN / 1 WF / 1 FIRE / 1 BEAVER to 1711 ASH / 1115 BURN / 1 WF / 1 FIRE / 1 BEAVER.
• The BURN rows have 0 exact overlap between the two snapshots. By decoded target prefix, 23h36 has 808 tree_cuttable, 754 crop_harvestable, 77 path_infrastructure, 21 structure, 9 stockpile, 5 water_infrastructure, 1 power_infrastructure; 23h41 has 243 tree_cuttable, 759 crop_harvestable, 77 path_infrastructure, 21 structure, 9 stockpile, 5 water_infrastructure, 1 power_infrastructure.

Current working hypothesis: the shared blocker is tied to the newer latest Fuel autosave selected after the #64 pass, not obviously to #44 commit b2728418 itself. The next worker pass should continue read-only first: compare save selection and runtime snapshot load behavior between 23h36 and 23h41, then justify at most one guarded Timberborn launch if artifact inspection cannot falsify the hypothesis.

[Ustice]

Follow-up read-only finding from the #44 blocker log and #64 pass transcript.

The important distinction is not just that wildfire_command_bridge_ready appears. In the #44 blocked log, the bridge logs ready during load, but the runtime initializer never appears to reach an update attempt afterward.

Evidence:

• Gate Slow Reactable Wildfire Tuning #44 blocked Player.log has only 114 lines and ends immediately after wildfire_command_bridge_ready.
• It includes wildfire_timberborn_persistence_loaded version=1 firesim_saved=true ash_entries=1711 beaver_behavior_entries=1 consequence_burn_damage_entries=1115.
• It includes wildfire_timberborn_runtime_initialize_deferred_until_update.
• It does not include wildfire_timberborn_runtime_initialize_waiting_for_entities, wildfire_timberborn_world_import_entity_snapshot, wildfire_timberborn_runtime_initialize_started, wildfire_timberborn_firesim_persistence_restored, wildfire_timberborn_persistence_runtime_state_restored, or wildfire_timberborn_runtime_initialize_completed.
• The command bridge is an ILoadableSingleton and logs ready in Load(), while command processing is in UpdateSingleton(). The timed-out status probes are therefore consistent with load reaching singleton Load() but not reaching the update phase that would process command-inbox.txt.
• Make persistence stored-goods fixture-readiness prove item loss #64 loaded the older 23h36m save, reached loaded HUD, and the command result showed runtime_loaded=true loaded_game_ready=true simulator_integrated=true tick_count=30744. That same result already had the reduced registered target shape later persisted in the 23h41m autosave (burn_damage_registered_targets=1115, persistent_restore_no_live_fuel_cells_cleared=1701).

Current sharper hypothesis: the 23h41m save produced after the #64 proof run is reload-unsafe or stalls Timberborn before the first world update, after singleton Load() but before Wildfire runtime initialization/update processing. This still does not implicate #44 commit b2728418 directly.

[Ustice]

Additional refinement from the #64 startup artifacts: the reduced burnable-state shape existed before the #64 fixture command ran.

Evidence:

• Make persistence stored-goods fixture-readiness prove item loss #64 command-status-before-unpause.txt from the successful 23h36m load already reports runtime_loaded=true, loaded_game_ready=true, simulator_integrated=true, tick_count=30743, burn_damage_registered_targets=1115, world_import_total_sources=4550, world_import_tree_sources=714, world_import_crop_sources=63, and persistent_restore_no_live_fuel_cells_cleared=1701.
• The subsequent qa-fixture-readiness stored-goods result at tick 30744 reports the same burn_damage_registered_targets=1115 and persistent_restore_no_live_fuel_cells_cleared=1701.
• The extracted raw 23h36m persisted snapshot had 1675 BURN rows, while the later 23h41m persisted snapshot had 1115.

So the likely transition is not “the stored-goods fixture command corrupts the save” by itself. It is more specifically: load the older save, sanitize/restore Wildfire runtime state down to the current live-fuel world, then Timberborn writes a newer autosave that is not reload-safe and stalls before Wildfire runtime initialization update logs appear. Worker should inspect the persistence restore/save cycle around persistent_restore_no_live_fuel_cells_cleared=1701 and whether the sanitized runtime snapshot is safe to persist back into Timberborn saves.