-
Notifications
You must be signed in to change notification settings - Fork 6
Code Graph
Language: English · 简体中文
Native commands forward stdout, stderr and exit status without wrapping; lwc_codegraph preserves native MCP results. Read lwc cg help COMMAND and lwc cg tools for runtime contracts. lwc doctor --verbose and lwc cg status show routing; lwc cg inspect returns native statistics. Configure an explicit owner with lwc cg configure --help; missing indexes never silently switch owner. LWC-managed .lwc/codegraph is the default, not the only selectable index.
For named files, use lwc cg --require-fresh --file PATH query SYMBOL. Missing/unknown evidence fails closed. These fingerprints prove only the specified scope; readiness is not repository-wide freshness or relationship completeness. An empty query is not proof that code can be deleted.
LWC integrates a pinned CodeGraph runtime for structural questions about checked-out code. It maps files, symbols, definitions, calls, and dependencies so an Agent can locate the smallest relevant source surface before reading exact files.
The code graph is independent from the document knowledge graph. One models source code structure; the other models Wiki Pages, Sources, citations, and semantic relations. Enable and verify them separately.
Use CodeGraph for:
- symbol definitions and signatures;
- callers and callees;
- source and test dependencies;
- file topology;
- structural exploration around a feature;
- change impact before editing a shared symbol.
Use rg for literal text, comments, log strings, configuration keys, and one-file edits already proven by exact search. CodeGraph complements source reading; it does not replace it.
LWC separates installation from indexing:
pinned runtime -> installed once globally per version and platform
project index -> stored separately in each project's .lwc/codegraph
The first project that runs cg init may download the verified pinned runtime. Later projects reuse that global runtime, but each project builds and maintains its own index. An update downloads a new pinned version; normal project initialization does not repeatedly download the same runtime.
The default LWC owner uses its pinned runtime with telemetry disabled. An explicitly configured external owner keeps its selected runtime and index; LWC does not silently switch between owners.
lwc --scope project cg statusstatus is read-only and separates runtime availability from project index initialization. An existing, user-authorized index can be queried without new consent.
If the runtime or project index is missing, explain the download, local index, and storage effects before asking once for consent. Detection alone is not permission to download or index code.
After consent:
lwc --scope project cg init
lwc --scope project cg statusUse --verbose only when detailed indexing progress is useful. Initialization is complete only when status reports an installed healthy runtime and initialized=true for the current project.
Never pass another project path through the wrapper, point it at an unrelated working tree, or edit .lwc/codegraph directly.
Start with a symbol search:
lwc cg query "checkpoint restore" --limit 10
lwc cg node checkpoint_restore
lwc cg callers checkpoint_restore --limit 20
lwc cg callees checkpoint_restore --limit 20-
querysearches indexed symbols and can filter by symbol kind. -
nodereturns one symbol's source plus caller and callee context; with--file, it reads a bounded line-numbered file window. -
callersanswers “who calls this?” -
calleesanswers “what does this call?”
Disambiguate common symbol names with exact files or follow the indexed locations into the checkout. Do not make a final implementation claim from a symbol name alone.
lwc cg explore "checkpoint recovery"
lwc cg files --filter src/store --format tree --max-depth 3
lwc cg impact checkpoint_restore --depth 2
lwc cg affected src/store/checkpoints.rs-
explorecombines relevant symbols, source, and call paths for one area. -
filesshows indexed file structure with optional directory and glob filters. -
impacttraverses code affected by a symbol change. -
affectedidentifies tests affected by changed source files.
Keep limits and depth bounded. Use the graph to locate candidate files, then read the exact checked-out implementation and its tests.
The index may lag behind uncommitted edits. When a task depends on current dirty code, synchronize before the first structural query, after relevant code changes, and before a final structural claim:
lwc --scope project cg sync
lwc --scope project cg statusCodeGraph reconciles files with document-granular transactions. A successful sync updates the project index; it does not commit Git changes or write LWC Wiki knowledge.
lwc serve --mcp exposes CodeGraph through native lwc_codegraph and compatible lwc_explore tools. Use mode=code for code-only exploration or mode=all when both Wiki memory and code structure matter.
MCP never initializes the runtime or project index. When CodeGraph is unavailable, it returns readiness guidance and requires an explicit CLI cg init outside the read-only tool.
- Index only the current authorized project root.
- Treat checked-out source as current implementation evidence when Wiki memory differs.
- Do not ingest the CodeGraph database as a Wiki Source.
- Do not edit, copy between projects, or remove the index database manually.
- Do not mistake index success for build, test, or runtime verification.
- Run native tests and inspect exact code before claiming a change is safe.
CodeGraph use is complete when:
-
cg statusreports the expected pinned runtime and initialized project index; - the index was synced after relevant dirty changes;
- structural queries identified the relevant symbols and files;
- exact checked-out source and tests confirmed the final claim;
- the project-local index remained inside
.lwc/codegraphwith telemetry disabled.
Next: Word graph
LWC Wiki
- Architecture overview · 总体架构
- Storage and data model · 存储与数据模型
- Retrieval and indexing · 检索与索引设计
- Graph projection and performance · 图投影与性能设计
- MCP, Hooks, and AgentTarget design · MCP、Hook 与 AgentTarget 设计
- Safety and trust boundaries · 安全模型与信任边界
- Maintenance and diagnostics · 维护与诊断
- Troubleshooting and FAQ · 故障排查与常见问题
- Migration and compatibility · 迁移与版本兼容
- Support and issue reporting · 获取帮助与问题反馈
- Contributing and development · 贡献与开发指南
- Testing and release process · 测试与发布流程
- Wiki style guide · Wiki 编写规范