@hunter-harness/workflow-harness 0.2.55 → 0.2.56

package/harness/bundles/java/cursor/harness-knowledge-ingest/SKILL.md

@@ -2,7 +2,7 @@
 name: harness-knowledge-ingest
 description: 确认归档 ZIP 已上传并由 Hunter Platform 在服务端解包、校验和入库。客户端不再构建或维护本地知识索引。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-knowledge-ingest
 
 知识 ingest 完全由 Hunter Platform 负责。归档完成时，客户端生成一个确定性 ZIP；

package/harness/bundles/java/cursor/harness-knowledge-query/SKILL.md

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

package/harness/bundles/java/cursor/harness-package/SKILL.md

@@ -2,7 +2,7 @@
 name: harness-package
 description: 增量模块打包：拉取最新→编译验证→mvn package→汇总 jar/war。仅当用户显式调用 /harness-package 时使用，不得自动触发。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-package — 增量模块打包（Java overlay）
 
 ## Purpose

package/harness/bundles/java/cursor/harness-package/checklist.md

@@ -39,7 +39,7 @@ description: harness-package 的8步工作流详细步骤、模块识别方法
 
 **读取 verification-ledger + 确定 baseCommit**：
 
-1. 读取 `.harness/changes/<change-name>/evidence/verification-ledger.json`（旧路径 `verification-ledger.json` 兼容），记录 `unitTest`/`apiTest` 的 status、`diffHash`、`currentHead`
+1. 通过共享状态目录解析器读取 `evidence/verification-ledger.json`（旧路径 `verification-ledger.json` 兼容），记录 `unitTest`/`apiTest` 的 status、`diffHash`、`currentHead`
 2. 确定 `baseCommit`：优先取 `.harness/changes/<change-name>/logs/execution-log.md` 中 harness-submit 阶段的 `final pushed hash`（旧路径 `execution-log.md` 兼容）；无 submit 记录时取当前 `git rev-parse HEAD`
 3. 判断 ledger 是否有效（全部满足才算有效）：
    - `unitTest.status=OK` 且 `apiTest.status=OK`

package/harness/bundles/java/cursor/harness-plan/SKILL.md

@@ -3,7 +3,7 @@ name: harness-plan
 description: 将需求转化为设计文档+实施计划+完整测试场景表，必须在编码前完成。仅当用户显式调用 /harness-plan 或明确要求进入
   Harness 规划阶段时使用；不得因用户描述需求就自动触发。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-plan — 需求规划
 
 ## Purpose
@@ -16,7 +16,7 @@ description: 将需求转化为设计文档+实施计划+完整测试场景表
 
 仅当用户显式调用 `/harness-plan`（或明确说"用 harness 规划这个需求"）时执行。用户只是描述需求、提问或讨论方案时，**不得**自动进入本 skill。
 
-**单阶段原则**：本 skill 只负责 plan 阶段。plan finalize + verify 完成后必须停止并交还用户，仅提示下一步可执行 `/harness-run`；禁止自动开始编码或调用其他 harness 阶段 skill。
+**单阶段原则**：本 skill 只负责 plan 阶段。plan finalize + verify 完成后必须停止并交还用户，仅提示 `plannedPhases` 中的真实下一阶段；禁止自动调用其他阶段 skill。
 
 ## 统一读取协议
 
@@ -67,13 +67,14 @@ description: 将需求转化为设计文档+实施计划+完整测试场景表
 |------|------|
 | 0 | 用当前解释器运行 `harness_runtime.py doctor`，后续消费绝对 argv；git status；脏工作区 → baseline 隔离 + `decision`，不询问 |
 | 0.5 | 确定英文 `change-name` 后，根据需求生成一次简洁的中文展示标题（建议 6～24 个可见字符，保留必要产品名），执行 `harness_context.py prepare --phase plan --executor <tool> [--change <id>] --title "<中文标题>" --json`；英文名继续作为目录与稳定标识。以其唯一 change/executionRoot 初始化 plan-run-id 与 attempt（首次为 1），用同一身份追加 `phase.start`；从第一条知识查询起保留事件证据，并在 finalizer 中复用该身份 |
+| 0.6 | 使用 `classify` 返回的默认阶段和项目能力生成 `plannedPhases`，向用户用中文说明可选阶段；确认后运行 `harness_context.py configure-plan --project . --change <id> --phases "plan,run,...,archive" --operator <tool> --reason "<中文原因>" --json`。无 Git 或不需要提交时不得加入 `submit`；快速迭代默认 `plan,run,archive`。省略项由脚本写入 `skippedPhases`，不得伪造阶段事件 |
 | 1 | `harness-knowledge-query` 单次远端 query（失败记 `issue`，不建立本地索引或离线回退） |
 | 2 | 歧义优先检查 + 复杂度分级；先确认会改变实现方向的语义歧义 |
 | 3 | 按复杂度执行有预算的代码探索；简单修复不得扩散到无关模块 |
 | 4 | **设计审批包** blocking user confirmation；确认事件早于 approved 设计文档和 `meta/worktree.json` |
 | 5–6 | plan + implementation-detail + test-scenarios → `plans/` |
 | 7.5 | 仅 `--adversarial` 对抗评审 |
