hunter-harness 0.2.0 → 0.2.2

package/resources/harness/bundles/java/codex/harness-review/protocols.md

@@ -1,68 +0,0 @@
----
-description: harness-review 的原生修复反馈协议。内化 receiving-code-review 能力，但不运行时依赖外部 skill。
----
-
-# harness-review 原生修复反馈协议
-
-本文件定义 `/harness-review` 的 `review-fixback-protocol`。它把 RED/YELLOW 审查建议转成结构化修复反馈，不调用 Superpowers `receiving-code-review`。
-
-## review-fixback-protocol
-
-用于 review 报告生成之后。目标是让 RED/YELLOW 问题可以被后续 run 或人工修复直接消费，同时保持 harness-review 的 advisory 定位。
-
-### 输入
-
-- `reports/review/review-report-YYYYMMDD-HHmm.md`
-- 当前 diff 的 RED/YELLOW 问题清单
-- `plans/<change-name>-test-scenarios.md`
-- `evidence/verification-ledger.json` 与 `evidence/run-task-status.md`（如存在）
-
-### 输出规则
-
-如果存在 RED/YELLOW 问题，必须单独生成结构化 fixback 并写入：
-
-```text
-.harness/changes/<change-name>/reports/review/fixback-YYYYMMDD-HHmm.md
-```
-
-每条 fixback 必须包含：
-
-| 字段 | 要求 |
-|------|------|
-| 等级 | RED / YELLOW |
-| 影响位置 | 文件路径 + 行号或最小可定位区域 |
-| 风险说明 | 说明为什么值得处理 |
-| 推荐修复 | 可执行的修复方向，不写空泛建议 |
-| 验证方式 | 构建、测试、场景编号或人工确认方式 |
-| submit 影响 | 默认 advisory；仅 strict-review-gate=true 时标记阻塞 |
-
-如果没有 RED/YELLOW，必须明确写：
-
-```markdown
-无需 fixback：本次 review 未发现 RED/YELLOW 问题。
-```
-
-### 定位边界
-
-- harness-review 默认仅供参考，不阻塞 submit/archive。
-- `review-fixback-protocol` 只生成修复反馈，不自动修改代码。
-- 不得把 YELLOW 写成必须阻塞 submit。
-- 只有配置 `strict-review-gate: true` 时，RED 才可标记为阻塞 submit。
-
-### 模板
-
-```markdown
-# Review Fixback — <change-name>
-
-## 摘要
-
-- RED: N
-- YELLOW: M
-- strict-review-gate: true/false
-
-## 修复反馈
-
-| # | 等级 | 影响位置 | 风险说明 | 推荐修复 | 验证方式 | submit 影响 |
-|:--:|:----:|----------|----------|----------|----------|-------------|
-| 1 | RED | `path/to/file:123` | ... | ... | `test-scenarios.md` API-001 + 构建命令 | advisory / blocking |
-```

package/resources/harness/bundles/java/codex/harness-review/reference.md

