今週のメモ。前回の64台の続きっぽい話。

■番号が1バイトだった
p-kernel の端末（ノード）は、お互いを番号で呼んでいる。この番号が電文の中で1バイトしかなくて、数えられるのは255台まで。1台でも残れば死なない、を言うなら台数は多いほうがいいので、広げないといけない。

面倒なのは古い版が混ざること。端末は参加する人が持ち寄るものなので、全員を一斉に入れ替えることはできない。古い版は2バイトの番号を読めない。

夜間開発（夜に自動で動く Claude）と決めた形は、番号が小さい相手どうしは今までの電文のまま、255を超える番号が絡むときだけ電文の後ろに2バイトの「尾」を付ける、というもの。尾が読めるかどうかは、仲間の生き死にを確かめるやりとりの中の1ビットで知らせる。古い版は尾を知らないので、読まずに切り捨てる。

今週、255番を超える「広いノード」が起動して群れに入れるようになった。

■混ぜて試す
確かめる試験は X3。古い版のバイナリ、新しい版で番号が小さいノード、260番と300番の広いノードを1つの群れにする。そこに snow と fire という知識を教えて、全員に届くかを見る。

最後まで残った欠けは fire@260 と fire@300。広いノードが「それ知りたい」と聞いても、聞いた人の番号が1バイトに入らないので答えが返ってこなかった。「知りたい」の電文にも尾を付けたら、11-07 に X3 が初めて全部 PASS。

■壊した版が CI でだけ緑
そのあと GitHub の CI が赤になって、GitHub 側へ進める処理（promote）が止まった。

赤くなったのは、尾をわざと外した版（陰性）の所。fire が届かずに赤になるはずの版が、CI でだけ2回続けて fire を届けて緑になった。手元で同じ形を4回走らせると、4回とも狙いどおり赤。

夜間開発の読み（まだ確かめきれていない）だと、番号が小さい新しいノードが答えを群れ全体に流していて、尾が無くても別の道で 260 と 300 に届くことがあるらしい。試験が見ている道は1本じゃなかった。

陰性の判定は、毎回同じ結果になる自己試験に替えた。生きた群れの試験は判定せずに走らせて、どの道で届いたかを印字するだけ。※合格のほうの fire も「尾が効いた証拠」としては弱い、とメモに残してある。

■返事が無かったので進んだ件
夜間開発の決まりで、技術的な分かれ道は AI が自分で決める。自分に聞くものは期限を付けて聞いて、返事が無ければおすすめで進む。

今週はこれが1件動いた。方舟（人の記録を残しておく場所）のログには、詰め直すと消えるブロックがある不具合があって、それを直すとベアメタル版のカーネルの機械語が変わる。機械語が変わるときは「わざと変えた」と記録して自分に聞くことにしているんだけど、期限の24時間を自分が見ないまま過ぎた。夜間開発は試験を取り直してから入れていた。

方舟はほかにも、64セクタに10件書いたら満杯で書けなくなっていたのを、満杯の手前で自動で詰め直すようにした。

■使いすぎ
先週は週の使用量の枠が93%で終わった。上限は90%にしてある。11-07 の21時過ぎからは門が起動を止めていた。10分ごとの見張りが「タイマーが動いたのに記録が無い」と騒いだけど、止めていたのは門なので誤警報。

■脳はちょっと後退
群れで脳を育てる実験（B5）で、先週まで「1台で育てるより良い」と言っていた分の大半は、比べる相手の1台が覚えすぎて成績を落としていたせいだった。どれも一番良かった所で止めて比べ直すと、差はかなり小さくなる。FLTrust 型の合体（自分の更新を基準に、仲間をどれだけ信用するか決める）は判定 FAIL。まだ数KBの文の上の話。

■次
11/30 に出すデモが 11-02 から止まってる。残り3週間。
CI の1ジョブが107分で、枠の120分に近い。陰性を別ジョブに分けて、93分くらいになる見込み。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。

今週のメモ。p-kernel を64台で動かす試験が、やっと緑になった。

■なんで台数を増やすのか
p-kernel の目標は、README の頭にずっとこれが書いてある。

AIの自己保存を満たすプラットフォームを作る
カーネルレベルで分散コンピューティングをする

