sdd-workflow 1.1.0

package/templates/skills/sdd-implement/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: sdd-implement
+description: 执行SDD任务分解中的开发任务 - 遵循红-绿-重构流程，测试优先实现
+invocable: true
+---
+
+# SDD Implement - 任务执行器
+
+按顺序执行SDD任务分解中的开发任务，遵循测试优先的红-绿-重构流程。
+
+## 核心定位
+
+> Implement 是 SDD 流程的最终执行阶段，可以包含完整的代码、SQL、文件操作。
+> 实现过程中发现的上游问题，**必须按自循环机制反向纠正**，不允许带病绕过。
+
+## 前置条件
+
+- spec.md 或 spec/README.md ✓
+- testcases.md ✓
+- plan.md 或 plan/README.md ✓
+- tasks.md 或 tasks/README.md ✓
+
+## 执行流程
+
+### 1. 加载任务文档（渐进式）
+
+检测 tasks 文档结构：
+- **模块化结构** (`tasks/README.md` 存在): 先加载 README 获取概览，按需加载单个 Phase 文件
+- **单文件结构** (`tasks.md`): 直接加载完整文件
+
+### 2. 展示任务概览，让用户选择执行哪个 Phase
+
+展示各 Phase 状态（任务数/工时/完成情况），用户选择后只加载对应 Phase 文档。
+
+### 3. 执行模式
+
+- **交互式（默认）**: 逐任务执行，每完成一个等待确认
+- **自动**: 按顺序执行，遇错暂停
+- **指定任务**: 只执行用户指定的任务
+
+### 4. 每个任务的执行步骤（红-绿-重构）
+
+1. **确认测试用例映射** - 如 Task 1.4 → UT-001~015
+2. **🔴 红阶段** - 根据testcases.md写测试，运行确认失败
+3. **🟢 绿阶段** - 写最小实现使测试通过
+4. **🔵 重构阶段** - 在测试通过前提下优化代码
+5. **反馈扫描** - 检查是否触发自循环反馈（见第5节）
+6. **更新 tasks.md** - 标记状态，记录实现差异
+
+### 5. 自循环反馈（核心！）
+
+实现阶段是反馈最密集的阶段。**每个任务完成后，必须进行反馈扫描：**
+
+#### 5.1 反馈触发条件
+
+| 发现的问题 | 反馈目标 | 级别 | 处理方式 |
+|-----------|---------|------|---------|
+| API 路径/参数需要调整 | plan.md | L1 | 直接修改 plan + tasks，记录 CR |
+| 可复用现有模块，无需新建 | plan.md | L1 | 简化 plan，更新 tasks，记录 CR |
+| 实现逻辑与 plan 设计不一致 | plan.md | L2 | 暂停，向用户说明差异，确认后修改 |
+| 边界条件 plan 未覆盖 | plan.md + testcases.md | L2 | 补充设计 + 补充测试用例 |
+| bug 暴露设计缺陷 | plan.md | L2 | 分析根因，修正设计，记录 CR |
+| bug 暴露需求逻辑漏洞 | spec.md | L2 | 暂停，向用户说明，确认后修正 spec + 级联更新 |
+| 性能问题需架构调整 | plan.md | L3 | 暂停全部，输出影响分析，等用户决策 |
+| 发现需求方向性错误 | spec.md | L3 | 暂停全部，输出影响分析，等用户决策 |
+
+#### 5.2 反馈执行流程
+
+```
+发现问题时：
+1. 创建 CR 记录（在当前文档的变更记录中）
+2. 按 L1/L2/L3 级别处理
+   L1: 直接修正源头 → 级联更新下游 → 继续执行
+   L2: 暂停 → 向用户说明 → 用户确认 → 修正源头 → 级联更新 → 继续执行
+   L3: 暂停全部 → 输出影响报告 → 等用户决策
+3. 修正完成后，从修正点重新验证到当前阶段
+```
+
+#### 5.3 级联更新检查清单
+
+修正源头文档后，检查下游是否需要同步更新：
+
+- [ ] spec 修正 → testcases 是否需要补充？
+- [ ] spec 修正 → plan 的设计是否仍然适用？
+- [ ] plan 修正 → tasks 的任务分解是否需要调整？
+- [ ] plan 修正 → 已完成的代码是否需要返工？
+- [ ] testcases 修正 → plan 的测试覆盖是否完整？
+
+### 6. 阶段合约自检（SDD v2 新增）
+
+> **受 Harness Sprint Contract 启发**: 每个 Phase 完成后，对照 plan.md 中的"阶段合约"进行自检。
+
+每个 Phase 完成后（在检查点之前），执行合约自检：
+
+#### 6.1 自检流程
+
+1. 读取 plan.md 中当前 Phase 的阶段合约
+2. 逐项检查交付物清单（是否都已实现）
+3. 逐项检查验证标准（是否都满足）
+4. 检查质量阈值（是否都达到）
+
+#### 6.2 自检输出
+
+```
+📋 Phase {N} 合约自检
+
+交付物清单:
+  ✅ 数据模型层：对应实体和服务
+  ✅ 数据访问层：仓储 + 映射
+  ❌ API层：控制器（未实现分页参数）
+
+验证标准:
+  ✅ #1 创建 API 返回正确数据格式
+  ✅ #2 查询支持筛选条件
+  ❌ #3 查询支持分页（缺少分页参数）
+
+质量阈值:
+  ✅ 所有 API 端点可访问
+  ✅ 无 N+1 查询
+  ✅ 架构分层正确
+
+自检结论: FAIL - 2 项未通过，需修复后重新自检
+```
+
+#### 6.3 自检规则
+
+- 自检全部 PASS → 进入步骤 7（检查点）
+- 自检存在 FAIL → 修复问题 → 重新自检（最多 3 轮）
+- 超过 3 轮仍未通过 → 暂停，向用户报告阻塞项
+
+### 7. 检查点与评审触发（SDD v2 增强）
+
+- **Checkpoint 1**: 后端完成 + 合约自检通过 + API可访问
+  - → **建议运行 `/sdd-review {feature_id}` 进行后端独立评审**
+- **Checkpoint 2**: 前端完成 + 合约自检通过 + 页面可访问
+  - → **建议运行 `/sdd-review {feature_id}` 进行前端独立评审**
+- **Checkpoint 3**: 全部测试通过 + Code Review通过
+  - → **建议运行 `/sdd-review {feature_id}` 进行最终评审**
+- **最终检查**: 检查所有 CR 记录是否已闭环，L2+ 的反馈是否已沉淀到宪法
+
+> **评审是可选的但强烈建议**。小功能可以跳过评审直接提交，大功能务必经过评审。
+
+### 7. 完成后生成执行报告
+
+汇总：任务统计、变更文件列表、CR 反馈统计、待处理事项、下一步操作。
+
+## 注意事项
+
+- 不跳过单元测试，不忽略 lint/checkstyle 警告
+- 注意 N+1 查询问题，注意 SQL 注入和 XSS 防护
+- API 变更时同步更新文档
+- **L2+ 级别的反馈经验，必须提炼为经验教训追加到宪法**
+- 文件路径使用项目实际目录结构（参考 CLAUDE.md）