@@ -1,86 +0,0 @@
----
-description: harness-review 的审查标准说明和输出报告完整模板。仅在需要理解审查标准或生成详细报告时读取。
----
-
-# harness-review 参考 — 审查标准
-
-## 为什么需要审查
-
-即使有 TDD 和场景覆盖，仍然可能遗漏一些只在"阅读代码"时才能发现的问题：
-- 违反架构约束（TDD 关注行为，不关注结构）
-- 安全漏洞（测试通常不会故意测试安全攻击）
-- 编码规范偏离（IDE 自动格式化可能产生不一致的风格）
-- 性能隐患（N+1 查询在单元测试中不起眼，但在生产环境是灾难）
-
-> 维度检查项的详细列表和重要性说明见 `checklist.md`，本文件保留"为什么需要审查"概述、严重级别判定标准和输出报告模板。
-
-## 严重级别判定标准
-
-RED/YELLOW/OK 三态的判定原则——结论必须基于实际 diff 内容，不得凭印象；每条建议给出文件:行号 + 修复做法。
-
-| 级别 | 判定原则 | 典型场景 |
-|:----:|------|------|
-| RED | 高风险，强烈建议处理——生产环境会直接造成损失或数据破坏 | 硬编码密码/Token/密钥；SQL 字符串拼接（注入）；新增接口无权限校验；删除/修改已发布接口字段或数据库字段；写操作无事务边界；业务层间循环依赖；接口层跨模块调用；对生产库执行写操作 |
-| YELLOW | 中低风险，建议处理——影响可维护性或存在隐患，但不会立即造成损失 | 数据类暴露不必要可变 setter（应改只读访问器）；控制台输出替代日志框架；集合返回 null 而非空集合；魔法值未定义常量；公共 API 无文档注释；N+1 查询；缺少索引；大事务；逐条 insert；新增非空字段；新增业务方法无对应单元测试 |
-| OK | 该维度在本次 diff 中无问题 | —— |
-
-**判定要点**：
-- 敏感信息（明文 token/密码/密钥）一律 RED，并在报告中以 `<TOKEN_REDACTED>` 等占位符引用
-- 占位符与脱敏做法遵循 `../protocols/sensitive-info-protocol.md`；结论须基于实际 diff 证据，见 `../protocols/evidence-based-reporting-protocol.md`
-- 安全维度的问题默认 RED（除非确属误报）
-- 兼容性维度：删除/修改已发布契约为 RED，新增字段提醒为 YELLOW
-- 测试维度：核心业务方法无任何测试覆盖为 YELLOW（建议补充），不判 RED（review 不阻塞）
-- 当界限模糊时，倾向 YELLOW 并在建议中说明判断依据，让用户决定
-
-## 输出报告完整模板
-
-```markdown
-## 代码审查报告 — <功能名>
-
-### 变更摘要
-- 变更文件: N 个 | +xxx / -xxx
-
-### 审查结果
-
-| 维度 | RED 高风险 | YELLOW 中低风险 | OK 通过 |
-|------|:------:|:------:|:------:|
-| 架构 | 0 | 1 | 4 |
-| 安全 | 0 | 0 | 5 |
-| 编码规范 | 0 | 2 | 4 |
-| 兼容性 | 0 | 0 | 4 |
-| 测试 | 0 | 1 | 3 |
-| 性能 | 0 | 0 | 3 |
-
-### RED 高风险建议（强烈建议处理）
-| # | 文件:行 | 维度 | 问题 | 建议 | 参考优先级 |
-|:--:|---------|------|------|------|:--------:|
-| （列出所有高风险问题） |
-
-### YELLOW 中低风险建议（建议处理）
-| # | 文件:行 | 维度 | 问题 | 建议 | 参考优先级 |
-|:--:|---------|------|------|------|:--------:|
-| 1 | xxx:396 | 架构 | ... | ... | 建议优先处理 |
-| 2 | xxx:25 | 规范 | 数据类暴露可变 setter | 改为只读访问器 | 建议在 submit 前人工确认 |
-
-### 规则对照
-| 规则文件 | 结果 |
-|----------|:----:|
-| architecture.md | OK / FAIL |
-| 项目编码规范（按技术栈，示例：Java 项目的 `java-coding-standards.md`，前端项目按项目实际规则文件） | OK / FAIL |
-| 项目框架规范（按技术栈，示例：Java 项目的 `spring-boot-patterns.md`，其他技术栈按项目实际） | OK / FAIL |
-| testing-conventions.md | OK / FAIL |
-| database-safety.md | OK / FAIL |
-
-### 总结
-RED 高风险建议: N | YELLOW 中低风险建议: M | 仅供参考，不阻塞后续 harness 流程
-```
-
-## Fixback 输出关系
-
-当审查报告包含 RED 或 YELLOW 问题时，执行 `protocols.md` 的 `review-fixback-protocol`，另行生成：
-
-```text
-.harness/changes/<change-name>/reports/review/fixback-YYYYMMDD-HHmm.md
-```
-
-fixback 是给后续修复循环使用的结构化清单，不替代 review-report；无 RED/YELLOW 时记录跳过原因，不生成空文件。

package/resources/harness/bundles/java/codex/harness-run/SKILL.md

