AiderBusabase × Aider

Aiderのナレッジベース

Aiderは強いcode evidenceを残します。Repository context、diff、test、帰属付きGit commitです。BusabaseはGitが所有しない部分、つまり変更の運用上の意味、責任者、他teamやAgentが再利用できるreview stateを加えます。

Code change evidenceCommit detected
Aiderのcode changeに関連付けたBusabase file review
Commitは変更内容を証明します。レビュー済み記録は組織が何を受け入れたかを示します。

4つの成果物、4つの役割

Repo mapやchat historyを第2のsource of truthにしない。

Aiderはrepository編集のためにcontextを最適化します。永続knowledgeでは各成果物を本来の所有systemに残します。

成果物証明すること永続owner
Repository mapModelに有用だったsymbolとdependencyAider session context
Chat / mode historyPlanがeditへ変わった経路Aider history
Diff、test、commitCodeで実際に変わった内容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にしたりしません。

ASK

問題を探索

選択肢と未解決の前提を残す。

ARCHITECT

提案を編集へ変換

提案と結果diffを結び付ける。

CODE

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をリンクします。

RepositoryImplementationの保管場所
Revision正確なcommitまたはimmutable branch point
Diff変更されたfileとbehavior
VerificationLint、test、build、review結果
Aider commitとreview evidenceを関連付けるBusabase record

Native MCP clientはない

AiderとBusabaseは1つのtool surfaceを装わず並行して動く。

Aider公式文書はMCP clientを説明していません。Aiderはrepositoryに集中し、同じterminalのbusabase-cliまたはcodeからのREST APIでrecordを読み、review対象の更新を提案します。

AIDER

Edit・test・commit

Repository executionとcode artifactを所有。

BUSABASE CLI / API

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が通ったか?
impactUserやoperationに何が変わるか?
owner誰がimpactを受け入れられるか?
decisionAccepted、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なしで再現できる順序にします。

01定義編集前に期待outcomeを記述。
02編集必要最小限のfileとrepo-map contextを利用。
03検証Lint、test、build、domain checkを実行。
04Commit正確なdiffとattributionをGitへ保存。
05提案busabase-cliまたはRESTでimpact packetを提出。
06Review責任ownerがclaimを承認または却下。

実務上の質問

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します。