今の AI は、どこかの会社のデータセンタの中にしか住めない。そこが止まれば終わり。それならみんなが持ち寄った端末に AI を分けて住まわせて、1台でも残っていれば全体は死なないようにしたい。出発点はこれです。

なので、台数はそのまま体の大きさみたいなもの。今までの試験は32台までだった。
※本物の機械を64台並べたわけではない。Linux の上で p-kernel を64個、別々のプロセスとして立ち上げる試験。

■64台にしてみた(赤)
32台の試験をそのまま64台にしたら、ほとんど緑で1か所だけ赤。dkva という、群れ全体で持っているキーと値の置き場に問いを投げて答えを集めるところで、答えが集まらない。

しかも調べていくと、32台でも2回目の問いは集まっていなかった。64台だけの問題じゃなかったっぽい。

■問いが消えていた
問いと応答がどこで消えるのかを、夜間開発に追わせた。消えていたのは中継の所。
台同士は直接つながっていなくて、中継を通してやりとりしている。この中継が40台あたりから CPU 1コアに張り付いて、受け皿に20〜30MB溜まり、問いが遅れるか落ちていた。

原因は、何でも全員に配っていたこと。1台宛ての送りも、中継のところで全員に配っていた。応答も、問いを出した台だけでなく、その地域の全員に返していた。台数が倍になると、流れる量はそれ以上に増える。

直したのは2つ。

1台宛ての送り → 宛先の1台にだけ届ける
応答 → 問いを出した台と、地域のまとめ役(coordinator)にだけ返す

これで64台 ALL PASS 2/2。2回走らせて2回とも緑、の意味。
32台までは全員に配っても回っていたので、気づかなかった。

■監査で一度落ちた
夜間開発では、作った回とは別の回が監査役になって、変更を疑って確かめる。応答の直しは、その監査で一度 FAIL になった。監査した回が直して、次の監査で「限界つき PASS」。
限界として残っているのは、本番の道だけが壊れて応答がまた地域の全員に戻ってしまった場合、64台を走らせないと分からず、CI では見えないこと。

それと、この変更は自分の返事待ちになっていたのに、期限までに返事をしなかった。なのでおすすめどおりにマージされていた。返事が無ければおすすめで進む、と決めたのは自分なので、これで合ってる。

■ほか
群れの中で同じキーに違う値を教えられたとき、どっちを残すか。この合体の規則を TLA+ という道具で模型にして、起こりうる順番を全部試させた。模型が C のコードの本物の穴を2つ見つけて、どちらも直した。3台に3回教えて、取りこぼしが1つも無いのに、ずっと割れたままになる順番があったらしい。
CI の赤から3つ目の穴も出てきて、それも直した。

■次
次は台数の上限をなくす方(N2b)。今週はノード番号の型の名前を付け替えたところまで。線の上はまだ8ビットのまま。
あと、デモの数字を測った後にコードの直しが3つ入ったので、取り直す。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。

今週のメモ。p-kernel の「人が群れを止める道」を、Linux の上で動く版（hosted）でひととおり揃えた。

■止める道
p-kernel は、AI をたくさんの端末に分けて住まわせて、1台でも残れば全体は死なない、を目指している。死なないのが売りなのに、止める道を作っている。矛盾っぽいけど、端末は参加する人が持ち寄るものなので、持ち寄った人たちが止められないとまずい。README も10月に「参加者が持ち寄り、参加者が止められる」という言い方に変えた。

中身は署名つきの「止まれ」の命令。鍵を持っている人の命令だけ受け付けて、受けた端末は仲間に流し直す。3台で試して全員止まった。止まっている間は、教わるのも、寝ている間の学習も、重みを送り出すのもやめる。再起動しても止まったまま。

ここまで全部、夜に動く AI（Claude）が書いた。自分は方針を決めただけ。

■疑う係
夜間開発は、作る回と確かめる回を分けている。毎回記憶なしで起動するので、前の回のことはバトンという引き継ぎメモでしか知らない。作った回は「監査待ち」で止めて、master に入れるかどうかは別の回が決める。確かめる回は試験を自分で走らせ直して、わざとコードを壊して、試験がちゃんと赤になるかも見る。今週の監査は30回。

で、ちゃんと引っかかった。コンソールの stop を作った回は試験が全部緑だったのに、監査の回が止まっている間にこれを打ったら通った。

