e28aca099e
Add actor lifecycle hooks and two-mode graceful stop mechanism: - ActorInterface::on_start() called once before first message (panic = poison) - ActorInterface::on_stop() called on graceful stop (NOT on panic - unsafe) - ctx.stop_self() for immediate self-stop after current message - runtime.stop_actor() for external stop (PoisonPill semantics, queued) - Separate stats tracking: stops counter distinct from panics - 12 new behavioral tests, 82 total passing Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2.3 KiB
Plan: You are to improve this codebase via: - investigating similar codebases - identifying and summarizing their design decisions when compared to swactor: - runtime engine - benchmarking - testing - overall performance - etc. - implementing improvements based on your anaylsis
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.
- 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.
- 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 related codebase and a concept to execute (benchmarks, test coverage, engine performance under various scenarios) - compare to swactor - make analysis - implement plan - execute - evaluate - 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