---
name: techtide-lovable-production-handoff
description: Convert a Lovable prototype into a repo-owned production candidate by inventorying, replacing mocks, and adding tests and deployment gates. Use when a prototype needs to leave Lovable for a real repo, CI, and production. Not for starting new Replit projects (use techtide-replit-fullstack-bootstrap), hardening v0 UI prompts (use techtide-v0-ui-prompt-hardener), or packaging skills for Lovable (use lovable-native-packaging-bridge).
license: MIT
metadata:
  author: TechTide AI (Alex Cinovoj)
  provenance: original
  category: Delivery & Handoff
---

# Lovable Production Handoff

A prototype earns production status by surviving extraction, not by looking finished in the preview. Inventory everything, mark every mock, and gate promotion on documented operational posture.

## Workflow

1. **Inventory.** List routes, components, data calls, auth behavior, environment variables, and dependencies. This list is the handoff contract, anything not on it does not exist.
2. **Mark before replacing.** Flag every mock, localStorage fallback, and placeholder integration in the code before changing any of them. Replacing unmarked mocks is how one survives to production.
3. **Move to a real repo.** Package manager, lint, test, build, and deployment scripts. The app must build and run outside Lovable from a clean clone.
4. **Test the critical paths.** Smoke tests around user-critical flows, plus a visual check at the first viewport (375px).
5. **Gate promotion.** Block production until secrets handling, auth, observability, and rollback posture are documented. Read references/adapter-map.md when the handoff also needs companion outputs for Cursor, Kiro, v0, or Replit.

## Output contract

Return a concise brief with:

- Handoff inventory.
- Mock replacement plan (each mock: what replaces it, and when).
- Test plan.
- Production gate report.
- Verification performed and still required.
- Security and privacy notes.

## Guardrails

- Extract reusable methods, never private local content.
- Never request or expose credentials, tokens, DSNs, service-role keys, customer data, or business exports. Record variable names only, values live in the secret store.
- Placeholders for people, accounts, projects, URLs, and datasets unless the user supplies public-safe values.
- Explicit human approval before production mutation, external messaging, public deployment, billing changes, or destructive filesystem actions.

## Good vs bad

Good mock replacement plan entry: "`useOrders` returns fixture JSON (src/hooks/useOrders.ts:12). Replace with server fetch against `/api/orders`, auth required, before beta. Until then the route shows a 'demo data' banner."

Bad: "Swap out the fake data before launch." No location, no replacement, no deadline, no interim safeguard. That mock ships.

## Verification

Do this: clone the extracted repo fresh, run install, lint, test, and build, then start the app and exercise each smoke-tested flow. Expect all commands to exit zero and every flow to work without Lovable-only assumptions (no missing env, no localStorage-seeded state). If anything fails, the handoff is incomplete: fix the repo, not the demo.

## Completion checklist

- [ ] Inventory covers routes, components, data calls, auth, env vars, dependencies
- [ ] Every mock and fallback marked before replacement started
- [ ] Clean-clone build, lint, and tests pass
- [ ] Smoke tests cover the user-critical flows
- [ ] Production gate report documents secrets, auth, observability, rollback
- [ ] Human approval obtained for any production-affecting action

Any box unchecked: not done. Fix or say so.

## Footguns

- Trusting the Lovable preview as proof: the preview injects environment and state a clean repo does not have. Only the fresh-clone run counts.
- Replacing mocks by search-and-delete: fallback branches (`|| demoData`) survive greps for the mock name. Mark first, then replace against the marked list.
- Copying env values into the repo "temporarily": the temporary commit is permanent history. Names in code, values in the secret store, from the first commit.
- Promoting with observability "planned": an app you cannot see failing is not production-ready, it is production-invisible.