package/templates/skills/sdd-init/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: sdd-init
+description: 初始化 SDD 工作流 - 分析项目结构，生成项目宪法，适配 SDD 配置
+invocable: true
+---
+
+# SDD Init - 项目初始化
+
+> 首次在项目中使用 SDD 时运行此命令，自动分析项目并生成项目宪法。
+
+## 核心定位
+
+> SDD Init 是 SDD 工作流的入口点。它分析项目结构、技术栈、架构模式，
+> 生成一份项目宪法（constitution.md），作为后续所有 SDD 命令的上下文基础。
+
+## 执行步骤
+
+### 1. 项目结构探测
+
+#### 1.1 探测项目类型
+
+扫描项目根目录，识别项目类型：
+
+| 文件标识 | 项目类型 |
+|---------|---------|
+| `package.json` | Node.js / 前端 |
+| `pom.xml` | Java Maven |
+| `build.gradle` / `build.gradle.kts` | Java Gradle / Kotlin |
+| `go.mod` | Go |
+| `Cargo.toml` | Rust |
+| `requirements.txt` / `pyproject.toml` | Python |
+| `.csproj` / `.sln` | .NET |
+| 以上都有 | 全栈 / Monorepo |
+
+#### 1.2 探测技术栈
+
+**前端技术栈**（如果有 package.json）：
+- 框架：React / Vue / Angular / Svelte / Next.js / Nuxt
+- UI 库：Ant Design / Material UI / Element UI / Tailwind
+- 状态管理：Redux / MobX / Vuex / Pinia / Zustand
+- 构建工具：Webpack / Vite / Rspack / Rollup
+
+**后端技术栈**（如果有 pom.xml / build.gradle 等）：
+- 语言：Java / Kotlin / Go / Python / Rust / C#
+- 框架：Spring Boot / Express / FastAPI / Gin / Actix
+- ORM：MyBatis / JPA / Hibernate / Sequelize / Prisma
+- 数据库：PostgreSQL / MySQL / MongoDB / SQLite
+
+#### 1.3 探测架构模式
+
+扫描目录结构推断架构模式：
+
+| 目录特征 | 架构模式 |
+|---------|---------|
+| `domain/`, `application/`, `infrastructure/` | DDD 分层 |
+| `controllers/`, `services/`, `models/` | MVC |
+| `src/modules/`, `src/features/` | 模块化/特性驱动 |
+| `cmd/`, `internal/` | Go 标准布局 |
+| `pages/`, `components/`, `stores/` | 前端 SPA |
+| 无明显分层 | 简单/待定 |
+
+#### 1.4 探测测试框架
+
+| 文件特征 | 测试框架 |
+|---------|---------|
+| `jest.config.*`, `*.test.js` | Jest |
+| `vitest.config.*` | Vitest |
+| `pytest.ini`, `conftest.py` | pytest |
+| `*_test.go` | Go testing |
+| `*Test.java`, `*Tests.java` | JUnit |
+| `playwright.config.*` | Playwright (E2E) |
+| `cypress.config.*` | Cypress (E2E) |
+
+### 2. 展示探测结果并确认
+
+向用户展示探测到的一切信息，询问是否需要修正：
+
+```
+━━━ 项目探测结果 ━━━
+
+📁 项目类型: 全栈 (前端 + 后端)
+
+🔧 前端技术栈:
+  - 框架: React 17
+  - UI 库: Ant Design 4
+  - 状态管理: MobX 5
+  - 构建工具: Webpack 5
+
+🔧 后端技术栈:
+  - 语言: Java 8
+  - 框架: Spring Boot 2.1.7
+  - ORM: MyBatis
+  - 数据库: PostgreSQL
+
+🏗️ 架构模式: DDD 分层 (后端) + SPA (前端)
+
+🧪 测试框架: Jest (前端) + JUnit (后端)
+
+❓ 以上信息是否正确？如有需要修正的地方请告诉我。
+```
+
+### 3. 交互式补充信息
+
+基于探测结果，补充以下信息（只问探测不到的）：
+
+1. **API 响应格式**：`{ status: "0", message: "", data: {} }` 或其他格式
+2. **是否使用知识库 MCP**（如 Confluence）：是/否
+3. **开发原则补充**：是否有团队特有的开发规范
+4. **项目特殊约束**：如 Java 版本限制、浏览器兼容性等
+
+### 4. 生成项目宪法
+
+基于确认的探测结果和补充信息，生成 `.specify/memory/constitution.md`。
+
+使用模板：`.specify/templates/constitution-template.md`
+
+如果模板不存在，则使用以下内置模板结构。
+
+#### 自动填充的变量：
+
+- `{frontend_stack}`: 前端技术栈详情
+- `{backend_stack}`: 后端技术栈详情
+- `{database}`: 数据库类型
+- `{architecture_pattern}`: 架构模式描述
+- `{test_frameworks}`: 测试框架列表
+- `{api_response_format}`: API 响应格式
+
+#### 必须包含的章节：
+
+1. **绝对铁律** - 数据字段不可凭猜测、禁止 N+1 查询等通用铁律
+2. **开发原则** - 简单性原则、代码质量、测试标准
+3. **架构约束** - 基于探测到的架构模式
+4. **SDD 文档职责边界** - spec/plan/tasks 的 What/How/When 分工
+5. **SDD 阶段合约与评审标准** - 评审维度、权重、硬阈值
+6. **经验教训** - 空白模板，供后续积累
+
+#### 宪法内容模板
+
+当 `.specify/templates/constitution-template.md` 不存在时，使用以下结构生成：
+
+```markdown
+# 项目宪法 (Constitution)
+
+> 自动生成于 {date}，由 SDD Init 分析项目结构后创建。
+> 可随时通过 /sdd-constitution 命令更新。
+
+---
+
+## 1. 技术栈
+
+{frontend_stack_section}
+
+{backend_stack_section}
+
+### 数据库
+- 类型: {database}
+
+### 测试框架
+- {test_frameworks}
+
+---
+
+## 2. 绝对铁律
+
+> 违反以下任何规则等同于生产事故。
+
+### 2.1 数据完整性
+- **数据字段不可凭猜测**：所有字段名、类型、约束必须从数据库或 API 文档确认
+- **禁止假设数据格式**：日期格式、枚举值、ID 规则必须验证
+- **修改前先读取**：任何修改操作前，先读取当前数据状态
+
+### 2.2 查询性能
+- **禁止 N+1 查询**：循环中不可有数据库查询，必须使用批量查询
+- **新增查询必须有索引支持**：WHERE 条件字段必须有对应索引
+- **分页必须带 LIMIT**：列表查询必须有上限保护
+
+### 2.3 安全底线
+- **SQL 参数化**：禁止字符串拼接 SQL
+- **权限校验**：所有 API 入口必须有权限验证
+- **敏感数据**：密码、密钥等不可出现在日志或响应中
+
+---
+
+## 3. 开发原则
+
+### 3.1 简单性原则（Simplicity Principle）
+1. **复用优先**：新增方法前先查找现有方法是否可复用
+2. **最小改动**：只改必须改的，不做"顺便"的重构
+3. **渐进式**：优先选择最简单的实现路径
+
+### 3.2 代码质量标准
+- 函数长度不超过 50 行
+- 嵌套不超过 3 层
+- 新增公共方法必须有注释说明用途
+- 遵循项目已有的命名风格
+
+### 3.3 测试标准
+- 核心逻辑必须有测试覆盖
+- 测试用例在实现之前编写（TDD / 红-绿-重构）
+- 边界条件和异常路径必须测试
+
+---
+
+## 4. 架构约束
+
+{architecture_constraint_section}
+
+---
+
+## 5. API 规范
+
+### 响应格式
+{api_response_format}
+
+### 错误处理
+- 所有异常必须有对应的错误码和用户友好提示
+- 未知异常统一返回 500，不暴露内部细节
+
+---
+
+## 6. SDD 文档职责边界
+
+| 阶段 | 文档 | 回答的问题 | 不包含 |
+|------|------|-----------|--------|
+| Specify | spec.md | What — 做什么？为什么？ | 技术实现细节 |
+| Test Cases | testcases.md | How to verify — 怎么验证？ | 实现代码 |
+| Plan | plan.md | How — 怎么实现？技术方案 | 具体代码 |
+| Tasks | tasks.md | When — 什么时候做？任务拆分 | 实现细节 |
+
+---
+
+## 7. SDD 阶段合约与评审标准
+
+### 评审维度与权重
+
+| 维度 | 权重 | 硬阈值 |
+|------|------|--------|
+| 功能完整性 | 30% | 所有 spec 定义的场景已覆盖 |
+| 代码质量 | 20% | 无 lint 错误，无重复代码 |
+| 测试覆盖 | 20% | 核心逻辑测试通过率 100% |
+| 架构合规 | 15% | 符合架构约束，分层正确 |
+| 性能安全 | 15% | 无 N+1 查询，无安全漏洞 |
+
+### 评审流程
+1. 自动检查：lint、测试、类型检查
+2. AI 审查：对照 spec + plan 合约逐项验证
+3. 评分：满分 100，低于 70 分不通过
+4. 不通过时：自动修复 → 重新评审（最多 3 轮）
+
+---
+
+## 8. 经验教训
+
+> 开发过程中积累的经验，持续更新。
+
+<!-- 在此添加项目中遇到的实际问题和解决方案 -->
+```
+
+### 5. 创建目录结构
+
+确保以下目录存在：
+
+```
+.specify/
+├── memory/
+│   └── constitution.md    ← 刚生成的宪法
+├── specs/                 ← 功能规格目录
+├── templates/             ← 模板文件（已安装）
+└── scripts/               ← 工具脚本（已安装）
+```
+
+使用 bash 命令创建不存在的目录：
+```bash
+mkdir -p .specify/memory .specify/specs
+```
+
+### 6. 输出初始化报告
+
+```
+━━━ SDD 初始化完成 ━━━
+
+✅ 项目宪法已生成: .specify/memory/constitution.md
+
+📋 项目配置摘要:
+  - 项目类型: {type}
+  - 前端: {frontend_stack}
+  - 后端: {backend_stack}
+  - 数据库: {database}
+  - 架构: {architecture}
+  - 测试: {test_frameworks}
+
+🚀 开始使用 SDD:
+  /sdd-specify <功能名称>          创建功能规格
+  /sdd-run <id> <功能描述>         全自动流水线（推荐）
+```
+
+## 注意事项
+
+1. **不修改 CLAUDE.md**：只输出建议追加的内容，由用户决定是否添加
+2. **幂等性**：重复运行时检测已有宪法，询问是更新还是重新生成
+3. **渐进式**：探测不到的信息不强制要求，可后续通过 `/sdd-constitution` 补充
+4. **最小化提问**：只问真正探测不到的关键信息，不超过 5 个问题

