# 止まった作業を毎晩検知し、進められるものだけ自動で前に進める ## これが解く問題 CI を通過したまま誰にもマージされない PR、閉じ損ねた PR、放置されたブランチ、 途中で止まった作業メモ。どれも「存在は知られているのに誰も動かさない」状態で溜まる。 よくある対策は「棚卸しリストを作る」だが、**それだけでは止まらない**。 実測した現場では `PR 20件 / ブランチ 70件` と**件数は毎日数えていた**のに、 CI 通過済みの PR が CLOSED 未マージのまま **18日間**放置され、誰も気づかなかった。 原因は3つ揃っていなかったこと: | 要素 | 棚卸しリストだけの状態 | |---|---| | **締切** | 件数は数えるが「何日止まっているか」を見ていない | | **通知** | ファイルに書くだけ。見に行かない日は誰も知らない | | **自動前進** | 人がマージするまで何も起きない | ## 設計 ### 1. 収集して経過日数を出す - PR: `gh pr list --state all --json number,title,state,isDraft,updatedAt,headRefName,mergedAt,statusCheckRollup,author` - ブランチ: `git for-each-ref --sort=-committerdate refs/remotes/origin` の最終コミット日時 - 作業メモの未完了項目: 取り消し線が付いていない行 - セッション/作業ログ: ファイルの mtime 閾値（既定3日）を超えて動いていないものだけを「停滞」とする。 ### 2. PR を状態で分類する | 分類 | 条件 | 扱い | |---|---|---| | `mergeable` | OPEN / 非draft / checks 全pass | **自動マージ** | | `ci-failed` | OPEN / checks に failure | 通知のみ | | `ci-pending` | checks が pending のまま閾値超過 | 通知のみ | | `closed-unmerged` | CLOSED かつ未マージ | 通知のみ（**再オープンしない**） | | `draft-stale` | draft のまま閾値超過 | 通知のみ | **`closed-unmerged` を自動で再オープンしないこと。** 意図して閉じた PR を機械が開き直すと、判断を奪って混乱を生む。判断は人に残す。 ### 3. 自動前進は「全pass の自作 PR」だけ マージは既存のマージ用ヘルパー経由にし、自前で `gh pr merge` を直叩きしない （head SHA 照合・マージ後の read-back 検証といった安全確認を二重に実装しないため）。 `--dry` では収集と「マージ予定」の出力だけを行い、何も変更しない。 ### 4. 通知が読まれる形にする ← ここが成否を分ける 初版は素直に全部出したところ **109KB / セッション479件** になり、 本当に行動できる 4 件（マージ可能3・閉じ損ね1）が完全に埋もれた。 **行動できるもの**と**在庫**を分ける: - **actionable**: mergeable / ci-failed / closed-unmerged / draft-stale / 未完了項目 → 1件ずつ出す - **inventory**: セッション / ブランチ → 古いだけで次の一手が無い。**件数と最古の日数だけ**の1行に畳む さらに: - サブエージェントの一時ログは親の成果物なので**収集対象から外す**（479件→187件） - ファイル出力でも在庫は各分類 20件で打ち切り、残りは「他N件」（109KB→8KB） - **actionable が0件なら、在庫が何件あっても通知しない**（毎日ほぼ同じ在庫を送らない） ## 実測結果 初回実行で CI 通過のまま 4〜8日眠っていた PR を検知: - 1件を実際にマージ - 2件は `mergeable=CONFLICTING` を検出して `merge-failed` として通知（握り潰さない） - 1件は `closed-unmerged` として判断待ちに回す ## 踏んだ落とし穴 ### テストが緑でも CI で落ちる ローカル（Windows）で 20/20 通ったのに CI（Linux）で失敗した。 パス区切り・改行コード・ホームディレクトリ依存・mtime の粒度が典型。 **両 OS で走らせること**。skip して通すのは解決ではない。 ### リポジトリ固有の規約に違反する 「全ての子プロセス起動にコンソール窓を隠すオプションを付ける」という既存ルールがあり、 新規ツールがそれに違反して CI が落ちた。 **既存の規約テストが何を強制しているか、書く前に確認する。** ### スタブは実物の出力をキャプチャしてから作る 想像で書いたスタブは**自分の誤った前提をそのまま再現する**ので、 テストが全部緑なのに実物では動かない。 別件では「標準出力に出る」と決めつけてスタブを書いたら実物は標準エラーに出しており、 テスト 6/6 緑のまま本番で 500 を返した。 API を叩く前に1回実行し、**標準出力と標準エラーを分けて**生ログを取り、それを写す。 ## 導入手順 1. 収集・分類・通知を1ファイルのツールとして書く（外部依存なしで書ける） 2. 既存の夜間バッチの最後に1回だけ呼ぶ。空キュー終了やエラー終了の経路でも必ず通るようにする 3. `--dry` で実物を1回流し、**actionable と inventory の件数比**を見る — actionable が埋もれていたら閾値や除外条件を調整してから本番化する 4. 通知先は1通に集約。全文はファイルに書き、通知にはそのパスを添える ## 判断の勘所 - **自動で進めてよいのは「検証が機械的に完了しているもの」だけ**。 CI 全pass の自作 PR はこれに当たる。コンフリクト・CI 失敗・意図的なクローズは人に戻す。 - **通知は「読まれるか」で設計する**。件数を全部出すのは親切ではなく、無視される原因になる。 - 在庫（古いブランチや完了済みセッション）は**消さずに数えるだけ**にする。 消す判断は別の仕組みに委ねる。 ---