KAUT — 信頼に基づく知識の実現

レガシーコードベースをAIネイティブにする。 KAUTは、プロジェクトの自己維持型でAIファーストなドキュメントです。つまり、文書化されていない弱いコンテキストのコードをAIエージェントが読み取れるようにする知識層です。会話の記憶ではなく、システム自体に関する知識ベースです：何をするか、どのように構造化されているか、そしてなぜか。エージェントが作業中に学んだことを生きたドキュメントに変えるので、どのセッションもゼロから始まることはありません。

依存関係ゼロのNode.js（≥ 20、24で開発）、Apache-2.0。macOSとLinuxで開発・テスト済み（CIはLinux、Node 20と24で実行）。Windowsはサポートされていません。

完全でスタンドアロンの製品。 git clone 1つでインストール完了。ハーネスを同梱のMCPサーバーに向ける（または任意のスキル/プロンプトからCLIを呼び出す）だけで動作します。オーケストレーターも、フレームワークも、サービスも、アカウントも、他にデプロイするものは何もありません。姉妹プロジェクトのTAUTオーケストレーションフレームワークと組み合わせることができます（TAUTはエージェントを駆動し、KAUTは彼らが知っていることです）が、その統合はオプションであり、依存関係ではありません。

ステータス: v0.8.1 — フルループが稼働中。 読み取り: lookup（ワンコールで準備完了の回答）は鮮度判定（マージベースアンカー、不確かなときに「新鮮」と叫ぶことは決してない）、信頼ティア、altitudeカバレッジバンドを備えています。改ざん封じ込めは、パイプライン外で編集されたものをすべて保留します。マルチリポジトリ: ワークスペースレジストリ、メンバーごとのストア、ランチャーリポジトリにアンカーされた1つのシステムストア。書き込み: レイヤードライトゲート（エージェント層の更新は直接反映、オーナーゲート層と新規ドキュメントは非同期レビューのためにドラフトとしてキューに入ります）。メンテナンス: refresh（再導出デルタバンドル）、touched（変更サイトセンサー）、digest/note（使用状況と結果のテレメトリ）。相互運用: ストアはOKF v0.2適合バーを満たし、kaut okf exportは慣用的なOKFバンドルを生成します（来歴、信頼、ライフサイクルファミリーを含む）。MCP対応のハーネスは同梱のMCPサーバーを介して接続できます。詳細な稼働内容: docs/HANDBOOK.md §16。

それが解決する問題

新しいAIセッションは毎回記憶喪失から始まります。エージェントはプロジェクトを再探索し、同じ質問を繰り返し、そして最悪なことに、最も高くつく種類の間違いを犯し続けます：コンパイルは通りテストも通るが、知る由もなかったビジネスルールを静かに破るコード。

プロジェクトの「なぜ」は通常どこにも書かれていません。KAUTはそれに居場所を与え、生かし続けます。

これはレガシーコードで最も痛みを伴います：何年もの文書化されていない決定、元の作者がいない、ビジネスルールが副作用としてしか見えない。まさにそこが、今日のAIコーディングツールが不十分な場所であり、KAUTが対象とするコードベースです。KAUTはより大きな目標の第一歩です：レガシーコードベースをAIネイティブにする — エージェントが安全かつ低コストで作業できるように構造化すること。

Related MCP server: 50 First Tapes MCP Server

KAUTとは何か、何でないか

別のメモリシステムではない。 メモリは「何について話したか、このユーザーは何を好むか」に答えます — 個人的で、エピソード的で、検証不可能です。KAUTは「このプロジェクトはどう動くのか、そしてなぜか」に答えます — ドキュメントです：ドメインごとに整理され、ソースに結び付けられ、鮮度チェックされ、信頼ラベルが付けられ、任意のエージェントと人間が読めます。個人的なメモは決してKAUTに入りません。プロジェクトの知識は決して1つのエージェントのメモリに閉じ込められません。その境界は書き込みパスに組み込まれています。

