
Debugging and maintaining an unfamiliar software repository often begins with a repetitive evidence-gathering process. Developers may need to understand the repository structure, inspect dependency manifests, search for relevant code, examine Git history, identify frequently changed files, and investigate individual files before making a change. This work can be time-consuming and is often repeated manually for each investigation. SourceEvidence addresses this workflow by providing a deterministic evidence layer for real Git repositories. It scans repository files and sizes, analyzes dependency declarations, performs Git archaeology directly from repository data, searches source code, identifies historical change hotspots, explains individual files, and provides a Codebase Overview for quickly understanding the structure of a project. It can also generate text and Markdown reports and combine the gathered information into a structured Evidence Pack in JSON or Markdown. The project deliberately separates evidence gathering from AI reasoning. SourceEvidence does not embed an LLM or claim to automatically determine the correct fix. Instead, it produces inspectable repository facts that can be reviewed by a developer and supplied to IBM Bob 2.0 as structured context for repository-aware investigation. The demonstrated workflow is: Developer problem → SourceEvidence → Evidence Pack → IBM Bob 2.0 investigation and implementation → regression test → developer review. The workflow is demonstrated using a sample payment-processing repository containing a retry/idempotency defect that can result in the same payment being charged twice. The failing regression test provides a concrete debugging task. IBM Bob investigates the repository context and assists with the code change, after which the regression test is run independently to verify the result. SourceEvidence is designed as a local, read-only developer tool. Repository analysis does not require network access or third-party runtime dependencies, and the inspected repository is not modified by the analysis workflow. The target users are developers working with unfamiliar, large, or actively changing repositories who need a repeatable way to gather and inspect evidence before debugging or modifying code.
27 Sep 2026