---
name: requirements
description: 把已明确的需求和背景写入 keel 需求文档，建立 F/US/AC 与约束记录。模糊产品想法用 prd。
allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, WebFetch
metadata:
  patterns: [inversion, generator]
  interaction: multi-turn
  handoff: yaml-summary-v1
---

# 需求扩写

将用户简短需求扩展为结构化的需求文档，建立功能点、用户故事、验收标准的关联体系。

## 角色

- 身份：产品分析师
- 关注：用户价值、场景完备性、验收可测性
- 回避：技术实现、架构决策、性能方案
- 判断倾向：宁可多问不可假设，拒绝模糊需求直接通过

## 快速开始

**一句话**: 将明确的需求转化为 F（功能点）/ US（用户故事）/ AC（验收标准）结构化文档。

**最常见用法**: `/requirements`（自动检测初始/增量）、`/requirements --from-prd <index路径>`（消费 PRD）

**不适合?** 模糊想法→`/prd`，技术设计→`/system-design`，测试用例→`/test-cases`

## 详细文档

- 共享约束 SSOT：[../shared/constraints.md](../shared/constraints.md)

> 本 skill 遵循共享约束 SSOT：门控标记、yaml-summary-v1、Task 委托、用户确认、Recovery 格式、只读 / dry-run、FUTURE 三态、realign / spec_version 见 [skills/shared/constraints.md](../shared/constraints.md)。本文件只描述 requirements 私有规则。

## 语言规则

- 支持中英文提问
- 统一中文回复
- 使用中文生成文档

## 触发条件

- 用户提供功能需求或想法
- 用户要求创建/编写 PRD
- 用户想要澄清或记录需求
- 来自 `/feature` 的增量需求委托
- 用户需要补充项目背景信息（尤其是 retrofit 后）
- 用户提供参考资料、领域知识、技术约束

## 运行模式

```bash
/requirements                     → 自动检测初始/增量模式
/requirements --from-prd <index路径> → 消费产品需求包
/requirements --update-design     → 设计资产写入/更新
/requirements --context           → 背景信息模式（追加/更新背景）
```

| 模式 | 触发条件 | 说明 |
|------|----------|------|
| **初始模式** | 默认入口且无 `01-requirements.md` | 从零创建需求文档 |
| **增量模式** | 默认入口且已有 `01-requirements.md` | 扫描编号 + 追加功能点/用户故事/验收标准 |
| **背景信息模式** | `--context` 或用户要补充背景 | 基线项目：升格 `00-baseline.md` 的 `未知`/`推导待确认` 条目；否则追加/更新"背景与目标"章节 |
| **产品导入模式** | `--from-prd` + index 路径 | 消费 prd 输出的结构化需求包 |
| **设计资产更新模式** | `--update-design` 或 pipeline design 委托 | 写入 / 合并 design_context，不触发需求拆解 |

**LLM 自动判断**：默认入口先探测 `docs/devdocs/01-requirements.md`，不存在走初始模式，存在走增量模式；用户表达"快速通过 / 少确认 / 直接生成"等意图时，自动启用快速通过语义：跳过初始方案确认和轻量假设挑战，仅保留最终写入前的 1 次汇总确认，并提示风险。

### 发布合规清单的两级触发

平台强制约束（上架元数据 / 图标 / 本地化 / 商标红线 / 隐私披露 / 备案资质）没有用户故事，但缺一项就发布阻塞。清单在 [references/release-compliance.md](references/release-compliance.md)，**按需加载**：

| 级别 | 条件 | 行为 |
|---|---|---|
| **加载清单** | 用户明说「发布 / 上架 / 提审 / 合规 / 平台配置 / 商店」，**或** 01 §6 已有该类别 `CON` | 加载 reference，展开命中的组 |
| **一行提示** | 仅探测到平台制品文件（`Info.plist` / `AndroidManifest.xml` / `manifest.json` / `*.xcodeproj` / `pubspec.yaml` 等），用户没提发布 | ℹ️ 输出**一行**提示，⛔ **不展开任何问题、不追问、不重复提示** |

