51 lines
2.8 KiB
Markdown
51 lines
2.8 KiB
Markdown
|
|
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
|