Wires the player→ecology coupling for fauna (the USP: the living world reacts to
the player). GdFaunaEcology.deplete_species #[func] resolves the string species id
→ numeric via the species library and calls EcologyEngine::deplete_population.
combat_utils._roll_wild_creature_loot now passes the slain creature's tile into
item_system.roll_fauna_drops, which calls EcologyState.fauna_ecology.deplete_species
on every fauna kill — so sustained hunting drives a species to local extinction
(is_extinct), and the engine's growth/emergence recover it once pressure eases.
Logic stays in mc_ecology (Rail 1); GDScript only triggers + passes the tile.
Verified: mc-ecology cargo green; dylib rebuilt + deployed; canonical GUT 745/0
(new roll_fauna_drops signature + caller load cleanly, deplete_species callable).
p3-19 stays partial — flora-harvest half (chop/intensive → flora population) next.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Rust foundation for player→ecology feedback: PopulationSlot::deplete(amount)
(floors at 0, can cross the is_extinct threshold) + EcologyEngine::deplete_population
(col,row,species_id,amount) → post-depletion population, safe 0.0 no-op for a
missing tile/species. This is the hook hunting/harvesting will call to make
over-harvest drive local extinction; the engine's existing growth/emergence then
recovers abundance once pressure eases.
Tests: deplete_reduces_floors_at_zero_and_can_extinct (PopulationSlot) +
deplete_population_reduces_tile_species_and_can_extinct (engine); mc-ecology green.
p3-19 → partial. Remaining: GdEcologyEngine #[func] + GDScript kill/harvest wiring
+ dylib/GUT (loop continues).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pick_for_city gains a scout branch (after the early-military floor, before
expansion): when dwarf_scout is buildable (its tech/race/resource/building gates
met — mirrors pick_best_unit_of_type) and the capital owns no scout, the capital
queues one. Single scout, capital-only; the existing frontier-seek + scout-sweep
maneuvers (movement.rs) already drive dwarf_scout, so the AI stops diverting
combat units to scouting.
Tests: ai_builds_scout_when_buildable_and_none_owned +
ai_does_not_build_scout_without_its_tech; mc-ai 289/0 green. p3-22 → done.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Game 1 was NOT actually complete; the green dashboard overstated it. Created
objectives for the verified, untracked gaps (all confirmed 2026-06-25 against the
code, both Rust + GDScript paths):
- p3-19 player→ecology feedback (over-harvest/hunt deplete live populations; extinction)
- p3-20 weather affects scouting (vision penalty, not just movement)
- p3-21 weather-driven migration (migration ignores weather today)
- p3-22 AI builds dedicated scouts (only frontier-seeks with idle military)
- p3-23 trade richness (luxury swaps only; no gold/strategic trades)
- p3-24 Rail-1 port of economy/happiness/climate per-turn glue logic from GDScript
Dashboard regenerated. (Systems I'd wrongly doubted — ecology engine ticking, AI
worker improvements, naval harbor-gating — are confirmed working; not reopened.)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tools/objectives-report.py after marking p3-18 (water crossing) done. Keeps the
dashboard fresh for verify step 2.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
teched_army_fords_water_then_attacks_enemy_on_far_landmass: end-to-end proof of
the conquest payoff that motivated p3-18. Over an ocean-wall map, a player-0 army
with ocean_navigation embark fords the ocean column to landmass B (process_move_requests),
then strikes a player-1 unit waiting there (queued AttackRequest → process_pvp_combat):
a cross-water battle resolves and the enemy takes damage. Embark turns an
otherwise-unreachable rival on another landmass into an attackable one.
Deterministic, cargo-verifiable; complements P6-core (the ford proof). The full
headless 1v1-to-game_over demo is the only remaining (confirmatory) P6 item.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Completes single-source on the action bridge. With auto-embark (no explicit
Embark action), the embark/adjacency inputs to legal_actions_for / can_invoke were
dead:
- api-gdext: drop is_embarked / adjacent_water / adjacent_land params from both
#[func]s (+ the consume lines + doc).
- GDScript callers updated to the new arity: unit.gd (get_legal_actions +
can_invoke_action), unit_panel.gd (legal_actions_for + its dead arg vars and the
three dead _get_* helpers), test_unit_actions.gd (4 calls).
- unit.gd: remove the now-dead has_adjacent_water/has_adjacent_land fields (never
set — their _refresh_unit_terrain_context setter is long gone) + their serialize/
deserialize; test_unit_serialize.gd updated. is_embarked stays (real state).
Verified: cargo check green; dylib rebuilt + deployed; canonical GUT suite 745
tests / 732 passing / 0 failing (13 pending). No arg-mismatch errors.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Embark + transport now work in both the headless sim (authoritative) and the
rendered UI, verified at unit / integration / GUT levels (732 GUT passing).
Remaining: P6-full headless 1v1-to-game_over demo (confirmatory over P6-core),
vestigial-FFI trim (cosmetic), transport refinements (deferred, documented).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
test_pathfinder_embark.gd: over an ocean-column map, a land unit finds no path
without embark (embark_level 0), fords the column with embark (level > 0) and
reaches the far landmass; naval movement is unaffected by the embark arg.
Verified headless against the rebuilt dylib: GUT 732 passing / 0 failed (+3 from
729 — these tests; no regression). UI embark now matches the authoritative
headless sim.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Wires the rendered game's GDScript movement to the data-driven embark capability,
so a human playing the UI can cross water when teched (previously embark worked
headless only):
- pathfinder.gd: find_path / movement_range / find_path_with_fog gain a defaulted
embark_level param (non-breaking for all existing callers); _is_passable lets a
land unit enter water when embark_level > 0. Single-tier UI gate — the precise
coast-vs-ocean tier stays authoritative in the Rust sim; the gate avoids
hardcoding the biome→tier map in GDScript (Rail 1).
- KnowledgeWeb + TechWeb: embark_level(researched) passthroughs to the Rust
GdTechWeb.embark_level (the tech→level mapping stays in Rust, data-driven).
- world_map.gd: _current_embark_level() (defensive) feeds the active player's
level into all four pathfinder call sites (move, range overlay, fog previews).
gdlint clean. Verifies via dylib rebuild + GUT (next).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The rendered game moves via GDScript pathfinder.gd (GDScript-authoritative; no
Rust round-trip) over GDScript-canonical tech. To make UI movement embark-aware
WITHOUT re-deriving the tech→level mapping in GDScript (Rail 1: logic stays in
Rust), GdTechWeb gains embark_level(researched: PackedStringArray) -> i64 (0 none
/ 1 coast / 2 ocean) backed by the data-driven TechWeb::embark_level. The GDScript
pathfinder will call this and carry only a thin water-passability gate.
cargo check -p magic-civ-physics-gdext green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
P5a (dead GDScript embark UI) and P6-core (ford integration proof) landed. P5b
(rendered UI embark) scoped: the rendered state is hybrid (GDScript GameState/Player
+ Rust GdGameState bridge); the single-source path is a GdGameState #[func]
exposing the Rust-computed EmbarkLevel, threaded into pathfinder.gd — dylib-gated
(build-gdext.sh works) + GUT. P6-full demo is confirmatory over the integration proof.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
P3b deleted the Civ-V explicit Embark/Disembark actions on the Rust side, leaving
the GDScript UI plumbing dangling (it dispatched the now-removed "embark"/
"disembark" actions; gated on the amphibious keyword no unit carries, so it never
rendered). Removed it: unit_panel.gd embark_pressed/disembark_pressed signals,
their ACTION_SIGNAL_MAP entries + emit cases; world_map.gd signal connections +
_on_embark/_on_disembark handlers. No dangling refs remain; no GUT test referenced
them. Auto-embark (move onto water) remains the only embark model, now consistent
across Rust and the GDScript UI.
Remaining P5: the rendered game's movement (pathfinder.gd, GDScript logic) is not
yet embark-aware — entangled with the broader Rail-1 debt that rendered movement
runs GDScript rather than the Rust pathfinder. Tracked in the objective.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The scenario that motivated p3-18: an army on landmass A reaching landmass B
across an ocean strip. teched_army_fords_open_ocean_to_far_landmass asserts the
full chain through process_move_requests — without naval tech the ocean rejects
the move (army stays put); with ocean_navigation (Ocean embark) the army crosses
the strip onto the far landmass and auto-disembarks on arrival.
Deterministic, cargo-verifiable evidence (the project's preferred proof form), no
dylib/Godot needed. The full headless 1v1-to-game_over demo (P6-full) is the
heavier dylib follow-up.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The earlier "cargo resolver panic blocks the gdext dylib" claim was wrong: I was
running `cargo -p gdextension-api`, which is a crates.io godot dependency, not our
crate. The local crate is `magic-civ-physics-gdext`; `cargo check -p
magic-civ-physics-gdext` is green in ~38s. P5 (UI embark) and P6 (demo) are
feasible locally via build-gdext.sh + GUT — not build-host-gated.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Records transport P4a/b/c complete + the finding that the rendered game moves via
GDScript pathfinder.gd (not the Rust pathfinder), so embark works headless only
until P5 plumbs the embark gate into the GDScript path (or routes movement through
Rust). Transport refinements (carried-unit target-protection, AI-use) deferred.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
After the PvP combat phase, prune_orphaned_cargo drops any unit whose carrier_id
references a hull no longer in its player's roster — the transport sank, its
cargo goes down with it. Order-preserving removal that keeps the index-parallel
unit_upkeep aligned; idempotent and a no-op for carrier-free rosters (so existing
combat is untouched — pvp tests still green).
Test: destroyed_transport_loses_cargo (orphaned cargo pruned, uncarried unit
survives, unit_upkeep stays aligned).
Known follow-up: carried units ride the hull's hex (stacked); fully shielding
them from being individually targeted needs combat target-selection changes that
touch 1UPT assumptions — tracked, not in this commit.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Implements the carry mechanic in process_one_move, modelled as automatic moves
(consistent with auto-embark — no new explicit actions):
- BOARD: a land unit stepping onto an adjacent friendly transport hull (on water)
boards it (carrier_id = hull.id) instead of being blocked — no embark tech
needed, capacity-gated at TRANSPORT_CAPACITY. Handled before find_path (a land
unit can't path onto water otherwise).
- CARRY: when a transport moves, its loaded units are dragged to the new hex
(they ride the hull's hex, stacked).
- DISEMBARK: a carried unit steps off onto an adjacent empty land hex (carrier_id
cleared); rejected otherwise (carried units can't move independently on water).
Boarding/disembarking units are aboard, not embarked (is_embarked stays false).
Tests: transport_board_carry_then_unload (full cycle) + transport_rejects_boarding_when_full;
mc-turn 246 lib + all integration binaries green (the new modes only activate for
units with carrier_id or a transport-at-target, so existing movement is untouched).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Foundation for the transport mechanic (owner: build it):
- catalog UnitStats gains `keywords: Vec<String>` (authored on units/<id>.json),
+ `is_transport()` (keywords.contains("transport")) and a TRANSPORT_CAPACITY=2
constant mirroring the combat.json transport keyword ("carry up to 2 land
units"). Data-driven — no unit id hardcoded.
- MapUnit gains `carrier_id: Option<u32>` — the hull carrying this land unit
(None = on map normally). A carried unit rides the carrier's hex, isn't
independently attackable, and is lost with the carrier.
Test: transport_keyword_detected_data_driven; mc-units lib green. Mechanic
(board/carry/unload + combat-loss) lands in P4b/P4c.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Auto-embark is now the sole embark model. Remaining: transport (P4, large fresh
Rust mechanic), GDScript mirror + vestigial-FFI trim (P5, needs build host),
end-to-end conquest demo (P6).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With Civ-VI auto-embark live (move onto water → embarked), the half-built Civ-V
explicit path was a redundant second model — and dead besides (gated on the
`amphibious` keyword, which no unit carries). Per owner direction (unify on one
model, no two definitions), it is removed:
- mc-core: drop ActionKind::Embark/Disembark (+ idx/as_str/from_str), the four
embark DisabledReasons, the amphibious Embark/Disembark action-gen block, and
the now-dead UnitCapability is_embarked/adjacent_water/adjacent_land fields
(+ all fixtures and the amphibious action tests).
- mc-turn: drop handle_embark/handle_disembark + their dispatch arms + tests.
- mc-ai: drop the dead capability fields from the action-query construction.
- mc-state: MapUnit::is_embarked doc now describes auto-embark (its sole writer
is process_one_move).
- api-gdext: the legal_actions_for/can_invoke FFI embark inputs are now vestigial
(no longer affect legality); kept for ABI stability + flagged for the P5
GDScript-mirror trim.
The only embark model is now the data-driven auto-embark (P1b/P2/P3).
Tests: mc-core 263, mc-ai 287, mc-turn 244 green (−4 = the deleted explicit-embark
tests). gdextension-api full compile deferred to the build host (local cargo
resolver panics on a pre-existing thiserror/wasm feature-unification issue,
unrelated to this change — no Cargo.toml touched).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The tactical AI's own passability gate (passable_land_hexes) hard-excluded all
water, so even a teched army never considered crossing it — exploration and the
march-on-enemy-capital both stopped at the shoreline. Now the AI is embark-aware:
- TacticalState carries the bound player's embark_level (data-driven; projected
from PlayerState::embark_level by project_tactical_with_vision).
- passable_land_hexes → passable_hexes(map, embark): water tiles open per the
embark level (coast water needs Coast, open/deep ocean needs Ocean), mirroring
mc_pathfinding::is_passable. Non-water impassables (mountains/volcano/ice) stay
blocked regardless of embark.
So a frontier-seeking or capital-marching army with the naval tech will path
across water to reach a rival on another landmass — the discovery/conquest gap
that motivated p3-18.
Tests: embark_opens_water_for_passability (None/Coast/Ocean tiers) +
embark_never_opens_non_water_impassables; mc-ai lib 287 green (the embark=None
default preserves all existing movement behaviour).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Civ-VI auto-embark model (owner choice): a land unit that ends its move on a
water tile becomes embarked; stepping back onto land disembarks it — no explicit
action needed. Wires the previously-dead is_embarked field + embarked_defence_penalty.
- mc-pathfinding: pub is_water_at(grid, pos) helper.
- mc-turn process_one_move: after a land unit moves, set MapUnit::is_embarked =
(destination is water). The dragged escort protectee's embarked state is kept
consistent with the tile it lands on too. Naval units never toggle (they belong
on water).
- mc-combat: CombatParams gains defender_is_embarked; resolve() halves the
defender's defence via the canonical embarked_defence_penalty when set. The
apply_attack caller passes the defender unit's is_embarked.
So an army can cross water (P1 gate + tech) and is vulnerable while doing so
(the Civ embarked rule), exactly as the half-built scaffolding intended.
Tests: mc-combat embarked_defender_takes_more_damage (high-defence case so the
50% penalty clears damage-rounding); full mc-combat (146) + mc-turn (248) green,
no regression (penalty only activates when embarked).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
P1 hardcoded the tech ids ("shipbuilding"/"ocean_navigation") in Rust — a Rail-2
violation (JSON is the canonical content store) and not single-source. Per owner
direction ("should be a player-level config setting"), the embark grant now lives
in data and is cached per player:
- mc_core::EmbarkLevel moves to the shared base crate (was mc-pathfinding) so
PlayerState can hold it; mc-pathfinding re-exports it. Adds from_mechanic_key
(the ONLY place the embark_* mechanic-key strings live).
- The naval techs carry the grant in JSON via unlocks.mechanics: shipbuilding →
embark_coast, ocean_navigation → embark_ocean. Which tech grants embark is now
authored data, not Rust.
- TechWeb::embark_level(researched) derives the strongest grant across a player's
researched techs (None < Coast < Ocean).
- PlayerState gains a cached embark_level field; process_science recomputes it
each turn from the researched set (idempotent → save-load / tech injection
covered). The move handler reads the cache (no per-move tech parsing).
Tests: mc-core EmbarkLevel ordering + mapping; mc-tech embark_level method
(inline web) + a real-data guard that authored naval.json carries the mechanics;
mc-pathfinding 9/9 unchanged. All green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Land units were hard-confined to their landmass: is_passable("ocean", Land) was
always false, with no tech path across water (Civ "embarkation" gap). The
scaffolding existed but was dead (embarked_defence_penalty, the transport keyword).
P1 wires the first layer — the pathfinding gate:
- mc-pathfinding gains EmbarkLevel {None, Coast, Ocean}; is_passable + find_path
take it. A Land unit may now enter water per level — coastal (IsCoast) water
needs Coast, open/deep ocean needs Ocean. None = legacy land-locked (default,
so existing behaviour is unchanged).
- The move handler (process_one_move) derives the level from the player's naval
tree via embark_level_for: ocean_navigation→Ocean, shipbuilding→Coast. So a
teched army can cross water; an un-teched one still cannot.
Maps onto the existing naval tech tree and the IsCoast/IsWater biome tags — no
new techs, no new biomes. Civ two-tier model (Optics/Astronomy → shipbuilding/
ocean_navigation).
Tests: mc-pathfinding 9/9 (incl. embark_gates_land_on_water_by_level +
ocean_embark_lets_a_land_unit_cross_an_ocean_strip); mc-turn suite green.
Objective p3-18 created (full design + phased acceptance P1–P6); P1 marked done.
Follow-ups: P2 embarked combat, P3 AI water-pathing, P4 transport, P5 GDScript
mirror, P6 end-to-end conquest demo.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The pump loop treated an empty stdin read as "EOF or no line yet" and yielded +
retried forever, so `cat reqs | player-api-server.sh` hung until CP_TIMEOUT_SEC
instead of the documented clean EOF exit. Godot 4.6's read_string_from_stdin
blocks, so an empty return is end-of-stream — break and quit(0). Also add a
`{"type":"stop"}` request (acked, sets the loop flag) so interactive clients that
hold stdin open (Popen drivers, the MCP adapter) can exit cleanly without relying
on EOF — the clean-exit request path the docs promised but never implemented.
Verified: 11-request batch pipe now exits 0 in ~1s (was 124/timeout); view+stop
exits 0 in ~4s with both responses acked.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds the deterministic end-to-end proof p3-16's last bullet needed: in AI-vs-AI
self-play, once frontier-seek exploration brings a militarist into view of a
*weaker* rival, it dispatches a war-dec and the relation flips to War within 60
turns. Asymmetric armies (slot 2 weakened) so the aggressor clears its
superiority threshold on discovery. Pairs with the existing decide_diplomacy unit
cases (cautious-holds-at-parity / warmonger-strikes) to demonstrate
personality-driven war-decs manifest in actual play — the integration that was
blocked purely on discovery (p3-17). Shared self-play setup helper extracted.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closes p3-17's "measurable improvement in self-play: earlier first-contact" as a
reproducible cargo test (the sim is deterministic, so this needs no apricot smoke
batch). Two AI militarists start fogged-apart on a 12x12 map; the frontier-seek
exploration must bring one into view of another within 40 turns. Asserts no
contact at game start (fog intact) and contact by the budget. This is the
discovery feed p3-16's decide_diplomacy (declares only on a *discovered* rival)
depends on — it never fired reliably before exploration landed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
movement.rs::is_at_war defaulted a missing relation slot to `true` (at war) —
the legacy p1-01 "missing → war" model that courier-diplomacy (p3-16) supersedes:
every pair starts at PEACE, war begins only on a war-dec envelope. An absent slot
now defaults to peace (`map_or(false, …)`), so the AI never treats a
not-yet-projected pair as a phantom war. project_tactical_relations fills the vec
from real courier state, so genuine wars are unaffected. mc-ai+mc-player-api 556/0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Guards the wiring the movement unit tests can't: compute_vision (fog) →
project_tactical_with_vision (sets TacticalTile.explored) → decide_tactical_actions.
An idle warrior with no visible enemy on a 20x20 foggy map must issue a MoveUnit
toward the fog rather than idling — the discovery feed p3-16's war-dec gate needs.
Asserts the far corner projects as unexplored and the unit steps off its start
tile. Reproducible (no MCP), runs under cargo test --workspace.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Idle military/scout units' explore move used a centroid-mirror heuristic (head
for the far reach) that ignored actual fog, so the AI rarely expanded its
explored footprint or made first contact — starving target acquisition and the
p3-16 war-dec discovery gate.
- Add `explored: bool` to TacticalTile (serde default true so un-flagged bridge
tiles read as seen, never spuriously sought). projection.rs::project_tactical_map
populates it from PlayerVision::is_explored (omniscient → all true).
- Upgrade movement.rs::score_explore_move to target the nearest genuinely
unexplored tile (nearest_unexplored_frontier), with a deterministic per-unit
tie-break so a stack fans across frontier tiles; the centroid-mirror is kept as
the fully-explored fallback. No rng/Instant — determinism contract preserved.
- 2 new tests (targets-nearest-unexplored, mirror-fallback-when-fully-explored).
The headless self-play path (dispatch → project_tactical_with_vision, rebuilt per
turn) now drives real exploration. mc-ai+mc-player-api 555/0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add tools/check-no-gdscript-sim-logic.py and wire it as verify step 18 (TOTAL
20→21). Fails if presentation GDScript (src/game/engine/src/**/*.gd) re-introduces
catalog yield aggregation (`yield_production += …`) or hand-built spec dicts
(`"yield_production": …`) — the exact drift class just moved to Rust. Verified to
flag the pre-7e2baa25d aggregation and pass clean on the current tree. Logic
belongs in the mc-* crates, reached via the GDExtension bridge (Rail 1).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Twin of the building consolidation. The GDScript build_unit_catalog did the
buildable-unit filter (drop faction:"wild" monsters + "freepeople" NPCs) and
field mapping by hand. Add mc_ai::tactical::parse_unit_catalog as the one Rust
implementation (resilient: skips malformed, drops map-spawned factions, defaults
tier=1), exposed as GdItemSystem.parse_unit_catalog_json. GDScript
build_unit_catalog now marshals the raw unit docs to it; the bench routes through
the same transform. The wild/freepeople filter lives only in Rust now.
Validated: mc-core+mc-ai+mc-player-api 826/0 (3 new parse_unit_catalog tests);
rebuilt aarch64 dylib; headless GUT 729/0/13 incl. a unit round-trip + wild-filter
delegation test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Godot's JSON.parse_string decodes every JSON number as a float, so a tactical
catalog that round-trips through GDScript (build_*_catalog → JSON →
decide_actions / set_ai_*_catalog_json) presents tier/cost/yields as `1.0`, and
Rust's u32/i32 deserialize rejected the whole catalog
("invalid type: floating point 1.0, expected u32"). Add lenient_u32 / lenient_i32
deserializers and apply them to TacticalUnitSpec.tier and TacticalBuildingSpec
{tier, cost, yield_*×9, great_work_slots}. This was latent in the building
delegation and would have bitten as soon as buildings loaded; the unit-catalog
delegation surfaced it. Unit-tested (float + int forms).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a regression guard that loads the ENTIRE authored content store through the
Rust source-of-truth types — every public/resources/units/*.json into UnitStats
AND TacticalUnitSpec, every buildings/*.json through parse_building_catalog — not
just the 7-file bench subset. The `game data JSON schemas` step validates against
schemas; this validates against the structs the simulator actually runs on, so a
file can no longer satisfy a schema yet break the sim. Runs under
`cargo test --workspace`, so verify auto-enforces it; a drifting file fails the
gate with its filename.
The guard immediately caught two parser-parity bugs the bench never exercised:
- Building `effects[]` may carry a boolean value (`{"type":"enables_naval",
"value":true}`); `BuildingEffect.value: f64` rejected it, dropping the whole
building (harbor, stable, deep_*, …) from the catalog. Add a lenient_number
deserializer that coerces non-numbers to 0.0 — parity with the GDScript
`value is int or is float` guard. (NB: the dylib from 7e2baa25d had the strict
parser; rebuilt so the live game re-includes these buildings.)
- TacticalUnitSpec.tier had no serde default while the GDScript builder defaults
it to 1; a unit JSON omitting tier (founder.json) failed to deserialize. Add
#[serde(default = "default_tier")] for path parity.
Test excludes the *.schema.json / *_categories.json sidecars that live in the
content dirs. Validated: mc-core+mc-ai+mc-player-api 822/0; rebuilt aarch64 dylib;
headless GUT 728/0/13.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The effects→yield aggregation existed in two places: GDScript
(ai_turn_bridge_state.gd::build_building_catalog) and Rust
(mc_ai::tactical::parse_building_catalog). Both were byte-equivalent but a
duplicated transform that could drift. Per Rail 1 (simulation logic in Rust),
the GDScript copy is now retired.
- api-gdext: GdItemSystem gains `aggregate_building_catalog_json(raw)` — a thin
#[func] over parse_building_catalog that takes the raw authored building docs
and returns the aggregated Vec<TacticalBuildingSpec> JSON (reuses the existing
lightweight stateless bridge class — no new registered class, so no plum
class-cache churn).
- ai_turn_bridge_state.gd: build_building_catalog now marshals
DataLoader.get_data("buildings").values() to that method instead of summing the
effects[] array in GDScript. The ~80-line aggregation loop is deleted.
- parse_building_catalog: made resilient (skips malformed entries instead of
failing the whole catalog) to match the GDScript builder's has("id") filter.
Validation: cargo mc-ai building_catalog 4/4; rebuilt the aarch64 dylib; full
headless GUT 728 passing / 0 failing / 13 pending, including 2 new tests that
exercise the GDScript→Rust→GDScript round-trip (forge production→yield_production,
research→science, trade→gold) and the malformed-input empty-catalog path.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The building effects→yield aggregation existed only in GDScript
(ai_turn_bridge_state.gd::build_building_catalog), and the mc-player-api bench
kept a third hand-written copy of the resulting TacticalBuildingSpec literals
(fixed costs/yields/gates) that drifted from public/resources/buildings/*.json.
Add `mc_ai::tactical::parse_building_catalog` as the ONE Rust implementation of
the transform: parses authored building docs (object or array shape), aggregating
each `effects[]` entry into the scalar yield fields with the exact same
effect-type→field mapping the GDScript builder uses (food/production/gold|trade/
science|research/culture/defense|city_hp|wall_hp/happiness, gpp_*/great_work_slots_*
prefixes). Empty gate strings → None; missing tier → 1. Unit-tested.
The bench `build_building_catalog` now loads granary/forge/library/walls straight
from the canonical JSON through this transform — no hand-maintained specs, can't
drift. (granary is correctly tech-gated by husbandry now.) The engine bridge can
adopt the same fn to retire the GDScript copy — follow-up.
mc-ai + mc-player-api green: 547/0, incl. 3 new parser tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The mc-player-api bench harness hand-defined unit stats twice — `build_unit_catalog`
(TacticalUnitSpec) and `build_runtime_units_catalog` (UnitStats) — as inline literals
that silently drifted from public/resources/units/*.json: wrong unit_type ("military"
vs "melee"), build_cost 0 vs the real 40, iron_working vs the real bronze_working.
Each drift masked a real AI-production bug and had to be patched field-by-field.
Root fix per Rail 2: both catalogs now deserialize straight from the canonical
`public/resources/units/<id>.json` documents (UnitStats flattens the top-level combat
line + renames cost/movement; TacticalUnitSpec's gate fields are all serde(default)),
so one file feeds both and the bench economy — cost, tier, race/tech gates, combat
stats, archetype — cannot diverge from the shipped game. Tier-2 slot uses the
dwarf-native `dwarf_berserker` (single-object, iron_working-gated) instead of the
generic legacy `pikeman.json` (a multi-unit array). This supersedes the earlier
inline unit_type/build_cost band-aids.
Full mc-player-api suite green (163/0), incl. claude_vs_ai_full_game_transcript with
real costs (warrior 40), so the AI still fields units on the corrected economy.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
City unit production spawned every unit at the flat `lair_combat_config.unit_spawn_cost`
(8) regardless of the unit's authored production cost — `dwarf_warrior` costs 40 in
public/resources/units/dwarf_warrior.json ("cost", loaded as UnitStats.build_cost).
Buildings/wonders already pay their real queue_cost in process_city_production, but
Queueable::Unit is routed to try_spawn_unit, which hardcoded the flat 8. Result:
units were ~5x too cheap, so a starter city (~6 prod/turn) spawned a warrior every
~1.3 turns instead of ~7 and the AI stack ballooned in the opening turns.
try_spawn_unit now charges `units_catalog[unit].build_cost` when the runtime catalog
knows it (>0), falling back to the flat unit_spawn_cost only for un-costed bench
fixtures and the no-queue auto-warrior. The data-loaded game (build_cost=40) now
prices units correctly; bench tests with build_cost=0 are unchanged (flat 8). This
restores Rail 2 — the JSON cost is canonical, not a hardcoded Rust constant.
Validated: mc-turn lib 248/0 (incl. all spawn + gold-gate tests), mc-player-api +
mc-turn 138/0, claude_vs_ai_full_game_transcript green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`claude_vs_ai_full_game_transcript` failed: "no AI slot built a unit by turn 10".
Root cause was two test-fixture values diverging from the real engine, both in the
`build_3_player_state_like_harness` construction:
1. `add_player_militarist_inline` never set `PlayerState.race_id`. The real engine
sets it from presentation metadata (api-gdext set_player_presentation ->
p.race_id); the tactical production picker filters race-gated units
(`dwarf_warrior` has race_required="dwarf") by it, so an empty race_id rejected
every unit. Set race_id="dwarf" (Game 1 is all-dwarf).
2. `build_unit_catalog` set `unit_type: "military"` for dwarf_warrior/pikeman, but
`pick_best_unit_of_type` filters on the combat archetype unit_type ∈
{melee,ranged,siege} — the real units JSON uses "melee" (72 melee / 41 ranged /
20 siege across public/resources/units). "military" matched no preferred type.
With either wrong, `pick_best_unit_for_clan` returned None and fell back to the
phantom id "warrior", which the queue classifier (units_catalog keyed by
"dwarf_warrior") then treated as a *building* (Queueable::Item) — so try_spawn_unit
skipped it, no unit ever spawned, no UnitCreated event fired, and the AI bled units
(4->3->2->1) with no replacement. After the fix the AI queues
`Unit { dwarf_warrior }`, spawns via step's try_spawn_unit (units 4->6 by turn 3),
and emits UnitCreated on the wire. Full mc-player-api suite green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
process_siege was changed from "≥3 attackers within 2 hexes = instant capture" to
HP-gated siege: 15 dmg/attacker/turn against the city's persistent hp, capture at
hp<=0. A starter city has 510 hp, so 3 attackers (45/turn) capture neither in one
step (last_survivor) nor in 10 turns (event_collector). Drop each defender city's
hp below the single-turn 3-attacker total (45) so the capture fires as the tests
intend, and refresh the stale "nearby_attackers >= 3" doc comments.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- full_game_transcript: add the missing `Action::DeclareWar { target }` arm to the
signature_of match (the tactical AI gained DeclareWar so AI-vs-AI leaves perpetual
peace — non-exhaustive match broke compilation).
- ai_controller: player_index_to_slot now caps out-of-range indices to the last slot
(graceful degradation for >MAX_PLAYERS games) instead of erroring; assert the cap.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The p1_29j_rust_action_application_found_and_capture_stamp test had been spliced
into the MIDDLE of refound_suppression_lever_sweep, orphaning that sweep's
directional-gate tail (and a stray `}`) — the file never compiled because cargo
test never ran headless-clean. Reunite the sweep with its tail, and drop the new
fn's references to a private `CityState` import (unused) and a MapUnit `owner`
field that does not exist (unit ownership is by the player's `units` vec).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`tools/objectives-report.py --check` was failing (README/objectives.json stale vs
per-objective frontmatter after recent objective edits). Regenerated both.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
uuid reaches api-wasm transitively (mc-mapgen → mc-turn → mc-state → mc-comms →
mc-replay → uuid) and gates its v4 RNG (`RngImp`) behind uuid's own `js` feature
on wasm32 — `wasm-pack build api-wasm` failed with E0433. Add a wasm32-target
uuid dep with `features=["js"]` (feature-unifies across the wasm build); native
builds are untouched (they must not pull wasm-bindgen through uuid).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Both tests now call processor.load_authored_encounter_rates() so the fauna /
ambient encounter pass is live (it no-ops without rates) — fixes p2_58b ambient
count and turn_processor's fauna-encounter assertion.
- turn_processor's "wealth must accumulate >60" was wrong for a single-city
militarist: it earns wealth income but reinvests it into unit upkeep, hovering
at the insolvency floor (verified empirically — a seeded 60 treasury drains to
0). Reframed to assert the economy stays SOLVENT (gold >= 0) over 50 turns;
net hoarding belongs to wealth/merchant scenarios.
GUT: suite now 726 passing / 0 failing / 13 pending (was 51 failing at session start).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
