Busabase × AiderKnowledge Base for Aider
Aider leaves unusually strong code evidence: repository context, diffs, tests, and attributed Git commits. Busabase adds the part Git does not own: the accepted operational meaning, accountable owner, and review state that other teams and Agents may reuse.
Four artifacts, four jobs
Do not turn the repo map or chat history into a second source of truth.
Aider optimizes context for editing a repository. The durable knowledge path should preserve each artifact in the system built to own it.
| Artifact | What it proves | Durable owner |
|---|---|---|
| Repository map | Which symbols and dependencies were useful to the model | Aider session context |
| Chat and mode history | How a plan became edits | Aider history |
| Diff, tests, and commit | Exactly what changed in code | Git and CI |
| Accepted impact | What downstream teams may now rely on | Busabase |
Plan and edit are not approval
Ask, architect, and code modes separate reasoning from file changes, not judgment from authority.
Ask mode discusses without editing. Architect mode turns a proposal into edits through an editor model. Code mode changes files directly. None of these modes assigns a business owner or makes an operational claim canonical.
Explore the problem
Capture options and unresolved assumptions.
Propose then translate
Keep the proposal linked to resulting diffs.
Edit repository files
Require tests and review before promotion.
Git-native evidence
Use Aider's commits as immutable evidence, not as the final decision record.
Aider can commit its edits with descriptive messages, separate pre-existing dirty work, attribute authorship, show diffs, and undo a change. Link the exact repository and revision instead of copying source code into a knowledge base.
No native MCP client
Aider and Busabase run side by side instead of pretending to be one tool surface.
Aider's official documentation does not describe an MCP client. Keep Aider focused on the repository; use busabase-cli in the same terminal or call the REST API from code to read records and propose reviewed updates.
Edit, test, commit
Owns repository execution and code artifacts.
Read and propose
Owns review-gated structured state.
Change dossier
Promote one decision packet, not the entire coding conversation.
The packet should be small enough to review without replaying the session.
| Field | Review question |
|---|---|
| change_key | Which durable claim is changing? |
| repo_revision | Which code state produced the evidence? |
| request | What outcome was requested? |
| implementation_refs | Which diff, files, or pull request carry it? |
| verification | Which tests, lint, build, or runtime checks passed? |
| impact | What changes for users or operations? |
| owner | Who can accept that impact? |
| decision | Accepted, conditional, rejected, or superseded? |
| effective_at | When may downstream work rely on it? |
Two review loops
Code review protects the repository. Record review protects every workflow that consumes the claim.
A clean diff can still encode the wrong policy, deployment assumption, support promise, or operational status.
Repository review
Does the implementation work and belong in this branch?
Record review
Is the stated consequence evidenced, owned, and current?
Sidecar handoff
Build the record after verification, while evidence is still addressable.
Keep the sequence explicit so a later reviewer can reproduce it without access to Aider's full chat history.
Practical questions
Aider knowledge base FAQ
Does Busabase replace Git?
No. Git owns source, commits, branches, and code history. Busabase links those artifacts to reviewed operational decisions.
Does Aider support Busabase through MCP?
Not through an officially documented MCP client. Use busabase-cli beside Aider or the REST API from code.
Should chat history be copied into Busabase?
Usually not. Promote only the decision, evidence references, owner, and current status.
Is an Aider commit automatically approved?
No. It records a code state. Repository review and record review remain separate decisions.
What if Git integration is disabled?
Provide another immutable revision and verification trail. Do not treat an unversioned working tree as durable evidence.
Start with one verified change
Keep the code in Git and promote only the consequence that needs shared trust.
Choose one Aider change with a stable revision and completed verification. Build a concise impact packet, then let its owner review the claim before another Agent uses it.