需求：REQ-{id}

Dispatch policy: waves-v1

名称：{需求名称} 状态：draft / locked / changed / archived （draft→locked 的翻转由 agent 依据人类在对话中的明确"锁定"拍板执行，见 skills: requirement-funnel） Owner：{产品/用户} PM / Architect：{姓名} 版本：v0.1.0 创建日期：YYYY-MM-DD UI impact：none / changed / unknown

UI impact 是 状态：locked 的强制顶部字段，req bind 只解析这一处（§C 的回显必须与之一致，不一致会被拒绝）。值必须三选一：none / changed / unknown。unknown 会触发规划暂停门禁，需在 §D 澄清后才能推进 S2。

§A 理念（Why）

A1 不是人的原话：你接收并理解人的表述后，过滤口语歧义、补全隐含前提，整理成结构化复述，交人确认"这就是我想说的"。原话会歧义；对话不入册，整理稿才是权威。

用户和利益相关者（决策权"高"的诉求冲突 = 拍板点候选）：

术语（分歧当场定名；统一叫法供全部下游文档使用）：

§B 方向与约束（How 的边界——需求级选型，架构归 S2）

方向取舍（每个被否方向必须有一句否决理由——ADR 雏形，S2 承接）：

硬约束（agent 对人给的每条"必须"追问打破的代价；答不出代价的不是必须，降级为偏好并入下方假设与风险表）：

关键假设与风险：

§C 具体需求（What——逐条可追溯）

正向范围 = 本节需求点全集（FR + NFR）；§A4 只登记负向。

需求点（"服务于"指不回任何 §A 条目 = 范围蔓延，当场质疑）：

流程和异常：

验收标准（换个人来判，结果一样；指向列填写规则——S0 阶段只需保证 FR-{id} 指向 §C 真实存在的 FR 行；其余两种合法值是"经背书的 N/A"：NFR-{id}（须在下方非功能需求表声明）或 §A4-{条目}（指向"明确不做"表的某一行）。自由文本（如"人工检查"）会在 S2 收口时被机器拒绝。示例：FR-003 ✅ / NFR-002 ✅ / §A4-2 ✅ / 上线后观察 ❌）：

非功能需求：

数据迁移范围清单（轻量模式、迁移类、重构类需求即使跳过独立设计文档也必须填写本区；本区是 task 拆分边界依据）：

填写纪律：删除项在"说明"列注引用清理标准；每个文件映射到唯一 task 或明确标注共享边界；任务拆分前检查重复 import、脚本引用、生成物入口和别名路径。

UI 影响（任何涉及前端页面、组件、交互、可见状态、错误展示、权限展示或响应式布局变化的需求必须填写本区；UI impact = changed 时必须先完成 UI Design Package Gate 才能锁定 FE/BE/SYNC 合同）：

真相包齐备性、S/F-NNN 完整性与 branch 覆盖率由 S2 的 loop-harness scenario validate 校验，不在本节自查。

§D 待澄清问题

§E 锁定记录与逐层拍板（locked 行的拍板权在人；拍板行与自审由 agent 依拍板凭证填写）

逐层拍板记录（compaction 后的拍板凭证——对话不是权威，未落盘的拍板等于没发生）：

{agent 自审结论——提议锁定前全审的输出，一段话：审过什么、修了什么、留了什么旁注}

§F 派生文档与覆盖矩阵（S0 不读不填——整个 §F 由 S3 起的 CONTRACTS-{id} 索引维护，本表仅锁定时快照；跳到 §G/文末即可）

派生 UI 设计包

派生合同

条款覆盖

模块当前真相映射

REQ 只能作为来源，不能创建需求私有设计或测试副本。任何触及模块的 REQ 都必须维护模块全集并触发 full-module regression。

批次下游索引

变更记录