sdd-full 4.6.1 → 4.8.0

package/skills/rules/project_rules.md

@@ -1,78 +1,405 @@
-# 项目规则 - SDD全流程开发技能体系（团队共享）
+项目规则 - SDD全流程开发技能体系（团队共享）
 
-## 一、项目概述
+一、项目概述
 
 本项目是一个完整的SDD（Software Design Document）全流程开发技能包，包含从需求分析到发布运维的全流程技能，支持Trae和Claude Code双调用机制。
 
-## 二、核心流程规范
-
-### 2.1 新项目开发流程
-```
-需求收集 → 头脑风暴 → 市场调研 → PRD编写 → SDD拆分 → UI设计 → 代码设计 → 测试设计 → 开发 → 测试 → 质量检查 → 发布 → 复盘
-```
-
-### 2.2 Bug修复流程
-
-Bug修复流程为选项类型，根据Bug类型选择对应子流程：
-
-```
-1. 简单Bug修复 - 直接修复 → 验证 → 质量检查 → 经验沉淀
-2. 复杂Bug系统调试 - 复现确认 → 系统化调试 → 验证 → 质量检查 → 经验沉淀
-3. 性能问题修复 - 性能优化 → 验证 → 质量检查 → 经验沉淀
-4. 安全漏洞修复 - 安全审计 → 复现确认 → 系统化调试 → 验证 → 质量检查 → 安全复核 → 经验沉淀
-5. 回归Bug修复 - 复现确认 → 系统化调试 → 补充回归用例 → 修复 → 验证 → 质量检查 → 经验沉淀
-6. Flutter iOS真机调试 - 环境检查 → 复现确认 → Flutter专项调试 → 定位修复 → 真机验证 → 验证 → 质量检查 → 经验沉淀
-```
-
-### 2.3 小型功能迭代流程
-```
-需求澄清 → SDD快速拆分 → 开发 → 验证 → 质量检查 → 发布
-```
-
-## 三、技能使用规范
-
-### 3.1 技能分类与职责
-| 分类 | 技能 | 职责描述 |
-|------|------|---------|
-| 需求分析 | brainstorming, market-research, competitive-brief, prd-write, requirement-completion-officer, sdd, sdd-full | 需求收集、分析、拆分 |
-| 设计规划 | ui-sdd, ui-sdd-specialized, sdd-code, function-sdd, sdd-test, sdd-deploy, sdd-ops, writing-plans, ai-coding-rules, design-to-code, enterprise-spec, flutter-map, flutter-av | 设计方案制定 |
-| 开发执行 | sdd-add, test-driven-development, systematic-debugging, verification-before-completion, bug-reproduction-confirm, performance-optimize, flutter-errors | 代码实现 |
-| 质量保障 | quality-gate, security-audit, bdd-acceptance, flutter-test | 质量把关 |
-| 发布运维 | finishing-a-development-branch, release-flow | 发布管理 |
-| 知识沉淀 | claudeception, mempalace-auto-saver | 经验积累 |
-| 专项工具 | using-superpowers, requesting-code-review, receiving-code-review, env-check | 辅助工具 |
-
-### 3.2 强制使用技能
-- ✅ **所有发布前必须通过 quality-gate**
-- ✅ **所有需求必须经过 sdd/sdd-full 拆分**
-- ✅ **所有Bug修复根据类型选择对应流程：简单Bug直接修复，复杂Bug走bug-reproduction-confirm → systematic-debugging，性能问题走performance-optimize，安全漏洞走security-audit，回归Bug需补充Test-SDD，Flutter iOS真机调试走env-check → flutter-errors**
-- ✅ **所有性能问题必须经过 performance-optimize**
-- ✅ **发布后必须进行 claudeception 经验沉淀**
-
-## 四、文档规范
-
-### 4.1 SDD模板规范
+核心逻辑：以SDD全流程为唯一主线，Figma Make不脱离SDD规范，仅负责UI布局、视觉风格、全量App UI产出，融入ui-motion-interaction-standard技能规范动效交互、enterprise-spec（企业级全栈工程规范SDD）统一定制全流程标准，所有UI相关需求均来自SDD定义，流程各节点严格对应真实技能，不新增任何虚构技能、不遗漏核心技能。
+
+二、核心流程规范
+
+2.1 完整SDD+Figma Make闭环流程（含ui-motion-interaction-standard+enterprise-spec）
+
+# 阶段1：需求分析（SDD启动，对应需求分析类技能）
+market-research（市场调研） → competitive-brief（竞品分析） → brainstorming（头脑风暴）
+→ prd-write（生成PRD） → requirement-completion-officer（需求补全） → sdd（需求拆分，明确用户故事、前后端需求，作为全流程唯一真源头）
+→ sdd-full（全流程入口，确定流程方案） → enterprise-spec（企业级全栈工程规范SDD，同步输出全流程基础规范，指导后续各阶段）
+
+# 阶段2：设计规划（SDD主导，Figma Make准备，对应设计规划类技能）
+sdd（需求拆分输出UI、前后端相关需求，贴合enterprise-spec规范，SDD为唯一依据） → ui-sdd（UI交互SDD，输出交互/流程/动效规范，给Figma Make提供依据，遵循enterprise-spec）
+→ ui-motion-interaction-standard（UI动效交互标准，规范Figma Make动效设计，补充动效交互依据，符合enterprise-spec统一标准）
+→ ui-sdd-specialized（复杂UI场景规范，辅助Figma Make，遵循enterprise-spec） → function-sdd（单一功能SDD，补充UI、前后端功能依据，贴合enterprise-spec）
+→ writing-plans（制定计划，含Figma Make执行计划、各类全自动测试计划，遵循enterprise-spec流程规范，明确测试与SDD校验要求） → enterprise-spec（二次校准，确保设计规划全环节符合企业级全栈工程规范）
+
+# 阶段3：Figma Make执行（仅负责UI布局风格，不越权）
+基于 enterprise-spec + ui-sdd + ui-motion-interaction-standard + ui-sdd-specialized + function-sdd 输出的规范，生成：
+App桌面图标、闪屏页、全局Icon库、所有业务页面UI、弹窗/动效布局（动效符合ui-motion-interaction-standard标准，整体符合enterprise-spec规范，严格对齐SDD要求）
+
+# 阶段4：设计转开发+后端开发（衔接Figma Make与开发，同步推进前后端）
+# 前端开发分支
+design-to-code（Figma UI转前端代码，同步还原ui-motion-interaction-standard规范的动效，遵循enterprise-spec编码标准，对齐SDD） → flutter-apply-architecture-best-practices（Flutter架构适配，贴合enterprise-spec企业级架构规范）
+→ flutter-build-responsive-layout（响应式布局适配，符合enterprise-spec多端适配标准） → flutter-setup-declarative-routing（页面导航配置，遵循enterprise-spec路由规范）
+→ flutter-implement-json-serialization（数据模型转换，支撑UI渲染，符合enterprise-spec数据规范，对齐SDD数据定义）
+# 后端开发分支
+sdd-code（后端功能实现SDD拆分，按架构特性适配，定义代码规范，严格遵循SDD需求，作为后端开发唯一依据） → 后端代码实现（贴合enterprise-spec接口规范，对齐SDD接口定义）
+
+# 阶段5：开发执行+四类全自动测试流程（所有需求添加流程必走，SDD为唯一真源头）
+test-driven-development（TDD开发，遵循enterprise-spec开发规范，严格对齐SDD） → flutter-use-http-package（前端网络请求开发，对接后端接口，符合enterprise-spec接口规范，对齐SDD）
+→ flutter-fix-layout-issues（修复UI布局问题，含ui-motion-interaction-standard相关动效布局问题，修复后符合enterprise-spec，同步校验与SDD一致性） → systematic-debugging（调试，含UI、动效、前后端Bug，调试流程遵循enterprise-spec，确保与SDD一致）
+→ bug-reproduction-confirm（Bug验证，含各类Bug，验证标准贴合enterprise-spec，对齐SDD验收要求） → performance-optimize（UI+代码+动效+后端性能优化，贴合ui-motion-interaction-standard，符合enterprise-spec性能标准）
+→ flutter-errors（Flutter专项错误处理，含UI转码、动效实现错误，处理方案遵循enterprise-spec，确保与SDD一致）
+
+# 阶段6：质量保障（衔接全自动测试与SDD校验）
+flutter-test（补充各类全自动测试未覆盖场景，确保测试全面性，遵循enterprise-spec测试标准，同步校验与SDD一致性） → bdd-acceptance（结合全自动测试结果，完成UI交互+动效+用户故事验收，贴合enterprise-spec验收规范，对齐SDD） → security-audit（后端安全审计，符合enterprise-spec安全标准，对齐SDD安全要求）
+→ quality-gate（质量门禁，校验全自动测试通过率、UI还原度、动效合规性、SDD一致性，符合ui-motion-interaction-standard和enterprise-spec全流程规范，不合格则返回开发阶段复改+重新走Bug修复+前置检查+测试流程）
+
+# 阶段7：发布运维（全程以SDD为唯一真源头）
+release-flow（发布流程管理，同步归档全自动测试报告、SDD校验报告，负责版本规划、风险评估、发布验证、复盘总结，确保发布顺利，含UI、动效、前后端相关版本管理，遵循enterprise-spec发布规范，确保发布版本与SDD一致）
+→ finishing-a-development-branch（开发分支完成，负责代码合并、分支清理，同步留存全自动测试相关文档、SDD文档，规范分支管理流程，含所有代码分支管理，符合enterprise-spec分支管理标准，确保分支代码与SDD一致）
+
+2.2 四类全自动测试流程（所有需求添加流程必走，按场景执行）
+
+序号
+
+测试类型
+
+技能支撑
+
+测试内容
+
+触发时机
+
+1
+
+前端UI全量测试
+
+flutter-test
+
+Widget测试、E2E测试、UI布局校验、动效验证（贴合ui-motion-interaction-standard）
+
+前端开发完成后
+
+2
+
+用户故事流程测试
+
+bdd-acceptance
+
+基于SDD定义的用户故事验证功能是否符合业务预期
+
+功能开发完成后
+
+3
+
+后端全量测试
+
+security-audit、flutter-test
+
+接口校验、数据处理、安全审计（符合enterprise-spec）
+
+后端开发完成后
+
+4
+
+Bug修复流程
+
+bug-reproduction-confirm、systematic-debugging
+
+前置检查、Bug复现、修复验证
+
+测试不通过时
+
+2.3 Bug修复流程（含前置检查）
+
+测试不通过 → 【Bug修复前置检查】
+    → env-check（环境检测，校验开发/测试环境配置、依赖是否正常，排查环境类Bug诱因）
+    → 包兼容性检查（校验前后端包版本、依赖包兼容性，排查兼容性类Bug诱因）
+    → bug-reproduction-confirm（结合前置检查结果复现Bug，定位根因）
+    → systematic-debugging（Bug修复，修复后同步校验环境及包兼容性）
+    → 选择对应测试流程（UI/用户故事/后端测试）重新验证
+测试通过 → 进入SDD校验环节
+
+2.4 SDD校验环节（所有代码流程最后必走）
+
+校验内容：
+1. 前端代码与SDD一致性
+2. 后端代码与SDD一致性
+3. UI实现与SDD一致性
+4. 动效效果与SDD一致性
+
+若不一致 → 返回对应开发/设计环节修改 → 重新执行测试流程 → 再次SDD校验
+若一致 → verification-before-completion（完成前验证，结合四类全自动测试报告+SDD校验结果，含UI还原度、动效合规性、测试通过率、SDD一致性校验，整体符合enterprise-spec验收规范）→ 进入质量门禁
+
+三、功能添加流程（按分类细分，所有功能添加必走，无缝衔接主流程）
+
+核心原则：无论何种分类的功能添加，均以SDD为唯一真源头，所有环节、所有修改均需对齐SDD，enterprise-spec全程提供规范指导，不偏离主流程核心逻辑。
+
+3.1 功能分类定义（3大类，覆盖常见场景）
+
+1.  基础功能（核心必备类）：App基础运行所需功能（如登录、注册、基础页面导航），无复杂UI/动效，前后端逻辑简单
+2.  业务功能（核心业务类）：承载核心业务场景的功能（如交易、数据统计、业务流程审批），含常规UI/动效，前后端逻辑复杂
+3.  优化类功能（迭代升级类）：对现有功能的迭代优化、体验提升（如UI样式优化、性能优化、交互优化），无需完整走全流程，聚焦优化点
+
+3.2 基础功能添加流程（专属简化流程，核心不遗漏）
+
+1.  需求启动与SDD拆分（衔接主流程阶段1，需求分析类技能）
+    brainstorming（明确基础功能核心诉求） → requirement-completion-officer（需求补全，明确验收标准）
+    → sdd（拆分简单前后端、UI需求，输出专属SDD） → sdd-full（选择基础功能流程）
+
+2.  功能设计规划（简化，衔接主流程阶段2，设计规划类技能）
+    ui-sdd（基础UI交互规范） → function-sdd（细化实现标准） → writing-plans（简易计划） → enterprise-spec（输出简化规范）
+
+3.  UI实现（简化，衔接主流程阶段3，设计规划类技能）
+    design-to-code（Figma UI转前端代码） → 基于 enterprise-spec + ui-sdd + function-sdd，生成简易UI、基础弹窗（无复杂动效，对齐SDD）
+
+4.  前后端开发（简化，衔接主流程阶段4，Flutter专项/设计规划类技能）
+    # 前端：flutter-build-responsive-layout → flutter-use-http-package（贴合SDD）
+    # 后端：sdd-code（拆分） → 基础接口、数据处理开发（对齐SDD）
+
+5.  开发执行与测试（简化，衔接主流程阶段5，开发执行类技能）
+    systematic-debugging → bug-reproduction-confirm
+    # 简化测试：前端UI简易测试（flutter-test）、后端基础测试（security-audit）、Bug修复流程（含env-check前置检查）
+
+6.  SDD校验（必走，开发执行类技能）：校验前后端代码、UI与SDD一致 → verification-before-completion
+
+7.  质量门禁与发布（简化，衔接主流程阶段6、7，质量保障/发布运维类技能）
+    quality-gate → release-flow（归档文档） → finishing-a-development-branch（分支清理） → claudeception（经验沉淀）
+
+3.3 业务功能添加流程（完整流程，贴合主流程）
+
+1.  需求启动与SDD拆分（衔接主流程阶段1，需求分析类技能）
+    market-research → competitive-brief → brainstorming → prd-write → requirement-completion-officer
+    → sdd（拆分详细需求，输出专属SDD） → sdd-full（选择业务功能流程）
+
+2.  功能设计规划（衔接主流程阶段2，设计规划类技能）
+    ui-sdd → ui-motion-interaction-standard → ui-sdd-specialized（按需） → function-sdd
+    → writing-plans（详细计划） → enterprise-spec（完整规范，二次校准）
+
+3.  UI实现（衔接主流程阶段3，设计规划类技能）
+    design-to-code（Figma UI转前端代码，还原动效） → 基于 enterprise-spec + 各类UI规范，生成完整业务UI、复杂动效（对齐SDD及规范）
+
+4.  前后端开发（衔接主流程阶段4，Flutter专项/设计规划类技能）
+    # 前端：flutter-apply-architecture-best-practices → flutter-build-responsive-layout → flutter-setup-declarative-routing → flutter-implement-json-serialization → flutter-use-http-package
+    # 后端：sdd-code（详细拆分） → 业务接口、复杂数据处理开发（贴合SDD）
+
+5.  开发执行与测试（衔接主流程阶段5，开发执行类技能）
+    test-driven-development → flutter-fix-layout-issues → systematic-debugging → bug-reproduction-confirm → performance-optimize → flutter-errors
+    # 完整四类全自动测试（按场景执行，含Bug修复前置检查env-check）
+
+6.  SDD校验（必走，开发执行类技能）：全面校验前后端、UI、动效与SDD一致 → verification-before-completion
+
+7.  质量门禁与发布（衔接主流程阶段6、7，质量保障/发布运维类技能）
+    flutter-test → bdd-acceptance → security-audit → quality-gate → release-flow（归档报告） → finishing-a-development-branch → claudeception（经验沉淀）
+
+3.4 优化类功能添加流程（聚焦优化点，简化非必要环节）
+
+1.  需求启动与SDD更新（衔接主流程阶段1，需求分析类技能）
+    brainstorming（明确优化点） → requirement-completion-officer（补全需求）
+    → sdd（更新原有SDD，输出优化专属SDD） → sdd-full（选择优化流程）
+
+2.  优化设计规划（简化，衔接主流程阶段2，设计规划类技能）
+    ui-sdd（按需）/ui-motion-interaction-standard（按需） → function-sdd（细化优化标准） → writing-plans（优化计划） → enterprise-spec（优化规范）
+
+3.  优化实现（衔接主流程阶段3、4，设计规划/Flutter专项类技能）
+    # UI优化（按需）：design-to-code（仅修改优化涉及部分，贴合SDD）
+    # 前后端优化：针对性修改代码，严格对齐SDD及enterprise-spec
+
+4.  开发执行与测试（聚焦优化点，衔接主流程阶段5，开发执行类技能）
+    systematic-debugging → performance-optimize
+    # 针对性测试：优化点UI/动效测试、功能测试，Bug修复流程（含env-check前置检查）
+
+5.  SDD校验（必走，开发执行类技能）：校验修改部分与SDD一致，不破坏原有功能 → verification-before-completion
+
+6.  质量门禁与发布（简化，衔接主流程阶段6、7，质量保障/发布运维类技能）
+    quality-gate → release-flow（归档SDD更新文档） → finishing-a-development-branch → claudeception（经验沉淀）
+
+3.5 流程闭环总结
+
+# 正常闭环
+各类功能添加均遵循：需求分析类技能（SDD拆分/更新） → 设计规划类技能（对应分类专属设计规划） → Flutter专项类技能（针对性实现） → 开发执行类技能（适配分类的全自动测试，含Bug修复前置检查env-check） → 测试通过 → verification-before-completion → 质量保障类技能（质量门禁） → 发布运维类技能（发布） → claudeception（经验沉淀）
+
+# 异常闭环
+测试不通过 / 质量门禁不合格 → Bug修复前置检查（env-check+包兼容性检查，专项工具类技能） → systematic-debugging（Bug修复，开发执行类技能） → 重新测试 → SDD校验 → 直至通过后进入发布环节
+
+四、流程场景参数
+
+场景编号
+
+流程场景
+
+说明
+
+适用技能
+
+1
+
+完整3阶段SDD流程
+
+大型项目，需要完整的SDD全流程
+
+sdd-full, enterprise-spec, ui-sdd, sdd-code
+
+2
+
+从零开始新项目
+
+新项目立项，需要创意、调研、PRD
+
+brainstorming, market-research, competitive-brief, prd-write, sdd-full
+
+3
+
+小型功能迭代
+
+快速迭代，小功能开发
+
+sdd-add, requirement-completion-officer
+
+4
+
+Bug处理
+
+Bug修复，调试问题
+
+bug-reproduction-confirm, systematic-debugging, env-check
+
+5
+
+代码发布
+
+版本发布，质量检查
+
+quality-gate, release-flow, finishing-a-development-branch
+
+五、技能使用规范
+
+5.1 技能分类与职责
+
+分类
+
+技能
+
+职责描述
+
+适用阶段
+
+需求分析
+
+brainstorming, market-research, competitive-brief, prd-write, requirement-completion-officer, sdd, sdd-full
+
+需求收集、分析、拆分
+
+阶段1
+
+设计规划
+
+ui-sdd, ui-sdd-specialized, ui-motion-interaction-standard, function-sdd, sdd-code, writing-plans, enterprise-spec, design-to-code
+
+设计方案制定、动效规范
+
+阶段2
+
+开发执行
+
+sdd-add, test-driven-development, systematic-debugging, verification-before-completion, bug-reproduction-confirm, performance-optimize, flutter-errors
+
+代码实现、调试
+
+阶段5
+
+Flutter专项
+
+flutter-apply-architecture-best-practices, flutter-build-responsive-layout, flutter-setup-declarative-routing, flutter-implement-json-serialization, flutter-use-http-package, flutter-fix-layout-issues
+
+Flutter开发支持
+
+阶段4-5
+
+质量保障
+
+quality-gate, security-audit, bdd-acceptance, flutter-test
+
+质量把关、测试验收
+
+阶段6
+
+发布运维
+
+finishing-a-development-branch, release-flow
+
+发布管理
+
+阶段7
+
+知识沉淀
+
+claudeception, mempalace-auto-saver
+
+经验积累
+
+发布后
+
+专项工具
+
+requesting-code-review, receiving-code-review, env-check, ios-full-auto-debug
+
+辅助工具
+
+全流程
+
+5.2 强制使用技能
+
+- ✅ 所有发布前必须通过 quality-gate
+
+- ✅ 所有需求必须经过 sdd/sdd-full 拆分
+
+- ✅ 所有代码流程最后必走SDD校验，保证代码与SDD一致
+
+- ✅ 所有需求添加流程必走四类全自动测试
+
+- ✅ Bug修复必须经过前置检查（env-check+包兼容性检查）
+
+- ✅ 所有性能问题必须经过 performance-optimize
+
+- ✅ 发布后必须进行 claudeception 经验沉淀
+
+- ✅ UI动效必须符合 ui-motion-interaction-standard 标准
+
+- ✅ 全流程必须遵循 enterprise-spec 企业级规范
+
+5.3 技能调用优先级
+
+1. 高优先级（必须调用）：sdd/sdd-full, enterprise-spec, quality-gate, claudeception
+
+2. 中优先级（按场景调用）：ui-sdd, sdd-code, design-to-code, flutter-test, bdd-acceptance
+
+3. 低优先级（按需调用）：其余技能根据实际需求选择
+
+六、文档规范
+
+6.1 SDD模板规范
+
 项目使用11种标准化SDD模板：
