リリースPR状況把握
読み込み中…
読み込み中…
読み込み中…
行は重大度でまとめてあり（公開済み・未マージ → 軸A判定なし → 判定不能 → ストア未公開 → 健全）、ヘッダのソートはそのまとまりの中だけで効きます。異常が下に沈まないようにするためです。
「異常のみ」は赤の 2 つ（公開済み・未マージ / 抑制期限切れ）に絞ります。抑制中（青紫）は異常ではないので既定でも絞り込みでも消しません。
「進行中PRあり」は「進行中PR」列に 1 件以上出ている行に絞ります（列と同じく軸A・軸B の両方を見ます）。他の絞り込みとは両方を満たす行だけが残ります。
「最終観測」は軸A スナップショットの生成時刻です（repo ごとの観測時刻は契約に無いため、全行で同じ値になります）。
「担当候補」は自己申告の担当者、無ければ release ブランチの最終コミット者。どちらも無いときは取得不能と出します（誰かに丸めません）。
「進行中PR」は軸A の観測（open_pr_numbers）と軸B の収集（open な PR）の両方を出し、どちらに居たかをバッジで区別します（2 つの収集は正常でも最大 24.5 時間ずれるので、片方にしか無い PR が出ます）。
「状態」は軸B との食い違いを解決した後の判定です。どちらの軸を採ったかを状態の下に出します（「軸B で解決」と出ている行は、軸A は別の判定を出していました）。
「mgre-auth」は、develop のコアの版が必要とする MGRe-Auth の版と、案件サーバーの本番（master）を比べた結果です（develop も併記）。必要な版はコアと MGRe-Auth の git から計算したもので（version_list/auth_compat）、エンタープライズ案件の独自の上書きやプランごとの view の違いは見ていません。案件がどの機能を使っているかは分からないので、機能を使う場合だけ足りないものは「機能次第（要確認）」に出します。
「異常のみ」は赤の 2 つ（公開済み・未マージ / 抑制期限切れ）に絞ります。抑制中（青紫）は異常ではないので既定でも絞り込みでも消しません。
「進行中PRあり」は「進行中PR」列に 1 件以上出ている行に絞ります（列と同じく軸A・軸B の両方を見ます）。他の絞り込みとは両方を満たす行だけが残ります。
「最終観測」は軸A スナップショットの生成時刻です（repo ごとの観測時刻は契約に無いため、全行で同じ値になります）。
「担当候補」は自己申告の担当者、無ければ release ブランチの最終コミット者。どちらも無いときは取得不能と出します（誰かに丸めません）。
「進行中PR」は軸A の観測（open_pr_numbers）と軸B の収集（open な PR）の両方を出し、どちらに居たかをバッジで区別します（2 つの収集は正常でも最大 24.5 時間ずれるので、片方にしか無い PR が出ます）。
「状態」は軸B との食い違いを解決した後の判定です。どちらの軸を採ったかを状態の下に出します（「軸B で解決」と出ている行は、軸A は別の判定を出していました）。
「mgre-auth」は、develop のコアの版が必要とする MGRe-Auth の版と、案件サーバーの本番（master）を比べた結果です（develop も併記）。必要な版はコアと MGRe-Auth の git から計算したもので（version_list/auth_compat）、エンタープライズ案件の独自の上書きやプランごとの view の違いは見ていません。案件がどの機能を使っているかは分からないので、機能を使う場合だけ足りないものは「機能次第（要確認）」に出します。
読み込み中…
既定の並びはブロッカーの深刻度順 → ブランチの変更（実装を含む方を先に）→ 古い順です。経過日数を第一軸にしていないのは、open 40 件のうち 90 日超が 23 件（57%）あり、日数で並べると全部が赤く見えてしまうためです。
CI 失敗は黄色のままにしています。merge_state_status が UNSTABLE なのにチェックは全部 SUCCESS という実例が 7 件あり、ブロッカー系シグナルの信頼度を確認できていません。誤検知が無いと確認できてから色を上げます。
「CI 失敗」と「必須チェック未達」は別の事象なので、同じ表示にまとめていません。
「実装差分ありのみ」は状態フィルタ「すべて」と組で使ってください。祖先関係の判定は open な PR を対象にしていないため（収集側の仕様）、既定の「進行中（OPEN）」のままでは 0 件になります。サマリーの「実装差分あり（要確認）」カードのボタンは、状態を「すべて」にしてから絞り込みます。
「祖先関係」はコミットの祖先関係だけを見た結果で、内容が取り込まれていないことを意味しません。実測で、実装差分ありと判定した 8 件のうち内容が一致していたものがありました。この 3 列だけでは実害を確定できないので、いちばん強い組み合わせでも「要確認」（黄）止まりにしています（赤は「公開済み・未マージ」と「抑制期限切れ」の 2 つだけ）。
「ブランチの変更」はそのブランチが積んだ変更の性質で、統合ブランチに無い変更ではありません。実測 61 件では 72% が版数コミットだけ（グレー）です。既定では隠さず並びで後ろに置き、上のチェックボックスで絞れるようにしています。参考値の「分岐後に積んだコミット数」（ahead_by）は 3 ドット比較の値なので、件数の根拠にも並び順にも使っていません。
CI 失敗は黄色のままにしています。merge_state_status が UNSTABLE なのにチェックは全部 SUCCESS という実例が 7 件あり、ブロッカー系シグナルの信頼度を確認できていません。誤検知が無いと確認できてから色を上げます。
「CI 失敗」と「必須チェック未達」は別の事象なので、同じ表示にまとめていません。
「実装差分ありのみ」は状態フィルタ「すべて」と組で使ってください。祖先関係の判定は open な PR を対象にしていないため（収集側の仕様）、既定の「進行中（OPEN）」のままでは 0 件になります。サマリーの「実装差分あり（要確認）」カードのボタンは、状態を「すべて」にしてから絞り込みます。
「祖先関係」はコミットの祖先関係だけを見た結果で、内容が取り込まれていないことを意味しません。実測で、実装差分ありと判定した 8 件のうち内容が一致していたものがありました。この 3 列だけでは実害を確定できないので、いちばん強い組み合わせでも「要確認」（黄）止まりにしています（赤は「公開済み・未マージ」と「抑制期限切れ」の 2 つだけ）。
「ブランチの変更」はそのブランチが積んだ変更の性質で、統合ブランチに無い変更ではありません。実測 61 件では 72% が版数コミットだけ（グレー）です。既定では隠さず並びで後ろに置き、上のチェックボックスで絞れるようにしています。参考値の「分岐後に積んだコミット数」（ahead_by）は 3 ドット比較の値なので、件数の根拠にも並び順にも使っていません。
条件を指定して「絞り込む」を押してください。
1 行 = リリース PR 1 本（open / closed / merged すべて）。新しい順、最大 500 件。
該当が 500 件を超えたときは「上限で切っています」と出します（黙って切りません）。
日付はすべて UTC です（期間の絞り込みも UTC の日境界で判定します）。
「祖先関係」はコミットの祖先関係だけを見た結果で、内容が取り込まれていないことを意味しません。実測で、実装差分ありと判定した 8 件のうち内容が一致していたものがありました。この 3 列だけでは実害を確定できません（だからいちばん強い組み合わせでも黄の「要確認」止まりです）。
「ブランチの変更」はそのブランチが積んだ変更の性質です。実測 61 件では 72% が版数コミットだけ（グレー）で、既定では隠していません。参考値の「分岐後に積んだコミット数」（ahead_by）は 3 ドット比較の値なので、件数の根拠にも並び順にも使っていません。
「祖先関係」はコミットの祖先関係だけを見た結果で、内容が取り込まれていないことを意味しません。実測で、実装差分ありと判定した 8 件のうち内容が一致していたものがありました。この 3 列だけでは実害を確定できません（だからいちばん強い組み合わせでも黄の「要確認」止まりです）。
「ブランチの変更」はそのブランチが積んだ変更の性質です。実測 61 件では 72% が版数コミットだけ（グレー）で、既定では隠していません。参考値の「分岐後に積んだコミット数」（ahead_by）は 3 ドット比較の値なので、件数の根拠にも並び順にも使っていません。