cc-devflow 2.4.6 → 4.1.0

package/.claude/commands/flow-review.md

@@ -1,257 +0,0 @@
----
-name: flow-review
-description: 'Two-Stage Code Review. Usage: /flow-review "REQ-123" or /flow-review'
-agents:
-  spec: .claude/agents/spec-reviewer.md
-  quality: .claude/agents/code-reviewer.md
-skills:
-  verification: .claude/skills/verification-before-completion/SKILL.md
-  receiving: .claude/skills/flow-receiving-review/SKILL.md
----
-
-# Flow-Review - 两阶段代码审查
-
-## User Input
-
-```text
-$ARGUMENTS = "REQ_ID" 或 空 (自动检测当前分支)
-```
-
-**示例**:
-```
-/flow-review "REQ-123"
-/flow-review              # 自动从分支名提取 REQ-ID
-```
-
----
-
-## 核心理念
-
-### Two-Stage Review
-
-```
-Stage 1: SPEC COMPLIANCE (先)
-┌─────────────────────────────────────────┐
-│ • 加载 PRD, EPIC, TASKS, BRAINSTORM    │
-│ • 创建需求清单                         │
-│ • 逐项验证（不信任实现者报告）         │
-│ • 检查超范围（scope creep）            │
-│ • 输出: SPEC_REVIEW.md                 │
-└─────────────────────────────────────────┘
-              ↓ Pass?
-Stage 2: CODE QUALITY (后)
-┌─────────────────────────────────────────┐
-│ • 代码清晰度、结构、命名               │
-│ • 测试质量和覆盖率                     │
-│ • Constitution 合规                    │
-│ • 性能和安全                           │
-│ • 输出: CODE_QUALITY_REVIEW.md         │
-└─────────────────────────────────────────┘
-```
-
-**关键**: Stage 2 只在 Stage 1 通过后执行。
-
----
-
-## 执行流程
-
-### Stage 0: Entry Gate
-
-```yaml
-1. 解析 REQ_ID
-   → 从参数获取，或从分支名提取 (feature/REQ-123-xxx)
-
-2. 验证需求目录存在
-   → devflow/requirements/${REQ_ID}/
-
-3. 加载必需文档
-   → PRD.md, EPIC.md, TASKS.md, BRAINSTORM.md
-
-4. 检查实现状态
-   → TASKS.md 中所有任务标记为完成
-```
-
----
-
-### Stage 1: Spec Compliance Review
-
-**调用**: `{AGENT:spec}` (spec-reviewer)
-
-```yaml
-执行:
-  1. 构建需求清单
-     → 从 PRD 提取验收标准
-     → 从 TASKS 提取预期结果
-
-  2. 代码验证 (不信任报告)
-     → 读取实际代码
-     → 逐项验证实现
-     → 标记: ✅ 实现 | ❌ 缺失 | ⚠️ 部分 | 🚫 超范围
-
-  3. Scope Creep 检测
-     → 扫描未在规格中的功能
-     → 每个额外功能 = 缺陷
-
-  4. BRAINSTORM 对齐检查
-     → 是否解决原始问题
-     → 是否遵循选定方案
-
-输出: devflow/requirements/${REQ_ID}/SPEC_REVIEW.md
-```
-
-**通过条件**:
-- 所有需求项标记为 ✅
-- 无 Scope Creep (🚫)
-- BRAINSTORM 对齐
-
-**失败处理**:
-```yaml
-如果 Stage 1 失败:
-  → 输出 SPEC_REVIEW.md 包含失败项
-  → 列出必需修复项
-  → 停止，不进入 Stage 2
-  → 返回给开发者修复
-```
-
----
-
-### Stage 2: Code Quality Review
-
-**前置**: Stage 1 必须通过
-
-**调用**: `{AGENT:quality}` (code-reviewer)
-
-```yaml
-执行:
-  1. 代码清晰度
-     → 命名是否清晰
-     → 结构是否合理
-     → 注释是否必要且有用
-
-  2. 测试质量
-     → 覆盖率 ≥ 80%
-     → 测试是否有意义 (非 cheater tests)
-     → 边界情况是否覆盖
-
-  3. Constitution 合规
-     → Article I: 完整实现
-     → Article II: 无重复代码
-     → Article III: 无硬编码密钥
-     → Article IV: 无资源泄漏
-     → Article V: 无死代码
-     → Article VI: TDD 顺序
-
-  4. 性能和安全
-     → 无明显性能问题
-     → 无安全漏洞
-
-输出: devflow/requirements/${REQ_ID}/CODE_QUALITY_REVIEW.md
-```
-
----
-
-### Stage 3: Exit Gate
-
-```yaml
-验证:
-  1. SPEC_REVIEW.md 状态 = PASS
-  2. CODE_QUALITY_REVIEW.md 状态 = PASS
-  3. 所有阻塞问题已解决
-
-输出:
-  → 更新 orchestration_status.json
-  → 记录到 EXECUTION_LOG.md
-```
-
----
-
-## 输出产物
-
-```
-devflow/requirements/${REQ_ID}/
-├── SPEC_REVIEW.md           # Stage 1 输出
-├── CODE_QUALITY_REVIEW.md   # Stage 2 输出
-└── EXECUTION_LOG.md         # 更新
-```
-
----
-
-## 收到审查反馈后
-
-当收到审查反馈时，使用 `{SKILL:receiving}` 原则：
-
-```yaml
-处理反馈:
-  1. 不盲目同意
-     → 反馈可能有误
-     → 技术上可疑？先验证
-
-  2. 不清楚？提问澄清
-     → "这个建议的具体原因是什么？"
-     → "能否提供示例？"
-
-  3. 验证后再实现
-     → 确认建议正确
-     → 然后实施修改
-```
-
----
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "实现者说完成了" | 读代码验证。不信任报告。 |
-| "测试通过了" | 测试可能不覆盖所有需求。 |
-| "差不多就行" | 差不多 ≠ 正确。规格是契约。 |
-| "额外功能是好事" | 额外 = scope creep = 缺陷。 |
-| "Stage 1 太严格" | 严格是为了质量。不妥协。 |
-
----
-
-## 错误处理
-
-### Stage 1 失败
-
-```yaml
-输出:
-  - SPEC_REVIEW.md (包含失败项)
-  - 必需修复清单
-
-下一步:
-  - 开发者修复缺失/超范围项
-  - 重新运行 /flow-review
-```
-
-### Stage 2 失败
-
-```yaml
-输出:
-  - CODE_QUALITY_REVIEW.md (包含问题)
-  - 改进建议
-
-下一步:
-  - 开发者修复质量问题
-  - 重新运行 /flow-review
-```
-
----
-
-## Next Step
-
-```
-/flow-qa "${REQ_ID}"
-```
-
-进入 QA 测试阶段
-
----
-
-**Related Documentation**:
-- [spec-reviewer.md](../.claude/agents/spec-reviewer.md) - Stage 1 Agent
-- [code-reviewer.md](../.claude/agents/code-reviewer.md) - Stage 2 Agent
-- [verification-before-completion](../.claude/skills/verification-before-completion/SKILL.md) - 验证技能
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/commands/flow-tech.md

