@hunter-harness/workflow-harness 0.4.8 → 0.4.10

package/harness/bundles/general/codebuddy/{harness-run/reference.md → harness-execute/coding-reference.md}

@@ -1,8 +1,8 @@
 ---
-description: harness-run 的编译失败策略表、TDD循环详细步骤和编码约束。仅在编码执行遇到编译问题或需要参考详细规则时读取。
+description: harness-execute 的编译失败策略表、TDD循环详细步骤和编码约束。仅在编码执行遇到编译问题或需要参考详细规则时读取。
 ---
 
-# harness-run 参考 — 详细规则
+# harness-execute 参考 — 详细规则
 
 ## 为什么走变更簇 TDD 而不是逐任务 TDD
 
@@ -30,7 +30,7 @@ description: harness-run 的编译失败策略表、TDD循环详细步骤和编
 
 ## Worktree 创建与切换详细规则
 
-`harness-run` 必须把 `worktree.json` 当作唯一决策源。
+`harness-execute` 必须把 `worktree.json` 当作唯一决策源。
 
 ### 状态机
 
@@ -119,7 +119,7 @@ requested=true + path missing
 4. 读取 .harness/changes/<change-name>/plans/<change-name>-test-scenarios.md
 ```
 
-**禁止 /harness-run 默认读取 `docs/superpowers/plans/*.md`** 作为任务来源。旧 `docs/superpowers/` 草稿最多作为人工线索，不作为执行输入。
+**禁止 /harness-execute 默认读取 `docs/superpowers/plans/*.md`** 作为任务来源。旧 `docs/superpowers/` 草稿最多作为人工线索，不作为执行输入。
 
 ### 步骤 0.1：执行模式（无询问）
 
@@ -182,7 +182,7 @@ powershell.exe -Command "<测试命令> <模块定位参数>"
 从场景表选取对应当前变更簇的测试用例：
 
 - **单元测试**（优先）：按技术栈测试框架（如 Java 的 JUnit 5 + Mockito + AssertJ），命名 `{方法名}_{场景}_{预期结果}()`，用断言库（如 Java 的 AssertJ `assertThat`）
-- **接口测试**（必要时代码逻辑已覆盖即可，实际 HTTP 调用留给 `harness-test`）
+- **接口测试**（必要时代码逻辑已覆盖即可，实际 HTTP 调用留给 `harness-execute`）
 - **多个测试类合并到一次构建/测试命令执行**（按技术栈模块/用例定位参数，如 Java 的 `mvn test -pl <module> -Dtest=TestA,TestB,TestC -o`）
 
 ### RED 有效性判定（⚠️ 必须逐项确认）
@@ -245,7 +245,7 @@ RED 不是"测试失败"即可通过，必须确认失败原因与目标 bug/需
 | 注释 | 构建验证 | 不影响运行时行为 |
 | 代码整理（import 清理）| 构建验证 | 不影响运行时行为 |
 | 格式化 | 构建验证 | 不影响运行时行为 |
-| 数据库迁移脚本 | 静态审查 + harness-test DB 验证 | 不做 TDD，生成审查清单 |
+| 数据库迁移脚本 | 静态审查 + harness-execute DB 验证 | 不做 TDD，生成审查清单 |
 | 配置模板 | 静态审查 | 部署时生效 |
 | 文档文件 | 静态审查 | 不涉及代码 |
 
@@ -283,7 +283,7 @@ RED 不是"测试失败"即可通过，必须确认失败原因与目标 bug/需
 | 是否可通过静态 mock（如 Java 的 mockStatic）构造？ | 是/否 |
 | 是否可写轻量集成测试？ | 是/否 |
 | 跳过自动化测试的具体阻塞点 | ... |
-| 后续必须由哪个阶段验证 | harness-test / 手工接口 / 部署验证 |
+| 后续必须由哪个阶段验证 | harness-execute / 手工接口 / 部署验证 |
 
 如果只是"配置麻烦"或"mock 复杂"，不得直接跳过。对数据契约字段（DTO）、分页返回、权限过滤、组织过滤等用户可见行为，必须优先写公共行为测试。
 
@@ -304,9 +304,9 @@ RED 不是"测试失败"即可通过，必须确认失败原因与目标 bug/需
 5. 输出必须明确写成：
    - "🟡 静态逻辑验证通过"
    - "未执行真实单元测试"
-   - "待测试基础设施补齐后运行 harness-test"
+   - "待测试基础设施补齐后运行 harness-execute"
 6. **禁止写成**："测试全部通过"、"测试通过 N/N"、"覆盖率 100%"等含暗示真实测试已运行的表述
-7. 提示用户在测试基础设施就绪后补充运行 `harness-test`
+7. 提示用户在测试基础设施就绪后补充运行 `harness-execute`
 
 ## GREEN：最简实现
 
@@ -327,7 +327,7 @@ RED 不是"测试失败"即可通过，必须确认失败原因与目标 bug/需
 
 ## GREEN 后反模式自检（内置清单）
 
-> 此步骤是 `/harness-run` 的内置自检，不依赖 Superpowers `test-driven-development`，也不存在外部 skill 调用成功后的跳过分支。
+> 此步骤是 `/harness-execute` 的内置自检，不依赖 Superpowers `test-driven-development`，也不存在外部 skill 调用成功后的跳过分支。
 
 GREEN 阶段完成后，对照以下反模式清单自检：
 
@@ -358,7 +358,7 @@ GREEN 阶段完成后，对照以下反模式清单自检：
 
 ## 批量构建验证策略
 
-harness-run 必须减少构建/测试启动次数。
+harness-execute 必须减少构建/测试启动次数。
 
 **默认策略**：
 1. 每个变更簇最多执行一次 RED 构建/测试、一次 GREEN 构建/测试
@@ -391,7 +391,7 @@ TestA+TestB+TestC RED → 实现相关代码 → TestA+TestB+TestC GREEN → 最
 
 ## 预存变更隔离
 
-如果 harness-run 开始时检测到已有未提交变更，并且用户选择保留，必须创建 baseline。
+如果 harness-execute 开始时检测到已有未提交变更，并且用户选择保留，必须创建 baseline。
 
 ### baseline 文件
 
@@ -485,7 +485,7 @@ TestA+TestB+TestC RED → 实现相关代码 → TestA+TestB+TestC GREEN → 最
 
 ## 步骤 2：构建验证（默认轻量，按需全量 test）
 
-> **轻量验证职责**：`/harness-run` 默认只做开发反馈，不默认跑全量测试命令。是否跑全量 test 按下方条件判断。
+> **轻量验证职责**：`/harness-execute` 默认只做开发反馈，不默认跑全量测试命令。是否跑全量 test 按下方条件判断。
 
 ### 2a. 构建验证（始终执行）
 
@@ -496,14 +496,14 @@ powershell.exe -Command "<构建命令> <模块定位参数>"
 
 ### 2b. 全量测试（仅当满足触发条件时执行）
 
-默认**跳过**全量测试命令，把完整单元测试留给 `/harness-test`。仅当满足以下任一条件时才在本阶段执行测试命令（按技术栈，如 Java 的 `mvn test -pl <module> -o`）：
+默认**跳过**全量测试命令，把完整单元测试留给 `/harness-execute`。仅当满足以下任一条件时才在本阶段执行测试命令（按技术栈，如 Java 的 `mvn test -pl <module> -o`）：
 
 - 修改了公共模块（被多模块依赖的 common/utils 等）
 - 修改了数据访问层 / 数据库迁移 / 查询配置
 - 修改了权限 / 认证 / 组织过滤逻辑
 - 修改了接口层 / 数据契约（VO/DTO）
 - 用户要求 `full-run-validation`
-- 用户不打算继续运行 `/harness-test`（run 需自证 P0 场景）
+- 用户不打算继续运行 `/harness-execute`（run 需自证 P0 场景）
 
 ```powershell
 powershell.exe -Command "<测试命令> <模块定位参数>"
@@ -523,7 +523,7 @@ powershell.exe -Command "<测试命令> <模块定位参数>"
 步骤 2 完成后**必须**通过 `harness_ledger.py record` 写入/更新 ledger（**禁止** Write/Edit `verification-ledger.json`）：
 
 - `compile` 项：始终写入（status / command / scope / evidence / 时间戳 / durationMs）
-- `unitTest` 项：仅当 2b 执行了全量测试命令时写入（testsRun / failures / errors / skipped / evidence）；未执行时标记 `{"status": "NOT_RUN_BY_RUN", "note": "轻量验证，全量单元测试由 harness-test 执行"}`
+- `unitTest` 项：仅当 2b 执行了全量测试命令时写入（testsRun / failures / errors / skipped / evidence）；未执行时标记 `{"status": "NOT_RUN_BY_RUN", "note": "轻量验证，全量单元测试由 harness-execute 执行"}`
 - 顶层写入 `diffHash` / `currentHead` / `baseCommit` / `module` / `profile`
 - `baseCommit`：merge-base 或计划起点（worktree 分支从主分支分出点，由 harness-plan 写入、run 读取复用；缺失时用 `git merge-base HEAD <默认分支>` 兜底）
 - `currentHead`：`git rev-parse HEAD`（步骤 2c 在 Step 5 checkpoint commit 之前执行，此时 HEAD==baseCommit；commit 后 HEAD 前移到 checkpoint commit，由 ledger-protocol reuse 规则 #2「currentHead 可前移」容忍，**不需为它改时序**）
@@ -536,7 +536,7 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 
 > `content-changeset-2` 同时读取 tracked diff、标准 untracked 文件和 manifest 的精确测试路径。manifest 缺失时保持普通行为；manifest 存在但路径越界、内容 hash 漂移或结构非法时命令失败，ledger 不可复用。checkpoint commit 不改变各路径的工作树内容，因此提交前后 hash 保持一致。
 
-> 这样 harness-test 的 Phase 1 可读取 ledger 判断是否复用 run 的 unitTest（diffHash commit-invariant + reuse 规则 #2 允许 HEAD 前移 → run 的 checkpoint commit 不破坏复用），submit 也可复用 compile 结果。详见 `../protocols/ledger-protocol.md`。
+> 这样 harness-execute 的 Phase 1 可读取 ledger 判断是否复用 run 的 unitTest（diffHash commit-invariant + reuse 规则 #2 允许 HEAD 前移 → run 的 checkpoint commit 不破坏复用），submit 也可复用 compile 结果。详见 `../protocols/ledger-protocol.md`。
 >
 > **Ledger v3**：`record` 自动解析并强制顶层身份（`schemaVersion=3/repositoryId/changeName/baseCommit/currentHead/diffHash/ownershipHash`），缺字段非零退出、不写账本；已有 v1/v2 ledger 在写前透明迁移，`migrationHistory` 回执记录原/目标 schema 与迁移前后 evidence identity。无法迁移时返回 `LEDGER_MIGRATION_REQUIRED` 和确定性 `rerecordCommand`，不得半升级。v2 契约下 `--metrics-json` 必须通过 typed schema（unit=`total/passed/failed`，apiContract=`scenariosTotal/passed/failed`，browserE2E=`total/passed/failed`，dbCompatibility=`applicability(+reason)`）。详见 `../protocols/ledger-protocol.md` 第十节。
 
@@ -554,7 +554,7 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 ### 静态验证不等于测试覆盖（⚠️ 关键规则）
 
 1. 🟡 静态检查 **不得计入"已测试通过"**
-2. 如果任一 `ownerPhase=run` 的 P0 场景仅静态验证，则 harness-run 最终结果必须是：
+2. 如果任一 `ownerPhase=run` 的 P0 场景仅静态验证，则 harness-execute 最终结果必须是：
    `🟡WARN：编码和编译完成，但存在 P0 场景未真实验证`
 3. 只有所有 run-owned P0 场景都有自动化测试或真实接口验证时，最终结果才能是：
    `✅OK成功`
@@ -564,7 +564,7 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
    自动化测试通过: 5
    静态检查未真实验证: 17
    未验证: 0
-   harness-run 结果: 🟡WARN，必须进入 harness-test 后才能 submit
+   harness-execute 结果: 🟡WARN，必须进入 harness-execute 后才能 submit
    ```
 6. **禁止用测试用例数冒充场景数**：计数对象是 `test-scenarios.md` 的场景编号（UT-001/N、API-001/N、COM-001/N、INT-001/N），不是测试框架的测试方法数（如 vitest "178 tests"、junit "Tests run: 178"）。场景总数 = test-scenarios.md 的场景数。
 7. **四类计数须自洽**：run-owned 的 🟡/❌ 计入未验证；`ownerPhase=test` 单列为 ⏳“按计划移交”，不得冒充 ✅，也不得反向污染 run 的结果。
@@ -574,9 +574,9 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 > ```
 > ### 场景覆盖检查
 > - ✅ UT-001~005: getEnabledIndicators 正常/异常/边界场景已测试通过
-> - 🟡 UT-006~010: getIndicatorPage 分页场景静态验证通过，待测试基础设施补齐后运行 harness-test
+> - 🟡 UT-006~010: getIndicatorPage 分页场景静态验证通过，待测试基础设施补齐后运行 harness-execute
 > - ❌ UT-011~015: getIndicatorByCode 场景未覆盖，需补充测试用例
-> - ⏳ API-001~005: `ownerPhase=test`，接口测试按计划移交 harness-test
+> - ⏳ API-001~005: `ownerPhase=test`，接口测试按计划移交 harness-execute
 > - ✅ COM-001~005: 数据库迁移脚本覆盖
 > - ⏳ INT-001~004: `ownerPhase=test`，按计划移交测试阶段验证
 > ```
@@ -587,12 +587,12 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 > 静态检查未真实验证: 17
 > 未验证: 0
 > 按计划移交测试阶段: 4
-> harness-run 结果: 🟡WARN，必须进入 harness-test 后才能 submit
+> harness-execute 结果: 🟡WARN，必须进入 harness-execute 后才能 submit
 > ```
 
 ## 步骤 3.5：权限/组织过滤类变更 — 安全矩阵
 
-> 凡是修改了以下逻辑，必须强制生成安全矩阵。如果任一权限边界的预期不明确，不允许标记 harness-run 为 ✅OK。
+> 凡是修改了以下逻辑，必须强制生成安全矩阵。如果任一权限边界的预期不明确，不允许标记 harness-execute 为 ✅OK。
 
 ### 触发条件
 
@@ -624,7 +624,7 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 
 ### 判定规则
 
-- 如果任一权限边界的预期不明确（如"非管理员+token空+指定组织"场景未明确是拒绝还是允许），则必须标记为 ❌未验证，且不允许标记 harness-run 为 ✅OK
+- 如果任一权限边界的预期不明确（如"非管理员+token空+指定组织"场景未明确是拒绝还是允许），则必须标记为 ❌未验证，且不允许标记 harness-execute 为 ✅OK
 - 每个场景的覆盖状态必须真实标注：✅ 自动化测试通过 / 🟡 静态检查未真实测试 / ❌ 未验证
 - 安全矩阵必须写入执行日志
 
@@ -714,7 +714,7 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 
 ## 步骤 5：计划状态持久化
 
-如果 `.harness/changes/<change>/plans/*.md` 是任务来源，则 harness-run 完成任务后必须持久化任务状态。
+如果 `.harness/changes/<change>/plans/*.md` 是任务来源，则 harness-execute 完成任务后必须持久化任务状态。
 
 ### 持久化方式
 
@@ -729,12 +729,12 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 | 任务 | 状态 | 测试场景 | 待验证 |
 |------|------|----------|--------|
 | Task 1 | ✅ DONE_AUTOMATED_TESTED | UT-001~005 | - |
-| Task 2 | 🟡 DONE_STATIC_ONLY | UT-006~010 | harness-test |
-| Task 3 | 🟡 DONE_NEEDS_INTERFACE_TEST | API-001~003 | harness-test |
+| Task 2 | 🟡 DONE_STATIC_ONLY | UT-006~010 | harness-execute |
+| Task 3 | 🟡 DONE_NEEDS_INTERFACE_TEST | API-001~003 | harness-execute |
 
 ## 待验证场景汇总
-- UT-006~010: 静态验证通过，需 harness-test 接口验证
-- API-001~003: 接口逻辑已覆盖，需 harness-test 真实 HTTP 验证
+- UT-006~010: 静态验证通过，需 harness-execute 接口验证
+- API-001~003: 接口逻辑已覆盖，需 harness-execute 真实 HTTP 验证
 ```
 
 ### 状态定义
@@ -748,7 +748,7 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 
 - 不允许只在对话里说"任务完成"但不写入任何持久化文件
 - 不允许修改 finalized plan Markdown 来记录状态；恢复信息只写 `evidence/run-task-status.md`
-- 后续 harness-test 和 harness-review 必须能从持久化状态识别哪些场景仍待验证
+- 后续 harness-execute 和 harness-review 必须能从持久化状态识别哪些场景仍待验证
 
 ## 输出示例
 
@@ -770,7 +770,7 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 - 静态检查未真实验证: M
 - 未验证: P
 - 按计划移交测试阶段: Q
-- harness-run 结果: ✅OK成功 / 🟡WARN（只由 run-owned 工作决定）
+- harness-execute 结果: ✅OK成功 / 🟡WARN（只由 run-owned 工作决定）
 
 ### 关门检查结果
 - git status --porcelain: ✅/❌
@@ -788,10 +788,10 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 - 状态已写入: `.harness/changes/<change-name>/evidence/run-task-status.md`
 
 ### 下一步
-> ⚠️ 如果存在 run-owned P0 场景为 🟡静态验证，下一步必须且只能是 harness-test。
+> ⚠️ 如果存在 run-owned P0 场景为 🟡静态验证，下一步必须且只能是 harness-execute。
 
-运行 `/harness-test` 验证剩余 P0 场景。
-在 harness-test 通过前，不建议也不应进入 `/harness-submit`。
+运行 `/harness-execute` 验证剩余 P0 场景。
+在 harness-execute 通过前，不建议也不应进入 `/harness-submit`。
 ```
 
 ## CLI 速查（gate / ledger）
@@ -857,7 +857,7 @@ C9 场景覆盖按 `ownerPhase` **分阶段判定**：run 关门只要求 `owner
 
 ## 执行日志记录
 
-`/harness-run` 只向 `events.ndjson` 追加事件（schema_version 3，兼容读取 v1/v2）；`logs/execution-log.md` 由 `harness_events.py append` 自动渲染。步骤 0 之前 append `phase.start`；各阶段写入 `command` / `verification` / `decision` / `issue`，人类可读摘要放 `note`。事件类型与脚本用法见 [[../protocols/report-pipeline-protocol.md|report-pipeline-protocol]] 与 SKILL.md `## 执行日志`。
+`/harness-execute` 只向 `events.ndjson` 追加事件（schema_version 3，兼容读取 v1/v2）；`logs/execution-log.md` 由 `harness_events.py append` 自动渲染。步骤 0 之前 append `phase.start`；各阶段写入 `command` / `verification` / `decision` / `issue`，人类可读摘要放 `note`。事件类型与脚本用法见 [[../protocols/report-pipeline-protocol.md|report-pipeline-protocol]] 与 SKILL.md `## 执行日志`。
 
 关键 `note` / `decision` 须覆盖：测试基础设施探测（CHECKING→结论）、预存变更、run-tdd-protocol RED 类型、变更簇 RED/GREEN、批量构建 exit code、关门检查 10 项、计划状态持久化路径。
 
@@ -876,7 +876,7 @@ C9 场景覆盖按 `ownerPhase` **分阶段判定**：run 关门只要求 `owner
 
 ## 数据访问层复杂查询真实验证要求
 
-数据访问层复杂查询（Java 的 `@Select`/JOIN/DISTINCT/IPage 分页/SQL/XML）变更在 run 阶段只能标记 🟡DONE_STATIC_ONLY，必须交给 harness-test 真实 DB/API 验证：
+数据访问层复杂查询（Java 的 `@Select`/JOIN/DISTINCT/IPage 分页/SQL/XML）变更在 run 阶段只能标记 🟡DONE_STATIC_ONLY，必须交给 harness-execute 真实 DB/API 验证：
 
 - SQL 可执行；
 - total 正确；

package/harness/bundles/general/codebuddy/{harness-run → harness-execute}/protocols.md

@@ -1,10 +1,10 @@
 ---
-description: harness-run 的原生执行协议。内化 TDD 与变更簇审查能力，但不运行时依赖 Superpowers。
+description: harness-execute 的原生执行协议。内化 TDD 与变更簇审查能力，但不运行时依赖 Superpowers。
 ---
 
-# harness-run 原生执行协议
+# harness-execute 原生执行协议
 
-本文件定义 `/harness-run` 的内置执行协议。它吸收 test-driven-development 与 subagent-driven-development 的有效做法，但正式流程不调用 Superpowers，也不把外部 skill 是否存在作为执行条件。
+本文件定义 `/harness-execute` 的内置执行协议。它吸收 test-driven-development 与 subagent-driven-development 的有效做法，但正式流程不调用 Superpowers，也不把外部 skill 是否存在作为执行条件。
 
 ## 协议一：run-tdd-protocol
 
@@ -15,7 +15,7 @@ description: harness-run 的原生执行协议。内化 TDD 与变更簇审查
 | RED 类型 | 何时使用 | 证据要求 |
 |----------|----------|----------|
 | 真实 RED | 测试基础设施可用，能写测试并运行失败 | 测试编译通过，失败断言指向目标行为 |
-| 静态 RED | 测试基础设施不可用或目标层无法真实验证 | 记录降级原因、静态验证场景、待 harness-test 验证场景 |
+| 静态 RED | 测试基础设施不可用或目标层无法真实验证 | 记录降级原因、静态验证场景、待 harness-execute 验证场景 |
 | 复用 RED | 计划和测试场景已明确失败场景，且本轮只执行同一场景的实现 | 引用 test-scenarios 编号与前序证据，仍需在 run 日志登记 |
 
 RED 失败原因必须与目标 bug 或需求直接相关。无效 RED（测试搭建错误、private 访问限制、mock/stubbing 错误、依赖注入失败、NPE 来自测试夹具）不得进入 GREEN。

package/harness/bundles/general/{codex/harness-test/checklist.md → codebuddy/harness-execute/testing-checklist.md}

@@ -1,8 +1,8 @@
 ---
-description: harness-test 的 Phase 0 环境准备 + Playwright 探测 + 关门检查清单。仅在执行测试前的环境准备阶段读取。
+description: harness-execute 的 Phase 0 环境准备 + Playwright 探测 + 关门检查清单。仅在执行测试前的环境准备阶段读取。
 ---
 
-# harness-test 检查清单 — Phase 0 环境准备 + 关门检查
+# harness-execute 检查清单 — Phase 0 环境准备 + 关门检查
 
 以下检查项确认完了再开始测试。每一项背后都有踩坑经历。
 
@@ -16,8 +16,7 @@ description: harness-test 的 Phase 0 环境准备 + Playwright 探测 + 关门
 
 先检查当前项目的测试配置文件（按优先级查找）：
 
-1. **优先**：`.harness/config/harness-test-config.md`（集中配置目录）
-2. **兼容**：`harness-test/harness-test-config.md（兼容旧路径）`（旧路径，过渡期仍支持）
+1. `.harness/config/harness-test-config.md`（集中配置目录；旧 skill 目录下的兼容路径已随 harness-test 入口移除而废弃）
 
 如果任一文件存在，**必须先读取并应用其中的配置**。配置文件通常包含：
 
@@ -70,7 +69,7 @@ description: harness-test 的 Phase 0 环境准备 + Playwright 探测 + 关门
 - [ ] 检查 `claude mcp list` 中是否有 playwright（如果可以执行命令）
 - [ ] 检查 `@playwright/mcp` 是否可启动
 - [ ] 检查当前 skill 的 `allowed-tools` 是否允许 Playwright 相关工具
-- [ ] 输出 fallback 执行器可用性表格（见 reference.md）
+- [ ] 输出 fallback 执行器可用性表格（见 testing-reference.md）
 - [ ] 记录决策：接口测试执行器 / PowerShell batch / Playwright MCP browser_evaluate / curl fallback
 - [ ] 如果 fallback 不可用，必须写明原因，不得静默改用 curl
 
@@ -194,21 +193,21 @@ powershell.exe -NoProfile -Command "try { (Invoke-WebRequest -Uri 'http://127.0.
 
 **如果用户选择 AI 启动或 AI 重启**：
 1. 从已知良好测试配置读取 module/profile/port/healthUrl/sdkUrl（按项目配置）。
-2. 生成 ASCII 运行时配置叠加：`C:/temp/harness-test-overlay/<change-name>/application-harness-test.yml`（按技术栈；Java Spring Boot 的 application.yml 为例）。
+2. 生成 ASCII 运行时配置叠加：`C:/temp/harness-execute-overlay/<change-name>/application-harness-execute.yml`（按技术栈；Java Spring Boot 的 application.yml 为例）。
 3. 禁止默认直接 Edit tracked 应用配置文件（如 `application-local-dev.yml`）。
 4. 默认启动命令（按技术栈，Java Spring Boot 为例）：
    ```powershell
-   powershell.exe -NoProfile -Command "mvn spring-boot:run -pl <module> -Dspring-boot.run.profiles=<profile> -Dspring-boot.run.jvmArguments='-Dspring.config.additional-location=file:C:/temp/harness-test-overlay/<change-name>/application-harness-test.yml'"
+   powershell.exe -NoProfile -Command "mvn spring-boot:run -pl <module> -Dspring-boot.run.profiles=<profile> -Dspring-boot.run.jvmArguments='-Dspring.config.additional-location=file:C:/temp/harness-execute-overlay/<change-name>/application-harness-execute.yml'"
    ```
 5. 写入 `service.pid`、`service-start-command.txt`、`service-start.log`、`runtime/service-session.json`（含 `moduleInputsHash`/`moduleInputsFiles`/`startCommandHash`/`profile`/`overlayPath`/`pid`/`startedBy=AI`/`startedAt`）。`moduleInputsHash` 来自 CLI `--files` ∪ `serviceStart.inputFiles`，空输入拒绝。
 6. 服务启动等待：0–30s 每 2s 探测；30–120s 每 5s 探测；>10s 必须输出状态行；>120s 读取最近 200 行日志。
 7. 发现启动失败特征（按技术栈识别，如 Java Spring Boot 的 `BindException` / `Could not resolve placeholder` / `Connection refused during bean init` / `BeanCreationException` / `Failed to start bean` / `BUILD FAILURE`）立即失败。
 
-#### 0.10.x 重入沿用（同一变更 harness-test 再次执行时）
+#### 0.10.x 重入沿用（同一变更 harness-execute 再次执行时）
 
 满足以下**全部**条件时，可沿用上次服务决策，不重复询问：
 
-1. 重入：同一 change-name 的 harness-test 再次执行（非首次）
+1. 重入：同一 change-name 的 harness-execute 再次执行（非首次）
 2. 环境未变：PG 可用性、目标端口、执行器可用性与上次一致
 3. 上次已确认执行器方案（如"内存 HTTP 执行器，PG 不可用"）
 4. 当前源码未改服务启动逻辑（如未改 main.ts 启动路径、未改服务端口/profile 配置）
@@ -270,7 +269,7 @@ powershell.exe -NoProfile -Command "try { (Invoke-WebRequest -Uri 'http://127.0.
 
 - [ ] Phase 1 前通过 state layout resolver 定位并检查 `evidence/verification-ledger.json`
 - [ ] 判断是否复用 run 的 unitTest：diffHash 一致 + module/profile 一致 + scope 一致或更严格 + run 后无行为性修改 + run 实际跑了全量测试
-- [ ] 复用 → 跳过重跑，标记"✅ 复用 harness-run 单元测试结果"
+- [ ] 复用 → 跳过重跑，标记"✅ 复用 harness-execute 单元测试结果"
 - [ ] 不复用 → 按 profile key resolve 重跑测试命令（`harness_profile.py resolve --key unitTest`，不复制示例 `-pl` 命令），结果写回 ledger 的 `unitTest` 项
 - [ ] HTTP/API 契约结果写入 `apiTest`；真实浏览器/真实栈 Playwright 结果写入 `browserTest`，两者不得互相覆盖
 - [ ] **本变更没有该维度场景时**（如全部为单元场景 → 无 API 场景）：用 `harness_ledger.py record --verification apiTest --status NOT_RUN --applicability NOT_APPLICABLE --applicability-reason "<为什么不适用>"` 登记，**不传 `--files`**。门禁 close 要求 requiredValidations 每项都有 entry，但**绝不能拿无关文件（比如单元测试文件）凑 `--files`**——那会让 ledger 声称该维度的输入是那些文件，是假证据

package/harness/bundles/general/codebuddy/harness-execute/testing-pitfalls-java.md

@@ -0,0 +1,21 @@
+---
+description: Java/Feign 相关测试踩坑（harness-execute）。API 实测前通读；发现客户端路径缺陷时回写 plan 外修复记录。
+---
+
+# Java 测试踩坑补充（Feign / 远程客户端）
+
+> 与 `testing-pitfalls.md`（通用）及 `overlays/java/pitfalls-java.md`（overlay 速查表）互补；本文件收录路径拼接类缺陷的症状与流程要求。
+
+## Feign/客户端路径前缀缺失
+
+**症状**：服务正常、接口 200，但客户端拿到 404 / 空数据 / fallback 生效。
+**根因模式**：`@FeignClient` 方法上只写了 `@GetMapping("/type")`，漏掉服务端类级前缀（如 `/system/dict-data`）。
+**定位**：对照服务端 controller 完整映射（类级 `@RequestMapping` + 方法级注解），或看服务端访问日志中的实际 404 路径。
+**流程要求**：此类缺陷若在 test 阶段被 API 实测发现，属于"计划外修复"——必须记 decision 事件（含根因与修复文件），并检查同客户端文件的其余方法是否同源错误。
+
+## Surefire 插件级 excludedGroups 压过命令行覆盖（静默 0 执行）
+
+**症状**：`mvn test -Dgroups=mysql -DexcludedGroups=` 想跑集成测试，结果 `Tests run: 0` + **exit 0**——只看退出码就是假阳性。
+**根因**：pom 在 surefire `<configuration>` 里写死 `<excludedGroups>mysql</excludedGroups>` 时，插件级配置压过命令行属性，空值覆盖不生效。
+**修复**：pom 改用属性占位 `<excludedGroups>${excludedGroups}</excludedGroups>`，命令行空值才能生效。
+**防线**：`harness_ledger.py record` 在命令含 `-Dgroups=`/`-Dtest=` 等选择器且证据显示 `Tests run: 0` 时输出 `ZERO_TESTS_WITH_SELECTOR` 警告（0.4.11 起）；看到它不要当噪音跳过。

package/harness/bundles/general/{claude-code/harness-test/pitfalls.md → codebuddy/harness-execute/testing-pitfalls.md}

@@ -1,11 +1,11 @@
 ---
-description: harness-test 的踩坑规则（来自真实对话日志）。执行测试前必须通读，遇到测试失败时重新参考。
+description: harness-execute 的踩坑规则（来自真实对话日志）。执行测试前必须通读，遇到测试失败时重新参考。
 ---
 
 # 避坑规则（32 条）
 
 > 以下规则来自真实对话日志（2026-06-12 ~ 08-17），每个都有明确的现象和根因。
-> 执行 `harness-test` 时必须通读，避免重蹈覆辙。
+> 执行 `harness-execute` 时必须通读，避免重蹈覆辙。
 
 | # | 规则 | 现象 | 根因 | 解法 |
 |:--:|------|------|------|------|
@@ -29,7 +29,7 @@ description: harness-test 的踩坑规则（来自真实对话日志）。执行
 | 18 | **Bash 不可执行执行器（如 node）** | "Bash 中没有 node" → 错误降级到 Playwright MCP | Windows 中文路径项目下 Bash 被 hook 拒；Node 不在 Bash PATH | 强制 `powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '<executorPath>' '...mjs'"`，禁止裸 `node`、禁止用 Bash 执行执行器 |
 | 19 | **Auto mode / 安全分类器降级时静默等待** | 接口测试长时间无响应，最终错误降级到逐条 MCP | PowerShell 命令被安全分类器拦截，Claude 静默重试 + fallback | Phase 0.1 preflight 检测出后**硬停**，原文输出"命令执行模式不可用..."，提示用户切换权限模式 |
 | 20 | **Playwright API 执行器与 Playwright MCP 混写** | 报告写"Playwright ✅ 使用"，实际是逐条 `browser_evaluate` | 两者被笼统称为"Playwright" | 报告中**强制区分**四种执行器：接口测试执行器 / PowerShell batch / Playwright MCP browser_evaluate / curl |
-| 21 | **直接 Edit tracked 应用配置文件** | 测试期间改配置，之后又还原，diff 噪声大 | 把运行时配置覆盖直接写进 tracked 文件 | 生成 ASCII 运行时配置叠加 `C:/temp/harness-test-overlay/<change>/application-harness-test.yml`，启动用该绝对路径叠加（如 `-Dspring.config.additional-location=...`） |
+| 21 | **直接 Edit tracked 应用配置文件** | 测试期间改配置，之后又还原，diff 噪声大 | 把运行时配置覆盖直接写进 tracked 文件 | 生成 ASCII 运行时配置叠加 `C:/temp/harness-execute-overlay/<change>/application-harness-execute.yml`，启动用该绝对路径叠加（如 `-Dspring.config.additional-location=...`） |
 | 22 | **唯一约束字段与本地预存数据冲突** | 大面积唯一约束冲突，9 个场景 BLOCKED | 执行器用硬编码字段值 | 用随机值（如 `900000 + random`）/ 先查避让 / 用唯一隔离值 |
 | 23 | **setup 失败后继续用 null ID 发送请求** | 后续 9 个接口全部 400/500，掩盖真正问题 | 执行器不区分 BLOCKED 状态 | 执行器强制 setup/test/cleanup 三阶段，依赖未满足 → 标 🟡 BLOCKED，**不发起请求** |
 | 24 | **归档数据把 PARTIAL 写成 NOT_RUN** | 平台显示「未执行」，但实际跑了 6 个场景 | 状态枚举不完整，只有 OK/FAIL/NOT_RUN | API 维度状态使用 OK/PARTIAL/BLOCKED/NOT_RUN/FAIL，5 PASS+9 BLOCKED+1 FAIL → `apiTest=PARTIAL` |
@@ -37,7 +37,7 @@ description: harness-test 的踩坑规则（来自真实对话日志）。执行
 | 26 | **凭证在同一流程内重复获取** | 浏览器 origin 在认证服务就再走一次登录 | 执行器依赖浏览器当前页面 origin | 执行器用 request context 直连本地 baseURL，凭证从 cache 读，`credentialRefreshCount > 1` → 🟡 WARN |
 | 27 | **服务启动盲等 + 无反馈** | 等待 90s 后才发现启动报错 | 没有启动状态机和异常关键字检测 | 0–30s/2s × 30–120s/5s 状态机；遇启动失败特征（按技术栈，如 BindException/Could not resolve placeholder/BeanCreationException）立即停；> 10s 必须输出一次状态行 |
 | 28 | **已有服务未先决策就跑业务接口** | 旧服务不含新代码，接口 500 后才发现版本不匹配 | 检测到已有应用服务（端口被占）后，未先展示服务决策门就跑业务接口 | 先展示服务决策门，询问复用/重启/跳过/停止；询问前只允许 health/meta 检查 |
-| 29 | **启动命令反复试相对配置叠加 / 中文路径** | 相对路径或中文路径导致应用读不到运行时配置叠加，启动失败 | 默认只用 `C:/temp/harness-test-overlay/<change>/application-harness-test.yml` ASCII 绝对路径，并固化已知良好测试配置 |
+| 29 | **启动命令反复试相对配置叠加 / 中文路径** | 相对路径或中文路径导致应用读不到运行时配置叠加，启动失败 | 默认只用 `C:/temp/harness-execute-overlay/<change>/application-harness-execute.yml` ASCII 绝对路径，并固化已知良好测试配置 |
 | 30 | **伪 diffHash 导致错误复用** | `3files-84plus-5minus` 不能证明代码未变 | 用 `git diff --binary` 生成 patch 并计算 SHA-256，ledger 只认 `sha256:<hash>` |
 | 31 | **尝试破解验证码 / 人机验证** | 认证服务返回"验证码不能为空"，AI 写图像识别脚本反复试坐标（实测 28 次 / 4 种算法全失败） | 测试配置里的账号密码登录流程被加了滑块/图形验证码，配置未同步 | **硬停**。禁止编写或运行任何验证码求解代码；立即标 `apiTest=BLOCKED`，请用户手工提供凭证写入 `runtime/credential-cache.json`，或临时关闭测试环境验证码 |
 | 32 | **预存环境缺陷被当成本次变更的阻塞** | `unitTestFull` 144 个测试挂 1 个，根因是别人提交引入的缺省配置缺失 | 全量验证把预存缺陷和本次 diff 混在一起判定 | 先用 `git log -S` + diff 触点证明与本次变更无关，再按「预存缺陷」上报并请用户决策（修根因 / 记 🟡WARN / 停止），**不得**擅自改 tracked 配置或排除测试 |
@@ -193,7 +193,7 @@ $cred = $resp.data.accessToken
 **严重度**：🟡WARN
 **场景**：测试期间为了切换外部服务配置直接 Edit tracked 配置文件（如 `application-local-dev.yml`），测试后再还原，留下 diff 噪声
 **后果**：git diff --stat 出现意外文件、提交风险、误以为有业务变更
-**正确做法**：生成运行时配置叠加 `.harness/changes/<change>/runtime/application-harness-test.yml`（不提交），启动用 `-Dspring.config.additional-location=file:...` 叠加（按技术栈）；如必须改 tracked 配置，先 blocking user confirmation，最终报告至少 🟡 WARN
+**正确做法**：生成运行时配置叠加 `.harness/changes/<change>/runtime/application-harness-execute.yml`（不提交），启动用 `-Dspring.config.additional-location=file:...` 叠加（按技术栈）；如必须改 tracked 配置，先 blocking user confirmation，最终报告至少 🟡 WARN
 
 ### 规则 22：唯一约束字段与本地预存数据冲突
 **严重度**：❌FAIL
@@ -249,9 +249,9 @@ $cred = $resp.data.accessToken
 
 ### 规则 29：启动命令反复试相对配置叠加 / 中文路径
 **严重度**：🟡WARN
-**场景**：运行时配置叠加用相对路径 `.harness/changes/<change>/runtime/application-harness-test.yml` 或中文路径作为 JVM `additional-location`，应用（如 Spring Boot）读不到配置叠加，启动失败后反复试不同路径
+**场景**：运行时配置叠加用相对路径 `.harness/changes/<change>/runtime/application-harness-execute.yml` 或中文路径作为 JVM `additional-location`，应用（如 Spring Boot）读不到配置叠加，启动失败后反复试不同路径
 **后果**：启动反复失败，浪费时间；中文路径进入 JVM 参数也可能失败
-**正确做法**：默认只用 ASCII 绝对路径 `C:/temp/harness-test-overlay/<change-name>/application-harness-test.yml`，并固化已知良好测试配置。禁止把相对路径作为默认 JVM `additional-location`。
+**正确做法**：默认只用 ASCII 绝对路径 `C:/temp/harness-execute-overlay/<change-name>/application-harness-execute.yml`，并固化已知良好测试配置。禁止把相对路径作为默认 JVM `additional-location`。
 
 ### 规则 30：伪 diffHash 导致错误复用
 **严重度**：❌FAIL

package/harness/bundles/general/codebuddy/{harness-test/reference.md → harness-execute/testing-reference.md}

@@ -1,12 +1,12 @@
 ---
-description: harness-test 的 API 测试执行细节、批量 runner、token 缓存、测试数据治理、报告模板和关门检查。仅在执行接口测试需要参考详细操作时读取。
+description: harness-execute 的 API 测试执行细节、批量 runner、token 缓存、测试数据治理、报告模板和关门检查。仅在执行接口测试需要参考详细操作时读取。
 ---
 
-# harness-test 参考 — API 测试详情
+# harness-execute 参考 — API 测试详情
 
 ## 命令执行模式 preflight（0.1）
 
-`/harness-test` 高度依赖 PowerShell 与接口测试执行器。在编译/启动服务/生成执行器 **之前**
+`/harness-execute` 高度依赖 PowerShell 与接口测试执行器。在编译/启动服务/生成执行器 **之前**
 必须执行 4 项执行模式检查：
 
 | 检查项 | 命令 | 预期 |
@@ -110,8 +110,8 @@ known-good-test-profile:
 
   overlay:
     pathStrategy: ascii-temp
-    directory: C:/temp/harness-test-overlay
-    fileName: application-harness-test.yml
+    directory: C:/temp/harness-execute-overlay
+    fileName: application-harness-execute.yml
 
   service:
     askBeforeReusingExisting: true
@@ -127,7 +127,7 @@ known-good-test-profile:
 不要直接 Edit tracked 应用配置文件（如 `application-local-dev.yml`）。默认生成 ASCII 绝对路径运行时配置叠加：
 
 ```text
-C:/temp/harness-test-overlay/<change-name>/application-harness-test.yml
+C:/temp/harness-execute-overlay/<change-name>/application-harness-execute.yml
 ```
 
 内容按已知良好测试配置渲染（按项目；Java Spring Boot 为例）：
@@ -147,10 +147,10 @@ spring:
 唯一默认启动命令（按技术栈，Java Spring Boot 为例）：
 
 ```powershell
-powershell.exe -NoProfile -Command "mvn spring-boot:run -pl <module> -Dspring-boot.run.profiles=<profile> -Dspring-boot.run.jvmArguments='-Dspring.config.additional-location=file:C:/temp/harness-test-overlay/<change-name>/application-harness-test.yml'"
+powershell.exe -NoProfile -Command "mvn spring-boot:run -pl <module> -Dspring-boot.run.profiles=<profile> -Dspring-boot.run.jvmArguments='-Dspring.config.additional-location=file:C:/temp/harness-execute-overlay/<change-name>/application-harness-execute.yml'"
 ```
 
-不得默认使用 `.harness/changes/<change>/runtime/application-harness-test.yml` 相对路径作为 JVM `additional-location`。如必须修改 tracked 配置文件，先 blocking user confirmation，最终报告至少 🟡 WARN。
+不得默认使用 `.harness/changes/<change>/runtime/application-harness-execute.yml` 相对路径作为 JVM `additional-location`。如必须修改 tracked 配置文件，先 blocking user confirmation，最终报告至少 🟡 WARN。
 
 ## 服务决策门（Service Decision Gate）与服务生命周期管理
 
@@ -184,7 +184,7 @@ serviceState：`AI_STARTED` / `AI_RESTARTED_FROM_USER_SERVICE` / `USER_STARTED`
 
 ### 重入沿用
 
-同一变更的 harness-test 重入时，若环境未变（PG/端口/执行器与上次一致）、上次已确认执行器方案、且源码未改服务启动逻辑，可沿用上次服务决策不重复询问，执行日志记 `重入沿用+环境未变`。不适用情形（fingerprint 不匹配、环境已变、USER_STARTED、源码改启动逻辑）仍须询问/重启。详见 checklist.md「0.10.x 重入沿用」。
+同一变更的 harness-execute 重入时，若环境未变（PG/端口/执行器与上次一致）、上次已确认执行器方案、且源码未改服务启动逻辑，可沿用上次服务决策不重复询问，执行日志记 `重入沿用+环境未变`。不适用情形（fingerprint 不匹配、环境已变、USER_STARTED、源码改启动逻辑）仍须询问/重启。详见 testing-checklist.md「0.10.x 重入沿用」。
 
 ## 启动等待状态机
 
@@ -652,7 +652,7 @@ TEST_<change-name>_<timestamp>_<short-random>
 - credentialRefreshCount: 0 / 1（>1 → 🟡 WARN）
 
 ### 单元测试
-> ✅ 复用 harness-run 单元测试结果：Tests run: N, Failures: 0, Errors: 0
+> ✅ 复用 harness-execute 单元测试结果：Tests run: N, Failures: 0, Errors: 0
 > （diffHash=<...>, module=<...>, profile=<...>, scope=<...>）
 > 或：🔄 已重跑（原因：diffHash 变化 / 行为性 post-test 修改 / run 未跑全量）
 
@@ -729,7 +729,7 @@ TEST_<change-name>_<timestamp>_<short-random>
 ### 下一步
 - 如果 ✅OK：进入 /harness-review
 - 如果 🟡WARN：根据 WARN 原因决定是否补充测试或进入 review
-- 如果 ❌FAIL：修复失败项后重新运行 /harness-test
+- 如果 ❌FAIL：修复失败项后重新运行 /harness-execute
 ```
 
 ## CLI 速查（gate / ledger）
@@ -769,7 +769,7 @@ python <skills-root>/scripts/harness_ledger.py scenario-receipt-template --chang
 | `PROJECT_ROOT_INVALID` | `--project` 传了项目名而不是路径 | 传 `.` 或绝对路径；报错的 `resolvedProject` 显示实际解析结果 |
 | `SCENARIO_RECEIPT_REQUIRED` | manifest 是 schemaVersion 2，`--scenario-ids` 必须配 receipt | 用 `scenario-receipt-template` 生成骨架 |
 | `SCENARIO_RECEIPT_NOT_FOUND` | receipt 路径找不到 | 看报错的 `triedPaths`；相对路径同时按 CWD 与 `--change-dir` 解析 |
-| `REQUIRED_SCENARIO_NOT_EXECUTED`（test 关门） | `ownerPhase=test` 的场景到 test 阶段仍无通过 receipt——这是真阻塞 | 补跑该场景；接口被验证码挡住时按 `pitfalls.md` 规则 31 记 BLOCKED，不得伪造 receipt |
+| `REQUIRED_SCENARIO_NOT_EXECUTED`（test 关门） | `ownerPhase=test` 的场景到 test 阶段仍无通过 receipt——这是真阻塞 | 补跑该场景；接口被验证码挡住时按 `testing-pitfalls.md` 规则 31 记 BLOCKED，不得伪造 receipt |
 
 `can-reuse` 的主文案按 `executionNeed` 呈现，错误码仅放技术详情：`first-run` 表示首次执行，`rerun` 表示已有证据因输入或环境变化失效，`evidence-incomplete` 表示旧记录缺少当前契约字段，`reuse` 表示可直接复用。不得把 `VALIDATION_MISSING` 翻译成“强制重跑”。
 
@@ -875,6 +875,6 @@ python <skills-root>/scripts/harness_ledger.py diff-hash --repo . --base <baseCo
 
 ## 执行日志记录
 
-`/harness-test` 只向 `events.ndjson` 追加事件（schema_version 3，兼容读取 v1/v2）；`logs/execution-log.md` 由 `harness_events.py append` 自动渲染。Phase 0 之前 append `phase.start`；各阶段写入 `command` / `verification` / `decision` / `issue` / `artifact`，人类可读摘要放 `note`。事件类型与脚本用法见 [[../protocols/report-pipeline-protocol.md|report-pipeline-protocol]] 与 SKILL.md `## 执行日志`。
+`/harness-execute` 只向 `events.ndjson` 追加事件（schema_version 3，兼容读取 v1/v2）；`logs/execution-log.md` 由 `harness_events.py append` 自动渲染。Phase 0 之前 append `phase.start`；各阶段写入 `command` / `verification` / `decision` / `issue` / `artifact`，人类可读摘要放 `note`。事件类型与脚本用法见 [[../protocols/report-pipeline-protocol.md|report-pipeline-protocol]] 与 SKILL.md `## 执行日志`。
 
 关键 `note` / 事件须覆盖：0.1 命令执行模式、fallback 执行器、serviceState、凭证策略、单元测试复用、批量执行器、verification-ledger 写入、关门检查、API 状态（不得把 PARTIAL 写成 NOT_RUN）。

package/harness/bundles/general/codebuddy/harness-knowledge-ingest/SKILL.md

@@ -2,7 +2,7 @@
 name: harness-knowledge-ingest
 description: 确认归档 ZIP 已上传并由 Hunter Platform 在服务端解包、校验和入库。客户端不再构建或维护本地知识索引。
 ---
-<!-- generated by harness_deploy.py; core=3c6eec08da6f5a5c; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=7c08c3960f78dc1a; overlay=none; agent=codebuddy; do not edit -->
 # harness-knowledge-ingest
 
 知识 ingest 完全由 Hunter Platform 负责。归档完成时，客户端生成一个确定性 ZIP；
@@ -40,6 +40,12 @@ powershell.exe -Command "npx hunter-harness archive upload --file '<archive.zip>
 ```
 
 4. 检查响应中的包哈希、服务端保存状态和 `knowledge_status`。
+4.5. **查询面回读验证（强制）**：`knowledgeStatus=ready` 只是入库回执，不代表可查。
+    执行 `npx hunter-harness knowledge status --json` 确认 `pipeline.results_count`
+    符合预期（有候选的归档应 > 0）；再用归档中的已知关键词跑一次
+    `npx hunter-harness knowledge query "<已知关键词>" --json`，`count=0` 视为
+    ingest 未真正完成——报告 `pipeline.jobs` 状态（queued/extracting/failed）
+    并停止宣称 ready，不得仅凭上传回执收尾。
 5. 只有服务端确认原 ZIP 已持久保存且知识状态为 ready，才删除本地待上传 ZIP。
 6. 上传或 ingest 失败时保留 ZIP 与失败收据；修复连接后重试同一个 ZIP，不重新拼散文件。
 

package/harness/bundles/general/codebuddy/harness-knowledge-query/SKILL.md

@@ -2,7 +2,7 @@
 name: harness-knowledge-query
 description: 在规划、实现或排查前，通过 hunter-harness CLI 查询远端项目知识库。远端不可用时直接报告不可用，不建立本地索引或离线回退。
 ---
-<!-- generated by harness_deploy.py; core=3c6eec08da6f5a5c; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=7c08c3960f78dc1a; overlay=none; agent=codebuddy; do not edit -->
 # harness-knowledge-query
 
 项目知识以 Hunter Platform 的服务端索引为唯一真源。客户端只提交查询并消费结果：

package/harness/bundles/general/codebuddy/harness-plan/SKILL.md

@@ -3,7 +3,7 @@ name: harness-plan
 description: 将需求转化为设计文档+实施计划+完整测试场景表，必须在编码前完成。仅当用户显式调用 /harness-plan 或明确要求进入
   Harness 规划阶段时使用；不得因用户描述需求就自动触发。
 ---
-<!-- generated by harness_deploy.py; core=3c6eec08da6f5a5c; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=7c08c3960f78dc1a; overlay=none; agent=codebuddy; do not edit -->
 # harness-plan — 需求规划
 
 ## Purpose
@@ -68,10 +68,10 @@ description: 将需求转化为设计文档+实施计划+完整测试场景表
 | 阶段 | 动作 |
 |------|------|
 | 0 | git status；脏工作区 → baseline 隔离 + `decision`，不询问。环境体检并入 0.5 的引导命令，不再单独跑 doctor |
-| 0.5 | 先定英文 `change-name`（kebab-case，`^[a-z0-9]+(-[a-z0-9]+)*$`）与一次性中文展示标题（建议 6～24 个可见字符，保留必要产品名），然后**一条命令完成引导**：<br>`python <skills-root>/scripts/harness_context.py bootstrap-plan --project . --change <cn> --executor <tool> --title "<中文标题>" --json`<br>它按序做完 doctor → 建 change 骨架 → prepare → state capture（首次把当时 HEAD 固定为不可变 `changeBase`）→ classify（落 `meta/gate-policy.json`）→ 生成合规 `plan_<uuid>` run-id 并追加 `phase.start`，返回紧凑摘要：`runId`/`attempt`/`tier`/`defaultPhases`/`conditionalPhases`/`requiredValidations`/`changeBase`/`head`/`executionRoot`。**重跑复用同一 run-id、不重复写 `phase.start`**（换 run-id 会让 finalize 按生命周期身份 fail-closed）。finalizer 必须复用该 `runId`/`attempt` |
+| 0.5 | 先定英文 `change-name`（kebab-case，`^[a-z0-9]+(-[a-z0-9]+)*$`）与一次性中文展示标题（建议 6～24 个可见字符，保留必要产品名），然后**一条命令完成引导**：<br>`python <skills-root>/scripts/harness_context.py bootstrap-plan --project . --change <cn> --executor <tool> --title "<中文标题>" --json`<br>它按序做完 doctor → 建 change 骨架 → prepare → state capture（首次把当时 HEAD 固定为不可变 `changeBase`）→ classify（落 `meta/gate-policy.json`）→ 生成合规 `plan_<uuid>` run-id 并追加 `phase.start`，返回紧凑摘要：`runId`/`attempt`/`tier`/`defaultPhases`/`conditionalPhases`/`requiredValidations`/`changeBase`/`head`/`executionRoot`。**重跑复用同一 run-id、不重复写 `phase.start`**（换 run-id 会让 finalize 按生命周期身份 fail-closed）。finalizer 必须复用该 `runId`/`attempt`。返回里的 `legacyBootstrap: true` 只是「本次引导前还没有任何交接凭证」的标记（首个阶段的正常状态），不是项目结构需要迁移 |
 | 0.5b | 仅在引导失败需要单步排查时用等价分解——**每条的参数都是必填，少一个就是白跑一轮**：<br>`harness_runtime.py doctor --project . --change-dir ".harness/changes/<cn>" --agent <claude-code\|codebuddy\|codex\|cursor> --json`<br>`harness_context.py prepare --project . --change <cn> --phase plan --executor <tool> --title "<中文标题>" --json`<br>`harness_state.py capture --project . --change-dir ".harness/changes/<cn>" --json`<br>`harness_gate.py classify --change <cn> --stage plan --json`<br>`harness_events.py append --change-dir ".harness/changes/<cn>" --phase plan --type phase.start --run-id plan_<uuid> --attempt 1`<br>⚠️ `--change-dir` 一律是 `.harness/changes/<cn>`（状态目录），**不是** prepare 返回的 `executionRoot`（代码执行根，无 worktree 时等于项目根）——填错会把 gate-policy/events 写到项目根 |
 | 0.6 | 用引导返回的 `tier`/`defaultPhases`/`requiredValidations` 生成 `plannedPhases`，向用户用中文说明可选阶段；确认后运行 `harness_context.py configure-plan --project . --change <cn> --phases "plan,execute,...,archive" --operator <tool> --reason "<中文原因>" --json`。无 Git 或不需要提交时不得加入 `submit`；快速迭代默认 `plan,execute,archive`。省略项由脚本写入 `skippedPhases`，不得伪造阶段事件。<br>⚠️ 无风险信号时 classify 默认 `standard`（`plan,execute,submit,archive` + compile/unitTest/unitTestFull），**不再默认 full**。需要 review 阶段与 apiTest 的高风险变更，在计划文档里写「风险等级: full」或用 `classify --tier-override full` 显式升档 |
-| 1 | 直接执行一次 `npx hunter-harness knowledge query "<用户需求原文>" --limit 10 --json`。这是唯一执行入口，不扫描技能目录、不查找其他脚本；失败记 `issue` 并继续，不建立本地索引或离线回退 |
+| 1 | 直接执行一次 `npx hunter-harness knowledge query "<用户需求原文>" --limit 10 --json`。这是唯一执行入口，不扫描技能目录、不查找其他脚本；失败记 `issue` 并继续，不建立本地索引或离线回退。**查询结果（含 0 条）必须落事件**：`harness_events.py append --phase plan --type command --name "knowledge query" --message "count=<n>" --json`（query 回执的 `receipt.index_generation` 反映索引代数；0 条时可先跑 `npx hunter-harness knowledge status --json`（0.4.11+）区分「job 未跑 / 失败 / 结果为空」） |
 | 2 | 歧义优先检查 + 复杂度分级；先确认会改变实现方向的语义歧义 |
 | 3 | 按复杂度执行有预算的代码探索；简单修复不得扩散到无关模块 |
 | 4 | **设计审批包** blocking user confirmation；确认事件早于 approved 设计文档和 `meta/worktree.json` |

package/harness/bundles/general/codebuddy/harness-plan/checklist.md

@@ -214,6 +214,7 @@ description: harness-plan 的阶段检查清单和覆盖检查列表。仅在执
 
 - [ ] **v2**：只手写 `meta/plan-evidence-input.json`。`plans/*.md` 由 finalize 派生，手写的会被渲染覆盖，只是白写
 - [ ] 任何缺失**都不得手工补写**（包括 `phase.end`）；回到对应阶段改自然输入/staging 后重跑
+- [ ] **phase.start/end 事件对完整**：plan 不经 gate close，0.4.11 起 `context close`/`handoff` 会自动补齐缺失的 `phase.end`（返回体 `phaseEndPair.code=PHASE_END_AUTO_PAIRED`）；发现平台 Run 监控计时不停时先查这对事件，而不是手工写事件
 - [ ] v2 过渡期**不写** `meta/plan-finalization.json` 与 `logs/execution-log.md`；缺这两项不算失败，不得为凑表手工补
 
 
@@ -227,7 +228,7 @@ description: harness-plan 的阶段检查清单和覆盖检查列表。仅在执
 - 如果需求不明确，优先提问而不是猜测后继续设计
 - 任务拆分粒度按复杂度调整——plan 简表保持可追踪，implementation-detail 按风险和复杂度自适应展开
 
-> Plan 的结束行为（禁止询问执行模式、只提示 `/harness-run`）由 `SKILL.md` 的关键规则表定义，
+> Plan 的结束行为（禁止询问执行模式、只提示 `/harness-execute`）由 `SKILL.md` 的关键规则表定义，
 > 详细规则见 `reference.md`「Plan 结束行为规则」。此处不再复述。
 
 ## 事件记录（前置规则）