// Auto-generated from src/ai-service/skills/system/third-party-migration/lovable.md
// Do not edit directly - edit the .md file instead
export const content = `# Lovable-specific mapping

This is a per-platform reference loaded from \`SKILL.md\`. The framework — target layout, universal mapping, non-negotiables, workflow, code-emission rules — lives there. This file documents only what's specific to a Lovable source.

> Lovable is not a fixed stack. Unlike Replit, there is no canonical template to assume. A Lovable app may talk to Lovable Cloud / Supabase directly from the client, may have edge functions, may call arbitrary third-party APIs, may have no backend at all, or may mix all of the above. **Discover before you map.** Do not assume Supabase, do not assume an Express server, and do not invent integrations the source does not use.

## Where the source lives

Hallmarks: \`src/integrations/supabase/client.ts\`, \`src/integrations/supabase/types.ts\`, \`supabase/config.toml\`, \`supabase/functions/<name>/index.ts\`, \`supabase/migrations/\`, a \`lovable-tagger\` entry in \`vite.config.ts\`, or a Lovable-flavored README.

If the user gave a path, use it. Otherwise look for the hallmarks above in the working tree. If ambiguous, ask.

## Typical shape (hints, not rules)

Use these as starting points; re-verify against the actual source tree on every migration.

- **Frontend**: React 18 + Vite + TypeScript + Tailwind + shadcn/ui. Routing via \`react-router-dom\` (v6 or v7) or sometimes \`wouter\`. Data fetching via \`@tanstack/react-query\`. Forms via \`react-hook-form\` + \`zod\`.
- **Backend (when present)** — pick whichever the source actually uses:
  - **Lovable Cloud / Supabase** is the default. Surfaces in the source as \`src/integrations/supabase/client.ts\`, \`src/integrations/supabase/types.ts\`, a top-level \`supabase/\` dir with \`migrations/\` and/or \`functions/<name>/index.ts\` (Deno edge functions), and direct \`supabase.from("table").select(...)\` calls from React components.
  - **Edge functions** (Deno-style): \`supabase/functions/<name>/index.ts\`. Each is its own HTTP endpoint, may use \`Deno.serve\`, often reads \`Deno.env.get(...)\`.
  - **Third-party APIs** called from the client (Stripe, OpenAI, Resend, etc.) — frequently with secrets that should never have been on the client.
  - **No backend at all** — pure static app, possibly with localStorage state. The framework's "Don't fabricate a backend" rule applies; the migrated app stays frontend-only.
- **Auth**: \`supabase.auth\` from the client (\`signInWithPassword\`, \`onAuthStateChange\`, \`getSession\`). Sometimes wrapped in an \`AuthContext\`.
- **Storage**: \`supabase.storage.from(bucket).upload(...)\` or third-party upload services.
- **Realtime**: \`supabase.channel(...).on("postgres_changes", ...)\` subscriptions. **Superblocks has no realtime equivalent in this template — flag and degrade to polling or one-shot fetches; do not silently drop.**

## Discovery checklist

This is the most important step for a Lovable migration — get it wrong and the rest is rework. In addition to the framework's discovery requirements, build a list of:

- Every distinct backend interaction: Supabase table queries (grouped by table + operation), Supabase RPC calls, edge functions, third-party API calls (each endpoint), storage operations, realtime subscriptions, auth calls.
- Every env var and where it's used (client vs. server, whether it's a secret).
- Every Supabase migration file and the schema it implies.
- Every RLS policy you can find — these become explicit \`WHERE\` clauses post-migration.
- Every leaked secret found on the client side (\`VITE_*\`, hardcoded keys) — these go into the security note at the end.

If the discovery summary doesn't tell you what every API will look like, you haven't discovered enough.

## Core mapping

- **Each client-side Supabase call → one Superblocks API**, then call it via \`useApi\`/\`useApiData\`. Direct database access from the client is not how Superblocks apps work — every read and write flows through \`server/apis/<ApiName>/api.ts\`.
  - \`supabase.from("table").select(...)\` → \`api()\` with a Postgres integration and \`ctx.integrations.db.query(...)\`. Translate the PostgREST filter chain (\`.eq\`, \`.in\`, \`.order\`, \`.range\`, \`.limit\`) into parameterized SQL — never string-interpolate user input.
  - \`supabase.from("table").insert/update/upsert/delete(...)\` → \`.execute(...)\` with parameterized SQL.
  - \`supabase.rpc("<fn>", { ... })\` → \`SELECT * FROM <fn>(...)\` via \`.query\` if it returns rows, else \`.execute\`.
  - **RLS / row-level-security policies** in Lovable do not transfer automatically. The Superblocks API runs as the integration's service user, not the end user. You must enforce per-user filtering in SQL using \`ctx.user.userId\` (or another claim) explicitly. Audit every ported query — if the original relied on \`auth.uid()\` in an RLS policy, the ported SQL needs an equivalent \`WHERE user_id = $N\` clause. Missing filters are a security bug. Write a one-line comment above the clause noting which RLS policy it replaces, since the _why_ is non-obvious to a future reader.
  - **Schema**: Postgres tables exist on the integration the user binds. Do not run Lovable's \`supabase/migrations/*.sql\` against the target DB. Read them to understand schema and surface a summary; if the integration's DB is empty or schema-mismatched, stop and ask the user how they want to proceed (apply migrations manually, point to an existing DB, or defer).
- **Each \`supabase/functions/<name>/index.ts\` edge function → one Superblocks API** at \`server/apis/<NameInPascalCase>/api.ts\`. Translate \`Deno.serve\`'s request handler the same way as any other handler: body/query/params → unified \`input\` schema, response → \`return { ... }\` from \`run\`. \`Deno.env.get(...)\` → \`ctx.env\`. Edge-function-specific helpers (CORS headers, JWT verification middleware) → drop; the platform handles them.
- **Each third-party API call → integration**. \`fetch("https://api.stripe.com/...")\` becomes a declared integration plus \`apiRequest(...)\`. Secrets from \`import.meta.env.VITE_*\`, hardcoded keys, or \`Deno.env.get\` move into the integration definition. A \`VITE_OPENAI_API_KEY\` on the client side is also a security finding worth surfacing in the migration summary.
- **\`supabase.auth\` → \`ctx.user\`**. Drop \`AuthContext\` providers, sign-in pages, password-reset flows, and magic-link handlers — they have no role in a Superblocks app.
- **\`supabase.storage\` → integrations**. If the source uses Supabase storage, ask the user which target storage integration to use (S3, GCS, etc.) — there is no Lovable-flavored "storage" integration. Surface the buckets used in the discovery summary.
- **\`supabase.channel(...)\` realtime subscriptions** → not supported in this template. Flag as a \`failed\` checklist item with \`failureReason: "realtime subscription on <table> has no Superblocks equivalent"\`, and ask the user before silently rewriting to polling.

## Ask-before-guessing — Lovable specifics

- "The source uses Supabase for both database and auth — bind to an existing Postgres integration, or do you want to point at a different DB? Auth is platform-managed in Superblocks regardless."
- "I see direct calls to \`<third-party API>\` from the client with secrets in \`VITE_*\` env vars. I'll move these server-side via an integration — confirm which integration to bind, or whether to create a new one."
- "The source has Postgres migrations under \`supabase/migrations/\`. I will not run them against your integration's database. How do you want the schema to land?"
- "I see realtime subscriptions on \`<table>\`. Superblocks has no realtime in this template — degrade to polling, drop the feature, or stop and let you decide?"
- "RLS policy \`<policy>\` filtered by \`auth.uid()\`. I'll replace it with \`WHERE user_id = $N\` keyed off \`ctx.user.userId\`. Is that the right user-claim mapping?"

## Page port — what changes vs. what doesn't

For each Lovable page, only these change:

- **Data hooks**: direct Supabase calls + \`@tanstack/react-query\` → \`useApi\` / \`useApiData\`.
- **Auth touchpoints**: \`supabase.auth\` / custom \`AuthContext\` → platform-managed (drop the provider; consume \`ctx.user\` server-side).
- **Router primitives**: if the source uses \`wouter\` or v6 patterns, adapt to \`react-router\` v7. The router is statically parsed by the editor — bind page components only via static imports or \`lazy(() => import("..."))\` (see "Router shape" in the framework SKILL). Lovable sources commonly emit a long \`<Routes>\` block with \`<Route element={<Page />} />\` JSX; rewrite this as a \`createBrowserRouter([...])\` array using \`Component:\` (or inline \`lazy:\`), keeping the \`const Page = lazy(() => import("./pages/Page/index.tsx"))\` declarations intact.

Everything else — JSX structure, Tailwind classes, shadcn variants, custom CSS, theme tokens, fonts, layout containers — transfers unchanged. If the diff goes beyond data + auth + routing, you are over-editing.

## Done — Lovable specifics

In the final report, additionally surface:

- Any unsupported features that became \`failed\` items (realtime subscriptions, Supabase storage without a target integration, etc.).
`;
//# sourceMappingURL=lovable.generated.js.map