docs: establish simulation architecture gate

docs/LEARNING_ROADMAP.md

@@ -28,6 +28,31 @@ Each milestone should produce five outcomes:
 
 Do not advance because files exist. Advance when the exit test passes.
 
+The current implementation has completed ResourceNode migration through player
+parity. Next, build only the minimal Jajce scaffold and navigation proof, then
+pass the architecture gate below before beauty production or broader simulation
+features. See [ADR 0001](decisions/0001-simulation-authority-boundary.md).
+
+## Mandatory architecture gate
+
+This gate sits between the first Jajce terrain/navigation proof and substantial
+beauty work, inventories, schedules, relationships, or population growth.
+
+It requires:
+
+- an explicit deterministic simulation clock;
+- controlled, seedable random streams;
+- a headless fixed-seed scenario runner and final-state checksum;
+- versioned serializable records for current NPC, village, and resource state;
+- authoritative resource amounts and reservations outside scene nodes;
+- stable action/profession IDs and initial definitions;
+- separate action selection, execution, target resolution, and visual travel;
+- an active-world adapter for navigation facts and NPC position synchronization.
+
+The gate is complete when the same scenario produces the same checksum without
+loading `main.tscn`, and loading or unloading a visual does not change
+authoritative NPC or resource state.
+
 ## Three vertical slices
 
 The long-term vision contains three major risks. Validate them separately before
@@ -207,7 +232,8 @@ The staged replacement of abstract task zones begins with
 - ownership, storage, reservations, and transactions;
 - production recipes;
 - world interaction points;
-- consistency and invariant testing.
+- consistency and invariant testing;
+- structured economic events as authoritative facts.
 
 ### Build
 
@@ -226,9 +252,12 @@ Include:
 - abstract transfer for distant agents;
 - reservation and cancellation;
 - spoilage only if it improves the initial loop;
-- player participation in the same resource rules.
+- player participation in the same resource rules;
+- structured gather, transfer, consume, deny, and depletion events carrying
+  stable actor, target, location, and resource IDs.
 
-Add wood only after the food chain is coherent.
+Wood extraction already exists. Do not build a deeper wood production chain
+until the food chain is coherent.
 
 ### Reusable artifact
 
@@ -548,26 +577,44 @@ At the end of each milestone, evaluate the system against this checklist:
 - Does it expose reason/debug information?
 - Do measurements justify its complexity?
 - Has at least one real gameplay feature exercised the API?
+- Does persistent authority remain valid when its presentation node is absent?
+- Can an active visual synchronize position without becoming the sole owner of
+  location state?
 
 Do not extract a plugin solely because a system might be reusable. Prefer a
 clear internal module until multiple real consumers establish a stable API.
 
 ## Recommended implementation order from the current repository
 
+Completed foundations:
+
+- finite food and wood `ResourceNode` instances;
+- NPC target selection, reservation, depletion, and authoritative yield;
+- player parity through the same extraction contract;
+- navigation-failure recovery and an initial headless contention scenario.
+
 The practical next sequence is:
 
-1. Add simulation controls and an NPC reason inspector.
-2. Add finite berry bushes and trees through the first `ResourceNode`.
-3. Migrate food target selection, reservation, depletion, and actual yield.
-4. Introduce an explicit deterministic simulation clock and seed.
-5. Replace remaining free-form task strings with action IDs/definitions.
-6. Separate action selection, action execution, and visual travel.
-7. Migrate wood and give the player the same extraction contract.
-8. Build the first location-based food storage/inventory.
-9. Make one NPC visibly gather, carry, store, retrieve, and eat food.
-10. Build the first attractive Terrain3D simulation-garden layout.
-11. Add simple stylized characters and profession readability.
-12. Add save/load before the mutable world state becomes substantially larger.
+1. Capture a reproducible flat-map baseline.
+2. Create only the minimal `JajceWorld` scaffold, terrain greybox, navigation
+   spike, and stable-ID resource-placement proof.
+3. Begin the architecture gate with deterministic clock/randomness, a headless
+   scenario runner, final-state checksums, and serializable state records.
+4. Move resource amount/reservation authority out of `ResourceNode` scenes.
+5. Replace free-form task and profession strings with stable IDs and
+   definitions.
+6. Separate action selection, execution, target resolution, and visual travel;
+   remove decision mutation from `WorldViewManager`.
+7. Define active-position synchronization and prove visual unload/reload.
+8. Pass the architecture gate's deterministic headless and unloaded-visual exit
+   tests.
+9. Build location-based food storage, inventory, and transactions.
+10. Emit structured economic events while making one NPC visibly gather, carry,
+   store, retrieve, and eat food.
+11. Add versioned save/load before schedules or social state expand.
+12. Resume the attractive Terrain3D simulation-garden beauty pass.
+13. Add stylized character and profession readability plus the reason
+   inspector.
 
 This order strengthens the simulation while regularly producing visible
 progress suitable for public development updates.