Busabase x Knowledge Base for Command CodeKnowledge Base for Command Code
Command Code learns from accepts, rejects, edits, and correction diffs. That feedback can make the next coding turn feel more like your team, but a learned preference is still different from a sourced fact about a system or business.
MAP
Taste can suggest a preference; your team decides what becomes shared knowledge.
Command Code learns from accepts, rejects, edits, and correction diffs. That feedback can make the next coding turn feel more like your team, but a learned preference is still different from a sourced fact about a system or business.
Accepts, rejects, edits, correction diffs
Project taste package
Preferences shared across projects or a team
Decision, source, owner, evidence
01 · Knowledge Base for Command Code
Taste-1 separates preference decisions from text generation
Command Code learns from accepts, rejects, edits, and correction diffs. That feedback can make the next coding turn feel more like your team, but a learned preference is still different from a sourced fact about a system or business.
| Taste signal | Accepts, rejects, edits, correction diffs | A behavioral signal, not a policy decision |
|---|---|---|
| Project taste | Project taste package | Project guidance that can be linted and changed |
| Global or remote taste | Preferences shared across projects or a team | Portable context with its own scope and freshness |
| Busabase record | Decision, source, owner, evidence | Canonical only after a Change Request |
02 · Knowledge Base for Command Code
Project, global, and remote taste packages have different scope
Taste can suggest a preference; your team decides what becomes shared knowledge.
A behavioral signal, not a policy decision
Project guidance that can be linted and changed
Portable context with its own scope and freshness
Canonical only after a Change Request
03 · Knowledge Base for Command Code
MCP, Skills, memory, and tastes remain execution context
Knowledge Base for Command Code: Taste-1 separates preference decisions from text generation; Project, global, and remote taste packages have different scope; MCP, Skills, memory, and tastes remain execution context.
command-code_1Accepts, rejects, edits, correction diffs · A behavioral signal, not a policy decisioncommand-code_2Project taste package · Project guidance that can be linted and changedcommand-code_3Preferences shared across projects or a team · Portable context with its own scope and freshnesscommand-code_4Decision, source, owner, evidence · Canonical only after a Change RequestEVIDENCE
Knowledge Base for Command Code: inspect the boundary
Taste-1 separates preference decisions from text generation Project, global, and remote taste packages have different scope MCP, Skills, memory, and tastes remain execution context
command-code_1Taste signal: Accepts, rejects, edits, correction diffs; A behavioral signal, not a policy decisioncommand-code_2Project taste: Project taste package; Project guidance that can be linted and changedcommand-code_3Global or remote taste: Preferences shared across projects or a team; Portable context with its own scope and freshnesscommand-code_4Busabase record: Decision, source, owner, evidence; Canonical only after a Change Request
ACCEPTANCE
Knowledge Base for Command Code: execution is not acceptance
Taste can suggest a preference; your team decides what becomes shared knowledge.
Verify Accepts, rejects, edits, correction diffs before accepting A behavioral signal, not a policy decision.
Verify Project taste package before accepting Project guidance that can be linted and changed.
Verify Preferences shared across projects or a team before accepting Portable context with its own scope and freshness.
Verify Decision, source, owner, evidence before accepting Canonical only after a Change Request.
FAQ
Knowledge Base for Command Code: practical questions
Taste can suggest a preference; your team decides what becomes shared knowledge.
Is taste the same as a coding rule?
No. Taste is learned from signals and stored as packages. A rule with operational consequences still needs an owner and a change history.
Should every accept become canonical?
No. An accept is evidence of a local preference. Promote it only when the team agrees it should govern later work.
Can remote taste replace a repository decision?
No. Remote taste is portable preference context. Repository decisions need sources, scope, and a change history.
Does MCP response become trusted because Command Code connected it?
No. The server connection gives capability; the returned claim still needs verification.
NEXT
Taste can suggest a preference; your team decides what becomes shared knowledge.
Command Code learns from accepts, rejects, edits, and correction diffs. That feedback can make the next coding turn feel more like your team, but a learned preference is still different from a sourced fact about a system or business.