AI behavior controls

The controls in Settings → AI Behavior let you tune how Watari balances precision against recall — fewer draft PRs and more manual routing, or more drafts and more review work. All changes apply to future processing only; they don't retroactively re-promote or re-demote bugs already in the dashboard.

Extraction language

By default, Watari extracts structured fields (title, description, severity, repro steps) into English so your engineering team reads consistent issue summaries regardless of what language the ticket arrived in.

If your engineering team works primarily in another language, change the default extraction language in Settings → AI Behavior → Multilingual extraction. Supported languages: English, Hindi, Spanish, German, French, Portuguese, Japanese, Korean, Chinese.

The customer's original words are always preserved verbatim in their source language — changing this setting only affects the structured fields, not the customer-verbatim quote.

Cross-lingual deduplication. An optional pre-translation step helps non-English tickets cluster with English tickets about the same bug. If your customer mix skews toward code-mixed scripts (Hinglish, Spanglish, etc.), enabling this toggle improves deduplication recall across language boundaries. It's off by default.

Auto-fix confidence threshold

The Auto-fix confidence threshold slider in Settings → AI Behavior controls the minimum confidence level required before Watari opens a draft PR.

When both the code-mapping step and the fix-generation step produce results above the threshold, a PR is drafted. When either falls below it, the bug is routed to your team for manual review — the AI's reasoning is shown on the bug detail page.

Four qualitative modes guide the slider:

• Aggressive — more PRs drafted, more noise to triage.
• Balanced — Watari's default. Drafts when the pipeline is in strong agreement.
• Conservative — only highly confident fixes are drafted; the rest go to your team.
• Very strict — almost everything routes to manual review. Useful while you're still building trust with the pipeline.

Changes apply to new Mapped Bugs only. Bugs already in the dashboard aren't re-promoted or demoted.

CI verify-loop

The CI verify-loop is off by default. When enabled, Watari watches your GitHub Actions or external CI run on each new draft PR and iterates the fix if checks fail — pushing follow-up commits on the same branch until tests pass or the attempt limit is reached.

Configure:

• Enable verify-loop on draft PRs — toggle on/off.
• Max iterations per PR — how many iteration attempts before giving up. Range 1–5; conservative default is 2.

If you already have CI running on draft PRs, Watari watches those results passively even when the verify-loop is off — CI status is surfaced on the bug detail page and in the Slack notification regardless of this setting.

Reviewer-comment iteration loop

The Reviewer-comment iteration loop is on by default. When a reviewer leaves an actionable comment on a Watari-drafted PR, Watari regenerates the fix and pushes a follow-up commit within 1–2 minutes.

Watari distinguishes actionable requests from praise and questions — lgtm and looks good, any thoughts on X? are skipped. Only explicit change requests trigger iteration.

Configure:

• Iterate on reviewer comments automatically — toggle on/off.
• Max iterations per PR — range 1–10; default is 5. Reviewer-driven iteration usually converges in 1–2 rounds; lower this if you want tighter control over worst-case usage.

Semantic validation (hallucination guard)

Before opening a draft PR, Watari can sandbox-run the language's type checker (TypeScript, Python, Go) on the proposed fix. If it fails, the system gets the diagnostics and tries again — up to the configured limit. The PR opens regardless; any residual errors are flagged on the PR card so reviewers know to look carefully.

This is on by default. If your CI already runs type checking on every PR, this step is redundant — Watari skips it automatically when it detects active CI on draft PRs.

Configure:

• Type-check AI fixes in a sandbox before opening PRs — toggle on/off.
• Max re-prompt iterations per PR — range 1–5; default is 2.
• Daily sandbox-run limit per org — a safety ceiling on sandbox runs per day. Set to 0 to suspend without disabling the feature.

Deploy & RCA

These settings control when the customer-facing RCA is published back to the support ticket.

Publish mode:

• Auto-publish when the fix is confirmed — Watari posts the RCA automatically once the confirmation event fires. Recommended for teams with a fast deploy cycle.
• Manual — Watari drafts the RCA but never posts it until an engineer clicks Publish from the bug detail page. Use this if you want a human sign-off on every customer-facing message.

Auto-publish triggers (when auto mode is on):

• When the fix is deployed to production — Watari watches GitHub deployment_status events and publishes only after the fix actually ships. Safe for any workflow where merge ≠ deploy.
• When the PR is merged — publishes the RCA at merge time. Only safe for trunk-deploy setups where a merge to main reaches production within minutes. Risk: if your deploy fails or stalls after merge, the customer receives an RCA saying the fix is live when it isn't.

Production environment name — when using deployment_status trigger, this tells Watari which GitHub Deployments environment counts as production. Default is production. Common values: production, prod, live. Match this to the environment value in your GitHub deployment workflow.

Soak window — an optional delay (0–60 minutes) after the production deploy event before Watari publishes the RCA. Catches immediate rollbacks before the customer is told the fix is live. Set to 0 for immediate publish on deploy.

Next: Notifications and digest — per-event toggles and daily digest settings — configure per-event notifications and the daily digest.