pr-feedback-quality-gate

PR フィードバックの品質ゲート

PR にレビュー フィードバック、マージコンフリクト、未完了のチェックがある場合、または修正後に状況を監視する必要がある場合に使用します。

ワークフロー

1. まず PR の状態を確認します。コメント、レビュー、マージ可能性、チェック、ブランチ、ローカルのワークツリーの状態を調べます。無関係なローカル変更は PR に含めないでください。
2. メインのチェックアウトがダーティな場合、リモートより遅れている場合、または別のエージェントが使用中の場合は、レビュー修正やコンフリクト解決に分離したワークツリーを使用します。
3. 安全な範囲で最小限の修正を行います。元のバグに関する不変条件と、main で新たに導入された上流の構造を維持してください。
4. まず範囲を絞った検証を実行し、続いてリポジトリで必須のゲートを実行します。このリポジトリでは pnpm guard を含めてください。変更したファイルに応じて、パッケージの型チェック、ビルド、テストを追加します。
5. コミットまたはプッシュの前に、ステージ済みまたは提案中の差分を読み取り専用でクロスレビューします。ファイル編集と、Git の書き込みコマンドや調整コマンドは禁止します。
6. クロスレビューは証拠として扱い、絶対的な権威とは見なしません。差分、リポジトリのルール、ユーザーの目標、または検証結果に根拠がある指摘のみを受け入れます。スタイル上の好み、広範なスコープ拡大、安全性や所有権の境界と相反する提案は、優先度を下げるか却下し、その理由を簡潔に記録します。
7. 受け入れたブロッカーが残っている場合は修正し、検証を再実行してレビューを繰り返します。検証が通過し、受け入れたブロッカーがなくなってから、コミットしてプッシュします。

監視の頻度

• レビュー中、またはチェックが失敗している場合：速やかにブロッカーを解消できる頻度で確認します。
• PR に問題がない、または承認済みでマージ待ちの場合：約 12 時間ごとに確認します。
• PR がマージされた場合：CI、リリース、回帰の兆候を軽く毎日確認する程度に減らし、依頼がない限りコード変更は停止します。

報告

PR の状態、実施した作業、クロスレビューの判定、受け入れた指摘または却下した指摘、実行した検証、プッシュしたコミット、理由を添えて省略したチェック、残っているリスク、次のステップを必ず報告してください。