价值三问
给谁用、解决什么问题、比现有做法好在哪。三问若答不出，说明需求还停留在想法，未转为可讨论的问题——此时先回到场景，而不是先写代码。这三问同时也是说明产品价值的开头。
定边界与规约
边界回答「本轮做到哪」，规约回答「做到什么算完成」。两者都写在文件里：前者供小组判定优先级，后者给 Harness 与验收共同使用。
1边界怎么定
先说清价值，再列这一轮要交付的能力。
本次要交付的能力清单
一条一句、编号排列，每条都要能单独被演示或被测试。清单之外的能力不是被否定，而是由后续课次按规约增量加入；这正是最小可用产品（Minimum Viable Product, MVP）的定法——先确定本轮可交付的边界，再逐轮扩大。
判断边界是否清楚的办法
把清单交给一位没参与讨论的同伴，请他复述本轮要做什么。能完整复述，边界就是清楚的；复述时不断追加「还有……」，说明边界还没定完。这是需求评审中最省事的一致性检查：复述者不需要懂技术，只需要能读懂清单。
对应的课程知识点：需求工程（requirements engineering）中的范围管理、最小可用产品、可验证需求（verifiable requirement）、需求评审的一致性检查。边界先于规约：先确定本轮做什么，再讨论每条做到什么算完成。
2规约的四份文件
用 /opsx-propose 起草一份变更，四份文件各管一件事。
| 文件 | 写什么，为什么单列一份 | 写完的标志（判据） |
|---|---|---|
proposal.md | 为什么做、本次做到哪、与既有约定的关系。动因单独成文，是为了让不读代码的人也能判定本次改动的必要性 | 不读代码亦可判定本次改动的必要性；至少写出一条被放弃的候选方案 |
design.md | 技术选型、分层结构，以及两到三条关键取舍与理由。取舍单独记录，后来接手的人才知道当时放弃了什么 | 每条取舍都能说明被放弃的候选方案是什么 |
specs/能力/spec.md | 每条能力（capability）一组场景，含失败路径。只有这一份能被逐条判定，其余三份服务于它 | 场景能被逐条执行并判定通过与不通过 |
tasks.md | 可执行的任务清单，编号可勾选，骨架任务排在最前。顺序写在这里，执行者就不必重新排序 | 按编号顺序做完即完成本次改动；换一位执行者也不需要调整顺序 |
3场景怎么写
三段式，不写形容词：「前置条件 / 操作 / 可观测结果」。
场景：连续提交同一份作答
前置条件：学生已登录；作业已发布且未截止；该学生尚无提交
操作： 以同一个幂等键（idempotency key）连续提交两次同一份作答
可观测结果：提交记录一份；批改记录一份；第二次返回首次结果- 前置条件写清角色、数据归属与已有数据。场景能否复现取决于这一段：缺了角色就无从判定授权，缺了数据归属就无从判定越权。
- 操作写清谁对哪个接口或页面做了什么。操作不可复述，场景就无法转成用例。
- 可观测结果写清返回值、数据变化与日志里各看到什么。只有这一段能被机器判定，形容词在这里一律无效。
对应的课程知识点：可验证需求、测试用例设计中的等价类划分（equivalence partitioning）与边界值分析、验收测试（acceptance testing）。「失败路径不少于四条」的依据是错误猜测与边界值：每条能力至少覆盖参数非法、无权限、资源不存在、依赖不可达四类，这四类在测试规范里直接转成对应层次的用例。数值写具体：条数上限、长度限制、超时、分页、重试次数都要写成数字。「大量」「较快」「若干」进了规约，等于把判定权交给了实现者。
4规约的验收
三条：一条机器检查，一条人工检查，一条对应关系检查。
- 校验命令通过。
/opsx-validate 变更名 --strict不通过，说明规约不完整——先补规约，不要先写代码。 - 另起一次会话能照做。另起一个不带历史上下文的 Harness 会话，只给它仓库路径与变更名，它能按任务清单与需求规约实现，且问不出含糊之处。若还能问出含糊之处，说明规约存在缺口，缺口在哪就补在哪。
- 能力与场景一一对应。列一张两列表：每条能力至少一组场景，没有场景的那一条即缺判定依据。这是需求—用例可追溯矩阵（traceability matrix）的最小形态。
对应的课程知识点：验收测试与需求可追溯性、质量门禁。校验命令只是形式检查；能否被一位不了解前情的执行者照做，才是实质检查。