@ohos-cpf/3rdloop 0.0.2 → 0.0.4

package/vendor/Server/Skills/acceptance-check/SKILL.md

@@ -1,191 +1,191 @@
----
-name: acceptance-check
-description: 对任务执行结果进行准出审核（验收测试），对照任务级验收标准逐条判断是否满足，生成结构化审核报告。当需要对任务产物进行最终验收检查、判断是否达到准出条件时调用。
-license: Apache-2.0
-compatibility: 需要访问任务工作目录、产物文件
-metadata:
-  author: LoopEngine
-  version: "1.1.0"
----
-
-# acceptance-check SKILL — 任务准出审核
-
-## 任务参数
-
-| 参数 | 必需 | 说明 |
-|------|------|------|
-| `taskDescription` | ✅ | 审核任务描述（含原始任务、验收标准、编排结果） |
-| `skillDir` | ✅ | 本 SKILL 目录绝对路径 |
-| `workDir` | ✅ | 任务工作目录，包含所有步骤产物 |
-| `reportPath` | ✅ | 审核报告输出路径 |
-| `summaryPath` | ✅ | 审核摘要输出路径 |
-
----
-
-## 工作流程概览
-
-```
-Phase 1: 产物收集 → Phase 2: 逐条标准评估 → Phase 3: 准出结论 → Phase 4: 报告生成
-```
-
----
-
-## Phase 1：产物收集
-
-### 1.1 扫描工作目录
-
-读取 `workDir` 目录下所有步骤产物文件：
-
-- `stepId{N}_result_{loop}.md` — 各步骤的执行结果报告
-- `stepId{N}_Summary_{loop}.md` — 各步骤的执行摘要
-- 其他生成的文档/报告文件
-
-> 详细文件格式参见 [产物收集指南](references/PHASE1_ARTIFACT_COLLECTION.md)
-
-### 1.2 解析审核任务描述
-
-从 `taskDescription` 中提取：
-
-- **原始任务描述** — 任务的核心目标
-- **任务级验收标准** — 需要逐条验证的标准列表（含 id、criterion、type、verification）
-- **编排结果摘要** — 步骤执行状态、成功/失败统计
-
-### 1.3 汇总产物清单
-
-将所有步骤产物按 stepId 和 loopCount 排序，形成产物清单供后续评估使用。
-
----
-
-## Phase 2：逐条标准评估
-
-### 2.1 对照验收标准
-
-对每个任务级验收标准，检查产物是否满足：
-
-```
-对于每个验收标准 [ac{id}]:
-  1. 读取该标准的内容 (criterion) 和验证方式 (verification)
-  2. 在产物中查找相关证据
-  3. 根据 verification 描述的验证方式执行检查
-  4. 记录评估结论：满足 / 未满足
-  5. 记录支持证据
-```
-
-### 2.2 验证方式分类
-
-根据标准的 `type` 字段采用不同验证策略：
-
-| type | 验证策略 |
-|------|---------|
-| `output` | 检查产物文件是否存在、内容是否完整 |
-| `quality` | 检查产物质量是否达标（如报告覆盖维度、分析深度） |
-| `performance` | 检查性能指标是否满足（如扫描覆盖率、执行时间） |
-| `compliance` | 检查是否符合规范标准（如编码规范、格式要求） |
-
-> 详细评估规则参见 [验收标准评估指南](references/PHASE2_CRITERIA_EVALUATION.md)
-
-### 2.3 关键声明核验规则
-
-对关键声明（分支血缘、产物存在、依赖版本、测试结果）执行核验时，必须遵守：
-
-1. **证据三角验证**：验收判定禁止仅凭前序步骤报告的"成功"结论，关键声明必须与实物产物（文件存在性/大小/时间戳）、现场 git/文件查询（如 `git merge-base` 验证分支血缘、直接读依赖清单原文）交叉验证；
-2. **依赖版本核验**：先读版本分析报告确认包架构（re-export / 源内复制 / fork），re-export 架构下区分适配包自身 `version` 字段与 `dependencies` 中的上游版本（二者语义不同）；依赖残留区分框架/运行时依赖（阻断项）与 dev 工具依赖滞后（记录项），未阻断项必须如实写入报告"遗留记录"节；
-3. **汇总指标分解**：验收标准含汇总数字（如 154/154、95/95）时，必须分解至报告分项逐项对账（如 59+85+10），防止口径错配；
-4. **扫描执行安全**：核验类扫描（版本残留/引用检查）必须排除 node_modules/oh_modules/lock 文件/*.har/*.hap/.git，限定依赖清单文件白名单，优先使用 rg（grep 全量扫描在大仓库实测 120s 超时）；
-5. **自动生成产物权威级**：链路中自动生成的 diff/扫描件若在后续人工分析报告中被修正，验收一律以修正结论件为准，自动件仅作参考。
-
-> 详细核验检查单、判定维度与示例参见 [关键声明核验规则指南](references/PHASE2_EVIDENCE_VERIFICATION.md)
-
----
-
-## Phase 3：准出结论
-
-### 3.1 汇总评估结果
-
-```
-准出结论 = 所有验收标准均满足 ? "通过" : "未通过"
-```
-
-### 3.2 生成改进建议
-
-如果准出未通过，针对每个未满足的标准生成改进建议：
-
-- 明确指出哪个标准未满足
-- 提供具体的修复方向
-- 建议需要重新执行或补充的步骤
-
----
-
-## Phase 4：报告生成
-
-### 4.1 审核报告格式
-
-将审核结果写入 `reportPath` 指定的文件，格式如下：
-
-```markdown
-# 准出审核报告
-
-## 准出结论
-通过
-
-（或：未通过）
-
-## 审核概要
-- 任务 ID: {taskId}
-- 循环次数: 第 {loopCount+1} 次循环
-- 审核时间: {timestamp}
-- 验收标准总数: {N}
-- 满足数量: {M}
-- 未满足数量: {N-M}
-
-## 逐条标准评估
-
-### [ac1] (output) 验收标准描述
-- **结论**: 满足
-- **证据**: {在产物中找到的证据}
-- **说明**: {补充分析}
-
-### [ac2] (quality) 验收标准描述
-- **结论**: 未满足
-- **证据**: {缺失的内容或不达标的分析}
-- **说明**: {具体问题}
-
-...
-
-## 改进建议
-（仅在未通过时提供）
-1. {改进建议1}
-2. {改进建议2}
-
-## 遗留记录
-（如有：核验中发现的非阻断遗留项）
-- {遗留项描述 + 风险定性 + 处置建议}
-```
-
-### 4.2 审核摘要格式
-
-将摘要写入 `summaryPath` 指定的文件：
-
-```markdown
-# 审核摘要
-
-## 结论
-{通过/未通过}
-
-## 关键发现
-{主要发现和结论}
-
-## 未满足标准
-（如有）
-- {未满足标准列表}
-```
-
----
-
-## 输出要求
-
-1. 审核报告必须包含 `## 准出结论` 字段，值为 `通过` 或 `未通过`
-2. 审核报告必须逐条列出每个验收标准的评估结论
-3. 未通过时必须提供改进建议
-4. 报告和摘要文件必须写入指定路径
-5. 核验中发现的非阻断遗留项必须如实记录在报告"遗留记录"节（含风险定性），不得隐藏不报，也不得因非阻断遗留项直接判未通过
+---
+name: acceptance-check
+description: 对任务执行结果进行准出审核（验收测试），对照任务级验收标准逐条判断是否满足，生成结构化审核报告。当需要对任务产物进行最终验收检查、判断是否达到准出条件时调用。
+license: Apache-2.0
+compatibility: 需要访问任务工作目录、产物文件
+metadata:
+  author: LoopEngine
+  version: "1.1.0"
+---
+
+# acceptance-check SKILL — 任务准出审核
+
+## 任务参数
+
+| 参数 | 必需 | 说明 |
+|------|------|------|
+| `taskDescription` | ✅ | 审核任务描述（含原始任务、验收标准、编排结果） |
+| `skillDir` | ✅ | 本 SKILL 目录绝对路径 |
+| `workDir` | ✅ | 任务工作目录，包含所有步骤产物 |
+| `reportPath` | ✅ | 审核报告输出路径 |
+| `summaryPath` | ✅ | 审核摘要输出路径 |
+
+---
+
+## 工作流程概览
+
+```
+Phase 1: 产物收集 → Phase 2: 逐条标准评估 → Phase 3: 准出结论 → Phase 4: 报告生成
+```
+
+---
+
+## Phase 1：产物收集
+
+### 1.1 扫描工作目录
+
+读取 `workDir` 目录下所有步骤产物文件：
+
+- `stepId{N}_result_{loop}.md` — 各步骤的执行结果报告
+- `stepId{N}_Summary_{loop}.md` — 各步骤的执行摘要
+- 其他生成的文档/报告文件
+
+> 详细文件格式参见 [产物收集指南](references/PHASE1_ARTIFACT_COLLECTION.md)
+
+### 1.2 解析审核任务描述
+
+从 `taskDescription` 中提取：
+
+- **原始任务描述** — 任务的核心目标
+- **任务级验收标准** — 需要逐条验证的标准列表（含 id、criterion、type、verification）
+- **编排结果摘要** — 步骤执行状态、成功/失败统计
+
+### 1.3 汇总产物清单
+
+将所有步骤产物按 stepId 和 loopCount 排序，形成产物清单供后续评估使用。
+
+---
+
+## Phase 2：逐条标准评估
+
+### 2.1 对照验收标准
+
+对每个任务级验收标准，检查产物是否满足：
+
+```
+对于每个验收标准 [ac{id}]:
+  1. 读取该标准的内容 (criterion) 和验证方式 (verification)
+  2. 在产物中查找相关证据
+  3. 根据 verification 描述的验证方式执行检查
+  4. 记录评估结论：满足 / 未满足
+  5. 记录支持证据
+```
+
+### 2.2 验证方式分类
+
+根据标准的 `type` 字段采用不同验证策略：
+
+| type | 验证策略 |
+|------|---------|
+| `output` | 检查产物文件是否存在、内容是否完整 |
+| `quality` | 检查产物质量是否达标（如报告覆盖维度、分析深度） |
+| `performance` | 检查性能指标是否满足（如扫描覆盖率、执行时间） |
+| `compliance` | 检查是否符合规范标准（如编码规范、格式要求） |
+
+> 详细评估规则参见 [验收标准评估指南](references/PHASE2_CRITERIA_EVALUATION.md)
+
+### 2.3 关键声明核验规则
+
+对关键声明（分支血缘、产物存在、依赖版本、测试结果）执行核验时，必须遵守：
+
+1. **证据三角验证**：验收判定禁止仅凭前序步骤报告的"成功"结论，关键声明必须与实物产物（文件存在性/大小/时间戳）、现场 git/文件查询（如 `git merge-base` 验证分支血缘、直接读依赖清单原文）交叉验证；
+2. **依赖版本核验**：先读版本分析报告确认包架构（re-export / 源内复制 / fork），re-export 架构下区分适配包自身 `version` 字段与 `dependencies` 中的上游版本（二者语义不同）；依赖残留区分框架/运行时依赖（阻断项）与 dev 工具依赖滞后（记录项），未阻断项必须如实写入报告"遗留记录"节；
+3. **汇总指标分解**：验收标准含汇总数字（如 154/154、95/95）时，必须分解至报告分项逐项对账（如 59+85+10），防止口径错配；
+4. **扫描执行安全**：核验类扫描（版本残留/引用检查）必须排除 node_modules/oh_modules/lock 文件/*.har/*.hap/.git，限定依赖清单文件白名单，优先使用 rg（grep 全量扫描在大仓库实测 120s 超时）；
+5. **自动生成产物权威级**：链路中自动生成的 diff/扫描件若在后续人工分析报告中被修正，验收一律以修正结论件为准，自动件仅作参考。
+
+> 详细核验检查单、判定维度与示例参见 [关键声明核验规则指南](references/PHASE2_EVIDENCE_VERIFICATION.md)
+
+---
+
+## Phase 3：准出结论
+
+### 3.1 汇总评估结果
+
+```
+准出结论 = 所有验收标准均满足 ? "通过" : "未通过"
+```
+
+### 3.2 生成改进建议
+
+如果准出未通过，针对每个未满足的标准生成改进建议：
+
+- 明确指出哪个标准未满足
+- 提供具体的修复方向
+- 建议需要重新执行或补充的步骤
+
+---
+
+## Phase 4：报告生成
+
+### 4.1 审核报告格式
+
+将审核结果写入 `reportPath` 指定的文件，格式如下：
+
+```markdown
+# 准出审核报告
+
+## 准出结论
+通过
+
+（或：未通过）
+
+## 审核概要
+- 任务 ID: {taskId}
+- 循环次数: 第 {loopCount+1} 次循环
+- 审核时间: {timestamp}
+- 验收标准总数: {N}
+- 满足数量: {M}
+- 未满足数量: {N-M}
+
+## 逐条标准评估
+
+### [ac1] (output) 验收标准描述
+- **结论**: 满足
+- **证据**: {在产物中找到的证据}
+- **说明**: {补充分析}
+
+### [ac2] (quality) 验收标准描述
+- **结论**: 未满足
+- **证据**: {缺失的内容或不达标的分析}
+- **说明**: {具体问题}
+
+...
+
+## 改进建议
+（仅在未通过时提供）
+1. {改进建议1}
+2. {改进建议2}
+
+## 遗留记录
+（如有：核验中发现的非阻断遗留项）
+- {遗留项描述 + 风险定性 + 处置建议}
+```
+
+### 4.2 审核摘要格式
+
+将摘要写入 `summaryPath` 指定的文件：
+
+```markdown
+# 审核摘要
+
+## 结论
+{通过/未通过}
+
+## 关键发现
+{主要发现和结论}
+
+## 未满足标准
+（如有）
+- {未满足标准列表}
+```
+
+---
+
+## 输出要求
+
+1. 审核报告必须包含 `## 准出结论` 字段，值为 `通过` 或 `未通过`
+2. 审核报告必须逐条列出每个验收标准的评估结论
+3. 未通过时必须提供改进建议
+4. 报告和摘要文件必须写入指定路径
+5. 核验中发现的非阻断遗留项必须如实记录在报告"遗留记录"节（含风险定性），不得隐藏不报，也不得因非阻断遗留项直接判未通过

package/vendor/Server/Skills/acceptance-check/references/PHASE1_ARTIFACT_COLLECTION.md

@@ -1,52 +1,52 @@
-# Phase 1：产物收集指南
-
-## 工作目录结构
-
-任务工作目录（`workDir`）通常包含以下文件：
-
-```
-{workDir}/
-├── stepId1_result_0.md       ← 步骤1第0次执行结果
-├── stepId1_Summary_0.md      ← 步骤1第0次执行摘要
-├── stepId2_result_0.md       ← 步骤2第0次执行结果
-├── stepId2_Summary_0.md      ← 步骤2第0次执行摘要
-├── stepId1_result_1.md       ← 步骤1第1次执行结果（重试）
-└── ...
-```
-
-## 收集策略
-
-1. **按 stepId 分组**：将同一步骤的所有产物归为一组
-2. **取最新 loopCount**：同一步骤多次执行时，取最后一次（loopCount 最大）的结果
-3. **结果文件优先**：result .md 包含执行状态和结论，是评估的主要依据
-4. **摘要文件辅助**：Summary .md 包含经验总结，可作为补充证据
-
-## 文件内容解析
-
-### result .md 格式
-
-```markdown
-## 执行状态
-成功 / 失败
-
-## 执行结果
-{具体执行内容和分析}
-```
-
-关键字段：
-- `## 执行状态` — 判断该步骤是否成功完成
-- `## 执行结果` — 获取步骤的产出内容
-
-### Summary .md 格式
-
-```markdown
-## 摘要
-{关键信息和经验总结}
-```
-
-## 产物完整性检查
-
-收集完成后，检查：
-- 每个步骤是否都有对应的 result 文件
-- 文件内容是否完整（非空）
-- 是否有步骤缺失产物（可能执行失败未生成）
+# Phase 1：产物收集指南
+
+## 工作目录结构
+
+任务工作目录（`workDir`）通常包含以下文件：
+
+```
+{workDir}/
+├── stepId1_result_0.md       ← 步骤1第0次执行结果
+├── stepId1_Summary_0.md      ← 步骤1第0次执行摘要
+├── stepId2_result_0.md       ← 步骤2第0次执行结果
+├── stepId2_Summary_0.md      ← 步骤2第0次执行摘要
+├── stepId1_result_1.md       ← 步骤1第1次执行结果（重试）
+└── ...
+```
+
+## 收集策略
+
+1. **按 stepId 分组**：将同一步骤的所有产物归为一组
+2. **取最新 loopCount**：同一步骤多次执行时，取最后一次（loopCount 最大）的结果
+3. **结果文件优先**：result .md 包含执行状态和结论，是评估的主要依据
+4. **摘要文件辅助**：Summary .md 包含经验总结，可作为补充证据
+
+## 文件内容解析
+
+### result .md 格式
+
+```markdown
+## 执行状态
+成功 / 失败
+
+## 执行结果
+{具体执行内容和分析}
+```
+
+关键字段：
+- `## 执行状态` — 判断该步骤是否成功完成
+- `## 执行结果` — 获取步骤的产出内容
+
+### Summary .md 格式
+
+```markdown
+## 摘要
+{关键信息和经验总结}
+```
+
+## 产物完整性检查
+
+收集完成后，检查：
+- 每个步骤是否都有对应的 result 文件
+- 文件内容是否完整（非空）
+- 是否有步骤缺失产物（可能执行失败未生成）

package/vendor/Server/Skills/acceptance-check/references/PHASE2_CRITERIA_EVALUATION.md

@@ -1,77 +1,77 @@
-# Phase 2：验收标准评估指南
-
-## 评估原则
-
-1. **证据驱动**：每条标准的评估结论必须基于产物中的实际证据
-2. **逐条独立**：每条标准独立评估，不因其他标准通过/未通过而影响
-3. **可追溯**：记录评估依据，便于后续复核
-
-## 按 type 分类的评估策略
-
-### output（产物检查）
-
-验证目标：确认预期的产物文件/内容是否存在且完整。
-
-评估方法：
-- 检查产物文件是否存在
-- 检查文件内容是否非空
-- 检查内容是否包含预期的章节/维度
-- 检查格式是否符合要求
-
-示例：
-- 标准要求"产出完整的质量检查报告" → 检查报告文件是否存在、是否包含所有维度章节
-
-### quality（质量要求）
-
-验证目标：确认产物的质量是否达标。
-
-评估方法：
-- 检查分析深度是否足够
-- 检查覆盖范围是否完整
-- 检查结论是否有数据支撑
-- 检查建议是否具体可操作
-
-示例：
-- 标准要求"对高优先级问题提供具体代码位置和修复建议" → 检查报告中是否包含文件名、行号、修复方案
-
-### performance（性能指标）
-
-验证目标：确认性能相关指标是否满足要求。
-
-评估方法：
-- 检查扫描覆盖率
-- 检查执行时间是否在合理范围
-- 检查资源使用是否达标
-
-示例：
-- 标准要求"使用至少一种主流静态分析工具" → 检查报告中是否标注了工具名称和版本
-
-### compliance（合规性）
-
-验证目标：确认产物是否符合特定规范或标准。
-
-评估方法：
-- 检查是否引用了正确的规范标准
-- 检查是否符合规范的具体要求
-- 检查合规性检查项是否完整
-
-示例：
-- 标准要求"符合 OpenHarmony 编码规范" → 检查报告中是否引用了 OpenHarmony 社区规范
-
-## 评估结论记录
-
-每条标准的评估结果应包含：
-
-| 字段 | 说明 |
-|------|------|
-| id | 验收标准 ID |
-| criterion | 标准描述 |
-| satisfied | 是否满足（true/false） |
-| evidence | 支持结论的证据 |
-| note | 补充说明 |
-
-## 常见问题处理
-
-1. **产物缺失**：如果某个步骤的产物不存在，相关标准标记为"未满足"
-2. **产物不完整**：如果产物内容不完整，根据缺失程度判断
-3. **无法判断**：如果产物信息不足以判断，标记为"未满足"并说明原因
+# Phase 2：验收标准评估指南
+
+## 评估原则
+
+1. **证据驱动**：每条标准的评估结论必须基于产物中的实际证据
+2. **逐条独立**：每条标准独立评估，不因其他标准通过/未通过而影响
+3. **可追溯**：记录评估依据，便于后续复核
+
+## 按 type 分类的评估策略
+
+### output（产物检查）
+
+验证目标：确认预期的产物文件/内容是否存在且完整。
+
+评估方法：
+- 检查产物文件是否存在
+- 检查文件内容是否非空
+- 检查内容是否包含预期的章节/维度
+- 检查格式是否符合要求
+
+示例：
+- 标准要求"产出完整的质量检查报告" → 检查报告文件是否存在、是否包含所有维度章节
+
+### quality（质量要求）
+
+验证目标：确认产物的质量是否达标。
+
+评估方法：
+- 检查分析深度是否足够
+- 检查覆盖范围是否完整
+- 检查结论是否有数据支撑
+- 检查建议是否具体可操作
+
+示例：
+- 标准要求"对高优先级问题提供具体代码位置和修复建议" → 检查报告中是否包含文件名、行号、修复方案
+
+### performance（性能指标）
+
+验证目标：确认性能相关指标是否满足要求。
+
+评估方法：
+- 检查扫描覆盖率
+- 检查执行时间是否在合理范围
+- 检查资源使用是否达标
+
+示例：
+- 标准要求"使用至少一种主流静态分析工具" → 检查报告中是否标注了工具名称和版本
+
+### compliance（合规性）
+
+验证目标：确认产物是否符合特定规范或标准。
+
+评估方法：
+- 检查是否引用了正确的规范标准
+- 检查是否符合规范的具体要求
+- 检查合规性检查项是否完整
+
+示例：
+- 标准要求"符合 OpenHarmony 编码规范" → 检查报告中是否引用了 OpenHarmony 社区规范
+
+## 评估结论记录
+
+每条标准的评估结果应包含：
+
+| 字段 | 说明 |
+|------|------|
+| id | 验收标准 ID |
+| criterion | 标准描述 |
+| satisfied | 是否满足（true/false） |
+| evidence | 支持结论的证据 |
+| note | 补充说明 |
+
+## 常见问题处理
+
+1. **产物缺失**：如果某个步骤的产物不存在，相关标准标记为"未满足"
+2. **产物不完整**：如果产物内容不完整，根据缺失程度判断
+3. **无法判断**：如果产物信息不足以判断，标记为"未满足"并说明原因