How Sarcio works

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.

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:

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 — the same bug still failing in a second browser is part of the demo script for a reason. 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. Low-risk patches take one approval; elevated-risk patches — including every module patch — require 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.

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 reload. 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.

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. With the Jira integration enabled, a ticket is filed when the patch drafts, commented as it goes live, and transitioned when the fix merges — your tracker reflects reality without anyone typing.

The three patch kinds

DOM patches — visual and markup bugs

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.

Server patches — API and backend bugs

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 thin shim in your app (Node, PHP, Java, or the WordPress plugin) talks to a Go sidecar you host, which verifies every rule's signature and fails closed — if anything is wrong, your app behaves exactly as if Sarcio weren't there.

Module patches — real logic bugs

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, hot-swapped into the running app with state preserved — React component state survives via real Fast Refresh, vanilla modules re-run their dependents, web workers apply over a verified bridge, and Angular components are re-created with their state carried over. On the server, Node clusters roll the swap out with a canary: one dedicated worker gets the fix first, only tester-marked traffic routes to it, and rollout to the whole cluster — or rollback — is an explicit step after verification on real traffic.

Module patches are built from your repository — either on the control plane or inside your own CI/CD, so your source never has to leave your infrastructure. More on that in the security model.