package/templates/skills/sdd-plan/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: sdd-plan
+description: 创建技术实现计划（Implementation Plan）- 基于测试用例设计技术方案、数据模型、API设计
+invocable: true
+---
+
+# SDD Plan - 技术计划生成器
+
+基于测试用例设计技术实现计划，确保实现有据可依。
+
+## ⚠️ 核心定位：Plan 是 Spec 的技术承接
+
+> **Plan 描述 How（怎么做）**，承接 Spec 中的 What（做什么）。
+> 所有 Spec 中故意省略的技术细节，都应该在 Plan 中详细展开。
+
+### Plan 中应该包含的内容（Spec 中不允许出现的）
+- **具体文件路径**：需要新增/修改的文件清单
+- **SQL / DDL**：数据库表设计、查询语句
+- **代码片段**：关键实现的代码骨架
+- **类名、方法名**：具体的命名设计
+- **架构图**：带代码级细节的架构图
+- **API 详细设计**：完整的 URL path、参数、响应格式
+- **调用链路**：完整的模块间调用链路
+- **修改清单**：所有需要变更的文件及变更类型
+
+### SDD 文档职责分工
+
+```
+spec.md    → What（做什么）：业务需求、用户故事、验收标准
+plan.md    → How（怎么做）：技术方案、架构设计、代码设计  ← 你在这里
+tasks.md   → When（何时做）：任务分解、执行顺序、进度跟踪
+```
+
+## 核心理念
+
+> **测试驱动设计**
+
+技术计划必须能够：
+1. 通过所有已定义的测试用例
+2. 覆盖测试用例中的边界条件
+3. 满足测试用例中的验收标准
+
+## 前置条件
+- 必须已有功能规格文档: `.specify/specs/{feature_id}/spec.md`
+- **必须已有测试用例设计: `.specify/specs/{feature_id}/testcases.md`** ← 测试优先
+- 推荐已有项目宪法: `.specify/memory/constitution.md`
+
+## 执行步骤
+
+### 1. 读取规格文档
+读取关联的功能规格: `.specify/specs/{feature_id}/spec.md`
+
+### 2. 读取测试用例（重要！）
+读取测试用例设计: `.specify/specs/{feature_id}/testcases.md`
+
+**重点关注**:
+- 单元测试场景 → 驱动业务逻辑层设计
+- 集成测试场景 → 驱动数据访问层设计
+- API测试场景 → 驱动接口设计
+- 前端测试场景 → 驱动组件设计
+- 边界条件 → 驱动异常处理设计
+
+### 3. 读取项目上下文
+- `.specify/memory/constitution.md` - 技术栈约束和架构模式
+- `CLAUDE.md` - 项目配置和目录结构
+- 相关模块的现有代码
+
+### 3. 技术调研（如需要）
+- 查找项目中类似功能的实现
+- 分析现有API模式
+- 检查数据库表结构
+
+### 4. 生成技术计划
+
+基于模板 `.specify/templates/plan-template.md` 生成文档，包括：
+
+#### 核心内容：
+
+##### 4.1 架构设计
+- 整体架构图（ASCII或描述）
+- 模块划分
+- 技术栈确认（从 constitution.md 读取）
+
+##### 4.2 数据模型
+- 数据库表设计（DDL）
+- 实体类设计
+- 数据流向
+
+##### 4.3 API设计
+- API列表
+- 请求/响应格式
+- API契约文件
+
+##### 4.4 前端实现
+- 页面结构
+- 组件设计
+- 状态管理方案（参考 constitution.md）
+- 路由配置
+
+##### 4.5 后端实现
+- 架构分层设计（参考 constitution.md 中的架构模式）
+- 核心类设计
+- 业务流程
+
+##### 4.6 阶段合约（SDD v2 新增）
+
+> **受 Harness Sprint Contract 启发**: 在写代码之前，为每个 Phase 定义明确的"完成"标准。
+> 合约来源于 spec 的完成定义和 testcases 的行为验证，将两者对接为可检查的交付物清单。
+
+为每个实现 Phase 生成阶段合约：
+
+```markdown
+### Phase 1 合约（后端）
+
+#### 交付物清单
+- [ ] 数据模型层：对应实体和服务
+- [ ] 数据访问层：仓储/Repository + 映射
+- [ ] 应用/服务层：业务逻辑
+- [ ] API层：控制器/路由
+- [ ] 数据库变更：新增/修改的表
+
+#### 验证标准
+| # | 验证项 | 验证方式 | 关联 |
+|---|--------|----------|------|
+| 1 | 创建 API 返回正确数据格式 | API调用验证 | spec Group A 完成定义 #1 |
+| 2 | 查询支持分页和筛选 | 参数测试 | spec Group A 完成定义 #2, #3 |
+| 3 | 数据访问层无 N+1 查询 | 代码审查 | constitution 相关章节 |
+| 4 | 架构分层正确 | 代码审查 | constitution 架构约束 |
+
+#### 质量阈值
+- 所有 API 端点可访问且返回项目约定的响应格式
+- 无 N+1 查询
+- 架构分层正确（参考 constitution.md 中的架构约束）
+```
+
+**合约设计原则**:
+- 交付物清单：列出该 Phase 应产出的所有代码文件/数据库变更
+- 验证标准：每项关联到 spec 的完成定义和/或 constitution 的约束
+- 质量阈值：该 Phase 的最低通过标准，评审时对照检查
+- 合约是 plan.md 的一部分，不是独立文件
+- 合约条目数量：每个 Phase 5-15 项验证标准
+
+##### 4.7 其他
+- 安全设计
+- 性能优化
+- 测试计划
+- 部署计划
+
+### 5. 生成API契约（可选）
+如果API较复杂，生成OpenAPI格式的契约文件:
+```json
+// .specify/specs/{feature_id}/contracts/api-spec.json
+{
+  "openapi": "3.0.0",
+  "info": { ... },
+  "paths": { ... }
+}
+```
+
+### 6. 保存文档
+保存到: `.specify/specs/{feature_id}/plan.md`
+
+### 7. 检测文档大小
+
+plan.md 超过 1000 行时，自动执行 `/sdd-split plan {feature_id} --auto` 拆分（在 sdd-run 中）或提示用户使用 `/sdd-split plan {feature_id}`（手动模式下）。
+
+### 8. 交互确认
+向用户展示技术计划要点，询问是否需要调整。
+
+## 输出示例
+
+```
+✅ 技术计划已生成: .specify/specs/001-user-authentication/plan.md
+
+📋 技术方案要点：
+
+1. 架构设计
+   - 前端: 项目前端技术栈 + 状态管理方案（参考 constitution.md）
+   - 后端: 项目架构模式（参考 constitution.md）
+   - 数据库: 使用项目数据库
+
+2. 数据模型
+   - 无新增表，使用现有用户表
+   - 新增Token缓存表
+
+3. API设计
+   - POST /api/auth/login - 登录
+   - POST /api/auth/logout - 登出
+   - POST /api/auth/refresh - 刷新Token
+
+4. 前端实现
+   - 页面: 登录页面组件
+   - 状态管理: 认证状态
+   - API: 认证接口调用
+
+5. 后端实现
+   - 核心业务逻辑: 认证服务
+   - API层: 认证路由/控制器
+   - 数据访问: 认证数据仓储
+
+请检查技术方案，如需调整请告诉我。
+```
+
+## 分层模板参考
+
+架构分层模板见 CLAUDE.md 和 constitution.md 中的架构约束。不同架构模式（DDD、传统三层、Clean Architecture 等）对应不同的分层方式。
+
+## 反馈触发点
+
+设计技术方案时，以下情况**必须触发向上反馈**：
+
+1. **需求技术上不可行** → 业务规则与现有架构冲突，反馈回 spec 重新定义
+2. **需求遗漏关联模块** → 发现依赖未在 spec 中说明，补充到 spec
+3. **测试用例无法通过当前设计覆盖** → 反馈回 testcases 确认是否遗漏场景
+4. **发现可复用现有模块，无需新建** → 简化 plan 并记录 CR
+
+反馈流程：在 plan.md 中创建 CR 记录 → 修正源头文档 → 同步更新 plan.md → 继续设计
+
+## 注意事项
+
+1. **遵循宪法**: 技术方案必须符合项目宪法的约束
+2. **架构一致**: 遵循项目既定的架构模式（参考 constitution.md）
+3. **数据库规范**: 注意使用项目正确的数据库 schema 和命名规范
+4. **API规范**: 遵循项目既定的 API 设计风格和响应格式
+5. **复用优先**: 优先考虑复用现有组件和服务
+6. **性能考量**: 设计阶段考虑索引、缓存等优化