dekko-verify

Verifying a low-confidence dekko answer

dekko's call-graph resolution is real but conditional — repeated hands-on evaluation rounds (see this repo's own test-repos/reports/) keep finding the same failure shape: a confident wrong answer, not a visible error. A caller trusts "0 callers" more than it should. This skill exists to catch that before it leads to deleting live code or missing a real impact.

When to double-check before trusting a result

Reach for one targeted grep -rn <name> (not a full re-read) as a sanity check — not a full re-verification — when any of these apply:

• A cross-package/cross-module qualified call is involved. pkg.Func()-style calls (Go), namespace::func() (C++), or any call where the receiver is a same-repo package/module rather than a local variable are a known resolver blind spot — confirmed missing 4 real call sites on a live repo as recently as this project's own round-13 eval. Same caution applies to trait/interface dispatch (Rust dyn Trait calls, Java/Kotlin interface methods) — the resolver ladder only reliably matches an explicit Type::method() or Type.method() form.
• The result doesn't disclose ambiguity. A real ambiguous call should say so (N call(s) resolved ambiguously), not just be silently absent from the count. If a symbol you expect to be widely used shows a low count with no ambiguity disclosure, that's more suspicious than a low count with one.
• The repo has any unsupported/partially-parsed language files — check dekko stats or the map-build summary for an "unsupported" note. Files dekko can't parse are tracked (not silently dropped), but a symbol only ever called from an unparsed file will still read as zero-caller.
• get_callers/get_callees used their default --no-tests filter. An empty result may just mean "no non-test callers" — check whether include_tests/--include-tests was applied before concluding dead code.
• A dense-repo common short method name (new, then, map, iter_mut, or similarly generic names in a 10k+-symbol repo) — resolver precision degrades under high symbol density; treat a count from these as directional, not exact.
• You're about to delete or rename based on dekko unused's dead-code list. Same blind spots apply; a callback passed by reference rather than called directly, or a call from an unparsed file, can both read as "no inbound calls."
• A heritage or throws-provenance result labels something (external). query supertypes/subtypes and query throws can mislabel an in-repo type-alias-as-heritage-base or a pattern-bound rethrow as a fake external entry when the extractor doesn't yet model that language's specific syntax shape (confirmed historically on TS implements <type-alias> and Java 16+ instanceof-pattern rethrows — both since fixed, but the general failure shape, a present result that's mislabeled rather than a missing one, can recur in a new syntax shape any of dekko's language extractors hasn't seen yet). An (external)/(unresolved) label on a name you're confident is first-party code is worth a query symbol <name> check before trusting it.