cc-devflow 4.2.0 → 4.4.1

package/.claude/docs/templates/ATTEMPT_TEMPLATE.md

@@ -1,156 +0,0 @@
-# Research Attempt Template
-
-> 本模板用于记录研究阶段的失败尝试。失败是学习数据，记录下来避免重复错误。
-
----
-
-## 文件命名规范
-
-```
-research/attempts/NNN-descriptive-name.md
-```
-
-**示例**:
-- `001-graphql-approach.md` - 尝试 GraphQL，因性能问题放弃
-- `002-rest-pagination.md` - 尝试偏移分页，改用游标分页
-- `003-redis-cache.md` - 尝试 Redis 缓存，因成本放弃
-
----
-
-## 模板内容
-
-```markdown
-# Attempt: [方案名]
-
-**Date**: YYYY-MM-DD
-**Context**: 解决 [什么问题]
-
-## Approach
-
-[描述尝试的方案]
-
-## Result
-
-❌ 失败 / ⚠️ 部分成功 / 🔄 放弃
-
-## Reason
-
-[为什么不行]
-
-## Learning
-
-[下次应该注意什么]
-
-## References
-
-- [相关文档链接]
-- [相关代码片段]
-```
-
----
-
-## 示例 1: 放弃 GraphQL
-
-```markdown
-# Attempt: GraphQL API Architecture
-
-**Date**: 2026-01-08
-**Context**: 解决前后端 API 通信，考虑使用 GraphQL 代替 REST
-
-## Approach
-
-使用 Apollo Server + GraphQL Schema 定义 API：
-- 单一端点 /graphql
-- 客户端按需查询字段
-- 减少 over-fetching 和 under-fetching
-
-## Result
-
-🔄 放弃
-
-## Reason
-
-1. **学习曲线**: 团队对 GraphQL 不熟悉，估计学习时间 2 周
-2. **工具链复杂**: 需要 Apollo Client, Codegen, Schema Stitching
-3. **Overkill**: 当前需求只有 5 个简单 CRUD 端点，REST 足够
-4. **成本**: GraphQL 服务器性能优化成本高（N+1 查询问题）
-
-## Learning
-
-- **YAGNI**: GraphQL 解决的问题（灵活查询、版本管理）当前不存在
-- **下次应该**: 先用 REST，等到真正需要灵活查询时再迁移
-- **决策原则**: 技术选型看当前需求，不为未来需求过度设计
-
-## References
-
-- [Apollo Server 官方文档](https://www.apollographql.com/docs/apollo-server/)
-- [GraphQL N+1 问题分析](https://example.com/graphql-n-plus-1)
-```
-
----
-
-## 示例 2: 偏移分页改用游标分页
-
-```markdown
-# Attempt: Offset-based Pagination
-
-**Date**: 2026-01-08
-**Context**: 实现用户列表分页，最初选择偏移分页（offset/limit）
-
-## Approach
-
-使用 SQL OFFSET/LIMIT:
-```sql
-SELECT * FROM users
-ORDER BY created_at DESC
-LIMIT 20 OFFSET 40
-```
-
-## Result
-
-⚠️ 部分成功（实现了但性能差）
-
-## Reason
-
-1. **性能问题**: OFFSET 40000 时查询时间 >2 秒（需扫描前 40000 行）
-2. **数据不一致**: 翻页时有新数据插入，导致重复或遗漏
-3. **数据库负载**: 大 OFFSET 导致 CPU 使用率飙升
-
-## Learning
-
-- **游标分页更适合**: 使用 `WHERE id > last_id` 替代 OFFSET
-- **性能对比**: 游标分页查询时间稳定在 50ms，与页数无关
-- **决策**: 对于大数据集，始终用游标分页
-
-## References
-
-- [PostgreSQL OFFSET Performance](https://example.com/postgres-offset)
-- [Cursor-based Pagination Best Practices](https://example.com/cursor-pagination)
-```
-
----
-
-## 何时记录尝试
-
-| 情况 | 是否记录 |
-|------|---------|
-| 方案调研后决定不采用 | ✅ 记录 |
-| 实现了但发现性能问题，放弃 | ✅ 记录 |
-| 简单方案 A vs B 对比，选 A | ❌ 不记录（在 research.md Decisions 记录即可） |
-| 重大架构决策放弃 | ✅ 记录 |
-| 技术选型放弃 | ✅ 记录 |
-
----
-
-## 与 ERROR_LOG.md 的区别
-
-| | research/attempts/ | ERROR_LOG.md |
-|--|-------------------|--------------|
-| 阶段 | 研究阶段（Phase 0） | 执行阶段（flow:dev, flow:verify） |
-| 内容 | 方案尝试与放弃 | 代码错误与修复 |
-| 格式 | Markdown 文件 | 结构化错误日志 |
-| 目的 | 避免重复研究 | 避免重复错误 |
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/docs/templates/BACKLOG_TEMPLATE.md

