用途：在部署阶段，以 simple-developer 的迁移模式运行，根据当前会话分支相对 session-base 的净差异，生成让真实 Supabase schema 与会话应用预期一致的 SQL 迁移，不多做改动。
主要能力与流程：
- 计算净变更：在 worktree 中执行 git diff session-base/<SESSION_SHORT_ID>..session/<SESSION_SHORT_ID>，不使用 git merge-base，也不与 main 对比。
- 识别 schema 相关变更：仅保留实体 TypeScript 类型、增删字段的假数据生成器、dataProvider 资源注册等；忽略 CSS、布局、文案与测试。
- 计算增量：将期望 schema 与 supabase/migrations/、supabase/schemas/ 中已部署内容对比，只输出增量；无 schema 影响则写 NO_MIGRATION_NEEDED。
- 编写幂等 SQL：写入 supabase/migrations/<YYYYMMDDHHMMSS>_<SESSION_SHORT_ID>migration<slug>.sql，使用 IF NOT EXISTS / IF EXISTS，列类型匹配 TS 类型，含外键，新表启用 RLS 并配置策略，禁止 USING (true)。
- 视图重建规则：若迁移在 supabase/schemas/03_views.sql 引用的表上新增列，必须用 CREATE OR REPLACE VIEW 重建视图，并把新列放在 SELECT 列表最后一项，位于所有已有列和已有计算别名之后，避免 PostgreSQL 42P16 序号位移错误。不要用 DROP VIEW … CASCADE，除非 CREATE OR REPLACE 确实无法处理（如删列或改名），且需在注释中列出被删依赖并在同一迁移中重建。同时同步更新 supabase/schemas/03_views.sql 为相同顺序。
- 提交与交接：在 <SESSION_SHORT_ID>/simple 上提交 SQL 后停止，SubagentStop 钩子会自动运行 typecheck/prettier/unit/e2e，随后由编排器交给 quality-reviewer 与 merger。
适用场景：Atomic CRM 项目在部署时自动生成 Supabase 迁移。限制：仅用于部署时迁移轮次；需遵循上述分支对比与视图顺序规则；资料未提供更多平台或收费信息。