@hunter-harness/workflow-harness 0.2.59 → 0.2.61

package/harness/bundles/general/claude-code/harness-run/SKILL.md

@@ -22,7 +22,7 @@ disallowed-tools:
   - Bash(curl *)
   - Bash(codegraph *)
 ---
-<!-- generated by harness_deploy.py; core=f89f132dc909b0d8; overlay=none; agent=claude-code; do not edit -->
+<!-- generated by harness_deploy.py; core=a5e0c1d624b5fad6; overlay=none; agent=claude-code; do not edit -->
 # harness-run — 需求编码
 
 ## Purpose
@@ -67,7 +67,7 @@ disallowed-tools:
 6. **implementation-detail** — 自适应执行参考；legacy 缺失 🟡WARN，不阻断
 7. **test-scenarios** — 测试真相源：`plans/<change>-test-scenarios.md`
 8. **禁止读取 `docs/superpowers/` 作为正式输入** — 旧草稿仅人工线索
-9. **每个 skill 边界只刷新一次状态快照** — 先运行 `python <skills-root>/scripts/harness_state.py capture --project . --change-dir ".harness/changes/<change-name>" --base <baseCommit> --json`；`changedSegments=[]` 时复用已有 profile/rules/map/change/code 指纹，不再重复跑全量 `harness-sync` 或代码库扫描。`knowledge` 段仅为兼容空段，知识始终按需远端查询；快照不能替代源码读取和验证门禁。
+9. **每个 skill 边界只刷新一次状态快照** — 先运行 `python <skills-root>/scripts/harness_state.py capture --project . --change-dir ".harness/changes/<change-name>" --json`。首次 Plan 捕获时，脚本把当时的 Git HEAD 写入不可变 `changeBase`；后续阶段只刷新 `git.head` 与各段指纹，不得用当前 HEAD 覆盖 `changeBase`。只有迁移旧 change 且已能证明真实计划起点时，才在首次补录时传 `--base <baseCommit>`。`changedSegments=[]` 时复用已有 profile/rules/map/change/code 指纹，不再重复跑全量 `harness-sync` 或代码库扫描。`knowledge` 段仅为兼容空段，知识始终按需远端查询；快照不能替代源码读取和验证门禁。
 
 状态目录分层：新路径优先，旧路径兼容 → [[../protocols/state-layout-protocol.md|state-layout-protocol]]
 > 片段：read-protocol · run 必读文件优先级 → `reference.md` Step 0
@@ -85,6 +85,8 @@ disallowed-tools:
 3. **场景覆盖检查**（场景表映射，禁止用用例数冒充场景数）
 4. **关门检查**（10 项）→ 只执行一次 `harness_gate.py close`；`--to-phase` 必须取返回的 `nextPhases` 或 `plannedPhases` 中 run 的真实后继，禁止写死 test。该命令内部关闭 test guard、写 `phase.end`、释放租约、写 handoff 并补传事件；不得再单独调用 test-guard/context close。失败时按结构化 `recoveryAction` 原样重试，已完成步骤幂等复用。
 
+**阶段归属规则**：只用 `ownerPhase=run` 的任务和场景判定编码阶段结果。`ownerPhase=test` 的任务或场景按计划留给测试阶段属于正常移交，必须记录为“待测试阶段执行”，不得将编码阶段降级为 WARN；只有 run 自身负责的工作未完成、验证降级或证据异常时才使用 WARN。
+
 **Fixback**：入口只用 `launch-review`，后续问题处理通过 `resolve-issue/close` 驱动，不得把修复说明当成新的普通 Run。只读取返回的受影响问题和文件；验证仅失效与 `changedFiles` 相交的目标，其他 Test/Review 证据继续复用。RED 优先；`manual`、`workflow` 或未选用的建议不进入代码批次，使用中文记录处理结论。
 
 **执行器边界**：优先使用项目 build profile 和已有测试入口。禁止为了绕过 ESM、路径或参数问题临时生成 `.js`、`require` 脚本；需要文件式 runner 时使用项目已有入口，确需新增时遵循项目模块类型（例如 ESM 使用 `.mjs`）。runner 包装说明写入 `runnerCommand` 元数据，不得拼进账本的规范 `command`。
@@ -116,7 +118,7 @@ disallowed-tools:
 | **探测/ledger** | 基础设施先探测；每次构建/测试经 `harness_ledger.py record`；禁止手写 ledger JSON；用 canonical `diff-hash --change-dir` |
 | **Gate/Guard** | 跨 Agent/阶段先用 `harness_context.py prepare/begin`；阶段门禁与上下文交接统一用 `harness_gate.py begin/close`；gate 内部负责 guard begin/close，模型只在需要记录测试来源或修复时调用 guard 的 `record/stage/mark` |
 | **预存变更** | 保留 → baseline 隔离；存在则最终 ≥ 🟡WARN |
-| **关门/状态** | 10 项关门检查；持久化 run-task-status；P0 静态-only 不得建议 submit |
+| **关门/状态** | 10 项关门检查；持久化 run-task-status；仅 run-owned P0 静态-only 导致 WARN；test-owned 待办正常移交 |
 | **Worktree** | `requested=true` 时代码只写 worktree |
 | **PowerShell** | 所有 git/构建经 `powershell.exe -NoProfile -Command` |
 

package/harness/bundles/general/claude-code/harness-run/checklist.md

@@ -164,13 +164,14 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 - [ ] 单元测试场景逐条确认覆盖
 - [ ] 接口测试场景逐条确认代码逻辑覆盖
 - [ ] 数据兼容场景逐条确认（新字段 nullable、旧格式兼容）
-- [ ] 将覆盖结果展示给用户（✅/🟡/❌ 标注）
-- [ ] **覆盖状态必须正确分类**：✅ 自动化测试通过 / 🟡 静态检查未真实测试 / ❌ 未验证
+- [ ] 将覆盖结果展示给用户（✅/🟡/❌/⏳ 标注）
+- [ ] **覆盖状态必须正确分类**：✅ 自动化测试通过 / 🟡 静态检查未真实测试 / ❌ 未验证 / ⏳ `ownerPhase=test` 按计划移交
 - [ ] 🟡 静态检查 **不得计入"已测试通过"**
-- [ ] 如果任一 P0 场景仅静态验证 → 最终结果必须是 🟡WARN
+- [ ] 如果任一 `ownerPhase=run` 的 P0 场景仅静态验证 → 最终结果必须是 🟡WARN
+- [ ] `ownerPhase=test` 的任务或场景只记录为“待测试阶段执行”，不得将编码阶段降级为 WARN
 - [ ] 最终摘要禁止写 `5✅ + 17🟡 = 22/22`，必须写 `自动化测试通过: 5 / 静态检查未真实验证: 17 / 未验证: 0`
 - [ ] **禁止用测试用例数（如 178 tests）冒充场景数**——计数对象是 test-scenarios.md 的场景编号
-- [ ] 三类计数自洽：存在 🟡/❌ 场景时"未验证"不得为 0
+- [ ] 四类计数自洽：run-owned 🟡/❌ 计入未验证；test-owned ⏳ 单列移交数量
 - [ ] 输出为场景表映射（UT/API/COM/INT 逐条或范围 ✅/🟡/❌），不得只给聚合测试数
 
 ### 权限/组织过滤类变更：安全矩阵
