polish-batch

ポリッシュの一括処理

キャプチャ、ディスパッチ、検証の3つのモードを個別に実行し、手動QAが細かな指摘へのリアルタイムな逐次対応にならないようにします。

ルール

• キャプチャ ≠ 修正。 キャプチャモードでは、プロダクトのコード、設定、コピー、アセットを変更しないでください。記入するのは、パンチリストの行、保留メモ、補足用のQAスクリーンショットのみです。「ついでに」細かな指摘を修正してはいけません。
• 帰属情報は一切付けません。コミット、PR、イシューのコメント、リリースノート、生成されたドキュメント、設定、コードコメントに、共同作成者、AI、ツールの帰属情報を追加したり、残したりしないでください。
• 対象は見た目の修正のみ。 細かな指摘とは、動作、データ、インターフェース（関数シグネチャ、API の形状、ルート、イベント、スキーマ、プロパティの契約）を変更しない、純粋に視覚的または文言上の表面の修正です。これらに触れるものは細かな指摘ではありません。スライスとして /to-tickets に差し戻すか、エージェントがすでに完了とした作業のバグであれば、そのイシューから /qa-escape に送ってください。動作変更を「ちょっとした修正」と言い換えようとする試みは、停止の合図として扱ってください。内容を明示し、細かな指摘として記録することを拒否し、適切な別の経路に回してください。
• デザインソースから逸脱しているページの対応は /pixel-audit の担当です。 パンチリストは散在する細かな指摘をまとめます。Figma のノードや参照画面に体系的に一致させる必要があるページは、依頼に「ポリッシュ」と書かれていても、必ず /pixel-audit に回してください。
• ディスパッチ時にリファクタリングや周辺の変更を行わないでください。 各項目は個別に修正し、一目で明らかに正しいと判断できる状態にしてください。そうでなければ、細かな指摘ではありません。周辺コードの整理、名前の変更、「ついでの改善」は禁止です。
• どこでも Project Matrix の完全な PROJECT-CODE を使用してください。あるプロジェクトの規約、トークン、コンポーネントを別のプロジェクトに混在させてはいけません。
• 細かな指摘がどのプロジェクトに属するか不明な場合は、確認してください。ユーザーが不在の場合は、最も可能性の高いコードの末尾に ? を付けて Needs user に記載してください。報告された指摘を破棄したり、PROJECT-CODE が確認される前にディスパッチしたりしてはいけません。
• Project Matrix がない（スタンドアロンの単一リポジトリへのインストール）場合は、リポジトリ名からコードを1つ導出し（大文字、ハイフン区切り）、一貫して使用してください。
• ディスパッチを開始するのは、ユーザーが明示的に指示した場合のみです。それまではキャプチャを続けてください。 自分の判断でキャプチャからディスパッチに進んだり、検証から出荷に進んだりしてはいけません。検証後は /code-review に続いて /commit-push-close または /commit-push-pr を提案し、そこで停止してください。
• 再オープンされた行は残してください。 検証に失敗した行は open に戻し（reopened として）、次のキャプチャ／ディスパッチのサイクルに引き継いでください。何も黙って破棄してはいけません。
• サブエージェント：独立した作業にはローカルのレーンを自動的に割り当ててください。クラウドエージェントは使用しないでください。ディスパッチ時にレーン数を伝え、各レーンの完了時に報告してください。レーンにはディスパッチされたタスクを割り当てられますが、マージと最終判断はメインセッションが担います。
• 各フェーズの移行時に Stage / Found / Next / Needs user を出力してください。各フィールドは1行ずつにします。

パンチリストの成果物

仕様ごとにパンチリストを1つ作成し、<artifacts-root>/specs/qa/<SPEC-ID>-punchlist.md に保存します。<artifacts-root> は、*.code-workspace ディレクトリがあればそのディレクトリ、なければコンテキストごとのルート（リポジトリのルートにある GLOSSARY-MAP.md。旧形式では CONTEXT-MAP.md）、それもなければリポジトリのルートとします。

<SPEC-ID> は仕様（PRD）または親イシューの識別子です（例：SPEC-142）。仕様がない場合は日付をキーにして specs/qa/qa-YYYY-MM-DD-punchlist.md とします。ファイル名を決めるためだけに、親となるトラッカー項目を作ってはいけません。

Markdown の表を1つ作成します。

# Punch List — <SPEC-ID>

Zero attribution: never add or leave co-author, AI, or tool attribution in any output.

| # | PROJECT-CODE | Where | Wrong → Right | Shot | Status |
| - | ------------ | ----- | ------------- | ---- | ------ |
| 1 | ADMIN-WEB | Settings › Billing header | "Recieve invoices" → "Receive invoices" | shots/admin-web-01.png | open |
| 2 | API-SVC | 429 response `message` field | "To many requests" → "Too many requests" | (no shot — text only) | open |

• Where — 正確な対象箇所：画面 › 領域 › 要素、またはレスポンスのフィールド／文字列キー。
• Wrong → Right — 現状 → 意図する状態を1行で記載します。検証時の受け入れ基準になります。
• Shot — specs/qa/shots/ 以下のパス、または文字どおりの (no shot — text only)。スクリーンショットがないことを理由にキャプチャを止めてはいけません。
• Status — open → dispatched → verified または reopened。

モード

要求されたモードのみを実行します。デフォルトは capture です。他のモードではなく、その手順と出力形式を読み込みます。

• capture — references/capture.md：QA 成果物のみを追記します。
• dispatch — references/dispatch.md：新たに明示的な dispatch 指示を受けた後、範囲を限定した修正をまとめ、変更前のコンソール証拠を記録します。
• verify — references/verify.md：タスクの報告後、対象範囲の差分と配信結果を比較します。証拠が不足している場合は保留のままにします。

リポジトリ横断

仕様の細かな指摘はすべて、仕様ごとに1つのパンチリストに記載します。リポジトリごとのファイルは作成しません。一方、dispatch は PROJECT-CODE ごとに行います。対象プロジェクトごとに1ファイル、1つの dispatch タスクです。

出力

選択したモードの参照ファイルに記載された更新内容を出力します。Verify は助言として次に推奨するスキルを1～3件提示して終了し、出荷を開始することはありません。

完了条件

• パンチリストが <artifacts-root>/specs/qa/<SPEC-ID>-punchlist.md（または日付キー付きのパス）に存在し、報告された項目がすべて行として記載されているか、Held に設定されているか、明示的に対象外へ振り分けられている
• capture：初期状態と最終状態のステータスおよび差分から、この実行で書き込まれたのが QA 成果物のみであることが確認できる。既存の変更はそのまま保持されている
• dispatch：更新内容にユーザーの明示的な指示が引用され、引き継いだすべての行の Status が dispatched になっている
• verify：dispatch 済みの各行が、証拠付きで verified、失敗により reopened、または未実施の確認内容を明記して dispatched のいずれかになっている