Is your feature request related to a problem?
First — thanks for building Gortex. We evaluated 8 CodeMap tools and chose it for its cross-module contract detection on our workspace (~100 services, 20,000+ source files). It solves the "fix A breaks B" problem well.
Our code agent already has grep. We installed Gortex for two reasons:
- Token savings: finding all consumers of an API across 80+ services takes 15-20 grep calls; Gortex reduces this to 1-2 graph queries.
- Blast radius awareness:
get_dependents(depth=3) answers "who will this change affect?" in one call — downstream services, MQ consumers, and Controller endpoints are all surfaced.
The problem: cold start takes 8-15 minutes on our workspace, making on-demand usage impractical. We only need the daemon ~10% of sessions (cross-module analysis); the other 90% it should stay stopped. With the current cold start time, developers either leave the daemon running (constant 2-3 GB memory) or skip Gortex entirely (back to grep).
Describe the solution you'd like
Per docs/architecture.md, Gortex's data flow splits parsing (step 4: Tree-sitter AST → nodes + intra-file edges) from cross-file reference resolution (step 5: calls / implements / extends edges). These are two independent stages. The warm restart's scoped path already proves resolution can run against a delta.
We propose making step 5 lazy — deferred to the first get_callers or find_usages query, triggered on-demand like the enrichment in PR #265 (lazy LSP) and PR #343 (on-demand graph analysis). Same pattern, one layer deeper.
Cold start (steps 1-4 only): Tree-sitter parse + node building → ~2 min → search_symbols ready
(step 5 skipped — cross-file edges not yet built)
First query: get_callers → triggers step 5 on-demand → returns in seconds → edges cached, subsequent queries instant
Use case
Before changing a shared API, a developer asks: "who calls this? who consumes this MQ event? what's the 3-hop blast radius?" Gortex answers in 1-2 calls — but only if the daemon is already running. With lazy resolution, the daemon starts fast enough for this to be a natural part of the workflow, not a planned activity.
This extends the lazy pattern from #265 and #343 to the reference resolution layer, consistent with the architecture's two-stage design. Admittedly this matters mostly for large workspaces (small ones cold-start in seconds already) — but for those it's the difference between usable and not. Thanks for considering!
Is your feature request related to a problem?
First — thanks for building Gortex. We evaluated 8 CodeMap tools and chose it for its cross-module contract detection on our workspace (~100 services, 20,000+ source files). It solves the "fix A breaks B" problem well.
Our code agent already has
grep. We installed Gortex for two reasons:get_dependents(depth=3)answers "who will this change affect?" in one call — downstream services, MQ consumers, and Controller endpoints are all surfaced.The problem: cold start takes 8-15 minutes on our workspace, making on-demand usage impractical. We only need the daemon ~10% of sessions (cross-module analysis); the other 90% it should stay stopped. With the current cold start time, developers either leave the daemon running (constant 2-3 GB memory) or skip Gortex entirely (back to grep).
Describe the solution you'd like
Per
docs/architecture.md, Gortex's data flow splits parsing (step 4: Tree-sitter AST → nodes + intra-file edges) from cross-file reference resolution (step 5: calls / implements / extends edges). These are two independent stages. The warm restart'sscopedpath already proves resolution can run against a delta.We propose making step 5 lazy — deferred to the first
get_callersorfind_usagesquery, triggered on-demand like the enrichment in PR #265 (lazy LSP) and PR #343 (on-demand graph analysis). Same pattern, one layer deeper.Use case
Before changing a shared API, a developer asks: "who calls this? who consumes this MQ event? what's the 3-hop blast radius?" Gortex answers in 1-2 calls — but only if the daemon is already running. With lazy resolution, the daemon starts fast enough for this to be a natural part of the workflow, not a planned activity.
This extends the lazy pattern from #265 and #343 to the reference resolution layer, consistent with the architecture's two-stage design. Admittedly this matters mostly for large workspaces (small ones cold-start in seconds already) — but for those it's the difference between usable and not. Thanks for considering!