Code to PR
How Watari drafts a pull request, runs your CI, iterates on review comments, and hands off for human approval.
The third pipeline stage opens a draft pull request with a proposed fix once a bug has confirmed code locations.
Never merge a Watari PR without review. The fix loop produces good results in most cases, but it is not infallible. A human engineer reviews every diff, and that review step is what makes the merge safe.
The fix loop
Once a Mapped Issue's code locations are confirmed, Watari drafts a fix from the mapped code and the bug report (description, repro steps, and the customer's own words), checks that the change addresses the described failure, and opens a draft pull request in your repository.
By default Watari starts on its own only when it is confident the report is a real issue. A report it is less sure about is still located in your code and marked Needs your review, and one click drafts it. You can change this to every located issue, or to never start without being asked, in How Watari works.
The draft PR includes a description that summarizes the bug, the proposed changes, and which customer tickets are linked. It is opened against your repository's default branch and follows your branch protection rules. It will not merge without the approvals your protection configuration requires.
If the repository is public, or Watari cannot confirm that it is private, the PR title, description and commit messages leave out your customers' own words, their quotes from linked tickets, and which support tool they came from. It keeps the bug summary and the number of customers affected, and links to the original report in Watari, so nothing your customers wrote is published to the open web.
Multi-file and multi-repo changes
Fixes can span multiple files in the same repository. When the mapped code locations span multiple repositories in the same GitHub App installation, Watari opens coordinated draft PRs in each (one per repository) and links them as a stack on the issue page. The customer-facing RCA is held until every PR in the stack is merged and a successful production deploy is confirmed.
If Watari starts a fix in one repository and finds the change actually belongs in another connected repository it also mapped (the backend is correct, the frontend that calls it is not), it drafts the fix there instead. That second draft does not use one of the issue's retry attempts.
CI status integration
Watari watches the CI check runs on its draft fixes and shows the current CI status on the issue page. When checks change who needs to act, the issue's Slack or Teams card says so. When a check fails, the per-check breakdown in the Fix section of the issue page names the failing step and, on Azure DevOps, shows the error lines from that step's log, so you can see what broke without opening the pipeline run.
When all checks pass, the PR moves to Ready for review status on the issue page.
When checks fail on a commit Watari pushed, Watari reads the failure output and, if the failure is in code (a compiler error, a lint error or a failing test), pushes one commit that fixes it, with a comment on the PR saying so. It works the same on GitHub and Azure DevOps. It does nothing when the failure is in the build machinery, when someone else has pushed to the PR, or when the same failure comes back after a fix. The PR then stays a draft for a human engineer to pick up.
The setting and the per-PR limit are in How Watari works, For engineers.
Reviewing a draft PR
The issue page in Watari shows the diff inline, the affected files, and the reviewers Watari assigned based on your .github/CODEOWNERS configuration. To complete your review, open the PR on GitHub.
Touch points considered
A defect rarely lives in one place. The same code is often reached from an API endpoint and from a background job, and a fix that only looks at one of them can read as careless even when it is correct. A draft PR therefore lists the other places Watari examined, each with a verdict:
- Changed: the fix edits it.
- No change needed: Watari looked at it and it is correct as written, with the reason.
- Needs follow-up: Watari believes it is also affected but changing it is outside this fix, with what it would do.
- Not examined: this place appears to call the code the fix is about, and the fix did not account for it. It is listed first, so you know exactly what to check before merging.
When Watari finds callers of the code a fix is about, or a parallel copy of it (the same file under a mobile or v2 directory, for example), the first draft of the PR gives each one a verdict, so you do not have to guess whether it was looked at and dismissed or never opened. The list covers product code, not tests, and it is not exhaustive: a function whose name is shared by several definitions, or one called from a great many places, is left to your review.
You have three options from the GitHub PR:
- Approve and merge: the PR moves through your normal merge process (required approvals, required checks). After merge, Watari starts the RCA generation step.
- Request changes with a comment: leave a review comment explaining what should be different. Watari reads the comment and attempts the change in a new commit, up to the configured iteration limit.
- Close without merging: if the bug is out of scope, handled another way, or the fix direction is wrong. Closing the PR does not affect billing, the Mapped Issue was metered when it qualified, not when the PR is opened or closed.
Iteration on review comments
When you request changes, Watari pushes a new commit to the same PR branch that addresses your comment, and CI runs again.
If CI is green after the iteration and you have no further comments, the PR is ready to merge. If CI fails again, Watari retries up to the configured limit. When the limit is reached, it stops and posts a summary comment on the PR.
The iteration limit applies per review cycle, not per PR lifetime. You can start another round by leaving additional comments after Watari stops.
Bundled, not metered
PR drafting and all iterations are included in every plan at no additional charge. The billing meter fires once when the bug qualifies as a Mapped Issue, before the PR is opened. The number of iteration rounds, the number of commits pushed, and whether the PR eventually merges do not affect your bill.
Next: Bug to RCA: drafting and publishing the customer-facing root-cause analysis, how Watari drafts and publishes the customer-facing root-cause analysis after the PR merges.