# doc-tspec-自动驾驶仪 ## 目的自动**测试规范 (TSPEC)** 生成管道，可处理 SPEC 文档，为 UTEST、ITEST、STEST 和 FTEST 生成全面的测试规范，并带有 TASKS-Ready 评分。 **层**：10 **上游**：SPEC（第 9 层） **下游**：任务（第 11 层） ** ** ## 输入合同（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 格式（TSPEC.NN.TT.SS，代码 40-43）|所有阶段 `文档规范验证器` |验证 SPEC TASKS-Ready 分数 |第二阶段 `doc-tspec` | TSPEC 创建规则、测试类型结构 |第三阶段 `质量顾问` |实时质量反馈 |第三阶段 `doc-tspec-验证器` |使用 TASKS-Ready 评分进行验证 |第四阶段 `doc-tspec-审计` |用于修复者移交的统一验证者+审阅者报告 |第五阶段：审核 `doc-tspec-审稿人` |内容审核、链接验证、质量评分 |第五阶段：审查 `doc-tspec-fixer` |应用审查报告中的修复，创建丢失的文件 |第五阶段：修复 ** ** ## 文件类型合同（强制）生成 TSPEC 文档实例时，自动驾驶仪必须： 1. **从模板中读取** `instance_document_type`： * 来源：`ai_dev_ssd_flow/10_TSPEC/TSPEC-MVP-TEMPLATE.yaml` * 字段：`metadata.instance_document_type：“tspec-document”` 2. **在生成的文档 frontmatter 中设置** `document_type`：自定义字段： document_type: tspec-document # NOT “模板” 工件类型：TSPEC 层数：10 3. **验证**：生成的文档必须具有 `document_type: tspec-document` * 模板有 `document_type: template` * 实例具有 `document_type: tspec-document` * 模式验证这两个值 **错误处理**：如果模板中缺少“instance_document_type”，则默认为“tspec-document”。 ** ** ## 智能文档检测自动驾驶仪根据输入文档类型自动确定操作。 ### 输入类型识别输入 |检测为 |行动 ---|---|--- `TSPEC-NN` |自型 |审查现有 TSPEC 文档 `SPEC-NN` |上游型 |缺失则生成，存在则查看 ### 检测算法 1.解析输入：从“{TYPE}-{NN}”中提取TYPE和NN 2. 确定行动： - IF TYPE ==“TSPEC”：审核模式 - ELSE IF TYPE == "SPEC"：生成/查找模式 - ELSE：错误（此自动驾驶仪的类型无效） 3. 对于生成/查找模式： - 检查：docs/10_TSPEC/ 中是否存在 TSPEC-{NN}？ - 如果存在：切换到 TSPEC-{NN} 的查看模式 - ELSE：继续从 SPEC-{NN} 生成 ### 文件存在性检查 # 检查嵌套文件夹结构（强制） ls 文档/10_TSPEC/TSPEC-{NN}_*/ ### 示例 # 审阅模式（相同类型 - TSPEC 输入） /doc-tspec-autopilot TSPEC-01 # 审查现有 TSPEC-01 # 生成/查找模式（上游类型 - SPEC 输入） /doc-tspec-autopilot SPEC-01 # 如果缺失则生成 TSPEC-01，或查看现有的 TSPEC-01 # 多个输入 /doc-tspec-autopilot SPEC-01,SPEC-02 # 生成/审查 TSPEC-01 和 TSPEC-02 /doc-tspec-autopilot TSPEC-01,TSPEC-02 # 评论 TSPEC-01 和 TSPEC-02 ### 行动确定输出输入：SPEC-01 ├── 检测类型：SPEC（上游） ├── 预期TSPEC：TSPEC-01 ├── TSPEC 存在：是→ docs/10_TSPEC/TSPEC-01_f1_iam/ └── 行动：审查模式 - 在 TSPEC-01 上运行 doc-tspec-reviewer 输入：SPEC-05 ├── 检测类型：SPEC（上游） ├── 预期TSPEC：TSPEC-05 ├── TSPEC 是否存在: 否 └── 行动：生成模式 - 从 SPEC-05 创建 TSPEC-05 输入：TSPEC-03 ├── 检测类型：TSPEC（自身） └── 行动：审查模式 - 在 TSPEC-03 上运行 doc-tspec-reviewer ** ** ## 工作流程概述流程图TD 子图 Phase1[“第 1 阶段：SPEC 分析”] A[开始] --> B[阅读规格文档] B --> C[提取方法] C --> D[提取接口] D --> E[提取数据模型] E --> F[目录测试目标] 结束子图 Phase2[“第 2 阶段：测试覆盖率规划”] F --> G[检查 SPEC TASKS-Ready 分数] G --> H{分数 >= 90%？} H -->|否| I[标记 SPEC 问题] I --> J{自动修复？} J -->|是| K[修复规格问题] K --> G J -->|否| L[中止 - 需要手动修复] H -->|是| M[计划测试覆盖率] M --> N[分配测试类型] 结束子图 Phase3[“第 3 阶段：TSPEC 生成”] N --> O[生成 UTEST 规格] O --> P[生成 ITEST 规格] P --> Q[生成 STEST 规格] Q --> R[生成 FTEST 规格] R --> S[质量顾问：实时反馈] S --> T[构建覆盖矩阵] T --> U[添加可追溯性标签] U --> V[写入 TSPEC 文件] 结束子图 Phase4[“第 4 阶段：TSPEC 验证”] V --> W[运行 doc-tspec-validator] W --> X{任务就绪 >= 90%？} X -->|否| Y[自动修复 TSPEC 问题] Y --> Z[重新验证 TSPEC] Z --> X X -->|是| AA[标记 TSPEC 验证] 结束子图 Phase5[“第 5 阶段：审查和修复周期”] AA --> AB[运行 doc-tspec-reviewer] AB --> AB2{分数 >= 90?} AB2 -->|否| AB3[运行 doc-tspec-fixer] AB3 --> AB4{迭代 < 最大值？} AB4 -->|是| AB AB4 -->|否| AB5【旗帜手册评测】 AB2 -->|是| AC[验证质量检查] AB5 --> 交流 AC --> AD[更新追踪矩阵] AD --> AE[生成总结报告] 结束 AE --> AF[完成] L --> AG[错误退出] ** ** ## 测试类型类型 |代码|目的|目标 ---|---|---|--- **UT测试** | 40 | 40单元测试 |单独的函数/方法 **测试** | 41 | 41集成测试|组件交互 **测试** | 42 | 42烟雾测试|关键路径验证 **FT测试** | 43 | 43功能测试|端到端工作流程 **测试测试** | 44 | 44性能测试|负载和压力测试 **秘密测试** | 45 | 45安全测试|漏洞和威胁测试 ** ** ## TSPEC 结构 **所有 TSPEC 都使用嵌套文件夹** (`TSPEC-NN_{slug}/`)。这使得测试规范文件和配套文件组织在一起。文档/10_TSPEC/ ├── TSPEC-01_认证/ │ ├── TSPEC-01.0_index.md # 套件索引 │ ├── TSPEC-01.1_utest.md # 单元测试 │ ├── TSPEC-01.2_itest.md # 集成测试 │ ├── TSPEC-01.3_stest.md # 冒烟测试 │ ├── TSPEC-01.4_ftest.md # 功能测试 │ ├── TSPEC-01.A_audit_report_v001.md # 合并审计报告（首选） │ ├── TSPEC-01.R_review_report_v001.md # 审核报告（旧版兼容） │ ├── TSPEC-01.F_fix_report_v001.md # 修复报告 │ └── .drift_cache.json # 漂移缓存 └── TSPEC-01_authentication.md # 重定向存根（可选） ** ** ## 覆盖矩阵格式规格元素 | UT测试|测试|测试| FTEST |覆盖范围 ---|---|---|---|---|--- 规格.01.28.01 | TSPEC.01.40.01 | TSPEC.01.41.01 | TSPEC.01.42.01 | - | 75% 规格.01.28.02 | TSPEC.01.40.02 | TSPEC.01.41.02 | - | TSPEC.01.43.01 | 75% ** ** ## 元素 ID 格式测试类型|代码|图案|示例 ---|---|---|--- UT测试| 40| TSPEC.NN.40.SS | TSPEC.01.40.01 测试| 41 | 41 TSPEC.NN.41.SS | TSPEC.01.41.01 测试| 42 | 42 TSPEC.NN.42.SS | TSPEC.01.42.01 FTEST | 43 | 43 TSPEC.NN.43.SS | TSPEC.01.43.01 测试测试 | 44 | 44 TSPEC.NN.44.SS | TSPEC.01.44.01 教派测试 | 45 | 45 TSPEC.NN.45.SS | TSPEC.01.45.01 ** ** ## 第 5 阶段：审核和修复周期 (v2.3) 迭代审查和修复周期以确保完成前的 TSPEC 质量。流程图TD A[第 5 阶段开始] --> B[运行 doc-tspec-audit] B --> C[生成合并审计报告] C --> D{审核通过且分数 >= 90？} D -->|是| E[通过 - 进入第 6 阶段] D -->|否| F{迭代 < 最大值？} F -->|是| G[运行 doc-tspec-fixer] G --> H[应用修复] H --> I[生成修复报告] I --> J[增量迭代] J --> B F -->|否| K[手动审核标志] K --> L[生成包含剩余问题的最终报告] 左--> 右 ### 5.1 初步审查运行“doc-tspec-audit”以执行验证者+审阅者检查并生成统一的修复程序就绪报告。 /doc-tspec-audit TSPEC-NN **输出**：“TSPEC-NN.A_audit_report_v001.md”（首选），保留“.R_review_report_vNNN.md”兼容性。 ### 5.2 修复周期如果评论分数 < 90%，则调用“doc-tspec-fixer”。 /doc-tspec-fixer TSPEC-NN --revalidate **修复类别**：类别 |已应用的修复 ---|--- 缺少测试类型 |创建缺失的 UTEST/ITEST/STEST/FTEST 文件失效链接 |更新规格参考元素 ID |转换旧模式（UT-XXX、IT-XXX 等）覆盖矩阵|从测试规范重新生成测试结构|添加每个测试类型模板缺失的部分溯源 |更新累积标签（8层） **输出**：`TSPEC-NN.F_fix_report_v001.md` ### 5.3 重新审查修复后，自动重新运行审核。 /doc-tspec-audit TSPEC-NN **输出**：“TSPEC-NN.A_audit_report_v002.md”（首选），具有旧版“.R_”兼容性。 ### 5.4 迭代控制参数|默认 |描述 ---|---|--- `最大迭代次数` | 3 |最大修复审查周期 `目标分数` | 90 | 90最低及格分数 `停止_手动` |假 |如果仅存在手动问题，请停止 **迭代示例**：迭代 1：评论 v001：得分 78（2 个错误，6 个警告）修复 v001：修复了 5 个问题，创建了 1 个测试文件迭代 2：评论 v002：得分 91（0 个错误，2 个警告）状态：通过（分数 >= 90） ### 5.5 质量检查（修复后）经过修复周期后： 1. **测试类型完整性**： * 提供所有 4 种测试类型（UTEST、ITEST、STEST、FTEST） * 每个测试类型文件都有必需的部分 * 没有剩余的占位符文本 2. **覆盖矩阵精度**： * 所有 SPEC 元素都有测试覆盖率 * 正确计算覆盖率 * 每个测试类型均达到目标覆盖率 3. **元素 ID 合规性**（根据“文档命名”技能）： * 所有 ID 均使用 TSPEC.NN.TT.SS 格式 * 对 TSPEC 有效的元素类型代码（40、41、42、43） * 无遗留模式（UT-XXX、IT-XXX、ST-XXX、FT-XXX） 4. **任务就绪报告**：任务-就绪分数细分 =========================== 测试类型完整性：25/25（所有 4 种类型均存在）覆盖率矩阵：18/20（达到覆盖率目标）规格对齐：20/20（测试跟踪至规格）元素 ID 格式：15/15（有效格式）可追溯性标签：10/10（需要 8 个标签）测试断言：8/10（存在断言） ---------------------------- 任务就绪总分数：96/100（目标：>= 90）状态：准备好生成任务 5. **可追溯性矩阵更新**： # 更新 TSPEC 可追溯性 python ai_dev_ssd_flow/scripts/update_traceability_matrix.py \--tspec 文档/10_TSPEC/TSPEC-NN_{slug}/ \--矩阵文档/10_TSPEC/TSPEC-00_TRACEABILITY_MATRIX.md --- ## 累计标签（需要 8 个） ``降价 @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 @ctr: CTR.NN.TT.SS # 可选 ** ** ## 配置 ### 默认配置 tspec_自动驾驶仪：版本：“1.0” 得分：任务准备就绪分钟：90 严格模式：假执行： max_parallel: 3 # 硬限制 - 不要超过 chunk_size: 3 # 每个块的文档块间暂停：true 自动修复：真错误时继续：错误 timeout_per_spec: 180 # 秒输出：结构：每个 TSPEC 分为 # 4 个测试类型文件报告格式：降价验证：跳过验证：假最大修复迭代次数：3 测试类型：测试：正确伊斯特：真实测试：正确测试：正确 ** ** ## 执行模式 ### 模式 1：生成模式（默认）从 SPEC 文档生成标准 TSPEC（请参阅上面的工作流程概述）。 ### 模式 2：审阅模式 (v2.1) 验证现有 TSPEC 文档而不进行修改。生成带有可行建议的质量报告。 **命令**： # 查看单个 TSPEC /doc-tspec-自动驾驶仪 TSPEC-01 --review # 查看目录中的所有 TSPEC /doc-tspec-autopilot docs/10_TSPEC/ --review --all # 审查并提供详细报告 /doc-tspec-自动驾驶仪 TSPEC-01 --review --verbose **审核流程**：流程图TD A[输入：TSPEC 文档] --> B[加载 TSPEC 内容] B --> C[验证测试结构] C --> D[检查任务就绪分数] D --> E[验证所有 4 种测试类型] E --> F[验证覆盖范围矩阵] F --> G[检查元素 ID] G --> H[验证累积标签] H --> I[生成审核报告] I --> J{发现问题？} J -->|是| K[问题分类] K --> L[生成修复建议] L --> M[输出审核报告] J -->|否|中号 **审查报告模板**： # TSPEC 审核报告：TSPEC-NN_{slug} ## 总结 - **任务就绪分数**：NN% (✅/🟡/❌) - **问题总数**：N（E 错误，W 警告） - **可自动修复**：N 个问题 - **手动审核**：N 个问题 ## 测试类型覆盖率 |类型 |文件 |测试 |覆盖范围|状态 | |------|------|--------|----------|--------| | UT测试| TSPEC-NN.1_utest.md |尼 | NN% | ✅/🟡/❌ | |测试| TSPEC-NN.2_itest.md |尼 | NN% | ✅/🟡/❌ | |测试| TSPEC-NN.3_stest.md |尼 | NN% | ✅/🟡/❌ | | FTEST | TSPEC-NN.4_ftest.md |尼 | NN% | ✅/🟡/❌ | ## 分数明细 |类别 |分数 |最大|状态 | |----------|--------|-----|--------| |测试类型完整性 |神经网络 | 25 | 25 ✅/🟡/❌ | |覆盖矩阵|神经网络 | 20 | ✅/🟡/❌ | |规格对齐|神经网络 | 20 | ✅/🟡/❌ | |元素 ID 格式 |神经网络 | 15 | 15 ✅/🟡/❌ | |可追溯性标签 |神经网络 | 10 | 10 ✅/🟡/❌ | |测试断言 |神经网络 | 10 | 10 ✅/🟡/❌ | ## 按类别划分的问题 ### 自动修复问题 |问题 |地点 |修复行动| |--------|----------|------------| |旧版 ID 图案 | 45号线 |转换 UT-001 → TSPEC.01.40.01 | |缺少累积标签 |溯源 |添加@req：REQ.01.01.01 | ### 需要手动审核 |问题 |地点 |推荐| |--------|----------|----------------| |缺少 STEST 文件 | TSPEC-01.3 |创建烟雾测试规范| |低覆盖率|规格.01.28.05 |为方法添加单元测试 | **分数指标**： * ✅ 绿色 (>=90%)：任务就绪 * 🟡黄色（70-89%）：需要改进 * ❌红色（<70%）：重大问题 **查看配置**：审查模式：启用：真检查： - test_struct # 存在所有 4 个测试类型文件 -coverage_matrix # 覆盖率 >= 每个 SPEC 元素的目标 -spec_alignment # 测试对 SPEC 方法的跟踪 - element_ids # TSPEC.NN.40-43.SS 格式 -cumulative_tags # 存在 8 个必需标签 - test_assertions # 每个测试都有明确的断言输出：格式：markdown # markdown, json, html include_recommendations: true include_fix_commands: true 覆盖范围_目标： utest: 95 # 单元测试覆盖率目标% itest: 85 # 集成测试覆盖率目标% stest: 100 # 冒烟测试必须覆盖关键路径 ftest: 75 # 功能测试覆盖率目标% ### 模式 3：修复模式 (v2.1) 自动修复现有 TSPEC 文档，并进行备份和内容保留。 **命令**： # 修复单个 TSPEC /doc-tspec-自动驾驶仪 TSPEC-01 --fix # 通过备份修复 /doc-tspec-自动驾驶仪 TSPEC-01 --fix --backup # 修复所有 TSPEC /doc-tspec-autopilot docs/10_TSPEC/ --fix --all # 仅修复特定类别 /doc-tspec-autopilot TSPEC-01 --fix --only element_ids,tags # 试运行修复（预览更改） /doc-tspec-自动驾驶仪 TSPEC-01 --fix --dry-run **修复过程**：流程图TD A[输入：TSPEC 文档] --> B[创建备份] B --> C[加载 TSPEC 内容] 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[生成修复报告] **TSPEC 特定修复类别**：类别 |描述 |自动修复操作 ---|---|--- `element_ids` |元素 ID 格式 |将旧模式转换为 TSPEC.NN.TT.SS `测试类型` |测试类型文件 |创建缺失的 UTEST/ITEST/STEST/FTEST 文件 `覆盖矩阵` |覆盖追踪|根据测试规范重新生成矩阵 `累积标签` |追溯标签|添加缺失的 8 个上游标签 `部分` |剖面结构|添加每个测试类型模板缺失的部分 `测试存根` |缺少测试 |为未覆盖的 SPEC 元素生成测试存根 `断言` |测试断言|没有断言的标记测试（手动修复） **元素 ID 迁移**（第 10 层）：传统模式|新格式 |示例 ---|---|--- UT-NNN | TSPEC.NN.40.SS | UT-001 → TSPEC.01.40.01 IT-NNN | TSPEC.NN.41.SS | IT-001 → TSPEC.01.41.01 ST-NNN | TSPEC.NN.42.SS | ST-001 → TSPEC.01.42.01 FT-NNN | TSPEC.NN.43.SS | FT-001 → TSPEC.01.43.01 TC-NNN | TSPEC.NN.40.SS | TC-001 → TSPEC.01.40.01（假设 UTEST）测试-NNN | TSPEC.NN.43.SS | TEST-001 → TSPEC.01.43.01（假设 FTEST） **内容保存规则**：内容类型 |保存规则 ---|--- 自定义测试说明 |从不删除，只增强元数据测试断言|保留所有测试逻辑测试数据/夹具|保留所有测试数据定义规格参考|仅验证和更新格式覆盖率 |修复后重新计算测试先决条件 |保留设置/拆卸逻辑 **修复配置**：修复模式：启用：真备份：启用：真位置：“tmp/备份/” 时间戳：真修复类别： element_ids: true # 转换旧版 ID 模式 test_types: true # 创建缺失的测试类型文件 coverage_matrix: true # 重新生成覆盖跟踪 cumulative_tags: true # 添加8个必需的标签 sections: true # 添加缺失的部分 test_stubs: true # 为未覆盖的 SPEC 生成存根断言： false # 仅手动（标记但不自动修复）验证： post_fix: true # 修复后验证 rollback_on_fail: true # 如果验证失败则恢复备份保留：测试描述：true 测试断言：true 测试数据：真规格参考：真 **修复报告模板**： # TSPEC 修复报告：TSPEC-NN_{slug} ## 总结 - **已创建备份**：tmp/backups/TSPEC-NN_{slug}_20260209_143022/ - **已修复的问题**：可自动修复的问题中的 N 个 - **手动审核**：标记了 N 个问题 ## 应用的修复 ### 元素 ID 迁移 |原创|固定|文件 |地点 | |----------|--------|------|----------| | UT-001 | TSPEC.01.40.01 | TSPEC-01.1_utest.md | 45号线 | | IT-001 | TSPEC.01.41.01 | TSPEC-01.2_itest.md | 23号线 | | ST-001 | TSPEC.01.42.01 | TSPEC-01.3_stest.md | 12 号线 | ### 已创建测试类型文件 |文件 |测试生成 |状态 | |------|-----------------|--------| | TSPEC-01.3_stest.md | 5 次烟雾测试 |从模板创建 | ### 覆盖矩阵重新生成 |规格元素 |之前 |之后 | |--------------|--------|--------| |规格.01.28.01 | 50% | 75% | |规格.01.28.02 | 25% | 75% | |总体 | 45% | 78% | ### 累计添加标签 - @ears：EARS.01.25.001（已添加） - @sys：SYS.01.01.01（已添加） - @req：REQ.01.01.01（已添加） ## 生成测试存根 |规格元素 |测试类型|存根 ID | |--------------|------------|---------| |规格.01.28.05 | UT测试| TSPEC.01.40.12 | |规格.01.28.05 |测试| TSPEC.01.41.08 | ## 需要人工审核 ### 没有断言的测试 |测试ID |文件 |问题 | |--------|------|--------| | TSPEC.01.40.03 | TSPEC-01.1_utest.md |没有断言语句 | | TSPEC.01.41.02 | TSPEC-01.2_itest.md |缺少预期结果 | ### 低覆盖区域 |规格元素 |当前|目标|需要采取行动| |--------------|---------|--------|---------------| |规格.01.28.07 | 25% | 75% |添加 3+ UTEST、1+ ITEST | ## 验证结果 - **任务就绪分数**：之前：68% → 之后：92% - **验证错误**：之前：12 → 之后：0 - **状态**： ✅ 所有自动修复均已验证 **命令行选项**（检查/修复模式）：选项|默认 |描述 ---|---|--- `--评论` |假 |仅运行审阅模式 `--修复` |假 |运行修复模式 `--备份` |真实 |修复前创建备份 `--试运行` |假 |预览修复而不应用 `--仅` |全部 |以逗号分隔的修复类别 `--详细` |假 |详细输出 `--全部` |假 |处理目录中的所有 TSPEC `--输出格式` |降价|报告格式（markdown、json） `--生成存根` |真实 |为未覆盖的 SPEC 生成测试存根 `--测试类型` |全部 |要修复的逗号分隔测试类型 ** ** ## 上下文管理 ### 分块并行执行（强制） **关键**：为了防止对话上下文溢出错误（“提示太长”、“对话太长”），所有自动驾驶仪操作必须遵循分块执行规则： **块大小限制**：每个块最多 3 个文档 **分块规则**： 1. **Chunk Formation** ：将 SPEC 派生的 TSPEC 文档分组为一次最多 3 个的块 2. **顺序块处理**：一次处理一个块，在开始下一个块之前完成一个块中的所有文档 3. **上下文暂停**：完成每个块后，提供摘要并暂停以供用户确认 4. **进度跟踪** ：显示块进度（例如，“块 2/4：处理 TSPEC-04、TSPEC-05、TSPEC-06...”） **为什么需要分块**： * 防止批处理期间出现“对话太长”错误 * 允许块之间的上下文压缩 * 能够从故障中恢复而不丢失所有进度 * 为用户审查提供自然检查点 **块完成模板**： ## 块 N/M 已完成生成： - TSPEC-XX：任务就绪分数 94%（UTEST + ITEST + STEST + FTEST） - TSPEC-YY：任务就绪分数 92%（UTEST + ITEST + STEST + FTEST） - TSPEC-ZZ：任务就绪分数 95%（UTEST + ITEST + STEST + FTEST）继续下一个块... ** ** ## 相关资源 * **TSPEC 技能** : `.claude/skills/doc-tspec/SKILL.md` * **TSPEC 验证器** : `.claude/skills/doc-tspec-validator/SKILL.md` * **命名标准** : `.claude/skills/doc-naming/SKILL.md` * **质量顾问** : `.claude/skills/quality-advisor/SKILL.md` * **TSPEC 模板** : `ai_dev_ssd_flow/10_TSPEC/TSPEC-MVP-TEMPLATE.md` ** ** ## 审查文档标准 (v2.2) 此技能生成的审核报告是正式的项目文件，并且必须符合共享标准。 **参考**：请参阅技能目录中的“REVIEW_DOCUMENT_STANDARDS.md”以了解完整的要求。 **关键要求**： 1. **存储位置**：与审阅的 TSPEC 文档相同的文件夹 2. **文件命名**：`TSPEC-NN.A_audit_report_vNNN.md`（首选）和`TSPEC-NN.R_review_report_vNNN.md`（旧版兼容） 3. **YAML Frontmatter** ：需要 `artifact_type: TSPEC-REVIEW`、`layer: 10` 4. **分数字段** : `impl_ready_score_claimed` / `impl_ready_score_validated` 5. **父级参考**：必须链接到父级 TSPEC 文档 **示例位置**（始终使用嵌套文件夹）：文档/10_TSPEC/TSPEC-03_f3_observability/ ├── TSPEC-03_f3_observability.md # ← 主文档 ├── TSPEC-03.A_audit_report_v001.md # ← 合并审计报告（首选） ├── TSPEC-03.R_review_report_v001.md # ← 审核报告 ├── TSPEC-03.F_fix_report_v001.md # ← 修复报告 └── .drift_cache.json # ← 漂移缓存 **嵌套文件夹规则**：所有 TSPEC 使用嵌套文件夹 (`TSPEC-NN_{slug}/`)，无论大小如何。这可以使伴随文件（审阅报告、修复报告、偏差缓存）与其父文档一起组织起来。 ** ** ## 版本历史版本 |日期 |变化 ---|---|--- 2.6 | 2.6 2026-02-27 |使用“versioning_policy”将 frontmatter 标准化为“metadata”模式；集成的“doc-tspec-audit”审计优先工作流程和输出；将过时的可追溯性命令路径更新为“ai_dev_ssd_flow/scripts/update_traceability_matrix.py”；规范化审阅文档命名指南为版本化“.A_”，首选与“.R_”旧版兼容性 2.5 | 2.5 2026-02-26 |在测试类型和元素 ID 表中添加了 PTEST（代码 44）和 SECTEST（代码 45）支持；修复了 ai_dev_ssd_flow/10_TSPEC/TSPEC-MVP-TEMPLATE.md 的模板路径；修复了 @spec 标记格式以使用破折号表示法 (SPEC-NN) 2.4 | 2.4 2026-02-11 | **智能文档检测**：新增文档类型自动识别；自类型输入（TSPEC-NN）触发审阅模式；上游类型输入（SPEC-NN）触发“缺失时生成”或“查找并审查”；使用基于类型的操作更新了输入模式表 2.3 | 2.3 2026-02-10 | **审核和修复周期**：将第 5 阶段替换为迭代审核 -> 使用 `doc-tspec-reviewer` 和 `doc-tspec-fixer` 修复周期；添加了`doc-tspec-fixer`技能依赖；添加迭代控制（最多 3 个周期）；添加了质量检查（测试类型完整性、覆盖矩阵准确性、元素 ID 合规性、TASKS-Ready 报告）；添加了追溯矩阵更新步骤 2.2 | 2.2 2026-02-10 |新增审核文件标准部分；审阅报告现在与审阅的文档一起存储，并具有适当的 YAML frontmatter 和父引用 2.1 | 2.1 2026-02-09 |添加了模式 2：仅验证分析的审核模式，具有视觉评分指标和覆盖率目标；新增模式3：修复模式，用于自动修复备份、内容保存和测试存根生成；元素 ID 迁移（UT-NNN→TSPEC.NN.40.SS、IT-NNN→TSPEC.NN.41.SS、ST-NNN→TSPEC.NN.42.SS、FT-NNN→TSPEC.NN.43.SS） 1.0 | 2026-02-08 |通过 5 阶段工作流程创建初始技能；集成文档命名、doc-tspec、质量顾问、doc-tspec-validator；支持所有 4 种测试类型

Doc Tspec 自动驾驶仪

包含技能