@@ -238,15 +239,15 @@ description: harness-run 的执行检查清单。仅在编码执行时读取。
 ## 事件收尾记录
 
 - [ ] append `phase.end` **仅**通过 `harness_gate.py close`（禁止手工 Edit `events.ndjson` / 直接 append phase.end 绕过 close 校验）
-- [ ] 如果存在 🟡静态验证 P0 场景 → 下一步必须写 `必须先运行 /harness-test`，不得并列"提交代码"
-- [ ] 如果存在数据库迁移/DB 验证未完成 → 最终不得输出纯 ✅OK
+- [ ] 如果存在 run-owned 🟡静态验证 P0 场景 → 下一步必须写 `必须先运行 /harness-test`，不得并列"提交代码"
+- [ ] 如果 run 阶段负责的数据库迁移/DB 验证未完成 → 最终不得输出纯 ✅OK
 
 ### 最终状态分级
 
-- [ ] **✅OK**：所有计划内代码变更完成 + 关键 P0 场景已自动化测试通过 + 构建成功 + 无预存变更或已隔离 + 无非计划文件混入 + 无 P0 静态-only 场景
-- [ ] **🟡WARN**：存在 P0/P1 场景仅静态验证 / 存在预存变更 / 数据库迁移需人工执行 / 数据访问层只做静态验证 / 低价值 Mock 替代真实验证
+- [ ] **✅OK**：所有计划内代码变更完成 + run-owned 关键 P0 场景已自动化测试通过 + 构建成功 + 无预存变更或已隔离 + 无非计划文件混入 + 无 run-owned P0 静态-only 场景
+- [ ] **🟡WARN**：存在 run-owned P0/P1 场景仅静态验证 / 存在预存变更 / run-owned 数据库验证未完成 / 低价值 Mock 替代真实验证
 - [ ] **❌FAIL**：构建失败 / 有效测试失败 / RED 无法建立 / 非计划文件被修改且无法解释 / git diff --check 失败
-- [ ] 如果存在数据库迁移/接口验证/DB 验证未完成 → 最终输出 🟡WARN，不得纯 ✅OK
+- [ ] `ownerPhase=test` 的待办属于正常阶段移交；不得因为后续阶段尚未执行而把已完成的 run 标成 WARN
 ## PowerShell-only 命令检查
 
 - [ ] 所有 git 命令使用 `powershell.exe -NoProfile -Command "git ..."`

package/harness/bundles/general/claude-code/harness-run/protocols.md

@@ -40,6 +40,8 @@ REFACTOR 只允许不改变行为的整理。若重构改变行为，必须回
 
 禁止把静态验证写成“测试通过”。静态 RED/GREEN 的最终状态至少是 🟡WARN，除非后续真实验证已完成。
 
+上述分级只评估 `ownerPhase=run` 的任务和场景。`ownerPhase=test` 的验证按计划留给测试阶段时，记录为“待测试阶段执行”，不得将编码阶段降级为 WARN；后续阶段未开始不是当前阶段的风险。
+
 ## 协议二：change-cluster-review-protocol
 
 用于高风险变更簇后的轻量审查。它内化 subagent-driven-development 的“新上下文审查”价值，但不把每个变更簇的 subagent 审查设为默认流程。

package/harness/bundles/general/claude-code/harness-run/reference.md

@@ -459,19 +459,20 @@ TestA+TestB+TestC RED → 实现相关代码 → TestA+TestB+TestC GREEN → 最
 
 ### ✅OK
 - 所有计划内代码变更完成
-- 关键 P0 场景已自动化测试通过
+- 所有 `ownerPhase=run` 的关键 P0 场景已自动化测试通过
 - 构建成功
 - 无预存变更或预存变更已明确隔离
 - 无非计划文件混入
-- 无 P0 静态-only 场景
+- 无 run-owned P0 静态-only 场景
+- `ownerPhase=test` 的待办已清楚移交给测试阶段
 
 ### 🟡WARN
-- 存在 P0/P1 场景仅静态验证，需 harness-test
+- 存在 `ownerPhase=run` 的 P0/P1 场景仅静态验证
 - 存在预存变更
-- 数据库迁移脚本需要人工执行或 DB 验证
-- 数据访问层/数据库迁移查询只做静态验证
+- run 阶段负责的数据库迁移脚本需要人工执行或 DB 验证
+- run 阶段负责的数据访问层/数据库迁移查询只做静态验证
 - 使用了低价值 Mock 替代真实验证
-- 构建/测试成功但仍需接口/DB 验证
+- run 阶段负责的接口/DB 验证仍未完成
 
 ### ❌FAIL
 - 构建失败
@@ -480,8 +481,7 @@ TestA+TestB+TestC RED → 实现相关代码 → TestA+TestB+TestC GREEN → 最
 - 非计划文件被修改且无法解释
 - git diff --check 失败
 
-如果存在数据库迁移、接口验证、DB 验证未完成，最终不得输出纯 ✅OK，应输出：
-🟡WARN：编码完成，需 harness-test 验证剩余 DB/API 场景。
+`ownerPhase=test` 的任务或场景按计划留给测试阶段属于正常移交，必须记录为“待测试阶段执行”，不得将编码阶段降级为 WARN。只有这些验证属于 `ownerPhase=run` 且未完成时，才输出 `🟡WARN`。
 
 ## 步骤 2：构建验证（默认轻量，按需全量 test）
 
@@ -544,18 +544,19 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 
 ## 步骤 3：场景覆盖检查
 
-对照场景表，逐条确认代码逻辑已覆盖，**并将覆盖结果展示给用户**。**状态必须三类标注**：
+对照场景表，逐条确认代码逻辑已覆盖，**并将覆盖结果展示给用户**。状态按阶段归属分为四类：
 
 - ✅ **已测试通过**：测试基础设施可用且测试已实际运行通过（测试命令输出测试通过证据，如 Java 的 Tests run + Failures: 0）
 - 🟡 **静态检查通过，未真实测试**：TDD 降级，仅做代码逻辑静态检查。**不得计入"已测试通过"**
 - ❌ **未覆盖 / 未验证**：场景未对应代码逻辑或需端到端验证
+- ⏳ **按计划移交**：场景明确为 `ownerPhase=test`，由测试阶段执行；不计入 run 的 🟡/❌，也不降低编码阶段结果
 
 ### 静态验证不等于测试覆盖（⚠️ 关键规则）
 
 1. 🟡 静态检查 **不得计入"已测试通过"**
-2. 如果任一 P0 场景仅静态验证，则 harness-run 最终结果必须是：
+2. 如果任一 `ownerPhase=run` 的 P0 场景仅静态验证，则 harness-run 最终结果必须是：
    `🟡WARN：编码和编译完成，但存在 P0 场景未真实验证`
-3. 只有所有 P0 场景都有自动化测试或真实接口验证时，最终结果才能是：
+3. 只有所有 run-owned P0 场景都有自动化测试或真实接口验证时，最终结果才能是：
    `✅OK成功`
 4. **最终摘要禁止写**：`5✅ + 17🟡 = 22/22`
 5. **最终摘要必须写**：
