用途
本技能是 Event Modeling 流程的第 7 步，目的是使用 Given-When-Then（GWT / Gherkin）格式细化场景，从而指定命令（Command）与视图（View）的行为。每个规格（spec）严格绑定到一个命令或一个视图。
它属于事件建模后期工作：在事件时间线与系统边界完成后，为每个命令和视图编写可验证的行为场景，作为实现与测试的依据。
主要能力
1. 命令场景（Command Scenarios）
指定命令行为，覆盖成功创建、输入校验失败、状态违规等情况。示例包括：
- 成功创建订单：校验订单创建、总价计算，并产出 OrderCreated 事件。
- 拒绝无效客户：命令被拒绝，原因 "Customer not found"，不产出事件。
- 拒绝空条目：拒绝原因 "Order must contain items"，不产出事件。
- 拒绝无效地址：拒绝原因 "Invalid shipping address"，不产出事件。
状态验证场景包括：
- Draft 状态下确认订单，产出 OrderConfirmed 事件。
- 拒绝重复确认已确认订单，原因 "Order already confirmed"。
- 拒绝确认已取消订单，原因 "Cannot confirm cancelled order"。
2. 视图场景（View Scenarios）
指定读模型（read model）如何展示数据，包括：
- 创建后显示订单信息（Order ID、Status、Total、Items、Created）。
- 确认后更新状态（Status、Confirmed Date）。
- 累积支付信息（Payment ID、Auth Code、Payment Status）。
3. 错误路径场景
指定系统如何应对失败，例如：
- 支付被拒时产出 PaymentFailed 事件（含 orderId、reason、timestamp）。
- 支付失败时更新订单视图（Payment Status、Failure Reason、Retry Available）。
- 支付失败后允许重试，新的授权支付命令可被接受并产出新的 PaymentAuthorized 事件。
4. 补偿场景
指定回滚 / 取消流程，例如：
- Draft 状态下取消订单，产出 OrderCancelled 事件。
- 已送达订单不可取消，拒绝原因 "Cannot cancel delivered order"。
- 取消时触发补偿：Confirmed 状态且存在 PaymentAuthorized 事件时，自动触发 RefundPayment 命令，随后是 RefundInitiated 事件。
使用方式
可选访谈阶段（Interview Phase）
当用户已明确以下内容时可跳过访谈：场景覆盖深度（正常路径 + 校验 + 状态违规）、需包含的已知边界情况、可参与评审的干系人。当覆盖目标不清晰或边界情况尚未识别时进行访谈。
关键问题包括：
- 场景深度与覆盖目标：仅正常路径 + 基本校验，还是所有命令变体，还是包含边界与错误路径的全面覆盖。
- 关键边界情况与业务规则：例如 "24 小时内订单取消"、"支付失败恢复"。
- 测试与自动化策略：自动化测试、手工 QA 参考，还是仅文档。
- 干系人评审与验证：产品负责人、QA / 测试、多角色，还是仅工程团队。
访谈流程分为两阶段：第一阶段覆盖规划（问题 1–2），确定深度与关键边界情况并建立优先级；第二阶段实现与评审（问题 3–4），决定自动化或文档化、确认干系人可用性并规划评审工作流。
访谈结论会写入项目事件建模文件：
.trogonai/interviews/[project-name]/EVENTMODELING.md
其中包含第 9 节 Scenarios，记录覆盖目标、关键边界情况、需要场景的业务规则、测试策略、评审与验证、关键场景规格，并附验证与完整性检查清单（字段可追溯、事件不可变、状态投影确定性、模型可代码生成）和访谈记录表。
工作坊引导（Workshop Facilitation）
场景通常在多干系人协作工作坊中创建。参与角色包括：产品负责人 / 领域专家、开发者、QA / 测试、引导者。准备工作包括白板或协作工具（Miro、Figma 等）、便签或数字卡片、已完成的事件时间线与系统边界、每个命令 / 视图的时间盒计时器。
每个命令 / 视图的快速循环约 15–20 分钟，顺序为：
- 先写正常路径（产品负责人主导）。
- 校验失败情况（开发者 / QA）。
- 状态违规情况（领域专家）。
- 替代路径（产品负责人）。
- 错误处理，如外部系统失败（开发者），覆盖支付被拒、库存不足、恢复 / 重试。
- 补偿，是否可撤销（领域专家），覆盖取消、冲正、退款，常能揭示缺失事件。
目标为每个命令 3–5 个场景，每个命令 10–20 分钟。多角色实时评审，各角色分别检查业务行为正确性、可实现性、可测试性与细节充分性。
输出格式
按领域输出：
# Scenarios: [Domain Name]## Commands，每个命令含描述与若干场景，使用 gherkin 代码块（Given / When / Then）。## Views，含视图描述与初始显示、更新、累积数据等场景。## Error Paths，错误路径场景。## Compensation Flows，补偿流程场景。
适用场景
- 事件建模后期的行为规格化。
- 需要把业务规则转化为可验证场景（成功与失败）。
- 为自动化测试、手工 QA 参考或纯文档提供场景文本。
- 通过多角色工作坊快速产出场景并暴露缺失事件。
限制与注意事项
资料中列出的常见工作坊错误包括：追求完美（不要在单个场景上花 30 分钟）、缺少角色、过于技术化（应使用领域语言而非代码）、Given 不完整（如 "Given an order" 太模糊，需指定状态）、事件不清晰（每个场景必须展示产出什么事件，或为什么没有事件）。
关于测试框架、具体平台、收费与价格、效果数据、可用的外部系统集成清单，资料未提供。