How Sarcio works

A production bug has two problems: your users are hitting it now, and the real fix takes time to ship. Sarcio solves both at once — a temporary, signed, reversible patch goes live in seconds, and the permanent source fix opens as a pull request in the same motion.

1. The report starts on the page

A small reporter widget lives on your site — visible to whoever you choose: your QA team, your client, your support agents, or everyone. When someone hits a bug, they flag it right where it happens. The report arrives with the context an engineer usually spends an afternoon reconstructing: what was on screen, recent console output, the failing network calls, and an optional screenshot.

No more "can you send a screenshot?" round-trips, no more works-on-my-machine dead ends — reproduction context is captured at the moment of failure.

A Sarcio report with its Screenshot panel open, showing the Alpine & Oak cart exactly as the reporter saw it: TRAIL10 at minus $14.90, yet a total of $173.85 — The reviewer sees the page exactly as the reporter did: a real Alpine & Oak report, with the total that went up in view.

The report's Element HTML panel showing the picked span with the coupon amount — The element the reporter picked, as HTML.

The report's Context panel listing the page's network calls with status and timing — Console and network calls from the moment it failed.

2. AI triages and drafts — it never ships

Sarcio's AI reads the report and its context, triages what kind of failure it is, and drafts the smallest fix that addresses it. Two hard rules keep the AI in its lane:

The draft is constrained. DOM and server patches are data — a fixed vocabulary of operations validated server-side against hard deny-rules. There is no path for the AI to emit free-form code into them.
Your reviewer sets the risk level, not the AI. A draft arrives unrated. The first person to review it decides whether it is routine or needs a second pair of eyes — because that depends on your product, not on which operation the patch used — and rating it elevated raises the approval bar to two different people.

3. Preview in isolation

Before anything goes live, an approver previews the patch applied for them alone. The rest of the world keeps seeing the unpatched site: open it in a second browser and the bug is still there, which is how you know the preview is yours alone. What you approve is exactly what ships.

4. Approval — with a second set of eyes when it matters

Every patch is approved by a human, and that human sets its risk level as part of approving it. Rate it low and your approval takes it live; rate it elevated and it needs two distinct approvers before anything is signed. Roles are enforced server-side: reviewers review, admins administer, and the audit log records who did what, from where, when. Approval happens only in Sarcio, by a signed-in person: an API token can't approve, and an approval on GitHub, GitLab or Bitbucket never counts toward it.

5. Signed, delivered, live — in seconds

On approval, the patch manifest is signed with your workspace's own Ed25519 key and broadcast over WebSocket. Every connected client verifies the signature against your workspace's published key before applying anything — then applies the fix live, with no redeploy (a React code fix reloads the open page onto it). Patches carry a hard expiry: if a patch somehow outstays its welcome, clients roll it back on their own.

Retiring is the same motion in reverse: one click, and every visitor is back on the original behavior, live.

The Alpine & Oak cart after the module patch went live: TRAIL10 at minus $14.90 and a total of $144.05 — After approval, the swapped pricing module subtracts the discount: $149.00 plus $9.95 shipping, minus $14.90, is $144.05.

6. The permanent fix is already in flight

In the same motion, Sarcio opens a pull request (or merge request) against your repository — GitHub, GitLab, or Bitbucket — carrying the permanent source fix. Merge it, and the temporary patch auto-retires. If the PR is closed or stalls, the patch is flagged on an orphaned-patches view instead of being quietly forgotten. The PR carries a sarcio/approval check naming who approved it, and Sarcio reads your CI result back onto the report page. If the Git host refuses the PR, the fix stays live and one click retries it.

With Jira connected, a ticket (a Bug, unless you choose another type) is filed when the patch goes live, or as soon as it drafts if you prefer. Milestones land as comments, the go-live one @mentioning the approvers, and the ticket moves to the status you pick when the fix merges — your tracker reflects reality without anyone typing. Admins can give Sarcio writing instructions so PR, commit, and ticket text follow your team's conventions.

One pipeline, three reaches

The three patch kinds

Visual & markup bugs

DOM patches

Constrained DOM operations applied by the widget in the browser: remove the stray attribute breaking a form, correct a broken element, hide the overlay that swallowed the checkout button. Never arbitrary JavaScript — the operation vocabulary is fixed and enforced server-side.

API & backend bugs

Server patches

Declarative request/response rules enforced at the boundary: default or strip a field, set a header, skip a broken validation, override a config value, reshape a response, gate a route. A small library in your app (Node, PHP or Java) talks to a sidecar you host, which verifies every rule's signature and fails closed. On WordPress the plugin does the same itself, on ordinary hosting, and so can the PHP library where a host cannot run a service.

Real logic bugs

Module patches

Some bugs live in code, and a DOM tweak can't fix subtotal * 0.1 * 2. Module patches replace exactly the modules a source fix touches in the running app: a React page reloads onto the fix, plain JavaScript and Angular swap it in with state kept, and on the server a canary worker takes the swap first. Built from your repository, optionally inside your own CI/CD. More in the security model.

See the whole loop on your own site.

Workspace, widget, first report, first live fix — it's a same-afternoon setup.

Create a workspace