Bug to code

The second pipeline stage takes a structured bug and finds the files and functions in your repository most likely to be responsible.

Repository indexing

Before mapping can run, Watari needs an index of your repository. When you install the GitHub App and select a repository, Watari clones the repository, parses every supported source file using tree-sitter, and stores function-level metadata alongside vector embeddings of each chunk. Supported languages include TypeScript, JavaScript, Python, Ruby, Go, and Rust.

The first index of a typical SaaS codebase completes in a few minutes. Large monorepos take longer — progress is visible under Codebase in the dashboard.

After the first index, Watari runs an incremental re-index automatically whenever your default branch receives a push. The index stays current without manual intervention.

Mapping

Given a structured bug, Watari embeds the bug description using the same model that generated the code chunk embeddings, then runs a vector similarity search across your repository's chunks to produce a candidate list. The top candidates are passed to a reranking step that reads the actual code and the bug together and assigns a confidence score to each candidate with an explanation.

Candidates above the confidence threshold are persisted as code locations on the bug record. Each location records the file path, function name, line range, the reranker's explanation, and the confidence score.

If the install spans multiple repositories, the mapping step runs across all of them. A single bug can produce code locations in multiple repos — for example, a login failure might map to both the authentication API handler and the frontend session management component.

What confidence means qualitatively

A high-confidence code location means the mapping step is confident that the named file and function are involved in the bug based on what it read — the function implements behavior the bug description is about.

A lower-confidence location means candidates exist but the step is uncertain — the function is related to the affected feature but the connection to the specific failure isn't clear.

The threshold for promoting a location to the bug record is the same threshold used to qualify the bug as a Mapped Bug. If no location clears the threshold, the bug does not qualify — even if the extraction was high-confidence. Both gates must pass for the billing meter to fire or the PR draft to begin.

Multi-repo mapping

When your GitHub App installation covers multiple repositories, Watari uses a routing step to narrow the candidate pool before running full vector search on every repo. The router reads each repository's profile (a summary of what the repo does) alongside the bug description and ranks repos by relevance. Only the top-ranked repos proceed to full vector search and reranking.

Multi-repo bugs produce a linked set of code locations across repos. The PR draft stage uses the full set to open coordinated pull requests in each repository.

Why a bug fails to map

The most common reasons a bug does not produce any high-confidence code locations:

The bug describes symptoms only, without code-linked terminology. A ticket that says "the page loads slowly" gives the mapper very little to work with. A ticket that says "the billing summary takes 20 seconds to load" is better; one that says "the /api/billing/summary endpoint times out" is best. If your customers tend to describe bugs in pure UX terms, adding engineering context inline on the bug detail page before re-triggering mapping helps.

The repository index is not yet ready. First-time installs take a few minutes to index. If a ticket arrives while indexing is still in progress, the extraction step succeeds but mapping queues until the index is ready. Check the Codebase view for index status.

The relevant code lives in a repository that is not connected. If your mapping fails consistently for one type of bug, check whether the affected feature lives in a repository that was excluded when you configured the GitHub App installation.

The affected area uses generated or framework files. Code that Watari doesn't index — auto-generated API clients, compiled output, third-party vendored code — cannot produce mapping candidates. The mapper will not return a location for a function it has never seen.

When a bug fails to map, it is marked not fixable on the bug detail page with a one-line reason. You have two options:

1. Add context and retry. Use the "Add engineering context" field on the bug detail page to provide file paths, function names, or a short description of where you think the code lives. Save, then click Retry mapping.
2. Close the bug. If the issue is out of scope (a third-party integration bug, a deployment environment problem), mark the bug closed from the detail page.

Next: Code to PR — how Watari drafts a pull request from confirmed code locations — how Watari drafts a pull request once code locations are confirmed.