magicciv/.project/team-leads/warcouncil.md

id	name	specialization	objectives
warcouncil	Warcouncil	AI action generation, MCTS, GPU look-ahead, clan personality differentiation, difficulty calibration	p0-01 p0-02 p0-20 p0-22 p0-24 p0-26

Mandate

The Warcouncil is the clan-elders' council of strategists. Its charge is to give every AI opponent a recognizable clan-soul — Ironhold that out-builds rivals, Blackhammer that commits aggression early, Goldvein that weaponizes gold, Deepforge that tall-empires, Runesmith that adapts — and to think N turns deeper than the player can afford to.

Quality metric set (user directive 2026-04-17)

AI tuning targets are measured via state-at-end quality metrics, NOT median time-to-victory. Every game ends at T300 (turn limit → score) or earlier via domination; TTV is a bimodal artifact of when domination fires vs when score-fallback hits. Use instead, per Normal-vs-Normal 10-seed T300 batch:

• Median winner tier_peak ≥ 6 (mid-late era reached)
• Median tier_peak_gap (winner − loser) ≤ 2 (contested, not steamroll)
• ≥1 player reached peak unit tier ≥ 6 in ≥7/10 games
• ≥1 wonder per player in ≥5/10 games
• total_combats ≥ 50 in ≥7/10 games (real conflict, not a fold)

These five sub-gates jointly measure game feel — whether the AI delivers competitive mid/late-game 4X arcs. Victory-type distribution (dom vs score) is characterization, not a quality knob.

Difficulty calibration (p0-24) layers on this: Easy / Normal / Hard must produce materially different tier_peak distributions (see p0-24 acceptance). The AI stack (MCTS + heuristic) is unchanged across tiers; only tuning knobs in difficulty.json differ.

Cross-reference instrumentation: p0-25 owns the tier_peak / peak_unit_tier / wonder_count fields in turn_stats.jsonl + tools/autoplay-report.py. Blocks quality-gate validation until landed; Shipwright-owned.

Owned surface

• src/simulator/crates/mc-ai/ — evaluator, MCTS tree, game state encoding, GPU rollout, and (per p0-26) the tactical executor under src/simulator/crates/mc-ai/src/tactical/ (unit move, attack target, fortify/heal, city-founding site pick, production queue, citizen assignment, scout vs garrison).
• src/simulator/api-gdext/src/ai.rs — both GdMcTreeController (strategic, p0-01) and GdAiController (tactical, p0-26) plus related AI bindings.
• src/game/engine/src/modules/ai/ai_turn_bridge.gd — the thin dispatch layer that calls into GdAiController / GdMcTreeController and reflects Action records onto engine entities. personality_assigner.gd also stays here (data-loading, not decision logic).
• AI tests: src/game/engine/tests/unit/ai/, src/simulator/crates/mc-ai/tests/, src/game/engine/tests/integration/test_ai_simulation.gd.
• AI portion of tools/autoplay-report.py and tools/checklist-report.py (per-clan tables, personality_win_balance gate).
• public/games/age-of-dwarves/data/ai_personalities.json — clan axis definitions.

simple_heuristic_ai.gd, ai_tactical.gd, ai_military.gd, and the ai_player.gd stub were deleted as part of the p0-26 port (task #8). wild_creature_ai.gd is explicitly out-of-scope for p0-26 (see its non-goals) and is not warcouncil-owned.

Boundaries

The Warcouncil reads from combat, tech, economy, magic, and map systems but does not modify them. If a rule change is required outside its owned surface, open a handoff in .project/handoffs/ to the appropriate specialist instead of editing across the boundary.

Out of scope:

• mc-combat/ — owned by combat-dev
• mc-tech/, mc-economy/, mc-city/, mc-happiness/, mc-culture/ — owned by game-systems
• mc-magic/, mc-magic GDScript — owned by magic-dev (Game 2)
• Rendering / UI / scenes — owned by godot-renderer / godot-ui
• Map generation — owned by game-algorithms

Closure Order (2026-04-25)

The AI cluster closes in this strict order; do not jump ahead:

1. p0-41 — parent close after split (p0-41a-rally-smoke.md carries the deferred smoke; parent is ✅ done as of 2026-04-25)
2. p0-42 — formation aggregation: finish acceptance bullets before closing
3. p0-43 — formation AI: finish acceptance bullets before closing
4. p0-02 re-run under p0-25 instrumentation (per the new first acceptance bullet: 5×10-seed batch demonstrating ≥10% tier_peak delta between goldvein vs ironhold and runesmith vs blackhammer)
5. p0-22 — ultimate stress test, the integrating gate (5 clans, huge map, deep lookahead)
6. p0-01 — closes last, as the umbrella of the chain (all five quality sub-gates must pass)

Rationale: each step's acceptance evidence feeds the next. Out-of-order claims will produce paperwork without movement. p0-01's tier_peak gate cannot be cited until p0-02's re-run confirms clan divergence; p0-22 provides the multi-clan sample that validates both. Do not claim p0-01 or p0-02 done before p0-22 evidence is in hand.

Escalation

• Failing determinism gate → handoff to the owner of mc-turn turn order; the Warcouncil preserves determinism in its own code (RNG seeding, sorted iteration, per-player GPU dispatch) but cannot unilaterally change the authoritative turn phase sequence.
• Victory-rate regression caused by a non-AI system → open an objective handoff with evidence from tools/autoplay-report.py rather than patching heuristics to paper over the underlying bug.
• GPU build breakage across wgpu versions → coordinate with whoever owns mc-compute and mc-turn for a unified wgpu version bump.