-| 8 | 在临时产物集上运行 `harness_plan_finalize.py finalize`，随后立即运行 `verify`；成功后把 finalizer 返回的绝对 `receiptPath` 原样传给 `harness_context.py close --from-phase plan --to-phase run --executor <tool> --artifact "<receiptPath>" --json`（也可使用返回的稳定 `artifactRef=meta/plan-finalization.json`），写 append-only handoff receipt；不得手写占位路径；原子发布、派生清单计数对账、完整生命周期、render → `checklist.md` |
+| 8 | 在临时产物集上运行 `harness_plan_finalize.py finalize`，随后立即运行 `verify`；成功后把 finalizer 返回的绝对 `receiptPath` 原样传给 `harness_context.py close`，`--to-phase` 必须取 `plannedPhases` 中 plan 的真实后继，不得写死。写 append-only handoff receipt；不得手写占位路径；原子发布、派生清单计数对账、完整生命周期、render → `checklist.md` |
 
 change-name 范围变更 → 提示重命名或记 🟡WARN（→ `reference.md`）
 
@@ -95,6 +96,9 @@ change-name 范围变更 → 提示重命名或记 🟡WARN（→ `reference.md`
 |------|------|
 | 产物路径 | 只写 `.harness/changes/<cn>/`；禁止 superpowers 输入 |
 | Change 标题 | 首次 Plan 同时确定英文 `change-name` 与中文展示标题；英文名保持目录和机器标识不变，中文标题由 `prepare --title` 持久化，后续阶段只复用、不重新生成 |
+| 阶段计划 | Plan 必须持久化 `plannedPhases`；固定从 plan 开始、以 archive 结束。Test、Review、Submit、Package、API 文档可按项目策略省略；高风险必需项只能转为“提前结束且不可发布”，不得伪装通过 |
+| 产品边界 | `ownership.productPaths` 必须覆盖计划会修改的源文件、测试文件和构建入口；只写目录前缀或精确文件，禁止 `**` 通配。finalize 前对照任务表补齐，避免归档阶段才发现边界缺口 |
+| 空目录 | 不得为“预留目录”生成 `.gitkeep`；只有产品明确需要跟踪空目录时才能创建，并在计划中说明业务原因 |
 | 设计审批包 | 一次 blocking user confirmation 含 worktree（读 `harness.json` `defaultWorktree`） |
 | 阶段 8 | spec/plan/detail/scenarios/gate-policy/worktree 六项标准产物先进入 staging；仅 finalizer 校验成功后发布并写唯一 `phase.end`/log；随后 `verify` 必须确认 start/end、收据完整覆盖六项标准产物、哈希、全部任务表和非空场景清单一致，失败不得手工补终态 |
 | Plan 结束 | **禁止**询问执行模式；只提示 `/harness-run` |

package/harness/bundles/java/cursor/harness-review/SKILL.md

@@ -4,7 +4,7 @@ description: 6维度代码审查（架构/安全/规范/兼容/测试/性能）
   .harness/context-index.json）和测试场景表，在隔离上下文运行。仅当用户显式调用 /harness-review 时使用；不得在
   test 结束后自动接续执行。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-review — 代码审查
 
 ## Purpose
@@ -45,14 +45,14 @@ description: 6维度代码审查（架构/安全/规范/兼容/测试/性能）
 
 ## Workflow
 
-先用 `harness_context.py prepare --phase review --executor <tool> [--change <id>] --json` 与 `harness_context.py begin --phase review --change <id> --executor <tool> --json` 解析唯一 active change 并校验 test→review receipt；多个 active change 未显式选择时返回 `ACTIVE_CHANGE_AMBIGUOUS`，禁止再按 Glob/mtime 猜测。阶段门禁使用 `harness_gate.py begin --phase review --change <id> --task <n> --skills-root <skills-root> --executor-tool <tool> --json`；结束时只执行一次 `harness_gate.py close --phase review --change <id> --status <OK|WARN|FAIL> --run-id <begin-run-id> --to-phase submit|run --executor <tool> --json`，由 gate 完成阶段事件、租约、上下文交接与远端补传。不得手工追加 `phase.start/phase.end` 或再次调用 context close；任一 close 失败不得宣称审查完成。
+先用 `harness_context.py prepare --phase review --executor <tool> [--change <id>] --json` 与 `harness_context.py begin --phase review --change <id> --executor <tool> --json` 解析唯一 active change 并校验实际前序 receipt；多个 active change 未显式选择时返回 `ACTIVE_CHANGE_AMBIGUOUS`，禁止再按 Glob/mtime 猜测。阶段门禁使用 `harness_gate.py begin --phase review --change <id> --task <n> --skills-root <skills-root> --executor-tool <tool> --json`；结束时只执行一次 `harness_gate.py close`，正常路径的 `--to-phase` 取 `plannedPhases` 中 review 的后继，Fixback 才返回 run。由 gate 完成阶段事件、租约、上下文交接与远端补传。不得手工追加阶段边界或再次调用 context close；任一 close 失败不得宣称评审完成。
 
 0. **启动准备** — 确定变更名（Glob `.harness/changes/*/plans/*-plan.md`，排除 `.harness/archive/*/`，读 frontmatter 提取 change-name）；**append `phase.start` 事件**（不得等审查完成才补）
 1. **读取 worktree 状态（门禁检查）** — 读 `.harness/changes/<change-name>/meta/worktree.json`：`requested=true` 但 worktree 不存在 → 停止并提示先修复 `harness-run`，不得静默回主目录（否则 git diff 为空）；`requested=true` 且 worktree 已创建 → spawned agent 用该 worktree 路径执行 `git diff`（确保审查 worktree 变更而非主目录）；`requested=false` → 审查主目录变更
 <!-- @section-id review.delegate -->
