commit-push-close

commit-push-close

/commit-push-pr との境界：共通の ship ポリシーは同じですが、このスキルでは、対象に適した課題参照を付けて PR を作成する代わりに、関連付けられた issue を直接クローズします。

issue コマンドには GitHub のデフォルトが示されています。ワークスペース名のトラッカーがある場合は、references/ship-policy.md の Tracker に従って、そのコマンドを上書きします。

共通の ship ポリシー

references/ship-policy.md を一度読み、現在の手順に該当する名前付きセクションを参照してください。安全ゲートは維持してください。このファイルでは直接クローズする手順を扱います。

issue クローズコメントの形式

クローズする前に issue に投稿してください。How-to-test rules の QA handoff テンプレートを完全な形で使用し、プロダクトの場所、変更した正確なパス、セットアップ、期待される結果を含む操作、検証ステータスを記載してください。帰属表示は一切禁止です。コミット、issue、コメントに共同作成者、AI、ツールの帰属表示を追加したり残したりしないでください。

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

コメントの投稿と issue のクローズは別々の操作であるため、「Implemented in」を使用してください。完了した状態を読み戻してから、クローズしたと述べてください。

ワークフロー

各フェーズの移行時に、Stage / Found / Next / Needs user を各項目1行で出力してください。

1. 状態を読み取る — Worktree handoff を使って作業用チェックアウトを特定し、references/ship-policy.md の Read state コマンドを実行します。現在のブランチが検出されたデフォルトブランチでない場合、このクローズの対象となるコードがまだマージされていない可能性があります。そのことを伝え、直接クローズするか /commit-push-pr に切り替えるかを確認してください。リポジトリで PR が必須の場合も同様です。ユーザーが不在の場合はドラフトの作成を続け、この選択肢をステップ6のドラフトとともに提示してください。この一括承認は引き続き必須のゲートです。

   次に、Code review を適用します。このセッションでこの差分に対して /code-review をすでに実行していない限り、「先にこの差分で /code-review を実行しますか（推奨）、それともレビューなしで進めますか？」と尋ねてください。修正すべき指摘があるレビュー結果の場合は、ここで ship を停止します。

2. issue を解決または作成する — 次の順に確認します。ブランチ名（例：feat/123-...、agent/PROJ-456-...）、最近のコミット、会話のコンテキスト。いずれにも該当しない場合は、有効な小規模の臨時作業について Inline issue creation に切り替えます。ここでドラフトを作成し、ステップ6の一括承認後にのみ作成します。作成したら、その番号をコミットの Issue: 行とステップ10の <num> に記入します。

3. issue のラベルを読む — 既存の issue については、gh issue view <num> --json state,labels,title,url,body を実行し、Label validation の表に照らして検証し、その結果に従います（停止状態の場合は /triage に切り替えます。分類体系がない場合のフォールバックが適用されます）。すでに CLOSED の場合は停止して、今回の作業のために再オープンするか、クローズせずにコメントするか、別の issue を対象にするかを尋ねます。インラインで作成したばかりの issue ではスキップします。ラベルは作成時に設定済みです。

4. コミットメッセージをドラフトする — issue のタイトルと差分をもとに、Commit message format と Naming anchor に従って作成します。コミットがベースより先行している状態でワーキングツリーがクリーンな場合は、Commits already on the branch に従います。新しいコミットは作成せず、ステップ8をスキップします。

5. issue クローズコメントをドラフトする — How-to-test rules を使って作成します。ship する前に Check evidence and reuse を適用し、既存の証拠を確認して、不足している、または無効になったチェックだけを実行します。実際の結果とその出所をドラフトに記載します。issue の各 Acceptance criteria を、自動テスト、またはブラウザーで確認できる動作については対象ポリシーが求めるモードでのブラウザー実行によって検証し、受け入れ基準の検証結果をドラフトに記載します。ユーザーが延期を承認しない限り、未達の基準があれば ship を停止します。差分とリポジトリから計画が明確でない場合は、不足している情報を尋ねてから続行します。

   ドラフトを提示する前に、Authorship policy に基づいて帰属表示を除去し、環境ファイルまたはキーが変更されている場合は Env parity policy の検証を実行します。

6. ドラフトをユーザーに提示する — 書き込み操作を行う前に承認を待ちます。個別に3回確認するのではなく、次の内容をまとめて一度に確認してください。

   • 既存の issue：コミットメッセージとクローズコメント。
   • インラインで作成した issue：新しい issue のタイトル、本文、カテゴリ／状態ラベル、コミットメッセージ、クローズコメント。承認後、まず issue を作成し、その後コミット、push、クローズの順に実行します。 ユーザーが不在の場合は、下書きを提示して停止します。承認されていないものをコミット、プッシュ、クローズしてはいけません。

7. コミット前の安全確認 — ステージングする前に、コミット前の安全確認に記載されたすべてのチェックを適用します。

8. コミット — コミットメッセージの形式に記載された引用符付きHEREDOC形式を使用します。

9. 現在のブランチをプッシュします：

   • リモートを追跡している場合 → git push。
   • アップストリームがない場合 → git push -u origin <branch>。
   • 現在のブランチが検出されたデフォルトブランチの場合：プッシュする前に停止し、別途確認します。手順6の承認はこのプッシュには適用されません。ユーザーが不在の場合は、コミットをプッシュせずに残し、クローズをスキップします（クローズコメントではプッシュ済みのコミットを参照する必要があります）。レポートの「ユーザー対応が必要」に両方を記載します。
   • クローズする前にプッシュの反映を確認します。エラーのない終了コードであることと、状態の読み取りに従い、対象の宛先に対する git ls-remote のSHAがローカルのコミットと一致することを確認します。ローカルの状態だけでは不十分です。プッシュが拒否された場合（non-fast-forward、認証の期限切れ）は、クローズを中止します。

10. イシューをクローズします — チェックの証跡と再利用が、プッシュされた内容と実行者を引き続き網羅していることを確認します。不足または無効になったチェック、あるいはリポジトリで必須のゲートを再実行します。失敗した場合はクローズを中止します。QAの下書きに実際のSHAとブランチを記入し、一時ファイルに書き込みます。クローズする前にコメントを投稿し、読み戻して確認します：

    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を報告し、クローズ未完了のままにします。再試行時は、未完了の操作のみを再開します。「クローズ済み」とするには、返された状態がcompletedである必要があります。

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（またはワークスペースのトラッカーにおける完了状態）— レポートに記載