Procedure
実装/スクリプト/パイプライン/設定/インフラを書いた・変えた・配線したら、完了宣言の前に頭からこれを潰す。
- 並行/競合 — 同時実行・連投・定時ジョブの重複でrace、git index.lock競合、二重deploy/書き込みは起きないか。→ mkdirロック(待ち+stale奪取)・冪等upsert・直列化で防ぐ。
- 失敗時の挙動 — 通信失敗・ファイル欠落・部分データ・外部API仕様変更・クォータ超過で、安全に止まるか / データ消失・フラップ(消えて復活)しないか。→ fail-safe(破棄して停止)・前回成功値のキャッシュ復元・「失敗なら何もしない」。
- 冪等性 — 同じ入力で再実行してバイト同一/無害か。二重登録・重複生成しないか。
- 境界/空入力 — 0件・空文字・最大件数・想定外形式・新旧フォーマット混在(片方しか対応してないと崩れる)。
- セキュリティ — 秘密値・実ホームパス混入、owner/remoteガード、push先が自分のprivate repoか。
- 自己修復/可観測性 — 失敗が次サイクル(cron/reminder)で再浮上して回復するか。ログ/Discord通知/フラグで気づけるか。
- 実検証(必須) — 「動くはず」で止めない。実際に走らせる/全分岐をテスト/期待件数vs実件数/ファイルmtimeで実体確認してから報告(捏造防止)。
- 配布物・特典(zip/テンプレ/スクリプトを他人に渡す時)は「受け取った初心者の手順」を頭から実走:クリーン環境に展開→READMEどおりコマンドを順に実行→最後まで通るか。「雛形だから」「骨格だから」は免罪符にならない(2026-07-11 Brain iOS特典: コード0行のproject.ymlが
xcodegen generate即死・全行コメントのshを売って本人指摘で発覚)。売り物は自分のマシン前提を捨てて検証する(前提ツールの有無・PATH・アカウント固有値)。
- 配布物・特典(zip/テンプレ/スクリプトを他人に渡す時)は「受け取った初心者の手順」を頭から実走:クリーン環境に展開→READMEどおりコマンドを順に実行→最後まで通るか。「雛形だから」「骨格だから」は免罪符にならない(2026-07-11 Brain iOS特典: コード0行のproject.ymlが
- 単純化/過剰抽象 — LLM/Codex生成コードは大げさになりがち。もっと少ないファイル・関数・新概念でできないか、既存パターンに素直に乗っているか、Dead code・不要コメント・関係ない変更が混じっていないか。「1000行の複雑」より「100行の明快」。削れるなら削ってから完了にする(重い時は
/simplify・code-simplifieragentへ委譲)。
各項目で「該当する弱点」を見つけたら、軽微でも一旦挙げ、直すか・見送るか(理由つき)を判断する。
適用例: 自律ビルド後の出力検証(旧 autonomous-build-verify から吸収)
大規模実装・スクレイパー・フルスタック生成の完了宣言前は、7観点に加えて具体的に:
- ダミーデータ残存:
grep -r "dummy\|placeholder\|TODO\|FIXME\|lorem\|example.com" src/で0件を確認 - 壊れた画像/URL:
<img>src の実在、スクレイパー出力の期待件数 vs 実件数(大きく下回れば問題として報告) - デプロイ状態:
git status(コミット漏れ)→ push 済み → 本番URLで動作確認。コミットだけでは本番に反映されない - スクレイパーUA: Googlebot UA は多くのサイトでブロックされる。Chrome UA を使う
- owner確認:
git remote -vが自分のprivate repoか、APIキーが環境変数経由か、.env が .gitignore に入っているか
Pitfalls
- 「ビルド通った」「pushした」だけで完了にしない=それは検証の一部でしかない。挙動の境界・失敗時を必ず見る。
- サブエージェント/Codexの「やった」報告を鵜呑みにしない。git diff・mtime・実行で実体確認してからレビュー。
- フラップ系(一時失敗で全消去→次回復活)は「動いてる時は見えない」ので特に意識して探す。外部fetchを使う生成器は要注意。
- 「全部潰した」と軽々しく言わない。無人系に絶対は無い。代わりに三層(①安全に止まる②自己修復③気づける)を示す。
Verification
完了報告に必ず次を含める:
- 潰した(実在バグ→修正+検証結果) / 既に堅牢(確認済み) / あえて見送り(理由・軽微) の3区分の短い表。
- 実際に走らせた検証コマンドと実結果(件数・200・diff等)。
- 「①安全に止まる②自己修復③気づける」がどう担保されているか1行で。
ユーザーが「漏れ全部潰してる?」と聞く前にこの表が出ていれば成功。聞かれたら運用失敗とみなし、次から発火を早める。