-### 2. 审查执行（主会话优先）
+### 2. 审查执行（独立评审优先）
 
-Cursor 提供通用隔离任务能力时，默认优先临时委派一次只读审查，**不要求安装固定 `harness-reviewer`**。子任务只读取 diff、规则和测试证据；主会话核验并写报告。无法委派、spawn 失败、空返回或无报告正文 → 不 retry，继续主会话审查。每次都记一条 `decision`，用 `REVIEW_DELEGATED` 或相应 `REVIEW_INLINE_*` 原因码说明是否委派及原因；正常 inline 不显示为故障。
+Cursor 提供通用隔离任务能力时，默认优先临时委派一次只读审查，**不要求安装固定 `harness-reviewer`，也不运行固定 `harness-reviewer` 预检**。子任务只读取 diff、规则和测试证据；主会话核验并写报告。无法委派、spawn 失败、空返回或无报告正文 → 不 retry，继续主会话审查。每次都记一条 `decision`，用 `REVIEW_DELEGATED` 或相应 `REVIEW_INLINE_*` 原因码说明是否委派及原因；正常 inline 不显示为故障。
 ## Review 定位（重要）
 
 **harness-review 是参考性代码审查阶段，不是硬门禁。**

package/harness/bundles/java/cursor/harness-run/SKILL.md

@@ -3,7 +3,7 @@ name: harness-run
 description: 按变更簇执行 TDD 编码循环（RED→GREEN→REFACTOR→编译验证），逐变更簇实现计划中的任务。仅当用户显式调用
   /harness-run 时使用；不得因用户提到编码/实现就自动触发，也不得被其他阶段 skill 自动接续。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-run — 需求编码
 
 ## Purpose
@@ -14,7 +14,7 @@ description: 按变更簇执行 TDD 编码循环（RED→GREEN→REFACTOR→编
 
 仅当用户显式调用 `/harness-run` 时执行；plan 完成后**不自动**进入本阶段。参数：`--subagent` 强制 Subagent-Driven；`--inline` 等同默认；`--fixback` 读最新 review fixback。**默认 Inline，不询问执行模式**。
 
-**单阶段原则**：run 关门（步骤 4 的 gate close + context close）完成后必须停止并交还用户，仅提示下一步可执行 `/harness-test`；禁止自动开始执行测试、review 或 submit。
+**单阶段原则**：run 关门后必须停止并交还用户，仅提示 `plannedPhases` 中的真实下一阶段；禁止自动开始其他阶段。
 
 ## 前置条件
 
@@ -59,14 +59,16 @@ description: 按变更簇执行 TDD 编码循环（RED→GREEN→REFACTOR→编
 
 ## Workflow 概要
 
