docs: simplify migration documentation

docs/adr/0001-authoritative-dotnet-backend.md

@@ -5,28 +5,28 @@
 
 ## 背景
 
-项目已有一套 NestJS 后端，数据库、认证和存储与 Supabase 的部署及规则耦合较深。新的 ASP.NET Core 后端已经形成完整解决方案、EF Core 模型、迁移链和大量业务 API。前后端尚未进入正式开发，当前仍处于可以直接收敛技术路线的窗口。
+旧 NestJS 后端与 Supabase 数据库、认证、存储和规则耦合较深。新的 ASP.NET Core 后端已经具备 EF Core 模型、迁移链和业务 API。前后端尚未正式开发，仍可直接收敛技术路线。
 
 ## 决策
 
 1. 本仓库是题库 SaaS 唯一继续演进的后端。
-2. 旧 NestJS 仓库冻结为业务行为、接口契约和数据迁移参考；除迁移阻断问题外，不再承接新功能。
-3. EF Core Migration 是普通数据库结构变更的唯一权威历史。生产环境通过 `Tiku.DbMigrator` 显式执行经审查的迁移，API 不在启动时自动同步结构。
-4. 应用只依赖标准 PostgreSQL 能力和 Npgsql，不再以 Supabase 作为运行时依赖或托管目标。
-5. 身份、对象存储、短信、支付和通知通过 Application 层接口隔离供应商，并通过租户级 `TenantExternalProvider` + `TenantSecret` 配置；不建设 Supabase Auth/Storage 兼容层。
-6. Yudao 不作为运行时依赖，只参考其 RBAC、租户套餐、审计和后台产品设计。
-7. 新功能按完整领域闭环迁移和验收，不以 Controller 或 endpoint 数量作为完成标准。
+2. 旧 NestJS 仓库冻结为业务行为、接口契约和数据迁移参考。
+3. EF Core Migration 是普通数据库结构变更的权威历史；生产通过 `Tiku.DbMigrator` 显式执行迁移，API 不自动同步结构。
+4. 应用只依赖标准 PostgreSQL 和 Npgsql，不以 Supabase 作为运行时依赖或托管目标。
+5. 身份、对象存储、短信、支付、通知和 AI 通过 Application 接口隔离供应商，并通过 `TenantExternalProvider` + `TenantSecret` 配置。
+6. Yudao 只参考 RBAC、租户套餐、审计和后台产品设计，不作为运行时依赖。
+7. 新功能按业务闭环迁移和验收，不以 Controller 或 endpoint 数量作为完成标准。
 
-## 迁移边界
+## 边界
 
 - 认证和授权由 ASP.NET Core、JWT、数据库 Session 和应用权限策略负责。
 - 多租户隔离由请求租户上下文、EF 查询/写入防护、数据库约束和真实 PostgreSQL 测试共同负责。
-- 普通表、列、索引、约束由 EF Core Migration 管理；确有必要的 PostgreSQL 专用 SQL 可以包含在 Migration 中并接受审查。
-- 旧 OpenAPI 用于发现能力缺口，不要求新接口逐字兼容。任何主动不兼容都必须在迁移清单中记录决定和替代接口。
+- 普通表、列、索引、外键和普通约束由 EF Core Migration 管理。
+- EF 不能表达的跨表租户不变量使用集中 PostgreSQL guard，由 migration 调用并接受测试。
+- 旧 OpenAPI 用于发现能力缺口，不要求新接口逐字兼容。
 
 ## 结果
 
-- 不再建设长期双后端或双写链路。
-- 不再保留 Supabase 作为认证、存储或数据库运行时备选目标。
+- 不建设长期双后端或双写链路。
+- 不保留 Supabase 作为认证、存储或数据库运行时目标。
 - 更换 PostgreSQL 托管商或外部服务供应商不要求重写业务代码。
-- 后续开发先补真实 PostgreSQL 测试、强制租户边界、生产配置 fail-fast 和敏感配置加密，再扩展业务模块。