v0.1 から v0.5.22 まで、156 日、116 のリリース。ここに書くのは機能一覧ではなく、私たちが踏んだ穴、それと引き換えに得たルール、まだ埋まっていない空白です。
データスナップショット 2026-11-01 · 数値は sync-facts と health:arch が Liri の本体リポジトリから収集
タイムラインへ移動2026 年 5 月 25 日、Liri の最初のバージョンは v0.1 でした。100 回の実質的なコミット、動くターミナル AI アシスタントが 1 つ。
最初に解こうとした問題は具体的でした——大規模モデルを本当にターミナルの中に座らせ、ファイルを読み、コマンドを実行し、コードを書き換える。Web の入力欄でチャットするだけではなく。ローカルモデルを優先したのは、個人のファイルを他人のサーバーへ送りたくないから。セキュリティ内蔵を選んだのは、それが API ではなく実際のマシンを渡されるからです。
その後の 3 か月で、能力を 1 つずつ広げました：ツール、27 のメッセージチャネル、デスクトップ、音声、ナレッジベース。8 月にはリポジトリに 4000 を超えるファイルがありました。
問題が初めて明示されたのもその頃です。2026 年 6 月 18 日のコードレビューでは、LocalHTTPService が 7200 行、ChatManager が 3263 行、テストファイル 150 個に対してソースファイル 3742 個。2 か月後、アーキテクチャ健全性の最初の採点は 10/40、グレード D で、105 個の上限超過ファイルがすべて未登録でした。
そこで分かったこと：プロジェクトを他人に引き継げるかどうかは、機能の数ではなく、穴に落ちた後にどんなルールを育てたかで決まる。
因果順に並べており、カレンダー順ではありません——期間は重なっています。
↳ 参加できること — 新しい能力を足したいとき：app/src 配下にモジュールを立て、カーネルには詰め込まない。
↳ 参加できること — 上限超過ファイルを 1 つ引き受けて分割してください（下の参加方法を参照）。
↳ 参加できること — CD01–CD07 に沿って「デッドコード候補」を 1 件確認してください。
↳ 参加できること — プッシュ前にローカルでゲートを 1 回実行（bun run ci）。赤くなったところを直す。
↳ 参加できること — カーネル境界の外にある新機能は app/src から始めればよく、カーネルに入れる必要はありません。
アーキテクチャは新しく発明したものではありません。薄いカーネル、サブシステムの境界、依存の方向、ゲートと可観測性——この組織化は OS の数十年のエンジニアリング実践から来ています。Agent 領域でここ 2 年に公開された設計パターンとエンジニアリングガイドも、ほぼ同じ問いに収束しています：階層、境界、状態、ガバナンス、評価。私たちは前者のやり方で自分たちを縛り、後者のチェックリストで自己点検します。
OS の概念 → Liri の現状
| 概念 | Liri での対応 | 状態 |
|---|---|---|
| カーネル | @openliri/kernel 独立パッケージ。外部には薄いインターフェースのみ公開し、K01–K08 のゲートで守る | 導入済み |
| サブシステム | ツール / チャネル / 記憶 / ルーティング / サンドボックス / タスク / 音声 / デスクトップ。それぞれに入口と境界 | 収束中 |
| ドライバー | プロバイダーアダプター、チャネルアダプター、6 種のサンドボックスバックエンド（Landlock / Docker / SSH / PTY / macOS / Windows） | 導入済み |
| プロセスとスケジューリング | セッション実行、PDCA、Swarm、Cron | 導入済み |
| 権限モデル | 5 層の防御線 + 承認の 4 段階（requested → presented → decided → recorded） | 外部監査待ち |
| 可観測性と監査 | イベントログ、コスト台帳、証拠台帳 | 導入済み |
| メンテナー（MAINTAINERS） | 未確立：サブシステムの owner も引き継ぎ経路もない | 空白 |
公開されている Agent の設計パターンとエンジニアリングガイドに 1 項目ずつ照らし合わせました。21 のパターンにはすべて実際の実装がありますが、うち 3 つの重要なスイッチは既定でオフです——そのため対外的には「実装あり」とだけ言い、「既定で有効」とは言いません。エンジニアリングの流れも同じ 5 段階で自己点検します：アーキテクチャ、ビルド、実行、ガバナンス、チューニング。
owner がいなければ引き継ぎ経路もありません。最も OS らしく、最も欠けている部分です。
契約の設計書はありますが、台帳 / LoopProfile が実装されたかは未確認——インターフェース安定性の約束はまだ固まっていません。
レビュー時点で約 4%。CI には 20+ 項目のアーキテクチャチェックがありますが、カバレッジのしきい値はまだありません。
正直に言うと、アーキテクチャ健全性は依然 D（10/40）、142 個の上限超過ファイルのうち 141 個が未登録、最大は今も chat モジュールです（ChatManager は 7,036 行から 2,570 行に分割済み）。カーネルはでき、境界は収束しつつあり、メンテナー制度はまだありません——これが「まだ歩き終えていない」という意味です。
入口からフィードバックまでの 8 つの機能層。エンジニアリング面では 6 層の依存ゲート（entry > ui > app > service > infra > core）で強制しています
毎月 1 行。アーキテクチャとガバナンスの変化のみを記録し、通常のコミットは載せません。
以降の毎月の更新もここに追記していきます。
このページは完了報告ではなく、招待です。3 つのこと、いずれも人手が足りていません。
Domain-first の知識ドメイン分離は設計書があり、Phase A/B/C は未実施。カーネル境界の外の機能もカーネルに入る必要はありません。
タスクを引き受ける142 個の上限超過ファイル（141 個が未登録）が分割待ち。テストカバレッジのしきい値もまだありません。
タスクを引き受ける5 層の防御線と 6 種のサンドボックスバックエンドは実装済みで、ルールのソースも確認できますが、第三者監査はまだ受けていません。これが最も欲しいフィードバックです。
監査チェックリストを見る入口：app/src/security、app/src/sandbox、app/src/permission。
脆弱性の詳細を見つけた場合は SECURITY.md に従って非公開で報告し、公開 issue を立てないでください。公開 issue は監査プロセスと範囲についてのみ扱います。
