Run your first fix

1. 1

   Find the bug on the live page

   On the Meridian demo, a status page, every metrics widget fails: the API rejects each query with 400 range is required because the page never sends a range.

   

   Enlarge

2. 2

   Report it from the page

   Open the widget's launcher in the corner, describe what you did and what happened, and press Send report. You don't need to copy errors: console and network context ride along automatically (twelve requests on this report).

   

   Enlarge

   When the problem is a specific element, press Pick element and click it. The report then carries its selector and HTML, so the draft targets exactly that element.

   

   Enlarge

3. 3

   Review the draft

   The report appears in the dashboard's Inbox with a proposed patch: the operation, the AI's explanation, and when the live patch will expire. Every draft lands unrated; nothing is live yet.

   

   Enlarge

   Read the operation against the error

   The explanation always sounds reasonable. Check the operation itself against the error in the report: would this exact change make the failing request succeed? That is the question approval answers.
4. 4

   Steer and regenerate a wrong draft

   On Loopdesk, sign-up failed with 400 taxId is required. The first draft defaulted taxId to an empty string. But the handler rejects a blank value too, so approving it would have changed nothing.

   

   Enlarge

   Don't reject it. Type what the draft got wrong in the steering note under the patch, say what would work, and press Regenerate.

   

   Enlarge

   

   Enlarge

   The same happened on Fernwood's newsletter route: the draft picked a list called default, but the route only accepts sunday-letter and field-notes. One steering note ("this form is the Sunday Letter") fixed it. Setting the site's server source file (see the Git host guides) lets drafts read the handler and avoid most of these misses.

   

   Enlarge

5. 5

   Rate the risk and approve

   Answer How risky is this patch? before approving. The rating is yours to make and is set once.

   • Low: you're confident. Approve & go live signs the patch and ships it immediately.
   • Elevated: the button becomes First approval — send for a second review. The patch waits until a different signed-in reviewer approves it.

   Use Preview first when you want to see a change on your page before anyone else does.

   If your workspace allows acting links and you have one, an unticked Also act as me box appears next to the button. Tick it and Sarcio also acts as you for the accounts you upgraded: it approves the fix pull request on the Git host, and posts the Jira go-live comment. It doesn't change the approval in Sarcio, and if it fails the workspace connection carries on as usual.

   

   Enlarge

6. 6

   Watch the page heal

   A server-side fix takes effect within a second or two. Click the same button again: the request that failed now succeeds, and nothing was deployed.

   

   Enlarge

   

   Enlarge

   A front-end fix reaches pages that are already open over a live connection. No reload, and the visitor keeps what they typed.

   

   Enlarge

7. 7

   Find the ticket and the pull request

   With Jira connected, approval files the ticket (MERIDIAN-2 here). Soon after, the permanent-fix pull request opens, titled with the ticket key. The report page links both and shows the diff the PR carries, with a Build: passing / failing / running chip for your CI once it reports. On the Git host, the PR's head commit carries a sarcio/approval check naming the approver, which branch protection can require (see your Git host's guide).

   

   Enlarge

   

   Enlarge

   Every live patch has an expiry date. Merge the permanent fix before then, so the patch has nothing left to do.

8. 8

   Retry the pull request if the Git host refused

   If the Git host rejects the pull request, the fix stays live and the report page says so. Fix what the Git host complained about, such as an expired token or a GitHub organization that hasn't approved the app, then press Retry pull request.

   

   Enlarge

Customize PR, commit and ticket text

Admins can give Sarcio writing instructions for three kinds of text: the pull or merge request title and description, the commit message, and the Jira ticket (its summary, description and the comments Sarcio posts). Set a workspace default under Writing, or override it for one site in Sites → Manage → Writing. A site's instructions win, then the workspace default, then Sarcio's built-in text.

Pull / merge request  Title in the imperative, under 70 characters.  Description must have ## Summary / ## Risk / ## Rollback sections.
Commit message  Use Conventional Commits with a scope from the file path, e.g. fix(checkout): ...
Jira ticket  Write summaries as user-facing problem statements under 80 characters.  Include acceptance criteria as a checklist.

Press Preview next to any field to see the result against the site's most recent patch (or a sample bug) before saving. Previews never touch your Git host or tracker.

• Sarcio's details are always added. Whatever the instructions say, the PR keeps its Sarcio context section, commits and titles keep the ticket key from your commit convention, and tickets keep the patch id, report link and expiry.
• The code doesn't change. Instructions shape wording only. The permanent fix is the same minimal edit either way.
• It falls back quietly. If AI is off or the model's text doesn't fit (too long, wrong shape), Sarcio uses its built-in text and the pull request or ticket still goes out.
• It doesn't use a draft. This text belongs to a draft that already counted, though its model calls spend AI credits like any other.

Troubleshooting

• No draft appears. The report is kept for manual triage when drafting doesn't run, for example when the month's AI drafts or credits are used up, or the site sent more reports to AI triage than its plan's intake limit allows. The report says which. Press Try drafting again on the report later.
• Approve & go live is greyed out. Pick Low or Elevated first. An unrated patch can't be approved.
• The second approval is refused. An elevated-risk patch needs a different reviewer from the first approval. Ask a colleague to sign in and approve.
• A server-side fix is live but the page still fails. Check the sidecar is running with the site's sidecar key and your app can reach its socket. Without the sidecar, your app runs its normal code.
• Pull request failed with 401 or 403. See the troubleshooting section of your Git host's guide: GitHub, GitLab, Bitbucket. Then Retry pull request.
• No sarcio/approval check or build chip. Both are best-effort. A fine-grained GitHub token also needs Commit statuses (read and write) and Checks (read); add them and the next pull request shows both.