我构建了一个 local-first 的跨仓库变更影响图工具

A small API change rarely stays small. In a multi-repository system, changing one route can affect a frontend wrapper, a backend handler, an internal service, a database call, documentation, and tests. I kept tracing those paths manually, so I built Where am I: an MIT-licensed, local-first tool that turns Git changes and static code evidence into a clickable impact graph. Repository: github.com/soil0119/Where-am-i Where am I is an early MVP. Its output is supporting evidence for review, not a replacement for tests, security checks, or engineering judgment. The problem I wanted to solve Most code search tools answer questions about one symbol or one repository. The question I usually had was broader: If I change this endpoint, where does the change flow across the whole system? The answer might cross several boundaries: frontend action -> API wrapper -> backend route -> handler or service -> database / external API -> OpenAPI docs -> tests Enter fullscreen mode Exit fullscreen mode A plain dependency graph is not enough. During review I also need to know why two nodes are connected, which line created the relationship, and whether the node belongs to my current work or to an incoming team change. Design goals I started with four constraints: Local-first: configured source repositories should not be uploaded to a hosted analysis service. Evidence over mystery: every useful connection should lead back to a file and, when available, a source line. Change-aware: the graph should prioritize the current diff and teammate updates instead of showing the entire codebase at once. Bounded work: large repositories need explicit scan limits so the tool remains usable during development. From Git state to an evidence graph The scanner is a Node.js script. For each configured repository it collects several views of change: working-tree and staged changes commits on the current branch compared with its base reference changes available from the selected remote/base reference It then combines changed files with priority files and API catalog files. This keeps the first pass focused while still allowing it to connect a changed implementation to contracts, wrappers, documentation, and tests. At a high level, the pipeline looks like this: Git repositories -> discover repos and base refs -> collect diffs and status -> extract static facts -> connect facts with evidence -> write a local snapshot -> render an interactive graph Enter fullscreen mode Exit fullscreen mode The current extractors recognize patterns such as: functions and call relationships API paths, frontend wrappers, and backend handlers database access and external HTTP requests OpenAPI documents, documentation, and tests application error codes For example, the test fixture includes a frontend fetch("/api/models"), a Go route registered with r.Post("/api/models", createModel), a database call, an external training request, and a Python error code. The test asserts that the generated graph contains handler, database, external-call, and error nodes together with relationship labels and the original evidence lines. That test matters because a visually convincing graph can still be wrong. I want the graph model—not only the UI—to be testable. Configuration stays explicit A minimal configuration can discover repositories under a workspace directory: { "repoRoots": ["/absolute/path/to/your/workspace"], "include": ["your-repo-prefix"], "baseBranch": "develop", "autoFetch": true, "liveWatch": true } Enter fullscreen mode Exit fullscreen mode Repositories can also be listed individually. Scan limits cover the number of files, API catalog files, changed files, facts, edges, and nodes included in a scenario. The defaults are intentionally configurable because a useful limit for a small service is not necessarily useful for a monorepo. If network access is undesirable, autoFetch can be disabled or the scanner can run with --no-fetch. The UI is a review surface The interface uses React and XYFlow. It provides separate perspectives for current work, team changes, API contracts, and the analysis engine. Search and filters can narrow the graph to changed impact or items that need review. Selecting a node or edge opens the supporting details: source evidence, representative diffs, relationship rules, change briefings, and suggested next checks. The interface is available in English and Korean; the language choice is stored locally in the browser. The goal is not to produce the largest possible graph. It is to make the next review question easier to answer. Local-first does not mean risk-free The scanner reads the source code in the repositories you configure. Its local configuration and generated snapshot may contain absolute paths, repository names, branches, commit messages, pull request titles, function names, API paths, and evidence lines. Both files are ignored by Git by default. Production builds remove the local snapshot and show bundled sample data. I still recommend reviewing screenshots and exported output before sharing them, because local analysis can surface information that was never meant to be public. Current limitations Static extraction is deliberately pragmatic, so it can miss dynamic calls, reflection, generated code, or complex metaprogramming. Coverage also varies by language and framework. A connection in the graph is evidence worth inspecting, not proof that every runtime dependency has been found. The next areas I want to improve are: language- and framework-specific extractors confidence and explanation for inferred edges clearer graph behavior on large systems better pull-request and branch comparison briefings Try it locally You need Node.js 22.13 or newer and at least one local Git repository: git clone https://github.com/soil0119/Where-am-i.git cd Where-am-i npm install cp whereami.config.example.json whereami.config.json npm run dev Enter fullscreen mode Exit fullscreen mode The README includes a PowerShell equivalent and the full configuration options. I would especially value feedback on three questions: Which language or framework extractor would make this useful for your codebase? What evidence would you need before trusting an inferred connection? At what graph size does this kind of view stop helping and start becoming noise? Because this is an open-source project, please feel free to open a GitHub issue for bugs, feature requests, extractor ideas, documentation gaps, or questions—even if you are not ready to contribute code. Issues and contributions are welcome in English or Korean. Disclosure: I used an AI assistant to draft and edit this post. The implementation details and technical claims were checked against the linked repository.