Aiderのナレッジベース
Aiderは強いcode evidenceを残します。Repository context、diff、test、帰属付きGit commitです。BusabaseはGitが所有しない部分、つまり変更の運用上の意味、責任者、他teamやAgentが再利用できるreview stateを加えます。
4つの成果物、4つの役割
Repo mapやchat historyを第2のsource of truthにしない。
Aiderはrepository編集のためにcontextを最適化します。永続knowledgeでは各成果物を本来の所有systemに残します。
| 成果物 | 証明すること | 永続owner |
|---|---|---|
| Repository map | Modelに有用だったsymbolとdependency | Aider session context |
| Chat / mode history | Planがeditへ変わった経路 | Aider history |
| Diff、test、commit | Codeで実際に変わった内容 | Git / CI |
| 受け入れ済みimpact | 下流teamが依存できる内容 | Busabase |
Planとeditはapprovalではない
Ask、architect、codeが分けるのは推論と編集であり、判断と権威ではない。
Ask modeは編集せず議論します。Architect modeは提案をeditor model経由でeditへ変換します。Code modeは直接fileを変更します。どのmodeも業務ownerを割り当てたり、運用claimをcanonicalにしたりしません。
問題を探索
選択肢と未解決の前提を残す。
提案を編集へ変換
提案と結果diffを結び付ける。
Repository fileを編集
昇格前にtestとreviewを要求。
Git-native evidence
Aider commitをimmutable evidenceとして使い、最終判断recordにはしない。
Aiderは説明付きcommit、既存dirty workの分離、author attribution、diff表示、undoを扱えます。Source codeをknowledge baseへ複製せず、正確なrepositoryとrevisionをリンクします。
Native MCP clientはない
AiderとBusabaseは1つのtool surfaceを装わず並行して動く。
Aider公式文書はMCP clientを説明していません。Aiderはrepositoryに集中し、同じterminalのbusabase-cliまたはcodeからのREST APIでrecordを読み、review対象の更新を提案します。
Edit・test・commit
Repository executionとcode artifactを所有。
Read・proposal
Review-gated structured stateを所有。
Change dossier
Coding conversation全体ではなく1つのdecision packetを昇格する。
Reviewerがsessionを再生しなくても判断できる大きさにします。
| フィールド | レビュー質問 |
|---|---|
| change_key | どの永続claimが変わるか? |
| repo_revision | どのcode stateが証拠を生成したか? |
| request | 要求された結果は何か? |
| implementation_refs | どのdiff、file、Pull Requestが実装するか? |
| verification | どのtest、lint、build、runtime checkが通ったか? |
| impact | Userやoperationに何が変わるか? |
| owner | 誰がimpactを受け入れられるか? |
| decision | Accepted、conditional、rejected、superseded? |
| effective_at | 下流が依存できる時点は? |
2つのreview loop
Code reviewはrepositoryを、record reviewはclaimを読む全workflowを守る。
Cleanなdiffでもpolicy、deployment assumption、support promise、operation stateを誤ることがあります。
Repository review
Implementationは動作し、このbranchに入れるべきか?
Record review
Claimは証拠、owner、freshnessを持つか?
Sidecar handoff
Verification直後、証拠を参照できる間にrecordを作る。
後のreviewerがAiderの全chat historyなしで再現できる順序にします。
実務上の質問
AiderナレッジベースのFAQ
BusabaseはGitを置き換えますか?
いいえ。Gitはsource、commit、branch、code historyを所有し、Busabaseはそれらをレビュー済み運用判断へ結び付けます。
AiderはMCPでBusabaseを使えますか?
公式に文書化されたMCP clientはありません。Aiderと並行してbusabase-cliを使うか、codeからREST APIを呼びます。
Chat historyをBusabaseへコピーしますか?
通常はしません。Decision、evidence refs、owner、current statusだけを昇格します。
Aider commitは自動承認ですか?
違います。Commitはcode stateの記録です。Repository reviewとrecord reviewは別の判断です。
Git integrationを無効にした場合は?
別のimmutable revisionとverification trailが必要です。Unversioned working treeを永続証拠にしません。
1つのverified changeから始める
CodeはGitに残し、共有trustが必要な結果だけを昇格する。
Stable revisionとverificationを持つAider changeを選び、短いimpact packetを作り、別Agentが使う前にownerがreviewします。

