fix: Rust integration tests never detected, and merge script fails on Python 3.9

[micahldixon]

Ran /understand on a Tauri v2 project, 141 files, mostly Rust with a React frontend. Great tool, the graph and the guided tour both came out genuinely useful. Hit two bugs in merge-batch-graphs.py along the way, so here are fixes for both with tests.

1. Rust test coverage gets dropped silently

This is the one that actually cost me something.

_TEST_NAME_PATTERNS has no .rs entry, so is_test_path() falls through to return False and no Rust file is ever seen as a test. On my run the merge discarded 12 tested_by edges, 10 unique pairs, and reported them as "orphan endpoint or test<->test / prod<->prod pair". Both endpoints were present in the merged node set, so that reason was wrong in every case.

In other words, Rust has no test-name convention to pattern match on. Cargo compiles every .rs file directly inside a crate's tests/ directory as an integration-test binary, whatever it's called. Mine were smoke_risk.rs, smoke_hooks.rs, sonar_shellout.rs. None of those carry a prefix or suffix marker, and they never will, because Rust unit tests live inline behind #[cfg(test)] instead of in their own files. Directory position is the only signal there is.

Repro on current main:

import importlib.util
spec = importlib.util.spec_from_file_location(
    "m", "understand-anything-plugin/skills/understand/merge-batch-graphs.py")
m = importlib.util.module_from_spec(spec); spec.loader.exec_module(m)
print(m.is_test_path("src-tauri/tests/smoke_risk.rs"))   # False, should be True

Why it's worth fixing: my run happened to have a review pass that caught it and restored the edges, so my graph is fine. Without that pass it ships a graph claiming the Rust backend has zero test coverage. That's confidently wrong rather than merely missing, which is the worse failure mode for something an agent queries later.

The fix matches on directory position for .rs only. Files under a nested directory like tests/helpers/util.rs stay classified as production, which keeps it consistent with how __tests__/helpers.ts is already handled.

2. The script won't run on Python 3.9

Four PEP 604 annotations (dict[str, Any] | None and friends) get evaluated at runtime on function definition, so on 3.9 the module dies at import:

TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

Honestly that reads like a bug in the script rather than a version problem, and it took me a minute to work out what was going on. The shebang is a bare #!/usr/bin/env python3 with no floor declared anywhere. Worth noting macOS still ships 3.9.6 as the system python3, so anyone on a Mac without a newer interpreter first on PATH hits this on their first run.

from __future__ import annotations is the smallest fix and keeps the annotations readable. If you'd rather declare a 3.10 floor and fail with a clear message instead, definitely happy to redo it that way, just say the word.

Testing

• python -m unittest tests.skill.understand.test_merge_batch_graphs passes, 82 tests, on both 3.9.6 and 3.13.5. On current main the same command cannot even import the module under 3.9.
• The other two suites CI runs (test_merge_subdomain_graphs, test_parse_knowledge_base) still pass, 15 tests, no regressions.
• Added 2 tests covering the Rust case: 4 real integration-test paths and 5 production paths including build.rs and the nested-helper case.
• Existing Go, Python, Java, Kotlin and JS/TS classification tests all still pass untouched.

I have not run pnpm test (the vitest side), since these changes are Python only and don't touch anything the JS suite covers.

Two commits, split so each one stands alone.

3. Separate suggestion, no code attached

One file-analyzer subagent cleared its own stale output with rm -f .understand-anything/intermediate/batch-1*.json. That glob also matches batch-10.json, batch-11.json and batch-12.json, so it destroyed a finished batch's work and I had to re-run it.

The agent improvised that command, it isn't in your instructions, but agents/file-analyzer.md doesn't mention cleanup either way so there's nothing steering it away from a glob. A line in the agent prompt saying to delete exact filenames only would close it, since all batches share one output directory. I left that one alone because it's your call how to word it. Happy to open it as a separate issue if you'd prefer to track it that way.

P.S. the layer assignment on a mixed Rust/TypeScript repo came out better than I expected, it put both halves of the IPC contract in the same layer without being told to. 🙂