@pigcloud/skills 1.0.0

package/skills/spec-refinement/references/ears-syntax.md

@@ -0,0 +1,127 @@
+# EARS 语法参考（Easy Approach to Requirements Syntax）
+
+> 消除需求歧义的结构化语法，参考 AWS Kiro 的 Spec 工作流
+
+## 核心句式
+
+### 1. 用户故事（User Story）
+As a [角色], I want [功能], so that [价值]
+
+**示例**:
+- As a 普通用户, I want 查看我的订单列表, so that 我可以追踪订单状态
+- As a 管理员, I want 审核退款申请, so that 我可以控制退款风险
+
+### 2. 验收标准（Acceptance Criteria）
+WHEN [事件/条件] THEN the system SHALL [响应/行为]
+
+**示例**:
+- WHEN 用户点击"提交订单" THEN the system SHALL 创建订单并返回订单号
+- WHEN 订单金额 <= 0 THEN the system SHALL 拒绝创建并提示"订单金额必须大于0"
+- WHEN 用户未登录 THEN the system SHALL 返回 401 NotLoginException
+
+### 3. 业务规则（Business Rule）
+IF [条件] THEN [动作/约束]
+
+**示例**:
+- IF 订单状态 != CREATED THEN 抛出 BusinessException("订单状态不正确")
+- IF 用户余额 < 订单金额 THEN 拒绝支付并提示余额不足
+
+### 4. 不变式（Invariant）
+ALWAYS [约束] / NEVER [动作]
+
+**示例**:
+- ALWAYS 订单号全局唯一
+- NEVER 在事务中执行远程调用
+- ALWAYS 敏感数据脱敏后返回
+
+## 语法模式识别
+
+从自然语言中识别 EARS 模式：
+
+| 自然语言模式 | EARS 句式 | 提取方法 |
+|-------------|----------|---------|
+| "用户可以..." | User Story | 识别角色 + 功能 |
+| "当...时，系统应该..." | Acceptance Criteria | 识别事件 + 响应 |
+| "如果...则..." | Business Rule | 识别条件 + 动作 |
+| "必须..." / "不能..." | Invariant | 识别约束 |
+| "只有...才能..." | Business Rule | 识别前置条件 |
+| "...之后自动..." | Acceptance Criteria | 识别触发事件 + 自动动作 |
+
+## 模糊关键词检测
+
+以下关键词表示需求可能不明确，需要追问：
+
+| 模糊词 | 风险 | 追问方向 |
+|--------|------|---------|
+| 大概/可能/也许 | 不确定性 | 具体条件是什么？ |
+| 合适的/适当的 | 主观判断 | 什么标准算"合适"？ |
+| 尽量/尽可能 | 非强制 | 是 Must 还是 Should？ |
+| 快速/高效 | 无量化 | 具体响应时间要求？ |
+| 大量/很多 | 无量化 | 预估数据量级？ |
+| 方便/好用 | 主观体验 | 具体交互方式？ |
+| 安全的 | 无具体措施 | 具体安全要求？ |
+| 有时候/偶尔 | 不确定性 | 触发条件是什么？ |
+| 等一下/稍后 | 时序不明确 | 具体时间要求？ |
+| 相关的/类似的 | 范围模糊 | 具体包含哪些？ |
+
+## INVEST 原则
+
+评估用户故事质量：
+
+| 原则 | 含义 | 检查方法 |
+|------|------|---------|
+| Independent | 独立的，不依赖其他故事 | 是否可单独交付？ |
+| Negotiable | 可协商的，细节可讨论 | 是否留有讨论空间？ |
+| Valuable | 有价值的，对用户有意义 | 用户是否在乎？ |
+| Estimable | 可估算的，复杂度可评估 | 是否能估算工作量？ |
+| Small | 足够小，一个迭代可完成 | 是否需要拆分？ |
+| Testable | 可测试的，有验收标准 | 是否有明确的通过/失败判定？ |
+
+## MoSCoW 优先级
+
+| 优先级 | 含义 | 判定标准 |
+|--------|------|---------|
+| **Must** | 必须有 | 核心功能，没有则系统不可用 |
+| **Should** | 应该有 | 重要功能，本次迭代尽量实现 |
+| **Could** | 可以有 | 锦上添花，资源允许时实现 |
+| **Won't** | 不会有 | 本次不实现，记录备查 |
+
+## 需求 ID 编码规范
+
+格式: REQ-{模块缩写}-{序号}
+
+示例:
+- REQ-ORD-001: 订单创建
+- REQ-ORD-002: 订单支付
+- REQ-ORD-003: 订单取消
+- REQ-USR-001: 用户注册
+- REQ-USR-002: 用户登录
+
+## 正反示例对比
+
+### 用户故事
+<good-example>
+As a 普通用户, I want 通过手机号+验证码登录, so that 我无需记住密码即可快速访问
+</good-example>
+
+<bad-example>
+用户要能登录系统
+</bad-example>
+
+### 验收标准
+<good-example>
+WHEN 用户输入正确手机号和验证码 THEN the system SHALL 返回 JWT Token 和用户信息，响应时间 < 500ms
+</good-example>
+
+<bad-example>
+登录成功后返回 Token
+</bad-example>
+
+### 业务规则
+<good-example>
+IF 验证码已过期（超过5分钟）THEN the system SHALL 抛出 ParameterIllegalException("验证码已过期，请重新获取") 【服务端强制】
+</good-example>
+
+<bad-example>
+验证码不能过期
+</bad-example>