-1. **Base-SDD** - 全局通用基线规范
-2. **Brain-SDD** - 头脑风暴文档
-3. **Competitor-SDD** - 竞品分析文档
-4. **PRD-SDD** - 产品需求文档
-5. **UI-SDD** - UI设计文档
-6. **Code-SDD** - 代码实现文档
-7. **API-SDD** - 接口设计文档
-8. **Env-SDD** - 环境配置文档
-9. **Test-SDD** - 测试设计文档
-10. **Performance-SDD** - 性能优化文档
-11. **BugReproduction-SDD** - Bug复现确认文档
-
-### 4.2 文档命名规范
-```
+
+1. Base-SDD - 全局通用基线规范
+
+2. Brain-SDD - 头脑风暴文档
+
+3. Competitor-SDD - 竞品分析文档
+
+4. PRD-SDD - 产品需求文档
+
+5. UI-SDD - UI设计文档
+
+6. Code-SDD - 代码实现文档
+
+7. API-SDD - 接口设计文档
+
+8. Env-SDD - 环境配置文档
+
+9. Test-SDD - 测试设计文档
+
+10. Performance-SDD - 性能优化文档
+
+11. BugReproduction-SDD - Bug复现确认文档
+
+6.2 文档命名规范
+
 {项目名称}-{模板名称}-{版本}.md
 示例：个人备忘录APP-Base-SDD-v1.0.md
-```
 
