pdlc-featurelisted

# 全自动 PDLC 新功能开发 <!-- @include templates/prompts/iron-law.md --> 接收功能描述或已有需求文档，全自动走完 PDLC 所有阶段，直到产出可上线状态，中途不暂停、不询问用户。 ## 输入解析（阶段一之前执行） 从 `$ARGUMENTS` 中判断输入类型： 1. **检测是否为文件路径**：如果输入匹配以下模式之一，视为文件输入： - 以 `/`、`./`、`../`、`~` 开头的路径 - 以 `.md`、`.txt`、`.docx`、`.pdf`、`.doc` 结尾 - 包含 `docs/` 或 `requirements/` 路径片段 - 是一个实际存在的文件路径 2. **文件输入**：读取文件内容，从中提取功能描述、用户故事、验收标准。阶段一基于文件内容结构化生成 PRD（保留原始意图，补充缺失部分），而非从零推断。在 PRD 中标注：`<!-- 来源文档: <原始文件路径> -->` 3. **文本输入**：按原有逻辑，从一句话描述自动推断 4. **已有 PRD 路径**：如果输入指向 `docs/01_requirements/prd/` 下已有的 PRD 文件，则**跳过阶段一**，直接从阶段一-B（任务拆解）或阶段二（技术设计）开始 ## 执行规则 - **全程自动**：不在任何阶段暂停等待确认，遇到歧义自行做合理假设并在最终报告中说明 - **严格顺序**：必须按阶段一→二→三→四→五→六顺序执行，不得跳过 - **文档先行**：每阶段先产出文档，再进入下一阶段 - **TDD 强制**：代码实现前测试必须已存在且处于失败状态 - **自查通过才结束**：所有测试通过、评审记录完成后才输出最终报告 - **功能ID贯穿全程**：阶段一分配功能ID后，所有后续文档和产出物统一使用该ID --- ## 功能ID分配（阶段一开始前执行） 1. 获取今日日期，格式 `YYYYMMDD` 2. 扫描 `docs/` 目录下所有文件名，匹配模式 `F<今日日期>-(\d{2})`，提取所有序号 3. 取最大序号 +1（两位补零），无匹配则为 `01` 4. 生成功能ID：`F<YYYYMMDD>-<NN>`（如 `F20260326-01`） 5. 从用户描述中提取功能名关键词（英文小写+连字符，如 `user-auth`） ### 关系建议（RFC#6） 分配 ID 后，扫描 `docs/.pdlc-state/*.json` 列出已有 feature 名，结合用户描述判断本功能与既有 feature 的关系： - 描述含「基于 / 扩展 / 增强 X」→ 建议 `extends X` - 描述含「需要 / 依赖 X」→ 建议 `depends_on X` - 描述含「替代 / 重做 X」→ 建议 `supersedes X` - 命中后填入 PRD §6.1 关系表，并在阶段四状态机的 `relations` 块写入。类型语义见 `relations.md` - 无明显关系则跳过 --- ## 阶段一：需求分析（PRD） 1. 根据功能描述，自动推断：功能范围、目标用户、核心用户故事（至少 3 条）、验收标准 2. 在 `docs/01_requirements/prd/` 下创建文件，命名格式：`<功能ID>-<功能名>-prd.md` 3. 使用 `templates/prd-template.md` 作为模