Multi-repo bug routing: escalate tickets to the right codebase automatically

Watari resolves which repository owns a bug before the escalation artifact is created. When a ticket arrives from Zendesk or Intercom, the pipeline chunks your code with tree-sitter, queries a pgvector index, and runs a reranking step to confirm code locations. The result is a Mapped Issue that already carries a repository, a file path, and a function name, so your engineers never triage the 'which repo?' question manually.

Why 'wrong repo' is as costly as 'no repo'

When a support ticket gets forwarded to engineering as a Slack message or a Linear card without a repository assignment, the first thing an engineer does is trace the symptom to a codebase. For teams running separate front-end, API, and data-pipeline repositories on GitHub or Azure DevOps, that trace can consume an hour of a senior engineer's time before any diagnostic work begins.

Wrong-repo assignment is the same problem one step later. The Jira ticket lands in the API squad's backlog, the API squad investigates for a day, then reassigns to the data-pipeline team. The symptom has now cost two squads context-switching time before anyone opened the relevant file.

The root cause is structural: support tools like Zendesk and Intercom describe symptoms in customer language. Engineering organizes around codebases. Without a layer that translates symptoms into code locations, every escalation is a manual guessing exercise.

Step 1: connect your repositories in Settings

Before the pipeline can route anything, Watari needs read access to your repositories and write access to open draft pull requests.

For GitHub, install the Watari GitHub App and select the specific repositories you want indexed. The App is scoped to an organization and to named repositories: it cannot read repositories you have not explicitly included. For Azure DevOps, the connection goes through Microsoft Entra ID, which gives you the same per-repository scope without personal access tokens. See the full setup steps in the GitHub connection guide and the Azure DevOps connection guide.

Once you connect a repository, Watari clones it and builds a function-level index using tree-sitter. Supported languages include TypeScript, JavaScript, Python, Ruby, Go, and Rust. The first index of a typical SaaS codebase completes in a few minutes. After that, the index stays current as new commits arrive.

How many repositories you can connect depends on your plan tier. See plans and pricing for the current limits.

Step 2: understand how the pipeline evidence-routes to the right repo

The routing decision is not a keyword match. It is a similarity search across every function-level chunk in every indexed repository, followed by a confidence gate.

When a ticket arrives from Zendesk or Intercom, the pipeline runs four stages:

1. Intake. The ticket body, conversation thread, attachments, screenshots, and any stack traces are all read.
2. Extraction. A structured bug is pulled from the ticket: severity, reproduction steps, expected versus actual behavior, and customer impact.
3. Mapping. The structured bug is embedded and compared against the pgvector index across all connected repositories. The top candidates are reranked by a language model that reasons about which functions are most likely responsible for the described behavior.
4. Confidence gating. Two gates must clear before a Mapped Issue is recorded. The extraction step must produce a high-confidence structured bug, and at least one code location must match with high confidence. If either gate fails, no billing event fires and the ticket is surfaced for manual review instead.

The result of a successful map is a set of code_locations: each entry names a repository, a file path, a function, and a confidence score. That set is what drives every downstream action. The routing decision is baked into the evidence, not bolted on after the fact.

You can read the full logic in Bug to code: how Watari maps a bug to specific files and functions.

Multi-repo fan-out for cross-cutting symptoms

Some bugs are genuinely cross-cutting. A payment-flow failure might involve a front-end validation error and an API serialization bug in the same user-visible symptom. When the mapping step finds high-confidence code locations in more than one connected repository, Watari opens a draft pull request in each. Both squads get a PR with their relevant diff; neither squad is blocked waiting for the other.

A migration shipped in mid-2026 addressed the edge case where one of those sibling PRs comes back as not fixable, meaning the language model correctly determined there is nothing to change in that repository. That result is now treated as non-blocking: the fix in the relevant repository proceeds normally, and the low-relevance sibling is marked accordingly rather than holding up the whole bug.

Step 3: configure CODEOWNERS so routing resolves to a named reviewer

Knowing the right repository is necessary but not sufficient. A draft PR assigned to a generic on-call queue or to the whole engineering team reintroduces the triage problem at the review stage.

Watari respects your repository's CODEOWNERS file. When a draft PR is opened, reviewer assignment follows the ownership rules already declared in your codebase. If src/billing/invoices.ts is owned by @payments-team, the draft PR for a billing-related bug goes to that team automatically. No separate routing table to maintain inside Watari.

This matters most for multi-repo setups. If your API repository has CODEOWNERS entries that route database-layer files to the data-infra squad and request-handling files to the backend squad, the draft PRs land with the right engineers even when two files in the same repository are responsible.

The CODEOWNERS behavior is documented alongside the rest of the PR lifecycle in Code to PR: how Watari drafts a pull request and hands off for human approval.

A few things to confirm before relying on CODEOWNERS routing:

• The CODEOWNERS file is present at the root or in .github/ of each repository.
• The teams and individuals listed in CODEOWNERS are members of your GitHub organization.
• Branch protection rules in your target repositories allow draft PR creation. Watari opens PRs as draft; the fix is never merged without human review and approval.

Step 4: handle the low-confidence fallback

Not every ticket produces a high-confidence mapping. The pipeline is designed to surface uncertainty rather than make a wrong routing decision silently.

When a ticket fails either confidence gate, it does not become a Mapped Issue. The billing meter does not fire. The ticket appears in your Watari dashboard with a reason that explains why the mapping did not qualify, and a Retry action that lets you act on it after adding context.

The most common reasons a ticket fails to map across a multi-repo setup:

• The ticket describes a UX symptom with no technical detail. Adding reproduction steps or attaching a HAR file or stack trace from Zendesk gives the extraction step more signal.
• The responsible code is in a repository that has not been connected or has finished indexing. The fix is to connect the repository and wait for the first index to complete.
• The symptom genuinely spans multiple repositories but the overlap signal is too diffuse to clear the confidence threshold in any of them. This is a real edge case; the resolution is usually a more specific repro in the ticket.

You can also adjust confidence threshold preferences in Settings → AI Behavior to shift the pipeline toward more draft PRs at the cost of more review work, or toward fewer drafts and more manual routing. The tradeoff is explicit: a lower threshold produces more drafts but some will need to be discarded; a higher threshold produces fewer drafts but more tickets will surface for human routing.

What the escalation artifact looks like end to end

When all four steps succeed, the escalation artifact is not a vague Slack message. It is:

• A structured bug record with severity, reproduction steps, and customer impact.
• Named code locations: repository, file, and function for each responsible chunk.
• A draft pull request in the right repository, assigned to the CODEOWNERS for the affected files.
• Synced to Linear or Jira (if connected) as a secondary ticket, so project management reflects the routing decision.
• A customer-facing RCA queued for publish once the fix ships and is confirmed in production.

All of that happens from a single Zendesk or Intercom ticket, without a support engineer sending a Slack message and without an engineering manager deciding which squad owns the bug.

For teams running more than one repository, the payoff is proportional to the number of repos. The more codebases in your stack, the more expensive the manual 'which repo?' question becomes, and the more leverage the automated routing delivers.