Lovable Rigor

Lovable Rigor

Lovable's agent is capable but self-reported "done" is not verified truth — it can misdiagnose, patch the wrong thing, forget to publish, or introduce a regression while fixing something else. This skill is the checklist that catches those failure modes before they reach production, distilled from a long QA/hardening engagement where every one of these failure modes actually happened at least once.

Core loop for any non-trivial request to Lovable

1. Investigate first, fix second. For anything beyond a one-line typo, tell Lovable explicitly: "investigate and report findings before writing any code." Don't let it jump straight to a migration/patch on a hunch — a wrong root-cause guess produces a fix that looks plausible and does nothing.
2. Verify the finding yourself before approving a fix. You have the same Supabase MCP tools Lovable does. Before approving a proposed fix, independently confirm the root cause: read the actual function definition (pg_get_functiondef), the actual constraint, the actual RLS policy, the actual data — not just Lovable's description of it. This is the single highest-leverage habit in this whole workflow: it catches misdiagnoses, stale claims, and "confirmed" findings that don't hold up.
3. After Lovable reports a fix shipped, re-verify the fix directly — don't trust the report. Query the deployed function/schema again, or drive the actual UI, to confirm the fix is really there and really works. A "done" message is a claim, not evidence.
4. Ask for live proof on anything security- or data-integrity-sensitive, not just a passing test suite: have Lovable reproduce the original failing scenario against the fixed code and show you the before/after, ideally via a rolled-back transaction or tagged scratch fixtures so nothing real gets touched. Then confirm that proof yourself with a second, independent read.

The publish gap (catches people constantly)

Lovable's code changes land on the preview build immediately, but require an explicit publish action to reach the real production URL. A "shipped" report can be true for preview and false for production simultaneously.

• After any fix that needs to be live, ask Lovable to publish, then confirm yourself: fetch /version.json (or equivalent build-stamp endpoint) on the actual production domain and check the build hash/timestamp actually changed. Don't just check preview.
• Publishing isn't instant — poll for the new hash rather than checking once and assuming failure.
• If Lovable's response shows only a <lov-open-publish>-style UI affordance rather than an actual publish tool call, that means it didn't publish — call it out and ask it to actually trigger the publish.

Safe testing against real-shaped data

• Prefer rolled-back transactions (BEGIN; ... RAISE EXCEPTION 'rollback';) for exercising RPCs/triggers against real schema without leaving residue.
• When persistent test fixtures are unavoidable, tag them distinctly (e.g. a qa-<cluster>- prefix in a name/notes field) so they're easy to find and batch-clean later, and agree explicitly on when cleanup happens (usually: end of the full pass, not mid-pass, in case a later step needs to reference earlier state).
• For a real client's production data: default to read-only unless the user explicitly authorizes a specific write, and say so out loud before doing anything destructive or corrective on their account.

Reviewing Lovable's own migrations/diffs

• For edits to an existing SQL function, ask for (or read yourself) a diff against the previous version rather than trusting a full-body rewrite — full rewrites are exactly where unrelated lines get silently mangled (wrong column name, dropped guard, reverted logic) while "just" fixing one thing.
• When Lovable rewrites a whole function to change one clause, that's a smell — prefer changing only the affected section, or explicitly diff the untouched parts against the prior version before shipping.
• Watch for stale scan/lint findings that don't match reality — a security scanner flags based on static patterns (e.g. an RLS policy) and can miss that a trigger stack already closes the gap behaviorally, or can flag your own throwaway QA scaffolding as a real vulnerability. Verify what the finding actually is before treating it as either "ignore" or "fix now."

Communication pattern with Lovable

• State findings and decisions plainly; when a design question is genuinely ambiguous, ask Lovable to lay out options with tradeoffs rather than silently picking one.
• When you already made this exact policy decision earlier in the conversation, say so and point back to it rather than re-litigating from scratch — Lovable's agent doesn't retain full context across compaction/summarization the way you might expect, and will sometimes present something you already settled as a fresh open question.
• Keep a running todo list across a long multi-part engagement (many small fixes, or a phased QA pass across "clusters"/areas) — it's easy for both sides to lose track of what's actually been verified vs. merely reported.

When to reach for this skill

Any time you're sending a message to a Lovable project's AI agent (via mcp__claude_ai_Lovable__send_message or equivalent) about something more consequential than pure cosmetic copy — bug fixes, schema changes, security findings, new features, anything touching RLS/auth/payments/tenant isolation.