@@ -1,261 +0,0 @@
-# Product Backlog: {{PROJECT_NAME}}
-
-**Updated**: {{UPDATED_DATE}} 北京时间
-**Total Items**: {{TOTAL_COUNT}}
-**P1 Count**: {{P1_COUNT}} | **P2 Count**: {{P2_COUNT}} | **P3 Count**: {{P3_COUNT}}
-
-**Input**:
-- candidates 列表（包含 RM-ID, title, priority, derived_from, description）
-- dependencies 依赖关系
-- timeline 时间线分配
-
-**Prerequisites**: roadmap-planner agent 正在基于 core-roadmap 命令的上下文生成此文档
-
-## Execution Flow (Backlog 生成流程)
-```
-1. Load context from command
-   → Parse candidates array
-   → Parse dependencies array
-   → Parse timeline object
-   → Validate all fields present
-
-2. Load BACKLOG_TEMPLATE.md
-   → Read template from .claude/docs/templates/BACKLOG_TEMPLATE.md
-   → Prepare to fill all sections
-
-3. Group candidates by priority
-   → Separate into P1 (MVP Must-Have), P2 (Important), P3 (Nice-to-Have)
-   → Sort by RM-ID within each priority group
-   → Count items in each priority
-
-4. Generate Priority 1 section
-   → For each P1 candidate:
-      • Generate detailed entry with all fields
-      • Extract business value from description
-      • Estimate effort (S/M/L based on effort_weeks)
-      • Identify dependencies from dependencies array
-      • Extract derived_from source
-      • Assign target milestone from timeline
-      • Set status = "Backlog"
-
-5. Generate Priority 2 section
-   → Similar to P1 but for P2 candidates
-
-6. Generate Priority 3 section
-   → Similar to P1 but for P3 candidates
-
-7. Generate Dependency Matrix
-   → For each RM-ID:
-      • Find what it blocks (RM-IDs that depend on this)
-      • Find what blocks it (REQ-IDs or RM-IDs this depends on)
-   → Format as markdown table
-   → Use "-" for no dependencies
-
-8. Validate completeness
-   → All candidates included
-   → All have priority assigned
-   → Dependency matrix complete
-   → No {{PLACEHOLDER}} remaining
-   → If incomplete: ERROR "Complete missing sections"
-
-9. Write devflow/BACKLOG.md
-   → Write complete file
-   → Use UTF-8 encoding
-
-10. Return: SUCCESS (BACKLOG.md generated)
-```
-
-**重要**: 这是一个自执行模板。roadmap-planner agent 应该按照 Execution Flow 生成完整的 BACKLOG.md 文件。
-
----
-
-## Priority 1 (MVP Must-Have)
-
-_P1 是必须完成的核心功能，没有这些功能产品无法交付价值。_
-
-### {{RM_ID_1}}: {{TITLE_1}}
-
-- **Description**: {{DESCRIPTION_1}}
-- **Business Value**: {{BUSINESS_VALUE_1}}
-  _为什么这是 P1？为什么用户需要这个功能？_
-
-- **Effort**: {{EFFORT_1}} (S/M/L)
-  - S (Small): 1 周以内
-  - M (Medium): 1-3 周
-  - L (Large): 3 周以上
-
-- **Dependencies**: {{DEPENDENCIES_1}}
-  _此功能依赖哪些已有需求？格式: REQ-009 (completed), REQ-010 (in progress)_
-
-- **Derived From**: {{DERIVED_FROM_1}}
-  _来源：REQ-001, Tech Stack, User Feedback, etc._
-
-- **Target Milestone**: {{MILESTONE_1}}
-  _计划在哪个里程碑完成？格式: M1-Q1-2025_
-
-- **Status**: {{STATUS_1}}
-  _Backlog | Ready | In Progress | Blocked | Completed_
-
----
-
-### {{RM_ID_2}}: {{TITLE_2}}
-
-- **Description**: {{DESCRIPTION_2}}
-- **Business Value**: {{BUSINESS_VALUE_2}}
-- **Effort**: {{EFFORT_2}} (S/M/L)
-- **Dependencies**: {{DEPENDENCIES_2}}
-- **Derived From**: {{DERIVED_FROM_2}}
-- **Target Milestone**: {{MILESTONE_2}}
-- **Status**: {{STATUS_2}}
-
----
-
-_重复以上结构为每个 P1 需求创建条目_
-
----
-
-## Priority 2 (Important)
-
-_P2 是重要功能，能够显著提升用户体验或解决重要问题，但不影响 MVP 交付。_
-
-### {{RM_ID_3}}: {{TITLE_3}}
-
-- **Description**: {{DESCRIPTION_3}}
-- **Business Value**: {{BUSINESS_VALUE_3}}
-  _为什么这是 P2？相比 P1 的区别是什么？_
-
-- **Effort**: {{EFFORT_3}} (S/M/L)
-- **Dependencies**: {{DEPENDENCIES_3}}
-- **Derived From**: {{DERIVED_FROM_3}}
-- **Target Milestone**: {{MILESTONE_3}}
-- **Status**: {{STATUS_3}}
-
----
-
-_重复以上结构为每个 P2 需求创建条目_
-
----
-
-## Priority 3 (Nice-to-Have)
-
-_P3 是锦上添花的功能，有更好没有也不影响核心价值。_
-
-### {{RM_ID_4}}: {{TITLE_4}}
-
-- **Description**: {{DESCRIPTION_4}}
-- **Business Value**: {{BUSINESS_VALUE_4}}
-  _为什么这是 P3？什么情况下会提升到 P2 或 P1？_
-
-- **Effort**: {{EFFORT_4}} (S/M/L)
-- **Dependencies**: {{DEPENDENCIES_4}}
-- **Derived From**: {{DERIVED_FROM_4}}
-- **Target Milestone**: {{MILESTONE_4}}
-- **Status**: {{STATUS_4}}
-
----
-
-_重复以上结构为每个 P3 需求创建条目_
-
----
-
-## Dependency Matrix
-
-| RM-ID | Blocks | Blocked By |
-|-------|--------|------------|
-| {{RM_ID_1}} | {{BLOCKS_1}} | {{BLOCKED_BY_1}} |
-| {{RM_ID_2}} | {{BLOCKS_2}} | {{BLOCKED_BY_2}} |
-| {{RM_ID_3}} | {{BLOCKS_3}} | {{BLOCKED_BY_3}} |
-| {{RM_ID_4}} | {{BLOCKS_4}} | {{BLOCKED_BY_4}} |
-
-_填充规则:_
-- **Blocks**: 此需求完成后可以解锁的其他需求（逗号分隔）
-  - 例如: `RM-003, RM-005`
-  - 如果没有: `-`
-
-- **Blocked By**: 此需求依赖的其他需求（逗号分隔）
-  - 格式: `REQ-001 (completed)`, `REQ-010 (in progress)`, `RM-002 (backlog)`
-  - 如果没有: `-`
-
-_说明: 此矩阵用于快速识别需求间的依赖关系，避免优先级冲突_
-
----
-
-## Backlog Management Notes
-
-### 优先级调整指南
-
-**何时提升 P3 → P2**:
-- 用户强烈要求
-- 技术依赖需要（为了完成 P1/P2，需要先完成此功能）
-- 竞争压力（竞品已有类似功能）
-
-**何时提升 P2 → P1**:
-- 成为 MVP 的阻塞项
-- 影响核心用户体验
-- 安全或合规要求
-
-**何时降低优先级**:
-- 用户需求不明确
-- 技术复杂度过高，风险大
-- 有更好的替代方案
-
-### 准入标准 (Definition of Ready)
-
-一个 backlog item 准备好进入开发 (运行 /flow:init) 的标准：
-- [ ] Description 清晰明确
-- [ ] Business Value 已明确
-- [ ] Effort 已评估
-- [ ] Dependencies 已识别并满足（依赖的需求已完成）
-- [ ] Derived From 已标注
-- [ ] 已分配到具体的 Milestone
-- [ ] 用户已确认需求
-
-### 完成标准 (Definition of Done)
-
-一个 backlog item 被认为完成的标准：
-- [ ] 通过 /flow:init, /flow:spec, /flow:dev 流程
-- [ ] 所有 TASKS.md 中的任务完成
-- [ ] 通过 /flow:verify (测试 + 安全审查)
-- [ ] 代码已合并到主分支
-- [ ] 文档已更新
-- [ ] 用户验收通过
-
----
-
-## Appendix: Priority Guidelines
-
-### P1 (MVP Must-Have) - 优先级评估标准
-
-| 标准 | 说明 | 示例 |
-|------|------|------|
-| **核心价值** | 没有此功能产品无法交付核心价值 | 用户认证（没有认证就无法使用） |
-| **阻塞依赖** | 其他高优先级功能依赖此功能 | 权限管理（多个功能需要权限控制） |
-| **用户痛点** | 解决用户最迫切的问题 | 性能优化（启动慢导致用户流失） |
-| **合规要求** | 法律、安全、合规必须 | 数据加密（隐私合规要求） |
-
-### P2 (Important) - 优先级评估标准
-
-| 标准 | 说明 | 示例 |
-|------|------|------|
-| **体验提升** | 显著提升用户体验但不影响核心功能 | 输入框增强（Markdown 预览） |
-| **运营需求** | 支持运营、分析、监控 | 数据分析模块 |
-| **扩展性** | 为未来扩展打基础 | 多账号支持 |
-| **差异化** | 与竞品形成差异化 | AI 辅助功能 |
-
-### P3 (Nice-to-Have) - 优先级评估标准
-
-| 标准 | 说明 | 示例 |
-|------|------|------|
-| **锦上添花** | 有更好，没有也不影响 | 快捷键自定义 |
-| **小众需求** | 只有少数用户需要 | 高级配置项 |
-| **实验性** | 需要验证是否有价值 | 新 UI 风格 |
-| **技术优化** | 技术层面的优化，用户无感知 | 代码重构 |
-
----
-
-**生成说明**:
-1. 所有 `{{PLACEHOLDER}}` 必须被实际内容替换
-2. Business Value 应具体说明为什么这个功能重要
-3. Effort 估算基于历史 Velocity
-4. Dependency Matrix 应与 ROADMAP.md 保持一致
-5. 所有日期使用北京时间

