replica-architect

replica-architect

replica/recon.md と replica/features.csv を読み込みます。replica/architecture.md に書き出します（テンプレート：このフォルダー内の architecture.md）。

調査マップがない場合は、作業を中止して、まず /replica-recon を実行してください。アプリの動作を記憶だけでクローンを計画すると、機能の半分を見落とします。

Step 1: スタック

ユーザーがすでにスタックを使っている場合は、それを採用します。そうでなければ、ユーザー数がゼロの段階ではどの部分も管理しやすく、ドキュメントが整っていて、低コストであるため、以下をデフォルトにします。

レイヤー	デフォルト	代替候補
Web アプリ	Next.js (App Router) + TypeScript	Remix, SvelteKit, Rails
スタイリング	Tailwind、replica-design のトークン	CSS modules
モバイル	Expo (React Native)	SwiftUI, Kotlin
データベース	Supabase または Neon 上の Postgres	PlanetScale, SQLite (Turso)
ORM	Drizzle または Prisma	raw SQL
認証	Supabase Auth または Auth.js	Clerk
決済	Stripe Checkout + Billing	Lemon Squeezy, Paddle
メール	Resend または Postmark	SES
ジョブ	Vercel Cron, Inngest または Trigger.dev	Fly 上のワーカー
ファイル	Supabase Storage または Cloudflare R2	S3
ホスティング	Vercel	Netlify, Fly, Render

それぞれの選択について、理由を一行で記述します。データベースは一つにします。マイクロサービスは使いません。クローンに必要なのは、元のアプリのアーキテクチャではなく、元のアプリの機能です。

Step 2: スキーマ

推定したデータモデルを SQL にします。すべてのテーブルに対して、以下を適用します。

• id uuid primary key default gen_random_uuid()、created_at、updated_at
• ユーザーが所有するすべてのものに、所有者のカラム（user_id または org_id）を追加
• 外部キーには、デフォルト任せにせず、on delete のルールを決定
• すべての外部キーと、フィルタリングまたはソートに使うすべてのカラムにインデックスを設定
• ステータスフィールドには enum または check 制約を設定
• 時刻は常に timestamptz とし、UTC で保存
• 金額は整数のセント単位と通貨カラムで保存
• アクセスルール：Supabase では Postgres の行レベルセキュリティを使うか、データレイヤーのクエリごとに認可チェックを行います。どちらを使うか明記してください。

予約アプリの例：

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

次に、調査で見つかった厳しい制約を記述します。二人のゲストが同じ時間枠を予約する問題は、UI の問題ではなく、データベースの問題です（排他制約またはユニークインデックスで対処します）。

Step 3: API

調査マップのフローごとにテーブルを一つ作成します。各ルートまたはサーバーアクションについて、以下を記述します。

method path | what it does | who can call it | input | output | flow

さらに、受信・送信する Webhook（Stripe、カレンダープロバイダー）と、バックグラウンドジョブ（リマインダー、同期、クリーンアップ）およびそのスケジュールも記述します。

ユーザー自身のキーで利用できる、公式の公開 API のみを使います。ブラウザーで確認できる場合でも、元のアプリの非公開エンドポイントは決して使わないでください。

Step 4: 問題になりやすい部分

該当する項目について、それぞれ一行で記述します。タイムゾーンと夏時間、冪等性（Webhook は二度届くことがあります）、競合状態、レート制限、ファイルサイズ制限、検索、リアルタイム、オフライン、メールの到達性、マルチテナント、GDPR に基づく削除。

Step 5: 構築の順序

1. 垂直スライス。 コアのループを端から端まで、見た目は気にせず構築します。サインアップして、ひとつの操作を行い、結果を確認します。これでスタックを検証します。
2. features.csv の必須機能を、エリアごとに実装します。
3. 実装すべき機能、次に、実装できればよい機能を実装します。
4. 実行後に replica-entrepreneur が見つけた修正を行います。

各マイルストーンには、画面（S-ID）、テーブル、ルートを記載します。

出力

replica/architecture.md、replica/schema.sql 内の SQL、または最初のマイグレーションとしての SQL、および以下の概要を作成します。スタックを一行で、テーブル数、ルート数、最もリスクの高い部分を三つ、次のステップ：/replica-design。