swactor/CLAUDE/TASK.md

Plan:
    You are to improve this codebase via:
        - implementing the features found in `docs/os-design`
        - writing comphrehensive tests that check behavior makes sense

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 an item to implement from the os-design docs
        - make analysis
        - implement plan
        - execute
        - evaluate
        - compress and move on to the next item

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
feat: actor watching — local death notifications Add watch/unwatch API to the actor system so actors can monitor each other's liveness. When a watched actor dies (panic or stop), watchers receive an ActorExited notification via on_actor_exit(). - ExitReason enum (Stopped, Panicked, NodeDown) and ActorExited struct - ContextInner::watch()/unwatch() + Ctx typed wrappers - ActorInterface::on_actor_exit() default method (system message fallback) - WatchRegistry in worker with bidirectional tracking - Death notification dispatch as phase 5b in tick_once - Runtime-level watch for external callers - 10 behavioral tests in tests/watch_api.rs - Design documents for OS features in docs/os-design/ Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> 2026-02-12 17:44:06 +00:00			`Plan:`
			`You are to improve this codebase via:`
			- implementing the features found in `docs/os-design`
			`- writing comphrehensive tests that check behavior makes sense`

			`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 an item to implement from the os-design docs`
			`- make analysis`
			`- implement plan`
			`- execute`
			`- evaluate`
			`- compress and move on to the next item`

			`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`