Join the waitlist
Capture & fix · Fixes and approvals

The fix arrives tested.Your engineer says yes.

Tore writes the change and its tests, has a second model check it, and preps the pull request. By default it waits for your engineer's approval, and the risky parts of your code always go to a person.

Join the waitlistSee how a fix is checked

Tore opens soon. Join the waitlist and we'll email you the day you can start.

app.tore.ai/beacon-data/fixes
Example data

Example: a fix queue with columns Investigating, Fix and tests, Second review, Awaiting approval and Deployed. Tore carries Priya's bug across the board: root cause found in paginate.ts line 57, 48 of 48 tests passing with one new test, reviewed by a second model, pull request 482 prepared and waiting, approved by Alex, deployed in version 2.4.2 and Priya told. A billing change stops in Awaiting approval because billing always goes to a person.

Your engineer's jobbecomes review and merge.

Tore does the slow middle of every bug: the change, the tests, the second opinion, the pull request and the note to the customer.

A change arrives tested

Tore writes the fix and runs your tests, so you get a working change, not a suggestion to try.

turning a bug report into a patch by hand

A cross-check you didn't staff

A second model reviews every fix before your engineer sees it.

waiting a day for someone to review it

Risky code stays with people

Auth, billing, migrations, personal data, tenant isolation and secrets always go to a person.

auditing every AI change line by line

Customers hear back

The people who reported it are told when the fix is live, without anyone remembering to.

a sticky note to email Priya when it ships

From the chat widget

Every fix starts with a report your customer made in seconds. They pinned the element, marked up a screenshot and recorded the screen from your chat widget, so Tore starts from evidence.

  • Pin the element
  • Marked-up screenshot
  • Screen recording
  • Last 30 seconds
  • Console and network
  • Secrets stripped
See the bug tools

Every fix shows its work.You decide how far it goes.

The change

A fix with tests, not a guess.

Tore writes the change against your real repository, runs your test suite, and adds a test for the bug it just fixed. Your engineer opens a change that already works.

  • Writes the fix and runs your tests
  • Adds a regression test, so the same bug doesn't come back
  • Checks the fix on staging before you see it
  • When a recent pull request caused it, offers to revert it first
fix · TCK-482
Example data
src/export/paginate.ts+1−1
55 const pageSize = 1000;
56 for (let page = 0; ; page++) {
57- if (rows.length >= pageSize) break;
57+ if (batch.length < pageSize) break;
58 rows.push(...batch);
$ pnpm test export ✓ exports every row past 1,000new ✓ keeps the header row ✓ 46 more passed 48 passed · 0 failedstaging: 4,812 rows ✓

The second opinion

A second model reviews it.

One model writes the fix. A different model checks it before your engineer is asked to look, the same way a teammate would review a pull request.

  • The reviewer is a different model from the one that wrote it
  • Checks the change matches the root cause and touches nothing else
  • Notes come back to the writer and get fixed before you see them
review · PR #482
Example data
Wrote the fixCodex · high
ReviewerClaude Opus · high
Change matches the root causepaginate.ts:57
No unrelated files touched1 file
New test fails before, passes after1 new
Note: empty export should still write headersfixed
Looks good. Ready for your engineer.

You step in

You steer. Tore revises.

Your engineer can request changes on any prepared fix in plain words. Tore replies, revises the change and re-runs the tests. Or they take it over, and Tore steps back.

  • Request changes in a sentence, right on the fix
  • The revised diff and a fresh test run arrive in the same thread
  • Take it over at any point: the branch is yours
PR #482 · review
Example data
fix: export stops at 1,000 rows
ApproveRequest changesTake it over
Alex · engineer

Request changes: keep the old cursor for v1 exports.

Tore

Got it. v1 exports keep the old cursor and the new loop runs for v2 only. Revising and re-running the tests.

src/export/paginate.tsrevision 2+1
54+ if (job.version === 'v1') return legacyCursor(job);
55 const pageSize = 1000;
56 for (let page = 0; ; page++) {
✓ v1 exports keep the old cursornew 49 passed · 0 failedready for Alex

Autonomy

You choose how much it does alone.

Set autonomy per repository: watch only, suggest, open a draft pull request on its own, or check the fix on staging first. Turn it up as trust grows.

  • Four autonomy levels: observe, assist, auto-draft, verify on staging
  • Four approval rungs per area: automatic, confidence-gated, approval required, human review
  • An area's setting can only be tighter than the default, never looser
  • Add your own risk classes for the code only you know is sensitive
settings · autonomy
Example data
Autonomy by repositoryBeacon Data
beacon/web
ObserveAssistAuto-draftStaging
beacon/api
ObserveAssistAuto-draftStaging
beacon/billinglocked area
ObserveAssistAuto-draftStaging
Copy and UI textautomatic
Exports and reportsconfidence-gated
Webhooksapproval required
Payments codehuman review

Locked risk classes

The dangerous areas always go to a person.

Six risk classes are locked. A change that touches one is sent to human review, whatever any other setting says. Tightening them tightens everything at once, so an old loose setting can't leak through.

  • Auth, billing, migrations, personal data, tenant isolation, secrets
  • One shared list, so every part of the product agrees on what is dangerous
  • Locked classes can never be loosened anywhere
risk classes
Illustration
Locked to a person6 classes
Auth Billing Migrations Personal data Tenant isolation Secrets
TCK-479 fix touches src/billing/invoice.ts
beacon/api: Assistbilling
Sent to human review. Billing is locked, so the lock wins over the repository setting.

After it ships

The people who reported it hear back.

When the fix is live, Tore tells everyone who reported the bug, in the conversation they started. Nobody has to remember who was waiting.

  • Reporters told automatically when their fix is live
  • Everyone who reported the same bug hears back, not just the first
  • The ticket closes with the pull request and version attached
TCK-482 · activity
Example data
Alex approved PR #482
deployed v2.4.2
Tore to Priyain her original conversation · 10:03

Fixed. Your export now includes every row, not just the first 1,000. Thanks for the replay, it pointed us right at it.

Also told: 3 others who reported it

Tune it

Autonomy · beacon/web auto-draftNever touch billing/Reviewer Claude Opus · high
All AI controls →
6risk classes locked to a person
4approval rungs, set per area, only ever tighter
2models on every fix: one writes, one reviews
1click to approve and open the pull request

Keep exploring.

Capture & fixAI investigationsWhere the fix starts: a root cause down to the file and line.See how → Capture & fixAutopilotDecide what Tore picks up on its own, with limits and a stop switch.See how → SolutionsDevelopersPull requests, tests and staging checks, from the engineer's side.See how →

Hand your engineer a fix,not a ticket.

Connect a repository and the next bug arrives as a tested change, reviewed and ready to approve.

You're on the list. We'll email you the day you can start.

Get early access when Tore opens. No spam.