Review Gate

Review Gate

現在の成果を次工程へ渡してよいか、契約と直接証拠で判定する。初回は異なる根本原因を探す観点を先に揃え、全適用観点を一巡してから指摘を一括で返す。一件のblockerは探索を終える理由にしない。

適用と資料

独立reviewerの役割分離とGate固有の質問は依頼元の契約に従う。Storyの開発Gateではdevelop-user-storyが条件ID・役割・開発状態を管理する。

実装を含むPR／Gateレビューではmanifest schemaとvalidatorを使う。状態、resource、外部作用、複数成果物を持たない純粋な文言確認など、単純な確認だけは省略できる。「USや変更影響へ限定する」という依頼は省略条件ではない。JSONのfield、stage別command、旧形式との互換性はschemaを正本とする。

観点が決まったら確認方法の該当節を読む。手法やmanifestを理由に確認対象を増やさない。

判断の境界

初回に未確認と明示した証拠が後で得られた場合、後から追加された契約、修正が生んだ回帰、現在範囲外の改善は見逃しに含めない。問題が修正前からあったかを根拠で区別する。

頻度が低くても、現在契約を破る別の根本原因の確認は必要である。一方、同じ原因を入力値・file・browser・時刻・操作順ごとに分割した全組合せ、一つの事実への重複証拠、影響しない観点の再探索は求めない。件数を完全性の指標にしない。

現在の条件にない監視、fallback、設定、診断、後工程の内部実装を先取りしない。証拠作成のための製品UI追加や、Journeyの失敗を新しい挙動で置き換えることも同じ境界を越える。これらをPLANへ必須項目として予約することも過剰計画である。

1. 対象を固定する

深い探索より前に、依頼、台帳、PLAN、実差分などの一次情報からReview Inputを作る。

• Gate質問、対象成果、対象の同一性を確認する方法。
• 条件ID、現在の公開契約、変更したsurface・状態・出力・外部作用。
• 通常導線と実在する例外導線、変更経路が影響し得る製品全体の不変条件。
• 対象外と、既存の後工程へ渡す場合のGate・owner・handoff契約。

PRのtarget_artifactsは実差分の全fileと一致させる。PR以外も判定対象の実装、文書、外部状態を列挙する。Briefで各成果物を適用surfaceへ対応付けるか、理由付きで対象外へ分類し、未確認fileを暗黙に落とさない。

mainはBrief作成前にReview Inputの全fieldを正本へ照合する（正本照合Gate）。既知の指摘や改善案から逆算しない。validatorは構造の一致を検査するが、正本への意味上の忠実性は保証しない。

Review Input、Brief、manifestは一時成果物とし、修正cycleが閉じるまでbaselineとして保持する。Story、PLAN、EVIDENCEへreview履歴、case台帳、一時path、branch、commit SHA、worktree、sessionの識別子を保存しない。

2. 観点と適用範囲を確定する

次の二方向を辿り、現在の成果を別の根本原因から壊し得る観点を導く。

1. 条件と観測結果からproducerへ遡る。
2. 変更surface、共有状態、外部作用からconsumerと観測結果へ進む。

現在契約、到達する因果経路、探索を止める境界を示せる候補だけを適用にする。契約上必要な配線・状態遷移の欠落も、その欠落を確認する経路として扱う。既存handoffは渡す値・状態の境界まで確認し、後工程の内部へ入らない。契約や到達経路に入らない候補は理由付きで非適用とし、追加作業へ昇格させない。必要な一次情報を取得できなければ未確認としてHOLDする。

観点は契約、状態保持、resource lifecycle、非同期処理、失敗復旧、統合、認証・分離、証拠の保証範囲などから、変更に適用するものだけを選ぶ。各観点に質問、契約、因果経路、停止境界、代表例、最小の観測方法を持たせる。同じ根本原因の値違いを新観点にしない。観点間の接続は実在する境界だけを確認する。

因果経路は入口origin、仕組みmechanism、出口observationの確認点（coverage point）に分ける。同じowner・開始・前進・失敗・退役経路はまとめ、ownerや退役経路が異なる状態・resource・非同期処理は別のmechanismとして残す。一例の成功で別ownerまで確認済みにしない。

一覧を深い探索前に別の文脈から一度見直し、上流追跡、下流追跡、独立原因の不足確認を記録する。独立reviewerを使える場合はこの見直しを任せ、mainが重複を統合する。レビュー対象、観点、確認点の境界をここで固定する。

