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 at the end, so a /clear or a
compaction never costs you the thread. Once the store has grown enough — 1,471 documents in the current
example — a fail-open search stack lets even the cheapest model find any of it in under a millisecond.
決定・調査・作業状態は、すべて repo の外の中央ストアに置く。Banto がセッション開始時に注入し、
終了時に保存するため、/clear や自動圧縮でも文脈を失わない。ストアが育つと（現在の実例で
1,471 文書）、0 件でも止まらない検索スタックが働き、いちばん安いモデルでも 1 ミリ秒未満で目当てのセクションに届く。
What accumulates — and how it comes back何が貯まるか — どう再注入されるか
An external memory, one per project. It accumulates decisions, research, and working state, and recalls them automatically at the next session start — the same store that saves also restores.プロジェクトごとの外部メモリ。決定・調査・作業状態を貯め、次のセッション開始時に自動で思い出す。保存するストアが、そのまま復元も担う。
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 and clears, the store keeps everything, session 2 restores automatically.ストアは 1 つ、セッションは入れ替わる。セッション 1 が作業して /clear を実行し、ストアが保存、セッション 2 が自動で復元する。
The re-injection is not manual. Banto hooks into six lifecycle events (SessionStart among them), so save and restore never require a human step — the full mechanics are on the mechanism page.
この再注入は手動ではない。Banto は6 つのライフサイクルイベント（SessionStart など）に hook し、保存と復元に人の一手を挟まない。仕組みの詳細は mechanism ページに譲る。
What's inside中身
One folder per project, a fixed layout 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 gates 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, additive only.
準備で作業を止めない。未登録のプロジェクトも即座に動く。まず仮のローカル置き場（~/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 — and when one comes up empty it moves to the next automatically, so 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; score = correct file paths, machine-checked. The 3 runs scored 7, 8 and 10 (mean 8.3).
*テストの中身：実際の記録に対して「◯◯と書いたファイルはどれか」を 10 問出題し、正しいファイルを言い当てた数を機械採点。3 回の結果は 7 点・8 点・10 点（平均 8.3）。
- 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 text directly, no morphological analyzer needed.
- 日本語はそのまま動く。trigram トークナイザが CJK（日本語・中国語・韓国語）の文字を直接マッチさせるため、形態素解析器は不要。
- Built for where it matters most: records grown to the 1,500-document scale, and cheap models doing the searching. Below that scale the grep layer simply 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, so 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台帳
A deterministic, complete document ledger for counting, auditing, and existence guarantees — measured to be where index-based navigation actually wins.数える・監査する・存在を保証するための決定論的な全数台帳。索引をたどる探索が実測で勝つのはここ。
2Store SearchStore Search
Full-text section search over every store, ranked by BM25, returning exact line ranges — so the agent reads the section, not the whole file.全 store を対象にした全文セクション検索。BM25 で順位付けし、行範囲を返す。エージェントは全文でなく、セクションだけを読む。
Measured, not assumed実測で選んだ
Three real-run measurements back this design. A strict index-only test (10 "which file says X?" questions, path-matched against the real store) took haiku from 4/10 before the redesign to a best of 10/10 after — the fix was 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 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 — 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 — concurrent writers, corruption on network filesystems — never arise: each machine builds its own index from the markdown it has, and the only writer is the local rebuild.sqlite の古典的弱点（同時書き込み・ネットワークファイルシステム上の破損）は構造上発生しない。各マシンが手元の markdown から自分の索引を作り、書き込むのはローカルの再生成だけ。
- Teammates never see it.メンバーは意識しない。 New members clone, open a session, and have their own index — no setup step, no shared infrastructure, no SQLite knowledge required.新メンバーは clone してセッションを開くだけで自分の索引を持つ。準備手順なし、共有インフラなし、sqlite の知識も不要。
- Access control stays in git.アクセス制御は git のまま。 Your index is built only from markdown you legitimately have — sharing granularity is decided by repository access, and the index can never widen it.索引は自分が正当に持つ markdown からしか作られない。共有の粒度はリポジトリのアクセス権が決め、索引がそれを広げることは決してない。
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 つ。それを動かす道具一式、その下で働く決定論的な仕組みと並ぶ。