commit-push-close

commit-push-close

与 /commit-push-pr 的区别：两者遵循相同的共享交付政策，但此技能会直接关闭关联的问题，而不是创建带有符合目标要求的问题引用的 PR。

问题命令显示的是 GitHub 默认设置；若使用以工作区命名的跟踪器，则按 references/ship-policy.md 中的 Tracker 覆盖这些命令。

共享交付政策

阅读一次 references/ship-policy.md，然后在当前步骤查阅其中对应的章节；保留其中的安全检查。本文件介绍直接关闭问题的步骤。

问题关闭评论格式

关闭问题前，先在问题下发表评论。使用 How-to-test rules 中完整的 QA handoff 模板，包括产品位置、确切的更改路径、设置、带预期结果的操作，以及验证状态。不得注明归属：提交、问题或评论中都不得添加或保留共同作者、AI 或工具归属信息。

Implemented in <SHA> on `<branch>`.
<QA handoff from the shared policy>

使用 “Implemented in”，因为发表评论和关闭问题是两个独立操作；只有在读回已完成的状态后，才能声称问题已关闭。

工作流

每次阶段转换时，按字段逐行输出 Stage / Found / Next / Needs user。

1. 读取状态 — 通过 Worktree handoff 确定任务检出目录，然后运行 references/ship-policy.md 中的 Read state 命令。如果当前分支不是检测到的默认分支，此次关闭涉及的代码可能尚未合并——请说明这一点，并确认是直接关闭还是转到 /commit-push-pr；如果仓库要求使用 PR，也同样处理。如果用户暂时不在线，继续起草内容，并在第 6 步的草稿中说明这个选择；这项组合审批仍是不可绕过的关卡。

   然后执行 Code review：除非本次会话已针对当前差异运行 /code-review，否则询问：“先对当前差异运行 /code-review（推荐），还是不经审查直接交付？”若审查发现需要修复的问题，则在此停止交付。

2. 确定或创建问题 — 按以下顺序检查：分支名称（例如 feat/123-...、agent/PROJ-456-...）、近期提交、对话上下文。如果都没有，则针对有效的小型临时工作，切换到 Inline issue creation——现在先起草，只有在第 6 步获得组合审批后才创建；创建后，将问题编号填入提交的 Issue: 行和第 10 步的 <num> 中。

3. 读取问题标签 — 对于已存在的问题，运行 gh issue view <num> --json state,labels,title,url,body，并根据 Label validation 表进行验证，按表中的处理结果执行（需要停止的状态转到 /triage；适用时使用分类体系缺失的回退方案）。如果问题已处于 CLOSED 状态，则停止并询问：本次是否重新打开、发表评论但不关闭，还是改用其他问题。刚通过行内创建的问题无需检查——创建时已设置标签。

4. 起草提交消息 — 根据问题标题和差异，按照 Commit message format 和 Naming anchor 起草。如果工作区干净，但相对于基准分支已有领先提交，则遵循 Commits already on the branch：不创建新提交，并跳过第 8 步。

5. 起草问题关闭评论 — 使用 How-to-test rules。交付前应用 Check evidence and reuse：检查现有证据，只运行缺失或已失效的检查；在草稿中写明实际结果及其来源。通过自动化测试验证每项问题 Acceptance criteria；对于浏览器可见的行为，则按照目标政策要求的模式运行浏览器，并在草稿中写明验收报告。若有验收标准未满足，则停止交付，除非用户同意延期。如果无法从差异和仓库中明确计划，先询问缺失的信息，再继续。

   展示草稿前，运行 Authorship policy 清理；若环境文件或密钥有更改，则执行 Env parity policy 验证。

6. 向用户展示草稿 — 在执行任何写入操作前等待审批；只需一次组合确认，不要分三次确认：

   • 已存在的问题：提交消息 + 关闭评论。
   • 行内创建的问题：新问题标题 + 正文 + 分类/状态标签 + 提交消息 + 关闭评论。获得审批后，先创建问题，再依次提交、推送、关闭。 如果用户不在，请展示草稿并停止——切勿提交、推送或关闭未经批准的事项。

