feat(agents): Event Storming coaching capabilities for HVE Core

Overview

Bring Event Storming (ES) coaching capabilities to HVE Core, modeled on the existing
dt-coach agent (#563 Design Thinking coaching capabilities for HVE Core
). Event Storming is a widely-used
collaborative modeling technique for discovering domain events, aggregates, and
bounded contexts — it fits naturally as a companion or alternative entry point to
Design Thinking, feeding into the same RPI (Research, Plan, Implement, Review)
pipeline.

Motivation

• No HVE Core agent currently addresses domain discovery / event-driven modeling.
  DT Coach covers human-centered problem framing; ES Coach would cover the
  domain-modeling side once a problem is validated (or standalone, for teams
  starting from a known domain rather than a fuzzy user problem).
• Teams doing DDD/event-sourcing work today have to run Event Storming sessions
  outside Copilot and manually transcribe results into specs — an ES Coach agent
  could run the session interactively and produce structured handoff artifacts
  directly.

Proposed approach (mirrors dt-coach)

• Agent: es-coach — guides a session through the classic Event Storming
  phases/levels (reusing the Think/Speak/Empower coaching philosophy from DT Coach):
  1. Big Picture — chaotic exploration: domain events, actors, timeline
  2. Process Modeling — commands, policies, read models, hotspots
  3. Software Design — aggregates, bounded contexts, context map
• Session state persisted the same way as DT Coach:
  .copilot-tracking/es/{project-slug}/coaching-state.md
• Coach never prescribes the model — it facilitates (asks questions, surfaces
  conflicting events, flags hotspots) rather than generating the domain model itself.
• Exit points produce structured handoff artifacts (event catalog, aggregate
  boundaries, context map) that feed into rpi-research the same way DT's
  Problem Statement / Concept Validated / Implementation Spec handoffs do.
• Could optionally reuse/extend the existing C4 notation work (architecture-diagrams
  skill) for rendering the resulting context map.

Open questions

• Standalone plugin (plugins/event-storming/) vs. extending design-thinking
  plugin with an ES track alongside DT's 9 methods?
• Should ES Coach be positioned as pre-DT (domain discovery before problem
  framing), post-DT (solution space → domain model), or independent, given
  teams enter at different points?
• Reuse DT Coach's session-state format as-is, or define an ES-specific schema
  given events/aggregates ≠ DT's problem/solution artifacts?

References

• DT Coach agent: docs/design-thinking/dt-coach.md
• DT Coach epic: #563
• DT/RPI integration contract: docs/design-thinking/why-design-thinking.md

Start by reading docs/design-thinking/dt-coach.md and docs/design-thinking/why-design-thinking.md, then compare the proposed ES phases, session state, and RPI handoffs with the existing DT Coach. Resolve the open questions about plugin placement, lifecycle position, and state schema before defining the implementation scope. Done means the scope and integration contract for an ES Coach are agreed.