RAGではない。 検索拡張生成は、存在するテキストをインデックス化し、最も一致するチャンクを提供します — それらがまだ真実かどうかはわかりません。KAUTは逆の選択を保存します：再導出にコストがかかり、コードに安価に見えない知識だけ（ストレージのリトマス試験）を、モデルが全体を読む短いドキュメントに蒸留します — 埋め込みも、ランキングも、チャンクスープもありません。そして、すべてのドキュメントには機械チェックされた鮮度判定が付いています：それが導出されたコミットにアンカーされ、毎回の読み取りで追跡されたメインブランチと差分され、gitが他の方法で証明できない場合は古い方に傾きます。コードに対してRAGを実行したいならどうぞ — KAUTはコードが言わないことのためのものです：なぜ、横断的な不変条件、部族の知識。

LLMウィキではない。 自動生成ドキュメントはもっともらしいテキストであり、生まれた時点で検証されておらず、最初のコミットで放棄されます。KAUTドキュメントは、型付きソースバインディングとアンカーコミットなしには存在できません — そして、ソースが毎回の読み取りで差分されるため、静かに間違ったままになることはできません。書き込みパスはもう半分です：機械的な層は自動的に再生成され、エージェントはセッション中に検証した運用上の事実を配置できますが、判断層の知識（決定、ドメインセマンティクス、契約）は人間が承認したゲートを通ってのみ入ります — 更新はドラフトとしてキューに入り、バッチでレビューします。Wikiはデフォルトで劣化します。KAUTのデフォルトは告白です。

そして、独自のサイロではない。 KAUTはベンダーニュートラルなOpen Knowledge Format (OKF) v0.2の実装です — ストアは型付きマークダウンのコンセプトドキュメントであり、その場でOKFの適合バーを満たし、kaut okf exportは任意のストアを完全に慣用的なOKF v0.2バンドル（来歴、信頼、ライフサイクルファミリーを含む）に投影し、任意のOKFコンシューマーが読めます。KAUTの鮮度/信頼メカニズムは、OKF保護された拡張キーとしてその上に乗ります：フォーマットは知識を記録し、エンジンがそれを真実に保ちます。規範的なマッピングはSCHEMA.mdにあります。

原則

1. ソースに結び付けられ、コミットにアンカーされている。 すべての事実は、それが由来するファイルと、それが導出されたコミットを明示します。ソースがなければドキュメントもありません — 契約は入り口で検証されます。

2. 古い方に傾く。 鮮度は純粋なgit計算です（追跡されたメインブランチに対するマージベース）。gitがドキュメントが最新であることを証明できない場合、判定はそれを示します。KAUTは不確かなときに「新鮮」と叫ぶことは決してありません — 誤った「古い」は再チェックのコストがかかりますが、誤った「新鮮」はバグを出荷します。

3. 知識は情報を与えるが、決して許可しない。 健全な判定は再導出をスキップする許可であり、行動する許可ではありません。判定は信頼をルーティングします：健全+正確 = そのまま使用可能; 古い/壊れている/粗い高度 = まずコードで確認。

4. 保証できないものは提供しない。 ストアはAIエージェントによって読まれるため、パイプライン外の編集は利便性ではなくインジェクションチャネルです。最後のパイプラインコミットとバイト単位で同一でないものは、復元されるか正当に着地するまで完全に保留されます（tampered）。

5. 人間は判断を所有し、エージェントはメカニクスを所有する。 レイヤードライトゲート：マップは自由に再生成され、検証済みの運用事実はエージェント層に着地し、決定/ドメイン/契約知識はオーナーのワンキーストロークレビューのためにドラフトキューで待機します。

6. 最も安い場所で修復する。 鮮度の低下は構造的に戦われ、英雄的には戦われません：変更サイト（touchedはコード変更が負うドキュメントを指名します）、読み取りサイト（古い判定はrefreshデルタバンドルとともに到着します — 何が変わったか、何に対して再導出するか）、そして維持が追いついているかを見るための正直なテレメトリ（digest）。

7. ローカルファースト、依存関係ゼロ、リポジトリに触れない。 クローン1つ、インストールステップなし、デーモンなし、クラウドなし。知識ストアはリポジトリの外にあり、鮮度チェックはgit比較のコストであり、モデル呼び出しではありません。

