用途
该技能用于把领域分析转化为事件溯源（Event Sourcing）架构模型。它设计事件溯源的领域模型，将业务流程映射为不可变事件与状态投影。其核心立场是：事件是唯一事实来源，状态由事件派生。
主要能力
- 设计事件流：每个流围绕一个实体，包含不可变事实事件，事件类型使用过去时（如 Created、Confirmed、Shipped），事件数据由命令输入与隐式流状态上下文组成。
- 设计命令状态读模型：每个命令拥有独立的最小状态投影，命名约定为 [CommandName]State（已实现）与 [CommandName]StateToDo（计划中）。不同命令使用不同读模型接口，禁止共享。
- 设计命令：命令代表 UI 或处理器的意图数据，可被拒绝，仅 UI 或处理器可发出命令，命令针对流状态进行校验，成功则产生事件，失败则拒绝且不产生事件。
- 设计读模型：读模型是面向 UI/处理器查询的事件投影，可随时从事件重建，与命令校验状态严格分离。
- 记录事件因果与状态转换：展示命令到事件的流转关系，以及有效状态转换、不可能转换与拒绝条件。
- 可选访谈阶段：当用户未提供流标识策略、命令特定状态需求与读模型需求时，通过访谈确认流标识与每命令状态边界。
使用方式
技能按以下流程工作：
- 判断是否需要访谈。若用户已提供流标识、至少两个命令的不同状态需求、读模型需求，则跳过访谈直接设计；否则进行访谈。
- 访谈阶段确认流标识（哪个实体拥有事件、生命周期）与最小状态 vs 捆绑状态（不同命令是否需要不同状态）。
- 将访谈发现写入项目的事件建模文件：.trogonai/interviews/[project-name]/EVENTMODELING.md。
- 依次设计事件流、命令状态读模型、命令、读模型，并记录事件因果与状态转换。
- 按指定输出格式呈现完整模型，包括事件流、命令、读模型与实现说明。
核心架构规则：绝不使用 DDD 聚合根（捆绑状态）进行命令校验。每个命令处理器拥有自己的最小状态投影。DDD 所称的“聚合根”实际上是读模型，而非命令校验状态。
适用场景
- 需要将领域分析转化为事件溯源架构的建模工作。
- 需要避免在事件溯源模型中出现 DDD 聚合反模式的场景。
- 需要为每个命令定义最小、命令特定状态投影的设计。
- 需要区分命令校验状态与查询读模型的事件溯源系统。
限制
- 该技能不涉及具体编程语言或框架的实现细节，仅提供建模与设计方法。
- 访谈阶段为可选，仅在流边界或状态设计不清晰时进行。
- 关于收费、价格、平台支持等信息，资料中暂未提供。