当時の開発ログを見返しながらのメモ。
p-kernel の開発は、この夏に2回長く止まっている（7/12〜8/12 と 8/14〜9/2）。自分がだらけると止まる。
なので 9/3 から、AI が自分で起動して開発を進める仕組みを作った。人間がサボっていても止まらないように。
■初日に5回死ぬ
最初は1時間ごとに起動する形。朝の1回目は疎通確認だけで成功。ところが続く回が次々とすぐ死ぬ。
原因は、シェルで変数や $?、for ループを使うと、毎回「実行していいですか？」の確認が出ること。無人なので誰も答えられずにそこで止まる。
docker exec ... which gcc; echo "rc=$?" → 45秒で死亡
AI への指示書の一番上に「シェルの書き方（ここで既に5回死んでいます）」という節ができた。
さらに、クラウドの定期実行が枠を食い尽くして夕方に全部止まる。
自宅の小さなサーバーのタイマーから直接起動するように変えて、深夜 0:30 と 3:30 の2回、1回最長3時間に。
■引き継ぎのメモ「バトン」
毎回起動する AI は前の回のことを何も覚えていない。
なので「バトン」というメモを1枚置いて、最初に読んで最後に書き直す決まりにした。中身は、今どこまで進んだか、次に何をするか、次の回がハマりそうな罠。
面白かったのは、AI が前の回の申告を鵜呑みにしなかったこと。数字を計算し直したり、自分の統計の計算ミスに気づいて直したり、「言葉が強すぎる」と主張を弱めたり。見張り役のスクリプトの誤報を見つけてバトンに書き残していたこともあった。
■「欲張らない」で失敗
最初の指示書には「1回で1つの小さな前進だけ。欲張らない」と書いていた。質を守るつもりで。
実際は1回3〜7分で帰ってくる。6時間の枠のうち使ったのは12分（3%）。欲張らなさすぎ…
翌日に書き換え。
・1つ終わったら次に手をつける
・1つ片付くたびにログに書く（最後にまとめて書くと、途中で死んだとき全部消える）
・終わりの20分はバトンを書くために空けておく
・バトンに「作業キュー」を積む（やることが1つしか書いてないと、それが終わった時点で帰る）
■作る回と、確かめる回
p-kernel には前から「作った人と確かめる人を分ける」決まりがある。自分で書いたコードを自分で「検証した」とは言わない。
無人開発でも同じにした。作った回はバトンに「実装完了・監査待ち」と書いて終わり。別の回が差分を読み直して、テストを自分で走らせて、壊せないか試す。
どちらも同じ AI なので限界はあるけど、それも書いておく。回をまたいだこのやり方を指示書に書き込んだのは、少しあとの 9/19。
※リポジトリ: https://github.com/monyuonyu/p-kernel
※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。