replica-architect
讀取 replica/recon.md 與 replica/features.csv，並寫出 replica/architecture.md（範本：此資料夾內的 architecture.md）。
如果沒有探查地圖，請先停止並執行 /replica-recon。憑記憶規劃一個應用程式的克隆往往會遺漏一半的功能。
步驟 1：技術棧
如果使用者已有技術棧，就使用他們熟悉的方案。否則使用以下預設值，因為每個元件都是受管、文件完善且在零使用者時成本低廉：
| 層 | 預設 | 可替換為 |
|---|---|---|
| Web 應用 | Next.js (App Router) + TypeScript | Remix、SvelteKit、Rails |
| 樣式 | Tailwind，從 replica-design 取得 tokens | CSS modules |
| 行動端 | Expo (React Native) | SwiftUI、Kotlin |
| 資料庫 | Postgres on Supabase 或 Neon | PlanetScale、SQLite (Turso) |
| ORM | Drizzle 或 Prisma | 原生 SQL |
| 認證 | Supabase Auth 或 Auth.js | Clerk |
| 金流 | Stripe Checkout + Billing | Lemon Squeezy、Paddle |
| 郵件 | Resend 或 Postmark | SES |
| 工作排程 | Vercel Cron、Inngest 或 Trigger.dev | Fly 上的 worker |
| 檔案儲存 | Supabase Storage 或 Cloudflare R2 | S3 |
| 託管 | Vercel | Netlify、Fly、Render |
每個選擇用一句話說明原因。只使用一個資料庫。不採用微服務。克隆不需要複製原始應用的架構，只需要實現原始應用的功能。
步驟 2：Schema
將推導出的資料模型轉換為 SQL。每個資料表需包含：
id uuid primary key default gen_random_uuid()、created_at、updated_at- 一個 owner 欄位（使用者擁有的東西用
user_id，組織擁有的用org_id） - 外鍵需指定
on delete規則，不得使用預設值 - 對每個外鍵以及每個用於篩選或排序的欄位建立索引
- 狀態欄位使用 enum 或 check constraints
- 時間一律使用
timestamptz，並以 UTC 儲存 - 金額以整數分加上貨幣欄位
- 存取規則：Supabase 使用 Postgres Row Level Security，或在資料層中每個查詢加上一次授權檢查。請明確寫出採用哪種方式。
範例：預約應用
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 問題。
步驟 3：API
對應探查地圖中的每個流程建立一個資料表。每個路由或伺服器動作（Server Action）記錄：
method path | 功能 | 誰能呼叫 | 輸入 | 輸出 | 流程
此外需包含 Webhook 進站（Stripe、日曆供應商）與出站，以及背景工作（提醒、同步、清理）及其排程。
只使用官方、公開的 API，且需使用者自備金鑰。即使原始應用程式的私有端點在瀏覽器中可見，也絕不使用。
步驟 4：容易踩雷的部分
針對以下每個適用項目，寫一句說明：時區與日光節約時間、冪等性（Webhook 可能會送達兩次）、競態條件、速率限制、檔案大小限制、搜尋、即時功能、離線支援、郵件送達率、多租戶架構、GDPR 刪除要求。
步驟 5：建置順序
- 垂直切面。 先實現核心循環的端到端功能，外表醜陋也可以：註冊、執行主要操作、看到結果。這能驗證技術棧的可行性。
- 必要功能 根據
features.csv按領域實作。 - 次要功能 再來是「應該有」的功能。
- 修復 等 replica-entrepreneur 執行後，根據其發現的問題進行修正。
每個里程碑需列出其畫面（S-ID）、資料表與路由。
輸出
replica/architecture.md、replica/schema.sql 或作為第一個遷移（migration）的 SQL，以及一個摘要：一行說明技術棧、資料表數量、路由數量、三個風險最高的部分，以及下一步：/replica-design。