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 的设计令牌 | 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：数据库模式
将推理出的数据模型转化为 SQL。对于每个表：
id uuid primary key default gen_random_uuid(),created_at,updated_at- 用户拥有的每个对象都有一个所有者字段（
user_id或org_id） - 外键要明确指定
on delete规则，不采用默认值 - 为每个外键以及每个你过滤或排序的列创建索引
- 状态字段使用枚举或检查约束
- 时间一律使用
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 的问题。
步骤 3：API
根据侦查图谱中的用户流程，每个流程对应一个表。对于每个路由或服务器操作：
方法 路径 | 功能 | 调用者 | 输入 | 输出 | 流程
另外，需要包含 Webhook 入站（Stripe、日历提供商）和出站，以及后台任务（提醒、同步、清理）及其调度计划。
仅使用官方的、公开的 API，搭配用户自己的密钥。绝不能使用原始应用的私有端点，即使它们在浏览器中可见。
步骤 4：容易出问题的部分
针对每个适用项写一行说明：时区和夏令时、幂等性（Webhook 可能收到两次）、竞态条件、速率限制、文件大小限制、搜索、实时功能、离线、邮件送达率、多租户、GDPR 删除。
步骤 5：构建顺序
- 垂直切片。 端到端的核心闭环，允许粗糙：注册、完成一项核心操作、查看结果。用于验证技术栈。
- 必须实现的功能（来自
features.csv），按领域划分。 - 应该实现的功能，然后是可以考虑的功能。
- 修复事项，由 replica-entrepreneur 在运行后发现的。
每个里程碑列出涉及的屏幕（S-ID）、表和路由。
输出
replica/architecture.md、replica/schema.sql 中的 SQL（或作为首次迁移），以及摘要：一行技术栈、表数量、路由数量、三个风险最高的部分，以及下一步：/replica-design。