ArchView

Draw an architecture diagram of "how modules depend on each other" for a repository — the topology comes entirely from tree-sitter static analysis, and the LLM only writes a one-sentence human summary for each node. The same diagram is exposed to the agent in your IDE through MCP.

Standalone, local, bound only to 127.0.0.1. Chinese interface by default.

🚀 Have the AI install it for you (fastest)

Not published to npm, so there's no npx archview route — you can only get it from source. The good news is that the whole thing can be handed to an AI.

Copy the following entire block, paste it to any AI assistant that can read web pages and run commands (Kiro / Cursor / Claude Code / Codex …), and replace <my project path> with the repository you want to analyze:

帮我装 ArchView 并把我的项目接进去。

仓库：https://github.com/LZZLHY/archview
安装剧本（先读这个，它是给你写的）：https://raw.githubusercontent.com/LZZLHY/archview/main/SETUP-FOR-AI.md

我的项目在：<我的项目路径>

照剧本走：环境体检 → clone → pnpm install + pnpm build → archview init 我的项目 → archview build → 起服务。
剧本里标了「决策点」的地方问我一下再决定（尤其是装到哪、要不要改我的 AI 宿主配置、要不要现在开始写摘要）。
最后把带 token 的面板 URL 给我。

Every stage in the playbook (SETUP-FOR-AI.md) has a "how do I know this step worked" section, plus a "common failures and remedies" section. It's designed so an AI can read it through the raw URL before cloning.

Do it yourself: jump to Section 5 and run the five steps with copy-and-paste commands; or do the first two steps with a single command:

# Windows PowerShell（先 clone，再跑仓库里的脚本）
powershell -ExecutionPolicy Bypass -File scripts\setup.ps1

# macOS / Linux
bash scripts/setup.sh

If you want to first judge whether it's worth a look: Section 3 (why it belongs alone) and Section 10 (known limitations / who shouldn't use it).

Related MCP server: SGraph MCP Server

1. What problem it hits solving

Imagine you are alone writing a HarmonyOS app with 9 ohpm modules (this is the origin of this project). You want two things:

1. For yourself: a diagram that can be clicked, drilled into, and shows "entry depends on which HARs, who uses commons";

2. For agents: the assistant inside Cursor / Kiro / Claude Code can accurately know the project structure, instead of guessing through grep.

The existing tools each lack half:

ArchView joins the two ends together: CodeGraph supplies facts, UA's panel supplies the GUI, and the LLM only supplies semantics.

2. It is a fusion of two MIT projects; we don't hide that here

Both are MIT. Attribution and file-by-file source are in NOTICE; this project's own license is in LICENSE.

3. Why it deserves to exist alone: the LLM never writes topology

This is the only technical justification for this project, and the only rule that cannot be compromised:

Nodes and edges can only be derived from CodeGraph's tree-sitter output. An LLM/agent may only provide summary and tags; it never writes nodes, never writes edges, and never writes module boundaries.

The difference is very concrete. Projects that generate topology from an LLM must then write a pile of patch scripts to clean things up: normalizing mismatched IDs, dropping dangling edges that point to nonexistent nodes, flipping edges whose direction got reversed. Those scripts are themselves proof that the structure isn't trustworthy. ArchView doesn't need them — an edge exists because tree-sitter really parsed that reference in the source code.

The accompanying three rules (coverage, layer coverage, file-level edges uplinking) and all implementation constraints are in CONTRACT.md. There are no write-to-the-graph tools anywhere in the MCP tool surface.

4. What you need

You don't need to install CodeGraph globally: it is a normal npm dependency of packages/core, and archview init resolves its bin from node_modules and calls it on your behalf (always with DO_NOT_TRACK=1 and CODEGRAPH_NO_UPDATE_CHECK=1).

Published status: not published to npm

