Navegador is built around a single observation: **code structure and business knowledge are both graph-shaped, and they belong in the same graph.**
6
7
Most context tools for AI agents handle one or the other — either they parse code (AST tools, code search) or they surface docs (RAG over wikis, ADR files). Navegador stores both in the same property graph and connects them with typed edges. An agent asking "what does `process_payment` do?" gets back not just the function signature and call graph, but the business rules that govern it and the architectural decision that shaped its design — in a single structured query.
Populated automatically by `navegador ingest`. Contains the structural facts extracted from source code across 13 languages: which functions exist, what they call, which classes inherit from which, what decorators are applied. Supports incremental ingestion (content hashing), watch mode, and parallel processing. This layer changes whenever code changes; re-ingest is the refresh mechanism.
59
60
### Knowledge layer
61
62
Populated by humans (via `navegador add`) or semi-automatically (via wiki, Planopticon, ADR, OpenAPI, and PM ingestion). Contains the *why*: business concepts, architectural rules, recorded decisions, domain ownership, and documentation. This layer changes slowly and deliberately.
63
64
### Enrichment layer
65
66
Framework enrichers run after AST parsing to add framework-specific metadata — Django model field types, FastAPI route paths, React component display names, etc. VCS adapters (Git, Fossil) provide blame, history, and churn data. CODEOWNERS files are parsed to populate `Person`→`File` ownership edges.
67
68
### Analysis layer
69
70
Graph analysis commands operate over the populated code and knowledge layers without additional ingestion. They run Cypher traversals for impact analysis, cycle detection, dead code detection, test mapping, and community detection.
71
72
### Intelligence layer
73
74
NLP and LLM commands (`navegador ask`, `navegador semantic-search`, `navegador docs`) use configurable LLM providers (Anthropic, OpenAI, Ollama) to answer natural language queries grounded in graph data.
75
76
### Cross-layer edges
77
78
| Edge | Meaning | Direction |
79
|---|---|---|
80
| `ANNOTATES` | A knowledge node describes a code node | Concept/Rule → Function/Class/File |
81
| `GOVERNS` | A rule applies to a code node | Rule → Function/Class |
82
| `IMPLEMENTS` | A code node implements a concept or interface | Function/Class → Concept/Interface |
83
| `DOCUMENTS` | A wiki page documents a concept or code node | WikiPage → Concept/Function/Class |
84
85
These edges are created explicitly via `navegador annotate` or inferred during wiki/Planopticon ingestion when names match.
86
87
---
88
89
## FalkorDB as the store
90
91
Navegador uses [FalkorDB](https://www.falkordb.com/) — a property graph database with a Cypher query interface.
92
93
| Environment | Backend | Install |
94
|---|---|---|
95
| Local dev | `falkordblite` (SQLite) | Included in `pip install navegador` |
96
| Production / team | FalkorDB on Redis | `pip install "navegador[redis]"` |
97
98
Both backends implement the same `GraphStore` interface. The query path is identical; only the connection setup differs. The SQLite backend uses an embedded engine — no daemon, no port, just a `.db` file.