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.
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.
| Layer | Writer | Best use | Review model |
|---|---|---|---|
| QWEN.md | Human or /init-assisted | Commands, conventions, durable instructions | Git review for shared project files |
| Private auto-memory | Qwen Code | Preferences, feedback, local project context | User can inspect, edit, forget |
| Team memory | Qwen Code + collaborators | Shared project guidance in git | Diff/PR review and secret scan |
| Busabase record | Agent proposal + accountable owner | Cross-project facts, decisions, status | Change 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.
Personal auto-memory under the user's Qwen directory
QWEN.md and optional .qwen/team-memory in git
Curated memory protected from automatic cleanup
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 teammatecontext_scopeFresh, full parent, or bounded recent turnstool_scopeAllowed/disallowed tools and MCP serverspermission_modePlan, ask, auto-edit, auto, or yoloworking_dirShared checkout or explicit worktreeresult_refReturned message and generated artifactsApproval 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.
| Mode | File edits | Shell / network | Knowledge implication |
|---|---|---|---|
| Plan | Read-only | Not executed | Analysis still needs evidence |
| Ask Permissions | Manual approval | Manual approval | User saw actions, not necessarily every claim |
| Auto-Edit | Automatic | Manual approval | Diff review remains essential |
| Auto | Classifier-evaluated | Classifier-evaluated | Policy classification is not factual validation |
| YOLO | Automatic | Automatic | Use 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.
Procedure, support files, optional deterministic hook
Focused context and controlled tools
External tools, prompts, resources, authentication
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.
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 identitymemory_refsRelevant QWEN.md, private, team, or pinned memoryagent_traceParent, subagents, forks, native executorssource_refsOwning systems and exact evidenceproposed_stateConcise reusable claimownerAcceptance responsibilitydecisionAccepted, conditional, rejected, supersededfreshnessVerified-at and next-review boundaryChoose 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.
Stable project instructions and verification commands
Personal preferences and short-lived context
Reviewed shared guidance that belongs in the repository
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.

