Knowledge that survives the session. セッションを越えて残る知識。
Every decision, research note, and working state lives in a central store outside your repo.
Banto injects it at the start of every session and saves it again at the end, so a /clear or a
compaction never loses your context. Once the store grows large (1,471 documents in the current
example), the search stack takes over. It keeps searching even at zero hits, so even the cheapest model
reaches the right section in under a millisecond.
決定・調査・作業状態は、すべて repo の外の中央ストアに置く。Banto がセッション開始時に注入し、
終了時に保存するため、/clear や自動圧縮でも文脈を失わない。ストアが育つと（現在の実例で
1,471 文書）、検索スタックが働き始める。0 件のときも止まらず探し続けるため、いちばん安いモデルでも
1 ミリ秒未満で目当てのセクションに届く。
What accumulates, and how it comes back何が貯まるか、どう再注入されるか
The store is an external memory, one per project. It accumulates decisions, research, and working state, then recalls them automatically at the next session start. The same store that saves the record also restores it.ストアは、プロジェクトごとに 1 つ持つ外部メモリだ。決定・調査・作業状態を貯め、次のセッション開始時に自動で思い出す。保存するストアが、そのまま復元も担う。
Without a store, everything built up in a conversation vanishes on /clear or auto-compaction. Next session, you explain it all again.ストアがなければ、会話で積み上げた内容は /clear や自動圧縮で消える。次のセッションで、同じ説明をまた繰り返す。
Before / after困りごとと解決
The session ends. Memory drops to zeroセッションが終わる。記憶はゼロになる
- why a decision was made is lost決定の理由が消える
- the same research gets redone同じ調査をやり直す
- the same explanation, every session毎セッション、同じ説明を繰り返す
The store remembers. The next session continuesストアが覚えている。次のセッションは続きから始まる
- decisions and research persist決定・調査が残る
- restored automatically at session start開始時に自動で復元
- no re-explaining説明のやり直しなし
How it comes backどう戻ってくるか
One store persists; sessions come and go. Session 1 works, then runs /clear. The store keeps everything from that session. Session 2 opens already restored.ストアは 1 つ、セッションは入れ替わる。セッション 1 が作業して /clear を実行する。そのすべてをストアが保存する。セッション 2 は、復元された状態で始まる。
The re-injection is not manual. Banto hooks into six lifecycle events, including SessionStart (the event that fires when a session begins), so save and restore never need a human step. The full mechanics are on the mechanism page.
この再注入は手動ではない。Banto は6 つのライフサイクルイベントに hook する。その 1 つが SessionStart（セッション開始時に発火するイベント）で、保存と復元に人の一手を挟まない。仕組みの詳細は mechanism ページに譲る。
What's inside中身
Each project gets one folder, in a fixed layout that any tool can read. Shared knowledge is flat and author-tagged. Personal state is namespaced per author.プロジェクトごとに 1 フォルダを持ち、どのツールからも読める決まった構成にする。共有知識は階層を持たず、ファイル名に作成者名が入る。個人の状態は、作成者ごとの名前空間で分離する。
| Folderフォルダ | What goes in何が入るか | When it's usedいつ使うか | Scope区分 |
|---|---|---|---|
| decisions/ | design-decision log (one decision, one file)設計の決定ログ（1 決定 = 1 ファイル） | when you ask "why is it this way" later「なぜこうなったか」を後から引くとき | shared共有 |
| docs/research/ | external research findings外部調査の結果 | searched first, so the same research never runs twice次の調査の前に検索し、同じ調査を繰り返さない | shared共有 |
| docs/knowledges/ | promoted, durable knowledge昇格させた恒久ナレッジ | fixed once, referenced every session何度も効く知見を固定し、毎セッション参照 | shared共有 |
| docs/specs/ | specifications (output of the spec skill)仕様書（spec skill の出力） |
to settle the design before implementing, then referenced during the build実装前に設計を固め、実装中に参照 | shared共有 |
| workspaces/<author>/ | per-workspace state and tasksワークスペースごとの状態とタスク | switching work, resuming where you left off作業の切替・続きからの再開 | personal個人 |
| learnings/<author>/ | personal lessons個人の教訓 | injected automatically at session startセッション開始時に自動で注入 | personal個人 |
| sessions/ | checkpoints (session-state snapshots)チェックポイント（セッション状態の要約） | saved before /clear or compaction, read at the next start/clear・圧縮の前に保存し、次の開始時に取り込む |
ephemeral一時 |
| meta/ | notes for operating the store itselfストア運用のメタ情報 | health checks and the folder map健康診断・フォルダ地図の確認 | shared共有 |
…_<github>.md) — the team shares it階層なし・ファイル名に作成者（…_<github>.md）— チームで共有
personal個人under <author>/ — working state never collides<author>/ 配下 — 作業状態が衝突しない
ephemeral一時gitignored, never committed — this machine, this moment onlygitignore・コミットされない — このマシンのその場限り
Setup never stops the work. An unregistered project still works immediately. Records land in a temporary local home (~/ai-context-local/<project>/, same layout) until bootstrap registers a private GitHub store and pulls the local content in. That migration only adds. It never destroys anything.
準備で作業を止めない。未登録のプロジェクトも即座に動く。まず仮のローカル置き場（~/ai-context-local/<project>/・同じ構成）に記録し、bootstrap が非公開の GitHub ストアを登録した時点でローカル分を取り込む。移行は追加のみ。
Search across every store全 store を横断して検索する
Store Search is how the AI finds things in your accumulated records. It stacks three methods: plain grep, a full-text index, and a loosened retry. When one method comes up empty, Store Search moves to the next automatically. A search never dead-ends.Store Search は、AI が蓄積した記録から目当てを探し出す仕組みだ。索引なしの grep・全文索引・条件を緩めた再検索という 3 つの手段を重ねる。どれかが 0 件でも、次の手に自動で進む。検索が行き止まりにならない。
*The test: 10 questions of the form "which file says X?," asked against the real store. The score counts correct file paths, checked automatically. The 3 runs scored 7, 8, and 10 (mean 8.3). "Effort" here is the reasoning budget given to the model: raising it buys deeper thinking at the cost of time and money.
*テストの中身：実際の記録に対して「◯◯と書いたファイルはどれか」を 10 問出題する。正しいファイルを言い当てた数を機械採点する。3 回の結果は 7 点・8 点・10 点（平均 8.3）。なお effort とは、モデルに与える思考量の設定である。上げるほど深く考えるが、時間と費用も増える。
- The index is cross-project by construction. One index spans every project store on the machine. Any session, in any project, reaches every accumulated decision and research doc with a single query.
- 索引は、構造として横断的だ。マシン上の全プロジェクトの store を 1 つに束ねる。どのプロジェクトのセッションからでも、蓄積した全ての決定・調査に 1 クエリで届く。
- Japanese works out of the box. The trigram tokenizer matches CJK (Chinese, Japanese, Korean) text directly, so no morphological analyzer is needed.
- 日本語はそのまま動く。trigram トークナイザが CJK（日本語・中国語・韓国語）の文字を直接マッチさせるため、形態素解析器は不要だ。
- The stack is built for where it matters most: stores grown to the 1,500-document scale, searched by cheap models. Below that scale, the grep layer alone carries the load. The stack adapts by itself.
- 真価が出るのは、記録が 1,500 文書規模に育った store で、安いモデルに検索させる運用のときだ。それ未満の規模では、grep 層がそのまま受け持つ。スタックが自分で適応する。
How it's layered3 層構成
A tiny router directs each question to the layer built for it. No session ever dumps the whole store into context.小さなルーターが、質問ごとに向くべき層へ振り分ける。store 全体をコンテキストへ丸ごと投入することはない。
0Routerルーター
A tiny guide injected at session start: census questions go to the ledger, content questions go to Store Search.セッション開始時に注入される小さな案内。数える質問は台帳へ、内容の質問は Store Search へ。
1Ledger台帳
The ledger is a deterministic, complete list of every document. It exists to count, audit, and confirm what's there. This is where index-based navigation is measured to actually win.台帳は、数える・監査する・存在を保証するための決定論的な全数リストだ。索引をたどる探索は、ここでこそ実測で勝る。
2Store SearchStore Search
Store Search is a full-text search over every store's sections. It ranks results with BM25, a standard relevance-ranking algorithm, and returns exact line ranges. The agent reads just the matching section, never the whole file.Store Search は、全 store を対象にした全文セクション検索だ。BM25（定番の関連度ランキング手法）で順位付けし、該当する行範囲を返す。エージェントは全文でなく、セクションだけを読む。
Measured, not assumed実測で選んだ
Three real-run measurements back this design. A strict index-only test used 10 "which file says X?" questions, path-matched against the real store. Haiku went from 4/10 before the redesign to a best of 10/10 after. The fix combined four changes: automatic OR-relaxation on a 0-hit query, decision-weighted ranking, checkpoint exclusion from the index, and a --related follow. A separate 3-model × 3-effort sweep (18 runs, 2026-07-04) found that effort barely moves the score. Haiku at its lowest setting (9, 8) lands within noise of opus 4.8 at its highest (9, 9). At published June 2026 pricing, haiku runs at 1/5 opus 4.8's rate and 1/10 fable 5's. Every run, including the configurations that didn't make the cut, is in the evidence report.
この設計は 3 種類の実走行で裏づけた。索引のみに絞った厳しいテストでは、実際の store への「◯◯と書いたファイルはどれか」を 10 問・パス一致で採点した。haiku は、再設計前の 4/10 から再設計後は最高 10/10 まで改善した。効いたのは、0 件クエリの自動 OR 緩和・decision 重み付けランキング・checkpoint の索引除外・--related 追走の 4 点だ。別枠の 3 モデル × 3 effort 総当たり（18 走行・2026-07-04）では、effort はほぼ効かなかった。haiku の最低設定（9 点・8 点）が、opus 4.8 の最高設定（9 点・9 点）と誤差の範囲で並んだ。2026 年 6 月公表の単価では、haiku は opus 4.8 の 1/5、fable 5 の 1/10 で動く。採用しなかった構成も含む全走行は実測レポートにある。
Git and team scalegit と複数人運用
The rule is one line: the index is never committed.規律は 1 行：索引は絶対にコミットしない。
- Canonical vs. derived.正本と派生物。 Git manages markdown only. The index is a local cache with zero information value. You can delete it and lose nothing. The next session rebuilds it in 2.5 seconds.git が管理するのは markdown だけだ。索引は情報価値ゼロのローカルキャッシュだ。消しても何も失わない。次のセッションが 2.5 秒で作り直す。
- No shared database.共有 db なし。 SQLite's classic weaknesses never arise here: concurrent writers, corruption on network filesystems. Each machine builds its own index from the markdown it has. The only writer is the local rebuild.sqlite の古典的弱点（同時書き込み・ネットワークファイルシステム上の破損）は、構造上発生しない。各マシンが、手元の markdown から自分の索引を作る。書き込むのはローカルの再生成だけだ。
- Teammates never see it.メンバーは意識しない。 New members clone the repo, open a session, and their index is already there. There's no setup step, no shared infrastructure, and no need to know SQLite.新メンバーは、clone してセッションを開くだけで自分の索引を持つ。準備の手順も、共有インフラも、sqlite の知識も要らない。
- Access control stays in git.アクセス制御は git のまま。 Your index is built only from markdown you already have legitimate access to. Repository access decides the sharing granularity. The index itself can never widen that access.索引は、自分が正当に持つ markdown からしか作られない。共有の粒度は、リポジトリのアクセス権が決める。索引がその粒度を広げることは、決してない。
Register a new project新規プロジェクトを登録する
A brand-new repo works immediately in a temporary local store. Moving it to the shared central store, or pinning it local on purpose, is one sentence away.新規 repo は、一時的なローカル store の上ですぐに動き始める。中央 store へ上げるのも、意図してローカルに留めるのも、一言で済む。
A new repo is never blocked on setup. Records land in ~/ai-context-local/<project>/ (the same layout as the central store) until you decide otherwise.
新規 repo はセットアップで止まらない。まず ~/ai-context-local/<project>/（中央 store と同じ構成）へ記録し、決めるまではそのままそこに置かれる。
aLocal by default既定はローカル
A new repo is not yet on the shared GitHub store. It accumulates non-destructively in the temporary local home above.新規 repo はまだ GitHub の中央 store には乗っていない。上記の一時ローカル置き場に、非破壊で貯まっていく。
bMove it to the central store中央 store へ上げる
Say "I want this on GitHub" or "set up the store." That triggers bootstrap, which registers a private GitHub store and pulls the local content in.「GitHub に上げたい」や「store を作って」と言うと、bootstrap が発火し、非公開の GitHub store を登録してローカル分を取り込む。
cOr pin it local, on purpose意図してローカル固定
Say "keep this repo local-only," and local pins it. No GitHub store is ever registered for this project.「この repo はローカルだけで」と言うと local が固定する。この project 用の GitHub store は一切登録されない。
dAn old in-repo .ai-context/ still works旧 .ai-context/ もそのまま活きる
A repo that still carries an old in-repo .ai-context/ gets it copied into the central store automatically at session start. That copy only adds. Nothing is destroyed.repo 内に旧 .ai-context/ が残っている場合は、セッション開始時に自動で中央 store へコピーされる。コピーは追加のみで、既存のものは壊さない。
The harness holds the knowledge. You hold the vision.知識はハーネスが持つ。方針はあなたが持つ。
The store and its search are one of Banto's flagships, alongside the toolset that drives it and the deterministic mechanism underneath.ストアと横断検索は、Banto の目玉の 1 つだ。それを動かす道具一式や、その下で働く決定論的な仕組みと並ぶ。