@hunter-harness/workflow-harness 0.4.8 → 0.4.9

package/harness/bundles/general/cursor/contracts/workflow-policy.json

@@ -132,56 +132,6 @@
         "risk-classify-plan"
       ]
     },
-    "harness-run": {
-      "phase": "execute",
-      "inputs": [
-        "implementation-detail",
-        "state-snapshot"
-      ],
-      "artifacts": [
-        "code",
-        "verification-ledger"
-      ],
-      "events": [
-        "phase.start",
-        "phase.end",
-        "command",
-        "verification"
-      ],
-      "allowedInteractions": [],
-      "capabilities": [
-        "gate-begin",
-        "gate-close",
-        "ledger-record"
-      ]
-    },
-    "harness-test": {
-      "phase": "execute",
-      "inputs": [
-        "test-scenarios",
-        "verification-ledger"
-      ],
-      "artifacts": [
-        "test-reports",
-        "verification-ledger"
-      ],
-      "events": [
-        "phase.start",
-        "phase.end",
-        "command",
-        "verification"
-      ],
-      "allowedInteractions": [
-        "resource-intensive-test-confirmation"
-      ],
-      "capabilities": [
-        "gate-begin",
-        "gate-close",
-        "test-guard",
-        "ledger-record",
-        "resource-safe-test-runner"
-      ]
-    },
     "harness-review": {
       "phase": "review",
       "inputs": [

package/harness/bundles/general/cursor/harness-archive/SKILL.md

@@ -3,7 +3,7 @@ name: harness-archive
 description: 归档所有变更产出（计划/测试报告/审查/SQL/API文档）到 .harness/archive/，含归档元数据。仅当用户显式调用
   /harness-archive 时使用；不得被其他阶段 skill 自动接续触发。
 ---
-<!-- generated by harness_deploy.py; core=f3bbb4e119882451; overlay=none; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=b2f31f3090f759b0; overlay=none; agent=cursor; do not edit -->
 # harness-archive — 变更归档
 
 ## Purpose

package/harness/bundles/general/cursor/harness-codebase-map/SKILL.md

@@ -3,7 +3,7 @@ name: harness-codebase-map
 description: 分析现有代码库并生成 .harness/codebase/map/
   下的结构化代码库地图。用于陌生项目理解、重大改造前梳理、harness-sync 提示 map 过期后的人工刷新。
 ---
-<!-- generated by harness_deploy.py; core=f3bbb4e119882451; overlay=none; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=b2f31f3090f759b0; overlay=none; agent=cursor; do not edit -->
 # harness-codebase-map — 代码库地图
 
 ## Purpose

package/harness/bundles/general/cursor/harness-codebase-map/templates/TESTING.md

@@ -61,4 +61,4 @@ status: active
 
 ## Notes for AI Agents
 
-- <how harness-test should use this map>
+- <how harness-execute should use this map>

package/harness/bundles/general/cursor/harness-execute/SKILL.md

@@ -4,11 +4,11 @@ description: 执行阶段：按变更簇执行 TDD
   编码循环（RED→GREEN→REFACTOR→编译验证），随后完成单元/接口/数据兼容验证并输出测试报告。仅当用户显式调用
   /harness-execute 时使用；不得因用户提到编码/实现/测试就自动触发，也不得被其他阶段 skill 自动接续。
 ---
-<!-- generated by harness_deploy.py; core=f3bbb4e119882451; overlay=none; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=b2f31f3090f759b0; overlay=none; agent=cursor; do not edit -->
 # harness-execute — 执行（编码 + 验证）
 
-> 2026-08 阶段合并：原 `run`（编码）与 `test`（验证）合并为单一 `execute` 阶段。
-> `/harness-run` 与 `/harness-test` 保留为别名入口，语义与本 skill 相同。
+> 2026-08 阶段合并：原 `run`（编码）与 `test`（验证）合并为单一 `execute` 阶段；
+> 0.4.9（workflow-harness）起 `/harness-run`、`/harness-test` 入口移除，统一由本 skill 承担。
 
 ## Purpose
 
@@ -16,7 +16,7 @@ description: 执行阶段：按变更簇执行 TDD
 
 ## When to Use
 
-仅当用户显式调用 `/harness-execute`（或别名 `/harness-run`、`/harness-test`）时执行；plan 完成后**不自动**进入本阶段。参数：`--subagent` 强制 Subagent-Driven；`--inline` 等同默认；`--fixback` 读最新 review fixback。**默认 Inline，不询问执行模式**。
+仅当用户显式调用 `/harness-execute` 时执行；plan 完成后**不自动**进入本阶段。参数：`--subagent` 强制 Subagent-Driven；`--inline` 等同默认；`--fixback` 读最新 review fixback。**默认 Inline，不询问执行模式**。
 
 **单阶段原则**：execute 关门后必须停止并交还用户，仅提示 `plannedPhases` 中的真实下一阶段；禁止自动开始其他阶段。
 
@@ -41,7 +41,7 @@ description: 执行阶段：按变更簇执行 TDD
 **状态与代码分离**：代码/编译/测试在 `worktreeRoot`；`stateDir`（logs/events/ledger/reports）写回 `.harness/changes/<change-name>/`。
 
 创建命令与 JSON 模板 → 各 skill `reference.md`（plan 写决策，run 创建/更新）。
-> 片段：worktree-gate · 创建命令 → `harness-run/reference.md`
+> 片段：worktree-gate · 创建命令 → `coding-reference.md`
 
 ## 统一读取协议
 
@@ -62,10 +62,10 @@ description: 执行阶段：按变更簇执行 TDD
 ## Workflow 概要
 
 0. 加载上下文：先 `harness_context.py prepare --project . --change <id> --phase execute --executor <tool> --json`（`--project` 必填），再 `harness_context.py begin --project . --change <id> --phase execute --executor <tool> --json` 校验交接，最后运行 **`harness_gate.py begin --phase execute --change <id>`**。旧名 `--phase run` / `--phase test` 仍被接受并归一为 execute。<br>**交接凭证不必手工补**：v2 计划的 `plan finalize` 不写 context 事务，`prepare` 会在检测到 committed 的 `meta/publication-journals/*.json` 时自动补录 `plan → execute` 凭证（凭证带 `bootstrapSource=plan_publication_journal` 留痕）。仍报 `HANDOFF_REQUIRED`/`LEGACY_BOOTSTRAP_REQUIRED` 说明**没有**这份发布证据——回到 plan 阶段确认发布是否真的完成，**不得**自己拼 `classify + configure-plan + close` 造凭证。<br>**Fixback** 不得拼装底层步骤，必须只调用一次 `harness_fixback.py launch-review --project . --change <id> --change-dir <change-dir> --executor <tool> --skills-root <skills-root> --product-identity <当前产品身份> --json`；返回 `FIXBACK_NOTHING_TO_APPLY` 时直接报告并停止。禁止手写 `events.ndjson` / `phase.end`。
-0.5. **测试基础设施探测**与**命令执行模式 preflight** → `harness-test/reference.md`「命令执行模式 preflight」；测试基线已由 gate begin 内部建立，不得再次执行 guard begin
-1. **变更簇 TDD** — `harness-run/protocols.md` `run-tdd-protocol`；批量 RED/GREEN；按需 `change-cluster-review-protocol`
+0.5. **测试基础设施探测**与**命令执行模式 preflight** → `testing-reference.md`「命令执行模式 preflight」；测试基线已由 gate begin 内部建立，不得再次执行 guard begin
+1. **变更簇 TDD** — `protocols.md` `run-tdd-protocol`；批量 RED/GREEN；按需 `change-cluster-review-protocol`
 2. 构建验证 + **仅**通过 `harness_ledger.py record` 写 ledger（禁止 Write/Edit `verification-ledger.json`）；profile 缺失或陈旧时先 `harness_preflight.py detect --project . --json`；`record --project . --profile-input <key>` 从同一 target 推导 scope、coverage、规范命令与输入闭包
-3. **验证执行**：单元测试可复用则跳过（`harness_ledger.py can-reuse`）；接口测试**强制批量执行器**一次跑完全部场景；数据兼容验证按场景表执行 → `harness-test/reference.md`
+3. **验证执行**：单元测试可复用则跳过（`harness_ledger.py can-reuse`）；接口测试**强制批量执行器**一次跑完全部场景；数据兼容验证按场景表执行 → `testing-reference.md`
 4. **场景覆盖检查**（场景表映射，禁止用用例数冒充场景数）
 5. **关门检查**（10 项）→ 只执行一次 `harness_gate.py close`；`--to-phase` 可省略——计划后继唯一（排除 fixback 自环）时自动派生并交接（输出含 `derivedToPhase`）。仅 fixback 回环时显式传 `--to-phase execute`。该命令内部关闭 test guard、写 `phase.end`、释放租约、写 handoff 并补传事件；不得再单独调用 test-guard/context close。失败时按结构化 `recoveryAction` 原样重试，已完成步骤幂等复用。
 
@@ -79,13 +79,13 @@ description: 执行阶段：按变更簇执行 TDD
 python <skills-root>/scripts/harness_test_runner.py exec --project . --timeout-seconds <预估上限> -- <构建命令及参数>
 ```
 
-资源档位是硬合同（`safe` 默认；`system`/`full` 需用户明确授权或 `--confirm-resource-intensive`）；Python `unittest` 必须逐模块隔离模式（`harness_test_runner.py unittest --profile safe --tests-dir <目录>`）。返回 `TEST_RUN_ALREADY_ACTIVE` 说明已有构建在跑：等待或查明持有者，不得绕开锁另起并行构建。完整约束 → `harness-test/checklist.md`「0.0-A 资源安全档位」。
+资源档位是硬合同（`safe` 默认；`system`/`full` 需用户明确授权或 `--confirm-resource-intensive`）；Python `unittest` 必须逐模块隔离模式（`harness_test_runner.py unittest --profile safe --tests-dir <目录>`），并发上限由 runner 注入的 `HARNESS_TEST_MAX_WORKERS` 决定，不得自行提升。返回 `TEST_RUN_ALREADY_ACTIVE` 说明已有构建在跑：等待或查明持有者，不得绕开锁另起并行构建。完整约束 → `testing-checklist.md`「0.0-A 资源安全档位」。
 
 **长阶段租约**：`gate begin` 的租约默认 TTL 3600 秒，execute 阶段常常跑得更久。租约过期不会中断执行，**也不再阻断收尾**：`gate close` 发现租约过期而 run-id 仍是本阶段的，会自动用原 run-id 重取并照常关门，只在返回体的 `leaseLapsed` 里记录。不需要定期续租；报 `LEASE_ABSENT`/`LEASE_INVALID` 时先确认 begin 真的跑过，**不要**重跑 `gate begin`。
 
 **关门重试是幂等续跑**（0.4.5 workflow 起）：租约释放是 close 的最后一个可失败步骤，handoff/monitor/清草稿任一失败时租约仍持有，原样重跑同一命令即可（已完成步骤由 closeTransaction journal 幂等跳过）。万一处于「phase.end 已写 + 租约已放 + 交接未完成」的历史中间态，重跑 close 会自动识别并补跑剩余步骤（`PHASE_CLOSE_RESUMED`）：未带 `--to-phase` 时从 plannedPhases 派生唯一后继，后继不唯一才报 `PHASE_HANDOFF_PENDING` 并列出候选。**都不需要手工 `harness_change.py claim`**——LEASE_ABSENT 只在 begin 从未跑过时才该出现。
 
-**接口测试执行器优先级**：接口测试执行器（默认首选）> PowerShell batch `.ps1` > Playwright MCP `browser_evaluate`（仅前两者不可用或用户明确选择）> curl + UTF-8 JSON body file（兜底）。执行器在 PowerShell 可用时**禁止**用 Playwright MCP 逐条执行。→ `harness-test/reference.md`「接口测试工具优先级」
+**接口测试执行器优先级**：接口测试执行器（默认首选）> PowerShell batch `.ps1` > Playwright MCP `browser_evaluate`（仅前两者不可用或用户明确选择）> curl + UTF-8 JSON body file（兜底）。执行器在 PowerShell 可用时**禁止**用 Playwright MCP 逐条执行。→ `testing-reference.md`「接口测试工具优先级」
 
 **陈旧测试安全修复**：只有当前生产代码、已批准计划或可验证历史能唯一确定新契约时，才允许仅修改测试并立即重跑，然后记录：
 
@@ -111,7 +111,7 @@ python <skills-root>/scripts/harness_test_guard.py record --project . --change-d
 
 ## 关键规则（硬门禁速查）
 
-> 编码侧细则 → `harness-run/reference.md`、`harness-run/protocols.md`；验证侧细则 → `harness-test/reference.md`、`harness-test/checklist.md`、`harness-test/pitfalls.md`
+> 编码侧细则 → `coding-reference.md`、`protocols.md`；验证侧细则 → `testing-reference.md`、`testing-checklist.md`、`testing-pitfalls.md`
 
 | 域 | 要点 |
 |----|------|
@@ -132,11 +132,11 @@ python <skills-root>/scripts/harness_test_guard.py record --project . --change-d
 
 ## 渐进披露
 
-- **Read `harness-run/protocols.md`** — run-tdd + change-cluster-review
-- **Read `harness-run/reference.md`** — Step 0–5 细节、TDD/RED/ledger/迁移/安全矩阵
-- **Read `harness-test/checklist.md`** — 验证前各项强制检查、preflight、服务生命周期清单
-- **Read `harness-test/reference.md`** — API 测试执行方法、执行器模板、运行时配置叠加
-- **Read `harness-test/pitfalls.md`** — 测试踩坑规则
+- **Read `protocols.md`** — run-tdd + change-cluster-review
+- **Read `coding-reference.md`** — Step 0–5 细节、TDD/RED/ledger/迁移/安全矩阵
+- **Read `testing-checklist.md`** — 验证前各项强制检查、preflight、服务生命周期清单
+- **Read `testing-reference.md`** — API 测试执行方法、执行器模板、运行时配置叠加
+- **Read `testing-pitfalls.md`** — 测试踩坑规则
 
 ## 交互白名单
 

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

@@ -1,8 +1,8 @@
 ---
-description: harness-run 的执行检查清单。仅在编码执行时读取。
+description: harness-execute 的执行检查清单。仅在编码执行时读取。
 ---
 
-# harness-run 执行检查清单
+# harness-execute 执行检查清单
 
 > 编码执行时逐项勾选，确保不遗漏关键步骤。
 
@@ -88,10 +88,10 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 
 ### 进入变更簇 RED 前：执行 run-tdd-protocol
 
-- [ ] 已读取 `harness-run/protocols.md`
+- [ ] 已读取 `protocols.md`
 - [ ] 为当前变更簇选择 RED 类型：真实 RED / 静态 RED / 复用 RED
 - [ ] 真实 RED → 测试编译通过且失败断言指向目标行为
-- [ ] 静态 RED → 记录降级原因、静态验证场景、待 harness-test 验证场景
+- [ ] 静态 RED → 记录降级原因、静态验证场景、待 harness-execute 验证场景
 - [ ] 复用 RED → 引用 test-scenarios 编号与前序证据，并在执行日志登记
 - [ ] 任何 RED 类型都已写入 events.ndjson（`decision` / `verification` / `issue`）
 
@@ -121,7 +121,7 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 ### 数据访问层查询条件验证检查
 
 - [ ] 如果变更涉及数据访问层查询逻辑（Java 的 Mapper/LambdaQueryWrapper/SQL/XML）→ 不得用纯 Mock 宣称"自动化测试通过"
-- [ ] 纯 Mock 数据访问层测试 → 标记为 🟡静态验证，交给 harness-test 真实 DB 验证
+- [ ] 纯 Mock 数据访问层测试 → 标记为 🟡静态验证，交给 harness-execute 真实 DB 验证
 - [ ] 如果必须自动化 → 使用真实数据访问层（非 mock）或可检查查询条件的测试方式
 
 ### 编码前检查（远程客户端 / stub 同源错误）
@@ -157,7 +157,7 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 - [ ] 如果使用静默模式（如 Maven `-q`）→ 报告中写 `exitCode=0`，**不得写"构建成功"字样（如 Java 的 BUILD SUCCESS）**
 - [ ] 最终构建只执行一次，如果前面已有构建成功证据，可复用 verification-ledger
 - [ ] 判断是否需要全量测试：改了公共模块/数据访问层/数据库迁移/权限认证/接口层/数据契约，或用户要求 full-run-validation → 执行测试命令（按技术栈，如 Java 的 `mvn test -pl <module> -o`）；否则跳过全量测试
-- [ ] 构建失败 → 先分析错误类型（见 reference.md 构建失败策略表）
+- [ ] 构建失败 → 先分析错误类型（见 coding-reference.md 构建失败策略表）
 - [ ] **经 `harness_ledger.py record` 写入 ledger**（禁止 Write/Edit `verification-ledger.json`）：`compile` 项必写；若执行了测试则 `unitTest` 项必写；未执行时标记 `NOT_RUN_BY_RUN`
 - [ ] 顶层写入 `diffHash` / `currentHead` / `module` / `profile`；`diffHash` 必须执行 `harness_ledger.py diff-hash --repo . --base <baseCommit> --change-dir ".harness/changes/<change-name>" --json`，纳入 test-tracking manifest 中的 ignored tests；`currentHead`=`git rev-parse HEAD`
 - [ ] test/submit/package 阶段如果 diffHash 一致，可复用 run 的 compile/unitTest 结果
@@ -181,7 +181,7 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 
 > 凡是修改了管理员/非管理员、orgCode、数据权限、越权异常等逻辑，必须强制生成。
 
-- [ ] 生成安全矩阵（模板见 reference.md）
+- [ ] 生成安全矩阵（模板见 coding-reference.md）
 - [ ] 覆盖：超级管理员 token 空/非空 × 请求 orgCode 空/指定 × projectType 有/无
 - [ ] 覆盖：非管理员 token 本组织/空 × 请求 orgCode 本组织/其他组织/空 × projectType 有/无
 - [ ] 如果任一权限边界预期不明确 → 不允许标记 ✅OK
@@ -237,12 +237,12 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 
 - [ ] 每个任务状态只更新到 `evidence/run-task-status.md`；不得修改 finalized plan 文件
 - [ ] 状态区分：✅ DONE_AUTOMATED_TESTED / 🟡 DONE_STATIC_ONLY / 🟡 DONE_NEEDS_INTERFACE_TEST / 🟡 NEEDS_DB_VALIDATION / ❌ FAILED
-- [ ] 确保后续 harness-test / harness-review 可读取待验证场景
+- [ ] 确保后续 harness-execute / harness-review 可读取待验证场景
 
 ## 事件收尾记录
 
 - [ ] append `phase.end` **仅**通过 `harness_gate.py close`（禁止手工 Edit `events.ndjson` / 直接 append phase.end 绕过 close 校验）
-- [ ] 如果存在 run-owned 🟡静态验证 P0 场景 → 下一步必须写 `必须先运行 /harness-test`，不得并列"提交代码"
+- [ ] 如果存在编码侧 🟡静态验证 P0 场景 → 下一步必须写 `必须先完成本阶段的验证执行（见 testing-checklist.md）`，不得并列"提交代码"
 - [ ] 如果 run 阶段负责的数据库迁移/DB 验证未完成 → 最终不得输出纯 ✅OK
 
 ### 最终状态分级

package/harness/bundles/general/{claude-code/harness-run/reference.md → cursor/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/cursor/{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/{claude-code/harness-test/checklist.md → cursor/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/cursor/{harness-test/pitfalls-java.md → harness-execute/testing-pitfalls-java.md}

@@ -1,10 +1,10 @@
 ---
-description: Java/Feign 相关测试踩坑（harness-test）。API 实测前通读；发现客户端路径缺陷时回写 plan 外修复记录。
+description: Java/Feign 相关测试踩坑（harness-execute）。API 实测前通读；发现客户端路径缺陷时回写 plan 外修复记录。
 ---
 
 # Java 测试踩坑补充（Feign / 远程客户端）
 
-> 与 `pitfalls.md`（通用）及 `overlays/java/pitfalls-java.md`（overlay 速查表）互补；本文件收录路径拼接类缺陷的症状与流程要求。
+> 与 `testing-pitfalls.md`（通用）及 `overlays/java/pitfalls-java.md`（overlay 速查表）互补；本文件收录路径拼接类缺陷的症状与流程要求。
 
 ## Feign/客户端路径前缀缺失