-0. 加载上下文：先 `harness_context.py prepare --phase run --executor <tool> [--change <id>] --json`，以返回的唯一 change/executionRoot/transition receipt 为准（多 active 缺参 → `ACTIVE_CHANGE_AMBIGUOUS`，禁止按 mtime 猜测）；再 **`harness_context.py begin --phase run --change <id> --executor <tool> --json`** 校验 Plan artifact/hash/HEAD，读 spec/plan/detail/scenarios/ledger/run-task-status/worktree；`--fixback` 读 fixback → **`harness_gate.py begin --phase run --change <id>`**（claim + phase.start + identity；禁止手工 Write `events.ndjson` / 手工 `phase.end`）。**C3 钩子**：`harness_gate.py begin` 在已连接平台时会 best-effort 调用 events-sync（注册 run / `running`）；失败只告警，不阻断 begin。
+0. 加载上下文：先 `harness_context.py prepare --phase run --executor <tool> [--change <id>] --json`，再 **`harness_context.py begin --phase run --change <id> --executor <tool> --json`** 校验交接。`--fixback` 时紧接着运行 `harness_fixback.py resume --change-dir "<executionRoot>"`，只消费返回的 `batchId/runId/attempt/nextStep/changedFiles/requiredVerifications`；重复调用必须复用同一批次和轮次，不重新通读实现或另建脚本。最后运行 **`harness_gate.py begin --phase run --change <id>`**；上下文未完成时 gate 会在创建租约前拒绝。禁止手写 `events.ndjson` / `phase.end`。已连接平台时 begin 会 best-effort 补传事件，失败只告警。
 0.5. **测试基础设施探测**（先写 `CHECKING`，四项证据齐备后再结论）→ `reference.md` Step 0.5；测试基线已由上一步 gate begin 内部建立，不得再次执行 guard begin
 1. **变更簇 TDD** — `protocols.md` `run-tdd-protocol`；批量 RED/GREEN；按需 `change-cluster-review-protocol`（高风险 + reviewer 预检可用）
 2. 构建验证 + **仅**通过 `harness_ledger.py record` 写 ledger（禁止 Write/Edit `verification-ledger.json`）；`diff-hash --change-dir` 纳入 ignored tests → `reference.md` Step 2c
 3. **场景覆盖检查**（场景表映射，禁止用用例数冒充场景数）
-4. **关门检查**（10 项）→ 只执行一次 **`harness_gate.py close --phase run --change <id> --status <OK|WARN|FAIL> --to-phase test --executor <tool> --json`**。该命令内部依次关闭 test guard、写 `phase.end`、释放阶段租约、写 append-only handoff，并立即补传远端事件；不得再单独调用 test-guard/context close。若返回 `PHASE_HANDOFF_PENDING`，修正明确指出的输入后原样重试同一命令，已完成步骤会幂等复用。
+4. **关门检查**（10 项）→ 只执行一次 `harness_gate.py close`；`--to-phase` 必须取返回的 `nextPhases` 或 `plannedPhases` 中 run 的真实后继，禁止写死 test。该命令内部关闭 test guard、写 `phase.end`、释放租约、写 handoff 并补传事件；不得再单独调用 test-guard/context close。失败时按结构化 `recoveryAction` 原样重试，已完成步骤幂等复用。
 
-**Fixback**：`--fixback` 或用户要求时读 `reports/review/fixback-*.md`；RED 优先；未选用则记 `fixback: advisory-not-applied`。
+**Fixback**：必须通过 `harness_fixback.py resume/add-issue/resolve-issue/close` 驱动，不得把修复说明当成新的普通 Run。只读取返回的受影响问题和文件；验证仅失效与 `changedFiles` 相交的目标，其他 Test/Review 证据继续复用。RED 优先；未选用则用中文记录“本轮未采纳该改进建议”。
+
+**执行器边界**：优先使用项目 build profile 和已有测试入口。禁止为了绕过 ESM、路径或参数问题临时生成 `.js`、`require` 脚本；需要文件式 runner 时使用项目已有入口，确需新增时遵循项目模块类型（例如 ESM 使用 `.mjs`）。runner 包装说明写入 `runnerCommand` 元数据，不得拼进账本的规范 `command`。
 
 **Foundation Gate**：若 `meta/implementation-checkpoints.json` 中 `foundation-gate` 为 pending，不得开始 plan 中任务 6+；由 `harness_gate.py` 硬阻断。
 

package/harness/bundles/java/cursor/harness-run/checklist.md