package/.claude/docs/templates/BRAINSTORM_TEMPLATE.md

@@ -1,148 +0,0 @@
----
-req_id: "{REQ_ID}"
-title: "{TITLE}"
-created_at: "{ISO8601_TIMESTAMP}"
-brainstorm_version: "1.0"
-status: "draft"
----
-
-# {REQ_ID} Brainstorm Record
-
-> **[PROTOCOL]**: 后续所有开发必须与本文档保持一致。如有偏离，需更新本文档并说明原因。
-
-## 原始需求（用户原话）
-
-> {用户的原始描述，一字不改，保留所有细节}
-
-## 核心问题定义
-
-### 解决什么问题？
-
-{一句话定义核心问题，例如："用户无法在移动端完成支付"}
-
-### 为谁解决？
-
-{用户画像，例如："日均活跃用户 10,000+，年龄 25-45，移动端为主"}
-
-### 现状痛点
-
-- {痛点1：具体描述，包含数据或用户反馈}
-- {痛点2}
-- {痛点3}
-
-## 成功标准
-
-### 如何判断需求完成？（验收标准）
-
-- [ ] {可度量的标准1，例如："支付成功率 ≥ 95%"}
-- [ ] {可度量的标准2}
-- [ ] {可度量的标准3}
-
-### 如何判断需求成功？（业务指标）
-
-- {业务指标1，例如："订单转化率提升 10%"}
-- {业务指标2}
-
-## 约束条件
-
-| 类型 | 约束 | 原因 |
-|------|------|------|
-| 技术 | {约束，例如："必须兼容 iOS 12+"} | {原因} |
-| 时间 | {约束，例如："2 周内上线"} | {原因} |
-| 资源 | {约束，例如："1 前端 + 1 后端"} | {原因} |
-| 安全 | {约束，例如："敏感数据需加密"} | {原因} |
-| 法规 | {约束，例如："符合 GDPR"} | {原因} |
-
-## 方案探索
-
-### 方案 A: {名称} ⭐ 推荐
-
-**描述**:
-{方案概述，100-200 字}
-
-**优势**:
-- {优势1}
-- {优势2}
-
-**劣势**:
-- {劣势1}
-- {劣势2}
-
-**适用场景**:
-{何时选择这个方案}
-
-**实现要点**:
-1. {关键步骤1}
-2. {关键步骤2}
-
----
-
-### 方案 B: {名称}
-
-**描述**:
-{方案概述}
-
-**优势**:
-- {优势1}
-
-**劣势**:
-- {劣势1}
-
-**适用场景**:
-{何时选择这个方案}
-
----
-
-### 方案 C: {名称}
-
-**描述**:
-{方案概述}
-
-**优势**:
-- {优势1}
-
-**劣势**:
-- {劣势1}
-
-**适用场景**:
-{何时选择这个方案}
-
-## 最终决策
-
-**选定方案**: 方案 {X}
-
-**选择理由**:
-{为什么选这个方案，而非其他方案}
-
-**否决理由**:
-- 方案 {Y}: {为什么不选}
-- 方案 {Z}: {为什么不选}
-
-## 关键决策记录
-
-| 决策点 | 决策 | 理由 | 日期 |
-|--------|------|------|------|
-| {问题1} | {选择} | {为什么} | {YYYY-MM-DD} |
-| {问题2} | {选择} | {为什么} | {YYYY-MM-DD} |
-
-## 风险识别
-
-| 风险 | 概率 | 影响 | 缓解策略 |
-|------|------|------|----------|
-| {风险1} | 高/中/低 | 高/中/低 | {应对措施} |
-| {风险2} | 高/中/低 | 高/中/低 | {应对措施} |
-
-## 变更历史
-
-| 版本 | 日期 | 变更内容 | 变更原因 |
-|------|------|----------|----------|
-| 1.0 | {YYYY-MM-DD} | 初始版本 | 头脑风暴完成 |
-
----
-
-**⚠️ 追溯声明**:
-本文档是 {REQ_ID} 的「北极星」。后续 PRD、EPIC、TASKS、实现都必须与本文档保持一致。
-如发现偏离，必须：
-1. 确认偏离原因
-2. 更新本文档
-3. 记录变更历史