編集ドメインでclock、scheduler、queue、retry、resource lifecycle、serializationを変更した場合は、適用先の.reference/にある対応source、consumer、test、修正履歴を対象capabilityに絞って確認する。

適用範囲Gate

判定質問・対象・契約・対象外が固定され、二方向の候補に未確認がなく、全成果物が適用surfaceまたは理由付き対象外へ一度ずつ分類されていることを確認する。各適用観点には因果経路と停止境界、後工程には正本に既存の名前付きhandoffが必要である。manifestを使う場合はscope stageも通す。

3. 全観点を探索する

固定した各適用観点を未着手から調べ、問題候補は指摘として確定せず別に保持する。観点と各coverage pointを成立、違反、未確認へ分類し、直接根拠を付ける。一点でも違反なら観点は違反、違反がなく未確認が残れば観点は未確認とする。

証拠は実行して観測、静的に確認、既存証拠を照合を区別し、その保証範囲を示す。test件数や「全体を読んだ」という自己申告で代用しない。見た目・聞こえ方・操作感など人の判断が必要な結果と、mute設定・時刻・routing・保存値など機械で観測できる事実を分け、後者を利用者の回答で代用しない。

reviewerが別の根本原因の不足を見つけた場合はmainへ返す。mainが現在契約への適用性を確認し、必要な場合だけ適用範囲Gateへ戻って観点を加える。単なる追加例では再開しない。

探索完了Gate

次が揃うまで修正指示や最終NO-GOを送らない。

• 全適用観点と全確認点に状態・直接根拠があり、集約状態が一致する。
• 因果経路、探索境界、観測方法と、実在する観点間の接続境界を確認している。
• 全問題候補が観点へ結び付き、対象成果は探索開始時から変わっていない。
• 全reviewerが完了している。続行不能なら残りを引き継ぐか、未確認の理由を残している。

manifestを使う場合はdiscovery stageを通す。main自身が内容を確認し、reviewerの完了申告やvalidator成功だけを完全性の根拠にしない。

4. 候補を採用し、一括で返す

指摘採用Gate

探索完了後に、各候補について次を判断する。

1. 到達可能な反例、破られる現在契約、一次根拠があるか。
2. 現在Gateの成立可否を変えるか。
3. 現在scopeと権限で、契約を変えずに直せるか。
4. 修正が必要最小限に収まり、新しい製品挙動や後工程を先取りしないか。

全候補を分類し、同じ根本原因を統合する。manifestを使う場合はcandidate stageを通し、採用した全指摘を一つの修正指示へまとめる。レビューだけの依頼では成果物を編集しない。

5. 修正後は影響した観点を再確認する

初回の観点と完了証拠をbaselineに、変更した公開状態・出力・外部作用から影響経路を特定する。影響した観点だけを再開し、影響しない観点は契約・境界・証拠の前提が不変である根拠を添えて引き継ぐ。

Gate質問や現在契約、対象成果やsurface、利用側までの因果経路・探索境界、独立観点の集合が変わった場合だけ、適用範囲から作り直す。文言、見た目、結果記録、進捗、review toolの変更は、それらを変えない限り全面レビューを発生させない。

修正前から存在した別観点の問題を見つけた場合は、初回レビューの見逃しとして扱う。一件だけ追送せず、観点選定と探索のどちらが不足したかを特定し、同じ不足から残り得る問題を一度まとめて確認して報告する。これを無制限の再探索へ広げない。

validator／schemaの更新だけで、開始時の版で成立したレビューを失効させない。現在成果に具体的な未確認を示す新しい根拠がある場合だけ、該当観点を再開する。

判定とhandoff

最終報告は、Gate質問へのGO／NO-GO、適用範囲Gate・探索完了Gate・指摘採用Gateの結果、根本原因ごとの指摘、未確認と残リスク、既存handoffへ残す責務を短く示す。指摘がなければ「なし」とする。未解決blockerも合否に必要な未確認もなく、直接証拠でGate質問へYesと答えられる場合だけGOにする。

StoryのGate・Journeyの再開と状態更新はdevelop-user-storyへ結果を返す。その他は依頼元の既存handoffに従う。レビュー担当が新しい製品挙動を考案・実装しない。