@@ -26,7 +26,7 @@
 - [ ] **读取详细计划（补充参考）**：`.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 结果
+- [ ] **读取验证账本**：通过共享状态目录解析器定位 change，再读取 `evidence/verification-ledger.json`（兼容旧路径）— 复用已有 compile/unitTest 结果
 - [ ] **读取任务状态**：`.harness/changes/<change>/run-task-status.md`（如存在）— 恢复上次运行状态
 - [ ] 确认 `项目规则（见 .harness/context-index.json）/` 规则已加载
 - [ ] 检查构建配置完整性（worktree 中确认 `.mvn/maven.config`、`settings.xml` 等存在）

package/harness/bundles/java/cursor/harness-run/reference.md

@@ -88,7 +88,7 @@ powershell.exe -NoProfile -Command "Test-Path '.worktrees/<change-name>/.git'"
 4. **读取详细计划（补充参考）**：`.harness/changes/<change-name>/plans/<change-name>-implementation-detail.md`（如存在）→ 获取详细执行说明
 5. **读取设计文档**：`.harness/changes/<change-name>/spec/<change-name>-design.md` �? 获取核心设计决策和不变项
 6. **读取测试场景�?**：`.harness/changes/<change-name>/plans/<change-name>-test-scenarios.md` �? 获取测试真相�?
-7. **读取验证账本**：`.harness/changes/<change-name>/verification-ledger.json`（如存在）→ 复用已有 compile/unitTest 结果
+7. **读取验证账本**：`通过共享状态目录解析器定位的 evidence/verification-ledger.json`（如存在）→ 复用已有 compile/unitTest 结果
 8. **读取任务状�?**：`.harness/changes/<change-name>/run-task-status.md`（如存在）→ 恢复上次运行状�?
 9. 确认 `项目规则（见 .harness/context-index.json�?/` 规则已加�?
 10. **执行测试基础设施探测**（见下方"步骤 0.5"�?
@@ -501,7 +501,7 @@ powershell.exe -Command "mvn test -pl <module> -o"
 
 ### 2c. 写入 verification-ledger
 
-步骤 2 完成�?**必须**写入/更新 `.harness/changes/<change-name>/verification-ledger.json`�?
+步骤 2 完成�?**必须**写入/更新 `通过共享状态目录解析器定位的 evidence/verification-ledger.json`�?
 
 - `compile` 项：始终写入（status / command / scope / evidence / 时间�? / durationMs�?
 - `unitTest` 项：仅当 2b 执行了全�? mvn test 时写入（testsRun / failures / errors / skipped / evidence）；未执行时标记 `{"status": "NOT_RUN_BY_RUN", "note": "轻量验证，全量单元测试由 harness-test 执行"}`

package/harness/bundles/java/cursor/harness-submit/SKILL.md

@@ -3,16 +3,16 @@ name: harness-submit
 description: 最终提交封装：验证→中文 commit→提交/推送；worktree 模式含 --no-ff 合并回主分支。仅当用户显式调用
   /harness-submit（或 /harness-merge 重入合并段）时使用；用户口头说'提交/commit/push'时必须先确认，不得自动触发。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-submit — 最终提交（含 worktree 合并）
 
 ## Purpose
 
-合并最新代码→最终验证→生成中文 commit→提交/推送；worktree 模式在本地 commit 后**自动接续** `--no-ff` 合并回主分支、push、清理 worktree，完成开发闭环。
+仅在 `plannedPhases` 包含 Submit 时执行 Git 提交/推送交付；没有 Git、没有远端或本次计划省略 Submit 时直接进入下一计划阶段，不得把 Submit 当作归档前提。
 
 ## When to Use
 
-仅当用户显式调用 `/harness-submit`（或 `/harness-merge` 从合并段重入）时执行。用户口头说「提交代码」「commit」「push」「完成开发」而未调用本 skill 时，先确认是否走 Harness 提交阶段，**不得自动触发**。前置：review 和 test 已通过或已明确跳过。
+仅当用户显式调用 `/harness-submit`（或 `/harness-merge` 从合并段重入）且 `plannedPhases` 包含 Submit 时执行。用户口头说「提交代码」「commit」「push」「完成开发」而未调用本 skill 时，先确认。前置阶段只按实际计划检查；Test/Review 被计划省略时不得补跑。
 
 > **主目录模式**（`worktree.json` requested=false）：commit+push 主分支后**停止**，仅提示可执行 `/harness-archive`，不自动归档。**worktree 模式**（requested=true）：worktree 内仅本地 commit，随后本 skill 在同一次调用内接续合并流程（这是同一次提交动作的一部分，不属于跨阶段自动推进）；**push 只在主分支发生一次**；合并完成后同样**停止**，仅提示 `/harness-archive`。
 
@@ -56,14 +56,14 @@ worktree 合并前必须运行 `harness_change.py integration-lock acquire --run
 
 0. **启动准备** — `harness_context.py prepare --phase submit --executor <tool> [--change <id>] --json` 确定唯一变更与 executionRoot；`harness_context.py begin --phase submit --change <id> --executor <tool> --json` 校验 review→submit receipt；**`harness_gate.py begin --phase submit --change <id>`**；读 ledger，以 `harness_ledger.py diff-hash --repo . --base <baseCommit> --change-dir ".harness/changes/<change-name>" --json` 计算 diffHash + post-test 7 类分类（禁止手写 ledger / 手工 phase.end）
 1. **合并最新代码** — 主目录与 worktree 均**不在业务工作区 stash/pull**；远端同步由合并段 integration transaction 在隔离 integration worktree 内完成（见「worktree 合并流程」）；**正常路径禁止 `git stash` / `stash pop`**
