Knowledge Base for Qwen CodeBusabase x Qwen Code

Knowledge Base for Qwen Code

Qwen Code now carries context through QWEN.md, private auto-memory, optional git-backed team memory, Skills, subagents, and MCP. Those layers make sessions more capable. They also make it important to distinguish what the Agent remembered from what a person reviewed and accepted.

Memory-derived proposalEvidence not yet accepted
Busabase reviewing knowledge proposed from Qwen Code
Memory can suggest a claim. Review decides whether it becomes canonical.

Four memory layers

QWEN.md, auto-memory, team memory, and canonical knowledge have different owners.

Qwen Code loads instructions and learned context at session start. Busabase should not erase those layers; it should receive only the small set of claims that need accountable reuse beyond one checkout or one Agent.

LayerWriterBest useReview model
QWEN.mdHuman or /init-assistedCommands, conventions, durable instructionsGit review for shared project files
Private auto-memoryQwen CodePreferences, feedback, local project contextUser can inspect, edit, forget
Team memoryQwen Code + collaboratorsShared project guidance in gitDiff/PR review and secret scan
Busabase recordAgent proposal + accountable ownerCross-project facts, decisions, statusChange Request then merge

Team memory

Git-backed sharing makes memory reviewable, not automatically authoritative.

Team memory is opt-in, source-controlled, and visible to collaborators. Qwen blocks detected secrets and writes appear in git diff, but auto-edit or YOLO can still apply them without a prompt. Treat the diff as proposed guidance. Keep business state and cross-system claims in a separately reviewed record.

PRIVATE

Personal auto-memory under the user's Qwen directory

PROJECT

QWEN.md and optional .qwen/team-memory in git

PINNED

Curated memory protected from automatic cleanup

CANONICAL

Busabase record with source, owner, decision, freshness

Subagents and forks

Delegation changes context and tools; it does not transfer authority to accept facts.

Named subagents start with separate context and controlled tools. Forks inherit selected parent turns and may narrow execution with fork_tools or a fork profile. Native Claude Code and Codex executors add their own runtime rules. Preserve which path ran, what it could access, and what returned to the parent.

agent_kindNamed subagent, fork, native executor, or teammate
context_scopeFresh, full parent, or bounded recent turns
tool_scopeAllowed/disallowed tools and MCP servers
permission_modePlan, ask, auto-edit, auto, or yolo
working_dirShared checkout or explicit worktree
result_refReturned message and generated artifacts

Approval Mode

Five execution modes describe action risk, not knowledge quality.

Choose a mode according to the environment. Record the effective mode when an outcome depends on edits, commands, network calls, or MCP tools.

ModeFile editsShell / networkKnowledge implication
PlanRead-onlyNot executedAnalysis still needs evidence
Ask PermissionsManual approvalManual approvalUser saw actions, not necessarily every claim
Auto-EditAutomaticManual approvalDiff review remains essential
AutoClassifier-evaluatedClassifier-evaluatedPolicy classification is not factual validation
YOLOAutomaticAutomaticUse only in controlled environments; review outcomes separately

Skills and MCP

Skills shape a procedure; MCP supplies capabilities and external evidence.

Qwen Skills may include instructions, scripts, templates, hooks, and path gates. MCP may expose tools, prompts, and resources with per-server filtering and trust settings. Keep the Skill revision, server identity, tool response, and acceptance decision as separate fields.

SKILL

Procedure, support files, optional deterministic hook

SUBAGENT

Focused context and controlled tools

MCP

External tools, prompts, resources, authentication

REVIEWED RECORD

Accepted conclusion with owner and lifecycle

Promotion path

Move from remembered context to a claim with explicit evidence.

Memory can surface a useful hypothesis. Qwen then reads the owning sources, uses the appropriate tools, and proposes one bounded update. Busabase keeps that proposal non-canonical until review.

01 · REMEMBER

QWEN.md or memory suggests context

02 · RESEARCH

Read source systems

03 · EXECUTE

Skills, subagents, MCP

04 · VERIFY

Tests and readback

05 · PROPOSE

One record change

06 · REVIEW

Owner accepts

Busabase delivery log for a Qwen Code knowledge proposal

Knowledge contract

Record what was accepted without freezing Qwen's entire memory state.

The canonical object should be smaller, more explicit, and more accountable than the session context that produced it.

knowledge_keyStable identity
memory_refsRelevant QWEN.md, private, team, or pinned memory
agent_traceParent, subagents, forks, native executors
source_refsOwning systems and exact evidence
proposed_stateConcise reusable claim
ownerAcceptance responsibility
decisionAccepted, conditional, rejected, superseded
freshnessVerified-at and next-review boundary

Choose the owner

Keep each kind of context in the narrowest system that can govern it.

This prevents Qwen memory from becoming a shadow database and prevents Busabase from replacing repository conventions.

QWEN.md

Stable project instructions and verification commands

AUTO-MEMORY

Personal preferences and short-lived context

TEAM MEMORY

Reviewed shared guidance that belongs in the repository

BUSABASE

Structured decisions and facts reused across projects, people, Agents, and Apps

Practical questions

Qwen Code knowledge base FAQ

Does Busabase replace QWEN.md?

No. QWEN.md is for always-on project instructions; Busabase holds selected reviewed state.

Is Qwen auto-memory reliable enough to be canonical?

It is useful context and remains inspectable, but it is model-written and best-effort. Verify claims against owning sources.

Does team memory require review?

Its git diff is reviewable. Auto-edit and YOLO may write without a prompt, so repository policy must still require review where needed.

Can a fork approve its own output?

No. Fork tool restrictions govern execution. An accountable owner still decides whether the returned claim becomes canonical.

Does trusted MCP mean trusted data?

No. Trust can skip confirmations and enable replay under limited conditions; validate the response and preserve provenance.

Start with one memory-derived claim

Ask Qwen Code to verify it before proposing a durable record.

Pick one useful remembered fact, trace it to the owner system, attach the Agent path and evidence, then review it independently.