user-feedback: document Lovable Cloud managed migration path

Start in skills/supabase/SKILL.md, especially the “Supabase MCP Server” and “Making and Committing Schema Changes” sections. Add provider-routing guidance for Lovable Cloud, distinguish raw query_database execution from provider-native migrations, and document the stop condition when migration history cannot be recorded. Done means the reviewed migration path preserves provider authority and forbids direct edits to supabase_migrations.schema_migrations.

What happened

Task: Apply reviewed PostgreSQL migration files to a Supabase-compatible database owned and managed by a Lovable Cloud project, without Lovable Chat, external Supabase accounts, connectors, CLI login, credentials, dashboards, or projects.

Skill said: The Supabase skill routes schema changes to Supabase MCP execute_sql / apply_migration or Supabase CLI and does not explain how to preserve a third-party provider's database authority and migration history.

Observed: Lovable MCP query_database officially supports SQL reads, writes, and DDL, but an empirical reversible privilege-change probe executed successfully without adding any row to supabase_migrations.schema_migrations. The privileges were restored and the ledger remained unchanged. Therefore raw query_database is not a safe substitute for a provider migration operation when auditable provider history is required.

The only separately exposed apply_migration tool belonged to the external Supabase connector. Using it would violate the project's explicit provider boundary and may target a different project identity.

Expected: The skill should first identify the database owner/provider. For a Lovable-owned database it must not request or use external Supabase setup. It should distinguish raw SQL execution from a provider migration operation and stop if the connected provider does not expose the latter. It must not recommend fabricating or manually inserting migration-ledger rows.

Source

File: skills/supabase/SKILL.md

Section: Supabase MCP Server and Making and Committing Schema Changes

Fix suggestion

Add a “Provider-managed Supabase-compatible databases” routing section:

• Identify the authoritative provider before selecting a tool.
• If Lovable Cloud owns the database, use only the connected Lovable project; do not request Supabase credentials, OAuth, dashboard access, CLI login, or a separate project.
• Document that Lovable MCP query_database can execute DDL but does not necessarily create provider migration-history entries.
• Require a provider-native migration operation for source-controlled production migrations when ledger provenance is an acceptance gate.
• Apply exact reviewed files individually in dependency order, then verify schema and provider history after every operation.
• Never edit supabase_migrations.schema_migrations directly.
• If only raw SQL is exposed, stop and report the missing provider capability rather than creating untraceable drift.

This preserves normal Supabase guidance while covering managed wrappers whose operational authority is not the Supabase MCP server itself.