-2. **最终验证** — ledger 复用优先；**提交前最终门禁只调 `can-reuse`**（删除与 coverage 冲突的二次全量门禁）：`harness_ledger.py can-reuse --verification unitTestFull --scope module --project . --profile-input unitTestFull --command <resolved commands.unitTestFull.command>`。`--command` **按 profile key resolve**：读 `build-profile.json` 的 `commands.unitTestFull.command`（v2），或 `harness_profile.py resolve --project . --key unitTestFull --json` 取 resolved command，**不复制示例模块名**（文档示例只展示 key）。`--profile-input unitTestFull` 从 `verificationInputs.unitTestFull`（v2 由 `commands.unitTestFull.inputs` 派生）展开依赖闭包，**禁止用仅含 staged 文件的 `--files` 快捷方式**冒充全量闭包。`reuse=true` → 不再执行二次全量测试；仅 `reuse=false` 时执行**同一 resolved verification**（profile `unitTestFull` 命令），成功后用同一文件集、command、`scope=module` 经 **`harness_ledger.py record`** 写回 ledger `unitTestFull` 项。增量 `unitTest` 永远不能冒充 `unitTestFull` 门禁。
+2. **最终验证** — ledger 复用优先；提交前只调用 `can-reuse --project . --profile-input unitTestFull --command <profile 规范命令>`。不得传入另一套 `--files`，不得把 runner 包装说明写进 `command`。`reuse=true` 时禁止重跑；只有真实输入、依赖、工具链或环境身份变化时才执行一次同一 profile 验证，并只登记一条结果。不要读取 ledger/archive 实现源码或临时编写散列脚本排查参数。
    - 无远端 CI 且 gate-policy 未强制 remote provider 时，验证通过/复用后运行 `harness_archive.py certify-local --change-dir ... --project . --json`，从同一 ledger 生成 `local-reproducible` 产品候选收据；该命令不执行测试。
    - gate-policy 要求 `remote-attested` 时不得降级成本地收据，等待远端 attestation。
 3. **.gitignore + 精确暂存** ⚠️ — 检查 `.harness/` 在 `.gitignore`；**禁止 `git add -A`**。若存在 `evidence/test-tracking.json`，先执行 `python <skills-root>/scripts/harness_test_guard.py stage --project . --change-dir ".harness/changes/<change-name>" --json`；失败即硬停止。无 manifest 时不使用 `-f`。manifest 之外的文件按精确业务路径正常暂存，**禁止全局 force-add**。
 4. **提交方式** — 主目录：blocking user confirmation 三选项（commit+push / 仅本地 / 取消）；**worktree：固定仅本地 commit**
 5. **commit-message.txt** ⚠️ — 展示 staged、diff stat、完整中文 message；用户确认
-6. **commit / push** — `git commit -F`；主目录按选项 push（push 前 fetch 检查远端）；**worktree：只 commit，记录 local hash**
-7. **收尾** — **`harness_gate.py close --phase submit --status ...`**；主目录：可选 worktree 清理 + 提示 `/harness-archive`；**worktree：接续下方合并流程**
+6. **commit / push** — `git commit -F`；主目录按选项 push（push 前 fetch 检查远端）；无 upstream 时允许仅本地 commit。commit 后立即重新运行 `harness_archive.py certify-local`：若验证输入未变化，脚本把候选从提交前身份安全重绑定到最终 commit，不得重跑测试或手工复制账本；**worktree：只 commit，记录 local hash**
+7. **收尾** — `harness_gate.py close --phase submit --status ... --to-phase <实际计划后继>`；通常后继为 Archive，但不得显示“等待 merge”或固定写死。主目录停止并提示真实下一阶段；worktree 才接续下方同一 Submit 内的合并流程。
 
 详细步骤见 `checklist.md`。
 

package/harness/bundles/java/cursor/harness-submit/checklist.md

@@ -30,7 +30,7 @@ description: harness-submit 的8 步工作流详细步骤和执行日志记录
 
 **读取 verification-ledger + post-test 变更分类**：
 
-1. 读取 `.harness/changes/<change-name>/evidence/verification-ledger.json`，记录 `diffHash` / `currentHead` / `unitTest` / `apiTest` 状态
+1. 通过 state layout resolver 读取权威 `evidence/verification-ledger.json`，记录 `diffHash` / `currentHead` / `unitTest` / `apiTest` 状态；split-v1 不得回退复制到 contract 目录
 2. 执行 `harness_ledger.py diff-hash --repo . --base <baseCommit> --change-dir ".harness/changes/<change-name>" --json` 计算当前 diffHash；manifest 校验失败即停止，不得绕过后与 ledger 比对
 3. 若 test 之后有代码变更（当前 diffHash ≠ test 完成时的 diffHash），按 7 类对 post-test diff 分类（见 `../protocols/ledger-protocol.md` 第六章），写入 ledger 的 `postTestClassification`
 4. 行为性变更（BEHAVIORAL_SERVICE_CHANGE / API_CONTRACT_CHANGE / SQL_OR_MAPPER_CHANGE / SECURITY_OR_PERMISSION_CHANGE）→ **停止 submit**，提示先重跑 `/harness-test` 相关场景

package/harness/bundles/java/cursor/harness-sync/SKILL.md

@@ -4,7 +4,7 @@ description: Use when the user asks to synchronize, refresh, or validate Harness
   metadata, adapters, remote knowledge ownership, instruction entrypoints,
   config origins, or CodeGraph status.
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-sync
 
 ## Purpose

package/harness/bundles/java/cursor/harness-test/SKILL.md

@@ -3,7 +3,7 @@ name: harness-test
 description: 测试执行：读取场景表，执行单元测试+API接口测试+数据兼容验证，输出测试报告。仅当用户显式调用 /harness-test
   时使用；不得在 run 结束后自动接续执行。
 ---
