replica-architect

Que fait replica-architect ?

Lit replica/recon.md et replica/features.csv. Écrit replica/architecture.md (modèle : architecture.md dans ce dossier).

S'il n'y a pas de carte de reconnaissance, arrêtez-vous et exécutez d'abord /replica-recon. Planifier un clone de mémoire de ce qu'une application fait, c'est le meilleur moyen d'en oublier la moitié.

Étape 1 : la stack

Utilisez ce que l'utilisateur connaît déjà s'il a une stack. Sinon, la valeur par défaut, car chaque partie est gérée, documentée et peu coûteuse à zéro utilisateur :

couche	défaut	remplacer par
application web	Next.js (App Router) + TypeScript	Remix, SvelteKit, Rails
styles	Tailwind, jetons depuis replica-design	CSS modules
mobile	Expo (React Native)	SwiftUI, Kotlin
base de données	Postgres sur Supabase ou Neon	PlanetScale, SQLite (Turso)
ORM	Drizzle ou Prisma	SQL brut
authentification	Supabase Auth ou Auth.js	Clerk
paiements	Stripe Checkout + Billing	Lemon Squeezy, Paddle
email	Resend ou Postmark	SES
tâches	Vercel Cron, Inngest ou Trigger.dev	un worker sur Fly
fichiers	Supabase Storage ou Cloudflare R2	S3
hébergement	Vercel	Netlify, Fly, Render

Écrivez chaque choix avec une ligne de justification. Une seule base de données. Pas de microservices. Le clone n'a pas besoin de l'architecture de l'original, il a besoin des fonctionnalités de l'original.

Étape 2 : le schéma

Transformez le modèle de données inféré en SQL. Pour chaque table :

• id uuid primary key default gen_random_uuid(), created_at, updated_at
• une colonne propriétaire (user_id ou org_id) sur tout ce qu'un utilisateur possède
• des clés étrangères avec une règle on delete décidée, pas par défaut
• des index sur chaque clé étrangère et chaque colonne que vous filtrez ou triez
• des énumérations ou des contraintes de vérification pour les champs de statut
• les heures en timestamptz, toujours, stockées en UTC
• l'argent en centimes entiers plus une colonne de devise
• des règles d'accès : sécurité au niveau des lignes Postgres sur Supabase, ou une vérification d'autorisation par requête dans la couche de données. Écrivez laquelle.

Exemple, pour une application de réservation :

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);

Ensuite, les contraintes strictes trouvées par la reconnaissance. Deux invités réservant le même créneau est un problème de base de données (une contrainte d'exclusion ou un index unique), pas un problème d'interface.

Étape 3 : l'API

Un tableau par flux de la carte de reconnaissance. Pour chaque route ou action serveur :

méthode chemin | ce qu'elle fait | qui peut l'appeler | entrée | sortie | flux

Plus les webhooks entrants (Stripe, fournisseurs de calendrier) et sortants, et les tâches d'arrière-plan (rappels, synchronisation, nettoyage) avec leur planification.

Uniquement les API publiques officielles avec les propres clés de l'utilisateur. Jamais les points de terminaison privés de l'application d'origine, même s'ils sont visibles dans un navigateur.

Étape 4 : les parties qui coincent

Écrivez une ligne pour chacun des points qui s'appliquent : fuseaux horaires et heure d'été, idempotence (les webhooks arrivent deux fois), conditions de concurrence, limites de débit, limites de taille de fichier, recherche, temps réel, hors ligne, délivrabilité des emails, multi-locataire, suppression GDPR.

Étape 5 : ordre de construction

1. Tranche verticale. La boucle principale de bout en bout, moche : inscription, faire la seule chose, voir le résultat. Prouve la stack.
2. Indispensables de features.csv, par domaine.
3. Souhaitables, puis possibles.
4. Les correctifs que replica-entrepreneur trouvera, une fois exécuté.

Chaque jalon liste ses écrans (ID-S), ses tables et ses routes.

Sortie

replica/architecture.md, le SQL dans replica/schema.sql ou en tant que première migration, et un résumé : stack en une ligne, nombre de tables, nombre de routes, les trois parties les plus risquées, et l'étape suivante : /replica-design.