@@ -1,129 +0,0 @@
----
-name: harness-run
-description: 按变更簇执行 TDD 编码循环（RED→GREEN→REFACTOR→编译验证），逐变更簇实现计划中的任务。使用场景：开始编码、实现功能、写代码、TDD 编码
----
-<!-- generated by harness_deploy.py; core=9a7af3c66acaad35; overlay=java; agent=codex; do not edit -->
-# harness-run — 需求编码
-
-## Purpose
-
-基于 plan + test-scenarios，按**变更簇**执行 TDD（RED→GREEN→REFACTOR→构建验证），写入 verification-ledger。负责 worktree 创建/切换（见 [[shared/worktree-gate.md|worktree-gate]]）。
-
-## When to Use
-
-触发语："开始编码""实现功能""写代码""TDD编码"。参数：`--subagent` 强制 Subagent-Driven；`--inline` 等同默认；`--fixback` 读最新 review fixback。**默认 Inline，不询问执行模式**。
-
-## 前置条件
-
-- `spec/*-design.md`、`plans/*-plan.md`（含 frontmatter）存在且已审批
-- 读 `meta/worktree.json`：`requested=true` 时 worktree 须存在或 run 负责创建
-
-## Worktree 门禁
-
-读取 `meta/worktree.json`（兼容旧路径 `worktree.json`）：
-
-| 条件 | 行为 |
-|------|------|
-| `requested=false` | 主目录执行 |
-| `requested=true` + path 存在 | 切换 worktree 执行 |
-| `requested=true` + path 不存在 | **必须创建**（run）或 **停止**（test/review/submit） |
-
-**严禁** `requested=true` 时静默回主目录。创建失败 → 停止或 AskUserQuestion 降级（须 🟡WARN + 用户确认）。
-
-**状态与代码分离**：代码/编译/测试在 `worktreeRoot`；`stateDir`（logs/events/ledger/reports）写回 `.harness/changes/<change-name>/`。
-
-创建命令与 JSON 模板 → 各 skill `reference.md`（plan 写决策，run 创建/更新）。
-
-## 统一读取协议
-
-1. **`.harness/changes/<change-name>/` 是唯一真相源** — 所有输入从该目录读取，产物写入对应子目录
-2. **change-name 优先从 frontmatter 读取** — `spec/*-design.md`、`plans/*-plan.md` 的 YAML `change-name`
-3. **frontmatter 缺失时兼容旧格式** — 从路径推断，标记 `🟡 legacy-plan`，不失败
-4. **spec** — 设计真相源：`spec/<change>-design.md`
-5. **plan** — 任务真相源：`plans/<change>-plan.md`
-6. **implementation-detail** — 自适应执行参考；legacy 缺失 🟡WARN，不阻断
-7. **test-scenarios** — 测试真相源：`plans/<change>-test-scenarios.md`
-8. **禁止读取 `docs/superpowers/` 作为正式输入** — 旧草稿仅人工线索
-
-状态目录分层：新路径优先，旧路径兼容 → [[../protocols/state-layout-protocol.md|state-layout-protocol]]
-
-## 执行模式
-
-默认 **Inline Execution**；仅 `--subagent` 切换 Subagent-Driven。
-
-## Workflow 概要
-
-0. 加载上下文（change-name、spec/plan/detail/scenarios/ledger/run-task-status/worktree；`--fixback` 读 fixback）→ append `phase.start`
-0.5. **测试基础设施探测**（先写 `CHECKING`，四项证据齐备后再结论）→ `reference.md` Step 0.5
-1. **变更簇 TDD** — `protocols.md` `run-tdd-protocol`；批量 RED/GREEN；按需 `change-cluster-review-protocol`（高风险 + reviewer 预检可用）
-2. 构建验证 + 写 ledger（diffHash 三部分合并，`reference.md` Step 2c）
-3. **场景覆盖检查**（场景表映射，禁止用用例数冒充场景数）
-4. **关门检查**（10 项）+ 计划状态持久化
-
-**Fixback**：`--fixback` 或用户要求时读 `reports/review/fixback-*.md`；RED 优先；未选用则记 `fixback: advisory-not-applied`。
-
-### Java 构建验证（Maven）
-
-- 所有 `mvn`/`git` 经 `powershell.exe -NoProfile -Command`；命令读 `.harness/config/build-profile.json` 的 `buildCommands`（**禁止 hardcode 模块名/端口**）
-- 增量编译：`buildCommands.compile`（典型 `mvn compile -pl <module> -o -q`）
-- 变更簇 TDD：多测试类合并一次 `mvn test -pl <module> -Dtest=A,B,C -o`；每簇最多一次 RED + 一次 GREEN Maven
-- **轻量 run**：默认只 compile；全量 `mvn test` 仅当改了 mapper/sql/权限/controller/公共模块或用户要求 full-run-validation
-- **install -am**：仅 worktree 首建或上游模块文件变化时（见 ledger-protocol）；非每次 run 强制
-- worktree 中确认 `.mvn/maven.config` 等构建配置存在；缺失时从主目录复制
-## P0 执行可信度规则
-
-- 命令结果不得靠猜测；普通 Bash 被拒 → 立即改用等价 PowerShell 重试一次
-- 仅 PowerShell 成功且有明确证据（构建/git/测试输出、文件存在、exit 0）时可标 ✅OK；否则 ❌FAIL 或 🟡WARN
-- 禁止把 hook 拒绝、静态验证、无输出、用户跳过说成成功 → 详见 [[../protocols/powershell-protocol.md|powershell-protocol]]、[[../protocols/evidence-based-reporting-protocol.md|evidence-based-reporting-protocol]]
-
-## 关键规则（硬门禁速查）
-
-> 全文判定、示例、模板 → `reference.md`；ledger → `../protocols/ledger-protocol.md`
-
-| 域 | 要点 |
-|----|------|
-| **文档输入** | 只读 `.harness/changes/<cn>/`；禁止 `docs/superpowers/` |
-| **变更簇 TDD** | 一簇一次 RED/GREEN；低价值项豁免；新分支必须 RED |
-| **RED/GREEN** | RED 须有效；静态验证 ≠ 测试通过；greenfield 大重写豁免见 reference |
-| **Mapper/DB** | 纯 Mock 不得宣称 DB 验证通过；迁移脚本**永不自动执行** |
-| **探测/ledger** | 基础设施先探测；每次构建/测试写 ledger；三部分 diffHash |
-| **预存变更** | 保留 → baseline 隔离；存在则最终 ≥ 🟡WARN |
-| **关门/状态** | 10 项关门检查；持久化 run-task-status；P0 静态-only 不得建议 submit |
-| **Worktree** | `requested=true` 时代码只写 worktree |
-| **PowerShell** | 所有 git/构建经 `powershell.exe -NoProfile -Command` |
-
-### Java TDD / 数据访问补充
-
-| 项 | 规则 |
-|----|------|
-| **低价值豁免** | ErrorCode 常量、VO/DTO 字段、注释、import 清理、格式化、SQL 脚本、配置模板、文档 — 不单独建测试类；禁止为单个错误码单独跑 Maven |
-| **Mapper / LambdaQueryWrapper / SQL** | 纯 Mock 返回值**不得**宣称 DB 验证通过 → 🟡 静态验证，交 harness-test 真实 DB |
-| **行为性新分支** | 正则/条件/分支逻辑变更新增分支须 RED→GREEN；不属于低价值豁免 |
-| **ledger** | compile 必写；执行了 test 写 unitTest，否则 `NOT_RUN_BY_RUN`；diffHash 三部分合并（见 reference） |
-## Output Format
-
-变更文件表 + 构建/测试证据 + 场景覆盖摘要 + 最终状态（✅OK / 🟡WARN / ❌FAIL）。→ `reference.md`
-
-## 渐进披露
-
-- **Read `protocols.md`** — run-tdd + change-cluster-review
-- **Read `reference.md`** — Step 0–5 细节、TDD/RED/ledger/迁移/安全矩阵
-- **Read `checklist.md`** — 逐步勾选
-
-## 交互白名单
-
-1. **预存变更**：保留 / 暂存 / 终止
-2. **数据库迁移**：展示审查清单并确认（**永不自动执行**）
-3. **worktree 创建失败**：是否改主目录
-
-## 执行日志
-
-`events.ndjson` 为唯一事实源（schema_version 2，`note` 承载人类可读摘要）；`logs/execution-log.md` 由 `harness_events.py` 渲染，**禁止手工 Edit**。结构 → [[../protocols/report-pipeline-protocol.md|report-pipeline-protocol]]
-
-```powershell
-python <skills-root>/scripts/harness_events.py append --change-dir ".harness/changes/<change-name>" --phase <phase> --type phase.start --note "<触发指令>"
-```
-
-> **脚本接线**：`harness_events.py append`；`harness_archive.py finalize`；`harness_preflight.py check`；`harness_ledger.py can-reuse`；`harness_service.py ensure/stop`（须 `--files`/`serviceStart.inputFiles`）。JSON 输出按 D13 护栏解读。
-
-> **Task 4 §6.1 写入契约**：普通 `append` = 加锁 -> 追加一行 -> fsync -> 解锁，**不 load 历史、不渲染**（O(1)，跨进程锁 `events.ndjson.lock`，UUID 用完整 `uuid4().hex` 无需去重扫描）。仅 `--type phase.end` append 在追加成功后渲染一次 `execution-log.md`；显式 `harness_events.py render` 随时从完整 events 重建；`harness_archive.py finalize` 在 collect 前强制 render 一次。高频 command append 期间 log 可能滞后，phase 边界保持最新。

