specify-scenario

specify-scenario

使用时机

• 仅被 specify skill 显式调用

场景定义

场景是某一需求之下一个具体、可执行的业务流程或使用情境，用于描述“在特定前置条件下，执行一系列有序操作后，系统与用户应共同达到的预期结果”。场景聚焦于具体执行流程与可验证的结果，是需求在业务与体验层面的具象化落地单元。

指令

步骤1: 明确输入与上下文

• 业务意图: 从上层命令传入的 $ARGUMENTS, 表达本次要实现或调整的业务目标。
• 上下文文件: 优先读取 FEATURE_DIR/context.md, 参考其中的:
  • 「相关场景文档」章节，作为既有场景的主要参考来源
  • 架构分析、可复用模式、术语对齐、约束和假设
  • 若 context_mode = evidence_first，优先使用 on_demand.scope、on_demand.traceability、on_demand.contract_deltas、on_demand.risks、on_demand.evidence_gaps

步骤2: 分析既有场景的变更

基于步骤1输入与上下文，按「场景定义」识别并产出本次变更涉及的全部场景条目（含INSERT/MODIFY/DELETE/REFER），作为后续步骤的范围基线。

动作类型定义:

• MODIFY: 业务意图要求对既有某个场景的步骤、前置条件或结果进行调整或细化。
• INSERT:
  • 理解既有场景，业务意图无法合理归属到任何既有场景文档。
  • 不存在既有场景时，则需新增所需场景。
• DELETE: 除非删除具有明确业务必要性且风险可控，否则不删除；必须给出充分理由与影响分析（依赖方、兼容策略、回滚策略）。
• REFER: 既有场景已充分覆盖当前业务意图，无需对内容作任何修改，但需记录引用关系以支持后续影响分析。

边界增强规则（仅 evidence_first 模式）：

• 使用 on_demand.traceability 的 function -> interface 链路构建主场景，确保场景覆盖真实入口与关键处理路径。
• 对 on_demand.contract_deltas 的接口变化，必须在至少一个主场景与一个边界/异常场景中体现可验证行为。
• 场景范围默认受 on_demand.scope 限定；未进入 scope 且无证据链支撑的对象不纳入主场景。
• 将 on_demand.risks 与 on_demand.evidence_gaps 优先转化为边界情况与异常验收用例。

兼容规则（default 模式）：

• 若 context_mode = default 或 on_demand 字段缺失，完全沿用原有规则，不阻塞场景生成。

步骤3: 按照以下模板生成「场景」章节内容

## 场景

### [动作类型: INSERT/MODIFY/DELETE/REFER] - [场景ID] - [场景名称] (优先级: P1)

归属的需求: [关联的需求ID] - [需求名称]

场景描述: 作为 <用户角色>，我希望 <完成某个操作>，以便 <实现某个价值/达成某个目标>

**优先级原因**: [从业务价值、风险、依赖关系等角度解释该场景为何具有此优先级]
**独立测试**: [描述如何以独立方式对该场景进行端到端验证 —— 例如: “可以通过 [具体操作] 完整测试并交付 [具体价值]”]
**验收场景**:

1. **Given** [初始状态], **When** [操作时], **Then** [预期结果]
2. **Given** [初始状态], **When** [操作时], **Then** [预期结果]

[按照上述格式继续描述其他场景，每个场景都需明确优先级...]

### 边界情况

- 当 [边界条件] 出现时，系统与用户会经历怎样的行为与结果？
- 系统如何处理 [错误场景]，包括用户可见反馈与日志/告警等非功能性行为？

MODIFY

1. 从既有场景文档中准确提取对应条目的完整内容，填充到上述模板占位符。
2. 基于 业务意图 分析本次变更的动机与影响范围，明确需要调整的具体内容。对新增或修改的部分使用 **加粗** 标记，对拟删除的内容使用 ~~删除线~~ 标记，以便后续评审与追踪。

INSERT

1. 生成场景ID:

• 读取 DOC_DIR/specs/scenarios/0.scenario_list.md，提取已存在的 SCN-XXX 最大ID，取 最大ID + 1 作为新场景的ID。
• 不存在 0.scenario_list.md 时，场景ID从 SCN-001 开始。

2. 依据 .infra/metamodel/3.scenario-template.md 中的规范生成新场景内容:
   • 参考 DOC_DIR/specs/scenarios/ 下既有文档的组织方式与粒度，使新场景在抽象层级上与既有场景保持一致，避免过于宽泛（难以验证）或过于聚焦实现细节。
3. 使用步骤 3 中的模板，将生成的场景内容整理为「场景」章节条目。

DELETE

1. 从既有场景文档中提取拟删除条目的完整内容，填充到上述模板占位符。
2. 以审慎态度给出充分且清晰的变更原因，说明删除该场景在业务、合规与用户体验层面的必要性。

REFER

从既有场景文档中提取对应条目的完整内容填入模板，占位符 [变更原因] 统一填写为无变更，仅建立引用关系以支持后续波及分析。

步骤4: 将生成的「场景」章节内容追加到 FEATURE_DIR/spec.md 末尾

DoD（完成校验）

• 用户视角: 场景描述全部采用非技术化语言，清晰表达用户角色、动机与预期价值，不夹带实现细节或内部技术术语。
• 切片可交付: 每个场景都可以作为独立功能切片进行开发、演示与验收，且优先级（P1/P2/P3）设置合理、有据可依。
• 变更规范: 场景文档已按 INSERT/MODIFY/DELETE/REFER 规则完成更新，加粗/删除线等标记使用准确、一致，可支撑审计与回溯。
• ID一致: 新增场景的 SCN-XXX ID基于当前最大值顺序递增，无冲突或缺号。
• 需求关联明确: 每个场景都具备明确的归属需求 ID（新增场景直接标注；既有场景可通过 requirements.json 反向查询得到）。
• 验收可执行: 每个场景至少包含 2 条 Given/When/Then 验收用例，覆盖主路径以及关键异常或边界情形，便于测试落地。