# 文档请求自动驾驶仪 ## 目的自动**原子需求 (REQ)** 生成管道，处理 SYS 文档并将其分解为**多个原子 REQ 文件**（每个功能一个），使用包含 11 个部分的 REQ MVP 格式、双重就绪评分（SPEC-Ready + IMPL-Ready）和累积可追溯性。 **层**：7（REQ 生成） **上游**：BRD（第 1 层）、PRD（第 2 层）、EARS（第 3 层）、BDD（第 4 层）、ADR（第 5 层）、SYS（第 6 层） **下游工件**：CTR（第 9 层）、SPEC（第 10 层） **关键增强 (v2.0)**：基于 Trading Nexus REQ 层分析，此技能现在生成**原子文件分解**（每个模块 10-15 个文件）而不是单一的 REQ 文档。请参阅阶段 1.5：原子分解。 ** ** ## 输入合同（IPLAN-004 标准） * 支持模式： * `--ref <路径>` * `--提示“<文本>”` * `--iplan <路径|IPLAN-NNN>` * 优先级：`--iplan > --ref > --prompt` * IPLAN解析顺序： 1.存在时使用显式文件路径 2. 解析`work_plans/IPLAN-NNN*.md` 3. 解决 `governance/plans/IPLAN-NNN*.md` 4. 如果存在多个匹配项，则失败并显示消歧请求 * 合并冲突规则： * 主要来源和补充来源之间的目标/范围冲突会造成阻碍，需要用户澄清。 ** ** ## 输入合同（IPLAN-004 标准） * 支持模式： * `--ref <路径>` * `--提示“<文本>”` * `--iplan <路径|IPLAN-NNN>` * 优先级：`--iplan > --ref > --prompt` * IPLAN解析顺序： 1.存在时使用显式文件路径 2. 解析`work_plans/IPLAN-NNN*.md` 3. 解决 `governance/plans/IPLAN-NNN*.md` 4. 如果存在多个匹配项，则失败并显示消歧请求 * 合并冲突规则： * 主要来源和补充来源之间的目标/范围冲突会造成阻碍，需要用户澄清。 ** ** ## 技能依赖该自动驾驶仪协调以下技能：技能|目的|阶段 ---|---|--- `文档命名` |元素 ID 格式 (REQ.NN.TT.SS)，类型代码 01/05/06/27 |所有阶段 `文档系统验证器` |验证 SYS SPEC-Ready 分数 |第 2 阶段：系统准备就绪 `文档请求` | REQ 创建规则、REQ MVP 11 部分结构、模板 |第 3 阶段：REQ 生成 `质量顾问` | REQ 生成期间的实时质量反馈 |第 3 阶段：REQ 生成 `doc-req-validator` |验证 REQ 结构、内容、SPEC-Ready 分数 |第 4 阶段：REQ 验证 `文档请求审阅者` |内容审核、链接验证、质量评分 |第五阶段：审查 `文档请求修复程序` |应用审查报告中的修复，创建丢失的文件 |第五阶段：修复 **委托原则**：自动驾驶仪编排工作流程，但委托： * REQ 结构/内容规则 -> `doc-req` 技巧 * 实时质量反馈->`质量顾问`技能 * REQ验证逻辑-> `doc-req-validator`技能 * 内容审核和评分 -> `doc-req-reviewer` 技能 * 问题解决和修复 -> `doc-req-fixer` 技能 * SYS验证逻辑->`doc-sys-validator`技能 * 元素 ID 标准 -> `doc-naming` 技巧 ** ** ## 文件类型合同（强制）当生成 REQ 文档实例时，自动驾驶仪必须： 1. **从模板中读取** `instance_document_type`： * 来源：`ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.yaml` * 字段: `metadata.instance_document_type: "req-document"` 2. **在生成的文档 frontmatter 中设置** `document_type`：自定义字段： document_type: req-document # NOT “模板” 工件类型：REQ 层数：7 3. **验证**：生成的文档必须具有 `document_type: req-document` * 模板有 `document_type: template` * 实例具有 `document_type: req-document` * 模式验证这两个值 **错误处理**：如果模板中缺少“instance_document_type”，则默认为“req-document”。 ** ** ## 智能文档检测自动驾驶仪根据输入文档类型自动确定操作。 ### 输入类型识别输入 |检测为 |行动 ---|---|--- `REQ-NN` |自型 |审查现有的 REQ 文档 `SYS-NN` |上游型 |缺失则生成，存在则查看 ### 检测算法 1.解析输入：从“{TYPE}-{NN}”中提取TYPE和NN 2. 确定行动： - IF TYPE ==“REQ”：审核模式 - ELSE IF TYPE == "SYS": 生成/查找模式 - ELSE：错误（此自动驾驶仪的类型无效） 3. 对于生成/查找模式： - 检查：docs/07_REQ/ 中是否存在 REQ-{NN}？ - 如果存在：切换到 REQ-{NN} 的查看模式 - 否则：继续从 SYS-{NN} 生成 ### 文件存在性检查 # 检查嵌套文件夹结构（强制） ls 文档/07_REQ/REQ-{NN}_*/ ### 示例 # 审核模式（相同类型 - REQ 输入） /doc-req-autopilot REQ-01 # 审查现有 REQ-01 # 生成/查找模式（上游类型 - SYS 输入） /doc-req-autopilot SYS-01 # 如果缺少 REQ-01，则生成 REQ-01，或查看现有 REQ-01 # 多个输入 /doc-req-autopilot SYS-01,SYS-02 # 生成/审查 REQ-01 和 REQ-02 /doc-req-autopilot REQ-01,REQ-02 # 评论 REQ-01 和 REQ-02 ### 行动确定输出输入：SYS-01 ├── 检测类型：SYS（上游） ├── 预期需求：REQ-01 ├── REQ 存在：是 → docs/07_REQ/REQ-01_f1_iam/ └── 行动：审核模式 - 在 REQ-01 上运行 doc-req-reviewer 输入：SYS-05 ├── 检测类型：SYS（上游） ├── 预期需求：REQ-05 ├── REQ 存在：否 └── 行动：生成模式 - 从 SYS-05 创建 REQ-05 输入：REQ-03 ├── 检测类型：REQ（自身） └── 行动：审核模式 - 在 REQ-03 上运行 doc-req-reviewer ** ** ## 何时使用此技能 **在以下情况下使用`doc-req-autopilot`： * 您已准备好一份或多份已完成的 SYS 文档以生成 REQ * 您希望将系统需求自动分解为原子单元 * 在生成之前您需要进行 REQ-Ready 分数验证 * 您希望在创建 REQ 后自动进行 SPEC-Ready 分数验证 * 您需要生成包含 11 个部分的 REQ MVP 文档 **请勿在以下情况下使用**： * 通过广泛的手动定制创建单个 REQ（直接使用 `doc-req`） * SYS 文件不完整或处于草稿状态 * 您需要对每个 REQ 部分进行细粒度控制 * SYS REQ-Ready 分数低于 90% ** ** ## 工作流程概述流程图TD 子图 Phase1[“第 1 阶段：SYS 分析”] A[输入：SYS 列表] --> B[读取 SYS 文档] B --> C[提取功能需求] C --> D[确定质量属性] D --> E[目录接口规范] E --> F[提取阈值参考] 结束子图 Phase2[“阶段 2：REQ 准备情况检查”] F --> G{下一个系统} G --> H[检查 REQ-Ready 分数] H --> I{分数 >= 90?} 我-->|不| J[自动修复系统问题] J --> K[重新验证 SYS] K --> 我我-->|是| L[标记系统就绪] 结束子图 Phase3["阶段 3：REQ 生成"] L --> M[分解为原子需求] M --> N[生成 11 个必需的部分] N --> O[添加接口规范] O --> P[添加数据模式] P --> Q[添加错误处理规范] Q --> R[质量顾问：实时反馈] R --> S[添加累积标签 - 需要 6 个] S --> T[写入 REQ 文件] 结束子图 Phase4[“阶段 4：REQ 验证”] T --> U[运行 doc-req-validator] U --> V{规格就绪 >= 90？} V -->|否| W[自动修复 REQ 问题] W --> X[重新验证 REQ] X-->V V -->|是| Y{IMPL 就绪 >= 90？} 是-->|否|瓦是 -->|是| Z[验证通过] 结束子图 Phase5[“第 5 阶段：审查和修复周期”] Z --> ZA[运行 doc-req-reviewer] ZA --> ZB{分数 >= 90?} ZB -->|否| ZC[运行 doc-req-fixer] ZC --> ZD{迭代 < 最大值？} ZD -->|是|扎阿 ZD -->|否| ZE[标志手动审核] ZB -->|是| ZF[验证质量检查] ZE --> ZF ZF --> AA[检查 12 部分完整性] AA --> AB[验证累积标签 - 需要 6 个] AB --> AC[验证阈值参考] AC --> AD[检查原子需求原则] AD --> AE[标记 REQ 已完成] 结束 AE --> AF{更多 SYS？} 自动对焦 -->|是| G AF -->|否| AG[生成总结报告] AG --> AH[完成] ** ** ## 详细工作流程 ### 第 1 阶段：系统分析分析 SYS 文档以提取 REQ 分解的需求。 **输入源**（来自 SYS）：系统部分|需求内容 |测绘 ---|---|--- 第 4 节：功能要求 |核心能力|第 2 节：功能要求第 5 节：质量属性 |性能/安全 |第 7 节：质量属性第 6 节：接口规范 | API、协议 |第 3 节：接口规范第 7 节：数据管理 |架构、模型 |第 4 部分：数据模式第 8 节：测试要求 |验证|第10节：验证方法第 11 节：验收标准 |测试条件|第 9 节：验收标准第 13 节：可追溯性 |上游参考|第 11 节：可追溯性 **分析过程**： # 检查SYS文件 ls -la 文档/06_SYS/ # 预期结构： # - SYS-NN_{slug}.md（整体） # - SYS-NN_{slug}/（用 SYS-NN.S_{section}.md 文件分段） **输出**：具有原子单元、阈值参考和可追溯性链接的需求分解计划。 ### 阶段 1.5：原子分解（v2.0 中的新功能）将 SYS 功能需求分解为单独的原子 REQ 文件。 > **参考**：基于 Trading Nexus 项目模式 (`/opt/data/trading_nexus_v4.2/Nexus_Platform_v4.2/docs/07_REQ/REQ-01_f1_iam/`) **分解策略**： 1. **每种功能一个 REQ 文件**：每个 SYS.NN.MM.SS 功能需求映射到一个 REQ-NN.MM 文件 2. **自包含文件** ：每个文件都包含全部 11 个部分 3. **交叉链接**：文件通过“@discoverability”标签引用同级文件 **输出结构示例**（对于 F1 IAM 模块）：文档/07_REQ/REQ-01_f1_iam/ ├── REQ-01.00_index.md # 能力矩阵索引 ├── REQ-01.01_jwt_authentication.md # SYS.01.01.01 ├── REQ-01.02_token_refresh_mechanism.md # SYS.01.01.02 ├── REQ-01.03_token_replication.md # SYS.01.01.03 ├── REQ-01.04_session_binding.md # SYS.01.01.04 ├── REQ-01.05_rbac_enforcement.md # SYS.01.02.01 ├── REQ-01.06_4d_authorization_matrix.md # SYS.01.02.02 ├── REQ-01.07_permission_inheritance.md # SYS.01.02.03 ├── REQ-01.08_context_aware_access.md # SYS.01.02.04 ├── REQ-01.09_mfa_integration.md # SYS.01.03.01 ├── REQ-01.10_api_key_management.md # SYS.01.03.02 ├── REQ-01.11_audit_logging.md # SYS.01.04.01 └── REQ-01.12_compliance_reporting.md # SYS.01.04.02 **分解规则**：规则|描述 ---|--- **文件命名** | `REQ-{模块}.{序列}_{capability_slug}.md` **最小文件** |每个 SYS 模块 ≥3 个原子文件（可配置） **最大尺寸** |每个文件 30KB（触发额外拆分） **需要索引** |用于导航的“REQ-NN.00_index.md” **交叉链接** |每个文件引用相关功能 **索引文件模板** (`REQ-NN.00_index.md`)： # REQ-01：F1 身份和访问管理 - 原子要求索引 ## 能力矩阵 |请求 ID |能力|系统源|优先|规格就绪 | |--------|------------|------------|---------|------------| | REQ-01.01 | JWT 身份验证 |系统.01.01.01 | P1 | 94% | | REQ-01.02 |令牌刷新 |系统.01.01.02 | P1 | 92% | | REQ-01.03 |令牌撤销 |系统.01.01.03 | P1 | 91% | | ... | ... | ... | ... | ... | ## 交叉引用矩阵 |需求 |取决于|发现者 | |-----|------------|----------------| | REQ-01.01 | - | REQ-01.02、REQ-01.11 | | REQ-01.02 | REQ-01.01 | REQ-01.03 | | REQ-01.06 | REQ-01.05、REQ-01.07、REQ-01.08 | REQ-01.11、REQ-01.12 | **何时不分解**（使用整体式）： * SYS模块有≤2个功能要求 * 预计 REQ 内容总计 < 20KB * 显式设置 `--monolithic` 标志 ### 第 2 阶段：REQ 准备情况检查在生成之前验证源 SYS 文档是否满足 REQ-Ready 要求。 > **技能委派**：此阶段使用“doc-sys-validator”技能中的验证规则。请参阅：`.claude/skills/doc-sys-validator/SKILL.md` 了解完整的 SYS 验证规则。 **REQ-Ready 评分标准 (100%)** : 类别 |重量 |标准 ---|---|--- 功能完整性| 35% |优先记录所有 FR-NNN 要求质量属性| 25% |存在性能、可靠性、安全类别接口规格| 20% | API 合约、协议定义数据管理| 10% |记录数据模式、存储要求溯源 | 10% |存在 5 个上游标签（@brd、@prd、@ears、@bdd、@adr） **最低分数**：90%（可配置） **自动修复操作**：问题 |自动修复操作 ---|--- 缺少性能类别 |添加p50/p95/p99模板表缺少安全类别 |添加认证/授权模板接口规范不完整|添加协议模板结构缺少上游标签 |添加占位符引用缺少质量属性指标|添加MTBF/MTTR模板 **验证命令**（内部）： python ai_dev_ssd_flow/06_SYS/scripts/validate_sys.py \ --sys 文档/06_SYS/SYS-NN_{slug}.md \ --最低分数 90 \ --自动修复 ### 第 3 阶段：REQ 生成从经过验证的 SYS 生成 REQ 文档，并提供实时质量反馈。 > **技能委派**：此阶段遵循“doc-req”技能中定义的规则。请参阅：`.claude/skills/doc-req/SKILL.md` 以获取完整的 REQ 创建指南。 > > **质量指导**：使用“质量顾问”技能在生成过程中进行实时反馈。请参阅：“.claude/skills/quality-advisor/SKILL.md”以进行质量监控。 **生成过程**： 1. **预留 REQ ID** : # 检查下一个可用的 ID ls 文档/07_REQ/REQ-*.md 文档/07_REQ/*/REQ-*.md 2>/dev/null | \ grep -oP 'REQ-\K\d+' | grep -oP 'REQ-\K\d+' |排序 -n |尾部-1 # 新 REQ 的增量 2. **加载需求模板**： * 主要：`ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.md` * 部分模板：用于分段 REQ (>50KB) 3. **生成文档控制部分**：领域 |价值 ---|--- 请求 ID |请求-NN 状态 |草案（初始）版本 | 0.1.0 创建日期 |当前日期 (YYYY-MM-DD) 最后更新 |当前日期 (YYYY-MM-DD) 作者 |系统架构师优先|来自 SYS 优先级 (P1-P4) 类别 |功能性源文件| SYS-NN 截面 X.Y.Z 验证方法| BDD + 集成测试指定团队|来自 SYS 上下文 SPEC-Ready 分数 |生成后计算 IMPL-Ready 分数 |生成后计算模板版本| 3.0 4. **分解为原子需求**： **原子要求原则**： * **单一职责**：每个 REQ 精确定义一个要求 * **可衡量**：验收标准提供真/假结果 * **自包含**：无需外部上下文即可理解 * **SPEC-Ready** ：包含自动生成 SPEC 的所有信息 * **模态语言**：SHALL（强制）、SHOULD（首选）、MAY（可选） 5. **生成所有 11 个必需部分**： **第 1 部分：描述** * 使用 SHALL/SHOULD/MAY 语言的原子需求声明 * 背景和场景 * 商业理由 **第 2 节：功能要求** * 使用 REQ.NN.01.SS 格式的核心功能 * 业务规则 * 输入/输出规格 **第 3 节：接口规范** * 具有类型提示的协议/ABC 定义 * DTO 定义（数据类或 Pydantic） * REST 端点（如果适用） **第 4 节：数据模式** * JSON 模式（草案 07） * 带验证器的 Pydantic BaseModel * 数据库架构（如果适用） **第 5 节：错误处理规范** * 带代码的异常目录 * 错误响应模式 * 断路器配置 * 用于错误恢复的状态机 **第 6 节：配置规范** * 用于设置的 YAML 架构 * 环境变量 * 验证规则 **第 7 节：质量属性** * 绩效目标 (p50/p95/p99) * 可靠性指标（MTBF/MTTR） * 安全要求 * 可扩展性目标 * 全部带有@threshold 引用 **第 8 节：实施指南** * 推荐算法/模式 * 并发/异步注意事项 * 依赖注入模式 **第 9 节：验收标准** * 使用 REQ.NN.06.SS 格式的至少 15 个可衡量标准 * 类别：主要功能 (5)、错误/边缘情况 (5)、质量/约束 (3)、数据验证 (2)、集成 (3) **第 8 节：测试要求**（在 v2.0 中增强） * 带有类别前缀的单元测试（见下文） * 集成测试清单 * BDD场景参考 **单元测试类别格式**（v2.0 中的新增功能）：类别 |前缀 |描述 |最小计数 ---|---|---|--- 逻辑| `[逻辑]` |核心业务逻辑测试| 3 验证 | `[验证]` |输入验证测试| 2 状态| `[状态]` |状态机/转换测试 | 1 边缘| `[边缘]` |边缘情况和边界测试| 2 安全| `[安全]` |特定于安全性的测试 | 1 **单元测试表示例**： |测试用例|输入|预期输出 |覆盖范围| |--------------------------------|------------------------------------|----------------------|------------------------| | **【逻辑】有效登录** |有效的电子邮件/密码 | 200 个代币 | REQ.01.01.01 | | **[验证] 电子邮件地址无效** | “不是电子邮件”| 400 无效_电子邮件 | REQ.01.21.01 | | **[状态] 帐户被锁定** |锁定用户| 403 帐户锁定 | REQ.01.27.01 | | **[边缘]速率限制边界** |第五次尝试 | 200 OK（未阻止）| REQ.01.06.07 | | **[安全] 缺少令牌** |无授权标头| 401 未经授权 | REQ.01.02.02 | **第 9 节：验收标准**（在 v2.0 中增强） * 至少 15 个可衡量标准（分为几个小节） * 9.1 功能验收（≥10 个标准） * 9.2 质量验收（≥5项标准） * 用于跟踪的状态复选框 **第 10 节：可追溯性**（在 v2.0 中增强） * 10.1 上游来源表 * 10.2 下游工件表 * 10.3 可追溯性标签（需要 6 个） * 10.4 追溯矩阵 * **10.5 交叉链接（新）** \- 见下文 **第 10.5 节交叉链接格式**（v2.0 中的新增内容）： ### 10.5 交叉链接 @depends: REQ-NN.XX（直接依赖描述） @discoverability：REQ-NN.YY（交互上下文）； REQ-NN.ZZ（共享资源） **交易 Nexus REQ-01.06 的示例**： @discoverability：REQ-01.05（角色策略为矩阵提供数据）； REQ-01.07（继承输入驱动矩阵条目）； REQ-01.08（上下文维度与矩阵因子一致）； REQ-01.11（授权决策必须经过审计）； REQ-01.12（矩阵输出支持合规性证据） **第 11 节：实施说明**（在 v2.0 中增强） * 11.1 技术方法（具体模式和库） * 11.2 代码实现路径（新 - 强制） * 11.3 依赖关系表（新 - 强制） **第 11.2 节代码实现路径格式**（新）： ### 11.2 代码实现路径 - **主要**：`src/foundation/f1_iam/auth/jwt_auth.py` - **测试**：`tests/foundation/f1_iam/test_jwt_auth.py` - **集成**：`测试/集成/test_auth_endpoints.py` **第 12 节：更改历史记录** * 版本控制表 * 更改描述 6. **实时质量反馈**（通过“质量顾问”技能）： * 生成内容时监控部分完成情况 * 检测反模式（不完整的协议/ABC、缺少模式） * 验证累积标签（第 7 层需要 6 个标签） * 检查元素 ID 格式合规性 (REQ.NN.TT.SS) * 验证接受标准计数 (>=15) * 尽早标记问题以减少生成后的返工 7. **按类型添加元素 ID** ：元素类型 |代码|示例 ---|---|--- 功能需求| 01 |需求.02.01.01 依赖| 05 |要求.02.05.01 验收标准 | 06 |需求.02.06.01 原子要求 | 27 | 27要求.02.27.01 8. **添加累积追溯标签**（需要 6 个）： ## 11.可追溯性 **所需标签**（累积标签层次结构 - 第 7 层）： @brd：BRD.01.01.03 @prd：PRD.01.07.02 @ears：EARS.01.25.01 @bdd：BDD.01.14.01 @adr：ADR-033，ADR-045 @sys：SYS.01.01.01，SYS.01.02.07 9. **添加阈值参考**： ### 参考阈值 |阈值 ID |类别 |价值|来源 | |--------------|----------|--------|--------| | @threshold：PRD.01.perf.api.p95 |性能| 100 毫秒 |珠三角第 14 条 | | @threshold：PRD.01.timeout.Circuit_breaker |超时 | 30 多岁 |珠三角第 20.1 条 | | @threshold：PRD.01.retry.max_attempts |重试 | 3 |珠三角第 20.4 条 | 10. **文件输出**（始终使用嵌套文件夹）： * **单体**（<20k 令牌）：`docs/07_REQ/REQ-NN_{slug}/REQ-NN_{slug}.md` * **基于域** : `docs/07_REQ/{domain}/REQ-NN_{slug}/REQ-NN_{slug}.md` * **子域名** : `docs/07_REQ/{domain}/{subdomain}/REQ-NN_{slug}/REQ-NN_{slug}.md` * **分段**（≥20k 标记）：`docs/07_REQ/REQ-NN_{slug}/REQ-NN.0_index.md`、`REQ-NN.1_core.md` 等。 * **主索引**（始终）：`docs/07_REQ/REQ-00_index.md`（创建或更新） **嵌套文件夹规则**：所有 REQ 使用嵌套文件夹 (`REQ-NN_{slug}/`)，无论大小如何。这可以使伴随文件（审阅报告、修复报告、偏差缓存）与其父文档一起组织起来。 ### 第 4 阶段：REQ 验证 REQ 生成后，验证结构和双重就绪分数。 > **技能委派**：此阶段使用“doc-req-validator”技能中的验证规则。请参阅：`.claude/skills/doc-req-validator/SKILL.md` 了解完整的验证规则。 **验证命令**： ./ai_dev_ssd_flow/07_REQ/scripts/validate_req_template.sh 文档/07_REQ/REQ-NN_{slug}/REQ-NN_{slug}.md python3 ai_dev_ssd_flow/07_REQ/scripts/validate_req_spec_readiness.py docs/07_REQ/REQ-NN_{slug}/REQ-NN_{slug}.md --verbose **验证检查**：检查 |要求 |错误代码 ---|---|--- YAML 前沿 |有效的元数据字段 | REQ-E001 至 REQ-E005 剖面结构|所有 11 个部分均已呈现 |请求-E006 文件控制|所有 14 个必填字段 |请求-E009 接口规格|协议/ABC 定义 |要求-E010，要求-E015 数据模式| JSON 模式或 Pydantic |要求-E011，要求-E016 错误处理 |异常目录|要求-E012，要求-E017 验收标准 | >=15 个标准 | REQ-E013、REQ-W002 元素 ID 格式 | REQ.NN.TT.SS（4 段）|请求-E020 累计标签 |存在 6 个标签 |请求-W003 SPEC-Ready 分数 | >= 90% |请求-W001 IMPL-Ready 分数 | >= 90% |请求-W001 **新验证检查 (v2.0)** ：检查 |要求 |错误代码 ---|---|--- 单元测试类别 |全部 5 个类别均已呈现 |请求-E025 交叉链接部分|第 10.5 条存在 |请求-E026 错误目录深度|记录了 ≥5 个错误代码 |请求-E027 复苏策略|恢复表存在|请求-E028 代码路径|第 11.2 条呈现 |请求-E029 验收标准计数 |总标准≥15 |请求-E030 交流分体 | 9.1 功能 + 9.2 质量 |请求-E031 原子分解|如果策略=原子 | ≥3 个文件请求-E032 依赖关系表|第 11.3 条呈现 |请求-E033 索引文件| REQ-NN.00_index.md 存在 |请求-E034 **自动修复操作**：问题 |自动修复操作 ---|--- 缺少部分 |从模板插入缺少协议/ABC |添加界面模板缺少 JSON 架构 |添加架构模板缺少异常目录|添加错误处理模板验收标准 < 15 |添加占位符条件元素 ID 格式无效 |转换为 REQ.NN.TT.SS 格式缺少累积标签 |添加占位符引用缺少 SPEC-Ready 分数 |计算并插入 **验证循环**：循环（最多 3 次迭代）： 1. 运行 doc-req-validator 2. 如果发现错误：应用自动修复 3. 如果发现警告：如果严重，则进行审查并解决 4. IF SPEC-Ready 分数 < 90%：增强部分 5. 如果 IMPL-Ready 分数 < 90%：添加实施指南 6. 如果干净：标记为“已验证”，继续 7. IF 最大迭代次数：记录问题、手动审核标记 ### 第 5 阶段：审核和修复周期 (v2.1) 迭代审查和修复周期，以确保完成前的 REQ 质量。流程图TD A[第 5 阶段开始] --> B[运行 doc-req-reviewer] B --> C[生成审核报告] C --> D{评论分数 >= 90?} D -->|是| E[通过 - 进行最终检查] D -->|否| F{迭代 < 最大值？} F -->|是| G[运行 doc-req-fixer] G --> H[应用修复] H --> I[生成修复报告] I --> J[增量迭代] J --> B F -->|否| K[手动审核标志] K --> L[生成包含剩余问题的最终报告] 左--> 右 #### 5.1 初步审查运行“doc-req-reviewer”来识别问题。 /doc-req-审稿人 REQ-NN **输出**：`REQ-NN.R_review_report_v001.md` #### 5.2 修复周期如果评论分数 < 90%，则调用“doc-req-fixer”。 /doc-req-fixer REQ-NN --重新验证 **修复类别**：类别 |已应用的修复 ---|--- 丢失文件 |创建索引、参考文档失效链接 |更新路径，创建目标元素 ID |转换旧模式（AC-XXX、FR-XXX、R-XXX），修复无效的类型代码内容 |替换模板占位符，更新日期参考文献 |更新可追溯性标签、@threshold 引用交叉链接|添加缺失的@discoverability标签标准|添加缺少的测试类别前缀，添加占位符标准 **输出**：`REQ-NN.F_fix_report_v001.md` #### 5.3 重新审查修复后，自动重新运行审阅者。 /doc-req-审稿人 REQ-NN **输出**：`REQ-NN.R_review_report_v002.md` #### 5.4 迭代控制参数|默认 |描述 ---|---|--- `最大迭代次数` | 3 |最大修复审查周期 `目标分数` | 90 | 90最低及格分数 `停止_手动` |假 |如果仅存在手动问题，请停止 **迭代示例**：迭代 1：评论 v001：得分 84（4 个错误，6 个警告）修复 v001：修复 8 个问题，更新 3 个文件迭代 2：评论 v002：得分 92（0 个错误，4 个警告）状态：通过（分数 >= 90） #### 5.5 质量检查（修复后）经过修复周期后： 1. **12 部分完整性** : * 所有 11 个部分均已存在并具有实质性内容 * 没有占位符或存根内容 * 模板版本 = 3.0 2. **累积标签验证**（需要 6 个标签）： * @brd 标签引用有效的 BRD 元素 * @prd 标签引用有效的 PRD 元素 * @ears 标签引用有效的 EARS 元素 * @bdd 标签引用有效的 BDD 元素 * @adr 标签引用有效的 ADR 文档 * @sys标签引用有效的SYS元素 3. **阈值参考验证**： * 所有@threshold标签都引用有效的PRD阈值 * 品质属性中没有魔法数字 * 阈值与源匹配 4. **原子需求原则**： * 每个 REQ 定义单一职责 * 验收标准是可衡量的 * 独立，无需外部上下文 * 使用模态语言（SHALL/SHOULD/MAY） 5. **双重准备分数报告**： REQ 准备分数明细 ============================= SPEC 就绪分数：接口完整性：20/20 数据架构：15/15 错误处理：15/15 配置：10/10 质量属性：15/15 实施指南：10/10 接受标准：10/10 可追溯性：5/5 ---------------------------- SPEC 就绪总数：100/100（目标：>= 90） IMPL 就绪分数：实施指南：25/25 架构模式：20/20 并发处理：15/15 DI 模式：15/15 算法规范：15/15 测试策略：10/10 ---------------------------- IMPL 就绪总数：100/100（目标：>= 90）状态：准备好创建规范/IMPL 6. **可追溯性矩阵更新**： # 更新 REQ-00_TRACEABILITY_MATRIX.md python ai_dev_ssd_flow/scripts/update_traceability_matrix.py \ --req docs/07_REQ/REQ-NN_{slug}/REQ-NN_{slug}.md \ --矩阵文档/07_REQ/REQ-00_TRACEABILITY_MATRIX.md ** ** ## REQ MVP 部分参考 ### 必填部分（共 11 个）部分|目的|所需元素 ---|---|--- 文件控制|元数据 | 14 个字段，包括双重准备分数 1\.描述 |原子要求 |应/应该/可以语言、上下文 2\.功能需求|核心能力| REQ.NN.01.SS格式，业务规则 3\.接口规格| API、协议 |协议/ABC、DTO、REST 端点 4\.数据模式|模型、验证| JSON 模式、Pydantic、数据库 5\.错误处理 |异常，恢复|异常目录、断路器 6\.配置|设置、标志 | YAML 架构、环境变量 7\.质量属性|性能、安全| p50/p95/p99，@threshold 参考文献 8\.实施指南|模式、算法 | DI、并发、架构 9\.验收标准 |测试条件| >=15 个标准，5 个类别 10\.验证方法|测试| BDD、单元、集成、合同 11\.溯源 |参考文献 | 6个累积标签 **注意**：REQ MVP 中故意省略了更改历史记录。 ** ** ## 执行模式 ### 单系统模式从一个 SYS 文档生成 REQ。 # 示例：从 SYS-01 生成 REQ /doc-req-autopilot SYS-01 --输出文档/07_REQ/ ### 批处理模式从多个 SYS 文件按顺序生成 REQ。 # 示例：从所有 SYS 生成 REQ /doc-req-autopilot all --auto **批量配置** (`config/req_batch.yaml`)：请求生成： - ID：“01” slug：“订单验证” 系统：“SYS-01” 域名：“交易” 优先级：1 - ID：“02” slug：“风险限制” 系统：“SYS-02” 领域：“风险” 优先级：1 - ID：“03” slug：“数据收集” 系统：“SYS-03” 域：“数据” 优先级：2 执行：平行：假快速失败：真 ### 试运行模式预览执行计划而不生成文件。 /doc-req-autopilot SYS-01 --dry-run ### 审阅模式 (v2.1) 验证现有 REQ 文档并生成未经修改的质量报告。 **目的**：审核现有 REQ 文档的合规性、质量分数并识别问题。 **命令**： # 查看单个 REQ 文件夹 /doc-req-autopilot REQ-01 --模式审查 # 查看所有 REQ 文件夹 /doc-req-autopilot all --mode review \ --output-report tmp/req_review_report.md **审核流程**：流程图TD A[输入：现有 REQ] --> B[加载 REQ 文件] B --> C[验证 11 部分结构] C --> D[检查原子分解] D --> E[验证双重分数] E --> F[检查交叉链接] F --> G[确定问题] G --> H{生成报告} H --> I[可修复问题列表] H --> J[手动审核项目] H --> K[双分细分] I --> L[输出：审查报告] J --> L K --> L **审查报告结构**： # REQ 审核报告：REQ-01_f1_iam ## 总结 - **SPEC-Ready 分数**：88% 🟡 - **IMPL 就绪分数**：85% 🟡 - **文件总数**：12 个原子 REQ 文件 - **总问题**：15 - **可自动修复**：11 - **手动审核**：4 ## 双分数分析 ### SPEC-Ready 分数 (88%) |组件|分数 |状态 | |------------|--------|--------| |接口完整性| 18/20 | 🟡 | |数据架构| 14/15 | 14/15 ✅ | |错误处理 | 13/15 | 🟡 | |配置| 9/10 | ✅ | |质量属性| 14/15 | 14/15 ✅ | |实施指南| 8/10 | 🟡 | |验收标准 | 9/10 | ✅ | |溯源 | 5/5 | ✅ | ### IMPL 就绪分数 (85%) |组件|分数 |状态 | |------------|--------|--------| |实施指南| 22/25 | 22/25 🟡 | |架构模式| 18/20 | 🟡 | |并发处理 | 13/15 | 🟡 | | DI 模式 | 14/15 | 14/15 ✅ | |算法规范| 12/15 | 12/15 | 🟡 | |测试策略| 9/10 | ✅ | ## 原子分解检查 |检查 |状态 |详情 | |--------|--------|---------| |索引文件存在 | ✅ | REQ-01.00_index.md 存在 | |交叉链接有效 | 🟡 | 3 个文件丢失@discoverability | |第11.2节代码路径| ❌ | 4 个文件缺少实现路径 | |验收标准计数 | 🟡 | 2 个文件低于 15 个标准 | ## v2.0 合规性 |检查 |状态 |详情 | |--------|--------|---------| |现有 12 个部分 | ✅ |所有原子文件均已完成 | |元素 ID 格式 | 🟡 |找到 2 个旧 ID | |测试类别前缀 | ❌ |缺少[逻辑]/[验证]标签 | |恢复策略表| ❌ | 3 个文件丢失恢复表 | | @threshold 参考文献 | ✅ |所有数值参数化| | 6 累计标签 | ✅ |全部到场| ## 自动修复问题 | ＃|问题 |地点 |修复行动| |---|--------|----------|------------| | 1 |缺少@discoverability | REQ-01.03 |添加交叉链接标签 | | 2 |旧元素 ID | REQ-01.05：L45 |将 AC-001 转换为 REQ.01.06.01 | | 3 |缺少测试类别 | REQ-01.07：AC-003 |添加[逻辑]前缀| | ... | ... | ... | ... | ## 需要人工审核 | ＃|问题 |地点 |原因 | |---|--------|----------|--------| | 1 |接口规范不完整| REQ-01.04：S3 |所需领域知识 | | 2 |缺少算法| REQ-01.08：S8 |需要架构决策 | | ... | ... | ... | ... | **查看配置**：审查模式：启用：真检查： -section_completeness # 所有 11 个部分 -atomic_decomposition # 文件结构 - element_id_compliance # REQ.NN.TT.SS 格式 - Acceptance_criteria # >= 15 计数 - cross_links # @discoverability 标签 -cumulative_tags # 6 个上游标签 - Dual_score_calculation # SPEC 就绪 + IMPL 就绪 - test_categories # [逻辑]/[验证]前缀输出：格式：降价 include_fix_suggestions：true 阈值：规格准备通过：90 impl_ready_pass：90 警告：85 ### 修复模式 (v2.1) 自动修复现有 REQ 文档，同时保留手动内容。 **目的**：对 REQ 文档应用自动修复，以提高质量分数和合规性。 **命令**： # 修复单个 REQ 文件夹 /doc-req-autopilot REQ-01 --模式修复 # 通过备份修复 /doc-req-autopilot REQ-01 --模式修复 \ --备份 # 仅修复特定问题类型 /doc-req-autopilot REQ-01 --模式修复 \ --fix-types“element_ids、sections、cross_links” # 试运行修复（预览更改） /doc-req-autopilot REQ-01 --模式修复 \ --试运行 **修复类别和操作**：类别 |问题 |自动修复操作 |保留内容 ---|---|---|--- **元素 ID** |旧版 AC-XXX 格式 |转换为 REQ.NN.06.SS | ✅ **元素 ID** |旧版 FR-XXX 格式 |转换为 REQ.NN.01.SS | ✅ **元素 ID** |旧版 R-XXX 格式 |转换为 REQ.NN.27.SS | ✅ **章节** |缺少部分 |从模板插入 | ✅ **章节** |缺少 SPEC-Ready 分数 |计算并插入 | ✅ **章节** |缺少 IMPL-Ready 分数 |计算并插入 | ✅ **交叉链接** |缺少@discoverability |添加相关 REQ 参考 | ✅ **交叉链接** |缺少第 10.5 节 |添加交叉链接部分 | ✅ **标准** |缺少测试类别 |添加[逻辑]/[验证]前缀 | ✅ **标准** |计数低于 15 |添加占位符条件 | ✅ **可追溯性** |缺少累积标签 |添加占位符引用 | ✅ **索引** |过时的能力矩阵 |从文件重新生成 | ✅ **内容保存规则**： 1. **永远不要删除**现有的验收标准 2. **永远不要修改**功能需求文本 3. **永不改变**接口规格 4. **仅添加**缺少的部分和元数据 5. **仅转换**旧元素 ID 6. **首先备份** 如果设置了 `--backup` 标志 **修复报告结构**： # REQ 修复报告：REQ-01_f1_iam ## 总结 - **在 SPEC-Ready 之前分数**：88% 🟡 - **SPEC-Ready 分数**后：94% ✅ - **IMPL-Ready 分数之前**：85% 🟡 - **IMPL-Ready 分数之后**：92% ✅ - **已修复的问题**：11 - **剩余问题**：4（需要手动审核） ## 应用的修复 | ＃|问题 |地点 |修复已应用 | |---|--------|----------|-------------| | 1 |旧元素 ID | REQ-01.05：L45 |转换后的 AC-001 → REQ.01.06.01 | | 2 |缺少@discoverability | REQ-01.03 |添加了 REQ-01.01、REQ-01.11 的交叉链接 | | 3 |缺少测试类别 | REQ-01.07：AC-003 |添加了[逻辑]前缀 | | 4 |低于 15 个标准 | REQ-01.09 |添加了 3 个占位符条件 | | ... | ... | ... | ... | ## 文件修改 - 文档/07_REQ/REQ-01_f1_iam/REQ-01.00_index.md - 文档/07_REQ/REQ-01_f1_iam/REQ-01.03_token_replication.md - 文档/07_REQ/REQ-01_f1_iam/REQ-01.05_rbac_enforcement.md - 文档/07_REQ/REQ-01_f1_iam/REQ-01.07_permission_inheritance.md - 文档/07_REQ/REQ-01_f1_iam/REQ-01.09_mfa_integration.md ## 备份位置 -tmp/备份/REQ-01_f1_iam_20260209_143022/ ## 双分影响 ### 规范就绪 |组件|之前 |之后 |达美航空 | |------------|--------|--------|--------| |接口完整性| 18/20 | 19/20 | +1 | |错误处理 | 13/15 | 15/15 | 15/15 +2 | |验收标准 | 9/10 | 10/10 | 10/10 +1 | ### IMPL 就绪 |组件|之前 |之后 |达美航空 | |------------|--------|--------|--------| |实施指南| 22/25 | 22/25 24/25 | 24/25 +2 | |架构模式| 18/20 | 19/20 | +1 | |算法规范| 12/15 | 12/15 | 14/15 | 14/15 +2 | ## 后续步骤 1. REQ-01.04中完整的接口规范 2. 在REQ-01.08中添加算法详细信息 3. 重新运行验证以确认分数 **修复配置**：修复模式：启用：真备份：启用：真位置：“tmp/备份/” 保留天数：7 修复类别： element_ids: true # 旧版 ID 转换 sections: true # 缺少必需的部分 cross_links: true # @discoverability 标签 criteria: true # 接受标准 Traceability: true # 累计标签 index: true # 重新生成索引保存： Acceptance_criteria: true # 永远不要删除条件功能要求：true 接口规格：true 评论：真实验证： re_validate_after_fix: true 要求分数改进：假最大修复迭代次数：3 元素 ID 迁移： AC_XXX_to_REQ_NN_06_SS: true # AC-001 → REQ.01.06.01 FR_XXX_to_REQ_NN_01_SS：真 # FR-001 → REQ.01.01.01 R_XXX_to_REQ_NN_27_SS：真 # R-001 → REQ.01.27.01 **命令行选项（检查/修复）**：选项|模式|默认 |描述 ---|---|---|--- `--模式审查` |评论 | - |仅运行审阅模式 `--模式修复` |修复 | - |运行修复模式 `--输出报告` |两者 |汽车 |报告输出路径 `--备份` |修复 |真实 |修复前创建备份 `--修复类型` |修复 |全部 |以逗号分隔的修复类别 `--试运行` |修复 |假 |预览修复而不应用 `--保留全部` |修复 |假 |格外谨慎保存 ** ** ## 配置 ### 默认配置 #config/req_autopilot.yaml 要求自动驾驶仪：版本：“2.0” # v2.0 中的新功能：原子分解设置分解：策略：原子#原子|整体|汽车 min_files: 3 # 原子分解的最小文件数 max_file_size_kb: 30 # 超过则触发额外分割 create_index: true # 生成 REQ-NN.00_index.md require_cross_links: true # 强制执行第 10.5 节得分：请求就绪时间：90 规格就绪最小值：90 impl_ready_min: 90 严格模式：假执行： max_parallel: 3 # 硬限制 - 不要超过 chunk_size: 3 # 每个块的文档块间暂停：true 自动修复：真错误时继续：错误 timeout_per_sys: 300 # 秒输出：结构：atomic#atomic（默认v2.0）|整体|汽车大小阈值kb：30 报告格式：降价验证：跳过验证：假最大修复迭代次数：3 # v2.0 中的新功能：增强的验证规则最低接受标准：15 require_test_categories: true # [逻辑]/[验证]/等 require_error_catalog: true # 完整的错误表 require_recovery_strategy: true # 恢复表 require_code_paths: true # 第 11.2 节强制评论：启用：真检查部分：true 检查标签：true 检查阈值：true check_atomicity: true auto_fix_sections：true 最低接受标准：15 # v2.0 中的新功能 check_cross_links: true check_test_categories：true ### 命令行选项选项 |默认 |描述 ---|---|--- `--min-req-ready` | 90 | 90最低 REQ-Ready 分数 (SYS) `--min-spec-ready` | 90 | 90最低 SPEC-Ready 分数 (REQ) `--min-impl-ready` | 90 | 90最低 IMPL 就绪分数 (REQ) `--无自动修复` |假 |禁用自动修复（仅限手动） `--错误时继续` |假 |如果一个 SYS 失败则继续 `--试运行` |假 |仅预览执行计划 `--输出格式` |汽车 |强制平坦、基于域或分段 `--跳过审查` |假 |跳过最终审核阶段 `--domain` |汽车 |输出路径的强制域 ** ** ## 输出工件 ### 生成的文件 **所有 REQ 都使用嵌套文件夹** (`REQ-NN_{slug}/`)，无论大小如何。文档分段（整体与分段）仅取决于文档大小（>20k 标记 = 分段）。文件|目的|地点 ---|---|--- REQ-NN_{slug}/| REQ 文件夹（始终创建）| `docs/07_REQ/` 或 `docs/07_REQ/{domain}/` REQ-NN_{slug}.md |主要 REQ 文档（整体 <20k 代币）| `文档/07_REQ/REQ-NN_{slug}/` REQ-NN.0_index.md |分段索引（分段≥20k 标记）| `文档/07_REQ/REQ-NN_{slug}/` REQ-NN.S_{部分}.md |分段文件（分段≥20k 标记）| `文档/07_REQ/REQ-NN_{slug}/` REQ-NN.R_review_report_v{VVV}.md |审核报告| `文档/07_REQ/REQ-NN_{slug}/` REQ-NN.F_fix_report_v{VVV}.md |修复报告 | `文档/07_REQ/REQ-NN_{slug}/` .drift_cache.json |漂移检测缓存| `文档/07_REQ/REQ-NN_{slug}/` ### 验证报告报告|目的|地点 ---|---|--- req_validation_report.json |验证结果| `tmp/` spec_ready_score.json | SPEC-Ready 细分 | `tmp/` impl_ready_score.json | IMPL-Ready 细分 | `tmp/` autopilot_log.md |执行日志| `tmp/` ** ** ## 错误处理 ### 错误类别类别 |处理|示例 ---|---|--- 系统丢失|中止并显示消息 |未找到 SYS 文件 REQ-Ready 低于 90% |自动修复 SYS，重试 | SYS 分数为 85% 验证失败 |自动修复，重试 |缺少必填部分 SPEC-Ready 低于 90% |增强部分，重试 |得分88% IMPL 就绪率低于 90% |添加实施指南 |得分为 87% 超过最大重试次数 |手动审核标记|持续错误 ### 恢复行动 def handle_error(error_type: str, context: dict) -> 操作：匹配错误类型：案例“SYS_MISSING”：返回 Action.ABORT_WITH_MESSAGE 情况“REQ_READY_LOW”：返回 Action.AUTO_FIX_SYS 案例“VALIDATION_FAILURE”：如果上下文[“重试次数”] < 3：返回 Action.AUTO_FIX_RETRY 返回 Action.FLAG_MANUAL_REVIEW 情况“SPEC_READY_LOW”：返回 Action.ENHANCE_SECTIONS 案例“IMPL_READY_LOW”：返回 Action.ADD_IMPLMENTATION_GUIDANCE 案例_：返回 Action.FLAG_MANUAL_REVIEW ** ** ## 上下文管理 ### 分块并行执行（强制） **关键**：为了防止对话上下文溢出错误（“提示太长”、“对话太长”），所有自动驾驶仪操作必须遵循分块执行规则： **块大小限制**：每个块最多 3 个文档 **分块规则**： 1. **Chunk Formation** ：将 SYS 派生的 REQ 文档分组为一次最多 3 个的块 2. **顺序块处理**：一次处理一个块，在开始下一个块之前完成一个块中的所有文档 3. **上下文暂停**：完成每个块后，提供摘要并暂停以供用户确认 4. **进度跟踪**：显示块进度（例如，“块 2/4：处理 REQ-04、REQ-05、REQ-06...”） **为什么需要分块**： * 防止批处理期间出现“对话太长”错误 * 允许块之间的上下文压缩 * 能够从故障中恢复而不丢失所有进度 * 为用户审查提供自然检查点 **执行模式**：对于来自多个 SYS 文档的 REQ 批处理：第 1 块：REQ-01、REQ-02、REQ-03 → 完整 → 摘要 [上下文压缩机会] 大块 2：REQ-04、REQ-05、REQ-06 → 完整 → 摘要 [上下文压缩机会] ...继续直到处理完所有文件 **块完成模板**： ## 块 N/M 已完成生成： - REQ-XX：SPEC 就绪 94%，IMPL 就绪 92% - REQ-YY：SPEC 就绪 91%，IMPL 就绪 93% - REQ-ZZ：SPEC 就绪 95%，IMPL 就绪 94% 继续下一个块... ** ** ## 集成点 ### 预执行挂钩 # 挂钩：pre_req_ Generation # 在 REQ 生成开始之前运行 ./hooks/pre_req_ Generation.sh # 示例：验证 SYS 是否存在并准备就绪如果[！ -f“docs/06_SYS/SYS-01_*.md”];然后 echo“错误：需要 SYS-01” 1号出口菲 ### 执行后挂钩 # 挂钩：post_req_ Generation # REQ 生成完成后运行 ./hooks/post_req_ Generation.sh # 示例：触发 SPEC 自动驾驶仪以验证 REQ 如果[“$REQ_VALIDATED”=“真”];然后 /doc-spec-autopilot“$REQ_PATH”--输出文档/09_SPEC/ 菲 ### CI/CD 集成 # .github/workflows/req_autopilot.yml 名称：REQ自动驾驶仪于：推：路径： - '文档/06_SYS/**' 职位：生成请求：运行：ubuntu-latest 步骤： - 使用：actions/checkout@v4 - 名称：运行 REQ 自动驾驶仪运行： | /doc-req-autopilot all --auto --validate - 名称：上传验证报告使用：actions/upload-artifact@v4 与：名称：请求验证路径：tmp/req_validation_report.json ** ** ## 质量门 ### 相位门相|门 |标准 ---|---|--- 第一阶段 |输入门|至少找到一个 SYS 文件第二阶段 |准备门|系统要求就绪分数 >= 90% 第三阶段|一代门|生成所有 11 个部分第四阶段 |验证门 | SPEC 就绪 >= 90% 且 IMPL 就绪 >= 90% 第五阶段 |评论门 |不存在任何阻塞问题 ### 阻塞与非阻塞问题类型 |封锁|行动 ---|---|--- 缺少必填部分 |是的 |在继续之前必须修复 SPEC-Ready 分数 < 90% |是的 |必须加强部分 IMPL 就绪分数 < 90% |是的 |必须添加实施指南验收标准 < 15 |是的 |必须添加更多标准缺少协议/ABC |是的 |必须添加接口定义缺少@threshold标签|没有 |记录警告，继续样式/格式问题 |没有 |自动修复，继续 ** ** ## 验证清单自动驾驶完成后： * 生成所有目标REQ文档 * 每个 REQ 的 SPEC-Ready 分数 >= 90% * 每个 REQ 的 IMPL-Ready 分数 >= 90% * 每个 REQ 使用模板版本 3.0 * 已完成所有 12 个必填部分 * 更新了可追溯性矩阵 (`REQ-00_TRACEABILITY_MATRIX.md`) * 每个 REQ 引用所有 6 个上游标签（@brd、@prd、@ears、@bdd、@adr、@sys） * 第 3 部分：接口规范有协议/ABC 定义 * 第 4 节：数据模式具有 JSON 模式或 Pydantic 模型 * 第 5 节：错误处理有异常目录 * 第 7 节：质量属性有 @threshold 引用 * 第 9 部分：验收标准有 >= 15 个可衡量标准 * 元素 ID 使用 REQ.NN.TT.SS 格式（代码：01、05、06、27） * 无旧版 ID 模式（AC-XXX、FR-XXX、R-XXX） * 每个需求都是原子的（单一责任） ** ** ## 快速参考输入|输出|关键指标 ---|---|--- 系统|需求| SPEC 就绪 >= 90%，IMPL 就绪 >= 90% **用法**： /doc-req-autopilot <系统列表> [选项] **常用命令**： # 单个系统 /doc-req-自动驾驶仪 SYS-01 # 所有系统（自动） /doc-req-autopilot all --auto # 仅预览 /doc-req-autopilot all --dry-run # 失败后恢复 /doc-req-自动驾驶仪简历 # 基于域的输出 /doc-req-autopilot SYS-01 --域风险 ** ** ## 相关资源 ### 技能（委派） * **REQ Skill** : `.claude/skills/doc-req/SKILL.md` \- REQ 创建规则和 11 节结构 * **REQ Validator Skill** : `.claude/skills/doc-req-validator/SKILL.md` \- 验证规则和错误代码 * **SYS 验证器技能** : `.claude/skills/doc-sys-validator/SKILL.md` \- SYS 准备情况验证 * **质量顾问技能** : `.claude/skills/quality-advisor/SKILL.md` \- 实时质量反馈 * **命名标准技能** : `.claude/skills/doc-naming/SKILL.md` \- 元素 ID 格式 ### 模板和规则 * **请求模板** : `ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.md` * **请求架构**：`ai_dev_ssd_flow/07_REQ/REQ_MVP_SCHEMA.yaml` * **REQ 创建规则** : `ai_dev_ssd_flow/07_REQ/REQ_MVP_CREATION_RULES.md` * **REQ 验证规则** : `ai_dev_ssd_flow/07_REQ/REQ_MVP_VALIDATION_RULES.md` ### 部分拆分参考（适用于 >50KB 的文档） * 参考：`ai_dev_ssd_flow/ID_NAMING_STANDARDS.md`（基于部分的文件分割） ### 框架参考 * **SDD 工作流程** : `ai_dev_ssd_flow/SPEC_DRIVEN_DEVELOPMENT_GUIDE.md` * **MVP 自动驾驶仪** : `ai_dev_ssd_flow/AUTOPILOT/MVP_AUTOPILOT.md` * **SYS 自动驾驶仪技能** ：`.claude/skills/doc-sys-autopilot/SKILL.md`（如果可用） * **EARS 自动驾驶仪技能** : `.claude/skills/doc-ears-autopilot/SKILL.md` ** ** ## 审查文档标准 (v2.2) 此技能生成的审核报告是正式的项目文件，并且必须符合共享标准。 **参考**：请参阅技能目录中的“REVIEW_DOCUMENT_STANDARDS.md”以了解完整的要求。 **关键要求**： 1. **存储位置**：与审核的 REQ 文档相同的文件夹 2. **文件命名**：首选`REQ-NN.A_audit_report_vNNN.md`；旧版兼容 `REQ-NN-SSS.R_review_report_vNNN.md` 或 `REQ-NN.R_review_report_vNNN.md` 3. **YAML Frontmatter** ：需要 `artifact_type: REQ-REVIEW`、`layer: 7` 4. **分数字段**：`spec_ready_score_claimed/validated` 和 `impl_ready_score_claimed/validated` 5. **父级参考**：必须链接到父级 REQ 文档 **位置示例**：文档/07_REQ/REQ-03_f3_可观察性/ ├── REQ-03.0_index.md ├── REQ-03-001_telemetry_collection.md ├── REQ-03-002_metrics_export.md └── REQ-03.A_audit_report_v001.md # ← 首选合并审计报告 ** ** ## 版本历史版本 |日期 |变化 ---|---|--- 2.4 | 2.4 2026-02-11 | **智能文档检测**：新增文档类型自动识别；自类型输入（REQ-NN）触发审阅模式；上游类型输入（SYS-NN）触发“缺失时生成”或“查找并审查”；使用基于类型的操作更新了输入模式表 2.3 | 2.3 2026-02-10 | **审核和修复周期**：将第 5 阶段替换为迭代审核 -> 使用 `doc-req-reviewer` 和 `doc-req-fixer` 修复周期；添加了`doc-req-fixer`技能依赖；第 5 阶段现在包括流程图、迭代控制和质量检查部分 (5.1-5.5) 2.2 | 2.2 2026-02-10 |新增审核文件标准部分；审阅报告现在与审阅的文档一起存储，并具有适当的 YAML frontmatter 和父引用 2.1 | 2.1 2026-02-09 |添加了审核模式，用于验证现有 REQ 文件而不进行修改；添加修复模式，用于自动修复 REQ 文档，同时保留手动内容；添加了修复类别（element_ids、sections、cross_links、criteria、traceability、index）；新增内容保存规则；增加了修复操作的备份功能；添加了具有双重评分影响的审查/修复报告生成（SPEC-Ready + IMPL-Ready）；添加了元素 ID 迁移支持（AC_XXX、FR_XXX、R_XXX 统一格式） 2.0 | 2026-02-09 | **主要增强**：添加了基于 Trading Nexus REQ 层分析的阶段 1.5 原子分解；新的原子文件输出（每个模块 10-15 个文件）；增强第 8 节，带有单元测试类别前缀（[逻辑]/[验证]/[状态]/[边缘]/[安全]）；新的第 10.5 节带有@discoverability 标签的交叉链接；增强了第 11 节，包含强制性代码实现路径 (11.2) 和依赖关系表 (11.3)；增强了错误目录格式和恢复策略表；至少 15 个验收标准分为功能 (10+) 和质量 (5+)；新验证规则 REQ-E025 至 REQ-E032 1.0 | 2026-02-08 |通过 5 阶段工作流程创建初始技能；集成文档命名、文档请求、文档请求验证、质量顾问技能；新增REQ v3.0 12节结构；双重就绪评分（SPEC-Ready + IMPL-Ready）；需要 6 个累积标签（@brd、@prd、@ears、@bdd、@adr、@sys）；元素 ID 类型 01/05/06/27

文档要求自动驾驶仪

包含技能