7. 提交前安全检查——暂存前，执行 提交前安全检查 中的每项检查。

8. 按 提交消息格式 中带引号的 HEREDOC 形式提交。

9. 推送当前分支：

   • 已跟踪远程分支 → git push。
   • 没有上游分支 → git push -u origin <branch>。
   • 如果当前分支是检测到的默认分支：推送前单独停止并确认——第 6 步的批准不涵盖此次推送。如果用户不在，请保留未推送的提交，跳过关闭（关闭评论必须引用已推送的提交），并在报告的“需要用户处理”部分列出这两项。
   • 关闭前确认推送已成功——命令退出时未报错，且根据 读取状态，目标远程的 git ls-remote SHA 与本地提交一致；仅凭本地状态不足以确认。推送被拒绝（非快进、身份验证过期）时，停止关闭。

10. 关闭问题——确认 检查证据并复用 仍涵盖已推送的内容和执行身份；重新运行缺失或已失效的检查，或仓库规定的门禁。检查失败时停止关闭。将实际 SHA 和分支填入 QA 草稿，并写入临时文件。发布评论并读回确认后再关闭：

    gh issue comment <num> --body-file <temp-file>.md
    gh issue view <num> --json comments
    # 关闭前，确保已发布的评论正文和 URL 与草稿相符。
    gh issue close <num> --reason completed
    gh issue view <num> --json state -q .state   # 预期为 CLOSED
    

    如果发布评论或读回确认失败，保持问题开启。如果关闭失败，报告已推送的 SHA 和已发布的评论 URL，并保持问题未关闭。重试时只执行缺失的操作。只有返回的状态为已完成，才能视为“已关闭”。

11. 报告——<SHA> 已推送到 <branch>；问题 #<num> 已关闭（已验证状态为 CLOSED）；QA：<comment URL>。部分完成时，列出实际完成的操作，以及失败或推迟的操作和原因。包括任何需要用户执行的操作。附上 回复页脚。

示例

匹配的提交消息见 提交示例（问题 #418）。

关闭评论：

Implemented in 9f0e1a2 on `feat/418-idempotency`.

## QA handoff
Change: 9f0e1a2 on `feat/418-idempotency`.

### What changed
Repeated checkout requests now return the original confirmation without a second charge.

### Where changed
- Checkout, `POST /checkout`: `server/checkout/handler.ts` handles replayed request IDs.
- `server/checkout/handler.test.ts` covers replay and concurrent requests.

### Setup
Use the local app at this revision, a test account and the repo's payment sandbox. No real charges. Follow the repo's local setup instructions.

### How to test
1. Submit a test checkout and resend it with the same `x-request-id`. Expect the original confirmation and one charge.
2. Submit a different test order with a new request ID. Expect a separate confirmation and charge.
3. Run `pnpm test server/checkout/handler.test.ts`. Expect all replay and race tests to pass.

### Acceptance criteria
Partially accepted — 2/3 criteria verified by automated tests and headless browser; 1 pending manual.
- [x] A resubmitted checkout shows the original confirmation — browser: submit checkout → resubmit same `x-request-id` → original confirmation number shown.
- [x] Concurrent replays produce one charge — test: `pnpm test server/checkout/handler.test.ts` passed.
- [ ] Verified in the payment sandbox — pending manual: How to test step 1 (sandbox needs owner credentials).

### Verification
Status: PARTIAL — source: executed now
Automated check: 1 test file and 6 tests passed. Manual payment checks pending.
Before: `handler.test.ts` "replays return the original result" failed at base — expected 1 charge, received 2.
After: the same test passes.
Review: /code-review — standards and spec: no findings.

### Merge danger
Door: two-way — reverting the commit restores the old path; idempotency keys expire in 24h.
Blast radius: checkout API clients — checked: `rg "x-request-id"` shows only the web client sends it.

### Gaps
Webhook handling remains outside this fix, follow-up #419. Remove test orders after manual QA.

完成标准

• 共享策略中 交付完成标准 的每一项
• 已验证问题关闭——gh issue view <num> --json state -q .state → CLOSED（或工作区跟踪器中的已完成状态）——在报告中注明