# Phase 1.1: Hexagonal Architecture - Context

**Gathered:** 2026-01-30
**Status:** Ready for planning

<vision>
## How This Should Work

Event bus is the backbone of the architecture. Modules communicate through events, not direct calls — server, process, logging all decoupled and talking through a central event system.

This isn't just about clean code. It's preparing the nervous system for when agents exist. When you have multiple agents spawning, coordinating, merging work — those are all events flowing through the system. Get the pattern right now while it's simple.

The CLI talks to the server through tRPC. Type-safe, clean contract. Same interface whether it's CLI or future WebUI.

</vision>

<essential>
## What Must Be Nailed

- **Extensible event bus** — In-process EventEmitter abstracted behind an interface. Must be swappable for external systems (RabbitMQ, Knative Eventing) later. Ports/adapters applied to the event infrastructure itself.
- **Tests pass** — Everything from Phase 1 has test coverage. Can't refactor without a safety net.
- **tRPC contract** — CLI-server communication pattern established with type safety.

</essential>

<specifics>
## Specific Ideas

- Start with Node EventEmitter, abstract behind an interface — simplest swap path to external event systems
- Ports/adapters structure: `adapters/in.<name>/`, `adapters/out.<name>/`
- Event dispatcher is itself a port — can swap implementations without touching core logic

</specifics>

<notes>
## Additional Context

This is a retrofit of Phase 1 code, not a greenfield build. The existing server, process management, and logging all need to be refactored to use the event bus pattern.

Priority is establishing the extensible event pattern correctly — this is the foundation for multi-agent coordination in later phases.

</notes>

---

*Phase: 1.1-hexagonal-architecture*
*Context gathered: 2026-01-30*
