File bugs that reproduce themselves

The idea

A browser extension that sits idle with a ring buffer running. When someone hits a bug, they click the button and the extension packages the last ninety seconds: DOM session replay, console output, network calls with bodies, browser and viewport details, and the ordered list of elements they interacted with. It then compiles that interaction trace into a Playwright spec and attaches both the replay and the spec to a new issue. The engineer who picks it up runs one command and watches the bug fail in CI.

Why build this

Most bug reports are a sentence and a screenshot, and the first thing an engineer does is spend twenty minutes failing to reproduce them. Existing capture tools (Jam, Bugbug, the recorder built into Chrome DevTools) solve the recording half well, but they hand you an artifact a human has to watch. The gap is the last step: turning the recording into a test the project already knows how to run. Every team has QA folks, support agents, and designers who find real bugs and can't write a repro; every team also has a Playwright or Cypress suite sitting right there. Session-replay libraries are mature now, Manifest V3's chrome.debugger gives you CDP access from an extension, and a small model is good enough to turn a click trace plus DOM context into stable selectors — which is the part that used to make generated tests worthless.

Stack sketch

• Extension: Manifest V3, TypeScript, a service worker holding the buffer and a content script for the capture UI.
• Recording: rrweb for DOM mutations and input events; chrome.debugger attached to the tab for Network.* and Runtime.consoleAPICalled events.
• Buffer: fixed-size ring in IndexedDB, roughly 20 MB, oldest events dropped continuously so nothing leaves the machine unless someone clicks.
• Redaction: pre-upload pass that drops Authorization and Cookie headers, masks inputs marked type=password or data-sensitive, and applies user-supplied regex rules to request bodies.
• Backend: FastAPI plus Postgres for bundle metadata, S3-compatible object storage (Cloudflare R2) for the replay payloads.
• Codegen: Claude via the Anthropic API, prompted with the interaction trace and the DOM snapshot around each target, asked to prefer getByRole and getByTestId selectors and to refuse anything nth-child-shaped.
• Delivery: GitHub and Linear APIs for issue creation; the generated spec goes in as a patch on a branch named after the issue.

Scope for v1

• Chrome only, one capture at a time, manual trigger.
• Playwright TypeScript output only. No Cypress, no Selenium.
• GitHub issues as the single destination; Linear later.
• A hosted replay viewer with a timeline synced to console and network panes.
• A "does this spec actually fail?" check: the backend runs the generated test once against the reported URL and labels the issue repro-verified or repro-unconfirmed.
• Deliberately out: authenticated-flow recording, mobile, screenshot diffing, anything resembling a dashboard.

Where it could go

The verification runner is the wedge into CI. Once you are already executing generated specs to confirm they fail, promoting the confirmed ones into the project's suite is a small step, and now every reported bug becomes a permanent regression test. Teams end up with a suite grown from real user pain rather than from whatever an engineer imagined during sprint planning.

The second path is auth. Most interesting bugs live behind a login, and recording a session that starts logged in means capturing storage state and replaying it in the runner — doable with Playwright's storageState, but it turns a capture bundle into a credential and changes the security story completely. Worth charging for, worth doing carefully, and worth doing second.

Watch out for

The selector quality decides whether anyone trusts this: one flaky generated test and the team stops running them. Bias hard toward refusing to emit a spec when the trace is ambiguous, and label those issues as replay-only rather than shipping a guess.