-<!-- generated by harness_deploy.py; core=44594ca0f316c6fa; overlay=java; agent=cursor; do not edit -->
+<!-- generated by harness_deploy.py; core=ea74ea84e6cc3617; overlay=java; agent=cursor; do not edit -->
 # harness-test — 测试执行
 
 ## Purpose
@@ -14,7 +14,7 @@ description: 测试执行：读取场景表，执行单元测试+API接口测试
 
 仅当用户显式调用 `/harness-test` 时执行（已设 `disable-model-invocation`）。run 阶段结束后**不自动**进入本阶段；用户口头提到"跑测试"而未调用本 skill 时，先确认是否走 Harness 测试阶段。
 
-**单阶段原则**：test 关门后必须停止并交还用户，仅按风险层级提示下一步（`/harness-review` 或 `/harness-submit`）；禁止自动接续执行。
+**单阶段原则**：test 关门后必须停止并交还用户，仅提示 `plannedPhases` 中的真实下一阶段；禁止自动接续执行。
 
 使用场景：
 - 完成 `/harness-run` 编码后，验证单元测试 + 接口测试 + 数据兼容
@@ -46,7 +46,7 @@ description: 测试执行：读取场景表，执行单元测试+API接口测试
 
 ## Workflow
 
-测试跟踪由 `harness_gate.py begin/close` 统一协调 test guard；不得额外手工执行 guard close。任一失败都必须使用 gate 返回的结构化状态，不得以自然语言覆盖失败状态。
+测试跟踪由 `harness_gate.py begin/close` 统一协调 test guard；不得额外手工执行 guard close。任一失败都必须使用 gate 返回的结构化状态，不得以自然语言覆盖失败状态。所有 change/state 路径必须使用 `harness_change.py resolve` 或 context 返回的 `executionRoot`，不得固定拼接 `.harness/changes/**`；split-v1 默认位于 `.harness/state/changes/**`。
 
 兼容实现中的底层命令名是 `harness_test_guard.py begin` 与 `harness_test_guard.py close`，两者只允许由 gate 内部调用；写在这里用于能力审计，不构成模型执行步骤。
 
@@ -87,7 +87,7 @@ Runner 强制同项目单实例、低调度优先级、逐命令超时、正常
 
 先 `harness_context.py prepare --phase test --executor <tool> [--change <id>] --json`，再 `harness_context.py begin --phase test --change <id> --executor <tool> --json` 校验最新 run→test receipt 的 artifact/hash/HEAD；然后 **`harness_gate.py begin --phase test --change <id>`**（禁止手工 phase.start / 手写 ledger）。执行各项强制环境检查 + **命令执行模式 preflight (0.1)**；只有首选执行器不可用时，才执行 fallback 执行器探测。
 
-验证写入**仅**允许 `harness_ledger.py record` / `can-reuse`；禁止 Write/Edit `verification-ledger.json`。测试跟踪：gate begin → 执行（可选 `harness_test_guard.py mark stale-test-repair`）→ 单次 `harness_gate.py close --phase test --status ... --to-phase review --executor <tool> --json`。fixback 时由 `harness_fixback.py` 合批记录 RED/GREEN 和 affected verification，再把同一 close 命令的 `--to-phase` 改为 `run`，由 context 失效受影响 target。
+验证写入**仅**允许 `harness_ledger.py record` / `can-reuse`；禁止 Write/Edit `verification-ledger.json`。测试跟踪：gate begin → 执行（可选 `harness_test_guard.py mark stale-test-repair`）→ 单次 `harness_gate.py close`。`--to-phase` 取实际阶段计划的后继；Fixback 返回 run，普通流程可直接进入 Review、Submit 或 Archive。Fixback 只失效与改动文件相交的验证目标。
 
 - **Read `checklist.md`** — 各项检查详情 + 0.1 preflight + Playwright 探测 + 避坑规则指引
 - **失败处理**：任一项检查失败 → 终止流程并报告原因，用户确认修复后才能继续
@@ -109,7 +109,7 @@ Runner 强制同项目单实例、低调度优先级、逐命令超时、正常
 
 ### Phase 1-2：测试执行（默认主会话执行）
 
-**Phase 1 前先读 verification-ledger**：读取 `.harness/changes/<change-name>/evidence/verification-ledger.json`，判断是否可复用 run 阶段的 unitTest（见「关键规则·四」）。
+**Phase 1 前先检查 verification-ledger**：通过 state layout 解析后的路径调用 `harness_ledger.py can-reuse --project . --profile-input <key> --command <profile 解析出的规范命令>`；可复用时不得重跑。不得手工读取实现源码来猜账本参数。
 
 **默认在主会话执行**（不委派 subagent）：
 - 单元测试：可复用则跳过重跑；否则按技术栈执行测试命令
@@ -163,7 +163,7 @@ Runner 强制同项目单实例、低调度优先级、逐命令超时、正常
 
 ### 四、单元测试复用 + 写入 ledger
 
