Under the hood

What happens between the ticket and the merge.

Six steps, each with a gate that can stop it. Nothing reaches your reviewers unless the bug cleared extraction and mapping, and nothing reaches your customer until production confirms the fix is live.

webhook · HMAC · vision

Intake.

Every support channel becomes a queue. Zendesk, Intercom, and Freshdesk tickets stream in via webhook. Screenshots get read. Verbatims stay in the customer's language. Structured fields come out the other side, ready for a reviewer.

  • Webhook-driven

    HMAC-verified webhooks with per-tenant secrets where the provider supports it. Idempotency keys, retry-safe.

  • Vision-aware

    Screenshots, DevTools captures, UI traces analyzed alongside text.

  • Code-mixed

    Hinglish, Spanglish, Japanese: customer verbatims preserved unchanged.

StageSourceSubjectSeverityUpdated
Bug Extracted

verify-loop e2e failures: Greet output missing required phrase

zendesk · Acme Robotics · 2m ago

High13 days ago
PR Drafted

Checkout button hangs on Safari iOS 18 over $200

intercom · Northwind Trading · 5m ago

Critical13 days ago
Merged

CSV export missing last 3 rows when row count > 1k

zendesk · Globex · 8m ago

Medium13 days ago
Deployed

Dark mode flickers between routes on Firefox

intercom · Initech · 14m ago

Low13 days ago
RCA Published

Onboarding step 3 freezes after Google OAuth

zendesk · Hooli · 22m ago

High13 days ago
Bug Extracted

PDF upload returns 404 over 5MB on the bulk path

freshdesk · Cyberdyne Systems · 31m ago

Medium13 days ago
Classifying

Webhook signatures rejected by Stripe gateway

intercom · Pied Piper · 42m ago

High13 days ago
Closed

Stale cache after settings update across tabs

zendesk · Vandelay Imports · 1h ago

Low13 days ago

vision · structured outputs

Extract.

Read the screenshot, not just the text. Vision-aware extraction analyzes every attachment, parses the customer's thread, and emits a structured bug report with severity, repro steps, expected behaviour, and the verbatim quote. All typed against a strict schema.

  • Vision-aware

    Structured outputs via JSON schema. Vision on attachments.

  • Severity scoring

    Critical / High / Medium / Low with explanation.

  • Verbatim preservation

    The customer's words, untranslated, attached to the bug.

Customer verbatim
🇺🇸en-USEnglish

Hey team, our cart on Safari 18 just keeps spinning when the total is over $200. I tried two different cards. Smaller carts (≤ $150) work fine and the Stripe sheet opens. We saw a single charge attempt in our dashboard but no confirmation back to the app. This is blocking our weekend sale, please advise ASAP. Browser: Safari 18.0 on iPhone 15 Cart total: $214.50

Checkout button hangs on Safari iOS 18. Smaller carts work, anything over $200 just spins.

pgvector · HNSW · rerank

Map.

Map every signal to the function that owns it. Your repository indexed into a high-recall vector store. A multi-stage search (vector similarity, then a confidence-scored rerank) narrows the candidates to a file, a line, a function name, and a confidence score.

  • Vector index

    Halved-precision embeddings with cosine similarity; near-identical recall.

  • Rerank stage

    Top hits passed to a reasoning model for confidence-scored ranking.

  • Dual ≥ 0.7 gate

    Extraction AND mapping confidence both clear 0.7. Either misses, no billing event.

Code Locations
#1High · 95%
src/greeter.tsgreet

greet() returns a string missing the required enterprise phrase

#2Med · 78%
src/intent.tsdetectIntent

intent classifier short-circuits on empty body, never reaches the greeter

extended-thinking · test co-edit

Draft.

The PR your CI agrees with. An extended-thinking model drafts the fix. The PR includes the source change, every test that exercises the affected function, and a description that traces the customer report → file → fix. A multi-rule validator rejects the proposal if it deletes tests, rewrites snapshots, or inserts no-ops.

  • Extended thinking

    The drafting model reasons through contract changes and edge cases before emitting code.

  • Test co-editing

    The PR updates every test that exercises a changed function in the same diff.

  • Multi-rule validator

    No-op diffs, deleted tests, snapshot rewrites, and rogue imports are rejected before the PR opens.

Draft PR ready for review
Branch:
watari/fix-verify-loop-e2e-fail-greet-output-89f4e027f
Files modified:
1
Confidence:
90%
Semantic check:
Not validated (your CI is the source of truth)
PR:
watari/verify-loop #1289

