event-architecture-plannerlisted

# Event Architecture Planner ## Purpose Determine whether the project actually needs event architecture, and if it does, produce the smallest honest event model before implementation details drift. ## Core Rule Do not force a full event bus into every project. Do force explicit event thinking when the project has enough async or multi-consumer pressure that silence would create hidden coupling and painful rework later. ## Required Outputs ### `Event-Architecture.md` Required when event relevance reaches the minimum threshold. Minimum contents: - why events exist in this project - chosen topology - producer and consumer map - delivery expectations - failure handling expectations - correlation strategy - observability basics ### `Event-Catalog.md` Required when event complexity is high enough to justify multiple named events. Minimum contents: - event name - producer - consumers - trigger - business meaning - idempotency note ### `Event-Contracts.md` Required when event complexity is high enough to justify durable contracts. Minimum contents: - payload schema - metadata fields - versioning note - correlation ID - causation ID guidance - timestamp expectations ## Decision Policy - If event relevance is below threshold, explicitly record that event architecture is not justified yet. - If relevance reaches threshold, `Event-Architecture.md` becomes mandatory before leaving blueprint. - If complexity is higher, also require `Event-Catalog.md` and `Event-Contracts.m