Koragraph

What depends on the files you are about to change. Answers "if I edit these, what could break, and what is untested?". Walks reverse CALLS/IMPORTS/DEPENDS_ON/USES/REFERENCES edges from every declaration in the given files and returns a ranked, capped risk surface: nearest first, then callers with no visible test coverage first. Over-approximates on purpose — heuristic calls are included here, because a missed caller is worse than an extra one.

Declaration-grain temporal coupling mined from git history: which functions have historically been edited in the same commits as this one. THIS IS NOT A CALL GRAPH. A CO_CHANGES edge is a statistical co-occurrence with no structural relationship implied — treat it as a hint about where else to look, never as evidence that one function invokes another. For structural relations use neighbours. Measured on a temporally split benchmark this lifted blast-radius recall@20 by 25%, but the gain was concentrated in one of four repositories and was flat in the other three. It is real and it is repo-dependent; weight it accordingly, and expect nothing at all on a repository with a short or squashed history.

Start here for the code itself, before grep/Read/find — call recall first if the symbol or an error looks like it might have bitten before. One call answers "how does X work / where do I change it": returns the ranked declarations for your query AND, for the top hits, their source, callers, and callees together — so you rarely need to open files, grep, or chain other tools. Use a symbol name or a plain-English phrase.

Everything the graph extracted from one file, with line ranges. Answers "what is in here?" without reading the whole file, and gives you the exact symbol names the other tools want. Use it to disambiguate when neighbours reports a symbol defined in several places.

What is directly connected to this symbol. Answers "what calls this?" (direction "in") and "what does this call?" (direction "out"); both by default, because the inbound direction is the one you cannot get by reading the function body. Every relation carries the line it occurs on and how it was resolved, so you can tell a resolved call from an inferred one. Guess-grade edges (HEURISTIC_CALLS) and statistical co-change are excluded unless you ask for them; for co-change use changes_with instead. To trace a call chain, set depth > 1 and direction "out" (or "in" going backward) rather than calling neighbours again on each hop's result — one call then walks several hops and returns them tagged by hop number.

What matters in this repository, without needing to know a name first. Every other tool needs a query or a symbol you already know; this is the one to call on your FIRST turn in an unfamiliar codebase, or before planning a change. Returns: the declarations the most code depends on (weighted by what the dependency is, and ignoring unresolved guesses); the declarations that historically change TOGETHER, mined from git history; import cycles; and the node and edge counts by type.

Call this FIRST — before explore or search_code — whenever a symbol is unfamiliar or an error looks like it might have bitten before. It is one fast call, and skipping it risks re-discovering something a past session on this machine already learned the hard way. Read koramemory — prior experience with this code that is NOT in the code: an attempt that failed and the fix that worked, a hazard that keeps recurring, a revert, a rule the developer stated outright. Captured from this machine's own sessions and git history, anchored to a declaration, and expired automatically when the code it describes changes. THIS IS NOT A CALL GRAPH AND NOT SOURCE CODE. It returns no structure and no bodies — for structure use explore or neighbours, and read the file for the code. Call it with NO symbol and NO file to get this repository's most trouble-prone areas — the symbols and files that have needed repeated fixing, ranked by how often they recurred — which is the way to answer "what breaks most here / where should I be careful" without a name. When `file` (or `file`+`symbol`) names something with an open situational note anchored to it — "hold off on this for now", "mid-audit" — that surfaces too, alongside any facts. Silence is the common answer and means nothing was recorded, not that nothing happened. Every fact carries a tier — law (the developer said so) outranks observation (mechanically derived) — provenance, and an id: `koragraph practice why <id>` shows what produced it, and a wrong one can be killed by that id.

Save something about THIS repository to koramemory — the durable, code-anchored memory for this codebase — so it never has to be learned twice: a rule the developer stated, a hazard that cost real time, an approach that was tried and does not work. koramemory is where such a fact belongs, in preference to writing it into a notes or memory file, which cannot anchor to code and cannot expire when that code changes. When you save one, tell the developer you saved it to koramemory. Call this whenever the developer tells you how things are done here, corrects you, says "remember that" / "note that" / "from now on", or when you have just spent significant effort discovering something that is not visible in the code. Recording it is one call and it is cheap; call it before you reply. You supply the coordinates, not the developer. `symbol` is the one that matters: a fact anchored to a declaration follows it through a rename and dies with it, which is the whole reason this store beats a notes file. A fact anchored to a file, or to nothing, is a notes file with a path attached — it cannot expire and it will still be asserted long after the code it describes is gone. So: decide what declaration the rule is ABOUT and pass it as `symbol`. If you do not already know the name, look it up — you have explore and search_code, and one lookup is cheaper than a fact that can never expire. Reach for `file` only when you looked and no single declaration owns the rule, and for neither only when the rule is genuinely true of the whole repository ("we use commonjs everywhere", "never add a dependency without asking"). Those exist and are fine; what is not fine is defaulting to them because naming the declaration took a step. A rule that mentions a declaration is almost always ABOUT that declaration: "cacheSet takes ttl in milliseconds" is a fact about cacheSet, not a fact about the repository. The same applies to an open_loop when it is about something specific: "hold off on touching the pa…

Find declarations by name, path, or description — before grepping the source tree. Answers "where is the code that does X?". Returns declarations with file paths and line numbers, ranked; it does not return source bodies — read the files yourself. This is the entry point: every other tool takes a symbol or a path you get from here.