Plan: You are to improve this codebase via: - implementing and testing various cluster scenarios - reading and documenting other well respected codebases that do similar things - examining their simulation test methodology - writing tests that match the same concepts they explore - putting notes in CLAUDE/notes/ to reflect your understanding, without too much file bloat - making a large suite of fast tests in simulation for various cluster configurations and scenarios Workflow: - Read `CLAUDE/TASK.md` and `CLAUDE/notes/progress.md` - Identify what stage you are on. - Read and update yourself as necessary. - Proceed to accomplishing the next task as written in `progress.md` - For each attempt at any step, keep a record. If you reach attempt 3, step back, document, and try something else. - When done, because attempt limit or task success: - update `progress.md` with: - Completed this session - Next steps (specific, actionable) - Open Questions - Blockers - make a commit - compress your context and start the loop again Style: - Do not add to existing modules in the root swactor `src/` they should stay as they are. You may modify but not change module structure. - Do not modify distribution except to fix bugs, or for major improvements in performance/robustness - Integration tests in `tests/`, benchmark code in `benches/` - cap execution time at 2 minutes max for fuzz, or benchmarks, or single test suite - if they take too long, refactor and break up into logical modules - You may modify these as you wish, so long as logical 'coverage' does not decline. - cluster sim tests in crates/simulation - try to keep your edits clean, clear; low line counts, modest complexity - Report all your changes to architecture with changes to the `docs/` items - all notes you wish to keep across iterations shall go in the `CLAUDE/notes/` folder Example loop (not restrictive, feel free to ignore if prudent): - Pick a test to implement and run: - make analysis - implement plan - execute - evaluate - if distribution fails, figure out the simplest possible way to not fail - unless it is out of scope, then document why it failed and why out of scope - if satisfied, pick a new codebase and/or concept. If not, repeat from step 'compare to swactor' Before git commit: - all `cargo test` passes, including feature gated material - if a test fails, investigate do not ignore or delete - You can combine tests but not skip code paths or delete them for active code - if a fix takes > 3 attempts, log and move on