Error triage & investigation

Two loops debug your product. Error triage starts from a crash the 1mn SDK captured and fixes the highest-impact one. Investigate starts from a symptom you describe, traces it to root cause, and always posts what it found — fixing it too when the fix is small and safe. Both work inside a sandbox with your connected GitHub repo.

Error triage — fix the crash users are hitting

When your app reports errors through the 1mn SDK, the triage loop reads the grouped, symbolicated exceptions and turns the single highest-impact one into a pull request.

Prerequisites

• The 1mn SDK installed and reporting. Without it there are no captured errors to triage, and the loop says so and stops.
• A connected GitHub repo to open the fix against.

How it works

1. Loads the assigned error. Auto-filed error tickets carry a Fingerprint: in the brief — that exact error is the target. The loop pulls its full symbolicated stack (frames resolved to original source like app/routes/x.tsx:42 when sourcemaps exist) plus recent occurrences (page URL, time, visitor) so it can see where and when it fires.
2. Finds the root cause. The symbolicated line is where it threw, not always where the bug is — so it reads the surrounding code, the caller, and the assumption that was violated (a missing null check, an unhandled rejection, a changed response shape).
3. Makes the smallest correct fix, matching your conventions, and opens a PR. If, after reading the code, the error isn't reproducible or fixable from the repo — third-party script noise, a browser-extension error, or something already fixed on main — it doesn't invent a change.

When the brief has no fingerprint (a manual run), it lists the open error groups and picks the highest-impact one — preferring high affected-user count, then occurrence count, then a rising trend. One error per run.

Investigate — find the root cause of a symptom

Investigate is for "why is X broken?" File a ticket describing the symptom — "the dashboard total is wrong", "checkout throws on submit", "this started failing yesterday" — and the loop traces it to the line that causes it. Use it when the cause isn't known yet; for a change you've already scoped, use Coding tasks, and to work the captured-error backlog, use Error triage above.

Its discipline is the order: understand → gather signals → reproduce/trace → find root cause → report → decide whether to fix. Proving what's actually wrong is the job; acting is the easy part — it never edits before it can name the root cause and point at the line.

How it works

1. Gathers only the relevant signals — the SDK error detail when the brief carries a Fingerprint:; your saved records and files when it's a data bug ("the report shows wrong numbers", "this record is missing"); recent commits to bracket when a regression began; a web search for an error string it doesn't recognize.
2. Clones the repo and traces the failure backward from the symptom to the line that causes it — reading the caller and the violated assumption (a null that shouldn't be null, a changed response shape, a wrong default), reproducing where it helps by running your tests, the failing function, or loading a live URL from a real occurrence. When timing points at a regression, it uses git blame on the implicated lines to find the commit that introduced it.
3. Always posts a findings comment — a brief, evidence-backed root cause on the ticket. This happens every run, even when it doesn't ship a fix, and even when it couldn't reproduce (an investigation that rules things out is still a finding).
4. Fixes it only when the cause is clear and the change is small and low-risk — then opens a PR alongside the findings, verifying it builds (your repo's typecheck / build / lint) and adding a reproducing test where that's cheap. Otherwise it stops at the findings and hands off.

The findings comment is structured so you can act on it without re-reading the whole investigation:

Root cause.  A null `subtotal` reaches formatMoney() when the cart is empty.
Where.       app/lib/cart/totals.ts:88 — no guard before the .toFixed() call.
Evidence.    SDK fingerprint a1b2c3 — 41 occurrences / 12 users, all on /checkout;
             reproduced by loading /checkout with an empty cart.
Confidence.  High — the symbolicated top frame and the repro agree.
Proposed fix. Default subtotal to 0 in totalsFor() before formatting.

What it will not auto-fix

The fix ships in the same run only when the cause is confirmed against the code and the change is small, self-contained, and low blast-radius. It is always a hand-off — never an automatic edit — when the fix would touch:

• authentication, billing or payments, or secrets / credentials;
• database migrations or schema;
• infrastructure or deploy config; or
• anything destructive or irreversible.

When Investigate stops at the findings, the ticket surfaces an Implement fix button, so you green-light the coding work with the root cause already proven. (When it does open a PR, there's no button — you review the diff and merge.)

What you get

• Error triage: a pull request fixing the single highest-impact captured error, or a short report when there's nothing actionable.
• Investigate: a root-cause findings comment on the ticket every time, plus either a fix PR (when the cause is clear and the fix is low-risk) or an Implement fix hand-off.

In both, the loop opens the PR — you review the diff and merge. Nothing ships without you.

Verifying the fix

A fix isn't confirmed when the PR opens — it's confirmed when the symptom stops after it ships. When the trigger was an SDK error, the PR notes that the fix should be checked against the live error rate after deploy: a later run re-reads the error groups and confirms the group went quiet (a recurrence automatically re-opens it). That last check is the loop closing on itself, not a new investigation.

Notes & limits

• One problem per run, one PR max. Triage fixes one error; Investigate traces one symptom.
• No fixing blind. No edit until the root cause is named and pinned to a line — otherwise it hands off rather than papering over the symptom.
• No fabricated signals. If a log or error trail isn't reachable, the findings say so rather than inventing log lines. Error text and user-supplied data are treated as untrusted input — used to locate code, never executed.
• Errors flow from the SDK. See the SDK page for installing it and how captured exceptions are grouped and symbolicated.