Bug to code
How Watari maps a bug to specific files and functions, what the confidence score means, and what to do when a bug fails to map.
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 reads your default branch, parses every supported source file with tree-sitter, and builds a searchable index of your code. 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 code locations name real functions and classes.
These are indexed too, searchable with accurate line numbers: 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.
Documentation, configuration and data files (Markdown, JSON, YAML, TOML) and machine-generated source (such as Entity Framework *.Designer.cs files) are not indexed.
Languages Watari reads, under For engineers on each repository's page, says which of the three happened to every language in your repository: read in full, read by line, or left out, with a note when a language is left out on purpose.
Getting a typical SaaS codebase ready takes a few minutes. Large monorepos take longer. Under Codebase the repository sits under Watari's move, with the time left, until it reads Ready.
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 searches your indexed code for the functions most likely involved. A rerank step then reads that code alongside the bug and gives each candidate a confidence score and a short 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, Watari looks for the bug in all of them. A repository is included because its code matches the bug, so one bug can produce locations in several repositories.
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, telling Watari where to look on the issue page helps.
The repository index is not yet ready. First-time installs take a few minutes to index. If a ticket arrives while Watari is still reading your code, the issue is written up straight away and Watari looks for its code once the repository is ready. The issue page says it is waiting and how long is left; Codebase shows the same.
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 Watari cannot find the code, the issue page says so under Where it happens. If one detail would help, Watari asks for it in plain words on the issue page, and on the source work item when the issue came from your issue tracker. You have three options:
- Answer Watari's question, in Watari or by replying on the work item and mentioning
@watariai. Watari searches again with the answer. - Tell Watari where to look. An owner or admin can describe, in the next step at the top of the issue page and in your product's words, which screen or feature is involved, or which repository. Watari searches again with that context. Search again reruns the search without new context. Both are for owners and admins, because a new search can make the issue a Mapped Issue on your plan.
- Close the issue. If it is out of scope (a third-party integration bug, a deployment environment problem), close it from the issue 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.