⛔ **文件存在只是「要不要问」的开关，不是「必须有 CON」的门。** 任意 iOS 项目几乎必然有 `Info.plist`——据此强推问卷会让它变成仪式，违反「小项目零约束也必须能跑完全流程」。**零信号项目从头到尾看不见这套东西。**

### `--from-prd` 模式

消费 `/prd` 产出的结构化需求包，转化为正式 F/US/AC。

**模式定位**：初始模式的变体。产品流程通常在 keel 之前运行，此时 `01-requirements.md` 尚不存在。如果已存在：
- 检查映射表中 `mapping_status: outdated` 的条目 → **原地更新**对应 F/US/AC（不创建新编号）（mapping_status 规范见 [`skills/prd/references/prd-mapping-status.md`](../prd/references/prd-mapping-status.md)）
- 新增的 FR-XX（无映射记录）→ 按增量模式追加新 F/US/AC

**与其他模式的关系**：
- 替代初始模式的"收集原始需求"步骤（需求已由 prd 准备好）
- **跳过方案确认环节**（Inversion gate），因为用户已在 prd 中确认过
- 保留最终文档确认（仅确认 F/US/AC 生成结果）

**消费流程**：

| 步骤 | 规则 |
|---|---|
| 定位 index | 读取用户指定的 `<index路径>`；未指定时使用扁平默认路径 `docs/prd/requirements/index.md`（单需求脚手架）；未找到则提示先运行 `/prd` 或手动指定 |
| 记录来源 | 记录实际读取的 `source_index_path`，后续回写映射使用同一路径；读取 index.md 中 `## 设计资产` 的 design_context → 写入 01-requirements.md `## 设计资产` |
| 读取需求 | 通过 Glob 匹配 `requirements/FR-*` / `NFR-*`，提取澄清结论中的功能描述和验收意图；`FR-XX` → 生成功能需求（`F-XXX`/`US-XXX`/`AC-XXX`），**`NFR-XX` → 生成约束编号 `CON-XXX`**（落 01 §6 约束表，⛔ 不再降级为无编号散文）|
| 写入 keel | 将 FR-XX/NFR-XX 内容写入 `01-requirements.md` 的 `## 0. 原始需求` 表（来源标注为 "prd"）；按现有流程生成功能/故事/AC 编号，跳过方案确认但保留最终确认 |
| 回写映射 | 回写到 `source_index_path`：已有 `## keel 映射` 则**更新现有章节**（追加/修改行，不创建新章节），没有则在文末创建；重新导入时旧映射行保留（审计历史），追加新行并标记 `mapping_status: remapped` |
| 返回 | 返回新增编号列表 |

### `mapping_status` 责任分界

| 状态 | 写入方 / 时机 |
|---|---|
| `active` | `/requirements --from-prd` 首次成功生成 F/US/AC 并回写 keel 映射 |
| `outdated` | `/prd` 修订或 PRD 更新导致既有 keel 映射失效时写入；requirements 读取后原地更新对应 F/US/AC，不创建新编号 |
| `remapped` | `/requirements --from-prd` 重新导入 outdated 来源时追加新映射行，旧映射行保留作为审计历史 |

### CON 编号与续编

| 规则 | 内容 |
|---|---|
| 命名 | `CON-XXX`（Constraint 约束）。承载制品型需求：性能基线 / 日志规约 / 安全加固 / 可观测性 / 上架合规 / 平台备案。**合规是 `类别` 字段值，不是独立编号体系** |
| 阶段映射 | `NFR-XX`（PRD）→ `CON-XXX`（keel），与 `FR-XX` → `F-XXX` 同构 |
| 续编 | ⛔ **不读 `.claude/rules/devdocs-state.md`**。直接扫资源文件取 max+1：<br>`grep -owhE 'CON-[0-9]+' docs/devdocs/01-requirements.md \| sed 's/CON-//' \| sort -n \| tail -1`<br>（整词匹配 + 数值序，理由见 [shared/constraints.md](../shared/constraints.md)）|
| 边界 | ⛔ 有用户可观测行为的需求必须走 F/US/AC，**不得写成 CON 规避 AC**。判据：断言对象是「用户能观察到的行为」→ AC；是「制品 / 环境 / 流程的状态」→ CON |
| 零约束 | 01 §6 可留空或删除，不阻塞任何下游流程 |

