Code to PR
How Watari drafts a pull request, runs your CI, iterates on review comments, and hands off for human approval.
TL;DR
Code to PR
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 Bug's code locations are confirmed, Watari requests a sandbox fix attempt. The fix loop:
- Reads the relevant source files identified during mapping
- Reads the bug description, repro steps, and any customer verbatim
- Proposes code changes across the affected files
- Runs a semantic validation pass to check that the proposed changes address the described failure
- Opens a draft pull request via the Watari GitHub App
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.
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 bug detail page. The customer-facing RCA is held until every PR in the stack is merged and a successful production deploy is confirmed.
CI status integration
Watari watches the CI check runs on its draft PRs. The bug detail page and the Slack notification both surface the current CI status.
When all checks pass, the PR moves to Ready for review status on the bug detail page.
When checks fail, Watari's iterate-pr loop reads the failure output and attempts to fix the failing tests or address the lint errors, then pushes a new commit. The loop runs up to the configured retry limit before giving up. When retries are exhausted, the PR is left open as a draft with a comment summarizing what was attempted and where the loop stopped. A human engineer can then pick up from where the loop left off.
The retry limit is configurable in the AI behavior controls — CI verify-loop settings.
Reviewing a draft PR
The bug detail 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.
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's iterate-pr loop 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 Bug was metered when it qualified, not when the PR is opened or closed.
Iteration on review comments
When you leave a review comment requesting changes, the iterate-pr loop:
- Reads your comment alongside the current diff
- Proposes an updated change
- Pushes a new commit to the same PR branch
- Waits for CI to run again
If CI is green after the iteration and you have no further comments, the PR is ready to merge. If CI fails again, the loop retries up to the configured limit. When the limit is reached, the loop stops and posts a summary comment on the PR.
The iteration limit applies per review cycle, not per PR lifetime. You can trigger another round of iteration by leaving additional comments after the loop 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 Bug — 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.