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 connect a code host (the GitHub App, or Azure Repos through Microsoft Entra ID) and select a repository, Watari streams an archive of your default branch, parses every supported source file using tree-sitter, and stores function-level metadata alongside vector embeddings of each chunk. Your source code is never stored: the index holds embeddings plus metadata (file path, symbol name, line range), and the archive is discarded once it has been parsed.

Tree-sitter parses TypeScript, JavaScript, Python, Ruby, Go, Rust, Java, Kotlin, Scala, C, C++, C#, PHP, Swift, Objective-C, shell, Dart, Elixir, Lua, Zig, Terraform and HCL, and GraphQL schemas, so chunks land on function and class boundaries with real symbol names.

Files a fix routinely edits that have no grammar in that set are indexed too, chunked by line window so they stay searchable with accurate line numbers and no invented symbol names: Vue, Svelte and Astro single-file components, HTML, Handlebars and Go templates, CSS, SCSS, Sass, Less and PostCSS stylesheets, SQL, tree-sitter query files, XML and MSBuild build files such as pom.xml and .csproj, Erlang and R.

Templates matter more than they look. An Angular component is three files, a .ts, an .html and a stylesheet, so a rendering or conditional-display defect frequently lives in the .html and nowhere else.

Documentation, configuration and data files (Markdown, JSON, YAML, TOML) are deliberately left out of the index. Prose scores higher against a bug description than the code that causes the bug does, so indexing it would push real answers out of the candidate list. Machine-generated source is left out for the same reason: an Entity Framework *.Designer.cs snapshot is a wall of entity boilerplate that matches any bug naming a field, and nobody fixes a bug by editing one.

The Language coverage card on each repository says which of the three happened to every language in your repository: parsed with a grammar, indexed by line window, or not indexed.

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 Issue. 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 workspace has more than one repository connected, on either code host, the search itself decides which repositories are relevant. There is no separate guessing step. Watari runs the bug description as a similarity search across the indexed code of every active repository at once; the repositories whose code actually matches become the candidate set, and only those proceed to reranking. Routing is evidence-based: a repository is searched because its code matched the bug, not because a summary of the repo sounded related.

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 chose which ones to connect.

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.