01v699/20
「直すたびに版を上げる」ルール誕生
- 何が起きていたか
- それまでは開発途中の版（LG1.10.68）に直接手を入れ続けていて、版番号が変わらなかった。
- どう直したか
- AutoDev LG を 1 回直すたびに版番号を 1 つ上げ、ZIP で保存するルールに。v69 がその最初の版。
- その結果
- どの run がどの版で走ったかを、あとから必ずたどれるように。版番号が 150 を超えているのは、このルールのせいです。
「版番号インフレの始まり。」
02v769/21
1 週間ぶりの PASS
- 何が起きていたか
- loop16 では、設計役が画面の「タイトル入力欄」を設計に書き忘れ、テストは入力欄を推測で扱って落ちた。テストの中で、差し替えた関数が自分自身を呼び続ける無限ループも起きていた。
- どう直したか
- 設計の見本に入力欄を入れ、テストの中の自己呼び出しを見つけるチェックを追加。
- その結果
- 次の loop17 が 9/21 に PASS。9/14 以来、1 週間ぶりの成功。
「入力欄のないタスクボードは、さすがに使えない。」
03v869/23
同じファイルを延々と読み直す病
- 何が起きていたか
- ワーカーが正しいファイルを書き終えたあとも、同じ 3 つのファイルを約 50 回見直し続け、作業回数の上限で止まっていた。
- どう直したか
- 原因は、会話が 12 手ほどで自動要約されること。要約が「まだやることがある」と勘違いしたメモを書き込み、ワーカーはそちらに従っていた。要約が始まるまでの長さを 12 → 32 に延ばした。
- その結果
- 書き終えたら素直に終わるようになり、ムダな読み直しが減った。
「メモを取りすぎて、やることを見失う。」
04v1019/24
「テストの方が間違っている」を認める
- 何が起きていたか
- 直近 20 回の PASS は 3 回（15%）。失敗 17 回のうち 13 回は、正しい実装でも通らない、間違ったテストが原因だった。それまで一度作ったテストは変更できなかった。
- どう直したか
- 人間の承認を得て方針を変更。条件つきで、間違ったテストだけを別のモデルに作り直させ、さらに別のモデルが点検してから差し替える仕組みを追加。
- その結果
- 翌 9/25 は taskboard で 4 回 PASS（v101・v103・v105・v108）。
「採点表が間違っていたら、採点表を直す。」
05v1149/26
同じ答えが 2 回出たら、すぐ別の手
- 何が起きていたか
- loop59 では、診断が一字一句同じ答えを繰り返し、修理を 8 回・約 90 分続けて、それまで通っていたテストまで壊した。2 時間 56 分で人間が止めた。
- どう直したか
- 人間の要望で、同じ結果が 2 回出たら、すぐに回避策に切り替える仕組みを追加。
- その結果
- 同じところをぐるぐる回るムダな時間が減った。
「同じ話を 2 回したら、話題を変える。」
06v117・v1189/26
3 回連続 PASS を達成
- 何が起きていたか
- テストを直すための指示文に同じテストを何度も貼っていて、最大約 6.9 万トークンに膨らみ、モデルが読める長さ（65,536）からあふれていた。さらに v114 で入れた「設計の部分修正」は、自分のバグで一度も成功しない状態だった。
- どう直したか
- 指示文を 85 KB → 6.4 KB に圧縮し、部分修正のバグも直した。v118 ではレビューの答えの小さな抜けを補う仕組みも追加。
- その結果
- v117 で loop63 が PASS、v118 で loop64・loop65 も PASS。taskboard で 3 回連続 PASS を達成。
「直すための仕組みに、直すべきバグがあった。」
07v1309/27
最後の砦、gpt-oss-120b 加入
- 何が起きていたか
- 作り直しや点検には「作った本人とは別のモデル」が必要だが、INVADERS の inv10 ではその別モデルが尽きた。
- どう直したか
- 人間の要望で、3 つ目のモデル系統として gpt-oss-120b（63.4 GB、GPU 5 枚に分けて載せる）を追加。出力の速さは Flash-Next の約 2 倍。
- その結果
- テスト作成の合格率 73%（モデル成績表より）。loop69・loop70 では、ほかのモデルが通せなかったテスト作成を gpt-oss-120b が通した。
「控えに、大物を置く。」
08v134 → v1409/28
WSL が消えて、戻ってきた
- 何が起きていたか
- 開発環境の WSL（Windows 上の Linux）が丸ごと消えた。
- どう直したか
- 人間の判断でいったん Windows ネイティブ版（v134）に移植したが、長い文脈で llama-server がかなり遅く不採用。WSL を作り直して戻った（v140）。
- その結果
- 作り直した WSL で loop67 が PASS（約 79 分）。環境の作り直しは成功。
「引っ越したけど、元の家に戻った。」
09v141〜v1439/28〜9/29
MTP で 79 分 → 54 分
- 何が起きていたか
- taskboard を 1 回作るのに 1 時間半近くかかり、1 日に試せる回数が限られていた。
- どう直したか
- MTP（複数トークン予測）を各モデルに入れた（v141・v142）。さらに本番のリクエストを録って再生し、速さの設定を総当たりで詰めた（v143）。
- その結果
- taskboard の所要時間が loop67 の 79 分から loop68 の 54 分に（v142）。
「GPU は 1 枚も増やしていない。」
10v144・v1459/29
最速 38 分の PASS
- 何が起きていたか
- loop69・loop70 が NOT PASS。loop69 は、テストが選択欄の値を書き換えるだけで、選んだときの処理を動かしていなかった。loop70 は、設計で KeyError と決めた場面で、テストが ValueError を期待していた。
- どう直したか
- 画面操作には、アプリの処理を実際に動かす手順（ボタンを押すなど）を必須に（v144）。設計と違うエラーを期待するテストは「テスト側の間違い」と判定して直すように（v145）。
- その結果
- loop71 が約 38 分で PASS。taskboard の最速記録。
「値を書き換えても、選んだことにはならない。」
+v1509/29
おまけ：直したら、別のところが壊れた
設計図の抜けを点検する仕組みを入れた（v150）。ところがその副作用で、INVADERS の inv26 では設計図から「画面を描く部分」が抜け、Qwen3.8-27B・Gemma-4-26B-A4B-it・gpt-oss-120b の 3 モデルともテスト作成で止まった。次の直し方は、方針を決めてから取りかかる。
「モグラたたき、継続中。」