-### 4.3 文档归档规范（全局统一约定）
-```
+6.3 文档归档规范（全局统一约定）
+
 项目根目录/
 ├── brainstorm.md             # 原始需求
 ├── docs/
@@ -103,106 +430,190 @@ Bug修复流程为选项类型，根据Bug类型选择对应子流程：
     │   ├── security/
     │   └── data/
     └── refactor-plans/       # 重构计划
-```
 
-### 4.4 产出目录一致性说明
-| 技能 | UI产出 | 技术债务产出 |
-|------|--------|-------------|
-| `sdd` | `docs/ui/pages.md` | — |
-| `sdd-full` | `docs/ui/design.md` + `specs/ui/` | `docs/tech-debt/` |
-| `ui-sdd` | `specs/ui/` + `docs/ui/` | — |
-| `sdd-add` | — | `docs/tech-debt/`（统一目录格式） |
-| `sdd-code` | — | `docs/tech-debt/` |
+6.4 产出目录一致性说明
+
+技能
+
+UI产出
+
+技术债务产出
+
+sdd
+
+docs/ui/pages.md
+
+—
+
+sdd-full
+
+docs/ui/design.md + specs/ui/
+
+docs/tech-debt/
+
+ui-sdd
+
+specs/ui/ + docs/ui/
+
+—
+
+sdd-add
+
+—
+
+docs/tech-debt/（统一目录格式）
+
+sdd-code
 
