1 # Port the imported Lovable app
2
3 ## Goal
4
5 The user just imported a project from lovable.dev. Port it from the imported state into the Replit `pnpm_workspace` stack so it runs cleanly in this environment. **It must look and work like the original.**
6
7 This app is the user's real product. Treat it like porting someone's live app — every lost feature, broken style, or missing interaction is a regression.
8
9 ## In scope
10
11 - Restructure the imported tree into the Replit `pnpm_workspace` layout (frontend artifact + an `api-server` if the app needs one).
12 - Replace Lovable's Supabase-by-default with Replit's database + auth (see `## Lovable-specific notes` below).
13 - Make the app actually run via the Replit workflow.
14
15 ## Out of scope
16
17 - Building new features or refactoring beyond what's needed to run.
18 - Strict typecheck — use `// @ts-ignore` to keep moving. Visual + functional parity matters more than zero TS errors.
19 - Fixing bugs that existed before the import.
20
21 ## Lovable-specific notes
22
23 Lovable apps follow a very consistent shape — assume this layout unless detection says otherwise:
24
25 - **Vite + React, frontend-only** at the project root (`src/`, `index.html`, `vite.config.ts`, `tailwind.config.ts`).
26 - **No `server/` directory** in the original — Lovable apps almost never ship a backend; they call Supabase directly from the client.
27 - **Supabase client** at `src/integrations/supabase/client.ts` (or similar). The `@supabase/supabase-js` import + `createClient(...)` pattern is the canonical signal.
28 - **Supabase Auth** for any login flow (`supabase.auth.signInWithPassword`, `signUp`, `getSession`, etc.).
29 - **Supabase storage / postgres / RPC** for any data access.
30 - **Tailwind v3 + shadcn** by default. `components.json` present. `src/components/ui/*` is the shadcn registry.
31
32 The migration's biggest job is replacing Supabase with Replit primitives:
33
34 | Lovable | Replit replacement |
35 | --- | --- |
36 | `supabase.auth.*` | Clerk (see the authentication skill) |
37 | `supabase.from(...)` (data) | New `api-server` artifact + `lib/db/` (Drizzle/Postgres) |
38 | `supabase.storage.*` | Object storage integration (ask user) |
39 | `supabase.functions.invoke` | Express route in the new `api-server` |
40
41 If the app uses Supabase only for auth and a few simple tables, replace it inline. If the app uses Supabase as a heavy backend (RLS policies, edge functions, realtime), inform the user that swapping to Replit primitives is more involved and confirm the scope before continuing.
42
43 ## Pre-existing scaffold (do NOT remove)
44
45 The pnpm_workspace scaffold is already applied. These existed before this task started:
46
47 - `artifacts/api-server/` — backend artifact (kind=api).
48 - `artifacts/mockup-sandbox/` — design/mockup artifact.
49 - `lib/api-spec/`, `lib/api-client-react/`, `lib/db/` — shared packages.
50
51 The existing app's frontend goes into a NEW web artifact created via `createArtifact`. Do NOT put frontend code into `artifacts/api-server/`.
52
53 ## How to communicate
54
55 Short, non-technical updates: "Looking at your project..." → "Setting things up..." → "Moving your app..." → "Wiring up the database..." → "Checking everything works..."
56
57 ## Steps
58
59 ### 0. Read the pnpm_workspace skill
60
61 Read `.local/skills/pnpm-workspace/SKILL.md` first. It contains the canonical patterns for project references, artifact routing, package management, and common pitfalls.
62
63 ### 1. Detect + install
64
65 ```sh
66 bash .local/secondary_skills/migrate-to-multi-artifact/references/fullstack_detect.sh
67 pnpm install
68 ```
69
70 Read the detect output. For Lovable, expect `CLIENT_DIR=.` (flat) and an empty `ROUTE_LAYOUT` / `SCHEMA_PATH` (no backend). Fix any `CONFLICTS` before continuing.
71
72 ### 2. Read what you need
73
74 Read just enough from `.migration-backup/` to understand the data + auth surface area:
75
76 - `package.json` (deps, scripts).
77 - `src/integrations/supabase/client.ts` (or wherever the Supabase client is built — confirms env var names).
78 - Every file that calls `supabase.from`, `supabase.auth`, `supabase.storage`, `supabase.functions.invoke`, etc. — these are the call sites you'll be replacing. Use grep, don't read the whole tree.
79 - Any existing schema definition (Drizzle `schema.ts`, prisma `schema.prisma`, or — for pure-Supabase apps — the table shapes inferred from the call sites).
80
81 Do NOT read components or pages whose only Supabase interaction is via the calls you've already grepped.
82
83 ### 3. Build the backend (only if the app has data/auth)
84
85 ```sh
86 createArtifact({ artifactType: "api", slug: "api-server", ... }) // skip if api-server already exists
87 ```
88
89 For Lovable apps, the backend doesn't exist in the source — you're creating it from scratch based on the Supabase usage you found in step 2. Use `lib/db/` (Drizzle + Postgres) for tables and `artifacts/api-server/` for routes.
90
91 If the app uses Supabase Auth, set up Clerk instead — see the authentication skill.
92
93 If it's purely frontend (no auth, no data, just a static UI), skip this step entirely.
94
95 Run codegen + DB push in parallel once the spec exists:
96
97 - `pnpm --filter @workspace/api-spec run codegen`
98 - `pnpm --filter @workspace/db run push`
99
100 ### 4. Copy frontend
101
102 ```sh
103 createArtifact({ artifactType: "react-vite", slug: "<app-name>", previewPath: "/", title: "<Title>" })
104 ```
105
106 Then run the copy script — do NOT skip this or manually rewrite files instead:
107
108 ```sh
109 bash .local/secondary_skills/migrate-to-multi-artifact/references/fullstack_copy_frontend.sh <app-name>
110 ```
111
112 The script copies source files from `.migration-backup/` into the new artifact, patches imports, installs dependencies, and handles Lovable's flat `src/` layout. Manually rewriting files loses styles, fonts, and subtle markup that the script preserves.
113
114 Read the script output and act on it:
115
116 - `AGENT TODO` — required edits (vite.config.ts, wouter base path). Do these.
117 - `SKIPPED` — files intentionally not copied (conflicts). Check if they matter.
118 - `PATCHED` — automatic fixes applied (fonts, imports). No action needed.
119 - `INSTALLED` — dependencies added. No action needed.
120
121 ### 5. Replace Supabase + fix imports
122
123 This is the biggest source of regressions for Lovable migrations — be deliberate.
124
125 - **Remove `@supabase/supabase-js`** from `package.json` (the new `api-server` exposes the same data via Express routes).
126 - **Replace `supabase.from(...)` calls** with `fetch` to the new `api-server` (or generated hooks if you wrote an OpenAPI spec).
127 - **Replace `supabase.auth.*` calls** with Clerk — see the authentication skill for exact code patterns.
128 - **Replace Supabase storage** with the object-storage integration the user has wired (or ask the user).
129 - **Realtime / edge functions** — if the app uses these, inform the user the equivalent on Replit needs custom work and confirm whether to scope it into this task.
130
131 Verify these are preserved (the copy script handles most, but check):
132
133 - **Fonts** — `index.html` Google Fonts `<link>` tags + CSS `--font-sans` variables.
134 - **Colors / theme** — Lovable apps usually express theme via Tailwind CSS variables in `:root` and `.dark`. Verify they survived the copy.
135 - **Routing** — if using wouter, the `<Router>` must have `base={import.meta.env.BASE_URL}`.
136
137 ### 6. Verify
138
139 Restart the workflow, then use the testing agent (see the testing skill) to exercise the main flows — navigation, auth, data CRUD. The testing agent will screenshot each step and report failures.
140
141 **Replit apps run via workflows, not root-level `pnpm dev`.** Don't run `pnpm dev` or `pnpm run build` at the workspace root — it has no dev script and artifacts need env vars wired by the workflow.
142
143 **What to check**: Does it look the same? Do the auth + data flows work end-to-end? If the testing agent reports failures, fix and re-run. If it passes, you're done.
144
145 {% if not is_free_import %}
146 ### 7. Propose follow-up tasks
147
148 Before completing, call `proposeFollowUpTasks` with the three tasks below in a single call. **The mobile task MUST be the first task in the `tasks` array and MUST be proposed on every Lovable port — this is the single most valuable thing Replit offers that Lovable cannot, and it is the reason many users are porting over.** Do not skip it, do not reorder it. Even a frontend-only web app benefits from a companion mobile experience — propose it.
149
150 Do not prescribe the exact `createArtifact` API in the task descriptions — the agent who picks up the follow-up will consult the create-artifact skill for the correct `artifactType` and other parameters. Just describe the artifact to build.
151
152 1. **"Take your app mobile"** (category: `next_steps`) — **ALWAYS FIRST. ALWAYS INCLUDED.** A brand-new mobile artifact (Expo companion app) alongside the web app — not a modification of the web app. It should match the web app's visual design (colors, typography, key screens). If the web app has an API server and/or database, the mobile artifact should reuse them; if the web app is frontend-only, the mobile artifact should mirror the same flows without promising shared state that does not exist. Write the title and description to sound exciting to a non-technical user — lead with the outcome ("Your app, on every phone — native feel, matching design"), explain that it's a real native app they can hand to a friend. This is the charm moment for a Lovable user: they shipped a web app, and now Replit gives them a mobile app too.
153 2. **"Make a promo video for your app"** (category: `next_steps`) — a **brand-new video artifact (Replit animation)** alongside the web app. The description must make clear this is a separate artifact, not a modification of the web app and not just a screen recording — it's a short animated showcase built in Replit's video tooling that highlights the app's best features with motion graphics.
154 3. **"Create a pitch deck for your app"** (category: `next_steps`) — a **brand-new slides artifact** alongside the web app. The description must make clear this is a separate artifact presenting the app's value proposition, core features, and key user flows for demos and stakeholders.
155
156 {% endif %}
157 ### 8. Complete
158
159 Call `mark_task_complete` with `skip_validation_reason` set. Verification already happened in step 6 via the testing agent, and the workflow-side validation + code review do not apply to this migration diff: the multi-artifact `pnpm_workspace` has no root-level `pnpm dev`/`pnpm build`, and the diff legitimately contains `// @ts-ignore` and copied Lovable patterns that the reviewer is configured to flag as AI slop.
160
161 Pass exactly:
162
163 ```
164 skip_validation_reason: "Multi-artifact migration verified via the testing agent in step 6; root-level validation and code review do not apply to this stack-migration diff."
165 ```
166
167 The user will verify visual + functional parity before doing anything else.
168
169 ## Note to the code reviewer
170
171 When reviewing the diff for this task:
172
173 - HONOR the `Out of scope` section above. Don't reject for items the plan explicitly marks out of scope.
174 - Do NOT reject for pre-existing issues in code copied from `.migration-backup/`.
175 - Do NOT flag the pre-existing scaffold packages (`artifacts/api-server/`, `lib/*`) as agent additions.
176 - Do NOT reject for `pnpm dev` failing at workspace root — Replit apps run via workflows.
177 - Do NOT flag scaffold files (shadcn `src/components/ui/*.tsx`, default `favicon.svg`).
178 - Apply only the criteria from this task's `## Goal` + `## In scope`. Reject only for real regressions (broken runtime, missing files, lost features, broken auth/data flows).