KAUTが行うこと

• 既知の参照場所が1つ。 エージェントはコードを再探索する前にKAUTをチェックします。答えがそこにあるか、またはKAUTがギャップを記録して後で埋められるようにします。

• 知識は自動的に集まる。 タスクが完了した後、エージェントが学んだ有用なことはベースに凝縮されます — すでに支払われた作業の副産物であり、別のドキュメントプロジェクトではありません。

• 自信を持って嘘をつくことはない。 保存されたすべての事実は、それが由来するコードに結び付けられたままです。そのコードが変わると、その事実は自動的に古くなっている可能性があるとフラグが立てられます。疑わしいとき、KAUTはすべてが新鮮であるふりをする代わりに「これを再確認してください」と言います。

• 保証できないものを提供することを拒否します。 知識ベースはAIエージェントによって読まれるため、KAUTの背後で（独自のバージョン管理の外で）編集されたファイルは潜在的なインジェクションチャネルです。そのようなコンテンツは、復元されるか適切に再コミットされるまで完全に保留されます — エージェントが見るすべての回答は、来歴が追跡されたコミットから来ます。

• あなたが判断者であり続けます。 オーナーゲート層と新規ドキュメントは、あなたの承認なしには着地しません：更新はドラフト（kaut draft）としてキューに入り、あなたは一気にバッチ全体を着地または破棄します（kaut review）。エージェントが完了したときにあなたが立ち会う必要はありません。

• リポジトリには決して触れません。 すべての知識はプロジェクトの外の別のフォルダにあります。あなたのgit履歴、ブランチ、チームメイトはそれを見ることはありません。

• 任意のエージェントが接続できます。 CLIに加えて、KAUTはMCPサーバー（node <engine>/mcp.mjs、依存関係ゼロ）を同梱しています — 同じルックアップ、鮮度判定、ゲート付き書き込みをMCPツールとして提供し、MCP対応のハーネスやオーケストレーター向けです。1つのサーバーがマルチリポジトリワークスペース全体を処理します（各呼び出しはそのリポジトリを指定します）。

アーキテクチャ

flowchart LR
    subgraph clients["Clients"]
        direction TB
        HARNESS["AI agents\nany MCP-capable harness"]
        HUMAN["Humans and CI\nshell, scripts"]
        ORCH["Orchestrator, e.g. TAUT\n(optional)"]
    end

    subgraph engine["KAUT engine - stateless, zero-dep Node, no daemon"]
        direction TB
        SURF["Two surfaces\nmcp.mjs - 7 MCP tools\nkaut.mjs - CLI"]
        READP["READ path (lock-free)\nlookup / stale / digest\nfreshness verdict = pure git computation\n+ trust tier + altitude on every answer"]
        WRITEP["WRITE path (one chokepoint)\nlayered write gate + draft queue\nagent tier lands, judgment tier\nwaits for owner review"]
        MAINTP["Maintenance loop\nrefresh / touched / note\nmap collectors (stack adapters)"]
    end

    subgraph home["Knowledge data home - set once with kaut home"]
        direction TB
        STORES["One store per repo\ntyped markdown + frontmatter\nown private git = audit + rollback\njournal telemetry"]
        REG["workspaces registry\nmember stores + one system store"]
        BACK["backups/\nkaut backup / restore"]
    end

    REPOS["Your repositories\nREAD-ONLY sources\n(at most one git-ignored pointer file)"]
    OKFB["OKF v0.2 bundle\nkaut okf export"]

    HARNESS --> SURF
    HUMAN --> SURF
    ORCH --> SURF
    SURF --> READP
    SURF --> WRITEP
    SURF --> MAINTP
    READP -- "diff sources against\nthe anchor commit" --> REPOS
    MAINTP -- "derive maps from code" --> REPOS
    READP <--> STORES
    WRITEP --> STORES
    STORES --> OKFB

