Bug reports · your users' crashes, fixed by your agent

What it is#

An intake is an automation with a crash reporter in front of it. When something throws on your site, or somebody writes in to say a button does nothing, it lands in the Issues page of your sandbox: what broke, where, how often, and what the person was doing just before.

The difference from an error tracker is what happens next. The thing reading the report has your repository checked out, so it can reproduce the crash, fix the cause and run your tests — instead of paging you at eleven at night with a stack trace.

Reports are grouped, not counted twice#

Every report is fingerprinted the moment it arrives, from the shape of its stack rather than its text: the line numbers, the hash in your bundle's filename, the order id in the message and the host it was served from are all normalized away. So one broken deploy is one issue with a rising count, not one per affected browser.

That is also what makes this safe to leave switched on. A crash loop on a popular page would otherwise be an agent turn per visitor, which is a bill rather than a bug report. A known issue wakes your agent again only once it has happened ten more times since the last look — except when it was already resolved, in which case it interrupts immediately, because a fix that did not hold is the most important thing this inbox can tell you.

1 · Create it#

Open Automations and pick Bug reports, or press New automation, choose Listen (live), then Bug reports. The prompt comes prefilled: judge whether it is worth fixing, read the real source at the build it came from, reproduce, fix, run the checks.

2 · List the sites that may report#

Under Allowed sites, one origin per line — scheme and host only, no path, no trailing slash:

https://example.com
https://www.example.com

Those two are different origins. This is the commonest reason a fresh intake stays empty: the site redirects one to the other, the browser lands on the one you did not list, and every report is refused. List both. The install panel names the origin it turned away.

3 · Paste the snippet#

Press Install on the row and copy the line it gives you. It goes on any page you listed, just before </body>:

<script src="https://sandbox-<id>.<zone>/intake/sdk.js"
        data-automation="bug-reports" data-release="a1b2c3d" defer></script>

data-release is the one worth wiring up. Give it whatever your build already knows — a commit sha, a tag — and the agent checks that commit out and reads your real frames. There are no sourcemaps to upload anywhere in this product, because the thing reading the crash has the source.

With a bundler instead of a script tag, install @intentic/issue-sdk and call init() with the same three values. Anything that is not a browser — a phone, a desktop build, a server — POSTs the documented shape directly and presents an ingest key from the intake's settings instead of an origin.

4 · Check that it landed#

Reload your site, then look at the Install panel again. It lists every origin that has loaded this reporter and whether it was let in, so "installed, nothing has crashed yet" is visibly different from "the snippet never ran".

What gets sent#

• Crashes: uncaught errors and unhandled promise rejections, with the stack and the page.
• What people write in: a description they typed, and an address to reply to if you ask for one. Never grouped with anybody else's — two people describing one annoyance in their own words are two things to read.
• Breadcrumbs: the last few things that happened — console warnings and errors, failed requests, navigations, clicks. A failed request records its method, path and status; never its body, which is where the passwords are. A click is recorded as button#checkout "Pay now", never as the page's content. Keystrokes are not instrumented at all.
• A beforeSend hook is the last word on what leaves the page: return a modified report, or null to drop it. Where you scrub an id out of a message or throw away crashes coming from a browser extension.

What the agent may do about it#

A bug-fix turn is the opposite of a Front Desk's: it needs the run of your repository, and its brief was written by a stranger's browser. So bug-report wakes are held for your approval by default — the wake waits in your approvals queue with the crash's own title on the card, and one click runs it. Read the first few, then set the intake to run on its own if you like what it does.

Everything the report carries reaches the agent under a key that says it came from outside, and the sandbox's own floor holds credential reads and destructive commands in any turn that has taken in outside content. Each issue's turns run in their own git worktree.

Triaging#

The Issues page is three lists, in the order they owe you a decision:

• Waiting on you — open the row to read the stack and the breadcrumbs, then Investigate, Resolve or Ignore.
• Being looked at — a turn is running; the row offers that conversation rather than starting a second one.
• Dealt with — kept, not hidden, because "we fixed this in March" is what makes a recurrence legible.

Good to know#

• The reporter loads from your sandbox, so while the sandbox is off nothing is collected — and nothing on your page breaks either.
• The trigger's filters narrow what wakes an agent, not what is recorded: you can hear about production crashes while still reading staging's, from one intake.
• A daily ceiling caps what one intake can spend, and the grouping is what bounds it long before that.
• A cross-origin script without crossorigin gives every browser "Script error." and nothing else. Those are still reported, grouped by page, which is how you find out to add the attribute.