Reassess v0.5 roadmap comparing with Actor frameworks

[ElFantasma]

After completing Phase 1 (API alignment + Actor rename), reassess the remaining phases by comparing spawned's design with established Actor frameworks:

Frameworks to analyze:

• Erlang/OTP - The original: gen_server, supervisors, gen_statem, applications
• Akka (Scala/Java) - Actor model with typed actors, persistence, clustering
• Orleans (C#/.NET) - Virtual actors, automatic activation/deactivation, grains
• Pony - Reference capabilities, deny capabilities for data-race freedom
• Proto.Actor (Go/C#) - Cross-platform actors inspired by Akka
• Actix (Rust) - Actor framework for Rust with Tokio
• Bastion (Rust) - Highly-available distributed fault-tolerant runtime
• Lunatic (Rust/Wasm) - Erlang-inspired runtime for Wasm

Questions to answer:

1. Are Phases 2-5 aligned with industry best practices?
2. What features do we need that we're missing?
3. What features should we deprioritize?
4. Are there better design patterns we should adopt?
5. How does our API compare ergonomically?

Deliverable: Updated roadmap with adjusted priorities based on findings.

Blocked by: Phase 1 completion

[ElFantasma]

Issue Resolved

Framework comparison analysis complete. Deliverables:

1. PLAN.md Created

Project roadmap document added at repository root containing:

• Current status (Phase 1 complete)
• Framework comparison table (Erlang/OTP, Akka, Orleans, Actix, Ractor)
• Critical API issues identified
• Phase priority recommendations
• v0.6+ considerations

2. Issues #144 and #145 Identified

Two API design issues should be prioritized before Phase 2:

• Circular dependency problem with bidirectional actor communication #145 - Circular dependency with bidirectional actors
• Improve type safety for request/reply message handling #144 - Type safety for request/reply

These affect the core API and would be breaking changes if addressed later.

3. Issue #138 Updated

Added detailed comment with framework analysis summary and recommended priority ordering.

Conclusion

Phases 2-5 are correctly prioritized and align with industry best practices (following Erlang/OTP's evolution). The main recommendation is to address issues #144 and #145 first, as they are foundational API design concerns.