How anandb71/arbor works
1. Top-level shape
Arbor is a Rust monorepo centered on a shared indexing and graph-analysis engine. Most runtime logic lives in Rust crates under crates/, with separate client surfaces for CLI, server/MCP, desktop GUI, and a Flutter-based visualizer.
2. Core architecture
The architectural center is arbor-core plus arbor-graph. arbor-core handles source parsing and language-specific extraction, while arbor-graph turns extracted symbols and references into a queryable dependency graph with ranking, confidence, impact, slicing, and search support.
3. Source ingestion and parsing
Input starts from a local codebase on disk. arbor-core contains the parser pipeline, per-language adapters under src/languages/, and a fallback_parser for weaker support cases, so the system can ingest multiple ecosystems without depending on a single language frontend.
4. Graph construction and storage
Parsed nodes and edges flow into arbor-graph’s builder/store layer. The graph crate also maintains derived structures such as a symbol table, search index, heuristics, and confidence scoring, which are used to answer impact and traversal queries efficiently.
5. Analysis layer
Query-facing logic is built on top of the graph, not on raw text search. The main architectural outputs are caller/callee traversal, path finding, blast-radius analysis, and “slice” style dependency views that explain what changes are likely to affect.
6. CLI as the primary operator
arbor-cli is the main user entry point and drives setup, diff, refactor, check, and summary-style workflows. It is the command boundary that invokes the shared core to index a repo, inspect changes, and gate risky edits, including Git-aware checks for uncommitted or PR diffs.
7. Incremental updating
arbor-watcher provides the always-on indexing path. It watches the filesystem, feeds change events into an indexer, and keeps the graph cache fresh so Arbor can support near-real-time updates instead of only full re-scans.
8. Service and protocol layer
arbor-server packages the core engine behind a reusable protocol/handler/server boundary, with a sync_server suggesting incremental or stateful synchronization. arbor-mcp wraps that capability for MCP clients via stdio, exposing the same graph reasoning to agents and IDE assistants without duplicating analysis logic.
9. User interfaces
There are two visualization frontends: arbor-gui is a Rust desktop GUI, and visualizer/ is a Flutter/Dart app with its own graph rendering, force layout, and websocket service. Both sit above the same graph data model and are presentation layers rather than separate analysis engines.
10. Language and ecosystem boundaries
Language support is broad and explicit: Rust, TypeScript, Python, Go, Java, C/C++, C#, Dart, and several fallback-parsed languages. The repo is also packaged for multiple distribution channels—Cargo, npm wrapper, Homebrew, Scoop, Docker, VS Code extension, and GitHub Actions—which makes the core engine reusable across CLI, IDE, CI, and agent workflows.
11. Tests and operational surfaces
The workspace includes integration tests for CLI commands and GitHub workflows for Rust CI, release automation, MCP validation, marketplace publishing, and container builds. That tells you the repo is designed as a local-first analysis engine with multiple delivery surfaces, not a single application binary.
Main entry points: query.rs Analysis · builder.rs Graph builder · main.rs CLI · parser.rs Parser
Components 18
Core engine
Parsing, graph construction, and query analysis.
- Parser · Source ingestion, language adapters, and fallback parsing.
crates/arbor-core/src/parser.rs - Languages · Per-language extractors for supported ecosystems.
crates/arbor-core/src/languages/mod.rs - Fallback · Weaker parsing path for partially supported inputs.
crates/arbor-core/src/fallback_parser.rs - Graph builder · Builds and stores symbol and edge data from extracted nodes.
crates/arbor-graph/src/builder.rs - Analysis · Traversal, path finding, impact, and slice-style dependency queries.
crates/arbor-graph/src/query.rs - Indexes · Symbol table, search index, ranking, heuristics, and confidence support.
crates/arbor-graph/src/search_index.rs
Command and service surfaces
CLI and protocol layers that invoke the shared engine.
- CLI · Primary local operator for indexing, diffing, refactoring, and checks.
crates/arbor-cli/src/main.rs - Watcher · Filesystem monitor that keeps the graph fresh from change events.
crates/arbor-watcher/src/watcher.rs - Server · Reusable handler and server boundary for graph reasoning.
crates/arbor-server/src/server.rs - Sync server · Stateful or incremental synchronization path on top of the server.
crates/arbor-server/src/sync_server.rs - MCP · Exposes Arbor capabilities to MCP clients and agents.
crates/arbor-mcp/src/lib.rs
User interfaces
Desktop and visual frontends over the same graph model.
- GUI · Native desktop interface over the shared analysis engine.
crates/arbor-gui/src/main.rs - Visualizer · Flutter/Dart visualization frontend for graph exploration.
visualizer/lib/main.dart - Graph view · Force layout, painting, and graph interaction in the visualizer.
visualizer/lib/graph/graph_widget.dart - Websocket · Live data transport used by the visualizer frontend.
visualizer/lib/services/websocket_service.dart
Packaging
Repository entry points and release/distribution wrappers.
- VS Code · Editor extension surface for Arbor features.
extensions/arbor-vscode/src/extension.ts - NPM wrapper · Node-based launcher and install wrapper for the CLI.
packaging/npm/bin/arbor.js - Homebrew · Homebrew distribution entry for the CLI.
packaging/homebrew/arbor.rb
Connections 19
- Languages → Parser: feed parsers · Language-specific extractors plug into the shared parsing pipeline.
- Fallback → Parser: fallback input · Fallback parsing handles weaker or partially supported source files.
- Parser → Graph builder: emit symbols · Parsed nodes and references are handed off for graph construction.
- Graph builder → Indexes: populate indexes · The store layer also maintains symbol and search-oriented structures.
- Graph builder → Analysis: serve graph · Built graph state becomes the basis for traversal and impact queries.
- Indexes → Analysis: accelerate queries · Indexes and heuristics support faster graph analysis.
- CLI → Parser: index repo · CLI commands drive parsing and indexing of local codebases.
- CLI → Analysis: inspect changes · CLI workflows query the graph for diff, refactor, and summary actions.
- Watcher → Graph builder: refresh graph · Filesystem events are turned into incremental indexing updates.
- Server → Analysis: answer requests · The server exposes graph reasoning through its protocol boundary.
- Sync server → Server: sync state · Incremental synchronization builds on the main server implementation.
- MCP → Server: wrap protocol · MCP reuses the server-side analysis rather than duplicating it.
- GUI → Analysis: visualize analysis · The desktop UI sits on top of the shared graph engine.
- Visualizer → Graph view: render graph · The Flutter app delegates layout and painting to its graph view.
- Visualizer → Websocket: stream data · The app receives graph updates over websocket transport.
- Websocket → Server: sync graph · The visualizer talks to the shared server layer for live data.
- VS Code → MCP: assistant bridge · The extension surface connects editor workflows to Arbor capabilities.
- NPM wrapper → CLI: launch cli · The npm packaging layer wraps the main command-line entry point.
- Homebrew → CLI: install cli · Homebrew distributes the command-line tool as a packaged binary.