package/resources/harness/bundles/java/codex/harness-run/checklist.md

@@ -1,250 +0,0 @@
-# harness-run 执行检查清单
-
-> 编码执行时逐项勾选，确保不遗漏关键步骤。
-
-## 步骤 0：加载上下文
-
-### 步骤 0.0：Worktree 决策执行 ⚠️
-
-- [ ] 读取 `.harness/changes/<change-name>/worktree.json`
-- [ ] 如果文件缺失：🟡WARN，按 legacy 逻辑询问用户是否主目录执行或创建 worktree
-- [ ] `requested=false` → 主目录执行，记录原因
-- [ ] `requested=true` 且 worktree 存在 → 切换到 worktree 执行
-- [ ] `requested=true` 且 worktree 不存在 → 必须创建 worktree
-- [ ] worktree 创建命令必须使用 PowerShell：`git worktree add ...`
-- [ ] 创建后验证 `.claude/worktrees/<change-name>/.git` 存在
-- [ ] 创建成功后更新 `worktree.json` 的 `created=true/createdAt/createdBy`
-- [ ] 创建失败 → 停止，或 AskUserQuestion 询问是否改为主目录执行
-- [ ] 禁止 `requested=true && worktree 不存在` 时直接主目录执行
-- [ ] 记录 `projectRoot / worktreeRoot / stateDir`
-
-
-
-- [ ] 确定变更名：Glob 搜索 `.harness/changes/*/plans/*-plan.md`（排除 `.harness/archive/*/`），提取 `change-name`
-- [ ] 读取并执行 `worktree.json`：如果 `requested=true` 必须创建/切换 worktree，创建失败则停止或询问用户改为主目录；禁止静默降级
-- [ ] **读取计划文件（主任务源）**：`.harness/changes/<change>/plans/<change>-plan.md` — 获取任务列表和依赖关系
-- [ ] **读取详细计划（补充参考）**：`.harness/changes/<change>/plans/<change>-implementation-detail.md`（如存在）
-- [ ] **读取设计文档**：`.harness/changes/<change>/spec/<change>-design.md` — 获取核心设计决策和不变项
-- [ ] **读取测试场景表**：`.harness/changes/<change>/plans/<change>-test-scenarios.md` — 获取与当前任务相关的测试场景
-- [ ] **读取验证账本**：`.harness/changes/<change>/verification-ledger.json`（如存在）— 复用已有 compile/unitTest 结果
-- [ ] **读取任务状态**：`.harness/changes/<change>/run-task-status.md`（如存在）— 恢复上次运行状态
-- [ ] 确认 `项目规则（见 .harness/context-index.json）/` 规则已加载
-- [ ] 检查构建配置完整性（worktree 中确认 `.mvn/maven.config`、`settings.xml` 等存在）
-- [ ] 依赖模块预安装（worktree 中检查上游模块是否已 `mvn install`）
-- [ ] 代码探索优先用 `codegraph_explore`，仅在返回不完整时补充 Read
-- [ ] append `phase.start`（`note` 含测试基础设施 CHECKING 直至探测完成）
-
-### 步骤 0.1：执行模式
-
-- [ ] 默认 Inline；`--subagent` → Subagent-Driven；**不 AskUserQuestion 选模式**
-
-## 步骤 0.5：测试基础设施探测（⚠️ 必须先于任何 TDD 降级结论）
-
-> 探测完成前，执行日志中只能写 `**测试基础设施**: CHECKING`，不得写任何降级结论。
-
-- [ ] 探测 1：`src/test/java` 目录是否存在
-- [ ] 探测 2：`pom.xml` 是否包含 `spring-boot-starter-test` / `junit` / `mockito` 依赖
-- [ ] 探测 3：是否存在已有测试文件（`*Test.java` 或 `*Tests.java`）
-- [ ] 探测 4：目标模块测试命令是否可运行（`mvn test -pl <module> -o -q` 试运行）
-- [ ] 四项证据收集完毕 → 写结论：✅ 测试基础设施可用 / 🟡 测试基础设施部分可用 / ❌ 测试基础设施不可用
-- [ ] 如果 ❌ 不可用 → 记录 TDD 降级原因（必须引用具体证据，如"模块 X 无 src/test/java 目录"）
-
-## 步骤 0.2：预存变更检测与隔离
-
-> 如果 run 开始前检测到已有未提交变更，必须执行此步骤。
-
-- [ ] 检查 git status 是否有 run 前的预存变更
-- [ ] 如果有预存变更 → 使用 AskUserQuestion 询问用户处理方式（保留/暂存/终止）
-- [ ] 用户选择保留 → 创建 `.harness/changes/<change>/pre-existing-files.json`（文件列表 + diff hash + 用户选择）
-- [ ] 用户选择保留 → 创建 `.harness/changes/<change>/pre-existing-diff.patch`（完整 diff 备份）
-- [ ] 在执行日志中记录预存变更检测结果和用户选择
-
-## 变更簇 TDD 循环
-
-> 默认按变更簇执行 TDD，不按每个小任务单独 RED/GREEN。
-
-### 步骤 1a：划分变更簇
-
-- [ ] 读取 plan.md 任务列表，按业务行为分组为变更簇
-- [ ] 检查是否有低价值 TDD 豁免项（ErrorCode 常量、VO/DTO 字段、注释、import 清理、格式化、SQL 脚本、配置模板、文档）→ 标记为豁免，不单独建测试类
-- [ ] 确定每个变更簇的测试范围（哪些测试类合并执行）
-- [ ] 确认变更簇内 Mapper 查询条件是否需要用真实 DB 验证（非纯 Mock）
-
-### 进入变更簇 RED 前：执行 run-tdd-protocol
-
-- [ ] 在写第一行测试代码或生产代码之前执行 `run-tdd-protocol`（详见 `../protocols.md#协议一run-tdd-protocol`）
-- [ ] 测试基础设施可用 → 写真实 RED，记录：✅ 真实 RED 已建立
-- [ ] 测试基础设施不可用 → 记录降级原因，降级为静态 RED
-- [ ] RED 无效（测试搭建错误、private 访问限制、mock/stubbing 错误等）→ 必须先修测试，禁止进入 GREEN
-
-### RED（写测试 — 按变更簇批量执行）
-
-- [ ] 从场景表选取对应当前变更簇的测试用例
-- [ ] 写单元测试（JUnit 5 + Mockito + AssertJ），**优先通过 public API 验证**（非 private 方法）
-- [ ] **多个测试类合并到一次 Maven 命令执行**：`mvn test -pl <module> -Dtest=TestA,TestB,TestC -o`
-- [ ] **RED 有效性判定**（必须逐项确认）：
-  - [ ] 测试编译通过？（编译失败 → ❌无效 RED，先修测试）
-  - [ ] 未直接调用 private 方法？（private 访问限制 → ❌无效 RED）
-  - [ ] 失败断言指向目标业务行为？（mock/stubbing 错误 → ❌无效 RED）
-  - [ ] 失败原因与本次 bug/需求直接相关？（无关 → ❌无效 RED）
-  - [ ] 无 NoSuchBeanDefinitionException / NPE 来自测试搭建错误 / 不必要 stubbing？
-- [ ] 判定结果写入执行日志：`RED: ✅有效 / 🟡部分有效 / ❌无效`
-- [ ] 如果 ❌无效 RED → 必须先修测试，重新运行 RED，**禁止进入 GREEN**
-- [ ] 如果无测试基础设施 → 降级为静态逻辑验证（在执行日志和覆盖报告中标注覆盖关系，**不得在业务代码注释中标注**）
-
-### 低价值 TDD 豁免检查
-
-- [ ] ErrorCode 常量 → 不单独建测试类，compile 验证 + 被高层测试间接覆盖
-- [ ] VO/DTO 字段 → 不单独建测试类，被 service/API 测试间接覆盖
-- [ ] 注释 / import 清理 / 格式化 → compile 验证即可
-- [ ] SQL 迁移脚本 → 不做 TDD，生成审查清单，标记 NEEDS_DB_VALIDATION
-- [ ] 配置模板 / 文档 → 静态审查
-
-### Mapper 查询条件验证检查
-
-- [ ] 如果变更涉及 Mapper 查询条件 / LambdaQueryWrapper / SQL/XML → 不得用纯 Mock 宣称"自动化测试通过"
-- [ ] 纯 Mock Mapper 测试 → 标记为 🟡静态验证，交给 harness-test 真实 DB 验证
-- [ ] 如果必须自动化 → 使用真实 mapper 或可检查 wrapper 条件的测试方式
-
-### GREEN（最简实现 — 按变更簇批量实现）
-
-- [ ] 写最少代码让变更簇测试全部通过
-- [ ] 遵循约束：Controller 只做参数校验和路由；Service 是唯一业务逻辑层；统一返回 `Result<T>`；集合返回空集合不返回 null；日志用 Slf4j；新增字段允许为空
-
-### REFACTOR（重构）
-
-- [ ] 在测试保护下重构代码结构
-- [ ] 清理过程性注释（如 `// 修复分页查询缺项目类型 Bug`），改写为稳定业务规则描述或删除
-- [ ] 重构后重新运行变更簇测试确认全部通过
-
-### Maven 批量验证（变更簇间）
-
-- [ ] 每个变更簇最多执行一次 RED Maven、一次 GREEN Maven — **不得每新增一个测试类就单独跑一次 Maven**
-- [ ] 多个测试类合并执行：`mvn test -pl <module> -Dtest=TestA,TestB,TestC -o`
-- [ ] 最终 compile 只执行一次（如前面已有 compile 成功证据，可复用 verification-ledger）
-- [ ] 使用 `-q` 模式时：报告中写 `exitCode=0`，不得写 `BUILD SUCCESS`（除非输出中真实出现）
-- [ ] 按需触发 `change-cluster-review-protocol`（详见 `../protocols.md#协议二change-cluster-review-protocol`）
-
-## 步骤 2：编译验证（默认轻量，Maven 批量执行）
-
-- [ ] `mvn compile -pl <module> -o`（始终执行，优先不用 `-q` 以获取 BUILD SUCCESS 证据）
-- [ ] 如果使用 `-q` quiet 模式 → 报告中写 `exitCode=0`，**不得写 BUILD SUCCESS**
-- [ ] 最终 compile 只执行一次，如果前面已有 compile 成功证据，可复用 verification-ledger
-- [ ] 判断是否需要全量 `mvn test`：改了公共模块/mapper/sql/权限认证/controller/VO，或用户要求 full-run-validation → 执行 `mvn test -pl <module> -o`；否则跳过全量 test
-- [ ] 编译失败 → 先分析错误类型（见 reference.md 编译失败策略表）
-- [ ] **写入 verification-ledger.json**：`compile` 项必写（status/command/scope/evidence/时间戳/durationMs）；若执行了 mvn test 则 `unitTest` 项必写（testsRun/failures/errors/skipped/evidence）；未执行时标记 `NOT_RUN_BY_RUN`
-- [ ] 顶层写入 `diffHash` / `currentHead` / `baseCommit` / `module` / `profile`；`diffHash` **必须用三部分合并命令**（inline 见 reference 步骤 2c，与 ledger-protocol 五一致），**禁止仅用 `git diff` 未提交**；`currentHead`=`git rev-parse HEAD`
-- [ ] test/submit/package 阶段如果 diffHash 一致，可复用 run 的 compile/unitTest 结果
-
-## 步骤 3：场景覆盖检查
-
-- [ ] 单元测试场景逐条确认覆盖
-- [ ] 接口测试场景逐条确认代码逻辑覆盖
-- [ ] 数据兼容场景逐条确认（新字段 nullable、旧格式兼容）
-- [ ] 将覆盖结果展示给用户（✅/🟡/❌ 标注）
-- [ ] **覆盖状态必须正确分类**：✅ 自动化测试通过 / 🟡 静态检查未真实测试 / ❌ 未验证
-- [ ] 🟡 静态检查 **不得计入"已测试通过"**
-- [ ] 如果任一 P0 场景仅静态验证 → 最终结果必须是 🟡WARN
-- [ ] 最终摘要禁止写 `5✅ + 17🟡 = 22/22`，必须写 `自动化测试通过: 5 / 静态检查未真实验证: 17 / 未验证: 0`
-
-### 权限/组织过滤类变更：安全矩阵
-
-> 凡是修改了管理员/非管理员、orgCode、数据权限、越权异常等逻辑，必须强制生成。
-
-- [ ] 生成安全矩阵（模板见 reference.md）
-- [ ] 覆盖：超级管理员 token 空/非空 × 请求 orgCode 空/指定 × projectType 有/无
-- [ ] 覆盖：非管理员 token 本组织/空 × 请求 orgCode 本组织/其他组织/空 × projectType 有/无
-- [ ] 如果任一权限边界预期不明确 → 不允许标记 ✅OK
-
-## 步骤 4：关门检查（⚠️ 结束前强制执行）
-
-- [ ] `git status --porcelain`
-- [ ] `git diff --stat`
-- [ ] `git diff --check`（如果失败 → 最终结果必须是 ❌FAIL）
-- [ ] 变更文件是否全部在计划范围内
-- [ ] 是否新增/修改了测试文件
-- [ ] 是否误改 .harness/ 以外的非计划文件（如有 → 至少 🟡WARN，要求用户确认）
-- [ ] 是否有 conflict marker：`<<<<<<<` / `=======` / `>>>>>>>`
-- [ ] 是否有临时 debug：`System.out.println` / `console.log` / `debugger` / 临时 TODO/FIXME
-- [ ] 是否有敏感信息：`password` / `token` / `secret` / `accessKey` / 私有 IP/URL
-- [ ] 代码注释污染检查：生产代码中是否有 `// 修复 xxx Bug` / `// 本次变更` 等过程性注释（如有 → 必须在 REFACTOR 阶段清理）
-
-### 变更来源区分（预存变更隔离）
-
-- [ ] 区分本次 run 修改的文件 vs run 前预存变更的文件
-- [ ] 输出变更来源表（文件 / 来源 / 是否计划内 / 是否允许提交）
-- [ ] 如果存在预存变更 → 最终结果至少为 🟡WARN
-
-### SQL 迁移任务审查清单
-
-> 如果变更涉及 SQL 脚本，必须生成此清单。
-
-- [ ] DROP INDEX 是否存在 IF EXISTS 或等效检查
-- [ ] 新索引名称
-- [ ] 新索引字段
-- [ ] 是否包含 deleted_time
-- [ ] 是否兼容已有数据
-- [ ] 是否包含历史数据修正
-- [ ] 是否需要备份
-- [ ] 是否需要回滚 SQL
-- [ ] SQL 脚本头部已标注"人工审查后手动执行，禁止自动运行"
-- [ ] SQL 任务状态标记为 🟡 NEEDS_DB_VALIDATION（不得标记为自动化测试通过）
-
-## 步骤 5：Worktree checkpoint commit（⚠️ 强制阻断）
-
-> 仅在 worktree 中执行时触发此步骤。在主目录执行时跳过（标记 ⏭️主目录跳过）。
-
-- [ ] 确认当前 cwd 在 `.claude/worktrees/<change-name>/` 下
-- [ ] 生成变更摘要：`git diff --stat` + `git diff --stat --cached`
-- [ ] 构建 commit message：`wip(<scope>): <change-name> 编码完成 — N任务/M文件变更`
-- [ ] **⚠️ 强制阻断**：用 AskUserQuestion 展示变更列表 + commit message，等待用户确认
-- [ ] 用户确认 → 执行 `git add -A` + `git commit`（不用 --no-verify、--no-gpg-sign）
-- [ ] 用户拒绝 → 记录 `❌用户拒绝`，继续后续流程
-- [ ] 记录 checkpoint commit hash 到执行日志
-
-## 步骤 6：计划状态持久化
-
-- [ ] 每个任务状态更新到 plan 文件或新增 `run-task-status.md`
-- [ ] 状态区分：✅ DONE_AUTOMATED_TESTED / 🟡 DONE_STATIC_ONLY / 🟡 DONE_NEEDS_INTERFACE_TEST / 🟡 NEEDS_DB_VALIDATION / ❌ FAILED
-- [ ] 确保后续 harness-test / harness-review 可读取待验证场景
-
-## 执行日志完成记录
-
-- [ ] 追加结束时间、耗时、结果、摘要、checkpoint commit 状态
-- [ ] **执行日志去重检查**：同一阶段不重复追加小节，如需补充应 Edit 原小节
-- [ ] 如果存在 🟡静态验证 P0 场景 → 下一步必须写 `必须先运行 /harness-test`，不得并列"提交代码"
-- [ ] 如果存在 SQL 迁移/DB 验证未完成 → 最终不得输出纯 ✅OK
-
-### 最终状态分级
-
-- [ ] **✅OK**：所有计划内代码变更完成 + 关键 P0 场景已自动化测试通过 + compile 成功 + 无预存变更或已隔离 + 无非计划文件混入 + 无 P0 静态-only 场景
-- [ ] **🟡WARN**：存在 P0/P1 场景仅静态验证 / 存在预存变更 / SQL 需人工执行 / Mapper 只做静态验证 / 低价值 Mock 替代真实验证
-- [ ] **❌FAIL**：compile 失败 / 有效测试失败 / RED 无法建立 / 非计划文件被修改且无法解释 / git diff --check 失败
-- [ ] 如果存在 SQL 迁移/接口验证/DB 验证未完成 → 最终输出 🟡WARN，不得纯 ✅OK
-
-## events 记录（禁止手工 Edit execution-log）
-
-- [ ] 步骤 0 前 append `phase.start`
-- [ ] TDD/compile/test 写 `command` + `verification`；预存/worktree/降级写 `decision`/`issue`
-- [ ] `execution-log.md` 仅由 `harness_events.py` 渲染
-
-## PowerShell-only 命令检查
-
-- [ ] 所有 git 命令使用 `powershell.exe -NoProfile -Command "git ..."`
-- [ ] 所有 Maven 命令使用 `powershell.exe -NoProfile -Command "mvn ..."`
-- [ ] 所有文件系统命令使用 PowerShell
-- [ ] 如果出现 Bash hook error，记录违规命令并将当前阶段至少标为 🟡WARN
-
-## Ledger 必填字段检查
-
-- [ ] verification-ledger.json 包含 changeName/projectRoot/worktreeRoot/stateDir
-- [ ] 包含 currentHead/baseCommit/diffHash/module/profile
-- [ ] 包含 validations.compile 与 validations.unitTest
-- [ ] diffHash 必须用三部分合并命令（inline 见 reference 步骤 2c；commit 前 `baseCommit..HEAD` 部分为空也**必须保留**），`currentHead`=`git rev-parse HEAD`；禁止仅用 `git diff` 未提交——省略第一部分会导致 commit 后 diffHash 变化、run→test 复用链断裂
-- [ ] 缺字段时标记 `ledgerReusable=false`，后续阶段不得复用
-
-## 新筛选参数非法值行为检查
-
-- [ ] 如果新增筛选参数，设计中已明确非法值行为
-- [ ] 如果采用“忽略并不过滤”，必须有用户确认记录
-- [ ] 测试场景覆盖非法值