@@ -1,142 +0,0 @@
----
-name: flow-tech
-description: 'Generate Technical Design package. Usage: /flow-tech "REQ-123" or /flow-tech'
-scripts:
-  prereq: .claude/scripts/check-prerequisites.sh
-  tech_analysis: .claude/scripts/generate-tech-analysis.sh
-  extract_data_model: .claude/scripts/extract-data-model.sh
-  export_contracts: .claude/scripts/export-contracts.sh
-  quickstart: .claude/scripts/generate-quickstart.sh
-agent_scripts:
-  sh: .claude/scripts/update-agent-context.sh __AGENT__
-  ps: scripts/powershell/update-agent-context.ps1 -AgentType __AGENT__
----
-
-# Flow-Tech - 技术方案生成命令
-
-## User Input
-```text
-$ARGUMENTS = "REQ_ID"
-```
-若缺省则从当前分支或 `DEVFLOW_REQ_ID` 推断；进入流程前必须解析成功。
-
-## 命令格式
-```text
-/flow-tech "REQ_ID"
-/flow-tech             # Auto-detect from current branch
-```
-
-### 参数说明
-- **REQ_ID**: 需求编号 (可选，默认从当前 Git 分支或环境变量获取)
-
-## 执行流程
-
-### 阶段 0: Anti-Tech-Creep Gate
-- 读取 `CLAUDE.md` 的技术架构章节并对照 `research/internal/codebase-overview.md`。
-- 若缺失或与现状不符：重写 ≤15 行的架构摘要并记录核心原则。
-- 触发约束：除非在技术方案中明确说明，禁止引入新技术或任意替换既有栈。
-
-### 阶段 1: 前置条件检查 (Entry Gate)
-```
-1. 解析 REQ_ID
-   → If $ARGUMENTS provided: use split("|") first token
-   → Else: run {SCRIPT:prereq} --json --paths-only
-   → If仍为空: ERROR "No requirement ID found."
-
-2. 验证目录与产物
-   → 检查: devflow/requirements/${REQ_ID}/
-   → 必须存在: PRD.md, research/research.md, research/tasks.json, research/internal/codebase-overview.md
-   → orchestration_status.json.phase0_complete 必须为 true
-
-3. 状态门
-   → status ∈ {prd_complete, ui_complete, tech_design_failed}
-   → 未满足则拒绝进入。
-```
-
-### 阶段 2: 技术细化分析
-```
-1. 执行 {SCRIPT:tech_analysis} "${REQ_ID}"
-   → 输出: research/codebase-tech-analysis.md
-   → 内容: 数据模型模式、API 模式、认证、安全、数据库、可复用组件、测试、示例代码。
-
-2. 同步 EXECUTION_LOG.md
-   → 记录分析完成时间、重点洞察、待确认风险。
-```
-
-### 阶段 3: 资产生成与 Agent 调用
-```
-1. 准备 TECH_DESIGN 上下文
-   → 读取: PRD.md, research/research.md, research/codebase-tech-analysis.md
-   → 可选: UI_PROTOTYPE.html (存在时加载结构摘要)
-   → 更新 orchestration_status: status=tech_design_in_progress, phase=technical_design.
-
-2. 调用 tech-architect agent
-   → 加载模板: .claude/docs/templates/TECH_DESIGN_TEMPLATE.md
-   → 执行模板 Execution Flow，输出 TECH_DESIGN.md（无 {{PLACEHOLDER}}）
-   → 记录 log_event "${REQ_ID}" "Technical design completed"
-
-3. 派生资产
-   → Run: {SCRIPT:extract_data_model} "${REQ_ID}" → 生成 data-model.md
-   → Run: {SCRIPT:export_contracts} "${REQ_ID}" → 生成 contracts/openapi.yaml (或其他格式)
-   → Run: {SCRIPT:quickstart} "${REQ_ID}" → 生成 quickstart.md（包含环境、测试命令、验证步骤）
-
-4. 更新代理上下文
-   → Run: {AGENT_SCRIPT}  # 仅新增技术条目，保持 markers 内手动内容
-   → 在 EXECUTION_LOG.md 记录新增技术。
-```
-
-### 阶段 4: 完成校验 (Exit Gate)
-```
-1. 文件存在性
-   → TECH_DESIGN.md, research/codebase-tech-analysis.md
-   → data-model.md, contracts/, quickstart.md
-
-2. 质量检查
-   → TECH_DESIGN.md: 包含系统架构/技术栈/数据模型/API/安全/性能/Constitution Gate
-   → data-model.md: 实体、字段、关系、校验、状态机
-   → contracts/: 所有端点请求/响应 schema
-   → quickstart.md: 环境准备、测试矩阵、验证指令
-
-3. 宪法校验
-   → Run: validate-constitution.sh --type tech_design --severity warning
-   → 若有 ERROR 级别违规：终止并修复
-
-4. 状态更新
-   → orchestration_status.json:
-      • status = "tech_design_complete"
-      • phase = "epic_planning"
-      • phase1_complete = true
-      • completedSteps append "tech_design"
-   → EXECUTION_LOG.md 记录出口验收。
-```
-
-### 阶段 5: 输出与下一步
-- 汇总结果：
-  ```
-  ✅ TECH_DESIGN.md
-  ✅ research/codebase-tech-analysis.md
-  ✅ data-model.md
-  ✅ contracts/openapi.yaml
-  ✅ quickstart.md
-  ```
-- 建议操作：
-  1. 审阅技术方案关键决策。
-  2. 使用 `/flow-epic` 进入任务规划（会 gate 检查上述资产）。
-  3. 如需补充研究，回到 `/flow-init` 生成的 research/tasks.json 更新状态。
-
-## 错误处理提示
-- 缺少 PRD 或 research.md → 直接 ERROR，让用户先补 Phase 0。
-- agent 输出不完整 → 保留临时文件并记录 `tech_design_failed`，用户可修正后重试。
-- 派生资产脚本失败 → 标记 `phase1_complete = false`，提示对应脚本名与日志路径。
-
-## 宪法遵循
-- Simplicity Gate：设计 ≤3 栈层、禁止为未来功能做预设。
-- Anti-Abstraction Gate：直接使用框架，不新增自定义抽象层。
-- Integration-First Gate：所有 contracts 在 Phase 2 先定义，Phase 3 任务只需按合同落地。
-
-## 产物摘要
-- `TECH_DESIGN.md`: 技术总纲，引用子文档链接。
-- `research/codebase-tech-analysis.md`: 深度分析，支撑方案假设。
-- `data-model.md`: 供 planner 和 DB 工具使用的实体清单。
-- `contracts/`: OpenAPI/GraphQL 等契约基线。
-- `quickstart.md`: QA、Dev、CI 共享的执行脚本。

