hunter-harness 0.2.0 → 0.2.2

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

@@ -1,159 +0,0 @@
----
-name: harness-submit
-description: "最终提交封装：验证→中文 commit→提交/推送；worktree 模式含 --no-ff 合并回主分支。使用场景：提交代码、commit、push、合并分支、merge to main、完成开发"
-argument-hint: "变更名或留空自动检测"
-effort: medium
-allowed-tools: [Bash(powershell.exe:*), Read, Write, Edit, Glob, Grep]
-disallowed-tools:
-  - Bash(git *)
-  - Bash(mvn *)
-  - Bash(ls *)
-  - Bash(find *)
-  - Bash(grep *)
-  - Bash(cat *)
-  - Bash(cp *)
-  - Bash(mv *)
-  - Bash(rm *)
-  - Bash(mkdir *)
-  - Bash(touch *)
-  - Bash(sed *)
-  - Bash(awk *)
-  - Bash(curl *)
----
-<!-- generated by harness_deploy.py; core=3797d93d2cf363a9; overlay=none; agent=claude-code; do not edit -->
-# harness-submit — 最终提交（含 worktree 合并）
-
-## Purpose
-
-合并最新代码→最终验证→生成中文 commit→提交/推送；worktree 模式在本地 commit 后**自动接续** `--no-ff` 合并回主分支、push、清理 worktree，完成开发闭环。
-
-## When to Use
-
-- 代码开发完成，准备提交
-- 用户说「提交代码」「commit」「push」「完成开发」
-- worktree 模式：用户说「合并分支」「merge to main」「合入主分支」「/harness-merge」（别名，从合并阶段重入亦可）
-- review 和 test 已通过或已明确跳过
-
-> **主目录模式**（`worktree.json` requested=false）：commit+push 主分支后直接 `/harness-archive`。**worktree 模式**（requested=true）：worktree 内仅本地 commit，随后本 skill 自动执行合并流程；**push 只在主分支发生一次**。
-
-## 前置条件
-
-- test 已通过、无未暂存修改
-- 读取 `meta/worktree.json`：`requested=true` 且 worktree 已创建 → 在 worktree 目录执行提交段；不存在 → 停止并提示修复，不得静默回主目录
-- review 报告可读作参考，不得阻塞提交
-
-## Inputs
-
-- `$ARGUMENTS`：变更名（可选，Glob `.harness/changes/*/plans/` 自动检测）
-- 相关文件：`plans/*-plan.md`、`evidence/verification-ledger.json`、`meta/worktree.json`
-
-## 统一读取协议
-
-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]]
-
-## 状态目录分层
-
-新产物遵循 `../protocols/state-layout-protocol.md`；读取时先新路径后兼容旧路径。
-
-## Workflow
-
-**模式判定**：读 `meta/worktree.json`。`requested=false` → 步骤 0–7（主目录）；`requested=true` → 步骤 0–6 在 worktree 执行，成功后**不结束**，接续「worktree 合并流程」。用户仅调用 `/harness-merge` 且 worktree 已有本地 commit 时，从合并流程步骤 M0 重入。
-
-### 提交流程（步骤 0–7）
-
-0. **启动准备** — 确定变更名；读 ledger + 计算 diffHash + post-test 7 类分类；append `phase.start`
-1. **合并最新代码** — 主目录：`stash` → `pull --rebase` → `stash pop`；**worktree：N/A**（远端同步在合并段主分支完成）
-2. **最终验证** — ledger 复用优先；**提交前最终门禁**：`harness_ledger.py can-reuse --verification unitTestFull --scope module --project . --profile-input unitTestFull --command <build-profile.json buildCommands.unitTestFull>`（`--profile-input unitTestFull` 从 `build-profile.json` 的 `verificationInputs.unitTestFull` 展开依赖闭包文件集，**禁止用仅含 staged 文件的 `--files` 快捷方式**冒充全量闭包；`<command>` 直接读 `buildCommands.unitTestFull`，不复制示例模块名）。不可复用则执行 `buildCommands.unitTestFull` 模块级全量单元测试，成功后用同一文件集、command、`scope=module` 写回 ledger 的 `unitTestFull` 项。增量 `unitTest` 永远不能冒充 `unitTestFull` 门禁。
-3. **.gitignore + 暂存** ⚠️ — 检查 `.harness/` 在 `.gitignore`；**禁止 `git add -A`**
-4. **提交方式** — 主目录：AskUserQuestion 三选项（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. **收尾引导** — 主目录：可选 worktree 清理 + 提示 `/harness-archive`；**worktree：接续下方合并流程**
-
-详细步骤见 `checklist.md`。
-
-### worktree 合并流程（requested=true，commit 后自动执行）
-
-M0. append `phase.start`（phase=merge，若从 `/harness-merge` 重入则 note 标注重入）
-M1. **切回主目录主分支** — `symbolic-ref origin/HEAD` 读主分支名；必要时 stash；确认 checkout 主分支
-M2. **fetch + pull --rebase** — 记录是否引入他人提交（决定 M4 是否重跑验证）
-M3. **`git merge --no-ff worktree/<change-name>`** — 合并消息可让用户改文案，**方式固定 --no-ff**
-M4. **冲突处理** — 若 `CONFLICT` → **停下**，列出冲突文件，提示用户手动解决后重跑；**禁止 `checkout --theirs/--ours`**；状态 🟡WARN，不得宣称合并成功
-M5. **合并后验证** — 他人提交引入 → 必须重跑构建+测试；否则 ledger 复用 🔁REUSED
-M6. **push 主分支** — fetch 后 `log HEAD..@{u}` 非空则回 M2；否则 push，记录 `mergeFinalHash`
-M7. **清理 worktree** — `worktree remove` + `branch -D`（Windows 兜底见 `reference.md`）；更新 `worktree.json`（`created=false` + removedAt 等）
-M8. **ledger + 收尾** — 写入 `mergeFinalHash`；append `phase.end`；提示 `/harness-archive`
-
-## 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]]
-
-## 关键规则（硬门禁速查）
-
-> 细则见 `checklist.md`、`reference.md` 与各 protocol。
-
-### 一、提交方式固定三选项（主目录）
-
-commit+push / 仅本地 commit / 取消；**不调用 Superpowers 呈现 PR/丢弃选项**。
-
-### 二、中文 commit 永远用文件
-
-`.harness/changes/<change>/runtime/commit-message.txt` + `git commit -F`；禁止 amend 英文、禁止 `--no-verify`、禁止 AI footer。
-
-### 三、.gitignore / 远程新提交 / ledger 复用
-
-见 `checklist.md` 与 `../protocols/ledger-protocol.md`、`../protocols/submit-protocol.md`。
-
-### 四、worktree 合并硬规则
-
-- **push 只在主分支**；worktree 分支不 push
-- **`git merge --no-ff` 固定**；禁止 fast-forward
-- **冲突不自动解** → 停下 → 用户手动解 → 确认后继续
-- **`mergeFinalHash`** = 主分支 push 后 HEAD；archive 优先读此字段
-
-### 五、Shell 安全 / 敏感信息 / 证据化
-
-git 经 PowerShell；commit/报告不得含明文密钥。遵循 `../protocols/sensitive-info-protocol.md`、`../protocols/evidence-based-reporting-protocol.md`。
-
-## Submit 决策所有权
-
-确定性 Git 流程；验证基线由 ledger、`git diff --cached`、远端检查与必要构建/测试决定；Superpowers 仅人工参考。
-
-## Output Format
-
-主目录：commit hash、分支、变更统计、archive 建议。worktree：merge commit、push 范围、`mergeFinalHash`、worktree 清理状态、archive 建议。详见 `reference.md`。
-
-## 渐进披露
-
-- **Read `checklist.md`** — 提交流程 + worktree 合并详细步骤
-- **Read `reference.md`** — commit 模板、Windows worktree 清理兜底、输出示例
-
-## 交互白名单
-
-本 skill **仅允许**以下 AskUserQuestion；其余默认值 + `decision` 事件：
-
-1. **提交方式 + commit message**（主目录一次确认）；worktree 固定仅本地 commit，仅确认 message
-2. **远程有新提交**（push 前）：重新验证 / 停止 push
-
-## 执行日志
-
-`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/general/claude-code/harness-submit/checklist.md

@@ -1,407 +0,0 @@
----
-description: harness-submit 的8 步工作流详细步骤和执行日志记录格式。仅在执行提交流程时读取。
----
-
-# harness-submit 检查清单
-
-## P0 提交稳定性门禁（先读）
-
-执行任何 commit 前必须遵循 `reference.md` 与 `../protocols/submit-protocol.md`：
-
-- 提交方式只用固定三选项：commit+push / 仅本地 commit / 取消。
-- commit message 必须写入 `.harness/changes/<change>/runtime/commit-message.txt`。
-- 使用 `git commit -F`，禁止先英文 commit 再 amend。
-- commit message 禁止 `Co-Authored-By`、`Generated by`、`AI generated`。
-- AskUserQuestion 参数错误时不得自行绕过，必须改用固定模板重问。
-- staged diff 是唯一提交依据。
-
-
-## 步骤 0：启动准备
-
-确定变更名：用 Glob 搜索 `.harness/changes/*/plans/*-plan.md`（**排除 `.harness/archive/*/`**），读取 frontmatter 提取 `change-name`。默认最多一个未归档变更；如有多个，优先取最近修改的，或询问用户。
-
-**读取 worktree.json 判定模式**：读取 `.harness/changes/<change-name>/meta/worktree.json`。`requested=true` → **worktree 模式**：submit 只本地 commit、不 push，commit 成功后**自动接续** checklist「worktree 合并流程」步骤 M0–M8（`/harness-merge` 为别名，可从 M0 重入）。`requested=false` → 主目录模式：正常 commit+push 主分支。
-
-**读取 verification-ledger + post-test 变更分类**：
-
-1. 读取 `.harness/changes/<change-name>/evidence/verification-ledger.json`，记录 `diffHash` / `currentHead` / `unitTest` / `apiTest` 状态
-2. 计算当前 diff 的 diffHash，与 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` 相关场景
-5. 非行为性变更（NON_BEHAVIORAL_CLEANUP / COMMENT_ONLY / TEST_ONLY）→ 可继续 submit，但后续验证按复用规则处理
-
-**append `phase.start` 事件**（`harness_events.py append`；`note` 含 ledger diffHash、post-test 分类、验证策略）：
-
-## 步骤 1：合并最新代码
-
-> **分支名自动读取**：不硬编码 `master` 或 `main`，使用 `git rev-parse --abbrev-ref @{u}` 自动读取 upstream 分支。
-
-```powershell
-# 0. 自动读取 upstream
-powershell.exe -Command "git -C '<项目路径>' rev-parse --abbrev-ref @{u}"
-
-# 1. 暂存当前变更
-powershell.exe -Command "git -C '<项目路径>' stash"
-
-# 2. 拉取并合并远程
-powershell.exe -Command "git -C '<项目路径>' pull --rebase"
-
-# 3. 恢复暂存的变更
-powershell.exe -Command "git -C '<项目路径>' stash pop"
-```
-
-**Shell 安全规则（强制）**：
-- 任何 git 命令被 hook 拒绝（`Denied` / `PreToolUse:Bash hook error`）→ 停止流程，不得宣称"拉取成功"
-- 拉取成功的判断证据：git 输出包含 `Already up to date.` 或 `Fast-forward`、`Updating <hash>..<hash>`，且 exit code 为 0
-
-如果 stash pop 冲突或 merge 冲突，参考 `reference.md` 的常见问题处理。
-
-## 步骤 2：最终验证（ledger 复用优先）
-
-**先判断是否可复用 test 阶段验证**。读取 ledger 后，若**全部满足**：
-
-- 当前 diffHash 与 ledger 一致（或 post-test 仅为非行为性清理）
-- `unitTest.status=OK` 且 `apiTest.status=OK`
-- postTestClassification ∈ {NON_BEHAVIORAL_CLEANUP, COMMENT_ONLY, TEST_ONLY, 无}
-- 远端无新提交（步骤 1 pull 未引入他人提交）
-- 用户未要求 `submit-full-verify`
-
-→ **跳过重跑** 项目构建/测试命令，复用 ledger 结果，在执行日志标记 `🔁REUSED`，并在提交摘要写明"验证复用 test 阶段结果（diffHash=<...>）"。
-
-**重跑触发条件**（任一满足则必须重跑）：
-
-- 远端有新提交并完成 pull/rebase
-- staged diff 与 ledger diffHash 不一致且属行为性变更
-- post-test 修改属于行为性变更（已在步骤 0 拦截，此处兜底）
-- test 报告缺失或失败
-- 用户要求 `submit-full-verify`
-
-重跑时只使用 harness-submit 自有确定性验证，不调用 Superpowers 合并/收尾流程：
-
-```powershell
-powershell.exe -NoProfile -Command "<项目构建命令>"
-powershell.exe -NoProfile -Command "<项目测试命令>"
-```
-
-> **接口测试依赖编译产物时的重跑顺序**（通用）：若项目的接口测试执行器（如 in-process HTTP server runner）import 编译产物（build output）而非源码，重跑接口测试前**必须先跑构建命令**重新编译，否则接口测试测的是 post-test 改动前的旧产物，会漏检行为性变更。单元测试若通过别名/直指源码则不受影响，但接口测试执行器通常依赖独立编译产物——务必先编译再跑接口测试。
-
-编译或测试失败 → 停止提交，提示用户修复。
-
-**重跑后必须把结果写回 ledger** 的 `compile`/`unitTest` 项，并更新 `diffHash`/`currentHead`。
-
-**提交前最终门禁**（步骤 2 末尾，commit 前强制，`unitTestFull` 模块级全量）：
-
-```powershell
-python <skills-root>/scripts/harness_ledger.py can-reuse `
-  --change-dir ".harness/changes/<change-name>" `
-  --verification unitTestFull --scope module `
-  --project . --profile-input unitTestFull `
-  --command "<build-profile.json buildCommands.unitTestFull>" --json
-```
-
-- `--profile-input unitTestFull` 从 `build-profile.json` 的 `verificationInputs.unitTestFull` 展开**依赖闭包**文件集，**禁止用仅含 staged 业务文件的 `--files` 快捷方式**冒充全量闭包。
-- `--command` 必须直接读取当前项目 `build-profile.json` 的 `buildCommands.unitTestFull`，禁止原样复制示例模块名。
-- 增量 `unitTest`（scope=测试类）永远不能冒充 `unitTestFull` 门禁；ledger 只有 `unitTest` 时返回 `insufficient-evidence`。
-- `reuse=false` → 执行 `buildCommands.unitTestFull`（模块级全量单元测试），成功后用**同一文件集、command、`scope=module`** 写回 ledger 的 `unitTestFull` 项，再继续步骤 3。
-- profile 缺 `verificationInputs.unitTestFull` / glob 无匹配 / 结果为空 → 返回 `insufficient-evidence`（exit 0），仍须执行全量测试但**不允许缓存复用**，直到 profile 正确配置。
-
-**编译/测试成功必须有明确证据**：
-- 构建命令输出必须包含构建成功证据（如 `BUILD SUCCESS` / `Finished` / exit code 0）
-- 测试命令输出必须包含测试通过证据（如 `Tests run: N, Failures: 0` / `passed` / exit code 0）
-- 命令被 hook 拒绝或 exit code 非 0 → 标记为 ❌ 失败，停止提交流程
-
-**review 报告**（参考性）：如果 `.harness/changes/<change-name>/reports/review/review-report-*.md` 存在（旧路径 `reviews/` 兼容），可读取并展示摘要（如“review 报告：RED 高风险建议 N 个，YELLOW 中低风险建议 M 个，仅供参考”），但不得因 review 结果阻塞提交。
-
-**review fixback**（参考性）：如果 `.harness/changes/<change-name>/reports/review/fixback-*.md` 存在，展示最新 fixback 摘要并提示“可回到 `/harness-run --fixback` 处理”；除非 `review.strict-review-gate=true` 且存在 RED，否则不得阻塞提交。
-
-## 步骤 3：.gitignore 检查 + 暂存业务文件 ⚠️ 强制阻断
-
-提交前**强制检查 `.gitignore`** 是否包含 `.harness/`：
-
-```powershell
-powershell.exe -Command "Select-String -Path '<项目路径>\.gitignore' -Pattern '\.harness'"
-```
-
-如果未包含：
-- **必须提醒用户**：`⚠️ .gitignore 未包含 .harness/，会导致 .harness/ 下文件被提交（含日志、报告、可能含敏感信息）`
-- **默认不提交 .harness/ 下文件**：使用 AskUserQuestion 询问用户是否：
-  1. 添加 .harness/ 到 .gitignore（推荐）
-  2. 仅 stage 业务代码文件，不提交 .harness/
-  3. 取消提交
-
-**git status 中如出现 .harness/changes/**：
-```powershell
-powershell.exe -Command "git -C '<项目路径>' status --porcelain | Select-String '\.harness'"
-```
-- 如果有匹配，必须只 stage 业务代码文件，**禁止 `git add -A`**
-- 推荐 stage 方式：明确列出业务代码文件路径 `git add <file1> <file2> ...`
-
-## 步骤 4：提交方式选择（固定三选项）
-
-**worktree 模式（requested=true）**：固定为「仅本地 commit」，不展示「commit+push」选项；commit 完成后继续下方「worktree 合并流程」，跳过下方三选项询问。
-
-`harness-submit` 不调用 Superpowers 呈现合并选项。只允许使用固定 AskUserQuestion 模板：
-
-```text
-本次变更已完成验证，请选择提交方式：
-
-1. commit + push 到当前 upstream
-2. 仅本地 commit，不 push
-3. 取消提交
-```
-
-禁止在此步骤引入“创建 PR”“丢弃所有变更”“直接合并到主分支”等旧选项，避免 AskUserQuestion 参数错误和流程歧义。
-
-## 步骤 5：展示提交摘要 + 确认 ⚠️ 强制阻断
-
-展示完整的 commit message 和变更列表，等待用户确认。**不可跳过此步。**
-
-**commit message 生成规则**：
-- subject 只根据 `git diff --cached` 当前实际暂存的变更，或本次变更名生成
-- **不得混入历史任务上下文**（如之前的 plan 描述、与本次 diff 无关的短语）
-- 示例：本次 indicator 权限修复，正确 subject 应类似 `fix(indicator): 修复指标库列表组织权限过滤`，不得出现与本次 diff 无关的内容
-
-**展示四项信息**（缺一不可）：
-
-```powershell
-# 1. 实际 staged 文件列表
-powershell.exe -Command "git -C '<项目路径>' diff --cached --name-only"
-
-# 2. diff stat
-powershell.exe -Command "git -C '<项目路径>' diff --cached --stat"
-```
-
-格式：
-
-```markdown
-## 准备提交
-
-### 1. 实际 Staged 文件列表
-（基于 git diff --cached --name-only 的实际输出）
-- src/.../业务代码文件
-- test/.../测试代码文件
-
-### 2. Diff Stat
- src/.../业务代码文件 | +12 -3
- test/.../测试代码文件 | +45 -0
- 2 files changed, 57 insertions(+), 3 deletions(-)
-
-### 3. Commit Message
-<type>(<scope>): <中文描述>
-
-- 变更点1
-- 变更点2
-
-### 4. 是否会 push
-（根据本步骤提交方式选择：会推送到 origin/<branch> / 仅本地提交，不推送）
-
-### 确认？
-回复「是」→ 执行提交 | 回复「改」→ 修改 message | 回复「取消」→ 放弃
-```
-
-> Git 提交信息**不包含** `Co-Authored-By` 行（遵循项目 git-commit.md 规范）。
-
-
-### 5.1 生成 commit-message.txt（强制）
-
-在用户确认前，必须把完整中文 commit message 写入：
-
-```text
-.harness/changes/<change-name>/runtime/commit-message.txt
-```
-
-用 Write 工具或 PowerShell 创建文件。message 不得包含 `Co-Authored-By`、`Generated by`、`AI generated`。
-
-用户确认时展示该文件完整内容；确认后步骤 6 必须使用：
-
-```powershell
-powershell.exe -NoProfile -Command "git -C '<项目路径>' commit -F '.harness/changes/<change-name>/runtime/commit-message.txt'"
-```
-
-不得使用 `git commit -m` 提交长中文 message，不得先提交英文再 amend。
-
-## 步骤 6：执行 commit 和可选 push
-
-**worktree 模式（requested=true）**：只执行下方 `git commit -F`，**不执行 push**；记录 local commit hash 后**继续 worktree 合并流程 M0**，不结束 submit。
-
-用户确认后，根据步骤 4 的提交方式选择执行：
-
-```powershell
-powershell.exe -NoProfile -Command "git -C '<项目路径>' commit -F '.harness/changes/<change-name>/runtime/commit-message.txt'"
-```
-
-**记录 pre-pull local commit hash**：
-```powershell
-powershell.exe -Command "git -C '<项目路径>' rev-parse HEAD"
-```
-保存为 `<pre-pull-hash>` 用于后续比对。
-
-**push 前的远程新提交检查（强制）**：
-
-```powershell
-# 拉取远程最新引用
-powershell.exe -Command "git -C '<项目路径>' fetch"
-
-# 检查远程是否有新提交（自上次 fetch 以来）
-powershell.exe -Command "git -C '<项目路径>' log HEAD..@{u} --oneline"
-```
-
-**如果远程有新提交**（输出非空）：
-- **不得直接 pull 后 push**
-- 必须 pull/rebase 后**重新构建/测试**（ledger 复用条件被破坏，须重跑并写回 ledger）
-- 验证通过后再 push
-- 使用 AskUserQuestion 询问用户：
-  ```
-  远程有新提交（N 个），需要 pull/rebase 后重新验证：
-  1. 重新验证（pull/rebase + 构建 + 测试）
-  2. 停止 push（保留本地提交，等待用户后续处理）
-  ```
-- 如果用户选 2，必须停止 push，不得强行推送
-
-**如果远程无新提交**（输出为空），可以直接 push：
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' push"
-```
-
-**push 成功必须有证据**：
-- git push 输出包含 `To <remote>` 和实际推送范围（如 `<old-hash>..<new-hash>`）
-- exit code 为 0
-- 否则标记为 ❌ 推送失败 / 状态未知
-
-**记录 final pushed hash**：
-```powershell
-powershell.exe -Command "git -C '<项目路径>' rev-parse HEAD"
-```
-保存为 `<final-pushed-hash>`。
-
-**commit hash 双标注**：
-- 如果 `<pre-pull-hash>` ≠ `<final-pushed-hash>`，在执行日志中分别记录：
-  ```
-  - **pre-pull local commit hash**: <pre-pull-hash>
-  - **final pushed hash**: <final-pushed-hash>
-  ```
-- 后续 archive 阶段读取时以 `<final-pushed-hash>` 为准
-
-不用 `--no-verify`、`--no-gpg-sign` 等跳过 hook 的参数。
-
-## 步骤 7：收尾引导
-
-**worktree 模式（requested=true）**：不清理 worktree，**直接继续下方「worktree 合并流程」**。
-
-**主目录模式 Worktree 清理**：如果当前在 worktree 中，询问用户是否删除：
-- 是 → 先确认分支已推送 origin，再 `git worktree remove` + `git branch -D`
-- 否 → 保留
-
-> ⚠️ `git worktree remove` 在 Windows 下常因残留 `node_modules` 等深嵌套 gitignored 文件失败（"Directory not empty"）。完整兜底方法（robocopy /MIR 清空 + .NET 删空目录、ExitWorktree 限制、PreToolUse hook 对 `/MIR` 的误判规避）见 `reference.md`「Worktree 清理兜底（Windows）」。
-
-**产出归档引导**：展示 `.harness/changes/<change-name>/` 下的所有产出文件，询问用户：
-- 保留 → 后续可运行 harness-archive 归档
-- 归档 → 运行 harness-archive
-- 清理 → 删除 `.harness/changes/<change-name>/` 目录
-
-**append `phase.end` 事件**（submit 段；`note` 含结束时间、耗时、结果、final pushed hash、验证策略、摘要）：
-
----
-
-## worktree 合并流程（步骤 M0–M8）
-
-> worktree 模式 commit 成功后自动执行；用户仅说「合并分支」/`/harness-merge` 且已有本地 commit 时从 M0 重入。合并方式固定 `--no-ff`；冲突 → 停下 → 用户手动解 → 确认后继续；**禁止 `checkout --theirs/--ours`**。
-
-### P0 合并稳定性门禁
-
-- 主分支名不硬编码，用 `git symbolic-ref --short refs/remotes/origin/HEAD` 读取
-- push 只在主分支；worktree 分支不 push
-- 所有 git 命令通过 `powershell.exe -Command "..."` 执行
-
-### 步骤 M0：启动合并段
-
-append `phase.start`（`--phase merge`；`note` 含 worktree 分支、主分支、ledger diffHash、验证策略；重入时 note 标注「重入 merge」）。
-
-### 步骤 M1：切回主目录主分支
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' symbolic-ref --short refs/remotes/origin/HEAD"
-powershell.exe -Command "git -C '<项目路径>' stash"   # 主目录有未提交变更时
-powershell.exe -Command "git -C '<项目路径>' rev-parse --abbrev-ref HEAD"
-```
-
-不在主分支则 `git checkout <主分支>`。
-
-### 步骤 M2：fetch + 同步主分支
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' fetch origin"
-powershell.exe -Command "git -C '<项目路径>' pull --rebase"
-```
-
-pull 输出非 `Already up to date.` → 引入他人提交 → M4 必须重跑验证。
-
-### 步骤 M3：合并 worktree 分支
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' merge --no-ff worktree/<change-name>"
-```
-
-合并消息默认 `Merge branch 'worktree/<change-name>'`，用户可改文案，**方式固定 --no-ff**。
-
-### 步骤 M4：冲突处理
-
-若输出 `CONFLICT`：
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' diff --name-only --diff-filter=U"
-```
-
-- 列出冲突文件，**停下**，提示用户手动解决（编辑 → `git add` → `git commit`）
-- 状态 `🟡WARN(merge 冲突，待手动解决：<文件列表>)`
-- 用户确认解决后重跑 submit（从 M0 重入）
-- **禁止自动 `git checkout --theirs/--ours`**
-
-### 步骤 M5：合并后验证（ledger 复用优先）
-
-- 步骤 M2 引入他人提交 → **必须重跑** 构建+测试
-- 否则 diffHash 一致且 post-test 非行为性 → 🔁REUSED
-
-重跑后写回 ledger 的 `compile`/`unitTest`，更新 `diffHash`/`currentHead`。
-
-### 步骤 M6：push 主分支
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' fetch"
-powershell.exe -Command "git -C '<项目路径>' log HEAD..@{u} --oneline"
-```
-
-远端有新提交 → 回 M2；无则：
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' push"
-```
-
-记录 `mergeFinalHash`：`git rev-parse HEAD`。
-
-### 步骤 M7：清理 worktree
-
-```powershell
-powershell.exe -Command "git -C '<项目路径>' worktree remove '<worktree-path>' --force"
-powershell.exe -Command "git -C '<项目路径>' branch -D worktree/<change-name>"
-```
-
-> Windows 兜底见 `reference.md`「Worktree 清理兜底（Windows）」。
-
-更新 `meta/worktree.json`：`created=false` + `removedAt`/`removedBy`/`removalNote`。
-
-### 步骤 M8：更新 ledger + 收尾
-
-ledger 顶层写入 `"mergeFinalHash": "<hash>"`；append `phase.end`（merge 段）。
-
-```markdown
-## 合并完成 — <change-name>
-
-- Merge commit: `<merge-commit-hash>`
-- 主分支 push: ✅（<old>..<new> → origin/<主分支>）
-- mergeFinalHash: `<merge-final-hash>`
-- 验证策略: 🔁REUSED / 🔄已重跑
-- worktree: 已清理
-- 下一步: `/harness-archive`
-```