scenario-rehearsal
通过模拟真实使用场景验证可行性，支持四类推演对象：设计文档（设计点可行性）、需求文档（完整性/一致性/验收可达）、Skill（触发准确性等质量维度）、代码（纸上执行追踪状态演进）。触发："推演一下这个设计/需求/skill/代码"、"模拟跑一下这个函数"、"桌面走查"，或 design-craft 完成后自动触发。
SKILL.mdskills/scenario-rehearsal/SKILL.md
GitHub场景推演器
概述
目的：在技术设计完成后、开发之前，或 Skill 编写后、发布前，或代码编写后、运行之前，通过模拟真实使用场景验证设计/Skill/代码的可行性
核心价值：提前发现设计/Skill 中的盲点和潜在问题，避免开发后返工或 Skill 发布后效果不佳
与数据流图的本质区别：
| 维度 | 数据流图 | 场景推演 |
|---|---|---|
| 关注点 | 数据走向（从哪来、到哪去） | 数据走向 + 关键设计点实现 |
| 内部实现 | 不关心 | 关注设计文档中的关键设计点 |
| 验证目标 | 数据结构和流向是否正确 | 关键设计在真实场景中是否可行 |
| 分析粒度 | 组件级 | 角色 + 场景 + 设计点 |
输入：
- 设计文档模式：技术设计文档（DESIGN.md）+ 需求文档（requirement.md）+（可选）数据流图（data-flow.md）
- 需求文档模式：仅需求文档（requirement.md），设计尚未开始，无 DESIGN.md
- Skill 模式：Agent Skill 文件（SKILL.md）+（可选）关联资源文件（reference.md、strategies/ 等）
- 代码模式：代码文件/函数/diff +（可选）关联需求或设计文档（作为预期终态的依据）
输出：
- 直接展示推演结果
- 项目配置了
.requirements/config且关联了 REQ 时，同时落盘review/scenario-rehearsal.md并注册文档关联（见阶段 5.2）
何时使用
仅在以下情况使用本 skill：
设计文档模式（默认）：
- 技术设计文档已完成（design-craft 阶段 5 落盘后）
- design-review 评审已通过（建议）
- 用户希望在开发前验证设计可行性
需求文档模式：
- 仅有需求文档（requirement.md），设计尚未开始
- 用户希望在动手写设计前，先验证需求是否自洽、无缺口、验收可达
- 典型时机：requirement-mining 产出需求后、design-craft 之前
Skill 模式：
- Skill 编写或修改完成后，希望验证其质量
- 用户希望验证 Skill 的触发准确性、指令完整性、示例质量
- 典型时机：create-skill 完成后、skill 更新后、skill 评审时
代码模式：
- 代码编写或修改完成后，想知道"某个具体场景在这段代码上走下来会发生什么"
- 静态审查（code-review / challenger）之外，需要沿时间轴正向模拟执行、追踪状态演进时
- 典型时机：编码完成后按需触发；审查报告存在
[需运行验证]存疑项，想先低成本把存疑点具体化为场景实例时
触发短语：
- 设计模式："推演一下这个设计"、"验证设计方案"、"模拟用户使用流程"、"scenario rehearsal"、"walkthrough"
- 需求模式："推演一下这个需求"、"验证需求场景"、"需求走查"、"requirement rehearsal"
- Skill 模式："推演一下这个 skill"、"验证 skill 质量"、"模拟 skill 使用"、"skill rehearsal"
- 代码模式："推演一下这段代码"、"模拟跑一下这个函数"、"这个输入进去会怎样"、"桌面走查"、"trace 一下"、"code rehearsal"
前置依赖：
- 设计文档模式：已完成 design-craft（有技术设计文档）；data-flow-model 可选
- 需求文档模式：已完成 requirement-mining（有需求文档）
- Skill 模式：已完成 create-skill 或 skill 手动编写（有 SKILL.md 文件）
- 代码模式：已有可读的代码（文件/函数/diff）；关联需求/设计文档可选（用于确定预期终态）
核心原则
- 角色驱动：以执行者为入口，每个角色独立推演
- 双重验证：既要验证数据走向，也要验证关键设计点实现（设计模式）；验证 Skill 质量（Skill 模式）；验证执行轨迹与终态（代码模式）
- 场景覆盖：正常路径 + 异常路径 + 边界场景
- 问题导向：只记录问题，不修改设计文档/Skill
- 置信度标注：技术挑战标注置信度，低置信度降级为"建议"
- 策略驱动：按设计特征自动多选启用推演策略 profile，验证维度精选+加压，避免一刀切
- 可视化输出：核心场景推演路径默认用 🕸 文字树（渲染无关），协作时序与问题分布按需用 mermaid 增强，问题一目了然
- 证据性质诚实：推演是推理不是执行——结论一律表述为"推演通过（未实际执行）"，不得表述为"验证通过/已验证"；需要执行性证据时，在下一步建议中提示走 demo-verify / e2e-testing
- 全局视角先行：推演前先建立全局图景（功能的业务目标、在系统中的位置、上下游依赖、整体成功判据），每个局部场景的推演结论必须回扣全局目标——局部通过但破坏整体目标/其他场景前提的，按 🔴 记录，不得因局部正确而放行
工作流总览
阶段 0：对象类型识别 + 全局理解 → 判定推演对象：设计文档 / 需求文档 / Skill / 代码；先立全局图景再拆场景
阶段 1：角色识别 → 按对象类型从设计文档/需求文档/Skill/代码提取所有执行者角色
阶段 2：场景提取 + 策略识别 → 按对象类型提取场景；设计模式多选启用 profile，需求模式用需求质量维度，Skill 模式用 Skill 质量维度，代码模式用场景实例化 + 代码推演维度
阶段 3：推演执行 → 按角色走完整流程，按对象类型验证设计点/需求质量/Skill 质量，双重验证；每场景结论回扣全局目标
阶段 4：问题汇总 → 按严重度分级，按类型分类
阶段 5：结果展示 → 直接展示推演结果（含 🕸 文字树，mermaid 可选增强），与需求管理集成
各阶段顺序执行，阶段 3 的验证结果在阶段 4 统一输出。
确认交互为非阻塞：阶段 1/2 输出中的"请确认…"提示不中断推演——展示后即可继续下一阶段，用户可随时纠正并触发局部重推；仅当关键信息缺失且直接影响推演结论时才中断等待。自动触发链路（如 design-craft 完成后）不产生确认中断。
阶段 0：对象类型识别 + 全局理解
推演开始前先判定对象类型，决定后续所有阶段走哪条分支。
| 对象类型 | 判定依据 | 后续分支 |
|---|---|---|
| 设计文档 | 输入含技术设计文档（DESIGN.md） | 走设计文档模式：阶段 1~3 验证设计点，阶段 2.4 启用设计 profile |
| 需求文档 | 输入仅有需求文档（requirement.md），无 DESIGN.md | 走需求文档模式：阶段 1~3 验证需求质量，使用 strategies/requirement.md 维度 |
| Skill | 输入含 SKILL.md 文件，用户明确要求推演 skill | 走 Skill 模式：阶段 1~3 验证 Skill 质量，使用 strategies/skill.md 维度 |
| 代码 | 输入为代码文件/函数/diff，用户要求推演/模拟执行/走查代码 | 走代码模式：阶段 1~3 对场景实例做纸上执行，使用 strategies/code.md 维度 |
四种模式的本质区别：
| 维度 | 设计文档模式 | 需求文档模式 | Skill 模式 | 代码模式 |
|---|---|---|---|---|
| 验证目标 | 设计点在真实场景中是否可行 | 需求是否自洽、无缺口、验收可达 | Skill 触发准确性、指令完整性、示例质量、工作流合理性 | 代码在具体场景实例下的实际行为是否符合预期终态 |
| 数据走向 | 验证数据从创建到消费的链路 | 仅当需求描述了数据流时验证；否则跳过 | 不验证数据走向；验证 Skill 引用的资源完整性 | 验证运行时状态演进（变量/资源/副作用轨迹） |
| 验证维度 | 设计点维度（3.2）+ 设计 profile 加压 | 需求质量维度（见 strategies/requirement.md） | Skill 质量维度（见 strategies/skill.md） | 代码推演维度（见 strategies/code.md） |
| 触发时机 | design-craft 之后 | requirement-mining 之后、design-craft 之前 | create-skill 之后、skill 更新后 | 编码完成后按需触发（不自动接入审查链） |
| 执行者 | 用户角色 + 自动化程序 | 用户角色 | AI 系统 | 调用方角色 + 环境角色 |
若用户同时给了需求文档和设计文档，默认走设计文档模式（设计已存在，需求推演价值已部分被设计吸收）；如用户明确要"先推演需求"，则切需求模式。 若用户明确要求推演 Skill（输入含 SKILL.md），则走 Skill 模式，无论是否还有其他文档。 若用户明确要求推演代码（输入为代码/diff），则走代码模式；随附的需求/设计文档仅用作预期终态依据，不切换模式。
输出：
🎯 推演对象识别
━━━━━━━━━━━━━━
- 对象类型：需求文档模式（输入仅 requirement.md，设计未开始）
- 后续分支：阶段 1~3 验证需求质量，不验证设计点
Skill 模式示例：
🎯 推演对象识别 ━━━━━━━━━━━━━━ - 对象类型：Skill 模式（输入含 SKILL.md，用户要求推演 skill） - 后续分支：阶段 1~3 验证 Skill 质量，使用 strategies/skill.md 维度
0.1 全局理解（拆场景之前必做）
拿到文档后不要直接开始拆角色/拆场景，先通读文档建立宏观图景——否则各场景各推各的，容易陷入"每个局部都对、拼起来却是致命错误"。输出一份简短的全局理解声明：
代码模式辅助——强关联关系查询：理解"系统位置"（上游/下游依赖）时，若推演对象是代码，可调用 use_skill("ki-memory-lookup") 检索相关模块的强关联关系（跨模块契约/业务耦合），作为系统位置/模块间牵动的补充依据（查询失败或无可用记录，忽略继续）。
| 理解项 | 回答的问题 | 各模式含义 |
|---|---|---|
| 业务目标 | 这个功能/需求/Skill 整体要达成什么？用一句话说清 | 设计：方案服务的业务目的；需求：用户真实诉求；Skill：该 skill 在技能体系中的职责 |
| 系统位置 | 它在更大的系统/流程中处于什么位置？上游谁产生输入、下游谁消费输出？ | 设计：模块上下游依赖；需求：与其他需求/存量功能的关系；Skill：与其他 skill 的调用/接力关系 |
| 整体成功判据 | 什么情况下算"整体成功"？哪些全局约束不可破坏（如数据一致、权限不旁路、性能底线）？ | 后续所有局部场景结论的回扣基准 |
🌍 全局理解声明
━━━━━━━━━━━━━━
- 业务目标：{一句话}
- 系统位置：上游 {X} → 本功能 → 下游 {Y}
- 整体成功判据：{全局约束清单，后续场景逐个回扣}
文档信息不足以回答三项时，标注
[全局信息缺失]并在推演结论中声明"全局回扣受限"；这本身就是一个 🟡 问题（文档未交代全局图景）。
阶段 1：角色识别
从设计文档/需求文档/Skill 中提取所有参与交互的执行者角色。
角色分类
| 类型 | 识别方式 | 示例 |
|---|---|---|
| 用户角色 | 设计文档中的"用户"、"普通用户"、"管理员"、"运营" | 普通用户、管理员、游客 |
| 自动化程序 | 数据流图中的外部系统、定时任务、消息消费者 | 定时同步任务、Webhook 回调、消息队列消费者 |
| AI 系统（Skill 模式） | Skill 的 description 和指令中隐含的 AI 系统行为 | AI 判断是否触发、AI 执行工作流步骤、AI 生成输出 |
| 调用方角色（代码模式） | 触发这段代码执行的主体 | 用户请求、定时任务、上游服务、并发线程 |
| 环境角色（代码模式） | 会"出牌"的外部依赖（代码模式特色，review 不把依赖当角色） | 网络会超时、磁盘会满、第三方会返回乱序/错误码、时钟会回拨 |
权限层级：用户角色需进一步区分权限层级，不同层级的推演路径不同：
| 层级 | 典型角色 | 推演重点 |
|---|---|---|
| 未登录 | 游客、匿名用户 | 访问控制、登录引导 |
| 已登录 | 普通用户 | 核心功能流程 |
| 认证后 | 实名用户、绑定手机用户 | 权限提升后的功能差异 |
| 数据归属人 | 订单创建者、内容作者 | 对自己数据的操作权限 |
| 非归属人 | 同组用户、无关用户 | 对他人数据的操作限制 |
| 管理员 | 系统管理员、运营人员 | 管理功能、超权操作 |
按设计文档中实际定义的角色提取，未定义的角色层级标注"未提及"，不脑补。
识别规则
设计文档模式：
- 从设计文档提取：检查"术语"、"方案(TO-BE)"、"接口设计"章节中的角色描述
- 从需求文档提取：检查"用户角色"、"使用场景"中的角色定义
- 从数据流图提取：检查数据流的起点（触发者），识别自动化程序角色
需求文档模式：
- 从需求文档提取：检查"用户角色"、"使用场景"、"功能需求"中的角色定义（主要来源）
- 设计文档/数据流图不存在，不提取；自动化程序角色仅当需求中明确提及时纳入
Skill 模式：
- AI 系统是核心执行者：Skill 的工作流步骤由 AI 系统执行
- 用户（触发者）：用户的输入触发 Skill 的判断与应用，推演需覆盖"用户输入 → AI 判断是否触发 → AI 执行工作流 → 生成输出"完整链路
- 从 Skill 文件提取：检查 SKILL.md 的 description、指令、工作流，提取 AI 需要扮演的角色/行为以及用户可能的触发输入模式
代码模式：
- 调用方角色：从函数签名/调用点/入口推断谁会触发这段代码（同步调用方/定时触发/并发调用者），不同调用方携带不同输入域与时序
- 环境角色：识别代码依赖的外部实体（网络/磁盘/DB/第三方 API/时钟/锁），并假设它们会以失败/慢/乱序的方式"出牌"——这是代码推演区别于静态审查的核心
- 从代码提取：通读目标代码，识别入口参数、分支条件、外部调用点、共享状态，作为阶段 2 场景实例化的原料
输出格式
👥 角色清单
━━━━━━━━━━━━━━━━
| # | 角色 | 类型 | 权限层级 | 职责 | 来源 |
|---|------|------|---------|------|------|
| 1 | 普通用户 | 用户 | 已登录 | 注册、登录、使用核心功能 | 设计文档 §术语 |
| 2 | 管理员 | 用户 | 管理员 | 后台管理、审核、配置 | 设计文档 §方案 |
| 3 | 定时任务 | 程序 | — | 每日数据同步 | 数据流图 |
| 4 | 支付回调 | 程序 | — | 接收第三方支付结果 | 设计文档 §接口 |
请确认角色是否完整，权限层级划分是否准确，有无遗漏。
阶段 2：场景提取
从需求文档和设计文档中提取核心使用场景，并识别关键设计点。
2.1 场景提取
提取来源：
- 设计文档模式：需求文档"使用场景/验收标准" + 设计文档"方案(TO-BE)/时序图"
- 需求文档模式：需求文档"使用场景"、"验收标准"、"功能需求"（设计文档不存在，跳过）
- Skill 模式：SKILL.md 的 description（触发场景）、指令步骤（工作流场景）、示例（示例场景）
- 代码模式：场景实例化（与其他模式的本质区别）——不是抽象的"异常场景"，而是带具体值的可执行实例（如
余额=0.01，重试=3 次，网络在第 2 跳超时）；三个来源：① 输入域切分（正常/边界/非法值）② 环境状态（依赖失败/慢/乱序）③ 并发时序（指定具体交错：线程 A 在 T1 读、线程 B 在 T2 写）；每个实例推演前先声明预期终态（防止推演完后合理化结果）
场景分类：
- 核心业务场景：需求的主要功能流程
- 协作场景：需要多个角色协同完成的完整业务流程
- 异常场景：错误处理、边界情况
- 并发场景：多用户/多任务同时操作
2.2 关键设计点/Skill 质量点识别
从设计文档中提取需要验证的关键设计点（设计模式），或从 Skill 中提取需要验证的质量点（Skill 模式）：
设计文档模式 — 设计点提取：
| 设计点类型 | 提取位置 | 验证重点 |
|---|---|---|
| 关键决策点 | "关键决策点"章节 | 决策在场景中是否合理 |
| 接口契约 | "接口设计"章节 | 接口参数、返回值、异常是否满足调用需求 |
| 异常处理 | "异常处理"章节 | 异常场景下处理策略是否有效 |
| 并发策略 | "性能 & 安全"章节 | 并发场景下策略是否正确 |
| 数据约束 | "数据模型"章节 | 数据约束在业务场景中是否合理 |
Skill 模式 — 质量点提取：从 SKILL.md 的 description、指令/工作流章节、示例、资源引用、YAML 元数据中提取七个质量点（触发准确性 / 指令完整性 / 示例质量 / 工作流合理性 / 资源完整性 / AI 说明层 / 结构规范性），各质量点的验证问题与加压点见 strategies/skill.md。
代码模式 — 推演验证点提取：不提取设计点/质量点，而是以阶段 2.1 的场景实例为单位，每个实例声明：具体输入值 + 初始状态 + 环境行为（依赖是否失败/慢/乱序）+ 并发交错（如有）+ 预期终态。验证维度见 strategies/code.md。
2.3 构建推演矩阵
2.3.1 设计点覆盖矩阵
为确保每个关键设计点都在相关场景中得到推演验证，构建「设计点 × 场景」覆盖矩阵：
📋 设计点覆盖矩阵
━━━━━━━━━━━━━━━━
| 设计点 \ 场景 | 正常注册 | 重复注册 | 并发注册 |
|--------------|---------|---------|---------|
| 邮箱唯一约束 | ✅ | ✅ | ✅ |
| 验证码过期策略 | ✅ | - | - |
| 并发注册控制 | - | - | ✅ |
请确认设计点覆盖是否完整，有无遗漏的设计点。
设计点取自阶段 2.2 的关键设计点清单，每个设计点至少应有 1 个关联场景。标记为
-的设计点可能意味着该场景不需要验证，需用户确认。
2.3.2 角色场景推演矩阵
将角色和场景组合，构建推演矩阵：
📋 推演矩阵
━━━━━━━━━━━━━━━━
| 场景 \ 角色 | 普通用户 | 管理员 | 定时任务 |
|-------------|---------|--------|----------|
| 用户注册 | ✅ | - | - |
| 订单创建 | ✅ | - | - |
| 订单审核 | - | ✅ | - |
| 数据同步 | - | - | ✅ |
请确认推演矩阵是否覆盖核心场景和协作场景。
2.4 推演策略 profile 识别
按设计特征多选启用推演策略 profile。一个设计常混合多类关注点（如订单系统 = CRUD + 事务 + 并发），因此 profile 可叠加，不互斥。
候选 profile：
| profile | 启用信号（命中即启用） | 策略文件 |
|---|---|---|
| CRUD/接口类 | 接口以 CRUD 命名、RESTful 资源、列表/详情/表单 | strategies/crud-api.md |
| 事务/状态机类 | 状态机/状态流转/订单/支付/审批/事务/补偿/对账 | strategies/transaction-state-machine.md |
| 批处理/同步类 | 批处理/同步/ETL/定时任务/导出/数据迁移 | strategies/batch-sync.md |
| 实时/推送/消息类 | WebSocket/推送/通知/消息队列/订阅/实时 | strategies/realtime-messaging.md |
| 重构/迁移类 | 重构/迁移/灰度/兼容/双写/回滚/改造 | strategies/refactor-migration.md |
| 并发/竞态敏感类 | 并发/竞态/锁/原子/缓存一致性/限流/秒杀 | strategies/concurrency.md |
| Bug 修复类 | issue/bug/缺陷/故障/出错/崩溃/panic/异常/失败 | strategies/bug-fix.md |
| 新增功能类 | 新增功能/新特性/新增模块/新页面/新接口/新服务 | strategies/feature.md |
| 代码优化类 | 优化/重构/性能/可读性/可维护性/简化/提取/合并/拆分/清理/精简/高效 | strategies/optimization.md |
识别规则：
- 扫描设计文档的方案/接口/数据模型/非功能章节关键词
- 命中任一启用信号即启用对应 profile（可多选）
- 未命中任何 profile → 使用通用验证维度（3.2 全集）
- 启用的 profile 决定阶段 3 的维度精选与加压点
需求文档模式不启用上述设计 profile（无设计特征可扫描）。此时跳过本表扫描，统一使用 strategies/requirement.md 的需求质量维度全集（场景完整性 / 验收标准可达性 / 需求一致性 / 角色-需求对齐 / 边界异常覆盖 / 术语一致性），进入阶段 3 的需求质量验证。
Skill 模式不启用上述设计 profile（无设计特征可扫描）。此时跳过本表扫描，统一使用 strategies/skill.md 的Skill 质量维度全集（触发准确性 / 指令完整性 / 示例质量 / 工作流合理性 / 资源完整性 / AI 说明层），进入阶段 3 的 Skill 质量验证。
代码模式不启用上述设计 profile。此时跳过本表扫描，统一使用 strategies/code.md 的代码推演维度全集（终态正确性 / 中间态安全 / 时序鲁棒性 / 资源生命周期 / 可观测性），进入阶段 3 的纸上执行。代码模式的推演矩阵为「场景实例 × 推演维度」（而非设计点 × 场景）。
输出：
🎯 启用策略 profile
━━━━━━━━━━━━━━━━
- ✅ 事务/状态机类（命中：订单状态流转、支付）
- ✅ 并发/竞态敏感类（命中：秒杀、库存扣减）
- ➖ 未启用：批处理/同步类（无相关信号）
请确认 profile 识别是否准确，有无遗漏。
阶段 3：推演执行
按角色走完整流程，同时验证数据走向和关键设计点。
3.1 数据走向验证
设计文档模式：验证数据从创建到消费的完整链路：
| 验证项 | 检查内容 |
|---|---|
| 数据创建 | 数据是否在正确的节点创建 |
| 数据流转 | 数据是否按设计流向正确组件 |
| 数据消费 | 数据是否被正确的组件消费 |
| 新增数据贯通 | 设计新引入的数据元素（接口字段/模型字段/事件字段）是否贯通——正向：从入口到最终落点（入库/发送/返回）每一跳是否都有设计交代；反向：是否有生产方与消费方（死字段/空壳字段标 🟡 请设计方确认是否为分阶段铺垫） |
| 异常路径归宿 | 各节点失败/异常时数据的归宿是否有设计交代（重试/死信/补偿/用户提示），有无静默丢弃 |
| CRUD 一致性 | 实际操作与数据流图标注是否一致 |
需求文档模式：若需求文档未描述数据流，跳过本节；若需求描述了关键数据流（如"订单数据同步至风控"），仅验证该描述的内部一致性，不深入设计实现。
Skill 模式：不验证数据走向；改为验证 Skill 引用的资源完整性：
| 验证项 | 检查内容 |
|---|---|
| 文件存在性 | SKILL.md 引用的 reference.md、strategies/、examples.md 等文件是否存在 |
| 路径正确性 | 引用的文件路径是否正确（相对路径/绝对路径） |
| 内容一致性 | 引用文件中的内容是否与 SKILL.md 中的描述一致 |
代码模式：不验证静态数据走向，而是做纸上执行（desk check / trace）——逐步追踪每个场景实例的运行时状态演进，产出执行轨迹表：
| 步骤 | 代码位置 | 关键状态变化 | 副作用 |
|------|---------|-------------|--------|
| 1 | order.py:42 | balance: 0.01 → -9.99 | 无 |
| 2 | order.py:45 | ❌ 负数未拦截，进入扣款 | 调用支付 API |
轨迹的主干也可用 🕸 文字树表达（状态演化挂节点：
余额 0.01 → -9.99，问题点标❌，见 5.3）；表格保留，作为副作用 / 中间态字段的明细——树看主干，表看字段。
每个实例追踪完后做终态对比：预期终态 vs 推演终态，不一致即为偏差。除终态外，每一步后追问：若此步失败/进程在此崩溃，已发生的副作用留下的中间态是否一致、可恢复（中间态安全，代码模式最擅长抓的“半途而废留脏数据”）。
3.2 关键设计点验证
验证设计文档中的关键设计点在场景中的可行性：
设计文档模式 — 验证维度：
| 维度 | 验证问题 | 严重度 |
|---|---|---|
| 决策可行性 | 被选择的方案在给定场景下是否真的可行？ | 🔴 |
| 接口满足度 | 接口参数、返回值是否满足实际调用需求？ | 🔴 |
| 异常覆盖度 | 异常场景是否都有对应的处理策略？ | 🔴 |
| 并发正确性 | 并发场景下锁策略、事务边界是否正确？ | 🔴 |
| 幂等性 | 重复操作是否具有幂等保证？重复提交、消息重投是否安全？ | 🔴 |
| 数据完整性 | 数据约束是否覆盖所有业务场景？ | 🟡 |
| 边界处理 | 空输入、极大值、并发冲突等边界是否处理？ | 🟡 |
策略 profile 精选/加压：上表为通用维度全集。根据阶段 2.4 启用的 profile：
- 精选：优先验证 profile 关注的维度（非关注维度可降低优先级）
- 加压：对 profile 的"加压点"做额外深挖（见对应策略文件）
- 未启用任何 profile 时，按全集逐项验证
代码修复方向策略：当启用 Bug 修复类、新增功能类、代码优化类策略时，使用对应策略文件中的精选验证维度和加压点。这些策略特别关注：
- Bug 修复类：问题定位准确性、修复效果验证、副作用评估、意外场景概率评估
- 新增功能类：需求覆盖度、接口设计完整性、数据模型扩展性、意外场景概率评估
- 代码优化类：行为等价性、性能提升验证、复杂度评估、意外场景概率评估
需求文档模式 — 验证维度（不验证设计点）：使用 strategies/requirement.md 的需求质量维度全集——场景完整性🔴 / 验收标准可达性🔴 / 需求一致性🔴 / 角色-需求对齐🟡 / 边界异常覆盖🟡 / 术语一致性🟡，各维度的验证问题与典型缺口见策略文件。
需求模式不跑 profile 加压（无设计特征），直接按上述全集逐项验证。
Skill 模式 — 验证维度（不验证设计点/需求质量）：使用 strategies/skill.md 的 Skill 质量维度全集——触发准确性🔴 / 指令完整性🔴 / 示例质量🟡 / 工作流合理性🟡 / 资源完整性🟡 / AI 说明层🟡 / 结构规范性🟢，各维度的验证问题、加压点与输出格式调整见策略文件。
Skill 模式不跑 profile 加压，直接按上述全集逐项验证。
代码模式 — 验证维度（不验证设计点/需求质量/Skill 质量）：使用 strategies/code.md 的代码推演维度全集——终态正确性🔴 / 中间态安全🔴 / 时序鲁棒性🔴 / 资源生命周期🟡 / 可观测性🟡，各维度的验证问题与轨迹表格式见策略文件。
代码模式不跑设计 profile 加压，沿时间轴对每个场景实例逐步纸上执行，逐维度判定。
3.3 推演方式
Happy Path（正常路径）：
- 按设计预期的正常流程走完全程
- 验证核心功能是否可实现
Collaboration Path（协作路径）：
- 多个角色按时间顺序完成一个完整业务流程
- 验证角色间的衔接是否流畅、数据传递是否正确
- 典型场景：用户提交订单 → 管理员审核 → 用户收到通知
Exception Path（异常路径）：
- 模拟各种异常场景（网络超时、权限不足、数据冲突等）
- 验证异常处理策略是否有效
Edge Case（边界场景）：
- 空输入、极大值、并发冲突
- 验证边界处理是否合理
意外场景推演（Unexpected Scenario）：
- 推演真实场景中可能出现但有一定概率的意外情况
- 重点关注代码修复、新增功能、代码优化可能引发的连锁反应
- 评估意外场景的发生概率和影响程度
- 验证系统对意外场景的容错能力
3.4 单场景推演输出
🎬 场景推演：[场景名称]
━━━━━━━━━━━━━━━━
【执行者】[角色名称]
【场景描述】[一句话描述]
【数据走向验证】
| 步骤 | 操作 | 数据流向 | 验证结果 | 问题 |
|------|------|----------|---------|------|
| 1 | C: 创建用户 | 用户 → 用户表 | ✅ 通过 | - |
| 2 | C: 发送验证邮件 | 用户 → 邮件队列 | ⚠️ 存疑 | 未定义失败重试 |
> **数据守恒检查（三问+异常归宿）**（每条数据流逐跳检查）：①流向——数据去向/消费方与设计一致吗？②数量——到达消费方时有无静默增减（如过滤/异常丢弃/重复消费）？③内容——字段/精度/格式到达消费方时还是原样吗？④异常归宿——节点失败/异常时这条数据的归宿设计交代了吗（重试/死信/补偿/用户提示）？"异常则跳过"看似没毛病，静默丢弃（无记录无补偿无感知）按守恒破坏处理：最低 ⚠️（设计须补交代归宿或论证该数据可丢弃），消费端效果重大记 ❌。任一问命中变化 → 逐消费方做**效果等价性判定**：消费方拿这份数据做什么？用变化后的数据产生的效果与原来一致吗？🟰 效果一致 → ✅；🟡 影响可忽略（推演者推断，标注待确认交用户判断）→ ⚠️；🔴 影响重大（报表失真/告警漏报误报/资金偏差/不可逆丢失）→ 记 ❌ 并归入问题汇总的「数据问题」，不可逆的一律从重。
【关键设计点验证】
| # | 设计点 | 验证问题 | 验证结果 | 问题 | 置信度 |
|---|--------|---------|---------|------|--------|
| 1 | 邮箱唯一约束 | 重复注册时如何处理？ | ❌ 失败 | 设计未说明冲突提示 | 🔴 高 |
| 2 | 验证码过期策略 | 过期后能否重发？ | ✅ 通过 | 5分钟过期，支持重发 | - |
> **需求文档模式**：本节改为「需求质量验证」，列改用 strategies/requirement.md 的维度（场景完整性/验收可达性/需求一致性/角色对齐/边界覆盖/术语一致），不验证设计点。
>
> **Skill 模式**：本节改为「Skill 质量验证」，列改用 strategies/skill.md 的维度（触发准确性/指令完整性/示例质量/工作流合理性/资源完整性/AI 说明层），不验证设计点。
>
> **代码模式**：本节改为「执行轨迹表 + 终态对比」，逐步追踪代码位置/状态变化/副作用，末尾给出预期终态 vs 推演终态的对比判定（格式见 strategies/code.md），不验证设计点。
【意外场景推演】
| # | 意外场景 | 发生概率 | 影响程度 | 容错措施 | 推演结果 |
|---|---------|---------|---------|---------|---------|
| 1 | 修复导致其他模块异常 | 中 | 高 | 回归测试覆盖 | ⚠️ 存疑 |
| 2 | 新功能在并发场景下失效 | 低 | 高 | 并发测试 | ✅ 通过 |
| 3 | 优化导致性能退化 | 低 | 中 | 性能监控 | ✅ 通过 |
【推演结论】
- 数据走向：X 项通过 / Y 项存疑 / Z 项失败
- 关键设计/Skill 质量：X 项通过 / Y 项存疑 / Z 项失败
- 意外场景：X 项通过 / Y 项存疑 / Z 项失败
- 全局回扣：本场景结论放到全局目标（见 0.1 声明）下是否仍成立？是否破坏整体成功判据或其他场景的前提？✅ 成立 / 🔴 局部通过但破坏全局（说明破坏了哪条约束）
- 证据性质：推演结论（基于文档推理，未实际执行）
阶段 4：问题汇总
将阶段 3 的所有发现汇总，按严重度和类型分类。
4.1 问题分类
| 分类 | 说明 | 处理建议 |
|---|---|---|
| 遗漏场景 | 设计/需求未覆盖的使用场景 | 补充设计文档 / 需求文档 |
| 流程缺陷 | 设计流程中存在逻辑漏洞 | 修改设计方案 |
| 设计冲突 | 设计点之间存在矛盾 | 统一设计方案 |
| 数据问题 | 数据流转或约束存在问题（含守恒破坏：流向改变/数量静默增减/内容变形/异常路径静默丢弃；含贯通断链：新增数据元素某一跳缺失设计、死字段/空壳字段；严重度按消费端效果等价性定，不可逆丢失从重） | 修改数据流图或设计 |
| 全局破坏 | 局部场景推演通过，但破坏全局目标/整体成功判据/其他场景前提 | 回到全局视角重新设计，不得局部修补 |
| 需求缺口（需求模式） | 需求未定义的行为/异常/边界 | 补充需求文档 |
| 需求冲突（需求模式） | 需求条目之间相互矛盾 | 统一需求描述 |
| 触发问题（Skill 模式） | skill 的 description 无法准确触发 | 修改 description，增加触发术语 |
| 指令问题（Skill 模式） | skill 的指令不完整或模糊 | 补充指令步骤，明确边界条件 |
| 示例问题（Skill 模式） | skill 的示例不具体或不完整 | 补充具体示例，覆盖主要场景 |
| 工作流问题（Skill 模式） | skill 的工作流不合理或缺失 | 重新设计工作流，补充必要步骤 |
| 资源问题（Skill 模式） | skill 引用的资源不存在或路径错误 | 修正路径或创建缺失的资源文件 |
| 结构问题（Skill 模式） | skill 不符合标准结构 | 调整结构，符合规范 |
| 意外场景风险（代码修复方向） | 代码修复可能引发的意外场景风险 | 评估风险概率，制定应对策略 |
| 连锁反应风险（代码修复方向） | 修复可能引发的连锁反应 | 进行回归测试，评估影响范围 |
| 性能退化风险（代码优化方向） | 优化可能导致性能退化 | 进行性能测试，监控关键指标 |
| 并发场景风险（新增功能方向） | 新功能在并发场景下可能出现问题 | 进行并发测试，验证竞态条件 |
| 终态偏差（代码模式） | 推演终态与预期终态不一致 | 修正代码逻辑，使终态符合预期 |
| 中间态泄漏（代码模式） | 某步失败/中断后留下不一致或不可恢复的脏状态 | 补充事务/回滚/补偿，保证中间态一致 |
| 时序缺陷（代码模式） | 特定并发交错或外部乱序下行为错误 | 补充同步/幂等/顺序保证 |
| 资源泄漏（代码模式） | 异常路径下连接/句柄/锁未释放 | 补充 finally/defer/context 释放 |
4.2 严重度定义
| 严重度 | 含义 | 处理要求 |
|---|---|---|
| 🔴 阻断 | 设计存在重大缺陷，不修复将导致功能不可用 | 必须修复后才能进入开发 |
| 🟡 警告 | 设计存在潜在风险，可能导致问题 | 强烈建议修复 |
| 🟢 建议 | 设计可优化点，不影响功能 | 可选修复 |
4.3 输出格式
严重度必须由"功能影响"列支撑：🔴 要能从该列读出"哪个功能怎么不可用"，🟡 要能读出"可能导致什么问题"，不得仅凭问题描述定级。
📊 问题汇总
━━━━━━━━━━━━━━━━
| # | 类型 | 角色 | 场景 | 问题描述 | 功能影响（预期 → 实际） | 建议 | 严重度 |
|---|------|------|------|---------|------------------------|------|:------:|
| 1 | 遗漏场景 | 普通用户 | 注册 | 未考虑邮箱重复注册的用户提示 | 预期：重复注册时提示"邮箱已注册" → 实际：无任何提示，用户不知注册为何失败 | 补充冲突提示逻辑 | 🔴 |
| 2 | 流程缺陷 | 管理员 | 审核 | 审核拒绝后无通知机制 | 预期：被拒后用户收到原因通知 → 实际：用户无感知，一直等待审核结果 | 补充消息通知设计 | 🟡 |
| 3 | 数据问题 | 定时任务 | 同步 | 同步失败无重试策略 | 预期：失败自动重试保证最终一致 → 实际：失败数据永久缺失，下游报表少数据 | 补充重试机制 | 🟡 |
统计：
- 🔴 阻断：X 个
- 🟡 警告：Y 个
- 🟢 建议：Z 个
阶段 5：结果展示
直接展示推演结果；当项目配置了 .requirements/config 且关联了 REQ 时，同时将推演结果写入 review/scenario-rehearsal.md（见 5.2）。
5.1 展示格式
# 场景推演结果展示：{功能名称}
> 推演时间：YYYY-MM-DD
> 推演对象：{设计文档模式 / 需求文档模式 / Skill 模式 / 代码模式}
> 输入文档：{设计文档 / 需求文档 / SKILL.md / 代码文件或 diff 路径}
## 1. 全局理解声明 + 角色清单
（阶段 0.1 与阶段 1 输出）
## 2. 推演矩阵 + 启用策略 profile
（阶段 2 输出，含 2.4 profile 识别结果）
## 3. 场景推演详情
（阶段 3 输出，按场景分节；核心场景含 🕸 推演路径文字树，协作场景可选 mermaid 时序图，见 5.3）
## 4. 问题汇总
（阶段 4 输出）
## 5. 推演结论（可选 mermaid 问题分布饼图，见 5.3）
### 整体评估
- 推演覆盖：X 个角色 / Y 个场景
- 问题发现：🔴 X 个 / 🟡 Y 个 / 🟢 Z 个
### 评审结论
| 条件 | 结论 |
|------|------|
| 存在 ≥1 个 🔴阻断 | ❌ 不通过 |
| 无 🔴阻断，但存在 ≥1 个 🟡警告 | ⚠️ 有条件通过 |
| 仅存在 🟢建议或无问题 | ✅ 通过 |
> 结论均为**推演通过（未实际执行）**：基于文档推理，非执行性证据。设计中存在高风险点（未验证过的技术/API、性能敏感路径）时，在下一步建议中提示用 demo-verify / e2e-testing 获取执行性证据。
### 下一步建议
- 修复所有 🔴 阻断项后可进入开发
- 修复后建议使用增量推演模式（仅重推上一轮 🔴/🟡 问题关联的场景与设计点，其余沿用上轮结论）
5.2 需求管理集成
当项目配置了 .requirements/config 且关联了 REQ 时，推演结果展示后自动执行集成操作：
- 落盘推演结果：将阶段 5.1 的完整展示内容写入需求目录下的
review/scenario-rehearsal.md - 注册文档关联：
req update {REQ-NNN} \
--docs add review/scenario-rehearsal.md,rehearsal --changelog "完成场景推演"
- 错误处理：需求 ID 不存在或未关联 REQ → 跳过落盘与注册，仅展示推演结果
存储路径映射：
| 产出物 | 存储路径 | docs 类型 |
|---|---|---|
| 场景推演结果 | review/scenario-rehearsal.md |
rehearsal |
5.3 可视化输出规范（🕸 文字树默认 + mermaid 可选增强）
为提升展示直观性，核心场景推演路径默认用 🕸 文字树（渲染无关：聊天 / 终端 / Word / 飞书都可读），mermaid 作为渲染环境支持时的可选增强：
| 表达 | 适用场景 | 要求 |
|---|---|---|
| 🕸 文字树（默认） | 核心场景推演路径 / 代码模式执行轨迹 | 每个核心场景一棵：节点=步骤，用 ✅/⚠️/❌ 标注验证结果，问题节点标 ← ❌ 问题 |
sequenceDiagram |
协作场景（多角色按时间序） | 可选增强——多角色交互时推荐（渲染环境支持就画）：参与者=角色，消息=步骤，标注验证结果 |
flowchart TD |
核心场景推演路径（细粒度分支） | 可选增强：节点=步骤，✅/⚠️/❌ 标注，问题节点高亮 |
pie |
问题分布 | 可选：结论处一张：🔴阻断/🟡警告/🟢建议占比 |
flowchart LR |
有问题的数据走向分支 | 仅当数据走向验证发现问题时画，不画全量（避免与 data-flow-model 重复） |
🕸 文字树最小语法（跨 skill 统一，4 条）：① │+▼ 串联向下、├─ └─ 分支 / 并行；② 节点挂数字与状态（值演化 / 耗时），关键节点打标记（← ❌ 问题 / ← 待验证）；③ 并行标"（取 max）"、串行标"（串行相加）"；④ 只画结构类信息，清单仍用表格；节点 ≤15、层级 ≤4。
各
strategies/*.md的「mermaid 提示」一律按"可选增强"理解（默认先用 🕸 文字树，渲染环境支持且图更有表现力时才画 mermaid），无需逐文件改写；strategies/code.md的执行轨迹已改为文字树默认。
示例（推演路径文字树）：
{场景：用户注册}
▼
{提交表单} ✅
├─ {校验邮箱唯一} ⚠️ 未定义重复注册的提示
└─ {写入用户表} ❌ 并发下唯一约束冲突 ← ❌ 问题
▼
{发送验证邮件} ✅
示例（协作场景时序图，可选增强）：
sequenceDiagram
participant U as 普通用户
participant S as 订单服务
participant P as 支付回调
U->>S: 提交订单
S-->>U: 订单创建成功（待支付）
U->>S: 发起支付
S-->>P: 等待回调
Note over P: ⚠️ 未定义回调超时处理
P-->>S: 支付结果回调
S-->>U: ❌ 重复支付幂等未保证
示例（推演路径 flowchart，可选增强）：
flowchart TD
A[创建订单] -->|✅| B[扣减库存]
B -->|❌ 并发超卖| C[库存不足]
B -->|✅| D[生成支付单]
D -->|⚠️| E[等待回调超时未处理]
原则：图用于"一眼可见问题"，细节仍在表格中；问题节点必须在图中标注，并与表格问题编号对应。
反模式
推演范围层面
- ❌ 只走 Happy Path：忽略异常场景会导致设计缺陷遗漏
- ❌ 设计/需求/Skill 模式下关注代码实现细节：这三种模式推演关注设计/需求/Skill 层面，不下沉到具体代码实现；代码模式则相反，以代码为推演对象、以执行轨迹为产出
- ❌ 超出推演对象范围：不评审当前推演对象（设计/需求/Skill/代码）范围外的问题
推演流程层面
- ❌ 跳过角色识别：不同角色的推演路径不同，必须按角色分别推演
- ❌ 忽略置信度：技术挑战不标注置信度，导致低质量质疑浪费注意力
- ❌ 推演时修改设计：推演只记录问题，修改应交给 design-craft
推演内容层面
- ❌ 模糊问题描述："这里可能有问题"不是有效发现，必须说明什么条件下有问题
- ❌ 忽略数据走向：只验证设计点不验证数据走向，会遗漏数据层面的问题（设计模式）
- ❌ 不标注来源：每条问题必须标注来自哪个场景的推演
- ❌ 需求模式越界：需求模式只验证需求本身（完整性/一致性/验收可达），不提前评审尚未存在的设计，也不替 design-craft 写设计
- ❌ Skill 模式越界：Skill 模式只验证 Skill 质量（触发/指令/示例/工作流/资源/说明层），不修改 Skill 内容，也不评判 Skill 的业务价值
- ❌ 代码模式退化为静态审查：代码模式必须基于具体场景实例沿时间轴正向模拟执行（追踪状态演进），而非像 code-review 那样逐维度静态扫描、也非像 challenger 那样对已有结论做对抗质疑；无具体输入值/初始状态的抽象推演无效
- ❌ 编造虚构的执行轨迹（代码模式）：面对深调用栈/复杂三方库/不可静态确定的行为，禁止编造看似精确实则臆想的状态值（用精确外观骗取信任比模糊结论更危险）；跨越不确定处必须标注
[需运行验证]，超出可靠追踪范围则降级为"推演到此为止 + 待验证清单" - ❌ 推演前不声明预期终态（代码模式）：先跑后定结论会导致合理化推演结果，必须先声明预期终态再追踪
附加资源
- 推演示例 / 关键设计点验证维度详解：reference.md
- 推演策略 profile：strategies/（设计模式按设计特征多选启用，每个 profile 含精选维度/加压点/典型异常/mermaid 提示；需求模式使用 strategies/requirement.md 的需求质量维度；Skill 模式使用 strategies/skill.md 的 Skill 质量维度；代码模式使用 strategies/code.md 的代码推演维度）