CI · classifier · re-prompt

Verify.

Your CI is the source of truth. If a check fails, we read the failure log and push the next commit. Not a guess, a fix targeted at the actual stack trace. Reviewer comments trigger a classifier gate that lets only actionable feedback reach a regeneration.

  • CI verify-loop

    Listens to check_run / check_suite / status webhooks. Re-prompts the drafting model against the real failure log.

  • Reviewer-comment iteration

    A classifier reads every comment. Only actionable feedback triggers regen.

  • Semantic re-prompt

    Optional TypeScript / Pyright pass before push. Type errors loop back until clean.

CI verify loop
passing
  • lint4.2s
  • typecheck18.7s
  • test46.1s
  • build2m12s

deploy-gated · multi-lingual

Close.

Production confirms the fix, not merge. Watari watches GitHub deployment_status events and uses the Compare API to verify the merge commit is an ancestor of the live deploy. The customer-facing RCA, translated to the customer's language, publishes only after that verification.

  • Deploy-aware

    GitHub deployment_status + Compare API. Publish on production landing, not on merge.

  • Multi-lingual RCA

    IETF language tags. The drafting model generates the RCA in the customer's language; en-US fallback.

  • Cluster fan-out

    One bug, many tickets. The RCA fans out to every linked thread with idempotency.

Deploy confirmed · production

deployment_status webhook fired at 10:01 UTC; RCA queued for publish.

10:01 UTC
Root-cause analysis
published

Checkout button hang on Safari 18: fix shipped

Hi Maya, the checkout button on Safari 18 was failing because of a null intent guard that misfired when cart totals crossed $200. We have shipped a fix to production at 10:01 UTC and your charge for #4928 is now reattempting automatically. No further action is needed on your end.

Illustration

What the whole loop looks like.

A worked example, not a customer. The measured results, every case including the misses, are on the benchmark page.

  1. Zendesk

    TICKET-4928

    “Checkout button hangs on Safari iOS 18 when cart > $200.”

    Author
    Maya Chen
    Severity
    P1
  2. Watari

    Mapped Issue

    PayButton.tsx:142 · handleSubmit()

    Extraction
    0.91
    Code mapping
    0.86
  3. GitHub

    PR #1289

    fix(checkout): debounce Stripe sheet on iOS Safari

    Diff
    +2 −1
    CI
    passing

multi-repo · CODEOWNERS · deploy-gated

Multi-repo, by design.

Most fixes don’t live in one repo. Watari fans out across every repository scoring above the relevance gate, drafts a PR in each, routes reviewers via CODEOWNERS, and waits for every contributing merge plus a clean production deploy before publishing the customer’s RCA.

Fan-out gate

Cross-repo PR drafts only fire when relevance ≥ 0.7.

CODEOWNERS-aware

Each repo’s reviewers are picked from the file you already trust.

Deploy-gated RCA

Customer reply held until production agrees the fix is live.

The documentation for each step.

Frequently asked questions

How does Watari map a signal to my code?

Your repository is indexed into a high-recall vector store. Each signal runs a vector search, then a confidence-scored rerank narrows the top candidates to a file + function pair.

Does Watari work across multiple repositories?

Yes. The PR orchestrator fans out to every repository scoring ≥ 0.7 relevance. Each repo gets its own draft PR routed to the right reviewers via CODEOWNERS. The customer RCA waits for every contributing PR to merge and the production deploy to confirm.

When does Watari publish the customer-facing RCA?

Automatically, once the fix ships: at deploy time for platforms that report deployments to GitHub (Vercel, Netlify, Render, and most CD platforms), or at merge time otherwise. A periodic check and a manual "Mark as deployed" cover anything we can't observe. If a later deploy excludes the fix, we hold the RCA and surface a rollback banner.

What happens when Watari cannot draft a fix?

The bug still arrives mapped, with the reason recorded: the change is too large to fix safely, every file it maps to is over the 1MB fix ceiling, or a credential already committed to the file blocks the push. You get the mapped issue and the explanation, and a withheld PR does not consume a retry attempt.

Your next support ticket arrives as a draft PR.

Connect Zendesk, Intercom, or Freshdesk, then GitHub or Azure DevOps. Tickets land mapped to the file, function, and line, ready for your reviewer to take over.

Trial length
14 days
Bugs included
10 Mapped
Card required
No
Mismapped credit
7 days
Cancel
Any time

You only pay when we know what to change.