ERRase/ docs
How It Works

The Pipeline

From the moment an error fires in your browser to the moment your file is patched — here's exactly what happens.

1

Error Detected

A runtime error fires in your browser. ERRase's injected script — running in the page's main world — catches it via window.onerror and unhandledrejection before it reaches the console.
2

Stack Trace Resolved

The raw error is forwarded to the local CLI via WebSocket. The CLI fetches the .js.map file from your dev server and maps each bundled frame back to the original source file and line number — skipping node_modules frames automatically.
3

Context Extracted

The CLI reads ±15 lines around the failing line directly from your filesystem. Only that snippet is sent for analysis — your full codebase never leaves your machine.
4

AI Analysis

The snippet and error message go to Llama 3.3 70B via Groq. The model identifies the root cause, generates a one-line fix, and returns a plain English explanation alongside it.
5

Fix Applied

The overlay shows the explanation and diff. Click Apply Fix — the CLI does a surgical string replace on your file and saves it. Your dev server hot-reloads automatically.

Why local CLI?

Browser extensions can't access your filesystem or patch files directly. The CLI runs on your machine and acts as the bridge — it has filesystem access, can fetch source maps from your local dev server, and writes fixes back to disk. The extension handles the UI. The CLI does the heavy lifting.

Privacy

Privacy note

Your source code never touches ERRase servers. The CLI reads files locally and sends only a small snippet to Groq for analysis. Your API key is stored locally in your browser and transmitted directly to Groq — ERRase never sees it.