-## 五、质量标准
+—
+
+docs/tech-debt/
+
+design-to-code
+
+docs/ui/ + 前端代码
+
+—
+
+七、质量标准
+
+7.1 代码质量标准
 
-### 5.1 代码质量标准
 - 单元测试覆盖率 ≥ 80%
+
 - 代码审查必须通过
+
 - 无 P0/P1 级别 Bug
 
-### 5.2 文档质量标准
+- 符合 enterprise-spec 编码标准
+
+7.2 文档质量标准
+
 - 所有SDD模板必须完整填写
+
 - 文档版本管理规范
+
 - 文档与代码同步更新
 
-### 5.3 发布标准
+- 动效符合 ui-motion-interaction-standard
+
+7.3 发布标准
+
 - 所有测试用例通过
+
 - quality-gate 检查通过
+
 - security-audit 无高危漏洞
 
-## 六、协作规范
+- SDD校验通过（代码与SDD一致）
+
+八、协作规范
+
+8.1 分支管理
+
+- main - 主分支，稳定版本
+
+- develop - 开发分支
+
+- feature/* - 功能分支
+
+- bugfix/* - Bug修复分支
+
+- release/* - 发布分支
 
-### 6.1 分支管理
-- `main` - 主分支，稳定版本
-- `develop` - 开发分支
-- `feature/*` - 功能分支
-- `bugfix/*` - Bug修复分支
-- `release/*` - 发布分支
+8.2 代码审查流程
 
-### 6.2 代码审查流程
 1. 功能开发完成后提交 PR
+
 2. 触发 requesting-code-review
+
 3. 审查通过后触发 receiving-code-review
+
 4. 合并到 develop 分支
 
-### 6.3 沟通规范
+8.3 沟通规范
+
 - 使用明确的技能触发关键词
+
 - 及时更新状态
+
 - 遇到问题及时反馈
 
-## 七、调用机制规范
+九、调用机制规范
+
+9.1 Trae调用格式
 
-### 7.1 Trae调用格式
-```
 trae调用 模板名称 项目名称=XXX 阶段=XXX 流程场景=XXX
-```
 
-### 7.2 Claude Code调用格式
-```
+9.2 Claude Code调用格式
+
 调用 技能名称 参数
-```
-
-### 7.3 流程场景参数
-| 参数值 | 说明 |
-|--------|------|
-| 完整3阶段SDD流程 | 大型项目完整流程 |
-| 从零开始新项目 | 新项目立项 |
-| 小型功能迭代 | 快速迭代 |
-| Bug处理 | Bug修复 |
-| 代码发布 | 版本发布 |
-
-## 八、工具与环境
-
-### 8.1 推荐工具
-- **Figma** - UI设计
-- **GitHub** - 代码托管
-- **Trae** - 技能调用
-- **Claude Code** - AI协作
-
-### 8.2 环境要求
+
+9.3 快捷调用示例
+
+场景
+
+调用示例
+
+小型功能迭代
+
+调用 sdd-add 功能名称=用户登录 流程场景=小型功能迭代
+
+Bug修复
+
+调用 bug-reproduction-confirm Bug描述=登录失败
+
+质量检查
+
+调用 quality-gate 项目名称=电商平台
+
+发布流程
+
+调用 release-flow 版本号=v1.0.0
+
+十、工具与环境
+
+10.1 推荐工具
+
+- Figma - UI设计
+
+- GitHub - 代码托管
+
+- Trae - 技能调用
+
+- Claude Code - AI协作
+
+10.2 环境要求
+
 - Node.js ≥ 18.x
+
 - npm ≥ 9.x
-- sdd-full ≥ 2.2.0
 
-## 九、版本管理
+- sdd-full ≥ 4.7.0
+
+十一、版本管理
+
+11.1 版本命名规范
 
-### 9.1 版本命名规范
-```
 v{主版本}.{次版本}.{修订版本}
-示例：v2.2.0
-```
+示例：v4.7.0
+
+11.2 版本发布流程
 
-### 9.2 版本发布流程
 1. 完成功能开发与测试
+
 2. 更新版本号
+
 3. 通过 quality-gate
+
 4. 执行 release-flow
+
 5. 发布到 npm
 
----
+版本: v3.0
+
+更新时间: 2026-05-08
+
+适用项目: sdd-full-npm
 
-**版本**: v1.0  
-**更新时间**: 2026-05-06  
-**适用项目**: sdd-full-npm  
-**团队**: SDD开发团队
+团队: SDD开发团队