glm-5.1
5c820a41e9
Add 10 new tasks under tasks/architecture/ for Phase 0a (ADR writing): - 9 ADR tasks (026-034) with dependency-ordered structure - 1 review checkpoint task before Phase 0b spec writing ADR dependency graph (3 generations): Gen 1 (parallel): 026, 029, 030, 031, 032, 034 Gen 2 (depends on 029): 027, 028 Gen 3 (depends on 027+028): 033 Gen 4: review checkpoint Also mark all 34 prior implementation tasks as completed — they were finished but still showing as pending in the taskgraph.
2.0 KiB
2.0 KiB
id, name, status, depends_on, scope, risk, impact, level
| id | name | status | depends_on | scope | risk | impact | level |
|---|---|---|---|---|---|---|---|
| architecture/adr-032-event-boundary-discipline | Write ADR-032 — Event boundary discipline | pending | single | low | project | implementation |
Description
Write ADR-032 establishing event boundary discipline as a hard architectural constraint.
The research (services.md, storage.md) identifies three distinct communication patterns with clear boundaries:
- Domain events (Honker streams) — internal to the owning service, for state reconstruction. Never cross service boundaries without projection.
- irpc service calls — synchronous request-response, within a node or cluster. Internal to the system.
- Call protocol events (EventEnvelope) — cross-node, cross-language integration events. These are what cross boundaries.
The ADR must state this as a hard constraint, not a suggestion. Conflating these three patterns is an anti-pattern that leads to leaky event stores and coupling.
Acceptance Criteria
docs/architecture/decisions/032-event-boundary-discipline.mdexists- ADR follows established format (Status, Context, Decision, Consequences, References)
- Context explains the three patterns and why conflating them is harmful
- Decision states: domain events stay within the owning service; irpc calls are synchronous internal boundaries; call protocol events are the only events that cross node boundaries; projection from domain events to integration events is required when crossing boundaries
- Consequences include: prevents leaky event stores, services are independently deployable, Honker and irpc are implementation details not exposed across boundaries
- References: research/services.md, research/storage.md, integration-plan.md
References
- docs/research/services.md — event boundary discipline section
- docs/research/storage.md — Honker integration, event boundaries
- docs/research/integration-plan.md — ADR 032 entry
Notes
To be filled by implementation agent
Summary
To be filled on completion