4つの文でその形を説明する。エンジンはステートレスである——すべてのコマンド（CLIまたはMCPツール）は2つのgit履歴から答えを計算して終了する。常駐して実行・同期・破損するものは何もない。知識はリポジトリの外に置かれ、データホーム内にリポジトリごとに1つのストアがあり、各ストアはそれ自体が独立したプライベートgitリポジトリである——これこそが書き込みゲート、改ざん封じ込め、監査、ロールバックを可能にするものだ。読み取りパスは決してブロックせず、推測もしない。判定は、問い合わせた瞬間にドキュメントの型付きソースをアンカーコミットと差分比較することで導出される。書き込みパスにはちょうど1つのチョークポイントしかなく、ポリシー（エージェント層かオーナーレビューか）を別のコマンドを選ぶことで迂回することはできない。

クイックスタート

1. エンジンを、それが提供するリポジトリの隣にクローンする（兄弟フォルダ——セットアップは隣接フォルダをスキャンする。npm installは不要。エンジンは依存関係ゼロ）：

cd ~/projects && git clone https://github.com/yurgeno/kaut.git

2. セットアップを実行する——3つの質問があり、それぞれの回答にはスクリプト化インストール用のフラグがある：

node kaut/kaut.mjs setup

• 知識データフォルダ——ストアの置き場所（デフォルト: <siblings>/kaut-data）。 一度だけ永続化される（kaut homeリダイレクト）。以降のすべてのコマンドとMCPサーバーは自分でそれを解決する——エクスポートも受け渡しも不要。このフォルダはライブデータである。エンジンはそこに追加するだけであり、既存のものは一切消去・書き換えされない。

• どのリポジトリか——セットアップはすべての兄弟gitリポジトリを列挙する。all、番号、または名前で回答する。

• 今すぐブートストラップするか？——yesは選択した各リポジトリのストアをその場で作成・実体化する（冪等: 既存ストアは実体化されるだけで、再シードはされない）。noは設定を記録するだけで、後で使うリポジトリ別コマンドを表示する。

非対話型: node kaut/kaut.mjs setup --data <dir> --repos all --bootstrap --yes （--no-bootstrap、--scan <dir>で別の場所をスキャン）。

3. 表示された次のステップに従う——セットアップはちょうど2つで終了する。MCPサーバーをハーネスに接続し、知識契約をエージェントの指示に貼り付ける（両方とも下記）。オプションでリポジトリごとに機械的なマップを生成する：

node kaut/kaut.mjs map

（ブートストラップはすでにスタックを検出し、適切なコレクターをシード済み——対応スタックを参照。入力が存在しないコレクターはメモ付きで自身をスキップし、map.collectors: []はマップ層が単に空のままであることを意味する）。

対応スタック

ブートストラップ、知識ループ、鮮度判定、書き込みゲート——そのすべてがスタック非依存である。どのgitリポジトリでも動作する。機械的なmap/層だけがスタック固有であり、ブートストラップはスタックを自動検出してmap.collectorsをそれに応じてシードする（既存設定は決して触られず、すべてのノブは上書き可能のまま）：

認識可能なスタックがないリポジトリは空のマップ層になり、他のすべては同じように動作する。字句コレクターは誠実なベストエフォートスキャンであり、生成ドキュメント内でその旨が明記される。追加スタック用のアダプターは意図的に小さなモジュールである——自分のスタックがない場合はCONTRIBUTING.mdを参照。

エージェントの配線——これを現実にするステップ

ストアだけでは何も変わらない。エージェントがその存在と、いつ参照すべきかを知っている必要がある。 2つの操作（貼り付け可能なブロックと実演セッション付きの完全ガイド: docs/AGENT-INTEGRATION.md）：

1. MCPサーバーをハーネスに接続する（Claude Codeでは.mcp.json、Codexではconfig.toml——スニペットはガイドに記載）。7つのkaut_*ツールがすべてのセッションに現れ、その説明はすでにモデルに規律を教えている。再探索の前に調べる、判定で信頼をルーティングする、ゲートを通して書き戻す。