package/.claude/commands/flow-ui.md

@@ -1,189 +0,0 @@
----
-name: flow-ui
-description: 'Generate interactive HTML prototype from PRD. Usage: /flow-ui "REQ-123" or /flow-ui'
-scripts:
-  prereq: .claude/scripts/check-prerequisites.sh
-  validate_constitution: .claude/scripts/validate-constitution.sh
----
-
-# Flow-UI - UI 原型生成命令
-
-## User Input
-```text
-$ARGUMENTS = "REQ_ID?"
-```
-缺省时依据当前分支或 `DEVFLOW_REQ_ID` 自动解析。
-
-## 命令格式
-```text
-/flow-ui "REQ_ID"
-/flow-ui             # Auto-detect from current branch
-```
-
-## 触发原则
-- **自动触发**：PRD 含 UI 关键词（用户界面、前端、页面、交互…），或仓库存在 `package.json`、`src/components/` 等前端特征。
-- **手动触发**：用户显式调用 `/flow-ui`。
-- **自动跳过**：PRD 标注“纯后端/无 UI”，或项目缺少前端栈特征。跳过时记录 `ui_skipped`。
-
-## 执行流程
-
-### 阶段 1: Entry Gate
-```
-1. 解析 REQ_ID
-   → If argument provided: use it
-   → Else: run {SCRIPT:prereq} --json --paths-only
-   → If仍为空: ERROR "No requirement ID found."
-
-2. 校验资产
-   → 必须存在:
-      • PRD.md（无 {{PLACEHOLDER}}）
-      • research/research.md
-      • orchestration_status.status == "prd_complete"
-   → 如果 UI_PROTOTYPE.html 已存在 → WARN 并确认覆盖
-
-3. UI 需求检测
-   → 检查 PRD 关键词 + 项目结构
-   → 如检测不到且用户拒绝继续 → 记录 EXECUTION_LOG "ui_skipped" 后退出
-```
-
-### 阶段 2: 设计风格加载与灵感采样
-```
-1. 检查项目级 STYLE.md 是否存在
-   → 检查 devflow/STYLE.md 文件
-   → 如存在:
-      • 加载 STYLE.md 作为首要参考（优先级最高）
-      • 所有颜色、字体、间距、组件必须严格遵循 STYLE.md
-      • 在 EXECUTION_LOG.md 记录 STYLE.md 版本和使用情况
-   → 如不存在:
-      • 使用默认采样策略（80+ 设计大师）
-      • 建议用户先运行 /flow-style 建立项目设计标准
-
-2. 从 PRD 抽取风格线索（作为 STYLE.md 的补充或默认策略）
-   → 背景/目标、用户画像、NFR 中的视觉/品牌要求
-   → 关键词示例: 现代、简约、科技感、典雅、活泼、企业级、极简、暗色、明快
-
-3. 建立关键词 → 设计风格/大师映射（仅在无 STYLE.md 时使用完整策略）
-   • 现代 / 简约 / 专业:
-       - 现代主义信息设计 (Josef Müller-Brockmann, Massimo Vignelli)
-       - 工业设计 (Dieter Rams, Jony Ive)
-   • 科技感 / 创新 / 动态:
-       - 生成艺术 (Refik Anadol, John Maeda)
-       - 未来派建筑 (Zaha Hadid, BIG)
-   • 典雅 / 文化 / 文艺:
-       - 亚洲与当代艺术 (原研哉, 草间弥生)
-       - 平面设计 (Paula Scher, Neville Brody)
-   • 活泼 / 年轻 / 时尚:
-       - 后现代图形 (David Carson, April Greiman)
-       - 抽象艺术 (Henri Matisse, Joan Miró)
-   • 企业级 / 金融 / 严肃:
-       - 现代主义建筑 (Le Corbusier, Alvar Aalto)
-       - 工业设计 (Braun School)
-   • 未匹配关键词:
-       - 默认组合: 现代主义 + 工业设计
-
-3. 可选灵感采集
-   → 若 PRD 或用户提供参考站点/风格，使用 WebSearch/WebFetch 收集视觉要点，
-     保存至 `research/ui_inspiration_*.md`
-
-4. 生成 `research/ui_design_strategy.md`
-   → 结构建议:
-     ```
-     # UI 设计策略 - ${REQ_ID}
-
-     ## 项目级风格指南引用（如存在）
-     - STYLE.md 路径: devflow/STYLE.md
-     - STYLE.md 版本: v1.0.0
-     - 必须遵循的设计元素:
-       • 颜色: 主色 #XXXXXX, 辅色 #XXXXXX, ...（来自 STYLE.md）
-       • 字体: Font Family, Weight, Size（来自 STYLE.md）
-       • 间距: 4px, 8px, 16px, ...（来自 STYLE.md）
-       • 组件风格: Button, Card, Input 样式（来自 STYLE.md）
-       • 阴影、圆角、动画等（来自 STYLE.md）
-     - STYLE.md 未覆盖的部分处理策略:
-       • 使用 PRD 风格线索 + 默认采样策略
-
-     ## PRD 风格提取
-     - 领域 / 用户画像 / 场景
-     - 关键词列表
-     - 明确要求 / 禁忌
-
-     ## 采样策略（仅在无 STYLE.md 或 STYLE.md 未覆盖部分）
-     - 选定流派 1 （大师列表 + 采样理由）
-     - 选定流派 2 （大师列表 + 采样理由）
-     - 默认样式（无关键词时的 fallback）
-
-     ## 色彩 / 字体 / 布局假设
-     - 主/辅色、对比度、排版方向
-     - （如有 STYLE.md，此部分直接引用 STYLE.md）
-
-     ## 交互与响应式要点
-     - 核心动效、断点策略、可访问性注意事项
-     - （如有 STYLE.md，响应式断点、动画时长等引用 STYLE.md）
-
-     ## 外部灵感 (如有)
-     - 引用链接 + 摘要
-     ```
-   → EXECUTION_LOG.md 记录策略生成、STYLE.md 使用情况、关键词
-```
-
-### 阶段 3: 调用 ui-designer Agent
-```
-Prompt 要求:
-  - 输入:
-      • PRD.md
-      • ui_design_strategy.md
-      • research 集合
-      • devflow/STYLE.md（如存在，必须作为首要参考）
-  - 输出: UI_PROTOTYPE.html
-  - 遵循模板 (.claude/docs/templates/UI_PROTOTYPE_TEMPLATE.md):
-      • 页面列表、组件清单、设计系统 (颜色/字体/间距)
-      • 响应式断点 (320/768/1024)
-      • 交互状态 (hover/active/disabled)
-      • 文档内注释说明各部分映射的 PRD 验收标准
-  - STYLE.md 约束（如存在）:
-      • 所有颜色必须使用 STYLE.md 定义的色板（主色、辅色、语义色、中性色）
-      • 所有字体必须使用 STYLE.md 定义的字体系统（字体族、字阶）
-      • 所有间距必须使用 STYLE.md 定义的间距系统（spacing scale）
-      • 所有组件样式必须遵循 STYLE.md 定义的组件规范（Button, Card, Input 等）
-      • 阴影、圆角、动画、透明度等必须遵循 STYLE.md
-      • 响应式断点必须遵循 STYLE.md（如有定义）
-      • 仅在 STYLE.md 未覆盖的部分，才使用默认采样策略（80+ 设计大师）
-  - Constitution: 禁止外链资源、禁止敏感数据硬编码
-```
-
-### 阶段 4: Exit Gate
-```
-1. 文件存在
-   → UI_PROTOTYPE.html
-   → research/ui_design_strategy.md
-
-2. 结构检查
-   → HTML 内包含设计系统、页面导航、组件说明
-   → 注释中标注 PRD 用户故事和验收点
-
-3. 状态更新
-   → orchestration_status:
-        status = "ui_complete"
-        completedSteps append "ui"
-   → 如跳过，则 status = "ui_skipped" 并记录原因
-
-4. 宪法校验（可选）
-   → {SCRIPT:validate_constitution} --type ui --severity warning
-```
-
-## 输出
-```
-✅ UI_PROTOTYPE.html
-✅ research/ui_design_strategy.md
-✅ EXECUTION_LOG.md 更新（完成或跳过）
-```
-
-## 错误处理
-- 缺少 PRD 或研究资产 → 提示先完成 `/flow-prd`、`/flow-init` Consolidation。
-- Agent 生成失败 → status 设为 `ui_generation_failed`，可修正后重试。
-- 用户确认跳过 → 标记 `ui_skipped`，后续流程仍可继续。
-
-## 下一步
-1. 审阅原型并与产品对齐。
-2. 若涉及前端实现，确保 `/flow-tech` 引用 UI_PROTOTYPE 中的组件与断点。
-3. Planner 在 `/flow-epic` 阶段加载页面/组件清单生成对应任务。

