replica-architect - Arquitecto de Clon

replica-architect

Lee replica/recon.md y replica/features.csv. Escribe replica/architecture.md (plantilla: architecture.md en esta carpeta).

Si no hay mapa de reconocimiento, detente y ejecuta primero /replica-recon. Planificar un clon desde la memoria de lo que hace una aplicación es la forma de omitir la mitad.

Paso 1: el stack

Usa lo que el usuario ya conoce si tiene un stack. De lo contrario, el predeterminado, porque cada componente está gestionado, documentado y es económico con cero usuarios:

capa	predeterminado	reemplazar por
web app	Next.js (App Router) + TypeScript	Remix, SvelteKit, Rails
estilos	Tailwind, tokens de replica-design	CSS modules
móvil	Expo (React Native)	SwiftUI, Kotlin
base de datos	Postgres en Supabase o Neon	PlanetScale, SQLite (Turso)
ORM	Drizzle o Prisma	SQL sin procesar
autenticación	Supabase Auth o Auth.js	Clerk
pagos	Stripe Checkout + Billing	Lemon Squeezy, Paddle
correo	Resend o Postmark	SES
tareas	Vercel Cron, Inngest o Trigger.dev	un worker en Fly
archivos	Supabase Storage o Cloudflare R2	S3
alojamiento	Vercel	Netlify, Fly, Render

Escribe cada elección con una línea de por qué. Una base de datos. Sin microservicios. El clon no necesita la arquitectura original, necesita las funcionalidades originales.

Paso 2: el esquema

Convierte el modelo de datos inferido en SQL. Para cada tabla:

• id uuid primary key default gen_random_uuid(), created_at, updated_at
• una columna de propietario (user_id o org_id) en todo lo que un usuario posee
• claves foráneas con una regla on delete decidida, no predeterminada
• índices en cada clave foránea y en cada columna que filtres u ordenes
• enums o restricciones check para campos de estado
• horas como timestamptz, siempre, almacenadas en UTC
• dinero como céntimos enteros más una columna de moneda
• reglas de acceso: seguridad a nivel de fila de Postgres en Supabase, o una comprobación de autorización por consulta en la capa de datos. Escribe cuál.

Ejemplo, para una aplicación de reservas:

create table bookings (
  id uuid primary key default gen_random_uuid(),
  event_type_id uuid not null references event_types(id) on delete cascade,
  host_id uuid not null references users(id) on delete cascade,
  start_at timestamptz not null,
  end_at timestamptz not null,
  guest_name text not null,
  guest_email text not null,
  guest_timezone text not null,
  status text not null default 'confirmed'
    check (status in ('confirmed','cancelled','rescheduled')),
  answers jsonb not null default '{}',
  created_at timestamptz not null default now(),
  constraint no_zero_length check (end_at > start_at)
);
create index on bookings (host_id, start_at);

Luego las restricciones estrictas que encontró el reconocimiento. Que dos invitados reserven el mismo espacio es un problema de base de datos (una restricción de exclusión o un índice único), no un problema de interfaz de usuario.

Paso 3: la API

Una tabla por flujo del mapa de reconocimiento. Para cada ruta o acción de servidor:

método ruta | qué hace | quién puede llamarlo | entrada | salida | flujo

Además, webhooks entrantes (Stripe, proveedores de calendario) y salientes, y trabajos en segundo plano (recordatorios, sincronización, limpieza) con su programación.

Solo API oficiales y públicas con las claves propias del usuario. Nunca los endpoints privados de la aplicación original, incluso si son visibles en un navegador.

Paso 4: los puntos que muerden

Escribe una línea sobre cada uno que aplique: zonas horarias y horario de verano, idempotencia (los webhooks llegan dos veces), condiciones de carrera, límites de tasa, límites de tamaño de archivo, búsqueda, tiempo real, modo offline, capacidad de entrega de correo, multi-tenant, eliminación por RGPD.

Paso 5: orden de construcción

1. Corte vertical. El bucle principal de principio a fin, feo: registrarse, hacer la única cosa, ver el resultado. Prueba el stack.
2. Imprescindibles de features.csv, por área.
3. Deberían tener, luego podrían tener.
4. Las correcciones que encuentre replica-entrepreneur, una vez que se haya ejecutado.

Cada hito enumera sus pantallas (ID-S), tablas y rutas.

Salida

replica/architecture.md, el SQL en replica/schema.sql o como la primera migración, y un resumen: stack en una línea, número de tablas, número de rutas, las tres partes más riesgosas y el siguiente paso: /replica-design.