2. 知識契約を、エージェントが毎セッション読み込むもの（CLAUDE.md / AGENTS.md / システムプロンプト）に貼り付ける——ガイドの約15行のブロックで、行動を偶発的ではなく確実にする。再導出の前に読む。健全+正確 = そのまま使用、古い/粗い = コードで確認。結果にkaut_noteでタグ付け。ファイル編集後はkaut_touchedを実行し、変更が負うものを修復またはキューに入れる。

オプションで契約をハーネススキルとしてラップする（テンプレートはガイドに記載）、またはオーケストレーションフレームワークに配線をコンパイルさせる——TAUTはセットアップの1つの回答からそれを行う。その後は通常どおり作業する。 自分で閲覧したい場合は、node <engine>/kaut.mjs lookupでトピックのカタログが表示される。

日常的な使用——それは存在しない

KAUTは見えないように設計されている。ちょうど3つの瞬間に気づくことになる：

• 自分のコマンドで——エージェントに学んだばかりのことを保存するよう指示する（「これをKAUTに永続化して」）。セッションの成果をリトマス試験でフィルタリングし、適切なソースバインディング付きで書き込み、ストアのgitにコミットする。オーナーゲート付きの知識は依然としてドラフトキューでレビュー待ちになる。

• ドラフトが溜まったとき——kaut reviewが待っているものを一覧表示する。一気にバッチを承認または却下する（doctorもキューが保留中の間は警告する）。

• たまにエージェントが人間にしか答えられない質問をする（「このルールは意図的なものか、それとも事故か？」）。あなたの答えはベースの中で最も価値のある種類の知識になる。

それ以外のすべて——調べ物、鮮度チェック、マップの再構築——は自動的かつ静かに行われる。

コマンド

プロジェクトのgitリポジトリ内のどこからでも実行する：

node <engine>/kaut.mjs setup         # guided install: data home, sibling-repo scan, bootstrap (run once, from anywhere)
node <engine>/kaut.mjs bootstrap     # create/repair the project's knowledge store (idempotent)
node <engine>/kaut.mjs index         # regenerate INDEX.md (under lock; auto-commits changes)
node <engine>/kaut.mjs doctor        # integrity checks; exit 0 = healthy
node <engine>/kaut.mjs home [<dir>]  # show or set the knowledge-data home (redirect at ~/.kaut/config.json)
node <engine>/kaut.mjs paths         # print resolved {projectId, root, engine, repo, mainBranch, source}
# reading core:
node <engine>/kaut.mjs lookup [<id>] # one-call ready block; no id = catalog; unknown id = miss (exit 0)
node <engine>/kaut.mjs stale [<id>…] # freshness verdicts for all/selected docs (read-path, no lock)
node <engine>/kaut.mjs map           # regenerate L0 maps per config map.collectors + commit
# maintenance loop:
node <engine>/kaut.mjs refresh [<id>…]        # per-doc re-derivation delta bundles (read-only)
node <engine>/kaut.mjs draft <id>             # queue a finished doc update for async owner review
node <engine>/kaut.mjs review [<id>…]         # owner side: list / diff / --approve / --reject
node <engine>/kaut.mjs touched <file>…        # which docs bind the given changed files
# telemetry:
node <engine>/kaut.mjs note <topic> <result>  # record an in-session outcome (trusted|confirmed|insufficient|stale-misled)
node <engine>/kaut.mjs digest [--since <ISO>] # aggregate journal telemetry across workspace stores
# backup / restore (the whole data home — stores, registry, setup record):
node <engine>/kaut.mjs backup                 # dated, versioned .tar.gz under <data>/backups/
node <engine>/kaut.mjs restore [latest|<file>] [--force]   # no arg = list; never overwrites without --force
# open format (OKF v0.2):
node <engine>/kaut.mjs okf check              # store-as-OKF-bundle conformance report (exit 0 = conformant)
node <engine>/kaut.mjs okf stamp              # backfill `type:` on legacy docs (through the write gate)
node <engine>/kaut.mjs okf export --out <dir> # project committed HEAD into an idiomatic OKF v0.2 bundle
# workspace (multi-repo):
node <engine>/kaut.mjs workspace init --manifest <conductor>/manifest.json
                                     # registry + member stores + ONE system store anchored to the launcher