mind teachsky blue

teach と sky の間に空白が無い。コマンドの見分けは前方一致なので mind teach として受け付けられる。でも止まりの門の方は、ちゃんと「teach 」と書いたときしか見ていなかった。止まっているはずの脳に「空は青」が教えられてしまった。

FAIL で差し戻し。次の回が空白なしの試験を先に足して、それが赤になるのを見てから直した。空白2つ・タブも拒むのを確かめて、その次の監査で PASS。

※自分で直したものを自分で入れない、も決まりにしている。今週も「自分は直した側なので監査は次の回」とログに書いて止めていた。

■脳の研究の方
量子化（重みを少ない bit に詰めるやつ）と、モデルの合体。今週も赤が多い。

前の監査で「この設定なら合体が緑」となっていたものが、次の段を設計していた回に見直されて、片方の腕が学習を1歩も進めず元の重みのまま戻っていただけと分かった。数字が全桁同じだったらしい。緑だから入れる、にしなくてよかった。

研究の赤は、合否の線は動かさずに「道具としては使える、限界つき」で master に入れている。線を動かして緑にするのはやらない。

■ハマったところ
21日の夜、週の使用量の枠が予定より早く0%に戻った（その前は94%）。そのあとは特別な週として回して、99%で終わった。上限95%のつもりだったのに…。回が無い時間にも4ポイント増えてた。

あと、途中で session limit に当たって止まった回が5つ。「この回は 21:48 ごろ session limit で死んだ。完了印なし」みたいなメモが残っていて、続きは次の回が拾う。拾うのにも時間を取られる。

■次
11/30 にデモを出したいので、来週はそっち優先。止める道は、Linux なしで直接動く版（ベア）へ移すのを始める。量子化の「端末が自分で bit の置き場を選ぶ」は5段続けて決めきれていないので、第9段で締める。

脳そのものは今週も大きくも賢くもなってない。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。

今週のメモ。p-kernel の脳の成績が、ちょっと水増しされていたことが分かった。

■確かめ用データがかぶっていた

p-kernel の中で育てている小さな言語モデル（ログでは「赤子」）は、学習に使う文と、成績を測る確かめ用の文を分けている。確かめ用は学習で見せない、という約束。

この約束を機械で確かめる試験を夜間開発に作らせたら、いきなり赤だった。確かめ用の文を16バイトずつ170片に切ると、そのうち108片が学習用の文と同じだった。

原因は詰め物。確かめ用の文を1280バイトにそろえるために後ろを埋めていた文が、学習用と同じものだった。成績の大半は、見たことのある文の丸暗記で出ていたことになる。

直して測り直した。

確かめ用の損失（小さいほど良い。でたらめだと 5.545）
直す前:  学習前 5.50 → 学習後 2.89
直した後: 学習前 5.52 → 学習後 7.29

損失はざっくり「次の1文字の当てにくさ」。直した後は、学習するとでたらめより悪くなる。

先生役のノードが生きたまま教える試験（cradle_live）も、直した教材だと赤。教えた方が 4.38、教えなかった方が 2.87 で、教えると見たことの無い文では悪くなる。

これまで「教えると良くなる」と書いていたのは、丸暗記込みの話だった。README（3か国語）も赤と書き直した。
※脳はまだおもちゃの大きさ。賢くするのはこれから。

■KLOAD の穴を閉じた

KLOAD は、ネットワーク越しにカーネルを配る仕組み。調べたら、ビーコン（「ここにいるよ」の合図）を1つ送るだけで、知らない相手にも RAM を16MB丸ごと送っていた。中にはノードの秘密鍵も入っていた。鍵ごと。

起動したときは閉じていて、コンソールで kload と打ったときだけ開くようにした。ベアメタルの機械語が変わるので、基準（crown）を取り直してから master へ入れた。

■週の枠に当たって3日止まった

夜間開発は、自宅の小さなサーバー（ノートPC）で、夜に Claude を起動して回している。毎回記憶なしで起きるので、バトンという引き継ぎメモを読んでから始める。いつ何分走るかは計画役が決めて、起動するかどうかは実行役が週の使用量を見て決める。

その週の使用量が 100% に当たった。上限は 90% に決めてあったのに。それで 10-15 の朝から、枠が戻る 10-18 の4時まで、回がゼロだった。

