bts-simulatelisted

# Simulation Run scenarios to find what's missing or wrong: $ARGUMENTS ## Settings Simulation requires deep reasoning — it uses the main session model by default. If `agents.simulator` is explicitly set in `.bts/config/settings.yaml`, use that model instead. Adversarial validation uses `agents.simulator_validator` (default: sonnet) for the defense round and `agents.simulator_rebuttal` (default: session model) for the rebuttal round. Override in `.bts/config/settings.yaml`. Rebuttal uses the session model because constructing concrete failure scenarios requires deeper reasoning. ## Mode Detection Parse $ARGUMENTS: - If first word is `code` → **Code Simulation** (see below) - Otherwise → **Document Simulation** (spec walkthrough) --- ## Code Simulation Simulate against implemented code to verify all paths are covered. ### Step 1: Identify Code Files and Spec If tasks.json exists (implement recipe): - Read tasks.json for implemented file list - Read final.md for expected behavior and test scenarios If no tasks.json (fix recipe): - Read fix-spec.md "Changes" section for file paths - Read fix-spec.md for expected behavior ### Step 2: Read Code Read each implemented code file completely. Build a mental model of: - All functions and their call graph - All branches (if/else, switch, error returns) - All error handling paths - All external calls (DB, API, file I/O) ### Step 3: Design Scenarios **Mermaid-guided scenario design**: If final.md/fix-spec.md contains mermaid