CodeGuard: One-Scan Multi-Lens Modernization

Every time a developer fixes a bug, they check the one file it happened in — not whether the same mistake is hiding elsewhere in the codebase. Every time a team wants to delete "obviously dead" code, they hesitate, because naive tools flag things later discovered to be loaded dynamically, and one wrong deletion breaks production. Both problems trace back to the same root cause: acting on a codebase with confidence requires expensive, whole-repository understanding, and most tools rebuild that understanding separately for every concern instead of reusing it. CodeGuard solves both from a single IBM Bob repository scan. Rather than ingesting the codebase twice, we build one condensed repository map — file purposes, exports, and call relationships — and hand it to two subagents running in parallel. Lens A scans for other instances of a known bug pattern using that shared context. Lens B independently checks the same context for genuinely unreachable code, explicitly ruling out dynamic references such as string-based imports, decorators, and config-driven plugin loading before flagging anything. A synthesis agent merges both verdicts into one health report, and only auto-generates a deletion diff for code Lens B is highly confident is dead — anything ambiguous goes to a "needs human review" list instead of being silently removed. Our target users are teams maintaining an existing codebase, where "is this safe to touch?" is the real bottleneck, not writing new code. They point CodeGuard at a repo and one known bug fix; it returns a report showing every other instance of that bug across the entire codebase, plus a conservative, test-verified list of code safe to remove. What makes this different from typical modernization or cleanup tools is treating whole-repository understanding as a shared resource across two otherwise-separate concerns, instead of paying its cost twice. And unlike static dead-code tools that delete first, our safety gate refuses to act on anything it cannot confidently rule out as dynamically referenced. We validated this on TinyDB, a real, mature Python library. Lens A traced one live-reference mutation bug to five separate locations from a single seed example, independently confirmed by hand against TinyDB's actual MemoryStorage and CachingMiddleware configurations. Lens B correctly rejected all six dead-code candidates it considered, each for a specific, documented reason — proof the safety gate works rather than just defaulting to an empty list. The most telling result: our first fix broke one of TinyDB's own pre-existing tests, one that explicitly documents a piece of that behavior as intentional. We caught this ourselves, reverted the change, and updated our findings to say so plainly rather than quietly dropping it. That is the standard CodeGuard enforces on the codebases it analyzes, and the standard we held ourselves to while building it.