Enhancement ideas from heavy use on a large, fast-moving Rust codebase

[MFJG-dev]

Thanks for UA — we've been running it on a ~2000-file, 40-crate Rust audio workstation that lands ~30 PRs/day. The skills (especially /understand-explain and /understand-diff) have been genuinely useful. A few enhancements from that usage, roughly highest-leverage first:

1. Cheap incremental refresh keyed on a ref

/understand --since <commit> that re-analyzes only files changed since the graph's meta.json gitCommitHash, instead of a full rebuild. On a fast-moving repo the full rebuild cost is the main barrier to keeping the graph current — a refresh proportional to the actual drift would make 'rebuild periodically' nearly free. (Auto-update-on-commit is too aggressive at our velocity; an explicit incremental command is the sweet spot.)

2. Pre-flight cost/scope estimate

Phase 1 (scan-project.mjs) already computes file count + complexity ('very-large') + batch count. Surfacing an estimated token/time cost before /understand --full starts would let users decide to proceed or scope down. The data's already gathered; it's just not shown up front.

3. Staleness is silent

meta.json records gitCommitHash + lastAnalyzedAt, but nothing warns when the graph is far behind HEAD — ours sat ~650 commits stale before we noticed, and graph-dependent skills (/understand-chat, dashboard) answered confidently from the stale graph. A freshness check (commits-behind / days-behind, or fingerprint-mismatch count using the existing fingerprints.json) that warns before trusting an old graph would prevent confidently-wrong output.

4. A committable prose artifact, separate from the heavy graph

explain-notes.md was the one output worth versioning in-repo (it ages gracefully), but it sits next to the 50+ MB of graph/fingerprint JSON that must stay gitignored. A --emit-notes that writes just a small architecture summary, distinct from the bulk graph, would let teams commit the durable signal without the rot-prone bulk.

5. Rust language addendum

languages/ has no rust.md and frameworks/ is web-only, so Rust projects get only the base template. A languages/rust.md (crates/workspaces, traits, feature gates, unsafe/FFI boundaries, async runtimes) would sharpen summaries considerably for the Rust ecosystem.

Happy to contribute PRs for any of these if they're directions you'd welcome — particularly the Rust addendum (5) and the staleness check (3), which are self-contained. Thanks again!

[MFJG-dev]

One more from running the full pipeline on the Rust repo: the import resolver produced empty batchImportData for all 99 batches — it doesn't resolve Rust use/module dependencies, so the assembled graph had only contains edges and no cross-file dependency edges. So the missing languages/rust.md (item 5) isn't just about summary quality — Rust dependency resolution itself appears unsupported. A Rust-aware import resolver (crate/module/use-path resolution) would be needed for the dependency graph to populate on Rust projects.

[pallav-vunet]

One more from running the full pipeline on the Rust repo: the import resolver produced empty batchImportData for all 99 batches — it doesn't resolve Rust use/module dependencies, so the assembled graph had only contains edges and no cross-file dependency edges. So the missing languages/rust.md (item 5) isn't just about summary quality — Rust dependency resolution itself appears unsupported. A Rust-aware import resolver (crate/module/use-path resolution) would be needed for the dependency graph to populate on Rust projects.

Hi @MFJG-dev, we are also starting to work on a Rust project and would like to understand the implications of this.

We want to make use of an open-source Rust crate to develop an app. Since the docs are not yet mature, we thought we could run graphify or understand-anything to map out the library and then use it for our/Claude's understanding. The crate also gets frequent updates, so we were hoping to be able to incrementally refresh based on the diff. We haven't tried anything out yet - bcz the crate is massive (~700K lines of rust), and we don't want to feed our token budget without getting any output.

A few questions:

• As of today, does understand-anything produce any usable output on Rust code?
• Are you planning to raise a PR to resolve this?
• Have you solved this at your end by including a languages/rust.md?
• Have you tried using graphify instead? Did it work out for your use-case?