Guide · Lovable fix brief
Test your published Lovable site and send the fix brief back
Lovable’s browser-testing docs say: “Browser testing always runs against the preview of the project you are currently working on” (checked October 22, 2026). This guide covers the step after you publish: run a check on the published URL your visitors open, copy a fix brief from the report, send it into your Lovable project chat with the prompt below, then retest the same check. We make Sybqa, which is not affiliated with Lovable. The one statement here about how Lovable’s testing works is quoted from Lovable’s own documentation.
Have a site ready to check? Test my site free. 10 browser runs a month after sign-up, without AI review. See a sample report first.
First published · Facts checked
What Lovable’s docs say about where browser testing runs
Lovable’s browser-testing docs say: “Browser testing always runs against the preview of the project you are currently working on” (checked October 22, 2026). That is a check you can make while you build. The docs describe the preview, not the published site, so a check of the published URL answers a separate question: what a visitor sees after you publish. Using one does not stop you using the other.
For what Replit and Bolt say about their own testing, see what Lovable, Replit and Bolt say their testing covers. For the full pre-launch list, see the website testing checklist for AI-built apps.
From the published URL to a retest, in five steps
- Publish, then copy the published URL. Use the address visitors open, not the preview link. Check only a site you own or are allowed to test.
- Start a check in Sybqa. Paste the link, add a goal if you like, such as “signup and the pricing page”, and review the plan. Nothing runs until you approve it. A real browser checks the link at desktop (1440 px), phone (390 px) and narrow (320 px) widths, with axe-core accessibility checks.
- Open a finding and copy its fix brief. Each finding that has a fix brief shows a Copy fix brief button and a Download instructions link. Download all fix briefs gives one fix-handoff.md file with every brief. Read a brief before you copy it, as explained below. The report example shows how to read the rest of the report.
- Send the prompt below, then a fix brief, into your Lovable project chat. Sending one brief at a time keeps each change easy to review. If you send several, the prompt asks the builder to stop and report after each one.
- Publish the change, then retest. A check runs against the URL you give it, so the change has to be live there. In Sybqa, open the run and choose Retest after a fix. You review the plan and start the retest yourself.
Who does what
| Step | Where | Who acts |
|---|---|---|
| Check the published URL | Sybqa | You paste the link, review the plan and start the run. |
| Copy a fix brief | The Sybqa report | You copy it. Sybqa does not edit or deploy your code. |
| Apply the fix | Your Lovable project chat | You send the prompt and the brief, and you review what comes back. |
| Publish the change | Lovable | You. |
| Retest | Sybqa | You open the run, choose Retest after a fix, review the plan and start it. |
What a Sybqa fix brief contains
A fix brief is plain text for one issue. The same problem seen on several pages, steps or widths is grouped into one brief rather than one per page. It has the parts below.
| Part | What it holds |
|---|---|
| Target and run | The URL that was checked and the run ID. |
| Recorded failed checks and source checks | How many checks showed the issue, and their check IDs. |
| Observed issue | The observed problem as the run recorded it, with the reported impact and representative browser observations when the run has them. |
| Affected contexts and evidence | Each route and screen width where the issue was seen, with the check ID and the evidence files kept for it, or a note that no file was kept. |
| Reproduce and retest | For a failed journey only: the configured steps, how many steps completed, the assertion the journey was meant to reach and the observed result. Values typed into fields are left out. |
| Task for coding LLM | Five numbered instructions: reproduce the issue, inspect the source without assuming the cause, make the smallest change, verify in a browser and report what remains, and return the changed files with the before and after result. It also says not to claim a fix from code review alone. |
| Pointer to full context | A closing line naming report.json and findings.json in the same evidence bundle. The pasted text does not include those files. |
Journeys can type into fields, and typed values may contain customer data. The brief therefore leaves them out and writes “(input value omitted; use approved test data)” in their place. The person or tool applying the brief supplies the approved test data.
A prompt to send above the brief
Paste this first, then a brief underneath it in the same message. If a step needs typed input, add your approved test data to that message.
The prompt asks the builder to work through briefs item by item and to stop and report after each one. It does not ask the builder to publish or to retest. Those two steps stay with you.
Retest the same check after you publish
Open the run in Sybqa and choose Retest after a fix. The retest starts from the same plan, and its result is compared with the first run, so the original failure stays on record. Opening the run does not start a test.
- A passing retest means that check passed on that run. It does not show that nothing else changed or broke.
- The retest covers the checks in the plan. If the builder changed other parts of the site, look at them yourself or start a new check.
- A step that was blocked or not run is not a pass. If the retest lists one, it is still open.
- If a retest still fails, copy the brief from the new report and send that one.
To run the same saved plan on every deploy instead of by hand, see Run website QA on every deploy.
What this guide does not claim
Common questions
Does Lovable’s browser testing cover my published site?
Lovable’s browser-testing docs say “Browser testing always runs against the preview of the project you are currently working on” (checked October 22, 2026). They describe the preview, not the published site, so a check of the published URL answers a separate question.
Is Sybqa affiliated with Lovable?
No. Sybqa is a separate product that checks a link you give it. A link is enough to start a check; Sybqa does not need your Lovable login, and it does not edit or deploy your code.
Can I paste a Sybqa fix brief into my Lovable chat?
A fix brief is plain text you copy from the report. The report’s file list says the all-briefs file is to “Paste into Cursor, Lovable, Bolt or Claude.” Read the brief first, because it holds your URL, routes and short quotes of what the browser observed, and add approved test data yourself.
Why does the fix brief leave out form values?
Journeys can type into fields, and typed values may contain customer data. The brief writes “(input value omitted; use approved test data)” instead, so the person or tool applying it supplies approved test data.
Will Lovable apply the brief correctly?
We have not measured it and make no claim. The brief tells the builder to reproduce the issue, make the smallest change, verify in a browser and report what remains. Publish the change and retest to check the result.
Does a passing retest mean the issue is fixed?
It means the original check passed on that retest run. The retest covers the checks in the plan, blocked or not-run steps stay open, and a pass does not show that nothing else broke. Look at the site yourself before you share it.
Sources
Related
Try Sybqa on your site
Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.