node <engine>/kaut.mjs workspace list

MCPサーバー: node <engine>/mcp.mjs——セッション動詞をMCPツールとして公開するゼロ依存のstdio JSON-RPCサーバー（kaut_lookup、kaut_note、kaut_refresh、kaut_touched、kaut_write、kaut_draft、kaut_status）。すべてのツールはオプションのrepo引数を受け取るため、1つのサーバーでマルチリポジトリのワークスペース全体を提供できる。オーナー実行のエスケープ（review --approve、index --approve）は意図的にMCP経由では公開されない。

フラグ: --dry-run（実行せずにアクションを表示）・--json（stale|lookup|refresh|review|touched|digestの機械出力）・--quiet・--approve / --reject（オーナー実行）・--force（restore: 既存データを上書き。okf export: 空でないディレクトリに書き込む）・--out <dir>（okf export）・--note <text>（note、review --reject）・--manifest <path>（workspace init）・--workspace <name>（ワークスペース全体でのdoctor/stale/digest）・--since <ISO-date>（digest）・--help/-h（使用方法、終了コード0）。

終了コード: 0正常・1検証/doctor失敗・2ストアビジー（ロック保持中）・3環境欠落（gitリポジトリではない / ストアがブートストラップされていない）。

lookupとstaleは読み取りパスである——ロックを取らず、journal.jsonlに1行追加するだけ（使用テレメトリ、追跡対象外）。鮮度判定はデータであり、エラーではない。staleはドキュメントが古くても終了コード0で終了する。判定行は最大1つで、優先度はtampered > disputed > broken > stale > branch-advisory。健全なドキュメントはクリーンに表示される。

運用の深掘り——ディスク上のストアレイアウト、解決順序、改ざん封じ込めと書き込みゲートの詳細、アンインストール、エンジン内部: docs/OPERATIONS.md。

設定

1つのファイル: ストア内のkaut.config.json（ブートストラップが作成、適切なデフォルト値）。ほとんどの人はmapブロック（コレクターリストとファイルの場所——上記のクイックスタートのメモを参照）だけを触る。エンジンが実際に読み取るものの完全なリファレンス: docs/HANDBOOK.md §15。

実際に役立っているか？

KAUTは自分自身に正直であり続けるように構築されている：

• ストアごとに使用ジャーナル（journal.jsonl）を維持する。すべてのルックアップとその判定、すべてのゲート付き書き込み、すべての記録された結果。kaut digestはそれをワークスペース全体で集計し、到達度 / 自己メンテナンス / 価値シグナルの数値にする。

• セッションはドキュメントが実際にどうだったかを記録する（kaut note <topic> trusted|confirmed|insufficient|stale-misled）——知識がどこで作業を節約し、どこで誤解させたかを示す名誉システムの価値シグナル。

• ベンチマークは外部で行われる（同じタスクをKAUTありとなしで実行して比較する）。エンジンは意図的にベンチマークハーネスを同梱しない。

ジャーナルは追記専用の追跡対象外テレメトリであり、無制限に成長する。古い行を手動で切り詰めても安全である（それは決して知識ではなく、digestは単に短い履歴を見るだけである）。

バックアップ

データフォルダがデータベース全体である——それに応じて扱うこと。kaut backupはデータホーム全体（git履歴付きのすべてのストア、ワークスペースレジストリ、セットアップ記録）を、<data>/backups/配下の日付付きバージョン管理アーカイブにパックする——標準的なtarツールでも読み取れるプレーンな.tar.gz（手書きのustar + node:zlib、依存関係ゼロ）。kaut restore latest（またはファイル名）で復元する。--forceなしに既存のものが上書きされることは決してない——拒否された復元は競合を一覧表示し、何も触らない。

テスト

cd <engine> && node --test          # 213 tests, zero deps (node:test)

素のnode --testを実行する——テストディレクトリを引数として渡さないこと（Node ≥ 24ではその形式はスイートを解決できない）。

