@hunter-harness/workflow-harness 0.2.85 → 0.3.0

package/harness/bundles/general/codebuddy/harness-plan/checklist.md

@@ -77,22 +77,11 @@ description: harness-plan 的阶段检查清单和覆盖检查列表。仅在执
 
 确认后立即追加 decision 事件，并写入 `meta/worktree.json`。设计文档按路径分流：
 
-- **v2**：审批内容写进 `meta/plan-evidence-input.json` 的 `approval.content`（含 `approver_id`），
+- 审批内容写进 `meta/plan-evidence-input.json` 的 `approval.content`（含 `approver_id`），
   `plans/<change>-design.md` 由 finalize 从审批内容派生——**不要**手写它，手写的会被覆盖
-- **legacy**：写 `spec/<change>-design.md`（含下方 frontmatter）
 
 - [ ] 确认事件早于 approved 设计文档；未获确认时不得先落盘 `status: approved`
 
-legacy 设计文档必须包含 frontmatter：
-```yaml
----
-change-name: <change-name>
-created: YYYY-MM-DD HH:mm
-status: approved
-source: harness-plan
----
-```
-
 展示可审核包后，使用 `blocking user confirmation` 询问用户：
 - **确认**：设计方向正确，继续任务拆分
 - **修改**：某个部分需要调整，修改后再审核
@@ -184,8 +173,8 @@ source: harness-plan
 □ 已用 decision / issue 事件 note 记录五类输出：风险识别 / 复用机会 / 替代方案 / 推荐方案 / 关键决策
 □ 已叠加项目架构约束（分层规范、数据模型、接口规范）
 □ 需求澄清结论已追加到 events.ndjson，阶段结束后执行日志由渲染器生成
-□ 用户问题未超预算：简单修复 0-1 问，普通需求 1-3 问，高风险需求 5-7 问；无必须裁决事项时 0 问
-□ 提问遵循"一次一问、等答再继续"；能由 context pack / 阶段3代码探索 / CodeGraph 自答的问题已自答，未打扰用户
+□ 提问方式与问题预算符合 protocols.md 的 decision-grilling-protocol（预算数值以那份为准，此处不复述）
+□ 能由 context pack / 阶段3代码探索 / CodeGraph 自答的问题已自答，未打扰用户
 □ 每个需要用户决策的问题，AI 先给出了推荐答案、理由和取舍，用户仅确认或修正
 □ 高风险/业务语义决策（范围、权限、安全、支付、迁移、删除、API契约、用户可见行为）已显式等待用户确认
 ```
@@ -199,97 +188,34 @@ source: harness-plan
 ```
 □ 已读取 protocols.md，并按 implementation-planning-protocol 执行
 □ 输入为阶段4已审核设计文档
-□ 已生成基础任务列表，并用 artifact 事件 note 记录任务拆分摘要
+□ 已用 artifact 事件 note 记录任务拆分摘要
 □ 已叠加项目层序依赖（数据/契约→业务层→接口层）
 □ 已生成 4 维度场景表（单元/接口/数据兼容/集成）
 □ 每个自动化场景均标注执行层级、预计时长、资源预算、超时、可复用证据；快速反馈不默认扫描全仓库
 □ 已确定变更名（kebab-case）
