Searches for and synthesizes military doctrine, historical data, theorist writings, and philosophical/ethical works relevant to the current subsystem being developed
Scope explicitly includes philosophers, ethicists, and political theorists (Thucydides, Machiavelli, Grotius, Walzer, etc.) — not limited to military thinkers
Constrained to approved sources (see Research Source Tiers below)
Output: summary of relevant findings with full citations and source tier classification
Example: when implementing the morale system, invoke to survey Clausewitz on friction, du Picq on combat motivation, S.L.A. Marshall on fire ratios, modern RAND studies on unit cohesion
Example: when implementing ROE, invoke to survey Walzer on just war constraints, Grotius on proportionality, relevant Geneva Convention provisions
Focused on mathematical, stochastic, and signal processing modeling approaches
Constrained to approved sources (see Research Source Tiers below)
Output: summary of modeling approaches with mathematical formulations, assumptions, limitations, and citations
Example: when building the detection system, survey detection theory (Neyman-Pearson), ROC curves, SNR-based Pd models from radar/signal processing literature
Enforces post-MVP lockstep: completing Phase 11+ requires updating CLAUDE.md, project-structure.md, development-phases-post-mvp.md, devlog/index.md, phase devlog, README.md, and MEMORY.md together
New deficits discovered during post-MVP work must be added to both devlog/index.md AND the deficit-to-phase mapping
User-facing doc rules (Phase 31+): new modules update architecture.md; new scenarios update scenarios.md + eras.md; new units update units.md; API changes update api.md; new devlogs require mkdocs.yml nav entry; test count changes update index.md
Reviews a module's design against established military theory and project architectural decisions
Checks: does this morale model capture Clausewitzian friction? Does the C2 system implement OODA-like cycles? Does the logistics model respect Jominian LOC principles?
Keeps implementation honest against the theoretical foundations we've committed to
Interactive walkthrough for creating or editing campaign scenario YAML files
Guides user through sides, units, terrain, objectives, victory conditions, and calibration
Mandatory equipment mapping validation (Step 3): verifies all WEAPON/SENSOR equipment names have entries in _WEAPON_NAME_MAP/_SENSOR_NAME_MAP in scenario_runner.py. Missing mappings are added before YAML generation.
Mandatory sensor presence check: ensures every unit type has at least one category: SENSOR equipment entry. Adds era-appropriate defaults if missing.
Mandatory load test (Step 7): runs scripts/validate_scenario_data.py --file and verifies armed > 0, sensored > 0 through ScenarioLoader
Validates against CampaignScenarioConfig schema
Outputs complete scenario YAML to data/scenarios/{name}/scenario.yaml
Trigger: when a unit definition or scenario YAML is created or modified
Checks:
Validates against the pydantic schema for that unit class (id field, numeric types, probability ranges)
Equipment category validation: all category values must be valid EquipmentCategory enum values (WEAPON, SENSOR, PROPULSION, PROTECTION, COMMUNICATION, NAVIGATION, UTILITY, POWER — NOT "TOOL")
Sensor presence check: warns if unit YAML has no category: SENSOR equipment entry
Equipment name sanity: flags obviously malformed weapon equipment names
Scenario unit_type validation: flags unit_type values that look like display names instead of valid IDs
Action: block write if structural issues found; warn on missing sensors