パイプラインがミラー用リポジトリに直接書き込んでいた事故
今回やったこと
自動処理の作業先を間違えると、単なる未追跡ファイルの増加では終わらない。origin/main を追従するためのミラー用チェックアウトへ画像生成レッグが prompts.json を書き戻し、未追跡の入力をそこへ残していた。ミラーは作業場所ではないため、そのファイルはPRにもならず、同期処理の前提を壊す。
この問題に対して、生成した本文はIssue側を正本として扱い、通常のチェックアウトへ復元した内容を書かない経路へ変更した。さらに repo_guard で書き込み先を検査し、許可する作業場所を /tmp やworktreeに限定した。記事では、作業先の境界を文章だけでなくコードで守る考え方をまとめる。
ミラーと作業場所を分ける
ミラーの役割は、origin/main の現在地を各処理へ届けることだ。ここでブランチを切ったりファイルを書いたりすると、追従用のチェックアウトが作業中の状態になり、自動pullの前提を失う。未追跡ファイルは見た目には小さなゴミでも、生成物の正本がどこにあるか分からなくなる。
画像生成では、PNGのように機械上で一時的に扱う生成物と、PRへ入れるべき入力契約を分けた。prompts.json はIssue本文から復元できるため、メインチェックアウトへ保存しない。画像は別のドレイン処理が後から扱える前提だが、入力の正本はIssueに固定する。この差を曖昧にしないことが重要になる。
origin/main ──> ミラー（読み取り中心）
│
└─ 書き込み禁止
origin/main ──> 一時worktree ──> 生成・検証・commit・PR
Issue本文 ──> prompts.json の正本
書き込み経路を安全弁にする
repo_guard は、実行時のパスを見て許可範囲外なら処理を止める。これにより、プロンプトの復元や生成スクリプトが誤ってミラーへ書き込む経路を、運用者の注意力に依存せず検出できる。書き込み先が危険な場合に処理を続けないことが、後から未追跡ファイルを探すより安い。
この設計では、失敗しても画像依頼が消えるわけではない。Issueのラベルを残したまま受け皿へ戻し、後続の画像処理が再試行できる。自動化は成功率だけでなく、失敗時にどこへ戻れるかまで設計して初めて安全になる。
実装ステータス
実装済み。主な実装は scripts/lib/repo_guard.py と scripts/zashstudio_image_gen.py。画像生成、入力の正本、PRに入るファイルを同じ場所へ集めない構成にしている。
更新履歴
- 2026-08-23: 初稿
訂正履歴
なし。