# Sample Lovable Cloud Migration Risk Report

Fictional project: `Acme Portal Cutover`

This sample shows the report shape for one redacted Lovable Cloud to owned Supabase migration packet. It is not a report about a real buyer, company, repository, database, or private app.

## Scope

Reviewed one redacted packet covering:

- Lovable Cloud to owned Supabase cutover notes
- generated migration excerpts
- public table and policy summaries
- Storage bucket behavior notes
- frontend environment target assumptions
- launch smoke-test results and missing tests

No dashboard access, source-code access, database connection, service-role key, OAuth material, private customer records, private screenshots, payment data, or live tool calls were reviewed.

## Executive Summary

The migration packet is not ready for a public launch cutover. The highest risk is that the new owned Supabase project may pass a basic login test while still missing launch evidence for Storage overwrite behavior, wrong-tenant membership reads, explicit Data API grants, and clean local replay from migrations.

Recommended launch decision: **BLOCK public cutover until the role-matrix and Storage upsert tests pass against the owned Supabase target.**

## Findings

### High: `frontend_target_switch_unverified`

Evidence: the packet says the frontend target changed from Lovable Cloud to an owned Supabase project, but does not include deployed environment evidence or a post-switch smoke test.

Why it matters: a migration can appear successful in the editor while the deployed frontend still points at the old backend, a staging backend, or mixed environment values.

Fix direction:

- Record the deployed frontend target using redacted project labels only.
- Run one no-session, one owner-session, and one wrong-user request against the deployed app after the switch.
- Keep rollback target and DNS/deploy revert steps in `migration.md`.

### High: `storage_upsert_policy_gap`

Evidence: avatar and document buckets are mentioned, but the packet only shows upload success. It does not show SELECT plus UPDATE object-policy evidence for overwrite or `upsert: true`.

Why it matters: Supabase Storage object policies are separate from table RLS. Upload can pass while overwrite, list, download, delete, or wrong-path behavior fails or overexposes object paths.

Fix direction:

- Add a role-matrix for upload, overwrite/upsert, list, download, delete, and wrong-tenant path.
- Confirm object path includes the intended user, tenant, or organization boundary.
- Keep raw file names and private file contents out of the review packet.

### High: `data_api_grants_replay_missing`

Evidence: generated public tables are listed, but the migration notes do not show narrow table grants beside the RLS policies or a clean `supabase db reset` replay.

Why it matters: dashboard defaults or manual grants can make the current project work while a clean rebuild fails with `42501`, especially around the 2026 explicit-grants Data API rollout.

Fix direction:

```sql
-- Example shape only. Review exact operations before launch.
grant select, insert, update on table public.profiles to authenticated;
grant select on table public.memberships to authenticated;
```

Regression check: rebuild a disposable local or staging project from migrations, then run owner and wrong-owner browser Data API calls.

### Medium: `auth_profile_first_login_gap`

Evidence: auth users are marked migrated, but first-login profile behavior is not proven after the cutover.

Why it matters: a user can authenticate successfully while profile inserts, membership joins, trigger side effects, OAuth callback URLs, or foreign-key assumptions fail on first real use.

Fix direction:

- Test first login for one non-sensitive test account.
- Confirm the expected profile and membership side effects exist.
- Record only redacted flow names and pass/fail evidence.

### Medium: `lovable_mcp_handoff_boundary_unclear`

Evidence: the packet says Lovable MCP and Supabase MCP were used, but does not describe which tool changed schema, policies, environment variables, or branch state.

Why it matters: generated migrations and tool-assisted dashboard changes can drift. The launch owner needs to know which state is reproducible from migrations and which state exists only in a tool session.

Fix direction:

- List tool-assisted changes by category: schema, RLS, Storage policy, Edge Function, environment target, or seed data.
- Re-run the generated migration review after consolidating dashboard-only edits.
- Keep changed tools or destructive operations in ask/deny until review evidence exists.

## Minimum Role Matrix

| Scenario | Expected result |
| --- | --- |
| No session | No private profiles, memberships, documents, or bucket paths |
| Authenticated owner | Own profile, memberships, and intended Storage objects only |
| Different authenticated user | Denied for other user or tenant rows and Storage paths |
| Anonymous session, if enabled | Only explicitly onboarding-safe behavior |
| Clean `supabase db reset` replay | Same grants, policies, RPCs, views, and Storage assumptions are recreated |
| Deployed frontend after target switch | Calls only the owned Supabase target |

## Suggested `migration.md` Launch Gate

```md
# migration.md

Status: BLOCK

Before cutover:
- freeze writes or define rollback window
- rebuild disposable Supabase target from migrations
- run owner/wrong-owner/wrong-tenant role matrix
- run Storage upload/overwrite/list/download/delete/wrong-path tests
- verify deployed frontend target

Fallback:
- restore previous frontend target
- pause new signups
- keep owner-only write test evidence
```

## Buyer Action List

1. Add narrow grants beside the generated table migrations.
2. Run a clean replay from migrations, not just dashboard state.
3. Prove Storage overwrite/upsert and wrong-path behavior.
4. Prove first-login profile and membership side effects after auth cutover.
5. Re-run the free Lovable preflight and keep the new packet digest with the launch notes.

## Safety Boundary

This report is a planning aid, not legal advice, compliance certification, penetration testing, incident response, or a guarantee that a migration is safe. It should receive only redacted packet text and non-sensitive pass/fail notes.