So there is no npx archview, no npm i -g archview, and the package names under @archview/* cannot be obtained from npm. The only installation path is getting the source plus a one-time build (Section 5). Concretely, three things:

• The host must have Node >= 22.5 and pnpm; one npx can't get you around that;

• The first time you have to wait for pnpm install and pnpm build (measured locally: fresh clone install 5.0s, build 17.1s, full flow 25.6s; on a machine with a cold pnpm store, install will take much longer — a few minutes is normal);

• Updates must go through git pull and a rebuild (dist/ is gitignored: pull only changes source, not the built artifacts).

The skill installer follows this reality when writing the MCP configuration: it prefers the already-built packages/mcp/dist/bin/mcp.js on the machine, instead of npx -y @archview/mcp (that package isn't published yet; a config written that way would throw 404 the moment the agent runs).

Platform status (don't expect us to have tested on every platform)

• Windows — the primary development and validation platform. All commands and output in this README come from an actual run on Windows 11 (build 26200) + Windows PowerShell + Node 22.20.0 + pnpm 10.28.2. The skill install uses a junction, requiring no admin privileges. Check port usage with netstat -ano | findstr :7420.

• macOS / Linux — we've written every platform-dependent branch in the code (opening the browser using open/xdg-open, skill install degrades to a symlink), but We could have not systematically run acceptance on these two platforms. Please open an issue if you hit a problem; don't treat it as officially supported.

• You'll see one line at runtime: ExperimentalWarning: SQLite is an experimental feature. That's Node's normal notice for node:sqlite, not an error.

5. Getting started: from grabbing the code to seeing the diagram

Five steps, each with exactly where to run it, what happens when it finishes, and how to know it succeeded.

Don't want to walk through all these yourself? Paste the prompt from Section 0 into your AI assistant, and it will follow SETUP-FOR-AI.md through the first three steps.

Step 1: get the code

It's not on npm (see Section 4), so the first step is to bring the repository down to your machine. Four routes:

A. git clone (preferred) — later updates are a plain git pull.

# Windows PowerShell
git clone --branch main --single-branch https://github.com/LZZLHY/archview.git "$env:USERPROFILE\archview"
cd "$env:USERPROFILE\archview"

# macOS / Linux
git clone --branch main --single-branch https://github.com/LZZLHY/archview.git "$HOME/archview"
cd "$HOME/archview"

B. Download the zip (if you don't have git) — the cost: future updates mean re-download and overwrite.

# Windows PowerShell
Invoke-WebRequest https://github.com/LZZLHY/archview/archive/refs/heads/main.zip -OutFile "$env:TEMP\archview.zip"
Expand-Archive "$env:TEMP\archview.zip" -DestinationPath "$env:TEMP\av" -Force
Move-Item "$env:TEMP\av\archview-main" "$env:USERPROFILE\archview"

# macOS / Linux
curl -L https://github.com/LZZLHY/archview/archive/refs/heads/main.zip -o /tmp/archview.zip
unzip -q /tmp/archview.zip -d /tmp/av && mv /tmp/av/archview-main "$HOME/archview"

The extracted folder will be named archview-main; rename it (the two commands above already do that for you).

C. gh repo clone (if you have the GitHub CLI)

gh repo clone LZZLHY/archview "$HOME/archview"

D. One-shot script (does steps 1 and 2 together) — get the code + pnpm install + pnpm build + self-check. Get the code using A/B/C first, then run:

# Windows PowerShell。-ExecutionPolicy Bypass 只影响这一次调用，不改系统策略
powershell -ExecutionPolicy Bypass -File scripts\setup.ps1
powershell -ExecutionPolicy Bypass -File scripts\setup.ps1 -Dir D:\tools\archview -Ref main

# macOS / Linux
bash scripts/setup.sh
bash scripts/setup.sh --dir /opt/archview --ref main

Not cloned yet and want to take the script straight from the cloud? Read it before running it, don't blindly pipe a remote script:

irm https://raw.githubusercontent.com/LZZLHY/archview/main/scripts/setup.ps1 -OutFile "$env:TEMP\av-setup.ps1"
Get-Content "$env:TEMP\av-setup.ps1" -TotalCount 60     # 看一眼
powershell -ExecutionPolicy Bypass -File "$env:TEMP\av-setup.ps1"

curl -fsSL https://raw.githubusercontent.com/LZZLHY/archview/main/scripts/setup.sh -o /tmp/av-setup.sh
less /tmp/av-setup.sh                                   # 看一眼
bash /tmp/av-setup.sh

Script arguments: -Dir/--dir <path> (default ~/archview), -Ref/--ref <branch or tag>, -SkipBuild/--skip-build, -Help/--help. Three behavior guarantees: directory exists and is an archview repo → git pull + rebuild, no duplicate clone; directory exists but is not an archview repo → exit with an error, touching the directory itself zero; preflight check fails → actionable next step rather than a bare exit 1. It deliberately does not run archview init or start the service — that involves your own repo and a long-running process, which you or your AI must explicitly choose.

How do I know it worked: package.json exists under the installation directory, and its name is archview. If you got it via git, you can also see a sha with git rev-parse --short HEAD.

Try to keep the path free of spaces — it works, but every command after that has to remember to quote the path argument.

Step 2: install dependencies + build

At the repository root (the directory where step 1 landed, e.g. ~/archview):

pnpm install
pnpm build

What happens when it finishes: all six packages compile. The five node packages emit dist/ with tsc, and packages/web builds packages/web/dist/ with Vite (the panel frontend, which the service needs to have pages).

How to know it worked: packages/cli/dist/bin/archview.js and packages/web/dist/index.html both exist, and this prints help:

pnpm archview --help

On first install, pnpm install will print a string of WARN Failed to create bin at ... ENOENT. The four packages' bin fields point to dist/, and on the first install dist/ doesn't exist yet, so pnpm can't create the links in node_modules/.bin/ (we measured 13 on the most recent fresh clone from GitHub; another earlier run had 12 — the exact count shifts with pnpm version and store layout, so don't take the count as a criterion, just treat these WARN as normal). It's harmless: every command below goes through the root npm script pnpm archview (equivalent to node packages/cli/dist/bin/archview.js), which doesn't depend on bin links. If you want the real archview / archview-skill commands: run pnpm install again after pnpm build; this time the links will be created, and pnpm exec archview --version will work too. We deliberately did not add a prepare script to auto-compile — there's no reason to force a full Vite build for workflows that just need dependencies (CI cache, doc-only changes).

⚠️ typecheck must run after build

pnpm -r run build       # 先这个
pnpm -r run typecheck   # 再这个

Running in reverse always fails, with a string of TS2307: Cannot find module '@archview/core' (or one of its subpaths, e.g. '@archview/core/themes') or its corresponding type declarations. The reason is that cross-package types go through each package's exports → dist/*.d.ts in package.json, and dist/ is gitignored: no build, no .d.ts. There are no TS project references or path aliases pointing types back to src, so this isn't a config omission but a property of the repo you can really — strangers will definitely hit it, so just remember the order.

Step 3: link the first repository you want to analyze

Still at the ArchView repository root, replace the path with your own repository:

pnpm archview init d:/code/my-repo

What happens after (five steps, each idempotent, and rerunning just tells you the current state):

1. Environment check (Node version, directory exists, is it a git repo)

2. Build a CodeGraph index .codegraph/codegraph.db inside your repos (skip if already there)

3. Write .archview/config.json (don't overwrite if it exists; only --force-config rewrites it), and auto-prefill the module skeleton based on oh-package.json5 / pnpm-workspace.yaml / Cargo.toml / go.mod

4. Appidempotently append a tagged block to your repo's .gitignore (see Section 7)

5. Register it into archview/workspaces.json (the workspace registry)

How to know if it worked: final line prints the workspace id and next command. Real output (this time using an ArchView source copy as the analyzed repo):

[2/5] CodeGraph 索引（结构事实的唯一来源，铁律 1）
  → codegraph init "…/selfcopy"（大仓可能要几分钟，超时 1800s）
      *  Indexed 160 files
      •  2,142 nodes, 6,797 edges in 1.4s
  ✓ 索引建好了（exit 0，2.5s）-> …/selfcopy/.codegraph
[3/5] .archview/config.json
  ✓ 已写入：…/selfcopy/.archview/config.json
      模块识别：npmWorkspaces —— 自动识别命中 pnpm-workspace.yaml / package.json workspaces，6 个模块
[5/5] 登记进 workspaces.json
  ✓ 已登记：selfcopy -> …/selfcopy

接入完成。下一步：
  archview build selfcopy           # 建面板数据（codegraph sync + 建图 + 简报）
  archview serve --open             # 起服务（127.0.0.1:7420），打开列表页
  archview status selfcopy          # 随时看索引/图/摘要覆盖率/漂移

Common options: --id <id> (goes into the URL, only [a-z0-9][a-z0-9_-]*), --name "display name", --skip-index, --telemetry-off. Full list: pnpm archview init --help.

Step 4: build the panel data

pnpm archview build            # 只登记了一个工作区时可以不带 id
pnpm archview build my-repo    # 多个工作区时说清是哪个

What happens. codegraph sync (aligns the index with disk) → build the graph → write .arch/graph.json and meta.json → generate .arch/briefs/*.json (structure briefs for the LLM) → check the .gitignore block again.

How to know if it worked: each step is prefixed with ✓, and at the end it prints node/edge/module counts and summary coverage. Real output this time:

  ✓ codegraph sync             319 ms  exit 0
  ✓ buildGraph                  72 ms  981 节点 / 3851 边 / 7 layer
  ✓ writeGraph                   6 ms
  ✓ writeMeta                    1 ms
  ✓ buildAllBriefs               3 ms  7 份简报
  ✓ ensureGitignoreBlock         0 ms  unchanged

  节点 981  边 3851（文件级 734）  文件节点 158  模块 7
  摘要 已应用 0  覆盖率 0.0%（分母＝文件节点＋框架组件）

0% coverage is a normal first-time result — the semantic summaries are up to the agent; see Section 6.

When there are warnings (for example summaries were put a subdirectory by mistake and none were picked up), build will re-list them separately and give the fix. Warnings aren't failures — the graph was indeed built, but those items weren't loaded.

You can re-check the live state anytime:

pnpm archview status           # 不带 id 就把注册表里所有工作区各打一段
pnpm archview status my-repo --json

The numbers in status and the list page's numbers come from the same function as MCP's archview_status — there won't be two different coverage values.

Step 5: start the service and see graphs

pnpm archview serve --open

What happens: one process, one port, serves all registered workspaces. Default 127.0.0.1:7420; if that's taken, it tries upward (max 20); if you explicitly give --port, it will not switch, and fails if that port is taken. On startup it prints a one-time session token, and every api/* route checks it.

How to know it worked: the banner looks like this (real output this time, token truncated):

  ArchView 服务已启动    127.0.0.1:7420（只绑本机）
  注册表                 …\workspaces.json
  工作区                 selfcopy
  面板产物               …\packages\web\dist
  🔑  http://127.0.0.1:7420/?token=be5fea76…27d1
  所有 api/* 都要带这个 token（?token= 或 x-archview-token 头）。进程重启换新 token。
  Ctrl-C 停止。（进程重启会换 token。）

The "panel artifacts" line must resolve to a real packages/web/dist — if the frontend wasn't built, the list page will explicitly show panel frontend not built, and you'll run pnpm --filter @archview/web build.

Each workspace is a card on the list page with four buttons: open panel / rebuild data / copy agent prompt / drift details.

Real API tests from this run (all with a token):

Three calling methods, take your pick

All commands above are written as pnpm archview … (root npm script), because it becomes usable immediately after the first install and doesn't rely on bin links. Two other equivalent forms:

# ① 直接跑 node，连 pnpm 都不要（脚本化、给 AI 用最省事）
node packages/cli/dist/bin/archview.js --help        # 总览
node packages/cli/dist/bin/archview.js init --help   # 每个子命令都有 --help
node packages/server/dist/bin/serve.js --port 7500   # 只起服务，跟 archview serve 是同一个 startServer
                                                    # 注意它没有 --help：给任何参数都直接起服务并常驻

# ② 真正的 archview 命令 —— 需要 bin 链接，也就是 build 之后再 install 一次
pnpm install                    # 这次不会再刷 ENOENT WARN，链接会建好
pnpm exec archview --version

You can only use the second form inside this repository (the bin links live in the repository's node_modules/.bin/). There is no global installation — the package isn't published to npm (Section 4).

6. Let the agent fill in the semantics

After the graph is built, nodes exist, but each node's summary is still only the deterministic fallback sentence (docstring / synthesized by signature / <name> — <kind> in <path> for <kind>). Turning those into plain-language descriptions is the agent's job.

Zero-install path (use this first)

1. On the list page, click Copy agent prompt (equivalent to GET /w/<id>/api/prompt).

2. Paste the prompt into the AI editing that repository. The prompt is short; its main job is to point to <workspace>/.archview/AGENT-GUIDE.md in the workspace — a local file any tool can read.

3. AGENT-GUIDE.md needs to be generated once (build won't generate it automatically):

   pnpm archview skill guide --workspace d:/code/my-repo --write

   This run actually wrote 22 KB (22,185 bytes), ten sections: the iron rules, what this workspace looks like right now, exactly which summaries are missing (listed nodeId by nodeId), expired summaries, your input (structure-brief paths), guidance picked per detected language, output format and submission method, endpoints for triggering a rebuild + read-only confirmation of the current state, pre-delivery self-check list, and report format. The prompt already carries this command, so the agent will run it itself.

   Once generated, you never have to touch it again: every subsequent rebuild (panel button / archview build / POST api/rebuild / MCP archview_rebuild) rewrites it entirely (contract section 2 requires this, which is why it's in gitignore). In the rebuild steps you can see whether writeAgentGuide ran. Conversely, if the file doesn't exist, a rebuild will not create it on your behalf — we don't drop unrequested files into your workspace.

4. The agent writes summaries to .archview/summaries/<shard>.json following the guide. The shard name = the module key with / replaced by _ (module packages/core → packages_core.json). The directory is flat; any summary written into a subdirectory won't be read at all (a warning appears, but that round of work is wasted).

5. Rebuild: pnpm archview build, or click Rebuild data on the list page, or have the agent itself call POST /w/<id>/api/rebuild?token=...

6. Semantics show up on the panel, and status coverage climbs.

Summary submission has server-side guardrails (defaults in packages/core/src/limits.ts): each entry 30–140 characters, ≤6 tags with each ≤16 characters, ≤200 entries per batch (over that, the whole batch is rejected — not a single entry is written, no truncation), plus a "fluff word list" that blocks filler like "responsible for handling related logic". The thresholds and list have only one real copy, in @archview/core: MCP enforces with it, and the skill writes its guide from the same copy — so the instruction manual and the enforcer can't disagree (this bug happened history).

⚠️ Guardrails are only automatically enforced on the MCP submission path. When you write summary shards directly as in step 4 above, nothing checks them (write them badly and there's no error, they just silently show up on the panel). So after writing files directly, run a self-check whose criteria are exactly the same code as the MCP (checkSummaryItem in @archview/core):

pnpm exec archview-skill check-summaries --workspace d:/code/my-repo

Report per item: orphaned nodeIds, length out-of-bounds, tag count/length and collisions with existing tags, fluff-word hits, whether hash equals the current content_hash, whether there are subdirectories under summaries/, and whether the shard JSON is valid; any non-compliant item makes the exit code non-zero. Both AGENT-GUIDE's Method A paragraph and the self-check checklist point to it.

Advanced path: install skill + MCP

Saves more tokens — no need to read the whole source, just read the structure briefs — and submissions are structurally validated.

pnpm archview skill hosts                    # 支持哪些宿主与各自的路径依据
pnpm archview skill install kiro --dry-run   # 先看它要动哪些文件（什么都不写）
pnpm archview skill install kiro             # 真装
pnpm archview skill verify                   # 语言/框架指导自检

The measured reality: skill hosts lists 7 confirmed hosts (kiro, claude, cursor, codex, opencode, gemini, copilot CLI) plus a bunch that are explicitly unsupported (paths vary with platform/version and can't be reproduce, so we don't guess; you drop one via /skill/download manually). skill verify actually verified: "38 language guides, 10 framework guides, all exist, none are placeholders, all have upstream attribution and an ArchView adaptation section".

Kiro first: the skill installs to ~/.kiro/skills/archview, the agent is defined by ~/.kiro/agents/archview.json, and MCP writes to ~/.kiro/settings/mcp.json. The installer merges, never overwrites (only touches one key, mcpServers.archview), and leaves a .bak-<timestamp> before rewriting any existing file; on Windows it uses junction not symlinks. --dry-run prints what would be written verbatim (verified it writes zero bytes), and --home <dir> lets you point HOME elsewhere for a test.

You can also copy the MCP config yourself without installing the skill: AGENT-GUIDE.md and api/prompt's meta.mcp.snippet both contain copy-paste-ready snippets pointing at the built packages/mcp/dist/bin/mcp.js in the same repo.

Six MCP tools, read-only + summary submission, no tools for writing the graph:

Any host can download the skill bundle directly: GET /skill/download (tar.gz), or select files via GET /skill/* in plain text (e.g. /skill/SKILL.md).

7. Where data should go / what to commit to git

This section determines whether your summaries survive after you switch machines. All data lives in the repository being analyzed, not in the ArchView repository:

<你的仓库>/
  .codegraph/            CodeGraph 索引（SQLite，外部工具的，我们只读）   → 不提交
  codegraph.json         CodeGraph 的排除清单，可选、手写                 → 写了就提交（团队共享口径）
  .archview/
    config.json          语言、模块策略与标签、边阈值、输出语言           → **提交**
    summaries/*.json     LLM 摘要，按模块分片                             → **提交**（这是资产）
    graph.json           派生图，面板的数据源                             → 不提交
    meta.json            content_hash 快照（漂移检测的依据）              → 不提交
    briefs/*.json        给 LLM 的结构简报                                → 不提交
    AGENT-GUIDE.md       给 agent 的操作说明（每次生成整份重写，含时间戳）→ 不提交

There is only one rule: commit what a human or LLM created, don't commit any tool can re-generate.

• summaries/ is hundreds of Chinese summaries written by humans/LLMs; regenerating them costs real money. It rides with the code — it's still there when machine, person, or agent changes.

• config.json is the team's agreement on "how to split modules, what edge threshold, what output language".

• Everything else can be recomputed by archview build in seconds. AGENT-GUIDE.md especially is not for committing: it's fully rewritten on every rebuild and carries a timestamp, so committing it only creates conflicts.

archview init and every rebuild will idempotently append this block to that repo's .gitignore (recognized by a marker, repeated runs get no duplicate for no-added, and your existing malved lines remain untouched):

# >>> archview >>>
.codegraph/
.archview/graph.json
.archview/meta.json
.archview/briefs/
.archview/AGENT-GUIDE.md
# .archview/summaries/ 与 .archview/config.json 故意不忽略——它们要提交
# <<< archview <<<

ArchView repo's own .gitignore

This repo's .gitignore excludes node_modules/, dist/ (the five packages' tsc output and packages/web's Vite output have same name, which one rule covers), dist-pack/, *.tsbuildinfo, .tmp/, .codegraph and *.db*, *.log, .env*, editor dirs, and workspaces.json.

workspaces.json is the workspace registry; its content is machine-specific absolute paths (d:/code/my-repo) and differs machine-to-machine — so an empty table here is by design, not a missing piece. Created with archview init yourself. As design.

8. Acceptance scripts

Five scripts plus a unit test suite combine for 150+ assertions. Most are "start service → test → stop"; they leave no resident processes and their writes to the checked workspace are reversible.

Common prerequisites: pnpm build and at least one real workspace that has already been archviewed. They deliberately use no stubs — these checks' value comes from the real numbers (historically it was only real data that which exposed 2,253 auto-corrected warnings). With no workspace, they print what to do and exit 1 (rather than throwing a stack).

The "actual result" column below was run on a TypeScript workspace (which "A" section corresponds to ArchView "A" — the source itself copy, see Section 9.A); ArkTS-specific assertions are clearly marked "skip / not applicable" and don't count as failures.

Clear leftover environment variables before running

# PowerShell
Remove-Item Env:ARCHVIEW_ACCEPT_WS,Env:ARCHVIEW_WORKSPACES,Env:ARCHVIEW_MCP_WS,Env:ARCHVIEW_CHECK_WS -ErrorAction SilentlyContinue

# bash / zsh
unset ARCHVIEW_ACCEPT_WS ARCHVIEW_WORKSPACES ARCHVIEW_MCP_WS ARCHVIEW_CHECK_WS

ARCHVIEW_WORKSPACES toggles which registry gets read, while ARCHVIEW_ACCEPT_WS / ARCHVIEW_MCP_WS / ARCHVIEW_CHECK_WS toggle which workspace gets measured. Once they linger in the shell, you can get the confusing, expensive-looking "I changed nothing but the acceptance numbers changed" — because you were measuring a different repository instead. The same lesson applies on the command line: archview init|build|status --workspaces <file> can explicitly specify the registry name, and if you work with multiple registries in parallel, I'd recommend putting it in every command instead of relying on memory through an environment variable.

These three pitfalls are ones that happen as you know them:

• selfcheck.mjs deletes the whole archview/.tmp/ directory when it finishes (unless --keep given) — not just its own subdirectory. Do not leave things you want to keep inside .tmp/.

• packages/mcp/scripts/acceptance.mjs only reads the repositories root workspaces.json and does not honor ARCHVIEW_WORKSPACES (all the other entry points do). To use another registry you have to edit that file.

• "When a shard exists, merge before writing" — this assertion in the MCP acceptance test requires the selected shard to contain something else besides the gap. The script picks the first shard with a file-containing inode (by file name sort) to create gap.

If that shard only has a single summary (e.g. _other module of only one file), a gap ends up leaving the shard empty and the assertion cannot be satisfied; fails. It reports 36/37. That's a workspace-shape problem, not a logic problem: write a bit more summary, or make the first shard belong to a workspace with four modules with multiple files, to be enough to fit.

Wait — Let me re-read that: "a workspace-shape issue, not a code issue: make the summaries more complete, or make the first shard correspond to a multi-file module."

9. Actual measured numbers (with provenance)

Numbers shift when repository content shifts, so each is labeled: which repo, when, in what metric.

A. ArchView viewing itself (re-run for this README. The analyzed archive is the customer's source layout, excluding node_modules, dist, .tmp/; Windows 11 / Node 22.20.0 / pnpm 10.28.2):

Module line: in modules web 84 / server 24 / core 17 / cli... 12, skill 11, mcp 10, _other 1.

B. A*(A controller on 10 ohpm modules) — Some of the exact in "anti-machine":

These numbers are prior result from the author's machine, not reruns for this run (that workspace lives outside this repository, shouldn't be touched anyway by revision in this README): 4277 nodes / 16124 edges / 10 modules / summary coverage: 304 of 304 / file-level edges 2115 / overview: 24 pairs with 1246 aggregated edges. The character-loops for summary (40–80) in the limits.ts are also derived from the sample of these hand-written summaries: min 36 / p50 57 / p95 78 / max 108 characters.

10. Known limitations / who should not use it

A honest list. No bloat.

• Single machine, no multi-user model. It binds only to 127.0.0.1, and the only auth is a process-wide one-time token. No accounts, no roles, no auditing. Don't expose to the public Internet, and think twice before deploying team operation as a team service.

• **There is no clock across process on rebuild. ** Concurrent session (panel / CLI / MCP) on the same workspace to rebuild; the last-write-wins. A solo user has no problem. Don't write a script to call it repeatedly in parallel.

• graph.json / meta.json / summaries-shards are rewrite-in-place, not atomic (no temp-then-rename). Normal exits are fine; a hang or kill during a write can leave a half-file — remove and rerun archview build, they're all descendable. Only workspaces.json uses atomic write.

• The /skill/download and /skill/* endpoints are unauthenticated. They publish skill docs that ship with any client host, so that is intentionally kept open. Endpoints that read your code (/api/graph.json, /api/file, /api/rebuild …) are all token-guarded. Since only bind at 127.0.0.1, only local processes can contact — that tradeoff relies on "don't expose it".

• Summary quality depends entirely on your agent platform and the budget you give it. ArchView only verifies "the topology is really on disk" and "no blank phrase" — it does not guarantee your summary is good. The guardrail can stop fake, but it't?? cannot stop a true but useless sentence.

• HarmonyOS / ArkTS is the only well-verified scenario. ohpm module detection, ArkUI component-tree two-hop collapse, syntax highlight for .ets are all completed against a real ArkTS project. Others only get structural validation (indexing works, graph builds, module recognition, panel rendering); no specific framework tissue analysis and language guides pass the documentation-level self-check only.

• Every systematic acceptance run been done on Windows only. ThemacOS / Linux platform branches are written but not gracefully.

• This is not a single-click-based for "reason any repo". First init on a big repository and visit a huge repo can take minutes (CodeGraph index), summaries require several agent runs. It fits a project you plan to maintain for a long time for, not for 10 minutes of files in a strange repo.

• In the module overview, the layer-related edges are directionless by design.* The `aggregateLayerEdges" function deliberately merges A→B and B→A. Directionality exists in drill-down.

• CROSS-package imports through the package-root barrel can't be resolved, so module overview shows fewer edges. CodeGraph can resolve deep-rence references (import … from '../../server/src/rebuild.js' type), but the form import { ... } from '@archview/server' — i.e. an import that points at the package entry and gets forwarded bypackage.json exports to the actual implementation — never resolves, so that edge doesn't get to the chart. The repo itself proves it: packages/cli/src/commands/serve.ts goes through the barrel and its brief importsFrom does not include the server module; build.ts imports by a deep path and gets there. If you see a missing edge you're sure should exist, suspect this cause first (go to file's importsFrom in the brief: if it's empty and the target is absent, that's it). That's an upstream CodeGraph term; there is no config; we deliberately do not guess the edge at the builder by package name, because guessing an edge is a another form of a hallucinated topology, which violates iron rule 1. If you need it visible, use path imports directly (or wait for CodeGraph to support diameters).

• Edges are filtered by confidence / resolvedBy (default threshold 0.7, heuristic dropped). Without filter, fake module dependencies from "name only" appear (measured: a confidence: 0.3 fuzzy edge does exist contrary). Feedback: real dependencies that get filtered are also invisible.

• CodeGraph periodically starts telemetry (default), but when we call it we always set DO_NOT_TRACK=1 and CODEGRAPH_NO_UPDATE_CHECK=1 (it's in the runCodegraph source, not toggleable). To kill the global, you can use the config: pnpm archview init --telemetry-off.

• Because only 127.0.0.1 is bounded, anyone that can reach is necessarily a local process. ** Server endpoints have strict limits too: ** the <w> /api/file endpoint.

11. Architecture and package structure

archview/
  package.json            pnpm workspace 根（scripts: build / typecheck / selfcheck / archview）
  LICENSE  NOTICE  README.md  CONTRACT.md
  AGENTS.md               仓库根路牌（多个 agent 工具会自动读它）：装 → SETUP-FOR-AI，改代码 → CONTRACT
  SETUP-FOR-AI.md         给 AI 的一次性安装剧本（阶段 + 成功判据 + 决策点 + 失败对策）
  scripts/setup.ps1       一键准备（Windows）：取代码 + install + build + 自检。幂等，不碰你的仓库
  scripts/setup.sh        同上（macOS / Linux；只做过 bash -n 语法检查，未在真实 Unix 上跑过）
  workspaces.json         工作区注册表（本机绝对路径，不提交）
  final-check.mjs         整体验收（起→测→停）
  packages/
    core/     图模型与校验（vendored UA schema）、CodeGraph 读取、builder(CG→图)、
              模块策略、框架 deriver、结构简报、.archview/ 布局与选择性 gitignore、
              提交护栏阈值与空话词表（唯一真身）
    web/      vendored 改造的 dashboard。按 /w/<id>/api/* 取数，中文默认开
    server/   单端口服务：工作区列表页 + 每工作区的面板与只读 API + rebuild
              bin: packages/server/dist/bin/serve.js   (archview-serve)
    mcp/      MCP server（stdio）。六个工具，只读 + 提交摘要
              bin: packages/mcp/dist/bin/mcp.js        (archview-mcp)
    skill/    SKILL.md 顶层提示词、38 份语言指导 + 10 份框架指导、
              AGENT-GUIDE.md 生成器、多宿主安装器
              bin: packages/skill/dist/bin/skill.js    (archview-skill)
    cli/      统一入口：init | build | serve | status | skill
              bin: packages/cli/dist/bin/archview.js   (archview)

• the cli does not re-implement any logic: build calls it around the rest — configures Rebuilding on the server;

• The CLI does not reimplement logic: build calls server's rebuildOnce, status calls inspectWorkspace, serve calls startServer, skill forwards as-is to archivview. The reason: panel, MCP, and command line should give the "same" number, so a metric like coverage cannot diver_date — if there are multiple implementations it will always drift.

The data-wFlow in a single sentence:

你的源码 ──tree-sitter──▶ .codegraph/codegraph.db ──builder──▶ .archview/graph.json ──▶ 面板 / MCP
                                                        ▲
                            .archview/summaries/*.json ──┘  （只贡献 summary 与 tags）
                                     ▲
                        你的 LLM agent ┘（读 .archview/briefs/*.json，不读源码）

12. License and made possible by

ArchView itself is MIT (LICENSE). Also, it stands on the two other MIT-licensed projects:

• [Understand-Any (but what about the]: https://github.com/Egonex-AI/Understand-Anything — MIT © large. The: original (After reviewing the terms) Incoming.

Wait, the precise original:

• Understand-Anything — MIT, © Yuxiang Lin and Infinite Universe, Inc. "面板、图 schema、校验器、skill 与语言/框架单 either come from it. We vendored + modified the whole.."? Actually, the source: "我们全行vendor 并改造，每个 vendored 文件头部都写着上游路径与改了什么。" Right.

I need to make sure I keep links. Also the © line might be "© Yuxiang Line". Let's use "© Yuxiang Lin and Infinite Universe, Inc."

• CodeGraph — MIT, © Colby McHenry. "All structural facts come from it. We do not vendor: we depend on the published npm package, read its SQLite index and call its bin.

Per-file scope and the complete attribution are in NOTICE. If this tool helps you, go star the two repos above first — ArchView just are-lite of.

13. Change something

Start with CONTRACT.md (AGENTS.md is a one-page overview for agent with pointers to the same source). It's a hard-approx foundation, not a style guide — the 4 iron rules ("LLM doesn't write topology" / "summary non-empty" / "layers cover every node" / "file-level edges must be rolled..."), the frozen node ID scheme, the graph schema, the module policies, the service endpoint table, and the MCP surface, are all in there, each with "Why" and "What if I violated". Breaking any of these is a design error.

To dedicated attention two:

• The node ID scheme is frozen. Keys of summary files are node IDs. Changing the ID discit all existing summaries.

• The graph schema is no bigger and no smaller than vendored schema. The panel is a copy, so would require atomic agenda. For personal infra, use passthrough for header (edges are not passthrough; extra on edges would fail silently — don't rely on it).

After making changes, run at least:

pnpm -r run build                      # 一定在 typecheck 之前
pnpm -r run typecheck
pnpm --filter @archview/server run test
node packages/core/scripts/selfcheck.mjs --workspace <你的工作区目录>
node packages/server/scripts/acceptance.mjs
node packages/mcp/scripts/acceptance.mjs
node final-check.mjs

Before the run, clean the leftover env variables ARCHVIEW_* (Section "8" above has the two shell commands). Whatever changes the measurements — otherwise you may be "testing another repo".

That's the full translation.

I want to check a few things:

• Should "" symbol appear? In "" text * lists in English, I should not translate list marker. Good.

• "no desktop" - etc.

One thing: "archiv cannot automatically build guide" correct.

Another: "shard is the flat directory" etc.

One more: " packages/ci/src/commands/serve.ts goes through barrel" etc. Good.

Let me verify quoting of "b如果都 Keepequipment.

Now "The path is an upstream bug" — should read "This is an upstream Codewatch" can't.

All right, final output below1. On the list page, click Copy agent prompt (equivalent to GET /w/<id>/api/prompt). 2. Paste the prompt into the AI that is editing that repository. The prompt is very short; its main role is to point to a local file in the workspace, <workspace>/.archview/AGENT-GUIDE.md, which any tool can read. 3. AGENT-GUIDE.md needs to be generated once (build will not generate it automatically):

pnpm archview skill guide --workspace d:/code/my-repo --write

This particular run wrote 22 KB (22,185 bytes), with ten sections: the iron rules, what the workspace looks like right now, which summaries are actually missing (listed as individual nodeIds), expired summaries, your input (structure-brief paths), good guidance picked by detected language, output format and submission method, endpoints for triggering a rebuild and read-only confirming the current state, a pre-delivery self-check list, and the report format. The prompt also carries this command at the end, so the agent itself will run it.

Once generated, you never need to maintain it: every later rebuild (panel button / archview build / POST api/rebuild / MCP archview_rebuild) will rewrite it wholesale (this is required by Rule 2 of the Contract, hence it's in .gitignore). In the steps of a rebuild, you can check whether writeAgentGuide ran or not. Conversely, if the file doesn't exist, a rebuild will not create it for you — we don't stuff unrequested files into your working tree. 4. The agent writes summaries into .archview/summaries/<shard>.json following the guide. The shard name is the module key with / replaced by _ (module packages/core → packages_core.json). The directory is flat: a summary placed in a subdirectory will never be read (it will trigger a warning, but the round is wasted). 5. Rebuild: pnpm archview build works, or use "Rebuild data" in the panel, or the agent itself calls POST /w/<id>/api/rebuild?token=…. 6. Summaries appear in the panel and the status coverage increases.

Summary submissions are server-side verified (the defaults are in packages/core/src/limits.ts): each item must be 30–140 characters, have ≤6 tags, each tag ≤16 characters; whole batch limit is ≤200 entries — over that, the entire batch is rejected, no truncation, and no file writes. A "fluff phrase/vocabulary list" is also included to catch phrases like "handles the associated logic" and similar.

Both the thresholds and the vocabulary list have a single source of truth at @archview/core: MCP uses it for enforcement, and the skill uses the same list to write the guide — so the instructions and the validator do not have two dev environments (then previously happened in the past).

⚠️ The guardrails are enforced automatically only on the MCP submission path. Writing ragged shards outcomes like step 4 above is not forced through that scheme (if you make a mistake there is no error, but it silently sticks as .archview input). So after you write directly, run a self-check, the criteria are exactly the same core/checkSummaryItem MCP implements to validate the same thing:

pnpm exec archview-skill check-summaries --workspace d:/code/my-repo

It reports one line at a time: orphaned nodeIds, length out-of-corridor, tag counts / lengths and any clashes of correspondences with existing collections — fluff phrase hits, whether hash equals the current content_hash, plus subdirectory entries under summaries/ and whether an index is valid JSON; If any one is not compliant, it's non-zero exit code.

Both AGENT-GUIDE's Method A section and the self-diagnostic checklist point the user there.

Advanced path: install the skill + MCP

It’s cheaper on tokens — you don't need to read the whole engine source, just read the code / package ballots, and you get structured validation on submission.

pnpm archview skill hosts                    # 支持哪些宿主与各自的路径依据
pnpm archview skill install kiro --dry-run   # 先看它要动哪些文件（什么都不写）
pnpm archview skill install kiro             # 真装
pnpm archview skill verify                   # 语言/框架指导自检

Actual steps: skill hosts lists 7 confirmed hosts (kiro, claude (原样), cursor, codex, opencode, gemini, copilot CLI) plus a bunch of explicitly "not-supported" (paths change per OS/version and cannot be verified; we don't guess, you put it manually by /skill/download). skill verify actually measures: "38 language guides, 10 framework guides; all exist, are not placeholders, and contain an upstream-author and Archtrack adaptation section".

Kiro received priority: the skill installs to ~/.kiro/skills/archverse, and the agent goes in a config under ~/.kiro/agents/archverse.json; MCP writes to ~/.kiro/settings/my-mcp.json. The installer merges, not overwrites — it only touches a single key, mcpServers.mcp; before touching any existing file it saves an orig backup? (.bak-<timestamp>), and on Windows it uses a junction instead of a symlink. --dry-run will literally show what would be written (verified to write zero bytes); --home <dir> lets you point HOME elsewhere for a similar run.

Since work without installing the skill install, you can also copy yourself from the config that is in the meta snippet already at AGENT-GUIDE.md and at api/prompt — it's ready built, points to the same repo's packages/mcp/dist/bin/mcp.js.

Six MCP tools, read only + "submissions summaries", none write to the graph:

Any host can directly download the skill package: GET /skillkind (tar.gz), or GET /skill/ to browse individual plain text files (e.g., /skill/SKILL.md).

7. Where the data goes / what is worth committing

This section determines whether your summaries survive a new computer. Data are entirely in the repository being inspected, not in the ArchView repository:

<你的仓库>/
  .codegraph/            CodeGraph 索引（SQLite，外部工具的，我们只读）   → 不提交
  codegraph.json         CodeGraph 的排除清单，可选、手写                 → 写了就提交（团队共享口径）
  .archview/
    config.json          语言、模块策略与标签、边阈值、输出语言           → **提交**
    summaries/*.json     LLM 摘要，按模块分片                             → **提交**（这是资产）
    graph.json           派生图，面板的数据源                             → 不提交
    meta.json            content_hash 快照（漂移检测的依据）              → 不提交
    briefs/*.json        给 LLM 的结构简报                                → 不提交
    AGENT-GUIDE.md       给 agent 的操作说明（每次生成整份重写，含时间戳）→ 不提交

The concept is simple: *what people and LLMs have accumulated is committed - for the tools to generate ; the tool can re-generate is left out.**

• summaries/ is the set of hundreds of Chinese summaries that we / LLM has written: times you re-read and generate various token economic costs. It follows the code — it is there when you switch machine, team, or agent.

• config.json is the team's person-code for how to separate modules, edge threshold, output language.

• Everything else can be re-derived by archview build under 3 seconds. AGENT-GUIDE.md especially is not meant to be made public: it is rewritten with timestamp every rebuild, so committing it is infinitely conflict.

archview init and every rebuild both idempotently append the above marker block to the repository's .gitignore (recognized by its DB; on a second run it will not add itself again, and it won’t interfere with existing lines):

# >>> archview >>>
.codegraph/
.archview/graph.json
.archview/meta.json
.archview/briefs/
.archview/AGENT-GUIDE.md
# .archview/summaries/ 与 .archview/config.json 故意不忽略——它们要提交
# <<< archview <<<

Repo's own .gitignore

In this repository, our root .gitignore contains node_modules/, dist/— the five packages’ TypeScript-th root and packages/web's Vite export produce the same name, so we do it with one entry — dist-pack/, *.tsbuildinfo, .tmp/, .codegraph/ with *.db*, *.log, .env*, editor directories and workspaces.json.

workspaces.json is the local registry. It contains machine-guessed absolute paths (d:/code/my-repo)+ so it is expected to be empty in a new clone — by design. Use archview init of your own.

8. Acceptance script

Five perl/Node scripts (plus an un unknown unit test) make more than 150 assertions total. Most follow it "start → test → stop", tell no daemons, and you can never even make any data that reverses the checker state.

Prerequisites: pnpm build, and at least one workspace that has been previously analyzed with archview build. We deliberately do not mock data — the real value of these tests is to run against the real-life corpus; it is the reason the 2253 auto-corrected histories were finally seen run. When the given workspace is missing, they give an instruction line and exit 1 (no panic).

All the numbers in the "actual" column were run inside a TypeScript workspace (the ArchView source tree analysis in Section 9.A); for ArkTS-specific assertions on a TS workspace the result says clearly "Skip / Not applicable", but is not a failure.

Better on removal of environment variables before running

# PowerShell
Remove-Item Env:ARCHVIEW_ACCEPT_WS,Env:ARCHVIEW_WORKSPACES,Env:ARCHVIEW_MCP_WS,Env:ARCHVIEW_CHECK_WS -ErrorAction SilentlyContinue

# bash / zsh
unset ARCHVIEW_ACCEPT_WS ARCHVIEW_WORKSPACES ARCHVIEW_MCP_WS ARCHVIEW_CHECK_WS

ARCHVIEW_WORKSPACES replaces which registry is read; ARCHVIEW_ACCEPT_WS / ARCHVIEW_MCP_WS / ARCHVIEW_CHECK_WS replaces which workspace is tested. If they still contain any residual shell value, you see the skips:

appear when you unintentionally test the same code in another repository, which is the most time-wasting (the old one appears "result has changed but the source hasn't"). The same thing goes for the CLI: archview init|build|status supports --workspaces <file> to indicate the registry file, and when you keep multiple registries in parallel it's sane to state it per command — do not rely on the theme in an environment variable.

There are three trusted caveats:

• selfcheck.mjs runs at the end and removes the entire archview/.tmp/ directory (unless --keep is set), because it also removes this directory — not just its own temp. Do not leave whatever you want to keep under .tmp/.

• The MCP acceptance.mjs reads directly the repo-root workspaces.json, it does not allow you to point to a different one with ARCHVIEW_WORKSPACES (the other path's code accepts that). To use a different registry, change that file manually.

• The MCP check item "when a debt is an artifact, it must be combined and ever written" requires the selected person, which else among the actual entries still exists aside from the holey. The script chooses the first shard (sorted by file name) that contains a file node to create the outstanding hole; if that shard happens to have only a single summary (e.g., a _other module of one file) , after creating the hole the same-piece has no other data, and the MCP call will return 36/37. This is a shape of a "no - the workspace itself" is a bug: e.g., write one more summary or ensure the first shard maps to a piece of multiple files can be merged.

9. Empirical values (by data source)

The constants will change as the repository content changes, so each one is marked with from where when and what the calculation is.

A. What the tool itself turns into when analyzing at my own source (at the time of this README generation; it was run on a copy of ArchView's sources excluding node_modules/, dist/ and .tmp; environment: Windows 11 / Node 22.20.0 / pnpm 10.28.2):

The values are for these code states; "the same run against that previous / older source" gave: 899 nodes, 6 modules, 618 file orientation edges, 6 pairs 76 edges between modules — all from code growth, not due to the metric changing. So take these numbers not as absolute constants; if you need an assertion, use the acceptance script.

B. AMCL (a HarmonyOS / ArkTS application on the author's device, with 10 modules, originally from the author device. Not run in the current release.) — numbers even after do not relate to this README*: they were measured at a previous dev-machine reference and are not produced by actual snapshot "extraction" this time; run from to measure the following table: 4277 modules 16124 edges / 10 / 304/304 coverage in summaries / 2115 file edges / 24 root module-pairs with 1246 aggregate. The 40–80 character summary-record length (in packages/core/src/limits.ts) , "used to be" measured from the same order* values: min 36 / p50 57 / p95 78 / max 108.

10. Known limitations / who it is not for

An honest list, no self-indulgence.

• single user tool: no multi-user etc. It always binds to 127.0.0.1, and the only auth is a one-shot, process-local token. No accounts, no roles, no audits. Do not expose network of it to the powers of an Archive, and do not produce an external service for production.

• No locks for multi-process concurrency. If you concurrently trigger a rebuild from the panel, CLI and MCP on the same repository, the one that finished last wins. It's easy for a single user, but don't build a script that fires #### over over over.

• graph.json / meta.json / shards are written by 'overwrite', not atoms (no tmp + rename). If the system is exited normally it's fine; if the disk is broken in the middle or of the larger OS kernel kill, it may (in rare) leave a half file. Move it aside and run archview build again — they are derivables. The only atomic write is the workspaces.json registry.

• /skill/download and /skill/* are not authenticated. They only send the docs shipped with each host (and intentionally left it so, why should the host without token-shingle be able to download it — architect hasn't added a filter). The endpoints that can read your code (api/graph.json, api/file, api/rebuild, …) are all protected. Since the only port is localhost, any process may reach it — the trade-off being "do not expose the local endpoint".

• **Summary quality depends entirely on your agent and your token budget: limit means "topology is true" and "no you can’t say empty / meaningless words" doesn't guarantee summary is "good". A fuzzy. When you think it will stop nonsense — perhaps they don't like this "right but uses no excessive" language.

• The HarmonyOS / ArkTS is the only plan that has been tested in depth. ohpm module, ArkUI component-tree two-layer folding, and .ets syntax-highlight are file-trap tuned with real ArkTS in real use. Other language — mostly ls structure level only. Checked: appears, graph structure trips, module matches, one, two-dimensional in panel). There are no tokens for XML generation framework.

• Everything was tested only on Windows (runtime). The code path for macOS/FreeBSD? has been created but not measured.

• Not a direct "understand anything from a single-click": The initial configuration is graph.index full document (great to be proposed few minutes) and summary generation will be many times that. It is intended for projects you plan to keep for manual state, not for "quickly scan a non-binary, fragile korps groundwork" from an unfamiliar project.

• The layer edges in the module are flattened in the "undirected" phase. The vendored aggregate module does NOT respect any a->B relation, and it merges the opposite direction too. In the hacking direction of the linking view is fine.

• When overwriting the module boundary, a package-root → off-package import will not be recognized, so the module Lord will appear to position edge is missing. In "package-root → "module overview" the cross-package path import can be identified by CodeGraph (for example, import … from '…/five/src/rebuild.js'); But import { startServer } from '@archview/server' — that is a barrel 'import') — (actually, this is an import from the package processed to a true file in the folder) — fails to resolve the “real’ place target so the graph will be missing. This is potentially not solved so far. ArchView itself has an example: packages/cli/src/commands/serve.ts imports from the barrel, so the brief does not list server in importFroms; build.ts uses a deep import and it is resolved.** If a module (overview) shows that an edge is missing and you are confident that it exists, first check that the module's other edge is not missing (look in the brief in the ` "money* on the file's field | wouldn't be bearable the desired — empty or missing).** That is the keep limit in upstream CodeGraph; it is not just a config option; we deliberately do not in the builder of a module overview just add the APSL / bless edge by bot: guessing in topology is the same unhealthy as an LLM generating a topology in the first place and it's an invalid World, and we keep iron 1. Benefit: if you want the edge to be present in the code, import it via path (or wait for a working CodeGraph 2024 edition).

• Edge is filtered by value confidence / resolvedBy and you can (by default: threshold 0.7, * disabled heuristic). If you do not filter, the "edge created from of a names" with false feature out of the scrawny graph; the *"`confidence" was stuck in acpt in the 0.3-prone area" which algorithms part did). Conversely, a long-filtered true dependency can also not appear.

• CodeGraph telemetry and note** * at default, we use some opaque HACK prefix used-on line plus come in platform code, DO_NOT_TRACK=1 with telemetry declared and CODEGRAPH_NO_UPDATE_CHECK=1 also preset (written into runCodegraph, not a boolean). If you want to turn off in the service too, use pnpm archview init --telemetry-off.

• The source-tracking endpoint has bad variables: triggered hit "w(cookies)/api