package/.claude/docs/templates/CHECKLIST_TEMPLATE.md

@@ -1,52 +0,0 @@
-# {{TYPE}} Checklist: {{REQ_ID}}
-
-**Purpose**: {{TYPE_DESCRIPTION}}
-**Created**: {{TIMESTAMP}}
-**PRD Reference**: PRD.md
-**Quality Dimensions**: Completeness, Clarity, Consistency, Measurability, Coverage
-
----
-
-## Requirement Completeness
-
-- [ ] CHK001 - Are all {{TYPE}} requirements documented in PRD? [Completeness, Spec §FR-XXX]
-- [ ] CHK002 - Are success criteria defined for {{TYPE}} features? [Completeness]
-- [ ] CHK003 - Are error handling scenarios specified? [Completeness, Gap]
-
-## Requirement Clarity
-
-- [ ] CHK004 - Is '{{VAGUE_TERM}}' quantified with specific metrics? [Clarity, Spec §NFR-XXX]
-- [ ] CHK005 - Are {{TYPE}} behaviors explicitly specified? [Clarity]
-- [ ] CHK006 - Are technical constraints clearly documented? [Clarity]
-
-## Requirement Consistency
-
-- [ ] CHK007 - Are {{TYPE}} requirements consistent across sections? [Consistency]
-- [ ] CHK008 - Are terminology and naming conventions consistent? [Consistency]
-- [ ] CHK009 - Are data formats consistent between requirements? [Consistency]
-
-## Acceptance Criteria Quality
-
-- [ ] CHK010 - Can {{TYPE}} requirements be objectively verified? [Measurability]
-- [ ] CHK011 - Are acceptance criteria in Given-When-Then format? [Measurability]
-- [ ] CHK012 - Are performance metrics quantified with specific numbers? [Measurability]
-
-## Scenario Coverage
-
-- [ ] CHK013 - Are edge cases defined for {{TYPE}} scenarios? [Coverage, Gap]
-- [ ] CHK014 - Are error states and recovery paths specified? [Coverage]
-- [ ] CHK015 - Are boundary conditions addressed? [Coverage]
-
----
-
-## Notes
-
-- Check items off as completed: change `[ ]` to `[x]`
-- Items are numbered sequentially (CHK001-CHKnnn)
-- Quality dimensions: [Completeness], [Clarity], [Consistency], [Measurability], [Coverage]
-- References:
-  - `[Spec §X.Y]` - Links to existing PRD requirement
-  - `[Gap]` - Missing requirement identified
-  - `[Ambiguity]` - Unclear requirement needs clarification
-  - `[Conflict]` - Requirement conflicts with another
-  - `[Assumption]` - Needs validation