package/resources/harness/bundles/java/codex/harness-run/protocols.md

@@ -1,78 +0,0 @@
----
-description: harness-run 的原生执行协议。内化 TDD 与变更簇审查能力，但不运行时依赖 Superpowers。
----
-
-# harness-run 原生执行协议
-
-本文件定义 `/harness-run` 的内置执行协议。它吸收 test-driven-development 与 subagent-driven-development 的有效做法，但正式流程不调用 Superpowers，也不把外部 skill 是否存在作为执行条件。
-
-## 协议一：run-tdd-protocol
-
-用于每个变更簇。目标是保留 RED→GREEN→REFACTOR 的行为约束，同时允许 harness 按证据分级处理缺失测试基础设施的现实情况。
-
-### RED 三态
-
-| RED 类型 | 何时使用 | 证据要求 |
-|----------|----------|----------|
-| 真实 RED | 测试基础设施可用，能写测试并运行失败 | 测试编译通过，失败断言指向目标行为 |
-| 静态 RED | 测试基础设施不可用或目标层无法真实验证 | 记录降级原因、静态验证场景、待 harness-test 验证场景 |
-| 复用 RED | 计划和测试场景已明确失败场景，且本轮只执行同一场景的实现 | 引用 test-scenarios 编号与前序证据，仍需在 run 日志登记 |
-
-RED 失败原因必须与目标 bug 或需求直接相关。无效 RED（测试搭建错误、private 访问限制、mock/stubbing 错误、依赖注入失败、NPE 来自测试夹具）不得进入 GREEN。
-
-### GREEN
-
-GREEN 只做让当前变更簇通过的最小实现。不得顺手处理无关重构、顺手扩范围、或把未确认业务决策写入代码。
-
-### REFACTOR
-
-REFACTOR 只允许不改变行为的整理。若重构改变行为，必须回到 RED/GREEN。重构后重新运行当前变更簇对应验证；若无法运行真实测试，必须更新静态验证说明。
-
-### 证据写入
-
-每个变更簇结束必须写入或更新：
-
-- `evidence/verification-ledger.json`：构建/测试命令、证据、diffHash、复用状态。
-- `evidence/run-task-status.md`：任务状态、对应场景、未验证项。
-- `logs/execution-log.md`：RED 类型、GREEN 结果、REFACTOR 结果、验证证据。
-- `events.ndjson`：关键 command / verification / issue / artifact 事件。
-
-禁止把静态验证写成“测试通过”。静态 RED/GREEN 的最终状态至少是 🟡WARN，除非后续真实验证已完成。
-
-## 协议二：change-cluster-review-protocol
-
-用于高风险变更簇后的轻量审查。它内化 subagent-driven-development 的“新上下文审查”价值，但不把每个变更簇的 subagent 审查设为默认流程。
-
-### 触发条件
-
-满足**全部**条件时启用：
-
-- 变更簇命中高风险（数据迁移、权限、安全、并发、幂等、核心契约变更、缺真实测试证据等，见原触发列表任一）
-- `python <skills-root>/scripts/harness_preflight.py check-agents --skills-root <skills-root> --agent harness-reviewer --json` 返回 `usable=true`
-
-未满足时记录“跳过变更簇审查：低风险 / reviewer 不可用 / 后续 harness-review 覆盖”，不得视为降级。
-
-### 审查方式
-
-`usable=true` 时委派只读 `harness-reviewer` 审查当前变更簇 diff。**不 retry**；无效返回 → 主会话 checklist 自审，记 `decision` 事件。
-
-审查范围只限当前变更簇：
-
-- 是否偏离 plan / implementation-detail。
-- 是否遗漏 test-scenarios 中的 P0/P1 场景。
-- 是否破坏 API、数据、权限、安全或兼容契约。
-- 是否引入非计划文件、临时 debug、敏感信息或过程性注释。
-
-### 输出
-
-审查结论写入当前 run 日志：
-
-```markdown
-### 变更簇审查 — <cluster>
-- 触发原因: <risk trigger>
-- 方式: reviewer / 主会话自审 / 跳过
-- 结论: OK / YELLOW / RED
-- 问题: <文件:行 + 建议>
-```
-
-RED 问题必须在当前 run 中处理或明确记录为未处理风险；YELLOW 问题可交给后续 `/harness-review`。