package/skills/spec-refinement/references/requirement-checklist.md

@@ -0,0 +1,139 @@
+# 需求分析检查清单
+
+> 基于 FURPS+ 模型和 EARS 语法的完整需求分析检查项
+
+## 一、需求收集检查
+
+### 1.1 业务背景（Why）
+| 检查项 | 通过标准 | 常见问题 |
+|--------|---------|---------|
+| 业务目标明确 | 能用一句话描述功能目标 | "做一个管理系统" |
+| 业务价值清晰 | 能说明解决了什么问题 | "领导要求的" |
+| 业务背景完整 | 能说明触发原因 | 无背景说明 |
+
+### 1.2 用户角色（Who）
+| 检查项 | 通过标准 | 常见问题 |
+|--------|---------|---------|
+| 角色定义完整 | 所有操作者角色已列出 | 遗漏旁观者/审核者 |
+| 权限矩阵清晰 | 每个角色能做什么已定义 | "管理员可以操作" |
+| 角色关系明确 | 角色之间的关系已定义 | 无角色层级说明 |
+
+### 1.3 业务流程（How）
+| 检查项 | 通过标准 | 常见问题 |
+|--------|---------|---------|
+| 主流程完整 | 正常执行步骤无遗漏 | 跳过中间步骤 |
+| 异常流程覆盖 | 主要异常场景已列出 | "异常以后处理" |
+| 边界条件识别 | 边界值已识别 | 无边界分析 |
+| 分支流程定义 | 条件分支已定义 | "看情况" |
+
+### 1.4 数据范围（What）
+| 检查项 | 通过标准 | 常见问题 |
+|--------|---------|---------|
+| In Scope 明确 | 功能范围内的事项已列出 | 范围模糊 |
+| Out Scope 明确 | 明确不做什么 | 无 Out Scope |
+| 数据实体识别 | 涉及的数据实体已列出 | 遗漏关联实体 |
+| 数据量评估 | 预估数据量级 | 无数据量评估 |
+
+### 1.5 约束条件（Constraints）
+| 检查项 | 通过标准 | 常见问题 |
+|--------|---------|---------|
+| 性能要求 | 响应时间/并发量已明确 | "要快" |
+| 安全要求 | 认证/授权/脱敏已明确 | "要安全" |
+| 兼容性要求 | 浏览器/版本/接口兼容已明确 | 无兼容性说明 |
+| 技术约束 | 技术栈/框架限制已明确 | 无技术约束 |
+
+## 二、需求结构化检查（EARS 语法）
+
+### 2.1 用户故事
+| 检查项 | 通过标准 | 错误示例 | 正确示例 |
+|--------|---------|---------|---------|
+| 角色明确 | As a [具体角色] | As a user | As a 普通用户 |
+| 功能明确 | I want [具体功能] | I want 管理 | I want 创建、编辑、删除订单 |
+| 价值明确 | so that [具体价值] | so that 方便 | so that 可以追踪订单状态 |
+| INVEST 原则 | Independent/Negotiable/Valuable/Estimable/Small/Testable | - | - |
+
+### 2.2 验收标准
+| 检查项 | 通过标准 | 错误示例 | 正确示例 |
+|--------|---------|---------|---------|
+| WHEN 条件明确 | 触发事件清晰 | WHEN 用户操作 | WHEN 用户点击"提交订单"按钮 |
+| THEN 响应明确 | 系统响应可验证 | THEN 成功 | THEN 系统返回 Result<OrderVO>，订单状态变为 PAID |
+| 可验证性 | 有明确的通过/失败判定 | THEN 快速响应 | THEN 响应时间 < 500ms |
+| 边界覆盖 | 边界条件有验收标准 | - | WHEN 金额为 0.01 THEN ... |
+
+### 2.3 业务规则
+| 检查项 | 通过标准 | 错误示例 | 正确示例 |
+|--------|---------|---------|---------|
+| 条件清晰 | IF 条件明确 | IF 金额不对 | IF 订单金额 <= 0 |
+| 动作明确 | THEN 动作可执行 | THEN 报错 | THEN 抛出 ParameterIllegalException("订单金额必须大于0") |
+| 执行方标注 | 标注谁来保证 | 无标注 | 【服务端强制】/【调用方需预判】 |
+
+## 三、需求质量检查
+
+### 3.1 隐含假设
+| 检查项 | 检查方法 |
+|--------|---------|
+| 数据量假设 | "如果数据量增长 10 倍，这个需求还成立吗？" |
+| 并发假设 | "如果 100 个用户同时操作，会怎样？" |
+| 时序假设 | "如果操作顺序颠倒，会怎样？" |
+| 外部依赖假设 | "如果依赖的外部系统不可用，会怎样？" |
+| 权限假设 | "如果用户没有预期权限，会怎样？" |
+
+### 3.2 矛盾检测
+| 检查维度 | 检查方法 | 示例 |
+|---------|---------|------|
+| 权限矛盾 | A 要求开放 vs B 要求限制 | "所有接口公开" vs "需要管理员权限" |
+| 状态矛盾 | A 的流转 vs B 的流转 | "订单不可取消" vs "支持退款" |
+| 数据矛盾 | A 的唯一性 vs B 的重复 | "手机号唯一" vs "允许更换手机号" |
+| 时序矛盾 | A 实时 vs B 批量 | "实时通知" vs "每天汇总" |
+
+### 3.3 可测试性
+| 检查项 | 通过标准 | 不可测试示例 | 可测试示例 |
+|--------|---------|-------------|-----------|
+| 可验证 | 有明确通过/失败判定 | "系统应该快速响应" | "P99 响应时间 < 200ms" |
+| 可量化 | 有具体数值 | "支持大量数据" | "支持 10 万条记录分页查询" |
+| 可复现 | 测试步骤可重复 | "有时候会出错" | "当金额为负数时抛出异常" |
+
+## 四、需求完整性检查（FURPS+）
+
+| 维度 | 全称 | 检查项 | 通过标准 |
+|------|------|--------|---------|
+| F | Functionality | 功能完整性 | 每个功能点有输入/输出/规则 |
+| U | Usability | 可用性 | 用户角色和权限已定义 |
+| R | Reliability | 可靠性 | 异常处理策略已定义 |
+| P | Performance | 性能 | 响应时间/并发量已明确 |
+| S | Supportability | 可支持性 | 日志/监控/缓存策略已分析 |
+| + | 其他 | 安全/合规/兼容 | 安全要求/合规要求已明确 |
+
+## 五、迭代开发额外检查
+
+### 5.1 影响分析
+| 检查项 | 通过标准 |
+|--------|---------|
+| 模块依赖 | 受影响模块已识别 |
+| API 调用链 | Feign 调用影响已分析 |
+| 数据依赖 | 实体关联影响已分析 |
+| 状态流转 | 状态变更影响已分析 |
+| 回归风险 | 回归测试范围已评估 |
+
+### 5.2 风险评估
+| 风险等级 | 判定条件 | 处理方式 |
+|---------|---------|---------|
+| Critical | 涉及核心流程 + 跨服务调用 + 事务边界 | 必须有回滚方案 |
+| High | 涉及状态变更 + 权限变更 + 数据结构变更 | 需要回归测试 |
+| Medium | 涉及查询逻辑 + UI 字段调整 | 建议回归测试 |
+| Low | 涉及日志 + 注释 + 代码重构 | 常规测试 |
+
+## 六、Anti-rationalization Table (Requirement Analysis)
+
+| 常见借口 | 反驳理由 | 正确做法 |
+|---------|---------|---------|
+| "需求很清楚，不需要文档" | 清楚的需求也会变化 | 编写需求文档 |
+| "这个功能很简单" | 简单功能也有边界情况 | 完整需求分析 |
+| "用户会这样操作" | 用户操作方式多样 | 分析所有场景 |
+| "这个边界不会发生" | 边界情况总会发生 | 处理边界 |
+| "这个功能以后再加" | 以后加的成本更高 | 现在规划 |
+| "这个影响范围很小" | 小影响也会产生连锁反应 | 完整影响分析 |
+| "这个模块不依赖其他模块" | 模块间总有依赖 | 分析依赖 |
+| "先做再说，需求以后补" | 无文档的需求无法维护 | 先需求后实现 |
+| "用户说的就是需求" | 用户说的往往是解决方案而非需求 | 追问真实意图 |
+| "这个验收标准够了" | 不完整的验收标准导致返工 | 覆盖正常/异常/边界 |