@@ -566,7 +567,7 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
    harness-run 结果: 🟡WARN，必须进入 harness-test 后才能 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. **三类计数须自洽**：只要存在任一 🟡 或 ❌ 场景，"未验证"计数不得为 0；"待 harness-test"的场景归入 🟡静态或 ❌未验证，不得既不算 ✅ 又让"未验证:0"。
+7. **四类计数须自洽**：run-owned 的 🟡/❌ 计入未验证；`ownerPhase=test` 单列为 ⏳“按计划移交”，不得冒充 ✅，也不得反向污染 run 的结果。
 8. **输出须为场景表映射**：按 `UT-001~037: ✅X/🟡Y/❌Z`、`API-001~032: ...`、`COM-001~007: ...`、`INT-001~008: ...` 形式逐条或范围标注，不得只给一个聚合测试数。
 
 > 展示格式示例：
@@ -575,9 +576,9 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 > - ✅ UT-001~005: getEnabledIndicators 正常/异常/边界场景已测试通过
 > - 🟡 UT-006~010: getIndicatorPage 分页场景静态验证通过，待测试基础设施补齐后运行 harness-test
 > - ❌ UT-011~015: getIndicatorByCode 场景未覆盖，需补充测试用例
-> - ✅ API-001~005: enabled 接口场景代码逻辑已覆盖（接口测试待 harness-test 验证）
+> - ⏳ API-001~005: `ownerPhase=test`，接口测试按计划移交 harness-test
 > - ✅ COM-001~005: 数据库迁移脚本覆盖
-> - 🟡 INT-001~004: 需端到端部署验证
+> - ⏳ INT-001~004: `ownerPhase=test`，按计划移交测试阶段验证
 > ```
 >
 > **最终汇总**：
@@ -585,6 +586,7 @@ python <skills-root>/scripts/harness_ledger.py record --change-dir ".harness/cha
 > 自动化测试通过: 5
 > 静态检查未真实验证: 17
 > 未验证: 0
+> 按计划移交测试阶段: 4
 > harness-run 结果: 🟡WARN，必须进入 harness-test 后才能 submit
 > ```
 
@@ -767,7 +769,8 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 - 自动化测试通过: K
 - 静态检查未真实验证: M
 - 未验证: P
-- harness-run 结果: ✅OK成功 / 🟡WARN，必须进入 harness-test 后才能 submit
+- 按计划移交测试阶段: Q
+- harness-run 结果: ✅OK成功 / 🟡WARN（只由 run-owned 工作决定）
 
 ### 关门检查结果
 - git status --porcelain: ✅/❌
@@ -785,7 +788,7 @@ powershell.exe -Command "git -C '<project-path>' diff --check"
 - 状态已写入: `.harness/changes/<change-name>/evidence/run-task-status.md`
 
 ### 下一步
-> ⚠️ 如果存在 P0 场景为 🟡静态验证，下一步必须且只能是 harness-test。
+> ⚠️ 如果存在 run-owned P0 场景为 🟡静态验证，下一步必须且只能是 harness-test。
 
 运行 `/harness-test` 验证剩余 P0 场景。
 在 harness-test 通过前，不建议也不应进入 `/harness-submit`。

package/harness/bundles/general/claude-code/harness-submit/SKILL.md

@@ -21,7 +21,7 @@ disallowed-tools:
   - Bash(awk *)
   - Bash(curl *)
 ---
-<!-- generated by harness_deploy.py; core=f89f132dc909b0d8; overlay=none; agent=claude-code; do not edit -->
+<!-- generated by harness_deploy.py; core=a5e0c1d624b5fad6; overlay=none; agent=claude-code; do not edit -->
 # harness-submit — 最终提交（含 worktree 合并）
 
 ## Purpose
@@ -55,7 +55,7 @@ disallowed-tools:
 6. **implementation-detail** — 自适应执行参考；legacy 缺失 🟡WARN，不阻断
 7. **test-scenarios** — 测试真相源：`plans/<change>-test-scenarios.md`
 8. **禁止读取 `docs/superpowers/` 作为正式输入** — 旧草稿仅人工线索
-9. **每个 skill 边界只刷新一次状态快照** — 先运行 `python <skills-root>/scripts/harness_state.py capture --project . --change-dir ".harness/changes/<change-name>" --base <baseCommit> --json`；`changedSegments=[]` 时复用已有 profile/rules/map/change/code 指纹，不再重复跑全量 `harness-sync` 或代码库扫描。`knowledge` 段仅为兼容空段，知识始终按需远端查询；快照不能替代源码读取和验证门禁。
+9. **每个 skill 边界只刷新一次状态快照** — 先运行 `python <skills-root>/scripts/harness_state.py capture --project . --change-dir ".harness/changes/<change-name>" --json`。首次 Plan 捕获时，脚本把当时的 Git HEAD 写入不可变 `changeBase`；后续阶段只刷新 `git.head` 与各段指纹，不得用当前 HEAD 覆盖 `changeBase`。只有迁移旧 change 且已能证明真实计划起点时，才在首次补录时传 `--base <baseCommit>`。`changedSegments=[]` 时复用已有 profile/rules/map/change/code 指纹，不再重复跑全量 `harness-sync` 或代码库扫描。`knowledge` 段仅为兼容空段，知识始终按需远端查询；快照不能替代源码读取和验证门禁。
 
 状态目录分层：新路径优先，旧路径兼容 → [[../protocols/state-layout-protocol.md|state-layout-protocol]]
 > 片段：read-protocol

package/harness/bundles/general/claude-code/harness-sync/SKILL.md

@@ -19,7 +19,7 @@ disallowed-tools:
   - Bash(awk *)
   - Bash(curl *)
 ---
-<!-- generated by harness_deploy.py; core=f89f132dc909b0d8; overlay=none; agent=claude-code; do not edit -->
+<!-- generated by harness_deploy.py; core=a5e0c1d624b5fad6; overlay=none; agent=claude-code; do not edit -->
 # harness-sync
 
 ## Purpose

package/harness/bundles/general/claude-code/harness-test/SKILL.md

@@ -23,7 +23,7 @@ disallowed-tools:
   - Bash(node *)
   - Bash(codegraph *)
 ---
-<!-- generated by harness_deploy.py; core=f89f132dc909b0d8; overlay=none; agent=claude-code; do not edit -->
+<!-- generated by harness_deploy.py; core=a5e0c1d624b5fad6; overlay=none; agent=claude-code; do not edit -->
 # harness-test — 测试执行
 
 ## Purpose
@@ -59,7 +59,7 @@ disallowed-tools:
 6. **implementation-detail** — 自适应执行参考；legacy 缺失 🟡WARN，不阻断
 7. **test-scenarios** — 测试真相源：`plans/<change>-test-scenarios.md`
 8. **禁止读取 `docs/superpowers/` 作为正式输入** — 旧草稿仅人工线索