-Phase 1 前先读 `.harness/changes/<change-name>/evidence/verification-ledger.json`，并用 `harness_ledger.py diff-hash --repo . --base <baseCommit> --change-dir ".harness/changes/<change-name>" --json` 重算真实指纹：run 的 unitTest 满足（diffHash 一致 + module/profile 一致 + scope 一致或更严格 + run 后无行为性修改 + run 跑了全量测试）则复用，否则按 **profile key resolve** 执行测试命令（`python <skills-root>/scripts/harness_profile.py resolve --project . --key unitTest|unitTestFull --json`，**不复制示例 `-pl` 命令**）。Phase 1/2 完成后必须写回 ledger：执行增量测试类 → 记 `unitTest`（scope=incremental）；执行 profile 模块全量命令 → 记 `unitTestFull`（scope=module，可供 submit 复用）；HTTP/API 契约测试 → 记 `apiTest`；真实浏览器/真实栈 Playwright → 单独记 `browserTest`，不得覆盖 `apiTest`。详见 `checklist.md`「单元测试复用」、`../protocols/ledger-protocol.md`。
+Phase 1 前用 `harness_ledger.py diff-hash` 和 `can-reuse` 重算真实指纹。验证目标必须使用 profile key 的单一入口：`--project . --profile-input unitTest|unitTestFull --command <规范命令>`；声明 `--profile-input` 后不得同时传入另一套 `--files`。`npx vitest run` 与 `vitest run` 等包装差异由账本规范化，`safe runner` 等说明只能写 `--runner-command` 元数据。可复用则跳过；否则执行同一 profile 命令并只登记一条结果。增量测试记 `unitTest`，模块全量记 `unitTestFull`，API/浏览器分别记录。详见 `checklist.md` 与 ledger protocol。
 
 ### 五、命令与请求超时治理
 

package/harness/bundles/java/cursor/harness-test/checklist.md

@@ -248,7 +248,7 @@ powershell.exe -Command "Copy-Item '<main-dir>/<module>/src/main/resources/appli
 
 ### 单元测试复用（ledger 驱动）
 
-- [ ] Phase 1 前读取 `.harness/changes/<change-name>/evidence/verification-ledger.json`
+- [ ] Phase 1 前通过共享状态目录解析器读取 `evidence/verification-ledger.json`
 - [ ] 判断是否复用 run 的 unitTest：diffHash 一致 + module/profile 一致 + scope 一致或更严格 + run 后无行为性修改 + run 实际跑了全量 mvn test
 - [ ] 复用 → 跳过重跑，标记"✅ 复用 harness-run 单元测试结果"
 - [ ] 不复用 → 重跑 `mvn test -pl <module>`，结果写回 ledger 的 `unitTest` 项

package/harness/bundles/java/cursor/harness-test/reference.md

@@ -776,7 +776,7 @@ powershell.exe -NoProfile -Command "$base = '<baseCommit>'; $patch = '.harness/c
 
 `<baseCommit>` 从 ledger 读取（harness-plan 写入）；缺失时用 `git merge-base HEAD <默认分支>` 兜底。三部分：`git diff $base HEAD`（已提交）+ `git diff`（未提交 tracked）+ 未跟踪新文件（`git ls-files --others --exclude-standard`）；`& { }` 必须带 `&`。
 
-写入 `.harness/changes/<change>/evidence/verification-ledger.json`：
+通过共享状态目录解析器定位 change 后，写入 `evidence/verification-ledger.json`：
 
 ```json
 {

package/harness/bundles/java/cursor/protocols/ledger-protocol.md

@@ -21,10 +21,10 @@ verification-ledger 把每次验证（compile / unit test / api test / package
 ## 二、账本文件位置
 
 ```text
-.harness/changes/<change-name>/evidence/verification-ledger.json
+<resolved-change-state>/evidence/verification-ledger.json
 ```
 
-> 旧路径 `.harness/changes/<change-name>/verification-ledger.json`（根目录）兼容读取，详见 `state-layout-protocol.md`。新版本优先写 `evidence/`。
+> `<resolved-change-state>` 必须由共享状态目录解析器取得：split-v1 通常位于 `.harness/state/changes/<change-name>`，旧布局仍位于 `.harness/changes/<change-name>`。根目录旧文件 `verification-ledger.json` 只兼容读取，详见 `state-layout-protocol.md`；新版本统一写入 `evidence/`。
 
 - 不提交到 git（已在 `.harness/` 屏蔽范围内）
 - 每次验证执行后**立即写回**（不得等所有阶段结束才补）
@@ -32,7 +32,7 @@ verification-ledger 把每次验证（compile / unit test / api test / package
 
 ## 三、账本结构
 
-`.harness/changes/<change>/verification-ledger.json` 必须至少包含：
+解析后的变更状态目录中，`evidence/verification-ledger.json` 必须至少包含：
 
 ```json
 {