# 文档任务自动驾驶仪 ## 目的自动**任务分解 (TASKS)** 生成管道，可处理 SPEC 和 TSPEC 文档以生成 AI 结构的 TODO 任务，以便通过 CODE-Ready 评分实施。 **层**：11（代码之前的最终文档层） **上游**：SPEC（第 9 层）、TSPEC（第 10 层） **下游**：代码（第 12 层 - 执行层） ** ** ## 输入合同（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 格式（TASKS.NN.TT.SS，代码 18、30）|所有阶段 `文档规范验证器` |验证 SPEC TASKS-Ready 分数 |第二阶段 `doc-tspec-验证器` |验证 TSPEC TASKS-Ready 分数 |第二阶段 `文档任务` |任务创建规则，TODO 格式 |第三阶段 `质量顾问` |实时质量反馈 |第三阶段 `文档任务验证器` |使用 CODE-Ready 评分进行验证 |第四阶段 `文档任务审核` |统一验证器 + 审阅器包装器输出 |第五阶段：审计 `文档任务审阅者` |内容审核、链接验证、质量评分 |第五阶段：审查 `文档任务修复程序` |应用审核/审查报告中的修复，创建丢失的文件 |第五阶段：修复 ** ** ## 文件类型合同（强制）当生成 TASKS 文档实例时，自动驾驶仪必须： 1. **从模板中读取** `instance_document_type`： * 来源：`ai_dev_ssd_flow/11_TASKS/TASKS-MVP-TEMPLATE.yaml` * 字段：`metadata.instance_document_type：“任务文档”` 2. **在生成的文档 frontmatter 中设置** `document_type`：自定义字段： document_type: 任务文档 # 不是“模板” 工件类型：任务层数：11 3. **验证**：生成的文档必须具有`document_type：tasks-document` * 模板有 `document_type: template` * 实例具有`document_type:tasks-document` * 模式验证这两个值 **错误处理**：如果模板中缺少“instance_document_type”，则默认为“tasks-document”。 ** ** ## 智能文档检测自动驾驶仪根据输入文档类型自动确定操作。 ### 输入类型识别（多个上游）任务可以从 SPEC 和/或 TSPEC 导出：输入 |检测为 |行动 ---|---|--- `任务-NN` |自型 |审查现有的任务文档 `SPEC-NN` |主要上游 |缺失则生成，存在则查看 `TSPEC-NN` |替代上游 |缺失则生成，存在则查看 ### 检测算法 1.解析输入：从“{TYPE}-{NN}”中提取TYPE和NN 2. 确定行动： - IF TYPE ==“TASKS”：审阅模式 - ["SPEC", "TSPEC"] 中的 ELSE IF TYPE：生成/查找模式 - ELSE：错误（此自动驾驶仪的类型无效） 3. 对于生成/查找模式： - 检查：TASKS-{NN} 是否存在于 docs/11_TASKS/ 中？ - 如果存在：切换到 TASKS-{NN} 的审阅模式 - ELSE：继续从 {TYPE}-{NN} 生成 ### 文件存在性检查 # 检查嵌套文件夹结构（强制） ls 文档/11_TASKS/TASKS-{NN}_*/ ### 示例 # 审阅模式（相同类型 - 任务输入） /doc-tasks-autopilot TASKS-01 # 审查现有 TASKS-01 # 生成/查找模式（上游类型） /doc-tasks-autopilot SPEC-01 # 如果缺失则生成 TASKS-01，或查看现有 TASKS-01 /doc-tasks-autopilot TSPEC-01 # 如果缺失则生成 TASKS-01，或查看现有 TASKS-01 # 多个输入 /doc-tasks-autopilot SPEC-01,SPEC-02 # 生成/审查 TASKS-01 和 TASKS-02 /doc-tasks-autopilot TASKS-01,TASKS-02 # 评论 TASKS-01 和 TASKS-02 ### 行动确定输出输入：SPEC-01 ├── 检测类型：SPEC（主要上游） ├── 预期任务：TASKS-01 ├── 任务存在：是 → docs/11_TASKS/TASKS-01_f1_iam/ └── 行动：审核模式 - 在 TASKS-01 上运行 doc-tasks-reviewer 输入：TSPEC-05 ├── 检测类型：TSPEC（替代上游） ├── 预期任务：TASKS-05 ├── 任务是否存在：无 └── 行动：生成模式 - 从 TSPEC-05 创建 TASKS-05 输入：TASKS-03 ├── 检测类型：TASKS（自身） └── 行动：审查模式 - 在 TASKS-03 上运行 doc-tasks-reviewer ** ** ## 工作流程概述流程图TD 子图 Phase1[“阶段 1：SPEC/TSPEC 分析”] A[开始] --> B[阅读规格文档] B --> C[阅读 TSPEC 文档] C --> D[提取实现单元] D --> E[摘录测试要求] E --> F[目录工作项] 结束 subgraph Phase2[“阶段2：任务分解规划”] F --> G[检查 SPEC TASKS-Ready 分数] G --> H[检查 TSPEC TASKS-Ready 分数] H --> I{都 >= 90%？} 我-->|不| J[旗帜问题] J --> K{自动修复？} K -->|是| L[修复问题] 左--> 右 K -->|否| M[中止 - 需要手动修复] 我-->|是| N[计划任务分解] N --> O[识别依赖关系] 结束子图 Phase3["阶段 3：任务生成"] O --> P[生成实施任务] P --> Q[生成测试任务] Q --> R[构建依赖图] R --> S[分配优先级] S --> T[质量顾问：实时反馈] T --> U[生成实施合同] U --> V[添加可追溯性标签] V --> W[写入任务文件] 结束子图 Phase4[“第 4 阶段：任务验证”] W --> X[运行 doc-tasks-validator] X --> Y{代码就绪 >= 90%？} 是-->|否| Z[自动修复任务问题] Z --> AA[重新验证任务] AA --> Y 是 -->|是| AB[标记任务已验证] 结束子图 Phase5[“第 5 阶段：审查和修复周期”] AB --> AC[运行 doc-tasks-reviewer] AC --> AC2{分数 >= 90?} AC2 -->|否| AC3[运行 doc-tasks-fixer] AC3 --> AC4{迭代 < 最大值？} AC4 -->|是|交流电 AC4 -->|否| AC5【标志手册评测】 AC2 -->|是| AD[验证质量检查] AC5 --> AD AD --> AE[更新追踪矩阵] AE --> AF[生成总结报告] 结束 AF --> AG[完成] M --> AI[错误退出] ** ** ## 任务结构 ### 元素 ID 格式元素类型 |代码|图案|示例 ---|---|---|--- 任务| 18 | 18任务.NN.18.SS |任务.01.18.01 任务项| 30|任务.NN.30.SS |任务.01.30.01 ### 优先级优先|代码|描述 ---|---|--- P0|关键|必须先完成，阻止所有其他 P1 |高|核心功能 P2 |中等|重要但不阻塞 P3 |低|很高兴拥有，可以推迟 ** ** ## 任务文档结构 # TASKS-01：组件实现 ## 文件控制 |领域 |价值| |--------|--------| |状态 |草稿| |代码就绪分数 | 95% | ## 1. 任务概述来自 SPEC-01 的实施任务摘要。 ## 2. 依赖图 ````美人鱼图解TD T1[任务.01.18.01] --> T2[任务.01.18.02] T1 --> T3[任务.01.18.03] T2 --> T4[任务.01.18.04] T3 --> T4 ## 3\.实施任务 ### TASKS.01.18.01：设置项目结构 * **优先级**：P0 * **上游**：无 * **下游**：TASKS.01.18.02、TASKS.01.18.03 * **规格参考**：SPEC.01.28.01 * **估计复杂性**：2/5 ### TASKS.01.18.02：实现核心逻辑 * **优先级**：P1 * **上游**：TASKS.01.18.01 * **下游**：TASKS.01.18.04 * **规格参考**：SPEC.01.28.02 ## 7\.实施合同 [协议接口、异常层次结构、状态机契约] ## 8\.可追溯性 @brd：BRD.01.01.01 @prd：PRD.01.09.01 ... --- ## 实施合同根据“IMPLMENTATION_CONTRACTS_GUIDE.md”，在以下情况下生成合同： - TASKS 文件有 3 个以上下游依赖项 - 跨多个会话共享接口 - 复杂的状态机或异常层次结构 **合同类型**： 1. 协议接口 2. 异常层次结构 3. 状态机合约 4. 数据模型 5. 依赖注入接口 --- ## 第 5 阶段：审核和修复周期 (v2.3) 迭代审查和修复周期，以确保任务完成前的质量。 ````美人鱼流程图TD A[第 5 阶段开始] --> B[运行 doc-tasks-reviewer] B --> C[生成审核报告] C --> D{评论分数 >= 90?} D -->|是| E[通过 - 进入第 6 阶段] D -->|否| F{迭代 < 最大值？} F -->|是| G[运行 doc-tasks-fixer] G --> H[应用修复] H --> I[生成修复报告] I --> J[增量迭代] J --> B F -->|否| K[手动审核标志] K --> L[生成包含剩余问题的最终报告] 左--> 右 ### 5.1 初步审查运行“doc-tasks-reviewer”来识别问题。 /doc-tasks-审阅者 TASKS-NN **输出**：`TASKS-NN.R_review_report_v001.md` ### 5.2 修复周期如果评论分数 < 90%，则调用“doc-tasks-fixer”。 /doc-tasks-fixer TASKS-NN --revalidate **修复类别**：类别 |已应用的修复 ---|--- 缺失部分 |添加缺少的任务概述、合同部分元素 ID |转换旧模式（TASK-XXX、TODO-XXX）依赖图 |从任务引用重新生成美人鱼图优先格式|标准化为 P0-P3 格式实施合同|当存在 3 个以上依赖项时生成溯源 |更新累积标签（9层） **输出**：`TASKS-NN.F_fix_report_v001.md` ### 5.3 重新审查修复后，自动重新运行审阅者。 /doc-tasks-审阅者 TASKS-NN **输出**：`TASKS-NN.R_review_report_v002.md` ### 5.4 迭代控制参数|默认 |描述 ---|---|--- `最大迭代次数` | 3 |最大修复审查周期 `目标分数` | 90 | 90最低及格分数 `停止_手动` |假 |如果仅存在手动问题，请停止 **迭代示例**：迭代 1：审核 v001：得分 75（3 个错误，5 个警告）修复 v001：修复 6 个问题，重新生成依赖图迭代 2：评论 v002：得分 92（0 个错误，2 个警告）状态：通过（分数 >= 90） ### 5.5 质量检查（修复后）经过修复周期后： 1. **任务结构完整性**： * 存在所有必填任务字段（优先级、上游、下游） * SPEC 参考有效且已链接 * 提供复杂性估计 2. **依赖图有效性**： * 有效的 DAG（无循环依赖） * 所有任务引用均已解决 * 美人鱼图正确渲染 3. **元素 ID 合规性**（根据“文档命名”技能）： * 所有ID均使用TASKS.NN.TT.SS格式 * 对任务有效的元素类型代码 (18, 30) * 无遗留模式（TASK-XXX、TODO-XXX、TI-XXX） 4. **代码就绪报告**： CODE-Ready 分数细分 ========================= 任务完成度：24/25（所有必填字段）依赖图：20/20（有效 DAG）优先级分配：15/15（已分配 P0-P3）实施合同：14/15（需要时签订合同）可追溯性标签：15/15（所有 9 个标签均存在） SPEC/TSPEC 对齐：10/10（参考有效） ---------------------------- CODE-Ready 总分：98/100（目标：>= 90）状态：代码实施就绪 5. **可追溯性矩阵更新**： # 更新任务可追溯性 python ai_dev_flow/scripts/update_traceability_matrix.py \ --tasks docs/11_TASKS/TASKS-NN_{slug}.md \ --矩阵文档/11_TASKS/TASKS-00_TRACEABILITY_MATRIX.md ** ** ## 累计标签（需要 9 个） @brd：BRD.NN.TT.SS @prd：PRD.NN.TT.SS @ears：EARS.NN.TT.SS @bdd：BDD.NN.TT.SS @adr：ADR-NN @sys：SYS.NN.TT.SS @req：REQ.NN.TT.SS @spec：SPEC.NN.TT.SS @tspec：TSPEC.NN.TT.SS @ctr: CTR.NN.TT.SS # 可选 ** ** ## 配置 ### 默认配置任务_自动驾驶仪：版本：“1.0” 得分：任务准备就绪分钟：90 代码就绪分钟：90 严格模式：假执行： max_parallel: 3 # 硬限制 - 不要超过 chunk_size: 3 # 每个块的文档块间暂停：true 自动修复：真错误时继续：错误 timeout_per_spec: 180 # 秒输出：报告格式：降价验证：跳过验证：假最大修复迭代次数：3 合同：生成_when_dependency_gte：3 include_protocol_interfaces: true include_exception_hierarchies: true include_state_machines: true ** ** ## 执行模式 ### 模式 1：生成模式（默认）从 SPEC/TSPEC 文档生成标准任务（请参阅上面的工作流程概述）。 ### 模式 2：审阅模式 (v2.1) 验证现有 TASKS 文档而不进行修改。生成带有可行建议的质量报告。 **命令**： # 查看单个任务 /doc-tasks-autopilot TASKS-01 --review # 查看目录中的所有任务 /doc-tasks-autopilot docs/11_TASKS/ --review --all # 审查并提供详细报告 /doc-tasks-autopilot TASKS-01 --review --verbose **审核流程**：流程图TD A[输入：TASKS 文档] --> B[加载 TASKS 内容] B --> C[验证任务结构] C --> D[检查 CODE-Ready 分数] D --> E[验证依赖关系图] E --> F[验证元素 ID] F --> G[检查实施合同] G --> H[验证累积标签] H --> I[生成审核报告] I --> J{发现问题？} J -->|是| K[问题分类] K --> L[生成修复建议] L --> M[输出审核报告] J -->|否|中号 **审查报告模板**： # 任务审核报告：TASKS-NN_{slug} ## 总结 - **代码就绪分数**：NN% (✅/🟡/❌) - **问题总数**：N（E 错误，W 警告） - **可自动修复**：N 个问题 - **手动审核**：N 个问题 ## 分数明细 |类别 |分数 |最大|状态 | |----------|--------|-----|--------| |任务完成度|神经网络 | 25 | 25 ✅/🟡/❌ | |依赖图 |神经网络 | 20 | ✅/🟡/❌ | |优先任务 |神经网络 | 15 | 15 ✅/🟡/❌ | |实施合同|神经网络 | 15 | 15 ✅/🟡/❌ | |可追溯性标签 |神经网络 | 15 | 15 ✅/🟡/❌ | | SPEC/TSPEC 对齐 |神经网络 | 10 | 10 ✅/🟡/❌ | ## 按类别划分的问题 ### 自动修复问题 |问题 |地点 |修复行动| |--------|----------|------------| |旧版 ID 图案 | 45号线 |转换 TASK-001 → TASKS.01.18.01 | |缺少累积标签 |溯源 |添加@sys：SYS.01.01.01 | ### 需要手动审核 |问题 |地点 |推荐| |--------|----------|----------------| |循环依赖| T3 ↔ T5 |重构任务依赖关系 | |缺少复杂性 |任务.04.01.18 |添加估计的复杂性 | **分数指标**： * ✅ 绿色 (>=90%)：代码就绪 * 🟡黄色（70-89%）：需要改进 * ❌红色（<70%）：重大问题 **查看配置**：审查模式：启用：真检查： - task_struct # 存在所有必需的任务字段 - dependency_graph # 有效的 DAG，无循环 -priority_assignments # P0-P3 正确分配 -implementation_contracts # 当 3 个以上依赖项时的合约 -cumulative_tags # 存在 9 个必需标签 - element_ids # TASKS.NN.18.SS、TASKS.NN.30.SS 格式 -spec_alignment # 任务跟踪 SPEC/TSPEC 输出：格式：markdown # markdown, json, html include_recommendations: true include_fix_commands: true ### 模式 3：修复模式 (v2.1) 通过备份和内容保留自动修复现有任务文档。 **命令**： # 修复单个任务 /doc-tasks-autopilot TASKS-01 --fix # 通过备份修复 /doc-tasks-autopilot TASKS-01 --fix --backup # 修复所有任务 /doc-tasks-autopilot docs/11_TASKS/ --fix --all # 仅修复特定类别 /doc-tasks-autopilot TASKS-01 --fix --only element_ids,tags # 试运行修复（预览更改） /doc-tasks-autopilot TASKS-01 --fix --dry-run **修复过程**：流程图TD A[输入：TASKS 文档] --> B[创建备份] B --> C[加载任务内容] C --> D[运行审查分析] D --> E{自动修复问题？} E -->|否| F[报告：无需修复] E -->|是| G[按类别应用修复] 子图 FixCategories["修复类别"] G --> H[固定元素 ID] H --> I[固定优先级格式] I --> J[重新生成依赖图] J --> K[添加缺少的标签] K --> L[固定节结构] L --> M[添加实施合同] 结束 M --> N[验证固定文档] N --> O{验证通过？} 哦-->|否| P[回滚到备份] P --> Q[报告：修复失败] 哦-->|是| R[保存固定文档] R --> S[生成修复报告] **特定于任务的修复类别**：类别 |描述 |自动修复操作 ---|---|--- `element_ids` |元素 ID 格式 |将旧模式转换为 TASKS.NN.TT.SS `优先事项` |优先格式 |标准化为 P0-P3 格式 `依赖关系图` |任务依赖关系|从任务引用重新生成美人鱼图 `累积标签` |追溯标签|添加缺失的 9 个上游标签 `部分` |剖面结构|添加缺少的概述、合同部分 `合同` |实施合同|当存在 3 个以上依赖项时生成 `circular_deps` |循环依赖|仅标志（需要手动重组） **元素 ID 迁移**（第 11 层）：传统模式|新格式 |示例 ---|---|--- 任务-NNN |任务.NN.18.SS |任务-001 → 任务.01.18.01 TODO-NNN |任务.NN.18.SS | TODO-005 → 任务.01.18.05 TI-NNN |任务.NN.30.SS | TI-001 → 任务.01.30.01 项目-NNN |任务.NN.30.SS | ITEM-010 → 任务.01.30.10 **内容保存规则**：内容类型 |保存规则 ---|--- 自定义任务描述 |从不删除，只增强元数据依赖关系 |保留逻辑，更新格式优先任务|保留值，标准化格式实施合同|保留所有合约代码复杂性估计 |保留值，如果缺失则添加 SPEC/TSPEC 参考资料 |仅验证和更新格式 **修复配置**：修复模式：启用：真备份：启用：真位置：“tmp/备份/” 时间戳：真修复类别： element_ids: true # 转换旧版 ID 模式 priorities: true # 规范化 P0-P3 格式 dependency_graph: true # 重新生成美人鱼图 cumulative_tags: true # 添加 9 个必需标签 sections: true # 添加缺失的部分 Contracts: true # 满足条件时生成 circular_deps: false # 仅手动（标记但不自动修复）验证： post_fix: true # 修复后验证 rollback_on_fail: true # 如果验证失败则恢复备份保留：任务描述：true 依赖逻辑：真优先级值： true 合约代码：true **修复报告模板**： # 任务修复报告：TASKS-NN_{slug} ## 总结 - **已创建备份**：tmp/backups/TASKS-NN_{slug}_20260209_143022.md - **已修复的问题**：可自动修复的问题中的 N 个 - **手动审核**：标记了 N 个问题 ## 应用的修复 ### 元素 ID 迁移 |原创|固定|地点 | |----------|--------|----------| |任务-001 |任务.01.01.18 | 45号线 | | TI-001 |任务.01.30.01 | 78 号线 | ### 重新生成依赖图 - 更新了美人鱼图并修正了任务参考 - 任务总数：12，依赖项：18 ### 累计添加标签 - @ears：EARS.01.25.001（已添加） - @sys：SYS.01.01.01（已添加） - @req：REQ.01.01.01（已添加） ### 生成实施合同 - 协议接口：`IDataProcessor`（TASKS.01.18.03有4个依赖项） - 异常层次结构：`TaskExecutionError`系列 ## 需要人工审核 ### 循环依赖 |循环|涉及的任务 |推荐| |--------------------|----------------|----------------| |周期 1 | T3 → T5 → T3 |重组：T5不应依赖于T3 | ## 验证结果 - **CODE-Ready 分数**：之前：72% → 之后：94% - **验证错误**：之前：8 → 之后：0 - **状态**： ✅ 所有自动修复均已验证 **命令行选项**（检查/修复模式）：选项 |默认 |描述 ---|---|--- `--评论` |假 |仅运行审阅模式 `--修复` |假 |运行修复模式 `--备份` |真实|修复前创建备份 `--试运行` |假 |预览修复而不应用 `--仅` |全部 |以逗号分隔的修复类别 `--详细` |假 |详细输出 `--全部` |假 |处理目录中的所有任务 `--输出格式` |降价|报告格式（markdown、json） `--重新生成合同` |假 |强制重新生成实施合同 ** ** ## 上下文管理 ### 分块并行执行（强制） **关键**：为了防止对话上下文溢出错误（“提示太长”、“对话太长”），所有自动驾驶仪操作必须遵循分块执行规则： **块大小限制**：每个块最多 3 个文档 **分块规则**： 1. **Chunk Formation** ：将 SPEC/TSPEC 派生的 TASKS 文档分组为一次最多 3 个的块 2. **顺序块处理**：一次处理一个块，在开始下一个块之前完成一个块中的所有文档 3. **上下文暂停**：完成每个块后，提供摘要并暂停以供用户确认 4. **进度跟踪** ：显示块进度（例如，“块 2/4：处理 TASKS-04、TASKS-05、TASKS-06...”） **为什么需要分块**： * 防止批处理期间出现“对话太长”错误 * 允许块之间的上下文压缩 * 能够从故障中恢复而不丢失所有进度 * 为用户审查提供自然检查点 **块完成模板**： ## 块 N/M 已完成生成： - TASKS-XX：代码就绪分数 94% - TASKS-YY：代码就绪分数 92% - TASKS-ZZ：代码就绪分数 95% 继续下一个块... ** ** ## 相关资源 * **任务技能** : `.claude/skills/doc-tasks/SKILL.md` * **任务验证器** : `.claude/skills/doc-tasks-validator/SKILL.md` * **命名标准** : `.claude/skills/doc-naming/SKILL.md` * **质量顾问** : `.claude/skills/quality-advisor/SKILL.md` * **任务模板** : `ai_dev_flow/11_TASKS/TASKS-TEMPLATE.md` * **实施合同** : `ai_dev_flow/11_TASKS/IMPLMENTATION_CONTRACTS_GUIDE.md` ** ** ## 审查文档标准 (v2.2) 此技能生成的审核报告是正式的项目文件，并且必须符合共享标准。 **参考**：请参阅技能目录中的“REVIEW_DOCUMENT_STANDARDS.md”以了解完整的要求。 **关键要求**： 1. **存储位置**：与审阅的TASKS文档相同的文件夹 2. **文件命名**：`TASKS-NN.R_review_report_vNNN.md`（旧版）或`TASKS-NN.A_audit_report_vNNN.md`（首选） 3. **YAML Frontmatter** ：需要 `artifact_type: TASKS-REVIEW`、`layer: 11` 4. **分数字段** : `code_ready_score_claimed` / `code_ready_score_validated` 5. **父级参考**：必须链接到父级 TASKS 文档 **示例位置**（始终使用嵌套文件夹）：文档/11_TASKS/TASKS-03_f3_observability/ ├── TASKS-03_f3_observability.md # ← 主文档 ├── TASKS-03.R_review_report_v001.md # ← 审核报告 ├── TASKS-03.F_fix_report_v001.md # ← 修复报告 └── .drift_cache.json # ← 漂移缓存 **嵌套文件夹规则**：所有任务都使用嵌套文件夹 (`TASKS-NN_{slug}/`)，无论大小如何。这可以使伴随文件（审阅报告、修复报告、偏差缓存）与其父文档一起组织起来。 ** ** ## 版本历史版本 |日期 |变化 ---|---|--- 2.4 | 2.4 2026-02-11 | **智能文档检测**：新增文档类型自动识别；自类型输入（TASKS-NN）触发审阅模式；多个上游类型输入（SPEC/TSPEC-NN）触发“缺失时生成”或“查找并审查”；使用基于类型的操作更新了输入模式表 2.3 | 2.3 2026-02-10 | **审核和修复周期**：将第 5 阶段替换为迭代审核 -> 使用 `doc-tasks-reviewer` 和 `doc-tasks-fixer` 修复周期；添加了“doc-tasks-fixer”技能依赖；添加迭代控制（最多 3 个周期）；添加了质量检查（任务结构完整性、依赖图有效性、元素 ID 合规性、CODE-Ready 报告）；添加了追溯矩阵更新步骤 2.2 | 2.2 2026-02-10 |新增审核文件标准部分；审阅报告现在与审阅的文档一起存储，并具有适当的 YAML frontmatter 和父引用 2.1 | 2.1 2026-02-09 |添加了模式 2：使用视觉分数指示器进行仅验证分析的审核模式；新增模式3：修复模式，自动修复并备份和内容保存；元素ID迁移（TASK-NNN→TASKS.NN.18.SS、TI-NNN→TASKS.NN.30.SS）；实施合同自动生成 1.0 | 2026-02-08 |通过 5 阶段工作流程创建初始技能；集成文档命名、文档任务、质量顾问、文档任务验证器；添加了实施合同支持

文档任务自动驾驶仪

包含技能