Route in-repo file reads through codedb read --compact on the codedb path (token savings) #66

Summary (enhancement, not a correctness bug)

On the codedb-enabled path, graff correctly uses the codedb tool for structural location (symbol / search / outline / callers), but the actual file-span read before an edit still goes through the native read_file tool, which returns full raw bytes. Routing in-repo exploratory reads through codedb read --compact (exact line ranges + comment/blank stripping) could shave additional input tokens on the locate→read→edit loop.

Evidence

From a SWE-bench-style agentic run (deepseek-v4-pro via graff, in a disposable Linux sandbox), single instance, codedb present + indexed vs absent:

Observed trajectory on the codedb path:

⚙ codedb    symbol from_file --body      ← locate (replaces grep + whole-file read)
⚙ read_file <file> 232..282              ← native raw read for the edit span
⚙ edit_file <file>

The big win is already captured at the locate step (structural query replaces grep/bash + whole-file re-reads → ~3× fewer tokens). The remaining reads are native and raw.

What we might solve

• On the codedb path, prefer codedb read --compact <file> <start> <end> for exploratory in-repo reads — it supports exact ranges and strips comments/blank lines (~10–30% fewer tokens on comment-heavy files).
• Scope caveat: the immediate pre-edit read probably must stay byte-exact, because edit_file matches an exact old_string and compact/annotated output won't match. So this likely applies only to reads that feed reasoning, not the read that feeds the edit. Worth deciding which reads can safely use compact codedb read.

Why this isn't a bug

graff behaves as designed: codedb = structural companion, native read_file/edit_file = raw text + edits. Filing as an efficiency enhancement to evaluate, since a benchmark surfaced that raw reads bypass codedb entirely.

(All infra identifiers/keys from the run are intentionally omitted.)