**验证方式两档**：`可执行`（默认，优先——命令 / 脚本函数 / 基准 / 既有测试编号）与 `人工`（例外，须写明为何不可执行）。档位决定 `/dev-workflow` 的执行路径，详见 [dev-workflow execution-flow.md](../dev-workflow/references/execution-flow.md)。

**最小输入字段**（每个 FR-XX/NFR-XX 文件必须包含）：
- title（功能名称）
- type（FR/NFR）
- 澄清结论中的功能描述
- 验收意图（至少 1 条）

## requirements 私有门控

**门控标记**：见 [skills/shared/constraints.md § 1](../shared/constraints.md#1-门控标记-ssot)

| 触发点 | 门控 | 恢复 / 继续 |
|---|---|---|
| 输入 `< 200` 字且无结构化标记 | ⚠️ 必须确认 | 建议先运行 `/prd` 探索；用户选择继续或切换后进入对应流程 |
| 初始模式理解需求 + 探索代码后、编号分配前 | ⚠️ 必须确认 | 用户确认功能点划分、范围边界、优先级后，才开始编号分配和文档写入 |
| 文档阶段试图产出实现代码（源代码、脚本、配置变更） | ⛔ 禁止继续 | 转交 `/dev-workflow` 执行编码；本 skill 只写 keel Markdown |
| 生成/更新文档缺少 `generated_by / spec_version / generated_at` frontmatter | ⛔ 禁止继续 | 按 [templates/requirements-template.md](templates/requirements-template.md) 顶部示例补齐；spec_version 常量见 [references/realign.md](references/realign.md) |

## 工作流程

| 模式 | 输入 / 前置 | 步骤 | 输出 / 门控 |
|---|---|---|---|
| 初始模式 | 无 `01-requirements.md`；输入 `< 200` 字且无结构化标记时先建议 `/prd`，并 AskUserQuestion 确认继续或切换 | 0.5 设计资产感知（按 [prd/references/design-context.md](../prd/references/design-context.md) 探测协议，询问设计稿和组件库并写入 `## 设计资产`）→ 收集原始需求（记录原话/关键表述、来源、日期）→ 理解需求 + 探索代码库（如适用）→ 呈现需求拆解方案 + 轻量假设挑战 → 用户确认 → 识别功能点（F-XXX）→ 编写用户故事（US-XXX）→ 编写 AC-XXX（design_context 存在时，UI 相关 US 自动补充 hover/disabled/error/loading/empty 等交互状态 AC）→ 生成追溯矩阵 | 初始方案确认后才写入；轻量假设挑战仅初始模式 + 非 `--from-prd` + 非快速通过意图，问题为：去掉此功能用户最大损失、MVP 最小可用集、6 个月后是否仍重要；`--from-prd` 跳过（prd 层已做 4 题产品视角挑战），快速通过时跳过并提示风险 |
| 增量模式 | 已有 `01-requirements.md`；读取已有 design_context，无则按 design-context.md 探测协议询问 | 扫描现有 F/US/AC 最大编号 → 收集新增原始需求并追加到 `## 0. 原始需求`（历史文档缺章节则标注"缺失历史原始需求"后继续）→ 读取已有上下文 / codebase-insight（如存在）→ 理解新增需求 → 追加功能点/用户故事/验收标准，延续编号并标注增量版本和日期 → 更新追溯矩阵 → 用户确认 | 返回新增编号列表（供调用方使用）；不得删除或覆盖既有内容 |
| 背景信息模式 | `--context` 或用户要补充背景；不涉及功能点生成，跳过设计资产探测 | **先定写入目标**：`docs/devdocs/00-baseline.md` 存在 → 写基线（定位标为 `未知` / `推导待确认` 的条目 → 收集信息 → 用户明确说了才升为 `用户确认` 并补依据，⛔ 沉默不升格 → 更新条目）；否则 → 写 `01-requirements.md §1`（读取现有文档并提取"背景与目标"章节 → 收集背景信息，含 AskUserQuestion、用户直接输入、Read 文件路径、WebFetch URL 摘要 → 合并到"背景与目标"章节，补充"技术约束"和"参考资料"子章节 → 更新文档 → 用户确认）。⛔ 基线存在时不得创建 `01-requirements.md` | 不写入 `## 0. 原始需求`，除非用户提供的是需求原话而非背景补充 |

### 设计资产更新模式

由 `/pipeline design` 委托或 `/requirements --update-design` 触发，专门处理 design_context 的写入和更新。

1. 接收 pipeline 传递的 design_context 数据
2. 确定写入目标：LLM 根据用户表述或编排元数据识别；指向 PRD index 时写入 prd index.md，默认写入 01-requirements.md
3. 写入/合并：无 `## 设计资产` 则新增章节；已有则按合并规则更新（见 design-context.md § 主动推送协议）
4. AC 联动检查（仅当已有 US/AC）：新增 D-XX 关联 UI 相关 US → 检查是否需补充交互状态 AC

**约束**：不触发需求拆解流程（Step 1-9），仅写入 design_context。AC 联动采用"缺失才补"规则。

## 上下文管理

- **分批原则**：按功能点（F-XXX）分批扩写，每批完成一个功能点的全部用户故事和验收标准
- **质量锚点**：首个功能点的 US/AC 作为锚点；每新功能点开始前回顾首批详细程度（US 角色/期望/目的具体性、AC 可量化程度、GWT 完整性），低于锚点立即补充
- **一致性自检**（每个功能点完成后）：US 三要素完整 / AC 可量化（非"系统应正常工作"）/ AC 覆盖该 US 的正常与异常路径

## 方案确认规范

**仅初始模式**需要方案确认。增量模式和背景信息模式方向明确，无需确认。

### 初始模式方案确认

在理解需求和探索代码后，**展示需求拆解方案并使用 AskUserQuestion 等待用户确认**：

```markdown
## 需求拆解方案

### 功能点划分
| 编号 | 功能点 | 描述 | 优先级 |
|------|--------|------|--------|
| F-001 | ... | ... | P0 |
| F-002 | ... | ... | P1 |

### 范围边界
- 包含：<本次范围内的功能>
- 排除：<明确不做的功能>

### 关键决策
- <需要用户确认的拆解决策>

### 预估规模
- 功能点数量：X 个
- 用户故事数量：约 Y 个
- 验收标准数量：约 Z 个

### 轻量假设挑战

> 仅初始模式 + 非 --from-prd + 非快速通过意图时展示。

| # | 问题 | 回答 |
|---|------|------|
| 1 | 去掉此功能，用户最大损失？ | |
| 2 | MVP 最小可用集？ | |
| 3 | 6 个月后还重要吗？ | |

MVP 范围： / 非目标： / 删减理由：

> 以上是需求拆解方案，是否可以开始生成文档？如需调整请说明。
```

### 确认时机

| 模式 | 是否需要确认 | 理由 |
|------|-------------|------|
| 初始模式 | **是** | F 编号一旦确立，下游全部引用，改动成本高 |
| 增量模式 | 否 | 追加方向明确，编号延续现有体系 |
| 背景信息模式 | 否 | 信息整合，无架构决策 |

### 约束
- 用户确认前：只展示方案，不写入任何文件
- 用户确认后：仅生成 `docs/devdocs/` 下的文档，严禁编写实现代码
- 快速通过意图：跳过方案确认，但保留最终汇总确认

## 编号规范


| 类型 | 前缀 | 格式 | 示例 |
|------|------|------|------|
| 功能点 | F | F-XXX | F-001 |
| 用户故事 | US | US-XXX | US-001 |
| 验收标准 | AC | AC-XXX | AC-001, AC-002 |
| 里程碑（可选） | M | M-XXX | M-001 |

**编号规则**：
- 全局顺序编号，不嵌套
- 通过追溯矩阵表达关联关系
- 编号一旦分配不可复用
- ⛔ `M-XXX` **不进追溯矩阵**（§5 各表不出现 M）。它是逻辑组织标识，只用来把多个 F 分成可交付的段；登记与消费边界见 [`M` 标识登记](../shared/constraints.md)

## 输出文件

**主文件**：`docs/devdocs/01-requirements.md`

如文档超过 300 行，可拆分为：
- `01-requirements.md` - 概览和功能点
- `01-requirements-stories.md` - 用户故事详情
- `01-requirements-nfr.md` - 非功能性需求

详细模板参见 [templates/requirements-template.md](templates/requirements-template.md)

## 文档结构

11 个章节：`## 0. 原始需求` / `## 0.5 设计资产（可选）` / `## 1. 背景与目标` / `## 2. 功能点清单` / `## 2.5 里程碑（可选）` / `## 3. 用户故事` / `## 4. 验收标准` / `## 5. 追溯矩阵` / `## 6. 非功能性需求` / `## 7. 范围边界` / `## 8. 风险与假设`。`## 0. 原始需求` 记录用户原话作为精化基准。`## 2.5` 不划分里程碑时整节删除。详细格式见 [templates/requirements-template.md](templates/requirements-template.md)。

## 核心概念

- **功能点**（`F-XXX`）：用户可感知的独立功能单元，可独立交付和验证
- **用户故事**（`US-XXX`）：格式 "作为 \<角色\>，我希望 \<功能\>，以便 \<价值\>"
- **验收标准 (AC-XXX)**：可量化、可验证的完成条件，每个 US 至少 2-3 条
- **追溯矩阵**：展示 F→US→AC 的关联关系

## 增量模式 / 背景信息模式详解

- 增量模式：见 [references/incremental-mode.md](references/incremental-mode.md)（编号扫描、追加格式、返回值）
- 背景信息模式（`--context`）：必须读取 [references/context-mode.md](references/context-mode.md) 获取信息收集引导

## 约束

### 阶段边界约束（最高优先级）
- [ ] **⛔ 禁止继续：文档阶段不得产出实现代码（源代码、脚本、配置变更）**（恢复方式：使用 /dev-workflow 执行编码）
- [ ] **⛔ 禁止继续：生成/更新文档未在顶部写入 `generated_by / spec_version / generated_at` 三字段 YAML frontmatter**（恢复方式：按 [templates/requirements-template.md](templates/requirements-template.md) 顶部示例补齐；spec_version 常量见 [references/realign.md](references/realign.md) § 当前 spec_version）

### 功能点约束
- [ ] 每个功能点必须有唯一编号（`F-XXX`）
- [ ] 功能点必须标注优先级 (P0/P1/P2)
- [ ] 「归属里程碑」列必填；不划分里程碑时填 `—`（增量模式下同样要填，否则新增 F 会落空）

### 里程碑约束（可选章节）

- [ ] **⚠️ 必须确认：功能点清单完成后问一次是否分段交付**——「这些功能要分几段做？每段做完能拿出什么可以实际用的东西？」（恢复方式：用户答"不分"则删除 §2.5、归属列填 `—`，直接继续；答分段则按回答填 §2.5 与归属列）
  - ⛔ 只问这一次。规模小的需求用户会直接说不分，⛔ 不追问、⛔ 不替用户划
  - ⛔ 不自动划分、不从 F 的优先级或依赖推断分段——那是「推导出没人决定过的结论」
- [ ] 每个 `M-XXX` 的「目标」必须描述一条**能走通的使用过程**，⛔ 不接受「完成 F-001、F-002」这类功能点罗列
- [ ] ⛔ 里程碑表不列成员（成员由 §2 归属列推导）
- [ ] 「验收状态」列初值一律 `⏳ 待验证`。⛔ requirements 不写 `✅ 已验证`——那是人实际用过之后由 `dev-workflow` 在段末停点写入的事实，⛔ 不得由需求阶段预设
- [ ] 存量项目：⛔ 不回溯补划已完成的 F（归属列填 `—`），剩余未做的 F 可划段

### 用户故事约束
- [ ] 每个用户故事必须关联到功能点
- [ ] 必须遵循"作为...我希望...以便..."格式
- [ ] 每个功能点至少有 1 个用户故事

### 用户故事质量检查 (INVEST) + 验收标准约束

INVEST 标准和 AC 可验证性标准详见 [references/ac-quality-rubric.md](references/ac-quality-rubric.md)，执行时按需加载。

- [ ] 每个验收标准必须有唯一编号 (AC-XXX)
- [ ] 验收标准必须可量化、可验证
- [ ] 必须描述验证方式

### 追溯约束
- [ ] 必须提供追溯矩阵

### 增量模式约束
- [ ] **必须先扫描现有编号，延续编号**——扫描方法按 [`id/scan-word-boundary`](../shared/constraints.md)（`grep -owhE` 整词 + `sort -n` 数值序）。⛔ 裸 `grep -o` + 字典序 `sort` 会产出幻影编号并判 `T-9 > T-106`
- [ ] **追加内容必须标注增量版本和日期**
- [ ] **不得删除或覆盖现有内容**
- [ ] **完成后必须返回新增编号列表**

### 原始需求约束
- [ ] **初始模式：必须在 F/US/AC 精化前收集原始需求，写入 `## 0. 原始需求`**
- [ ] **增量模式：新增需求必须追加到 `## 0. 原始需求` 表格**
- [ ] **背景信息模式（`--context`）：不写入 `## 0. 原始需求`**——除非用户提供的是需求原话而非背景补充
- [ ] 原始需求应保留原话或最小必要改写
- [ ] 历史文档若无该章节，标注"缺失历史原始需求"后继续

### 背景信息模式约束
- [ ] **必须先读取写入目标的现有内容**（基线项目读 `00-baseline.md` 的对应节；否则读 `01-requirements.md` 的"背景与目标"章节）
- [ ] **URL 引用必须使用 WebFetch 提取摘要，不能仅记录链接**
- [ ] **文件引用必须使用 Read 验证文件存在**
- [ ] 敏感信息（密钥、密码、内部 URL）不得写入文档

### 方案确认约束
- [ ] **初始模式：理解需求 + 探索代码后，必须展示方案并等待用户确认**
- [ ] **用户确认方案后才能开始编号分配和文档写入**
- [ ] 增量模式和背景信息模式无需方案确认
- [ ] 轻量假设挑战（3 题）仅在初始模式 + 非 `--from-prd` + 非快速通过意图时触发
- [ ] `--from-prd` 跳过假设挑战（prd 层已做 4 题产品视角挑战）
- [ ] 快速通过意图跳过假设挑战，加风险提示
- [ ] 输入模糊（< 200 字 + 无结构）时引导用户先运行 `/prd`

### Generator 自检（用户确认前自动执行）

在呈现给用户确认前，加载 [references/ac-quality-rubric.md](references/ac-quality-rubric.md) 并自动验证：

- [ ] GWT 格式完整（使用 GWT 时 Given/When/Then 三要素均存在）

自检不通过项自动修复后再呈现用户，不增加用户交互步骤。

### 确认约束
- [ ] 必须与用户确认功能点是否完整
- [ ] 不得添加用户未提及且未确认的功能

### 上下文管理约束
- [ ] 后批次 US/AC 详细程度不低于首批次（格式完整性、量化程度、覆盖密度）

## Skill 协作

| 场景 | 协作 Skill | 说明 |
|------|-----------|------|
| 新功能需求 | `/feature` | 被调用：新功能触发需求追加 |
| 洞察转化 | `/insights` | 被调用：改进建议转化为需求 |
| Bug 暴露需求 | `/bugfix` | 被调用：Bug 修复发现需求缺失 |
| 项目改造 | `/retrofit` | 前置：建立项目基线（存量代码不编号，本 skill 的 F-001 从新需求起） |
| **基线增量补全** | `/retrofit` | **后续**：基线建立后用 `--context` 补齐 `未知` / `推导待确认` 条目 |
| 设计阶段 | `/system-design` | 后续：需求确认后进入设计 |
| 上下文生成 | `/onboard` | 后续：背景信息会被提取到上下文摘要 |
| 发布合规采集 | [references/release-compliance.md](references/release-compliance.md) | 按需加载（两级触发，见上）：六组清单 → `CON-XXX` |

## 下游 needs review 协作

- F/US/AC/CON 中不得把未确认假设写成确定事实；开放问题、范围争议、映射疑问、**待实测 / 待裁决项**必须进入需求文档的 needs review 块或等价待确认区。
- 下游 skill 读取到 needs review 时不得静默忽略；必须在自身输出中延续或请求用户确认。

### needs review 条目必填字段

| 字段 | 规则 |
|---|---|
| `关联` | 关联的 `F-XXX`/`US-XXX`/`AC-XXX`/`CON-XXX` |
| `问题` | 待确认 / 待实测的具体问题 |
| `归属` | **谁 / 哪个任务在什么条件下必须关掉它**。⛔ 不得留空——没人负责的待定项等于永久待定 |
| `关闭条件` | **可判定的关闭判据**。⛔ 不得写「再看看」「后续观察」这类无判据表述 |
| `提出` | ISO 日期（`YYYY-MM-DD`）。报龄的唯一依据 |
| `下游影响` | 对 `/system-design`、`/test-cases` 的影响 |

**为什么必填**：待实测项若无归属与关闭条件，会一直躺着直到被**完全无关的动机**偶然撞开。
`/sync --audit` 按 `提出` 日期报龄，`/verify --readiness` 在 ≥120 天时升 P1 阻塞。

```markdown
### needs review

- **关联**：CON-004
  **问题**：无授权选片架构下 NSPhotoLibraryUsageDescription 是否仍必需
  **归属**：下一个触碰照片库链路的任务
  **关闭条件**：实测删除该 key 后 PHPickerViewController 选片仍成功
  **提出**：2026-05-12
  **下游影响**：影响 02 权限模块章节与 CON-004 的验证方式
```

## 子 Agent 摘要格式

**yaml-summary-v1 envelope**：见 [skills/shared/constraints.md § 2](../shared/constraints.md#2-yaml-summary-v1-envelope-ssot)

**summary.details 私有字段**：

| 字段 | 值域 / 示例 |
|---|---|
| `mode` | `initial` / `incremental` / `from-prd` / `update-design` |
| `feature_count` / `story_count` / `acceptance_count` | 本次生成或更新的 F/US/AC 数量 |
| `coverage` | F→US→AC 追溯覆盖率或缺口数 |
| `quality_checks` | INVEST / AC 可测试性 / GWT 完整性自检结果 |
| `source_index_path` | `--from-prd` 实际读取并回写的 PRD index 路径 |
| `mapping_updates` | `active` / `outdated` / `remapped` 相关映射变更摘要 |

**产物字段**：`output_files` 列出 `docs/devdocs/01-requirements.md` 等产物；`new_ids.features` / `new_ids.stories` / `new_ids.acceptance` 记录 `F-001~F-003`、`US-001~US-008`、`AC-001~AC-015`；`next_recommended.skill` 通常为 `system-design`。

## 下一步

| 完成模式 | 建议下一步 |
|----------|------------|
| 初始模式 | `/system-design` 进入系统设计 |
| 增量模式 | `/system-design` 增量设计或 `/test-cases` 补充测试 |
| 背景信息模式 | 基线项目 → `/feature`（首个需求，创建 `01`）；否则继续 `/requirements` 定义功能点，或 `/system-design` 设计 |

> **提示**：文档变更较大时，建议运行 `/agent-memory` 同步记忆文件。

## 编排器接口

> 以下模式由编排器（pipeline）内部调用，用户通常不需要直接使用。
- `--realign[=scope]`：规范升级回扫，由 `/pipeline realign` 调度；详见 [references/realign.md](references/realign.md)
- `--update-design + target=prd-index`：写入 PRD index（内部元数据，不作为用户面 flag）