-9. **每个 skill 边界只刷新一次状态快照** — 先运行 `python <skills-root>/scripts/harness_state.py capture --project . --change-dir ".harness/changes/<change-name>" --base <baseCommit> --json`；`changedSegments=[]` 时复用已有 profile/rules/map/change/code 指纹，不再重复跑全量 `harness-sync` 或代码库扫描。`knowledge` 段仅为兼容空段，知识始终按需远端查询；快照不能替代源码读取和验证门禁。
+9. **每个 skill 边界只刷新一次状态快照** — 先运行 `python <skills-root>/scripts/harness_state.py capture --project . --change-dir ".harness/changes/<change-name>" --json`。首次 Plan 捕获时，脚本把当时的 Git HEAD 写入不可变 `changeBase`；后续阶段只刷新 `git.head` 与各段指纹，不得用当前 HEAD 覆盖 `changeBase`。只有迁移旧 change 且已能证明真实计划起点时，才在首次补录时传 `--base <baseCommit>`。`changedSegments=[]` 时复用已有 profile/rules/map/change/code 指纹，不再重复跑全量 `harness-sync` 或代码库扫描。`knowledge` 段仅为兼容空段，知识始终按需远端查询；快照不能替代源码读取和验证门禁。
 
 状态目录分层：新路径优先，旧路径兼容 → [[../protocols/state-layout-protocol.md|state-layout-protocol]]
 > 片段：read-protocol

package/harness/bundles/general/claude-code/harness-test/checklist.md

@@ -232,7 +232,7 @@ powershell.exe -NoProfile -Command "try { (Invoke-WebRequest -Uri 'http://127.0.
 - `USER_STARTED` → 保留进程，报告中提示用户可手动停止。
 - `REUSED_EXISTING` → 保留进程，除非用户明确要求关闭。
 
-最终报告 / final-summary 必须包含：
+测试报告与 `summary-data.json` 的服务生命周期投影必须包含：
 
 ```md
 ## 服务生命周期
@@ -354,4 +354,4 @@ powershell.exe -NoProfile -Command "try { (Invoke-WebRequest -Uri 'http://127.0.
 - 请求执行器必须在报告中明确记录（四种执行器，含降级原因）
 - 请求耗时统计必须包含在报告中
 - 服务由 AI 启动的情况，测试结束默认 Stop-Process；**即使测试失败也要进入 finally 清理**
-- final-summary 的 apiTest 状态必须用 OK/PARTIAL/BLOCKED/NOT_RUN/FAIL（不得把 PARTIAL 写成 NOT_RUN）
+- `summary-data.json` 与平台监控中的 `apiTest` 状态必须使用 OK/PARTIAL/BLOCKED/NOT_RUN/FAIL（不得把 PARTIAL 写成 NOT_RUN）

package/harness/bundles/general/claude-code/harness-test/pitfalls.md

@@ -32,7 +32,7 @@ description: harness-test 的踩坑规则（来自真实对话日志）。执行
 | 21 | **直接 Edit tracked 应用配置文件** | 测试期间改配置，之后又还原，diff 噪声大 | 把运行时配置覆盖直接写进 tracked 文件 | 生成 ASCII 运行时配置叠加 `C:/temp/harness-test-overlay/<change>/application-harness-test.yml`，启动用该绝对路径叠加（如 `-Dspring.config.additional-location=...`） |
 | 22 | **唯一约束字段与本地预存数据冲突** | 大面积唯一约束冲突，9 个场景 BLOCKED | 执行器用硬编码字段值 | 用随机值（如 `900000 + random`）/ 先查避让 / 用唯一隔离值 |
 | 23 | **setup 失败后继续用 null ID 发送请求** | 后续 9 个接口全部 400/500，掩盖真正问题 | 执行器不区分 BLOCKED 状态 | 执行器强制 setup/test/cleanup 三阶段，依赖未满足 → 标 🟡 BLOCKED，**不发起请求** |
-| 24 | **final-summary 把 PARTIAL 写成 NOT_RUN** | 报告显示"未执行"，但实际跑了 6 个场景 | 状态枚举不完整，只有 OK/FAIL/NOT_RUN | API 维度状态使用 OK/PARTIAL/BLOCKED/NOT_RUN/FAIL，5 PASS+9 BLOCKED+1 FAIL → `apiTest=PARTIAL` |
+| 24 | **归档数据把 PARTIAL 写成 NOT_RUN** | 平台显示「未执行」，但实际跑了 6 个场景 | 状态枚举不完整，只有 OK/FAIL/NOT_RUN | API 维度状态使用 OK/PARTIAL/BLOCKED/NOT_RUN/FAIL，5 PASS+9 BLOCKED+1 FAIL → `apiTest=PARTIAL` |
 | 25 | **AI 启动的服务测试结束不关闭** | 端口长期占用，下次启动端口占用异常（如 `BindException`） | 没有 service lifecycle 管理 | 通过 `service.pid` + `serviceState` 区分，AI_STARTED 默认 Stop-Process，**即使测试失败也 finally 清理** |
 | 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 必须输出一次状态行 |
@@ -208,9 +208,9 @@ $cred = $resp.data.accessToken
 **后果**：后续接口大面积 400/500，掩盖真正的根因（setup 失败）
 **正确做法**：执行器强制 setup/test/cleanup 三阶段；依赖 setup 数据的场景在 test 阶段开头判定依赖，缺失则标 🟡 BLOCKED，**不发起请求**
 
-### 规则 24：final-summary 把 PARTIAL 写成 NOT_RUN
+### 规则 24：归档数据把 PARTIAL 写成 NOT_RUN
 **严重度**：🟡WARN
-**场景**：15 个 API 场景中 5 PASS + 9 BLOCKED + 1 FAIL，final-summary 写 `apiTest=NOT_RUN`
+**场景**：15 个 API 场景中 5 PASS + 9 BLOCKED + 1 FAIL，`summary-data.json` 却写成 `apiTest=NOT_RUN`，导致平台错误显示为「未执行」。
 **后果**：报告与现实不符，下游 review / submit / package 误判
 **正确做法**：API 维度状态使用 5 个值：`OK / PARTIAL / BLOCKED / NOT_RUN / FAIL`。"部分执行+部分阻塞" 是 `PARTIAL`，附说明：`apiTest=PARTIAL — 15 个场景中 5 个 PASS, 9 个 BLOCKED, 1 个 FAIL`
 

package/harness/bundles/general/claude-code/harness-test/reference.md

@@ -708,7 +708,7 @@ TEST_<change-name>_<timestamp>_<short-random>
 - 测试数据: N 条已清理 / M 条遗留
 - credentialRefreshCount: 0
 
-### final-summary（顶层维度状态）
+### 归档数据与平台监控（顶层维度状态）
 - compile: ✅ OK
 - unitTest: ✅ OK / 🟡 REUSED_FROM_RUN
 - apiTest: **OK / PARTIAL / BLOCKED / NOT_RUN / FAIL**
@@ -797,7 +797,7 @@ python <skills-root>/scripts/harness_ledger.py can-reuse --change-dir <dir> --ve
 
 > **P0 场景 BLOCKED 不得仍 OK**：必须 🟡 WARN 或 ❌ FAIL。
 
-### API 测试维度状态（final-summary 中输出）
+### API 测试维度状态（写入 `summary-data.json` 并由平台展示）
 
 | 状态 | 定义 |
 |---|---|

package/harness/bundles/general/claude-code/protocols/archive-report-protocol.md

@@ -1,12 +1,12 @@
 ---
-description: harness-archive 的数据化归档和 final-summary 渲染协议。用于减少模型长篇 HTML 生成、提升数据准确性和页面一致性。
+description: harness-archive 的结构化归档与 summary-data 校验协议。用于减少重复产物、提升数据准确性和平台展示一致性。
 ---
 
 # Archive Report Protocol
 
 ## 原则
 
-archive 不应让模型临场生成 500+ 行 HTML。事实收集与校验由 `harness_archive.py finalize` 单命令完成（cleanup → **freeze（事件 cutoff）** → collect → source consistency → render → renderer consistency → validate → archive-meta 内嵌）；模型仅通过 events 写入维护结论。`meta/archive-meta.md` 由 finalize 生成，禁止手写。历史 archive 回放用 `harness_archive.py replay`（只读，不写 archive-meta / 不跑 cleanup）。
+归档不应维护与平台重复的展示文件。常规入口是 `harness_archive.py execute`：它一次性完成状态采集与自动门禁，再复用预检结果调用 finalize。finalize 执行 cleanup → **freeze（事件 cutoff）** → collect → source consistency → summary validate → archive-meta。模型仅通过 events 写入维护结论。`meta/archive-meta.md` 由 finalize 生成，禁止手写。历史 archive 回放用 `harness_archive.py replay`（只读，不写 archive-meta / 不跑 cleanup）。
 
 `knownRisks` 仅收录 severity∈{warning,error,critical} 的 issue 事件；无 severity 的 issue 进入 `maintenanceNotes`。`finalStatusReasons` 解释 CONDITIONAL_OK/WARN/FAIL 原因。finalize 在 before-manifest 前 cleanup：删除 lock/pid/launcher/credential，截断超大日志。
 
@@ -21,7 +21,6 @@ archive-meta.md
 archive-manifest-before.json
 archive-manifest-after.json
 summary-data.json
-final-summary.html
 events.ndjson（新流程推荐；历史 archive 可缺失）
 ```
 