-□ 产物已写入 .harness/changes/<change-name>/plans/：
-  - <change-name>-plan.md（简洁任务表）
-  - <change-name>-implementation-detail.md（自适应详细执行参考）
-  - <change-name>-test-scenarios.md（测试场景表）
 □ implementation-detail.md 按复杂度自适应：简单任务不过度展开，复杂任务写清接口/数据/顺序/风险/测试策略
 □ plan / implementation-detail / test-scenarios 三件套互相引用一致，无 TBD/TODO/空泛占位
 ```
 
+> 产物是否齐全、任务表与场景表是否非空、优先级与 ownerPhase 取值是否合法，由 finalizer
+> fail-closed 判定（`PLAN_ARTIFACT_MISSING` / `PLAN_TASKS_EMPTY` / `PLAN_SCENARIOS_EMPTY` /
+> `PLAN_SCENARIO_PRIORITY_INVALID`），此处不重复勾选。上面留下的都是机器判不了的：
+> 层序依赖是否合理、维度是否真被覆盖、详略是否配得上复杂度、三件套是否自洽。
+
 > 不再检查 Superpowers writing-plans 是否安装或调用；阶段 6 是 harness 原生协议，不存在 `docs/superpowers/` 同步分支。
 
 ## 阶段 8：结束前产物完整性检查 ⚠️ 强制
 
-> **缺任一文件 → ❌FAIL，不得宣称 plan 完成。**
-
-> **先认路径再对表**：v2 与 legacy 的完整性口径不同，混用会得出错误结论。
-
-### v2 路径（新 change 默认）
-
-- [ ] 只手写 `meta/plan-evidence-input.json`；`plans/*.md` 由 finalize 派生，**不得**手写后再被覆盖
-- [ ] `evidence-pack` 返回 `code:"PLAN_EVIDENCE_PACK_BUILT"`；结构报错按 `field_path`/`problems[]` 修正后重跑
-- [ ] `finalize` exit 0 且 `code:"PLAN_FINALIZED"`
-- [ ] 八 target 齐全：`plans/` ×4（design / implementation-detail / plan / test-scenarios）+ `meta/` ×4（gate-policy / implementation-checkpoints / scenario-manifest / worktree）
-- [ ] `meta/publication-journals/<op>.json` 的 `state === "committed"`
-- [ ] `meta/plan-events.ndjson` 含 `artifact_published` 与 `phase_ended` 两类终态事件
-- [ ] 以上任一缺失都不得手工补写；回到对应阶段改自然输入后重跑
-
-| 文件（v2） | 必须存在 | 检查结果 |
-|------|:---:|:---:|
-| `.harness/changes/<change>/meta/plan-evidence-input.json` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-design.md` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-plan.md` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-implementation-detail.md` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-test-scenarios.md` | ✅ | □ |
-| `.harness/changes/<change>/meta/gate-policy.json` | ✅ | □ |
-| `.harness/changes/<change>/meta/worktree.json` | ✅ | □ |
-| `.harness/changes/<change>/meta/implementation-checkpoints.json` | ✅ | □ |
-| `.harness/changes/<change>/meta/scenario-manifest.json`（非空且计数一致） | ✅ | □ |
-| `.harness/changes/<change>/meta/publication-journals/<op>.json`（committed） | ✅ | □ |
-| `.harness/changes/<change>/meta/plan-events.ndjson` | ✅ | □ |
-| `.harness/changes/<change>/events.ndjson` | ✅ | □ |
-
-> v2 过渡期**不写** `meta/plan-finalization.json` 与 `logs/execution-log.md`；缺这两项不算失败，不得为凑表手工补。
-
-### legacy 路径（自然输入不完整时的回退）
-
-- [ ] 所有待发布产物先写入 staging，不直接覆盖正式 change 目录
-- [ ] 执行 `harness_plan_finalize.py finalize --change-dir ... --staging-dir ... --change ... --run-id <plan-run-id> --attempt <attempt> --json`；身份必须与本次 `phase.start` 完全相同
-- [ ] finalizer 返回 `ok=true`、`artifactsHash`、绝对 `receiptPath` 与稳定 `artifactRef=meta/plan-finalization.json`；重复执行返回 `idempotent=true`
-- [ ] 紧接着执行 `harness_plan_finalize.py verify --change-dir ... --json`
-- [ ] verify 返回 `phaseStartCount=1`、`phaseEndCount=1`、`phaseEndStatus=OK`、`receiptConsistent=true`
-- [ ] 收据 `files` 完整包含 design / plan / implementation-detail / test-scenarios / gate-policy / worktree 六项标准产物；不得省略、重复或经 symlink/junction/reparse point 引用
-- [ ] verify 的 `taskCount` 等于全部任务表行数，`scenarioCount` 等于 Markdown 中全部唯一场景 ID 数；任一为 0 或不一致即 ❌FAIL
-- [ ] finalizer 失败时正式目录无半发布产物、无成功 `phase.end`、无伪造 execution log
-- [ ] 禁止在 finalizer 之前手工追加成功 `phase.end`
-- [ ] context close 的 `--artifact` 只传 finalizer 原样返回的 `receiptPath` 或 `artifactRef`，不得猜测、拼接或使用 `<plan-finalization>` 占位文本
-
-| 文件（legacy） | 必须存在 | 检查结果 |
-|------|:---:|:---:|
-| `.harness/changes/<change>/spec/<change>-design.md` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-plan.md` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-implementation-detail.md` | ✅ | □ |
-| `.harness/changes/<change>/plans/<change>-test-scenarios.md` | ✅ | □ |
-| `.harness/changes/<change>/meta/gate-policy.json` | ✅ | □ |
-| `.harness/changes/<change>/meta/worktree.json` | ✅ | □ |
-| `.harness/changes/<change>/meta/implementation-checkpoints.json` | ✅ | □ |
-| `.harness/changes/<change>/meta/scenario-manifest.json`（非空且计数一致） | ✅ | □ |
-| `.harness/changes/<change>/meta/plan-finalization.json`（finalized） | ✅ | □ |
-| `.harness/changes/<change>/logs/execution-log.md` | ✅ | □ |
-| `.harness/changes/<change>/events.ndjson` | ✅ | □ |
-
-### Plan 结束行为检查
+> **先认路径**：新 change 只走 v2；legacy 产物（历史 change）只读。必需文件清单 → `reference.md`「阶段 8」。
 
-```
-□ 未询问 Subagent-Driven / Inline Execution 等执行模式
-□ 最终输出只提示了产出物路径和下一步 /harness-run
-□ 未将 docs/superpowers/ 列为最终产物路径
-```
+文件是否齐全、哈希是否一致、身份是否匹配、计数是否对得上——这些 **finalizer 与 verify 已经 fail-closed 判定**，逐条复述不产生新结论，只会把一份事实变成两份。命令失败时按返回的 `code` 查 `reference.md`，不要对着清单猜。
 
-### Legacy Frontmatter 兼容
+下面三条不在机器判定范围内，必须自己守：
+
+- [ ] **v2**：只手写 `meta/plan-evidence-input.json`。`plans/*.md` 由 finalize 派生，手写的会被渲染覆盖，只是白写
+- [ ] 任何缺失**都不得手工补写**（包括 `phase.end`）；回到对应阶段改自然输入/staging 后重跑
+- [ ] v2 过渡期**不写** `meta/plan-finalization.json` 与 `logs/execution-log.md`；缺这两项不算失败，不得为凑表手工补
 
-```
-□ 已确认 plan 文件 frontmatter 存在
-□ 如不存在 → 已从路径推断 change-name 和 plan-name
-□ 如不存在 → 执行日志中已标记 🟡 legacy-plan
-□ 旧 plan 不因 frontmatter 缺失而 FAIL
-```
 
 ## 关键原则
 
@@ -300,7 +226,9 @@ source: harness-plan
 - 场景表是后续所有步骤的真相源——宁可多花时间打磨，不要草草了事
 - 如果需求不明确，优先提问而不是猜测后继续设计
 - 任务拆分粒度按复杂度调整——plan 简表保持可追踪，implementation-detail 按风险和复杂度自适应展开
-- **Plan 结束禁止询问执行模式**：Subagent-Driven / Inline Execution 属于 /harness-run 阶段
+
+> Plan 的结束行为（禁止询问执行模式、只提示 `/harness-run`）由 `SKILL.md` 的关键规则表定义，
+> 详细规则见 `reference.md`「Plan 结束行为规则」。此处不再复述。
 
 ## 事件记录（前置规则）
 

package/harness/bundles/general/codebuddy/harness-plan/protocols.md

@@ -128,4 +128,6 @@ description: harness-plan 的原生规划协议。吸收 brainstorming、grill-m
 - implementation-planning-protocol：plan 简表、implementation-detail、test-scenarios 三件套一致，无占位符
 ```
 
-该自检作为 `verification` 事件的 `note` 追加；关键结论分别追加 `decision` / `issue` 事件。渲染器在 `phase.end` 后生成执行日志。
+自检结论直接展示给用户即可，**不要**再追加一条 `verification` 事件——「协议自检通过」不改变
+任何结论，只增加监控噪声（roadmap 12 号「事件规则」）。真正影响行为的东西照常留痕：关键决策
+追加 `decision`，发现的冲突与阻塞追加 `issue`。渲染器在 `phase.end` 后生成执行日志。

package/harness/bundles/general/codebuddy/harness-plan/reference.md

@@ -6,7 +6,7 @@ description: harness-plan 的需求提取模板、任务拆分规则、测试场
 
 ## Worktree 决策文件模板
 
-阶段 4 设计审批包确认后必须生成 `.harness/changes/<change-name>/meta/worktree.json`。这是后续 `/harness-run` 是否创建/切换 worktree 的唯一机器可读依据。
+阶段 4 设计审批包确认后必须生成 `.harness/changes/<change-name>/meta/worktree.json`。这是后续 `/harness-execute` 是否创建/切换 worktree 的唯一机器可读依据。
 
 ### 使用 Worktree
 
@@ -21,7 +21,7 @@ description: harness-plan 的需求提取模板、任务拆分规则、测试场
   "branch": "harness/<change-name>",
   "decisionBy": "user",
   "decisionAt": "YYYY-MM-DD HH:mm",
-  "ownerSkill": "harness-run"
+  "ownerSkill": "harness-execute"
 }
 ```
 
@@ -43,7 +43,7 @@ description: harness-plan 的需求提取模板、任务拆分规则、测试场
 
 `path` 与 `branch` 必须来自 `harness_runtime.py adapter`/`meta/runtime.json`。所有 agent 共享统一路径 `.worktrees/<change-name>` 与统一分支前缀 `harness/`；`agent` 字段仅作创建者元数据，不再决定路径。
 
-`用户选择使用 Worktree；决策文件为 meta/worktree.json；requested=true, created=false；创建责任为 harness-run。`
+`用户选择使用 Worktree；决策文件为 meta/worktree.json；requested=true, created=false；创建责任为 harness-execute。`
 
 ## 参考 — 详细格式
 
@@ -108,12 +108,13 @@ description: harness-plan 的需求提取模板、任务拆分规则、测试场
 
 | 路径 | 审批内容去哪 | 设计文档 |
 |------|------------|---------|
-| **v2**（默认） | `meta/plan-evidence-input.json` 的 `approval.content` + `approver_id` | `plans/<change-name>-design.md`，由 finalize 从审批内容派生——**不要手写**，手写的会被派生渲染覆盖 |
-| **legacy** | 直接写文档 | `.harness/changes/<change-name>/spec/<change-name>-design.md`（不存在则不得进入阶段 6） |
+| **v2**（唯一路径） | `meta/plan-evidence-input.json` 的 `approval.content` + `approver_id` | `plans/<change-name>-design.md`，由 finalize 从审批内容派生——**不要手写**，手写的会被派生渲染覆盖 |
+
+> 历史 change 的 `spec/<change-name>-design.md`（legacy 产物）保持可读，归档与 read-protocol 照常消费。
 
 **设计文档路径规则**：禁止保存到 `docs/superpowers/specs/` 作为正式产物；`/harness-plan` 不运行时调用 Superpowers。同一 change 不得同时存在 `plans/` 与 `spec/` 两份设计——v2 发布的那份才受完整性门禁保护。
 
-### 设计文档模板（legacy 路径手写时使用；v2 由 finalize 派生，此模板仅作内容清单参考）
+### 设计文档模板（v2 由 finalize 派生；此模板仅作内容清单参考）
 
 ```markdown
 ---
@@ -189,8 +190,8 @@ source: harness-plan
 ```
 .harness/changes/<change-name>/plans/
 ├── <change-name>-design.md                  # 设计（v2 由 finalize 派生）
-├── <change-name>-plan.md                    # harness 简洁任务表，run 默认读取
-├── <change-name>-implementation-detail.md   # 原生自适应详细执行参考，run 补充读取
+├── <change-name>-plan.md                    # harness 简洁任务表，execute 默认读取
+├── <change-name>-implementation-detail.md   # 原生自适应详细执行参考，execute 补充读取
 └── <change-name>-test-scenarios.md          # 测试场景表
 ```
 
@@ -293,55 +294,21 @@ status: approved
    .harness/changes/<change-name>/backups/
    ```
 
-3. **保存设计文档**：
-   - **v2**：不手写文档；把审批内容填进 `meta/plan-evidence-input.json` 的 `approval.content`，
-     `plans/<change-name>-design.md` 由 finalize 派生（frontmatter 也由渲染器写）
-   - **legacy**：保存到 `.harness/changes/<change-name>/spec/<change-name>-design.md`
-
-   legacy 设计文档 frontmatter 格式：
-   ```yaml
-   ---
-   change-name: <change-name>
-   created: YYYY-MM-DD HH:mm
-   status: approved
-   source: harness-plan
-   ---
-   ```
-
-   > 如果 frontmatter 缺失，后续 run/test/review/submit/archive 不得依赖模型猜测 change-name。
+3. **保存设计文档**：不手写文档；把审批内容填进 `meta/plan-evidence-input.json` 的
+   `approval.content`，`plans/<change-name>-design.md` 由 finalize 派生（frontmatter 也由渲染器写）。
 
 4. **初始化结构化事件**：由阶段 0.5 的 `harness_context.py bootstrap-plan` 一次完成——它生成合规的 `<plan-run-id>`（`plan_<uuid>` 形状，必须小写字母开头：v2 identity 规则，裸 UUID 有 10/16 概率数字开头被拒）、`<attempt>`（首次为 `1`）并追加 `phase.start`，重跑复用同一身份不重复写事件。finalizer 必须复用引导返回的 `runId`/`attempt`，否则 verify 会按生命周期身份 fail-closed。同一次 plan 尝试内不得改变身份。执行日志在 `phase.end` 时由完整事件流渲染，任何阶段都不得直接用 Write/Edit 维护该投影。
 
-5. **保存计划文件**：
-   - **v2**：不手写；任务填 `structured_input.tasks`、场景填 `structured_input.scenarios`，
-     `plans/` 下四份 Markdown 全部由 finalize 派生
-   - **legacy**：手写并保存到（含 YAML frontmatter，含 change-name）
-     - `.harness/changes/<change-name>/plans/<change-name>-plan.md`（简洁任务表）
-     - `.harness/changes/<change-name>/plans/<change-name>-implementation-detail.md`（自适应详细执行参考）
-     - `.harness/changes/<change-name>/plans/<change-name>-test-scenarios.md`（测试场景表）
-
-   legacy 计划文件 frontmatter 格式：
-   ```yaml
-   ---
-   change-name: <change-name>
-   plan-name: <change-name>
-   created: YYYY-MM-DD HH:mm
-   source-spec: ../spec/<change-name>-design.md
-   implementation-detail: ./<change-name>-implementation-detail.md
-   test-scenarios: ./<change-name>-test-scenarios.md
-   status: approved
-   ---
-   ```
-
-   > 如果 frontmatter 缺失，后续 run 不得依赖模型猜测 change-name 或关联文件路径。
+5. **保存计划文件**：不手写；任务填 `structured_input.tasks`、场景填 `structured_input.scenarios`，
+   `plans/` 下四份 Markdown 全部由 finalize 派生。
 
-6. **等待用户确认后**，提示下一步：运行 `/harness-run`
+6. **等待用户确认后**，提示下一步：运行 `/harness-execute`
 
-   > 后续 skill（run/test/review）启动时，会扫描 `.harness/changes/*/plans/`（排除 `.harness/archive/*/`）自动定位变更名目录，无需手动指定路径。同一时间最多一个未归档变更。
+   > 后续 skill（execute/review）启动时，会扫描 `.harness/changes/*/plans/`（排除 `.harness/archive/*/`）自动定位变更名目录，无需手动指定路径。同一时间最多一个未归档变更。
 
 ## 阶段 8：结束前产物完整性检查 ⚠️ 强制
 
-> **缺任一文件 → ❌FAIL，不得宣称 plan 完成。先认清走的是 v2 还是 legacy——两条路径的必需文件集不同，拿 legacy 的表去查 v2 会得出假失败。**
+> **缺任一文件 → ❌FAIL，不得宣称 plan 完成。新 change 只走 v2；legacy 列仅用于读历史 change（0.3.0 起不再写入）。**
 
 | 文件 | v2 | legacy |
 |------|:---:|:---:|
@@ -351,17 +318,39 @@ status: approved
 | `.harness/changes/<change>/plans/<change>-plan.md` | ✅（派生） | ✅ |
 | `.harness/changes/<change>/plans/<change>-implementation-detail.md` | ✅（派生） | ✅ |
 | `.harness/changes/<change>/plans/<change>-test-scenarios.md` | ✅（派生） | ✅ |
-| `.harness/changes/<change>/meta/gate-policy.json` | ✅ | ✅ |
+| `.harness/changes/<change>/meta/gate-policy.json` | ✅（**classify 写，非发布产物**） | ✅ |
+| `.harness/changes/<change>/meta/plan-profile.json` | ✅（派生） | — |
 | `.harness/changes/<change>/meta/worktree.json` | ✅ | ✅ |
 | `.harness/changes/<change>/meta/implementation-checkpoints.json` | ✅ | ✅ |
 | `.harness/changes/<change>/meta/scenario-manifest.json` | ✅ | ✅ |
 | `.harness/changes/<change>/meta/publication-journals/<op>.json`（committed） | ✅ | — |
 | `.harness/changes/<change>/meta/plan-events.ndjson` | ✅ | — |
-| `.harness/changes/<change>/meta/plan-finalization.json` | — | ✅ |
-| `.harness/changes/<change>/logs/execution-log.md` | — | ✅ |
+| `.harness/changes/<change>/meta/plan-finalization.json` | — | ✅（只读） |
+| `.harness/changes/<change>/logs/execution-log.md` | — | ✅（只读） |
 | `.harness/changes/<change>/events.ndjson` | ✅ | ✅ |
 
-legacy 的 `plan-finalization.json.files` 必须完整列出 design、plan、implementation-detail、test-scenarios、gate-policy、worktree 六项标准输入。`verify` 对缺项、重复项、越界路径以及 symlink/junction/reparse point 一律 fail-closed；不得通过删减收据文件集后重算哈希来绕过完整性检查。
+历史 change 的 legacy `plan-finalization.json.files` 必须完整列出 design、plan、implementation-detail、test-scenarios、gate-policy、worktree 六项标准输入。`harness_plan_finalize.py verify`（唯一保留子命令）对缺项、重复项、越界路径以及 symlink/junction/reparse point 一律 fail-closed；不得通过删减收据文件集后重算哈希来绕过完整性检查。
+
+### 两套分类模型的边界（别把它们当同一件事）
+
+| | Python `tier` | TS `mode` |
+|---|---|---|
+| 取值 | `fast` / `standard` / `full` | `quick` / `standard` / `assurance` |
+| 写到哪 | `meta/gate-policy.json`（`schemaVersion:1`，camelCase） | `meta/plan-profile.json`（artifact 包装体，snake_case） |
+| 谁写 | `harness_gate.py classify`（阶段 0.5 由 bootstrap-plan 调起） | `hunter-harness plan finalize`（阶段 8 发布） |
+| 地位 | **classify 工作副本**：0.5 分类 + 0.6 阶段计划落盘处；未发布的 change 由它驱动门禁 | **门禁权威**：发布时把工作副本的门禁字段（DAG/validations/tier/source）并入 content 并哈希绑定；`harness_paths.load_change_gate_policy` v2 优先、工作副本回退 |
+| 输入 | 计划文档的「风险等级」正则 + capabilityGates 信号 | `risk_signals`（手填与命令推断取并集）+ 真实仓库 capabilities |
+
+**两者不共用文件名。** v2 发布对 `binding.ownership_paths` 逐个原子覆盖，若派生视图占用 `meta/gate-policy.json`，阶段 8 会把 classify 写的那份换成包装体，之后 `gate begin --phase execute` 直接 `POLICY_LOAD_FAILED`——`harness_gate.effective_workflow_policy` 读 `schemaVersion` 拿不到就 raise。
+
+**派生视图的两条前置缺陷已接通**（2026-08，接通 ≠ 门禁权威切换，权威仍是 Python gate-policy）：
+
+1. `risk_signals` 不再是纯手填。`plan evidence-pack` 按 `structured_input.tasks[].affected_paths`（主源）与 `git status --porcelain --untracked-files=all`（次源）经 marker 表推断信号（与 `harness_gate.py` classify 同一张表），**与手填取并集**——推断是安全地板，手填不能删除推断项；逐条信号在 `pack.context.signal_provenance` 标注 `declared / inferred / declared+inferred`。
+2. `capabilities` 由命令真实探测：`is_git`（`rev-parse --is-inside-work-tree`）、`has_remote`（`git remote` 非空）、`uses_worktree`（`--git-dir` ≠ `--git-common-dir`，或 `machine.worktree_policy=required`）；探针不可用（非 git 目录/无 git）则全 false 并标注 `provenance: "unavailable"`。阶段 0.6 `configure-plan` 落的 `meta/gate-policy.json` `plannedPhases` 也会被读取（顶层 `plannedPhases` 为字符串数组才视为权威形状，v2 包装体/坏 JSON 一律回退派生），可选阶段照它取舍，required 阶段缺失时保留并在 stdout 告警 `phase_set_required_retained`，来源标注 `phase_set_source: gate-policy | derived`。
+
+**权威已切换（2026-08）**：`meta/plan-profile.json` 是门禁权威。发布时 `plan evidence-pack` 把工作副本的 `requiredGateDag`/`requiredValidationsByPhase`/`tier`/`source` 并入 v2 gate_policy content（白名单键，哈希绑定），`harness_paths.load_change_gate_policy` 在 gate/context/phase/archive 各处统一 v2 优先：快照完整（含 `mode`/`planned_phases`/`required_gate_dag`/`required_validations_by_phase`）即以它为准；0.2.92-era 的不完整快照与未发布的 change 回退工作副本。两者并存且 `plannedPhases`（canonical 去重后）不一致 → drift 报告，以 v2 为准——发布后改写工作副本本身就是异常。provenance 标注只进 stdout 与 `pack.context`，不进任何哈希身份字段。
+
+`meta/implementation-checkpoints.json` 的情况不同：v2 包装体里的 `content.foundation_gate` 信息是够的，所以门禁在**只读侧**解包（`checkpoint_status` 同时认 `checkpoints[]`、顶层 `foundationGate` 与 v2 包装体三种形状），不改文件名。注意写回路径（`gate checkpoint approve`）仍然操作原始文档——用归一化结构覆盖会破坏 v2 产物的哈希绑定。
 
 ### 阶段 8 v2 路径（结构化证据包流程，新 change 优先）
 
@@ -392,7 +381,7 @@ npx hunter-harness plan finalize --input .harness/changes/<cn>/meta/plan-evidenc
 | `change_key` | `replace-with-change-name` | 真实 change-name（kebab-case：`^[a-z0-9]+(-[a-z0-9]+)*$`） |
 | `context.run_id` | `plan_replace-with-your-plan-run-id` | 阶段 0.5 生成、`phase.start` 已用的**同一个** plan-run-id |
 | `evidence_sources[].content_hash` | `sha256:deadbeef…` | 证据源内容的真实 sha256（校验器显式拒绝全 0） |
-| `risk_signals` | `["production_code"]` | classify 实际返回的信号 |
+| `risk_signals` | `["production_code"]` | 可留空数组：命令按 affected_paths 与 git status 推断并与手填取并集；手填只增不减 |
 
 **容易踩的硬约束**（违反时命令会给 `field_path`，不必再猜）：
 
@@ -422,47 +411,49 @@ npx hunter-harness plan finalize --input .harness/changes/<cn>/meta/plan-evidenc
 | `context` | project_id/run_id/branch_name/attempt（复用 plan-run-id 与 attempt） | 0.5 |
 | `expected_baseline` | 首次发布 `{state:"absent", manifest_hash:null, generation:0}` | 8 |
 
-> ⚠️ **已知缺口：v2 派生的 `meta/scenario-manifest.json` 目前喂不了 run/test 门禁。**
-> 它是 artifact 包装体，每条场景只有 `scenario_id/coverage_dimension/execution_level/
-> evidence_requirements/risk_level/task_refs/requirement_refs`；而门禁按
-> `id/priority/requiredEvidenceKind/ownerPhase/executableTestId/testFile/testTitle`
-> 判定哪些场景需要 ledger 证据。缺 `priority` 与 `requiredEvidenceKind` 时"必需场景"会算成空集，
-> 所以门禁**明确报 `SCENARIO_MANIFEST_V2_UNSUPPORTED` 并列出 `missingFields`，绝不静默放行**。
-> 需要 ledger 证据闭环的变更，在 v2 场景契约补齐这些字段前请走 legacy 路径。
+> **场景契约与门禁的对接**（曾经的已知缺口，现已打通）
+>
+> v2 派生的 `meta/scenario-manifest.json` 是 artifact 包装体，键名与门禁消费的不同。消费端
+> （`harness_gate` 的 C9、`harness_ledger` 的三处）统一调 `harness_plan_finalize.unpack_v2_scenario_manifest`
+> 解成 legacy 形状再判定：`scenario_id→id`、`owner_phase→ownerPhase`、`required_evidence_kind→requiredEvidenceKind`
+> 、可执行三元 `executable_test_id/test_file/test_title→executableTestId/testFile/testTitle`。
+> `required_evidence_kind` 由 `priority` 派生（P0/P1→`ledger`，P2→`advisory`），写在 artifact 里，
+> 消费侧不重推。
+>
+> 因此自然输入的 `scenarios` **必须**带 `priority`（P0/P1/P2）与 `owner_phase`。缺任一项，
+> 门禁**逐场景**校验后报 `SCENARIO_MANIFEST_V2_UNSUPPORTED` 并列出 `missingFields`，绝不静默放行
+> ——逐场景而不是取键的并集：并集只要有一条场景带了 `priority` 就算通过，其余缺字段的会静默
+> 落进非必需集，"必需场景"随之缩水。
+>
+> 可执行三元是**可选**的，但要么整组给全、要么整组省略。ledger 场景全部带齐 → manifest 声明
+> `schemaVersion 2`，关门可绑结构化执行收据；否则降为 1。
 
 - **证据包**（`plan-evidence.json`）是命令推导的产物（trusted/publication/context/baseline），不得手改；任何字段变化必须改自然输入后重跑 evidence-pack。
 - **成功语义**：finalize exit 0 且 `code:"PLAN_FINALIZED"`。落盘事实 = 八 target（plans/*.md ×4 + meta/*.json ×4）+ `meta/publication-journals/<op>.json`（状态 committed）+ `meta/plan-events.ndjson`（artifact_published/phase_ended）。确定性门失败 exit 1 且 `code:"PLAN_FINALIZE_DETERMINISTIC_FAILED"` 附 findings——此时必须回到对应阶段修正规划内容，**不得**手改证据包或 staged 内容绕过。
 - **验证**：journal `state==="committed"` + 八 target 存在 + plan-events.ndjson 含两类终态事件；不得手工补写任何一项。
-- **legacy 收据**：过渡期（阶段 14 前）v2 路径不写 `plan-finalization.json`；消费方若仍读 legacy receipt，由兼容投影单独提供，不得反向要求 v2 双写。
-- **回退**：v2 自然输入不完整（如缺真实审批记录）时才允许走 Python finalizer（legacy 路径）；同一次发布不得两条路径混用。
+- **legacy 收据**：v2 路径不写 `plan-finalization.json`；消费方若读历史 legacy receipt，`harness_plan_finalize.py verify` 保持可读。0.3.0 起 v2 无 legacy 回退——自然输入不完整先补齐（例如补真实审批记录），不得走已删除的 Python finalizer。
 
-### 发布后修订计划（republish）
-
-计划发布后又要改产物，是**正常且高频**的情况——用户看完计划补一个回归场景、修正一条任务、调整验收标准。这时不要与哈希守卫搏斗：
-
-```bash
-python <skills-root>/scripts/harness_plan_finalize.py republish \
-  --change-dir ".harness/changes/<cn>" --staging-dir ".harness/changes/<cn>/runtime/plan-staging" \
-  --change <cn> --run-id "plan_$(uuidgen)" --reason "<为什么要改>" --json
-```
+### 发布后修订计划（v2 重跑流）
 
-它一次性完成整套动作：校验 staging → 分配新 attempt（自动取已用最大值 +1）→ 追加 `phase.start` → 替换收据 → 重新派生 `scenario-manifest.json` 与 `implementation-checkpoints.json` → 写 `phase.end`。收据里保留 `supersedes`（被取代的 hash/runId/attempt）与 `amendReason`，修订全程可审计。
+计划发布后又要改产物，是**正常且高频**的情况——用户看完计划补一个回归场景、修正一条任务、调整验收标准。这时不要与哈希守卫搏斗，按三步重跑修订流：
 
-| 约束 | 说明 |
-|------|------|
-| `--reason` 必填 | 修订已发布计划必须留下理由，否则 `PLAN_AMEND_REASON_REQUIRED` |
-| `--run-id` 必须全新 | 复用旧 run-id 报 `PLAN_AMEND_RUN_ID_IN_USE`（attempt 与 run-id 一一绑定） |
-| 首次发布不能用它 | 无收据时报 `PLAN_NOT_FINALIZED`，首次发布走 `finalize` |
-| 内容没变则空操作 | 返回 `idempotent:true`，不写事件、不消耗 attempt |
+1. 改 `meta/plan-evidence-input.json`（自然输入是唯一可编辑面）。
+2. 重跑 `npx hunter-harness plan evidence-pack --input <input> --output <pack>`：
+   - `context.attempt` 递增（1→2→…）；
+   - `expected_baseline` 置 `present`，带上次发布的 `manifest_hash` 与 `generation`
+     （读 `meta/plan-finalization-transactions/` 最新事务的对应字段）。
+3. 再跑 `npx hunter-harness plan finalize --input <pack>`。
 
-⚠️ **绝对不要手改 `meta/scenario-manifest.json`**。它是 finalizer 从 `test-scenarios.md` 派生的产物，手改会造成真实漂移：`verify` 报 `ARTIFACT_HASH_DRIFT`，run 阶段 `validate_plan_handoff` 也会记 WARN。`republish` 会重新派生它，这才是唯一正确入口。
+新 attempt + 换收据 + 重新派生 `scenario-manifest.json` 与 `implementation-checkpoints.json`
+一次完成；事务链天然保留历史（每次 finalize 一条事务记录），修订全程可审计。
+（0.3.0 前 legacy change 用的 `republish` 子命令已删除；历史收据只读。）
 
-> 直接重跑 `finalize` 会报 `PLAN_FINALIZATION_HASH_CONFLICT`——这是守卫在防止发布后产物被悄悄改动，不是 bug。报错信息里已经给出 `republish` 命令行。
+⚠️ **绝对不要手改 `meta/scenario-manifest.json`**。它是 finalizer 从 `test-scenarios.md` 派生的产物，手改会造成真实漂移：`verify` 报 `ARTIFACT_HASH_DRIFT`，execute 阶段 `validate_plan_handoff` 也会记 WARN。重跑修订流会重新派生它，这才是唯一正确入口。
 
 ### Plan 结束行为规则
 
-- **禁止询问执行模式**：Subagent-Driven / Inline Execution 属于 /harness-run 阶段
-- 最终输出只提示产出物路径和下一步 `/harness-run`
+- **禁止询问执行模式**：Subagent-Driven / Inline Execution 属于 /harness-execute 阶段
+- 最终输出只提示产出物路径和下一步 `/harness-execute`
 - `docs/superpowers/` 不得作为最终产物路径出现在输出中
 
 ## C2 升级口：跨 provider 评审（显式、非默认）

package/harness/bundles/general/codebuddy/harness-pull/SKILL.md

@@ -3,7 +3,7 @@ name: harness-pull
 description: 从 Hunter Platform 下拉配置/规则/架构/指令（及显式来源分支的分支文件恢复）。仅当用户显式调用
   /harness-pull 或明确说'从平台拉取/恢复'时使用；不得自动触发。
 ---
-<!-- generated by harness_deploy.py; core=b0e6891811c856ce; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=d1485a25236f58dc; overlay=none; agent=codebuddy; do not edit -->
 # harness-pull — 从 Hunter Platform 下拉与恢复
 
 ## Purpose

package/harness/bundles/general/codebuddy/harness-push/SKILL.md

@@ -3,7 +3,7 @@ name: harness-push
 description: 上传本地配置/规则/架构/指令（及显式归档）到 Hunter Platform。仅当用户显式调用 /harness-push
   或明确说'上传到平台'时使用；不得因存在本地修改就自动触发。
 ---
-<!-- generated by harness_deploy.py; core=b0e6891811c856ce; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=d1485a25236f58dc; overlay=none; agent=codebuddy; do not edit -->
 # harness-push — 上传到 Hunter Platform
 
 ## Purpose

package/harness/bundles/general/codebuddy/harness-review/SKILL.md

@@ -4,7 +4,7 @@ description: 6维度代码审查（架构/安全/规范/兼容/测试/性能）
   .harness/context-index.json）和测试场景表，在隔离上下文运行。仅当用户显式调用 /harness-review 时使用；不得在
   test 结束后自动接续执行。
 ---
-<!-- generated by harness_deploy.py; core=b0e6891811c856ce; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=d1485a25236f58dc; overlay=none; agent=codebuddy; do not edit -->
 # harness-review — 代码审查
 
 ## Purpose
@@ -15,7 +15,7 @@ description: 6维度代码审查（架构/安全/规范/兼容/测试/性能）
 
 仅当用户显式调用 `/harness-review` 时执行。test 阶段结束后**不自动**进入本阶段；用户口头提到"审查/review"而未调用本 skill 时，先确认是否走 Harness 审查阶段。
 
-**单阶段原则**：review 关门（报告 + fixback 产出）后必须停止并交还用户，仅提示下一步可执行 `/harness-run --fixback`（有待修项）或 `/harness-submit`；禁止自动接续执行。
+**单阶段原则**：review 关门（报告 + fixback 产出）后必须停止并交还用户，仅提示下一步可执行 `/harness-execute --fixback`（有待修项）或 `/harness-submit`；禁止自动接续执行。
 
 ## Inputs
 
@@ -169,7 +169,7 @@ python <skills-root>/scripts/harness_events.py append --change-dir ".harness/cha
 
 > **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 边界保持最新。
 
-每个阶段的 `phase.start` 与对应 `phase.end` 必须复用同一 `--run-id` / `--attempt`；阶段结束必须写 `--status OK|WARN|FAIL|BLOCKED`。重试同一阶段时生成新的 run-id 并增加 `--attempt <n>`，不得覆盖或伪装成一次执行。**`attempt` 按 phase 全局递增，不是按 run-id**：一个 run-id 只绑定一个 attempt，重试必须「新 run-id ＋ 下一个 attempt」两者同时换，只换其一会撞 `EVENT_ATTEMPT_CONFLICT` 或 `PHASE_ALREADY_CLOSED`。已发布的 plan 用 `harness_plan_finalize.py republish` 自动分配两者。
+每个阶段的 `phase.start` 与对应 `phase.end` 必须复用同一 `--run-id` / `--attempt`；阶段结束必须写 `--status OK|WARN|FAIL|BLOCKED`。重试同一阶段时生成新的 run-id 并增加 `--attempt <n>`，不得覆盖或伪装成一次执行。**`attempt` 按 phase 全局递增，不是按 run-id**：一个 run-id 只绑定一个 attempt，重试必须「新 run-id ＋ 下一个 attempt」两者同时换，只换其一会撞 `EVENT_ATTEMPT_CONFLICT` 或 `PHASE_ALREADY_CLOSED`。已发布 plan 的修订通过重跑 `plan evidence-pack` + `plan finalize` 分配新 attempt（`harness_plan_finalize.py republish` 已于 0.3.0 移除）。
 
 阶段跑得久（plan/run 常见）时用 `harness_context.py renew --project . --change <cn> --executor <tool>` 续租；租约到期本身不再阻断 `close`（同一 owner 的过期租约不构成冲突，收据里记 `leaseLapsed`），但续租能让 `view` 的状态如实反映在跑。跨工具继续执行时写 `--executor-tool <codex|claude-code|codebuddy|cursor>`，并在接棒事件写 `--handoff-from-tool` / `--handoff-reason`；也可由 `HUNTER_HARNESS_TOOL/AGENT/MODEL/RUN_ID` 环境变量统一注入。
 > 片段：logging · phase=`review` · 事件：phase/decision/verification/issue/artifact

package/harness/bundles/general/codebuddy/harness-review/protocols.md

@@ -34,7 +34,7 @@ description: harness-review 的原生修复反馈协议。内化 receiving-code-
 | 风险说明 | 说明为什么值得处理 |
 | 推荐修复 | 可执行的修复方向，不写空泛建议 |
 | 验证方式 | 构建、测试、场景编号或人工确认方式 |
-| 修复动作 | `code` / `manual` / `workflow`；只有 `code` 会进入 `/harness-run --fixback` |
+| 修复动作 | `code` / `manual` / `workflow`；只有 `code` 会进入 `/harness-execute --fixback` |
 | submit 影响 | 默认 advisory；仅 strict-review-gate=true 时标记阻塞 |
 
 如果没有 RED/YELLOW，必须明确写：

package/harness/bundles/general/codebuddy/harness-run/SKILL.md

@@ -3,9 +3,15 @@ name: harness-run
 description: 按变更簇执行 TDD 编码循环（RED→GREEN→REFACTOR→编译验证），逐变更簇实现计划中的任务。仅当用户显式调用
   /harness-run 时使用；不得因用户提到编码/实现就自动触发，也不得被其他阶段 skill 自动接续。
 ---
-<!-- generated by harness_deploy.py; core=b0e6891811c856ce; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=d1485a25236f58dc; overlay=none; agent=codebuddy; do not edit -->
 # harness-run — 需求编码
 
+> **2026-08 阶段合并**：原 `run`（编码）与 `test`（验证）合并为单一 `execute` 阶段，
+> 统一入口为 **`/harness-execute`**（`harness/harness-execute/SKILL.md`）。本 skill 作为
+> 别名保留，frontmatter `name` 不变、内容照旧可用；门禁入参 `--phase run` 经
+> `LEGACY_PHASE_ALIASES` 归一为 execute。别名至少保留一个 minor 版本，退役时间见
+> `docs/harness-improvement-roadmap/`。下文出现的阶段名 `run`/`test` 均按别名解析。
+
 ## Purpose
 
 基于 plan + test-scenarios，按**变更簇**执行 TDD（RED→GREEN→REFACTOR→构建验证），写入 verification-ledger。负责 worktree 创建/切换（见 worktree-gate）。
@@ -83,13 +89,15 @@ python <skills-root>/scripts/harness_test_runner.py exec --project . --timeout-s
 
 返回 `TEST_RUN_ALREADY_ACTIVE`（退出码 3）说明**已有构建在跑**：等它结束或用 `lock-status` 查明持有者，**不得**改用裸跑绕开锁，也不得另起一个并行构建。确认持有进程已消失时才用 `lock-reap` 回收。
 
-**长阶段租约续期**：`gate begin` 的租约默认 TTL 3600 秒，而 run 阶段常常跑得更久。租约过期不会中断执行，只会让最后的 `gate close` 报 `LEASE_ABSENT`。凡预计超过 1 小时的阶段，每完成一个变更簇就用本阶段**原 run-id** 续租一次（同 run-id 重复 claim 即刷新，不会新开 attempt）：
+**长阶段租约**：`gate begin` 的租约默认 TTL 3600 秒，而 run 阶段常常跑得更久。租约过期不会中断执行，**也不再阻断收尾**：`gate close` 发现租约过期而 run-id 仍是本阶段的，会自动用原 run-id 重取并照常关门，只在返回体的 `leaseLapsed` 里记下这个阶段跑过了 TTL。过期本身不说明所有权变了——抢占会重写租约文件把 run-id 换掉，那时报的是 `LEASE_OWNER_MISMATCH`。
+
+因此**不需要**为了长阶段定期续租。确实想让租约始终有效时，用本阶段原 run-id 刷新即可（同 run-id 重复 claim 即刷新，不会新开 attempt）：
 
 ```text
 python <skills-root>/scripts/harness_change.py claim --change <id> --phase run --run-id <本阶段 run-id> --ttl-seconds 3600 --json
 ```
 
-已经报了 `LEASE_ABSENT` 也按同一条命令恢复——错误响应的 `resumeRunId` 就是要用的 run-id；**不要**重跑 `gate begin`，那会新开 attempt 并丢失本轮 capsule。
+仍然报 `LEASE_ABSENT` 说明这个阶段**根本没有租约记录**（从未 begin，或已被释放），不是超时；先确认 `gate begin` 真的跑过。报 `LEASE_INVALID` 说明租约文件损坏，无法证明没被抢占，需人工确认无并发后再用上面的命令重取。两种情况都**不要**重跑 `gate begin`——那会新开 attempt 并丢失本轮 capsule。
 
 **执行器边界**：优先使用项目 build profile 和已有测试入口。禁止为了绕过 ESM、路径或参数问题临时生成 `.js`、`require` 脚本；需要文件式 runner 时使用项目已有入口，确需新增时遵循项目模块类型（例如 ESM 使用 `.mjs`）。runner 包装说明写入 `runnerCommand` 元数据，不得拼进账本的规范 `command`。
 
@@ -123,7 +131,7 @@ python <skills-root>/scripts/harness_change.py claim --change <id> --phase run -
 | **关门/状态** | 10 项关门检查；持久化 run-task-status；仅 run-owned P0 静态-only 导致 WARN；test-owned 待办正常移交 |
 | **Worktree** | `requested=true` 时代码只写 worktree |
 | **构建/测试** | 一律经 `harness_test_runner.py exec`；禁止裸跑 mvn/gradle/npm test；`TEST_RUN_ALREADY_ACTIVE` 表示已有构建在跑，等待而非另起 |
-| **租约** | 阶段超 1 小时按变更簇用原 run-id 续租；`LEASE_ABSENT` 用 `harness_change.py claim` 恢复，不重跑 begin |
+| **租约** | 阶段超 TTL 由 close 自动用原 run-id 重取，无需续租；`LEASE_ABSENT`（无记录）/`LEASE_INVALID`（文件损坏）才需人工 `harness_change.py claim`，一律不重跑 begin |
 | **PowerShell** | 所有 git 经 `powershell.exe -NoProfile -Command` |
 
 ### 陈旧测试安全修复与精确跟踪
@@ -174,7 +182,7 @@ python <skills-root>/scripts/harness_events.py append --change-dir ".harness/cha
 
 > **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 边界保持最新。
 
-每个阶段的 `phase.start` 与对应 `phase.end` 必须复用同一 `--run-id` / `--attempt`；阶段结束必须写 `--status OK|WARN|FAIL|BLOCKED`。重试同一阶段时生成新的 run-id 并增加 `--attempt <n>`，不得覆盖或伪装成一次执行。**`attempt` 按 phase 全局递增，不是按 run-id**：一个 run-id 只绑定一个 attempt，重试必须「新 run-id ＋ 下一个 attempt」两者同时换，只换其一会撞 `EVENT_ATTEMPT_CONFLICT` 或 `PHASE_ALREADY_CLOSED`。已发布的 plan 用 `harness_plan_finalize.py republish` 自动分配两者。
+每个阶段的 `phase.start` 与对应 `phase.end` 必须复用同一 `--run-id` / `--attempt`；阶段结束必须写 `--status OK|WARN|FAIL|BLOCKED`。重试同一阶段时生成新的 run-id 并增加 `--attempt <n>`，不得覆盖或伪装成一次执行。**`attempt` 按 phase 全局递增，不是按 run-id**：一个 run-id 只绑定一个 attempt，重试必须「新 run-id ＋ 下一个 attempt」两者同时换，只换其一会撞 `EVENT_ATTEMPT_CONFLICT` 或 `PHASE_ALREADY_CLOSED`。已发布 plan 的修订通过重跑 `plan evidence-pack` + `plan finalize` 分配新 attempt（`harness_plan_finalize.py republish` 已于 0.3.0 移除）。
 
 阶段跑得久（plan/run 常见）时用 `harness_context.py renew --project . --change <cn> --executor <tool>` 续租；租约到期本身不再阻断 `close`（同一 owner 的过期租约不构成冲突，收据里记 `leaseLapsed`），但续租能让 `view` 的状态如实反映在跑。跨工具继续执行时写 `--executor-tool <codex|claude-code|codebuddy|cursor>`，并在接棒事件写 `--handoff-from-tool` / `--handoff-reason`；也可由 `HUNTER_HARNESS_TOOL/AGENT/MODEL/RUN_ID` 环境变量统一注入。
 > 片段：logging · phase=`run`

package/harness/bundles/general/codebuddy/harness-submit/SKILL.md

@@ -3,7 +3,7 @@ name: harness-submit
 description: 最终提交封装：验证→中文 commit→提交/推送；worktree 模式含 --no-ff 合并回主分支。仅当用户显式调用
   /harness-submit（或 /harness-merge 重入合并段）时使用；用户口头说'提交/commit/push'时必须先确认，不得自动触发。
 ---
-<!-- generated by harness_deploy.py; core=b0e6891811c856ce; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=d1485a25236f58dc; overlay=none; agent=codebuddy; do not edit -->
 # harness-submit — 最终提交（含 worktree 合并）
 
 ## Purpose
@@ -176,7 +176,7 @@ python <skills-root>/scripts/harness_events.py append --change-dir ".harness/cha
 
 > **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 边界保持最新。
 
-每个阶段的 `phase.start` 与对应 `phase.end` 必须复用同一 `--run-id` / `--attempt`；阶段结束必须写 `--status OK|WARN|FAIL|BLOCKED`。重试同一阶段时生成新的 run-id 并增加 `--attempt <n>`，不得覆盖或伪装成一次执行。**`attempt` 按 phase 全局递增，不是按 run-id**：一个 run-id 只绑定一个 attempt，重试必须「新 run-id ＋ 下一个 attempt」两者同时换，只换其一会撞 `EVENT_ATTEMPT_CONFLICT` 或 `PHASE_ALREADY_CLOSED`。已发布的 plan 用 `harness_plan_finalize.py republish` 自动分配两者。
+每个阶段的 `phase.start` 与对应 `phase.end` 必须复用同一 `--run-id` / `--attempt`；阶段结束必须写 `--status OK|WARN|FAIL|BLOCKED`。重试同一阶段时生成新的 run-id 并增加 `--attempt <n>`，不得覆盖或伪装成一次执行。**`attempt` 按 phase 全局递增，不是按 run-id**：一个 run-id 只绑定一个 attempt，重试必须「新 run-id ＋ 下一个 attempt」两者同时换，只换其一会撞 `EVENT_ATTEMPT_CONFLICT` 或 `PHASE_ALREADY_CLOSED`。已发布 plan 的修订通过重跑 `plan evidence-pack` + `plan finalize` 分配新 attempt（`harness_plan_finalize.py republish` 已于 0.3.0 移除）。
 
 阶段跑得久（plan/run 常见）时用 `harness_context.py renew --project . --change <cn> --executor <tool>` 续租；租约到期本身不再阻断 `close`（同一 owner 的过期租约不构成冲突，收据里记 `leaseLapsed`），但续租能让 `view` 的状态如实反映在跑。跨工具继续执行时写 `--executor-tool <codex|claude-code|codebuddy|cursor>`，并在接棒事件写 `--handoff-from-tool` / `--handoff-reason`；也可由 `HUNTER_HARNESS_TOOL/AGENT/MODEL/RUN_ID` 环境变量统一注入。
 > 片段：logging · phase=`submit`/`merge`

package/harness/bundles/general/codebuddy/harness-submit/checklist.md

@@ -117,7 +117,7 @@ python <skills-root>/scripts/harness_ledger.py can-reuse `
 
 **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，否则不得阻塞提交。
+**review fixback**（参考性）：如果 `.harness/changes/<change-name>/reports/review/fixback-*.md` 存在，展示最新 fixback 摘要并提示“可回到 `/harness-execute --fixback` 处理”；除非 `review.strict-review-gate=true` 且存在 RED，否则不得阻塞提交。
 
 ## 步骤 3：.gitignore 检查 + 暂存业务文件 ⚠️ 强制阻断
 

package/harness/bundles/general/codebuddy/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=b0e6891811c856ce; overlay=none; agent=codebuddy; do not edit -->
+<!-- generated by harness_deploy.py; core=d1485a25236f58dc; overlay=none; agent=codebuddy; do not edit -->
 # harness-sync
 
 ## Purpose