A working memory for your codebase.

What it will know

Across both frameworks: files, packages, modules, classes, interfaces, methods, functions, fields and annotations; definitions, references, imports, inheritance, implementation, calls, reads and writes; test-to-production relationships; configuration and build targets.

• Android — Gradle modules, plugins, dependencies, variants, namespaces and application IDs; AndroidManifest components and permissions; Activities, Fragments, Compose routes and screens, XML layouts and ViewModels; repositories, use cases, data sources, Retrofit APIs, DTOs and mappers; Room databases, entities, DAOs and migrations; Services, Workers, receivers and content providers; Hilt, Dagger and Koin; Navigation Component and Compose navigation; unit and instrumentation tests.
• Flutter — packages and dependencies from pubspec.yaml; widgets, screens and routes; Provider, Riverpod, BLoC and GetX state relationships; repositories, services, API clients, models and serializers; local storage and databases; platform channels matched to their native Android handlers; unit, widget and integration tests.

The model

Twenty-four node types and twenty-one edge types, chosen to describe mobile architecture rather than generic source code.

Nodes  Project · Module · Package · File · Class · Interface · Function
       Method · Screen · Route · ViewModel · StateUnit · Repository
       UseCase · ApiEndpoint · Dto · DomainModel · Database · Entity
       Dao · Worker · Service · Test · Resource

Edges  CONTAINS · DEFINES · IMPORTS · REFERENCES · CALLS · INHERITS
       IMPLEMENTS · INJECTS · NAVIGATES_TO · OBSERVES · EMITS · READS
       WRITES · SERIALIZES · MAPS_TO · REQUESTS · RETURNS · PERSISTS
       TESTS · CONFIGURES · DEPENDS_ON

Every node carries its evidence

Each node and edge will store its source file, line range, extraction method, confidence score, index version, source hash and optional evidence text. Extraction methods are ranked, so you can always tell an observed fact from a guess.

parsed     read directly from a syntax tree
detector   matched by a framework-specific rule
resolved   linked by reference resolution
inferred   proposed by a language model, with a confidence score

A language model is used for enrichment and explanation only. Anything it produces is stored as inferred with a confidence score — never as an observed fact.

How it will be built

Detect → Parse → Extract symbols → Infer roles → Create edges → Store and summarise. Deterministic extraction runs first: file and folder rules, Gradle, Manifest and pubspec parsing, tree-sitter syntax trees for Kotlin, Java, Dart, XML and Gradle scripts, then framework detectors. Semantic enrichment runs second, adding architecture roles, DTO → mapper → domain chains, screen → state → use case → repository paths, component summaries and flagged uncertainty.

It stays current

The file watcher hashes changed files, reparses only those, removes their nodes and edges, re-resolves affected references and refreshes only the affected summaries. There is no full rebuild.

Large repositories

Above a threshold the graph will open at module level — one card per module with node counts and aggregated edges — and expand on demand. There is deliberately no "show everything" action for a large project: search, trace, impact and expansion are how you reach any node.

What you will see

• An architecture summary card for the project
• A feature-path explorer that walks screen → state → domain → data
• A dependency view and an impact view
• "Why is this connected?", which shows the evidence rows behind an edge
• Open definition, jumping straight to the source range
• A stale indicator with Refresh and Rebuild
• Natural-language search across the graph