lovable-rigorlisted

# 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