Benzi

Where does this value come from? Reverse DATAFLOW (mirror: forwardflow) -- what FEEDS a function's parameters, in TWO tiers. TIER 1: per proven call site, the raw argument EXPRESSION bound to the parameter it lands on -- `data` is fed `req.body` from `handle` at app.py:40. TIER 2: each expression walked BACKWARD through the caller's assignments and up the call graph to where the value ORIGINATES (literal, constant, a call's return, an import) or an honest wall; depth-capped, exact or stopped, never guessed. A parameter a caller OMITTED comes back "defaulted" with the declared default and how many sites took it -- distinct from "no_static_feed" (nothing feeds it, no default). Best-effort on *args/**kwargs: a spread stays unresolved rather than guessed (as in trace_path).

Find TEXT -- a literal, a comment, an error string, a CSS class, an HTML id, a partial token -- inside the files the map INDEXES: analyzed code files plus the markup files (HTML/CSS/DOM-js) the code graph doesn't parse. It does NOT reach UNINDEXED files: a language with no grammar, a .sql, a fixture (list_unlisted_files inventories them). There, this returns "no matches" whether or not the text is present -- so for anything unindexed use your own grep, which has no such limit. The PATTERN IS A PYTHON REGEX, not a literal -- escape ( ) . * for literal characters (`\.pipe\(`). Each match carries its ENCLOSING SYMBOL (`in` -- a usable id), so it locates the handler, not just a line. Returns {path, line, in, text}; uncapped, true total always reported. `context` gives N lines around each hit (like grep -C, skips a follow-up read_source); `multiline` for patterns spanning lines.

The TRANSITIVE call closure from one function, which get_callers (one hop) and trace_path (two endpoints) can't give. "direction": "forward" = everything this transitively CALLS (what does this route actually touch?); "reverse" = everything that transitively calls it (blast radius before a change). Each node carries "depth" (hops out) and a "leaf" flag where the chain ends. Proven edges only unless include_candidates also follows the speculative tier, whose nodes come back tagged "via":"candidate". Cycle-safe and capped -- a truncated closure says so.

I changed what this returns -- who consumes it, and how far does it reach? The MIRROR of backflow, in TWO tiers. TIER 1: for every proven caller, the variable that CATCHES the return (`data = load()`) or an inline use. TIER 2: each caught value walked FORWARD -- passed on as an argument (landing on a named callee parameter), stored in a self.x field, or returned onward up the call graph -- to where it LANDS or an honest wall; depth-capped, exact or stopped, never a guess. Same best-effort binding as backflow/trace_path.

Every function that calls X -- the reverse direction a body's own outline can't show. Dynamic dispatch is covered honestly: an override also gets "possible_callers_via_dispatch" (callers of the base method whose call can land here at runtime -- possible, not proven), and a method with overrides gets "overridden_by" (its callers may dispatch there instead). Treat both as blast radius. This is half of it; the other half -- who HOLDS X without calling it (registries, callbacks, aliases) -- is "referenced_by" on get_definition.

The declaration card -- what a symbol IS: file, line span, parent, children, signature verbatim (defaults, annotations, splats), return type, decorators (@app.route, [HttpGet] -- evidence of how it gets invoked), base classes, docstring, and "fields" (for a struct/enum the fields ARE the meaning). A module adds its imports and which resolve in-repo. Constants and VARIABLES get a binding card: the ordered assignment sequence, every line the value could have changed, each rhs classified. "called_by" is who PROVENLY calls this, with a count; "referenced_by" is who HOLDS or reads it WITHOUT calling -- attribute reads, registry values, Thread(target=...) wiring, aliases -- the half of blast radius get_callers can't see. Body: skim_source. Raw text: read_source.

The class TREE for a type: resolved BASES (up) and direct SUBCLASSES (down) -- inheritance the compiler resolved at build time, which get_definition shows only as raw `extends` text. Returns "bases" (direct), "ancestry" (the whole chain, nearest first), "subclasses" (direct), each subclass tagged with the methods it OVERRIDES here and whether it has subclasses of its own. In-repo relations only (an external base like Thread won't appear).

The LIBRARY surface, deduped to library roots with usage counts (`numpy.array`/`numpy.mean` both roll into one `numpy` entry) -- "third_party": external code leaned on but not owned, plus the raw import statements behind that evidence. OMIT name_or_id for THE WHOLE REPO; pass a file path or a scope id (function/class) to scope the same dedup to just that target. The always-deduped-roots view -- for raw call SITES (name/args/line) at any of the same granularities, use list_external_calls instead. A separate `unresolved_imports` field (sibling to third_party, NOT inside it) lists imports whose own syntax already proves in-repo intent (a relative import, require_relative, a quoted #include, rust's use crate/self/super) but still failed to resolve to a file -- a compiler gap, never counted as a dependency. Aggregated from references; no vendored code is parsed. Non-code repo files are list_unlisted_files, calls the compiler couldn't classify are list_unresolved_calls.

A FILE's, a SCOPE's, or (name_or_id omitted) THE WHOLE REPO's EXTERNAL (stdlib/third-party) call SITES, each with raw arguments and line -- the calls a skim shows WITHOUT a → . profile flattens these to bare names and drops args/lines. A class returns the union across its methods, a file the union across every scope in it, no argument the union across the whole repo (capped -- narrow to a file/scope for the rest, or use list_dependencies for the already-deduped library-roots-with-counts view instead of raw sites). Each entry tagged with which file/scope makes the call. Entries of kind "unresolved" are the honest can't-settle case: `reason` names the wall -- opaque_receiver / untyped_local (no target named) or name_collision / linkage_refused (2+ real in-repo targets in `candidates`, no evidence to choose; NOT library calls) -- and `supposed` holds the raw text as scope::name, a lead, not a verified id. list_unresolved_calls collects these too; get_callers is the in-repo direction.

ONE directory level of the map (like `ls`, not `ls -R`). Returns {dir, files, subdirs}: `files` are the analyzed files DIRECTLY in `path`, each with language, line count, docstring, top-level symbols (id + kind + line -- every id is accepted by every other tool) and constant names; `subdirs` are the immediate folders, each with a recursive file count so you see where the code mass is. Omit `path` for the root, then drill with list_files("src/foo"). This is the project's OWN code; libraries are list_dependencies, non-code files list_unlisted_files.

Repo files the map does NOT index, each with its reason: "no_grammar" (non-code assets -- images, data, configs, docs, lockfiles -- and any language without a grammar), "data_blob" (supported extension skipped as minified/base64), "parse_error" (a supported file that crashed analysis -- a defect worth flagging), "not_downloaded" (hosted demo only: listed by GitHub's tree, never fetched). Also excluded_dirs, the directories the walk deliberately skipped (vendored/build/VCS), so absence is never silent. Repo-relative paths: read_source opens any of these, and your own grep searches them -- benzi_grep does NOT, it only sees indexed files. An unlisted schema.sql, fixture json, or a whole language without a grammar can still hold the answer.

Call sites the compiler SAW but could not settle -- neither in-repo nor provably a library call. Each carries `supposed` (raw call text as a scope::name id, `ax::plot` -- a lead, NOT a verified symbol) and `reason`: "opaque_receiver" (receiver expression dropped -- a nested call's result, a dereferenced pointer) or "untyped_local" (known name, type never inferred -- a parameter's .method(), a called function pointer), neither naming a target; or "name_collision" / "linkage_refused", which DID name 2+ real in-repo targets in `candidates` with no evidence to choose -- worth reading, not a dead end. OMIT name_or_id for THE WHOLE REPO (per-file counts, where the dark mass sits); pass a file path or a scope id (a function/class) for that target's entries with lines. Distinct from candidate_edges (dynamic dispatch, unresolvable statically) and list_dependencies (library evidence exists).

Fuzzy-find an ANCHOR by name -- a handle the UI hangs on: id (#tree-panel), class (.panel), or tag. Each hit shows its declare/style/grab tallies. Turns 'the left panel' into a handle for markup_get_definition.

The anchor card: where a handle is DECLARED (html element), STYLED (css rules + values + any @media), and GRABBED (js lookups), each with a layer-tagged uid (html::/css::/js::file:line). Those three lists ARE the blast radius. An id handle also gets `effective`: the WINNING rule per property (specificity + source order) as {prop:{uid,value}} -- to restyle, edit effective[prop].uid, since editing a non-winning styled rule does nothing on screen. Universal/@media/state/context rules appear in styled but aren't resolved into the winner.

Markup-engine orientation: which files carry UI (HTML/CSS/JS, embedded or standalone) and how much, plus the total anchor count.

The full 360 on one symbol in ONE call -- its declaration (what it IS), the functions it calls + data it defines (what it DOES), who CALLS it + who HOLDS it (the full blast radius), and what each parameter is passed one hop back (what FEEDS it). Deeper on any dimension: skim_source, backflow, get_callers, read_source.

Read one of Benzi's reference topics in full -- detail kept out of your system prompt so you only load what a job needs. Topics: "artifact" (how the map fits together -- call flow vs data flow and where they join, the symbol kinds, the UID-keyed tables the tools query), "uids" (the UID scheme, code and markup alphabets, the C/C++ declaration-vs-definition wrinkle), "languages" (how deep the map goes per language, and where an empty result means 'not indexed' rather than 'nothing uses it'), "markup" (anchors, the three layers, the cascade, its tools).

The symbol's ACTUAL source, sliced to the exact span the map knows -- full fidelity: control flow, values, comments as written. Use when the answer hinges on real code ('what threshold', 'which branch'). Read the narrowest symbol that answers; start_line/end_line (absolute, the same lines skims/edges/callers report) fetch a window of a long body. Oversized spans truncate with a note.

Turn a half-remembered NAME into the UIDs every other tool takes. Fuzzy case-insensitive SUBSTRING match over every symbol including nested methods ('pack' finds _skyline_pack, build_pack) AND every BINDING: function locals and class-body data (symbolKind "Binding", with its defining line and value). Each hit carries `id`, `symbolKind`, `path`, `line_span` and caller/reference counts, so you can usually tell which one you meant without a follow-up get_definition. Takes a LIST of names to resolve in one call.

Reach for this FIRST when you need to know what a body does; it tells you which lines are worth read_source. A one-level outline: calls (with the raw arguments at each site), assignments, return/yield/raise, LOOP exits (break/continue, with their label where they carry one -- so you can see whether a loop runs to completion), and condition headers verbatim (`if not data:`, `for row in cursor:`) -- in source order, line-numbered, INDENTED to mirror real nesting. A leading → marks a call landing in THIS codebase; skim that id to descend one level, no → means external. A class returns "members" instead (its calls live in its methods); a file returns both. It omits the computation BETWEEN these lines (arithmetic, expression bodies, comments). Long outlines page at 40 steps; a truncated tail names the offset for the next page.

The call chain between two functions AND the data along it: each hop's call site (line + raw args) plus "binds", those args zipped to the callee's parameter names, so renames read step to step (`req.body` enters `validate` as `payload`). No direction argument -- it searches both ways and reports which in "direction": forward, reverse (hops still in real call order), or undirected (shared intermediates only -- noted, not a flow). RESOLVED sites only: a value stashed in a field or passed through an untraced method call won't appear; read_source that hop.