設計

CLI と GUI は別プロセスとして、同じ store.sqlite を同時に書く。それでも壊れないのは、各書き込みを丸ごと1トランザクションにして SQLite に直列化させ、失敗したら丸ごと巻き戻すから。変更は change_feed に1行残り、GUI のウォッチャがカーソルで変わったぶんだけ読み直して画面に映す。

複数のプロジェクトを扱うと、AI は隣の文脈を拾って記憶を汚す。プロンプトで「触らないで」と頼んでも守られる保証はない。Amenbo は .amenbo でプロジェクトに束ね、外へ手を伸ばす操作を CLI 自体が out_of_reach で断る。お願いではなく、仕組みで区切る話。

第1回で「探索が約2倍軽い」と実測し、第2回で「ストアはグラフ」と示した。今回はその読み方。タスクに追いつくときは、つながった数件だけを索引でたどる（O(result)）。着手できるか・決定が現行かといった状態は保存せず、エッジからその場で導出する。だから一覧・カード・着手ガードがズレない。

AI エージェントのためのタスク管理 Amenbo の作りを、個別技術に入る前にざっと見渡す。GUI と CLI が同じ Rust の Core を呼び、データはローカルの単一 SQLite に入る。プロジェクトのフォルダは目印だけを持ち、ストアはタスクと決定のグラフになっている。

Amenbo という、AI エージェントのためのタスク管理アプリをリリースしました。第 1 回は、なぜこれをつくったのか。AI エージェントを使い込むほど壊れていく文脈の問題と、人間のタスク管理とは分けて、ローカルの閉じた環境に置くという棲み分けの話です。

crofty は『人が入れて最初の設定をしたら、あとはその人の AI が回す』ことを前提にした CLI です。操作する相手にエージェントを含めると設計はどう変わるか。発見性・状態と次の一手・勝手に書き換えないという方針を、実際のコマンド出力とともにまとめます。

静的サイトの多言語対応は「本文を翻訳する」だけでは終わりません。本文・固定文言・データの 3 種類に分け、それぞれに合った入れ物で持つ設計を、Hugo / crofty を例にまとめます。画像が /en/ から 404 になる罠も。