dekko-verify · git:20260927.bab3b36 · 2026-09-27 · sha256 434a47c04f3e51c6
dekko-verify git:20260927.bab3b36A
Immutable. This exact content never changes and is served at /api/v1/blob/434a47c04f3e51c6.
--- name: dekko-verify description: Sanity-check a suspiciously low or zero call-graph result from dekko (get_callers, get_callees, find_usages, impacted_tests, unused) before concluding "no callers" or "dead code," or a heritage/throws-provenance result (query supertypes, query subtypes, query throws) that labels something (external) when you expect it to be in-repo. Trigger whenever such a result looks surprising given the symbol's apparent importance, before deleting/renaming a symbol based on a zero-caller result, when the repo mixes languages/has any unsupported-language files, or when an (external)/(unresolved) label lands on a name you're confident is first-party code. --- # Verifying a low-confidence dekko answer dekko's call-graph resolution usually fails as a **confident wrong answer**, not a visible error, and "0 callers" is easy to over-trust. This skill catches that before it deletes live code or hides a real impact. It covers resolved relationships (callers, callees, usages, impacted tests, `unused`, heritage, throws), not `outline`, `query_symbol` or `search_code`, which only describe what exists. ## How to check Run `dekko sanity` (the `/sanity` command). It compares dekko's answer with one targeted grep sweep, buckets the results into matches / dekko-only / grep-only, and names a likely cause for every grep-only miss: ``` dekko sanity <symbol> # a get_callers result dekko sanity <name> --usages # a find_usages result dekko sanity --unused <symbol> # a `dekko unused` "dead" verdict ``` One run is enough. Don't read whole files or rebuild the call graph by hand; that defeats the point of dekko. ## When to double-check Spot-check, don't re-verify everything, when any of these apply: - **Dynamic dispatch or an unusual qualified call.** Trait/interface dispatch (Rust `dyn Trait`, Java/Kotlin interface methods) is the main blind spot: the resolver reliably matches only an explicit `Type::method()` / `Type.method()`. Qualified calls through a same-repo namespace or module usually resolve, but one routed through a re-export or alias can still drop. - **A low count with no ambiguity disclosure.** A real ambiguous call says so (`N call(s) resolved ambiguously`). A widely used symbol with a low count and *no* disclosure is more suspicious than one with it. - **Unsupported or partially parsed files.** `dekko stats` or the map summary notes them. A symbol called only from an unparsed file reads as zero-caller. - **`get_callers`' default test filter.** It hides test callers (and says so in a footer). Pass `include_tests=true` (CLI: leave `--no-tests` off) before concluding dead code. - **A generic short name in a dense repo** (`new`, `then`, `map`, `iter_mut` in a 10k+-symbol repo): treat the count as directional. - **Deleting or renaming on `dekko unused`'s word.** A callback passed by reference or a call from an unparsed file reads as unused. A row ending in `[dispatch?]` (`dispatch_candidate` in `--json`) shares its name with an interface/trait method or is a getter/handler read as a property: treat it as alive until `sanity --unused` says otherwise. `--unused` tags each piece of evidence by shape (`spread`/`typeof`/`subscript`/`call`/`other`). - **A thin `impacted_tests` / `dekko affected` list.** It follows resolved calls only; tests reached through an ambiguous call are counted in a `note:` line, and `dekko affected --possible` lists them. - **An `(external)` or `(unresolved)` label on a name you know is first-party**, from `query supertypes`/`subtypes` or `query throws`. A syntax shape the extractor doesn't model yet can mislabel an in-repo entry rather than drop it. `sanity` doesn't cover this; check with `dekko query symbol <name>` or one `grep -rn <name>`. ## What "good" looks like If the sweep agrees with dekko, or finds nothing dekko missed, trust the structural answer and move on. Most answers on supported languages with unambiguous calls are correct; this is for the conditions above, not a blanket "always grep after dekko."