@@ -81,7 +80,7 @@ events.ndjson（新流程推荐；历史 archive 可缺失）
 }
 ```
 
-`final-summary.html` 的数字必须全部来自 events、`summary-data.json`、ledger 或 manifest，不得手写另一套统计。
+`summary-data.json` 的数字必须全部来自 events、ledger 或 manifest，不得手写另一套统计。
 
 ### 数据采集来源（禁止手写统计）
 
@@ -90,7 +89,7 @@ events.ndjson（新流程推荐；历史 archive 可缺失）
 - `skillCalls`：从 execution-log 统计每个 `harness-<skill>` 小节出现次数（含重入）及结果。
 - `verification` 各项及 `passRate`：来自 `evidence/verification-ledger.json`，不得手写通过率。
 - `reviewSummary.redFixed`/`redConfirmed`/`yellowFixed`/`yellowDeferred`：从 review 报告清单 + 后续修复提交 diff 比对得出，不得手写。
-- `artifacts[]`：本次变更构建出的可分发 package 产物（如 `.jar`/`.war`/`.zip`/`.tar`/`.gz`/`.dll`/`.exe`/`.whl`/`.nupkg` 等）。来自项目构建输出目录扫描（按构建工具识别产物路径，如 Maven `target/*.jar`、Gradle `build/libs/*`、npm `dist/*`、.NET `bin/Release/*`），每项记录 `name`（basename）、`path`（相对仓库根）、`size`、`sha256`（`Get-FileHash -Algorithm SHA256` 计算），不得手写。无构建产物时留空数组（renderer 不渲染该卡）。注意：归档 manifest（`archive-manifest-after.json`）记录的是 `.harness/archive/` 目录文件，不包含项目构建产物，两者不可混用。
+- `artifacts[]`：本次变更构建出的可分发 package 产物（如 `.jar`/`.war`/`.zip`/`.tar`/`.gz`/`.dll`/`.exe`/`.whl`/`.nupkg` 等）。来自项目构建输出目录扫描（按构建工具识别产物路径，如 Maven `target/*.jar`、Gradle `build/libs/*`、npm `dist/*`、.NET `bin/Release/*`），每项记录 `name`（basename）、`path`（相对仓库根）、`size`、`sha256`（`Get-FileHash -Algorithm SHA256` 计算），不得手写。无构建产物时留空数组，平台不展示空卡片。注意：归档 manifest（`archive-manifest-after.json`）记录的是 `.harness/archive/` 目录文件，不包含项目构建产物，两者不可混用。
 - `reportPipeline.commands[]` / `verificationChecks[]` / `validationIssues[]`：来自 `events.ndjson`、ledger、validate 结果。旧 archive 无 events 时可从 ledger/log/manifest 回放，不得编造。
 
 ## manifest/checksum
@@ -121,7 +120,7 @@ powershell.exe -NoProfile -ExecutionPolicy Bypass -File "harness-skills/harness-
 
 ## 页面内容
 
-final-summary 必须突出：
+平台归档摘要必须突出：
 
 1. 本次变更业务目标；
 2. 代码变更统计（diffStat：文件数 / insertions / deletions）；
@@ -134,34 +133,28 @@ final-summary 必须突出：
 禁止出现顶部 `N/A`、正文 `100%` 这类互相矛盾的数据。
 
 
-## final-summary 信息密度要求
+## summary-data 信息密度要求
 
-`summary-data.json` 至少包含 `verification`、`artifacts`、`reviewSummary`、`archiveManifest`、`maintenanceNotes`、`knownRisks`、`manualActions`。renderer 只根据 JSON 渲染，不在 HTML 中重新推理数据。
+`summary-data.json` 至少包含 `verification`、`artifacts`、`reviewSummary`、`archiveManifest`、`maintenanceNotes`、`knownRisks`、`manualActions`。平台只读取该 JSON，不重新推理或维护第二套统计。
 
-`artifacts` 与 `uncommittedTestEvidence` 为空数组时，renderer 不渲染对应卡片（"📦 产物清单"/"🧪 未提交测试证据"），避免空态噪音；非空才渲染。字段在 JSON 中始终保留，仅控制是否展示。
+`artifacts` 与 `uncommittedTestEvidence` 为空数组时，平台不展示对应卡片，避免空态噪音；非空时才展示。字段在 JSON 中始终保留，仅控制界面展示。
 
-## 渲染器
+## 数据校验
 
-默认渲染器为 Node.js：
+`validate` 是 finalize 的内嵌同进程步骤（不存在独立 `report validate` CLI）。validate error 存在时，finalize 恢复原 changes 目录并 exit 非 0，绝不删除原 changes 目录。warning 保留在报告中，但不会被误判为 validate error。Hunter Platform 直接读取已校验的 `summary-data.json`。
 
-```powershell
-powershell.exe -NoProfile -Command "& '<node-path>' 'harness-skills/harness-archive/templates/render-summary.mjs' --summary '.harness/changes/<change>/reports/final/summary-data.json' --out '.harness/changes/<change>/reports/final/final-summary.html'"
-```
-
-PowerShell HTML renderer 仅作 legacy fallback。该脚本以 UTF-8 with BOM 保存，确保 Windows PowerShell 5.1 正确识别编码（无 BOM 会被 5.1 按 ANSI/GBK 误读导致中文 label 乱码）；默认渲染器仍为 Node.js `render-summary.mjs`。
-
-**Python fallback（`harness_archive.py` 内置）**：Node 不可用/超时/exit 非 0/未产出文件时，`harness_archive.py render_final_summary` 自动降级为内置 Python fallback（`render_fallback_html`），渲染含 changeName、finalStatus、`reportPipeline.commands`（command/exitCode）、`verification`（unitTests/apiTests/dbCompatibility）、changedFiles、archiveManifest、knownRisks、manualActions、maintenanceNotes 的确定性 HTML；USER_SKIPPED/BLOCKED_BY_DBA/失败状态可见，所有动态值 HTML 转义。返回结构统一为 `{ok, renderer: node|python-fallback|none, fallbackReason, out_path}`。Node 与 Python fallback **都失败**（`renderer=none, ok=false`）时，finalize 立即恢复原 change 目录并 exit 非 0，**绝不归档无 final-summary.html 的变更**。
+正常完成时，`baseCommit` 与产品 tip 相同属于 `ARCHIVE_BASE_EQUALS_FEATURE_TIP`，必须在暂存前阻断。不得手工改 ledger 或 state snapshot。已有提交确属本变更时，使用 `adopt-existing-range` 生成绑定仓库、ownership 和 diffHash 的不可变收据；主动废弃或被替代时允许零产品增量，但必须记录中文原因，且固定 `releaseEligible=false`。
 
-`validate` 是 `harness_archive.py finalize` 的内嵌同进程步骤（不存在独立 `report validate` CLI）；validate error 存在时，finalize 恢复原 changes 目录并 exit 非 0，绝不删除原 changes 目录。**缺 final-summary.html 恒为 validate error**（不再有"没有 HTML 但只 warning"的分支）。
+候选收据缺失时，`execute` 可以复用身份一致、范围完整的 `unitTestFull` ledger 自动生成本地候选认证。提交只改变 commit 身份而产品树和验证输入未变化时，允许安全重绑定到当前 HEAD；该过程不得执行测试。门禁策略未声明数据库能力且未要求 `dbCompatibility` 时，数据库投影为带原因的 `NOT_APPLICABLE`，不得把缺少无关数据库证据升级为归档错误。
 
 ## 冻结优先 finalize 与两层一致性（schemaVersion 2.3 起）
 
-finalize 在 collect 之前**冻结事件事实**：所有 archive-fact 事件落盘并 fsync 后，写入唯一的 `phase.end` 与 `evidence/evidence-cutoff.json`（`eventCount` + `sha256` + `frozenAt`）。cutoff 之后**禁止再向归档 events.ndjson 追加任何事件**；后续报告生成事实（render/validate 结果、manifest 比对）只写入 finalize JSON payload 与 maintenance outbox，不回写事件流。collect 是纯函数：stage/timeline/durations 全部由冻结事件推导，**不存在选择性 patch 步骤**。
+finalize 在 collect 之前**冻结事件事实**：所有 archive-fact 事件落盘并 fsync 后，写入唯一的 `phase.end` 与 `evidence/evidence-cutoff.json`（`eventCount` + `sha256` + `frozenAt`）。cutoff 之后**禁止再向归档 events.ndjson 追加任何事件**；后续校验结果与 manifest 比对只写入 finalize JSON payload 与 maintenance outbox，不回写事件流。collect 是纯函数：stage/timeline/durations 全部由冻结事件推导，**不存在选择性 patch 步骤**。
 
 两层 validator 顺序执行，任何一层失败都恢复原 change 目录并非零退出：
 
-1. **source consistency**（`validate_source_consistency`，render 前）：summary 事实对照冻结来源——`event_count` 对 cutoff、verification 对 ledger typed metrics projection、review 计数对 sidecars。结果写入 `reportPipeline.sourceConsistency = {ok, issues}`；`ok=false` 时 issue code 含 `event-count-mismatch` / `verification-mismatch`。
-2. **renderer consistency**（`validate_summary`，render 后）：HTML 对照 summary-data，数字不得漂移。
+1. **source consistency**（`validate_source_consistency`）：summary 事实对照冻结来源——`event_count` 对 cutoff、verification 对 ledger typed metrics projection、review 计数对 sidecars。结果写入 `reportPipeline.sourceConsistency = {ok, issues}`；`ok=false` 时 issue code 含 `event-count-mismatch` / `verification-mismatch`。
+2. **summary consistency**（`validate_summary_data`）：检查最终状态与验证结果是否矛盾，以及结构化字段是否满足归档要求。
 
 ## versioned repair（不改写原归档）
 
@@ -171,14 +164,14 @@ finalize 在 collect 之前**冻结事件事实**：所有 archive-fact 事件
 python harness/scripts/harness_archive.py repair --archive-dir ".harness/archive/<archive-id>" --json
 ```
 
-repair 先在 archive 外生成候选 derived version，两层 validator 均通过后，才以不可变新版本写入 `derived/v<N>/{summary-data.json, final-summary.html, repair-record.json}`，并把 `derived/authoritative.json` pointer 指向该版本；**原 summary-data.json、final-summary.html 与 manifest 永不覆盖**。知识层只从 authoritative pointer 指向且 hash 校验通过的版本提取条目。
+repair 先在 archive 外生成候选 derived version。来源校验与数据校验均通过后，才以不可变新版本写入 `derived/v<N>/{summary-data.json, repair-record.json}`，并把 `derived/authoritative.json` pointer 指向该版本；**原 summary-data.json 与 manifest 永不覆盖**。知识层只从 authoritative pointer 指向且 hash 校验通过的版本提取条目。
 
 ## 归档包与服务端知识 ingest（§8）
 
 archive close 的破坏性事务只执行确定性 close：
 
 ```text
-status -> manifest -> move -> collect -> render -> validate -> compare
+execute(one-shot status + gate) -> manifest -> move -> collect -> validate -> compare
 -> 生成确定性核心 ZIP -> 上传并等待服务端持久化/ingest 收据 -> stop AI service -> return
 ```
 
@@ -200,4 +193,4 @@ CONDITIONAL_OK
 
 run/test 本轮新增、更新或安全修复且被 `.gitignore` 忽略的测试，必须先由 `test-tracking.json` + `harness_test_guard.py stage` 精确提交；这类测试不得继续作为“未提交证据”收尾，也不得计入可复用 P0 验证后随 worktree 删除。
 
-`uncommittedTestEvidence` 只兼容历史归档或明确只读的外部证据：归档到 `backups/uncommitted-tests/`，记录文件名、验证范围与未提交原因，并在 final-summary 展示风险。若它是本轮可修改的回归测试，则 archive 必须阻断并要求先走精确跟踪流程。
+`uncommittedTestEvidence` 只兼容历史归档或明确只读的外部证据：归档到 `backups/uncommitted-tests/`，记录文件名、验证范围与未提交原因，并在 `summary-data.json` 中记录风险。若它是本轮可修改的回归测试，则 archive 必须阻断并要求先走精确跟踪流程。

package/harness/bundles/general/claude-code/protocols/evidence-based-reporting-protocol.md

@@ -66,11 +66,11 @@ description: harness 全流程的证据化报告协议。所有 skill 输出必
 | `To <remote>` + 推送范围 | ✅ 推送成功 |
 | 无输出 | ❌ 状态未知 |
 
-## final-summary.html / summary-data.json 状态映射
+## summary-data.json 状态映射
 
-final-summary.html 默认由 `summary-data.json + render-summary.mjs` 渲染；旧占位符模板仅作 legacy reference。
+平台监控直接读取 `summary-data.json`。本地归档不再生成重复的 HTML 报告。
 
-归档前必须执行 `harness_archive.py finalize` 内嵌 validate，或 `harness_archive.py replay` 等价校验。只有 validate 无 error 时，才能宣称 final-summary 与 summary-data 一致；validate error 不得被写成 WARN 或"已完成"。
+归档前必须执行 `harness_archive.py finalize` 内嵌 validate，或使用 `harness_archive.py replay` 做等价校验。只有 validate 无 error 时，才能宣称报告数据有效；validate error 不得被写成 WARN 或「已完成」。
 
 | 数据来源 | 无报告时 |
 |----------|----------|
@@ -122,7 +122,7 @@ harness-review 对代码/变更的审查发现按风险分级，反映的是**
 | 标记 | 含义 | 适用场景 |
 |:----:|------|----------|
 | CONDITIONAL_OK | 条件性通过 | API 测试 `USER_SKIPPED` 或 DB 兼容性 `BLOCKED_BY_DBA` 时的归档最终状态，不得写纯 OK，必须在 knownRisks/manualActions 说明风险接受与后续人工动作 |
-| 🔁REUSED | 复用前阶段结果 | 复用了前一阶段验证结果，final-summary 必须显式标记，不得伪装成重新执行 |
+| 🔁REUSED | 复用前阶段结果 | 复用了前一阶段验证结果，summary-data 必须显式标记，不得伪装成重新执行 |
 | 📝ADVISORY | 参考性未运行 | review 参考性意见，未作为门禁执行 |
 | ⏭️ | 用户选择跳过 | 用户主动选择跳过某步骤（如仅本地 commit 不 push、跳过 test/review） |
 
@@ -131,4 +131,4 @@ harness-review 对代码/变更的审查发现按风险分级，反映的是**
 - skill 执行状态回答"这个步骤跑没跑、成没成"；
 - review 发现严重级回答"被审查的东西有没有问题、问题多大"；
 - 条件态/跳过态回答"这个步骤的最终结论是什么特殊情况"。
-- 三者独立：例如 test skill 可 ✅OK 执行成功，但 review 发现其覆盖的代码存在 RED 问题；又如 archive 可因 `USER_SKIPPED` 给出 CONDITIONAL_OK，同时 review 发现为 YELLOW。final-summary 必须分别展示，不得用一个维度覆盖另一个。
+- 三者独立：例如 test skill 可 ✅OK 执行成功，但 review 发现其覆盖的代码存在 RED 问题；又如 archive 可因 `USER_SKIPPED` 给出 CONDITIONAL_OK，同时 review 发现为 YELLOW。summary-data 必须分别记录，不得用一个维度覆盖另一个。

package/harness/bundles/general/claude-code/protocols/ledger-protocol.md

@@ -14,7 +14,7 @@ description: verification-ledger、diffHash、service-fingerprint 的统一协
 - run 跑过测试命令（如 `mvn test`/`pytest`），test 阶段又原样跑一遍——浪费 3~8 分钟
 - submit/package 各自再 compile+test 一次——同一 diff 被验证三四轮
 - test 通过后用户改了一行注释/删了一个未用 import，package 不知道该不该重测，干脆全量重跑
-- final-summary 只展示全绿，看不出哪些是"重新执行"、哪些是"复用"、哪些是"小改动后复用"
+- 阶段汇总只展示全绿时，看不出哪些是「重新执行」、哪些是「复用」、哪些是「小改动后复用」
 
 verification-ledger 把每次验证（compile / unit test / api test / package）的**结果 + 证据 + 作用范围 + diffHash** 记下来，后续阶段先读 ledger 再决定是否重跑。
 
@@ -255,13 +255,13 @@ API 测试: 🔁 复用上一轮结果（diffHash 未变 / 仅清理性变更）
 | harness-run | 步骤 2 前读（确认是否已有 compile/unitTest 可复用） | 步骤 2 后写 compile + unitTest（若跑了全量测试） |
 | harness-test | Phase 1 前读（复用 run 的 unitTest） | Phase 1/2 后写 unitTest + apiTest |
 | harness-submit | 验证前读（复用 test 的 compile/unitTest） | 若重跑则写回 |
-| harness-archive | 归档前读（汇总各阶段状态用于 final-summary） | 不写（归档时一并移入 archive） |
+| harness-archive | 归档前读（汇总各阶段状态，写入 `summary-data.json` 并上传平台） | 不写（归档时一并移入 archive） |
 
-## 八、状态与 final-summary 的对应
+## 八、状态与归档投影的对应
 
-ledger 的 `status` 与 final-summary 展示状态对应：
+ledger 的 `status` 与 `summary-data.json`、平台监控中的展示状态对应：
 
-| ledger status | 含义 | final-summary 标记 |
+| ledger status | 含义 | 归档与平台标记 |
 |:---:|------|------|
 | `OK`（本阶段真实执行并通过） | 真实验证 | ✅OK |
 | `OK` 但本阶段复用了前一阶段 | 复用 | 🔁REUSED |
@@ -270,7 +270,7 @@ ledger 的 `status` 与 final-summary 展示状态对应：
 | `ADVISORY` | review 参考性 | 📝ADVISORY |
 | postTestClassification=NON_BEHAVIORAL_CLEANUP | 小清理 | 🧹NON_BEHAVIORAL_CLEANUP |
 
-**强制规则**：任何阶段若复用了前一阶段结果，final-summary 必须显示 `🔁REUSED`，**不得伪装成重新执行**。
+**强制规则**：任何阶段若复用了前一阶段结果，`summary-data.json` 与平台监控必须显示 `🔁REUSED`，**不得伪装成重新执行**。
 
 ## 九、Ledger v2（cluster 2）
 
@@ -329,7 +329,7 @@ v2 契约下 `record` 写入前强制解析并校验顶层身份字段，缺失
 | `schemaVersion` | 固定 `3` |
 | `repositoryId` | `harness_paths.repository_identity(repo_root)`（远端规范化 + root commit；无远端回退 git common-dir，跨 worktree 稳定，RET-09） |
 | `changeName` | change 目录名 |
-| `baseCommit` | `--base-commit` → 既有 ledger 值 → `git rev-parse --verify HEAD` |
+| `baseCommit` | `--base-commit` → 既有 ledger 值 → `state-snapshot.json.changeBase`。只有全新 change 的首次 ledger 写入可以用当时 HEAD 建立基线；旧 ledger 迁移缺少以上三种证据时必须报错，禁止用迁移时的当前 HEAD 猜测基线 |
 | `currentHead` | `git rev-parse --verify HEAD`（验证执行时） |
 | `diffHash` | `--diff-hash` → 既有 ledger 值 → 按 ownership 范围重算（§10.3） |
 | `ownershipHash` | 契约 `ownership` 段规范化 JSON 的 sha256 |

package/harness/bundles/general/claude-code/protocols/report-pipeline-protocol.md

@@ -1,5 +1,5 @@
 ---
-description: 结构化事件、summary-data 生成、final-summary 校验和外部可观测性边界协议（finalize/replay）。
+description: 结构化事件、summary-data 生成与校验，以及外部可观测性边界协议（finalize/replay）。
 ---
 
 # Report Pipeline Protocol
@@ -10,7 +10,7 @@ description: 结构化事件、summary-data 生成、final-summary 校验和外
 
 1. **Event Layer**：`events.ndjson` 记录结构化执行事实。
 2. **Report Data Layer**：`summary-data.json` 由程序或确定性规则生成。
-3. **Renderer / Final Report Layer**：`final-summary.html` 只渲染和解释 summary-data，不重新推理统计。
+3. **Platform View Layer**：Hunter Platform 读取 `summary-data.json` 并展示结果，不在本地保存重复报告。
 
 模型可以写维护者结论、风险解释和人工判断，但不得凭印象手写统计数字、通过率、耗时、命令结果或 artifact hash。
 
@@ -19,12 +19,12 @@ description: 结构化事件、summary-data 生成、final-summary 校验和外
 Skill-bundled 脚本（推荐）：
 
 ```powershell
-python <skills-root>/scripts/harness_archive.py finalize --change-dir ".harness/changes/<change-name>" --archive-root ".harness/archive" --json
+python <skills-root>/scripts/harness_archive.py execute --change-dir ".harness/changes/<change-name>" --archive-root ".harness/archive" --intent record-only --closure completed --json
 python <skills-root>/scripts/harness_archive.py replay --archive-dir ".harness/archive/YYYY-MM-DD-<change-name>" --json
 python <skills-root>/scripts/harness_events.py append --change-dir ".harness/changes/<change-name>" --phase "<phase>" --type <type> [--note "..."]
 ```
 
-归档报告流水线只有两个入口，均由 `harness_archive.py` 提供：`collect`/`render`/`validate` 是 `finalize` 的内嵌同进程步骤，**不再作为独立 CLI 暴露**（不存在 `report collect`/`report validate` 子命令）。`summary-data.json` 只能由 `finalize`（归档时）或 `replay`（回放时）生成；**禁止 agent 临场手写或拼装等价的 `summary-data.json`**。`harness_archive.py` 不可用时归档失败退出，不得退回手写汇总。
+归档报告流水线的常规入口是 `execute`。它只采集一次状态并复用给内部 finalize；`collect` 与 `validate` 是 finalize 的内嵌同进程步骤，**不作为独立 CLI 暴露**（不存在 `report collect` / `report validate` 子命令）。`summary-data.json` 只能由 finalize（归档时）或 `replay`（回放时）生成；**禁止 agent 临场手写或拼装等价的 `summary-data.json`**。`harness_archive.py` 不可用时归档失败退出，不得退回手写汇总。
 
 ## events.ndjson
 
@@ -141,15 +141,16 @@ summary-data 必须保留原 archive final report 维度，并增加事件层摘
 
 新增 `reportPipeline` 不替代这些字段；它负责为这些字段提供可追溯的数据来源和一致性校验结果。
 
-## finalize 责任边界（`harness_archive.py finalize`）
+## execute 与 finalize 责任边界
+
+`execute` 负责一次性状态采集、自动门禁、准备耗时事件和对 finalize 的单次调用。常规调用者不得串行执行 `auto-gate`、`status`、`finalize`。finalize 负责正式归档尝试，并复用 execute 传入的预检结果。
 
 | 阶段 | 责任 | 写入 |
 |---|---|---|
 | `collect` | 从 events/ledger/log/manifest/report/git evidence 收集事实 | `summary-data.json` |
-| `render` | 由 `render-summary.mjs` 渲染 final-summary | `final-summary.html` |
-| `validate` | 检查 final-summary 是否覆盖 summary-data 关键事实 | issues；不得静默忽略 error |
+| `validate` | 检查 summary-data 的身份、验证状态与事实是否一致 | issues；不得静默忽略 error |
 
-> **已废弃**：独立 `enrich` 步骤与 `harness-report` skill；全部并入 `finalize` 单命令。回放见 `harness_archive.py replay`。
+> **已废弃**：独立 `enrich` 步骤与 `harness-report` skill；报告生成并入 finalize，常规归档由 `execute` 调用。回放见 `harness_archive.py replay`。
 
 `validate` error 存在时，`harness-archive` 不得删除原 changes 目录。
 
@@ -168,4 +169,4 @@ summary-data 必须保留原 archive final report 维度，并增加事件层摘
 
 - 可保留 `reportPipeline.externalTraceRefs[]` 等扩展字段。
 - 不得要求外部服务可用才允许 archive 成功。
-- 未来接入也必须以 `events.ndjson` 和 `summary-data.json` 为稳定合同，不改变 final-summary 质量维度。
+- 未来接入也必须以 `events.ndjson` 和 `summary-data.json` 为稳定合同，不改变结构化报告的质量维度。

package/harness/bundles/general/claude-code/protocols/sensitive-info-protocol.md

@@ -1,10 +1,10 @@
 ---
-description: harness 全流程的敏感信息脱敏协议。所有 skill 的输出（控制台、execution-log、报告、commit message、final-summary）按本协议脱敏，禁止明文 token/密码/密钥。由原 harness-plan/sensitive-info.md 迁移。
+description: harness 全流程的敏感信息脱敏协议。所有 skill 的输出（控制台、execution-log、报告、commit message、summary-data）按本协议脱敏，禁止明文 token/密码/密钥。由原 harness-plan/sensitive-info.md 迁移。
 ---
 
 # Sensitive Info Protocol
 
-> 本协议适用于所有 harness-skills 的输出（控制台、execution-log.md、package-report、review-report、final-summary.html、commit message）。
+> 本协议适用于所有 harness-skills 的输出（控制台、execution-log.md、package-report、review-report、summary-data.json、commit message）。
 
 ## 1. 禁止明文输出的信息类型
 
@@ -49,7 +49,7 @@ description: harness 全流程的敏感信息脱敏协议。所有 skill 的输
 | 执行日志 | `.harness/changes/<change-name>/logs/execution-log.md` |
 | 审查报告 | `.harness/changes/<change-name>/reports/review/review-report-*.md` |
 | 测试报告 | `.harness/changes/<change-name>/reports/test/test-report-*.md` |
-| 最终总结 | `.harness/archive/YYYY-MM-DD-<change-name>/reports/final/final-summary.html` |
+| 最终总结数据 | `.harness/archive/YYYY-MM-DD-<change-name>/reports/final/summary-data.json` |
 | 归档元数据 | `.harness/archive/YYYY-MM-DD-<change-name>/meta/archive-meta.md` |
 | Commit message | git log 中的提交信息 |