为了确保 AI 在重构过程中不跑偏、不造黑盒、不写废话，我们需要将你的“宪法”和“军规”进行工业级的结构化整理。
你可以直接在项目根目录创建这两个文件：
第一份文件：项目军规（物理锁死 AI 行为）
文件名：.cursorrules (或 .windsurfrules / .ai-rules)
markdown

🛡️ PHP-to-Node 重构工程军规

1. 核心工作流 (Standard Operating Procedure)

• 文档先行：严禁直接改代码。任何逻辑变动必须先更新 docs/specs/*.md。
• 契约驱动：后端 API 必须严格对齐 docs/specs/ 中的 TypeScript 定义。
• 红绿循环 (TDD)：编写业务逻辑前，必须先生成对应的 Vitest/Jest 测试脚本。运行失败后，再编写实现代码，直至全绿。

2. 后端技术栈约束 (NestJS 规范)

• 架构模式：必须遵循 NestJS 官方模块化标准（Module -> Controller -> Service）。
• 参数校验：利用 class-validator 在 DTO 层实现 auth.md 中的 AC 判定规则。
• 数据访问：统一使用 Prisma。严禁在 Service 层直接拼接原生 SQL。
• 异常处理：统一使用 Exception Filters 捕获报错，禁止在业务逻辑中随处抛出未经定义的 Error。

3. 前端技术栈约束 (Vue3 规范)

• 开发范式：强制使用 <script setup> 和 TypeScript。
• 逻辑抽离：业务逻辑必须抽离到 composables/ (Composition API)，组件只负责渲染。

4. 交互限制 (Interaction)

• 禁止脑补：如果 PHP 源码逻辑模糊，必须询问用户，严禁私自猜测业务规则。
• 自审计：完成任务后，对比代码与 docs/specs/，并在回复中列出：
  • API 字段是否完全对齐？
  • AC 判定规则是否全部覆盖测试？
    请谨慎使用此类代码。

第二份文件：二合一技术方案（逻辑与契约锚点）
文件名：docs/specs/auth.md
markdown

🔐 认证模块技术方案 (Auth Spec)

1. 业务逻辑流程 (Logical Flow)