package/skills/spec-refinement/references/spec-workbook.md

@@ -0,0 +1,75 @@
+# Requirement Spec Workbook
+
+> 闇€姹傚垎鏋愮殑鍙鐢ㄦā鏉夸笌妫€鏌ラ」銆俙SKILL.md` 鍙繚鐣欐祦绋嬶紝杩欓噷淇濈暀浜у嚭缁撴瀯鍜屽父鐢ㄦ槧灏勩€傞渶瑕佸叿浣撹鍒欐椂锛屼紭鍏堝紩鐢?[rules/index.md](/D:/work/java/pig-skills/rules/index.md) 鍜屽搴斿瓙瑙勫垯銆?
+## EARS Template
+
+```markdown
+### REQ-001: [闇€姹傛爣棰榏
+- **浼樺厛绾?*: Must | Should | Could | Won't
+- **鐢ㄦ埛鏁呬簨**: As a [role], I want [feature], so that [benefit]
+- **楠屾敹鏍囧噯**:
+  - WHEN [event] THEN the system SHALL [response]
+- **涓氬姟瑙勫垯**:
+  - IF [condition] THEN [action/constraint]
+- **涓嶅彉寮?*:
+  - ALWAYS [constraint]
+  - NEVER [action]
+```
+
+## Assumption Checklist
+
+| 鍋囪 ID | 鍏宠仈闇€姹?| 鍋囪鍐呭 | 椋庨櫓绛夌骇 | 楠岃瘉鏂瑰紡 |
+|---------|---------|---------|---------|---------|
+| ASM-001 | REQ-001 | 鐢ㄦ埛宸茬櫥褰曚笖鏈夋湁鏁堟敹璐у湴鍧€ | 楂?| 鍓嶇疆楠岃瘉 |
+| ASM-002 | REQ-003 | 鏀粯鎺ュ彛鍝嶅簲鏃堕棿 < 3s | 涓?| 鍘嬫祴楠岃瘉 |
+| ASM-003 | REQ-005 | 鍟嗗搧浠锋牸鍦ㄤ笅鍗曞悗涓嶅彉 | 楂?| 浠锋牸閿佸畾鏈哄埗 |
+
+## Conflict Report
+
+| 鍐茬獊 ID | 娑夊強闇€姹?| 鍐茬獊绫诲瀷 | 鎻忚堪 | 寤鸿鏂规 |
+|---------|---------|---------|------|---------|
+| CONFLICT-001 | REQ-002, REQ-004 | 鐘舵€佸啿绐?| 宸插彂璐ц鍗曠殑鍙栨秷绛栫暐鍐茬獊 | 缁熶竴涓轰笉鍙彇娑?/ 澧炲姞瀹℃牳鍙栨秷娴佺▼ |
+
+## Capability Map
+
+| 闇€姹?ID | 闇€姹傛弿杩?| 鑳藉姏鍒嗙被 | 妗嗘灦鏀寔鏂瑰紡 | 澶囨敞 |
+|---------|---------|---------|-------------|------|
+| REQ-001 | RESTful API 杩斿洖 | 鍘熺敓鏀寔 | Result<T> + @RestController | - |
+| REQ-003 | 鏁版嵁鏉冮檺闅旂 | 鍘熺敓鏀寔 | @IgnoreTenant + 澶氱鎴锋嫤鎴櫒 | - |
+| REQ-005 | PDF 瀵煎嚭 | 鍙墿灞曟敮鎸?| 鑷畾涔?Starter 鎴栨帴鍏?iText | 璇勪及宸ヤ綔閲?|
+| REQ-008 | 瀹炴椂娑堟伅鎺ㄩ€?| 涓嶆敮鎸?| 闇€寮曞叆 WebSocket/MQ | 璇勪及寮曞叆鎴愭湰 |
+
+## Output Template
+
+```markdown
+# {妯″潡鍚峿 闇€姹傛枃妗?
+
+## 1. 鍔熻兘姒傝堪
+## 2. 鍔熻兘鑼冨洿
+## 3. 缁撴瀯鍖栭渶姹傦紙EARS锛?
+## 4. 闅愬惈鍋囪
+## 5. 闇€姹傚啿绐佹鏌?
+## 6. 妗嗘灦鑳藉姏鏄犲皠
+## 7. 楠屾敹鏍囧噯锛圔DD锛?
+## 8. 闈炲姛鑳芥€ч渶姹?
+## 9. 瀹屾暣鎬ф鏌ユ姤鍛?
+## 10. 褰卞搷鍒嗘瀽锛堜粎杩唬妯″紡锛?
+## 11. 瀹炵幇闃舵杈撳叆鎽樿
+```
+
+## Iteration Impact Summary
+
+| 鍙樻洿椤?| 姒傜巼 | 褰卞搷 | 椋庨櫓绛夌骇 | 鍥炲綊绛栫暐 |
+|--------|------|------|---------|---------|
+| 璁㈠崟鐘舵€佹祦杞慨鏀?| 楂?| 楂?| Critical | 鍏ㄩ噺鍥炲綊 |
+| 鏂板瀹℃牳瀛楁 | 楂?| 涓?| High | 妯″潡鍥炲綊 |
+| API 鍝嶅簲鎵╁睍 | 涓?| 浣?| Low | 澧為噺娴嬭瘯 |
+
+## Anti-rationalization
+
+| 甯歌鍊熷彛 | 鍙嶉┏ |
+|---------|------|
+| 鈥滈渶姹傚凡缁忓緢娓呮浜嗭紝涓嶉渶瑕佸啀闂€?| 鍏堝仛涓€娆℃緞娓呭洖璺?|
+| 鈥滃厛鍋氳璁★紝闇€姹傚彲浠ヨ竟鍋氳竟瀹屽杽鈥?| 鍏堥渶姹傚悗璁捐 |
+| 鈥滃奖鍝嶅垎鏋愬お鑰楁椂浜嗏€?| 璺宠繃浼氭妸椋庨櫓甯﹀埌鍚庨潰 |
+

package/skills/technical-design/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: technical-design
+description: Shape architecture and implementation boundaries from a stable spec when modules, interfaces, or dependencies still need decisions
+lifecycle_stage: design
+rule_profile: analysis
+dependencies:
+  - spec-refinement
+triggers:
+  - architecture decision
+  - module split
+  - interface contract
+  - dependency direction
+  - design boundary
+inputs:
+  - executable spec
+  - selected rules bundle
+  - existing module context
+outputs:
+  - design decisions
+  - dependency map
+  - interface contract
+  - implementation constraints
+workflow:
+  - confirm the spec is stable enough for design work
+  - define boundaries, dependencies, and interfaces
+  - map design decisions to the rules bundle
+  - hand off to feature-build
+gates:
+  - stop at design decisions
+  - do not reopen product discovery
+  - do not produce full code
+  - do not skip rule loading
+refs:
+  - skills/references/rule-loading-map.md
+  - skills/references/flow-test-cases.md
+  - skills/references/full-chain-replay-scenarios.md
+  - skills/references/prompt-replay-checklist.md
+  - rules/index.md
+---
+
+# Technical Design
+
+## Purpose
+
+Turn a stable spec into concrete architecture and implementation boundaries.
+
+## Suitable / Unsuitable
+
+- Suitable: architecture decisions, module split, interfaces, dependency direction, constraint mapping
+- Unsuitable: requirement discovery, code generation, redesigning the PRD, unresolved scope gaps, ignoring the rules bundle
+
+## Quick Start
+
+- Start from the stable spec and isolate the decisions that affect boundaries or dependencies.
+- Load the smallest rules bundle that matches the current task context.
+- Turn design choices into implementation constraints, not code.
+- If the spec is still unstable, stop and return to `spec-refinement`.
+
+## Inputs / Outputs
+
+- Inputs:
+  - executable spec
+  - selected rules bundle
+  - existing module context
+- Outputs:
+  - design decisions
+  - dependency map
+  - interface contract
+  - implementation constraints
+
+## Workflow
+
+1. Confirm the spec is stable enough for design work.
+2. Define boundaries, dependencies, and interfaces.
+3. Route scope gaps back to `spec-refinement` instead of forcing design decisions.
+4. Map design decisions to the rules bundle.
+5. Produce implementation constraints for `feature-build`.
+
+## Replay Signals
+
+- Input signal: multi-module change, boundary ambiguity, dependency risk, or compatibility concern.
+- Output to verify: design decisions, dependency map, interface contract, implementation constraints.
+- Stop signal: full code, reopened product discovery, or skipped rules loading.
+- Handoff signal: implementation can start inside `feature-build`.
+
+## Gotchas
+
+- Do not turn unresolved requirement issues into design decisions.
+- Do not skip rule loading when rule constraints matter.
+- Do not output full code or pseudo-code as the design artifact.
+- Do not collapse boundaries just to reduce context.
+- Do not keep working if the spec is not stable enough to design.
+
+## Stop Rules
+
+- Stop at design decisions.
+- Do not reopen product discovery.
+- Do not produce full code.
+- Do not skip rule loading.
+
+## References
+
+- `skills/references/rule-loading-map.md`
+- `skills/references/flow-test-cases.md`
+- `rules/index.md`

package/skills/technical-design/references/solid-checklist.md

@@ -0,0 +1,199 @@
+# SOLID 检查清单
+
+> 面向对象设计五大原则检查项
+
+---
+
+## S - Single Responsibility Principle (单一职责原则)
+
+**定义**：一个类应该只有一个引起它变化的原因
+
+| 检查项 | 问题信号 | 修复方案 |
+|--------|----------|----------|
+| 类职责过多 | 类名包含"And"或"Or" | 拆分为多个类 |
+| 方法类型混杂 | CRUD + 业务逻辑 + 工具方法 | 分离到不同类 |
+| 字段分组明显 | 字段可按功能分组 | 拆分为多个类 |
+| 变更频率不同 | 部分方法频繁变更，部分不变 | 拆分为多个类 |
+
+**示例**：
+```java
+// ❌ 违反 SRP：订单类同时处理订单数据和邮件通知
+public class Order {
+    private Long id;
+    private String orderNo;
+    
+    public void calculateTotal() { }
+    public void sendEmail() { }  // 应分离到 NotificationService
+}
+
+// ✅ 符合 SRP：职责分离
+public class OrderEntity {
+    private Long id;
+    private String orderNo;
+    public void calculateTotal() { }
+}
+
+public class NotificationService {
+    public void sendOrderEmail(OrderEntity order) { }
+}
+```
+
+---
+
+## O - Open/Closed Principle (开闭原则)
+
+**定义**：对扩展开放，对修改关闭
+
+| 检查项 | 问题信号 | 修复方案 |
+|--------|----------|----------|
+| 硬编码条件 | if-else 类型判断 | 使用策略模式/多态 |
+| 新增类型需修改现有代码 | 添加新类型需修改 switch | 使用接口+实现类 |
+| 逻辑固定 | 业务规则硬编码 | 使用配置/规则引擎 |
+
+**示例**：
+```java
+// ❌ 违反 OCP：新增支付方式需修改现有代码
+public class PaymentService {
+    public void pay(String type) {
+        if (type.equals("ALIPAY")) { }
+        else if (type.equals("WECHAT")) { }
+        // 新增支付方式需修改此处
+    }
+}
+
+// ✅ 符合 OCP：使用策略模式
+public interface PaymentStrategy {
+    void pay();
+}
+
+public class AlipayStrategy implements PaymentStrategy { }
+public class WechatStrategy implements PaymentStrategy { }
+// 新增支付方式只需添加新实现类
+```
+
+---
+
+## L - Liskov Substitution Principle (里氏替换原则)
+
+**定义**：子类必须能够替换其父类
+
+| 检查项 | 问题信号 | 修复方案 |
+|--------|----------|----------|
+| 子类抛出新异常 | 父类不抛出，子类抛出 | 保持异常一致 |
+| 子类返回不同类型 | 返回类型不兼容 | 保持返回类型一致 |
+| 子类行为不一致 | 相同输入不同输出 | 保持行为一致 |
+| 子类限制更强 | 子类拒绝父类接受的输入 | 放宽限制或重新设计 |
+
+**示例**：
+```java
+// ❌ 违反 LSP：子类行为不一致
+public class Rectangle {
+    public void setWidth(int w) { width = w; }
+    public void setHeight(int h) { height = h; }
+}
+
+public class Square extends Rectangle {
+    @Override
+    public void setWidth(int w) {
+        width = w;
+        height = w;  // 强制宽高相等，行为不一致
+    }
+}
+
+// ✅ 符合 LSP：不使用继承，使用组合
+public class Shape { }
+public class Rectangle extends Shape { }
+public class Square extends Shape { }
+```
+
+---
+
+## I - Interface Segregation Principle (接口隔离原则)
+
+**定义**：客户端不应该依赖它不需要的接口
+
+| 检查项 | 问题信号 | 修复方案 |
+|--------|----------|----------|
+| 接口方法过多 | 接口方法数 > 10 | 拆分为多个接口 |
+| 实现类空方法 | 实现类有空方法体 | 拆分接口 |
+| 客户端只使用部分方法 | 客户端调用 < 50% 方法 | 拆分接口 |
+| 接口职责混杂 | 接口包含不同职责方法 | 拆分接口 |
+
+**示例**：
+```java
+// ❌ 违反 ISP：接口方法过多
+public interface Worker {
+    void work();
+    void eat();
+    void sleep();  // Robot 不需要 sleep
+}
+
+// ✅ 符合 ISP：接口拆分
+public interface Workable {
+    void work();
+}
+
+public interface Feedable {
+    void eat();
+}
+
+public class Human implements Workable, Feedable { }
+public class Robot implements Workable { }
+```
+
+---
+
+## D - Dependency Inversion Principle (依赖倒置原则)
+
+**定义**：高层模块不应该依赖低层模块，两者都应该依赖抽象
+
+| 检查项 | 问题信号 | 修复方案 |
+|--------|----------|----------|
+| 直接 new 对象 | Service 中 new Mapper() | 使用依赖注入 |
+| 依赖具体类 | 依赖具体实现类 | 依赖接口/抽象类 |
+| 硬编码依赖 | 依赖类型硬编码 | 使用配置/注入 |
+
+**示例**：
+```java
+// ❌ 违反 DIP：Service 直接依赖具体 Mapper
+public class OrderService {
+    private OrderMapper mapper = new OrderMapper();  // 直接 new
+}
+
+// ✅ 符合 DIP：依赖注入
+public class OrderServiceImpl implements OrderService {
+    private final OrderMapper mapper;  // 注入抽象
+    
+    public OrderServiceImpl(OrderMapper mapper) {
+        this.mapper = mapper;
+    }
+}
+```
+
+---
+
+## Anti-rationalization Table (Design)
+
+| 常见借口 | 反驳理由 | 正确做法 |
+|---------|---------|---------|
+| "先实现功能，设计文档以后补" | 无文档的设计无法维护 | 先设计后实现 |
+| "这个实体很简单，不需要设计" | 简单实体也会变复杂 | 完整设计 |
+| "状态流转很直观，不用画图" | 直观的流转也有边界情况 | 绘制状态图 |
+| "接口定义很清楚，不需要文档" | 清楚的定义也需要确认 | 编写API文档 |
+| "这个依赖关系很简单" | 简单依赖也会产生循环 | 分析依赖图 |
+| "SOLID检查太耗时" | 违反SOLID的代码更耗时维护 | 执行SOLID检查 |
+| "这个功能单体和微服务都一样" | 架构差异影响设计决策 | 明确架构类型 |
+| "这个类以后会扩展" | 未预留扩展点会导致修改 | 使用开闭原则 |
+
+---
+
+## Verification Gates
+
+| 门禁 | 检查方法 | 通过条件 | 失败处理 |
+|------|---------|---------|---------|
+| SRP检查 | 类职责分析 | 每个类职责单一 | 拆分类 |
+| OCP检查 | 扩展点分析 | 新功能无需修改现有代码 | 添加扩展点 |
+| LSP检查 | 子类行为测试 | 子类可替换父类 | 修复行为不一致 |
+| ISP检查 | 接口方法数 | 接口方法 <= 10 | 拆分接口 |
+| DIP检查 | 依赖分析 | 无直接 new 对象 | 使用依赖注入 |
+| 用户确认 | 设计文档评审 | 用户确认设计 | 修改设计 |