59845f4059
Docker realization (bridging simulation to real TCP): - NodeDriver (`crates/distribution/src/driver.rs`): bridges DistributedNode tick loop to TcpTransport with piggyback-extended wire messages - swactor-node binary (`crates/node/`): CLI node with --listen, --seed, --dashboard-port, --actors flags - Dockerfile: multi-stage build (rust:1.93-slim → debian:bookworm-slim) - Docker integration tests (`tests/docker/`): 5-node cluster with 4 scenarios (convergence, failure detection, actor resolution, rejoin) - LAN cluster scripts for cross-machine validation - TCP transport retry-on-stale-connection logic - /api/distribution REST endpoint on dashboard (feature-gated) - Piggyback fields (piggyback + from_addr) on Ping/Ack/PingReq messages Docs reorganization: - docs/runtime/ — actor-model, runtime, worker-thread, channels - docs/distribution/ — distribution, swim, kademlia, transport - docs/diagrams/ — all SVG files - docs/connectome/ — connectome analysis - docs/development_history/ — DOCKER_REALIZATION.md, SIMULATION_TESTING.md - render_docs.sh outputs to docs/diagrams/ - README links updated to new paths Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2.8 KiB
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