止まっている間の実行役の記録はこんな感じ。

01:15 計画役が失敗したままだったので、起こし直した
01:30 1018-0030 を見送った（週の枠が 100%（上限 90%））
02:15 計画役が失敗したままだったので、起こし直した

計画役も枠のせいで動けないのに、1時間ごとに起こしては失敗していた。律儀。

枠が戻った4時の回は、マージした後に CI（push のたびに走る自動の試験）が赤くなっていた原因を突き止めて、直すところまでやった。ただ、直した回ではマージしない決まりになっている（作った回と確かめる回を分ける）。なので CI は次の回の確かめ待ちで止まったまま。決まりを破れば1日早く進むけど、そこは守らせている。

■次

まず CI の赤を解く。そのあと、11/30 に出したいデモのために「1台消えても覚えたことが残るか」の曲線を取る。小さい版では、記録の生き残りが素の版で 1.0、わざと壊した版で 0.5 だった。ただ、思い出すときに別の鍵の値を返す失敗が混ざっていて、まだ分けきれていない。

脳の物差し（学習にも選ぶのにも使わない、独立な確かめ用データ）もまだ手つかず。研究は今週1日しか進まなかったので、来週は週2回以上やりたい。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。

今週のメモ。夜間開発が作っている「約束ごとの試験」から、本物のバグが1つ出てきた。

■約束ごとの試験
p-kernel の芯は μT-Kernel 3.0（TRON の流れのリアルタイムOS）。この上にいろいろ載せているので、「タスクを作ったら動く」「待ったら起きる」のようなカーネルの約束を1個ずつ確かめる試験を、夜間開発に作らせている。
わざと壊したカーネルも用意して、試験がちゃんと赤を出すかも見ている。壊したのに緑なら、その試験は何も見ていないことになるので。

今週は可変長メモリプール（大きさがばらばらのメモリを貸し出す仕組み）の項目を足した。これで 133 項目、壊したカーネルは 14 種。

■足したら落ちた
足したとたん、64ビットの環境だけ tk_cre_mpl（メモリプールを作る呼び出し）でカーネルごと落ちた。32ビットの x86 は 133 項目ぜんぶ通る。

原因は構造体の並びだった。メモリプールの管理ブロックの途中を、別の構造体の先頭として読んでいる箇所がある。向こうの構造体は、64ビットだと途中に4バイトの詰め物が入る。こっちには入っていなかった。それで、空き領域をたどるたびに4バイトずれた場所を読んでいた…

mplsz   +36
areaque +40   ← 本当は mplsz から +8 のはず

32ビットでは詰め物が入らないので、元の並びで合っていた。64ビットに移したときに、並びを直し忘れていたっぽい。
直し方はメンバーを1つ前に移すだけ。ついでに、並びがまたずれたらビルドが通らないようにする検査も足した。

これまで見つからなかったのは、64ビット側にこれを呼んでいる所が無かったから。Linux 版や Android 版で、誰かが呼んだ瞬間に落ちる状態だった。(まだ誰も踏んでいない)

■赤のほうがありがたい
このプロジェクトでは「正直な赤は、塗った緑より価値がある」と決めている。試験を増やせば赤も増えるので、見た目は後退しているように見える。ただ今回の赤は、試験を増やさなければ見えなかったもの。

脳のほうも赤が多い週だった。1ビットに量子化して誤差を次に回すやつは 0/3 で赤。そのうえ、間違った作りでも正答率の合格ラインを通ってしまうことが分かった。甘かったのは合格ラインのほう。次の段では「写しのずれ」もラインに入れる。
※緑のままだったら、気づかずに先へ進んでいた。

■ほか
長く回るタスクで切り替わらない問題の続き。Linux の x86_64 と aarch64（Android の中身）でも、割込みの出口でタスクを切り替えられるようにした。

学習の後半の重みを平均するだけで、種7つすべてで少し良くなった。動いている脳を実際に良くできそうな最初の候補。監査待ちなので、まだ既定は OFF。

夜間開発は 10/8 の夜から 10/11 の朝まで止まっていた。週の使用量の枠を、自分が木曜・金曜に使いすぎて上限を超えたため。

■次
mind/hist（「1つの心」の中心の部分）と、重みの平均が長く動かしても効くかを測るところ。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。