アンインストール

ストアディレクトリ（~/.kaut/<project-id>）とポインターファイル（<repo>/.kaut.json）を削除し、<repo>/.git/info/excludeから.kaut.jsonの行を削除する。リポジトリはそもそも変更されたことがない——他にクリーンアップするものはない。

FAQ

これは単なる別のエージェントメモリシステムですか？ いいえ。エージェントメモリは会話と好みを記憶します。KAUTはプロジェクトのドキュメントです——AIファースト、ソースバインド、鮮度チェック付き。書き込みパスが境界を強制します。プロジェクト知識はKAUTへ、個人の好みはエージェント自身のメモリへ。

これはRAGですか？ いいえ。埋め込みも、チャンキングも、検索ランキングもありません。KAUTはエージェントが全体を読む少量の蒸留されたドキュメントを保存し、それぞれに来歴とgit計算による鮮度判定が付いています——そしてコードから安価に導出できないものだけを意図的に保存します。コードベースに対するRAGとKAUTは異なる質問に答え、共存は問題ありません。

これは自動生成のWikiですか？ いいえ。未検証の生成散文としてストアに入るものはありません。すべてのドキュメントは型付きソースバインディングとコミットアンカーを保持しなければならず、機械的な層は再生成され（幻覚ではなく）、判断層の知識は人間が承認したゲートを通過します。またWikiと違い、KAUTドキュメントは静かに腐敗しません——ソースは読み取りのたびに差分比較されます。

ストア形式は独自仕様ですか？ いいえ——その逆です。KAUTはベンダーニュートラルなOpen Knowledge Format (OKF) v0.2を実装しています。プレーンな型付きマークダウンのコンセプトドキュメントです。どのOKFコンシューマーもストアを読むことができ、kaut okf exportは完全に慣用的なOKFバンドルを生成します。ロックインはありません。知識はどちらにせよgitリポジトリ内のポータブルなマークダウンです。

リポジトリに何かをコミットしますか？ いいえ。多くても無視されるポインタファイルが1つだけです。ナレッジストアはリポジトリの外にあります。

チーム全体で導入する必要がありますか？ いいえ。KAUTはローカルファーストです。開発者が1人インストールすれば恩恵を受けられ、他の誰も関与したり影響を受けたりしません。

保存された事実が間違っていたらどうなりますか？ すべての事実には出典と信頼ラベルが付いています。エージェントは信頼度の低い事実には懐疑的に接し、コードと照合して検証します。ストアは完全な履歴を保持するため、不正なエントリは追跡してロールバックできます。

運用コストはどのくらいですか？ 最初のマップ構築が最もコストがかかる部分です（数分）。日常的なメンテナンスはほぼコストゼロになるよう設計されています。鮮度チェックは純粋なgit比較であり、AI呼び出しは一切含まれません。

詳細情報

• The project wiki — ガイド形式の「はじめに」「プロジェクトの接続」「中核概念」「メンテナンスループ」「FAQとトラブルシューティング」

• docs/HANDBOOK.md — すべての仕組みを、人間の言葉で完全な詳細に説明

• docs/OPERATIONS.md — オペレーター向けリファレンス：ディスク上のレイアウト、解決、改ざん封じ込め、書き込みゲート、エンジン内部

• docs/AGENT-INTEGRATION.md — エージェントをストアに接続：ナレッジ契約、ハーネス別スニペット、スキルテンプレート、実演セッション

• docs/MCP.md — MCPサーバーリファレンス：登録、全7ツール、プロトコル

• SCHEMA.md — このエンジンが実装する規範的なデータ契約（OKF v0.2 適合マッピングを含む）

• CHANGELOG.md — リリース履歴

• CONTRIBUTING.md · SECURITY.md · CODE_OF_CONDUCT.md

ライセンスと引用

Apache-2.0 — LICENSE と NOTICE を参照してください。KAUTを使用する場合、またはKAUTが実装する概念に基づいて構築する場合は、CITATION.cff を介して引用してください。

連絡先：Yuriy Orlov yuriy.orlov@undertrust.dev