Error Recovery: Re-decide Event-Manager-plugins vs dedicated Error Manager

[RyanTheRobothead]

DECISION CARD (Post-1.0). Through 1.0, all recovery + notification work ships as EventHandler plugins inside Event Manager (the PR #312 foundation). Post-1.0, re-decide whether to promote into a dedicated madsci.error_manager service, with real operational data instead of speculation.

What to evaluate when revisiting:

• Plugin codebase size — if event_handlers/ has grown into a meaningful subsystem (>~5 substantial handlers, complex shared infrastructure), service extraction starts paying for itself
• Event Manager restart frequency caused by plugin issues — if non-trivial, blast-radius isolation matters and a separate service wins
• Scaling pressure mismatch — if event ingestion and handler execution want different deployment topologies (e.g., agentic troubleshooters needing dedicated workers/GPU), they want different services
• Error-lifecycle UX demand — if operators are routinely asking for ack/assign/comment/close workflows on errors as distinct artifacts from the underlying events, that's the signal for a dedicated service with its own data model
• Whether agentic troubleshooters (issue Feature: Error Manager Service #247) are actually on the roadmap — they justify a dedicated service almost on their own

If revisited and the answer is 'promote to a service':

• Plugins move from event_manager.event_handlers to error_manager workers, consuming events via subscription rather than inline call
• AbstractEventHandler contract (locked by 1.0 API: AbstractEventHandler plugin contract as public-API commitment #339) is the migration boundary — well-factored handlers move with minimal change
• error_manager owns its own data model for error lifecycle (new/ack/investigating/resolved/recurring), pattern detection, dashboard view

If revisited and the answer is 'stay plugins':

• Close issue Feature: Error Manager Service #247 with a note redirecting to event_handlers as the canonical surface
• Document that 'error management' in MADSci is the event manager's plugin ecosystem, not a separate service

---

Roadmap metadata

• Phase: 1.1 — Near-term Post-1.0
• Project: Advanced Error Recovery
• Blocked by: Error Recovery: Deterministic condition→action rule engine (as EventHandler plugin) #321, Error Recovery: Recovery workflow framework + retry/cooldown/circuit-breaker primitives #322, Error Recovery: Additional notification handlers (Slack/webhook) + criteria-rich dispatch #323, 1.0 API: AbstractEventHandler plugin contract as public-API commitment #339
• Blocks: Feature: Error Manager Service #247

Generated as part of the MADSci → 1.0 roadmap. See docs/roadmap.md for context.