chore: formalize dotnet backend repository

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

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