package/.claude/skills/file-header-guardian/SKILL.md

@@ -1,56 +0,0 @@
----
-name: file-header-guardian
-description: 文件头三行契约注释。触发：create file、新建文件、编写代码。
----
-
-# 文件头注释守护者
-
-触发：创建代码文件，修改文件后检查头注释准确性。
-
-## 模板
-
-**TS/JS:**
-```typescript
-/**
- * @input  依赖什么
- * @output 提供什么
- * @pos    系统地位
- * ⚠️ 修改后同步：文件头 + 目录 CLAUDE.md
- */
-```
-
-**Python:**
-```python
-"""
-@input  依赖什么
-@output 提供什么
-@pos    系统地位
-⚠️ 修改后同步：文件头 + 目录 CLAUDE.md
-"""
-```
-
-**Shell:**
-```bash
-# @input  依赖什么
-# @output 提供什么
-# @pos    系统地位
-# ⚠️ 修改后同步：文件头 + 目录 CLAUDE.md
-```
-
-## 示例
-
-```typescript
-/**
- * @input  prisma.service 数据库连接
- * @output UserService: create/update/delete
- * @pos    用户模块核心
- * ⚠️ 修改后同步：文件头 + 目录 CLAUDE.md
- */
-export class UserService { }
-```
-
-## 豁免
-
-配置文件（json/yaml）、样式（css）、生成文件（*.d.ts）、node_modules。
-
-协作：本 skill 管文件，fractal-docs-generator 管目录。