cc-devflow 4.3.0 → 4.4.1

package/.claude/commands/flow/delta.md

@@ -1,245 +0,0 @@
----
-name: flow-delta
-description: Manage delta specs for incremental requirement tracking (RM-017)
-version: 4.0.0
----
-
-# /flow:delta
-
-> **[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md
-
-## Purpose
-
-Manage incremental specification changes (delta specs) for tracking requirement evolution.
-Delta specs capture ADDED/MODIFIED/REMOVED/RENAMED changes that are later applied to the SSOT.
-
-借鉴 OpenSpec 的 Delta Specs 设计，实现增量规格管理。
-
-## Usage
-
-```bash
-# Create a new delta spec
-/flow:delta create "REQ-123" "add-2fa"
-
-# List all deltas for a requirement
-/flow:delta list "REQ-123"
-
-# Apply delta to main specs (PRD.md)
-/flow:delta apply "REQ-123" "add-2fa"
-
-# Check delta status
-/flow:delta status "REQ-123" "add-2fa"
-```
-
-## Subcommands
-
-### create
-
-Create a new delta spec for a requirement.
-
-```bash
-/flow:delta create "REQ-123" "add-2fa"
-```
-
-Creates:
-```
-devflow/requirements/REQ-123/
-└── deltas/
-    └── {YYYY-MM-DD}-add-2fa/
-        ├── delta.md
-        └── tasks.md
-```
-
-**Process**:
-1. Validate REQ-ID exists
-2. Generate delta_id: `{YYYY-MM-DD}-{slug}`
-3. Create directory structure
-4. Generate delta.md from template
-5. Generate tasks.md for delta-specific tasks
-
-### list
-
-List all deltas for a requirement.
-
-```bash
-/flow:delta list "REQ-123"
-```
-
-**Output**:
-```
-Deltas for REQ-123:
-  1. 2026-02-01-add-2fa       [approved]  Add 2FA support
-  2. 2026-02-05-fix-login     [draft]     Fix login timeout
-  3. 2026-02-07-add-oauth     [review]    Add OAuth providers
-
-Total: 3 deltas (1 approved, 1 draft, 1 review)
-```
-
-### apply
-
-Apply a delta to the main PRD.md specification.
-
-```bash
-/flow:delta apply "REQ-123" "add-2fa"
-```
-
-**Process**:
-1. Parse delta.md using delta-parser.ts
-2. Validate delta status is "approved"
-3. Apply changes to PRD.md:
-   - RENAMED: Rename requirement headers
-   - REMOVED: Remove requirement blocks
-   - MODIFIED: Replace requirement content
-   - ADDED: Append new requirements
-4. Update delta status to "applied"
-5. Move to archive/
-
-**Validation**:
-- Delta must be in "approved" status
-- No duplicate requirements in ADDED
-- MODIFIED/REMOVED targets must exist
-- RENAMED source must exist, target must not
-
-### status
-
-Check the status of a specific delta.
-
-```bash
-/flow:delta status "REQ-123" "add-2fa"
-```
-
-**Output**:
-```
-Delta: 2026-02-01-add-2fa
-Status: approved
-Created: 2026-02-01T10:00:00Z
-
-Changes:
-  ADDED:     2 requirements
-  MODIFIED:  1 requirement
-  REMOVED:   0 requirements
-  RENAMED:   1 requirement
-
-Validation:
-  ✓ All ADDED requirements are unique
-  ✓ All MODIFIED targets exist
-  ✓ All RENAMED sources exist
-  ✓ Ready to apply
-```
-
-## Delta Spec Format
-
-```markdown
----
-delta_id: "2026-02-01-add-2fa"
-req_id: "REQ-123"
-title: "Add 2FA Support"
-created_at: "2026-02-01T10:00:00Z"
-status: "draft|review|approved|applied"
----
-
-# Delta: Add 2FA Support
-
-## Summary
-Brief description of changes.
-
-## ADDED Requirements
-
-### Requirement: Two-Factor Authentication
-Description of the new requirement.
-
-#### Scenario: Enable 2FA
-- GIVEN user is logged in
-- WHEN user enables 2FA
-- THEN system generates QR code
-
-## MODIFIED Requirements
-
-### Requirement: User Login
-New description.
-(Previously: old description)
-
-## REMOVED Requirements
-
-### Requirement: Legacy Session
-**Reason**: Replaced by JWT
-**Migration**: Run migration script
-
-## RENAMED Requirements
-
-- FROM: Old Name
-- TO: New Name
-```
-
-## Status Workflow
-
-```
-draft → review → approved → applied
-  │       │         │
-  │       │         └── /flow:delta apply
-  │       │
-  │       └── Manual review approval
-  │
-  └── /flow:delta create
-```
-
-## Scripts
-
-| Script | Purpose |
-|--------|---------|
-| `flow-delta-create.sh` | Create delta directory and files |
-| `flow-delta-list.sh` | List all deltas for a requirement |
-| `flow-delta-apply.sh` | Apply delta to PRD.md |
-| `flow-delta-status.sh` | Check delta status |
-| `delta-parser.ts` | Parse and apply delta blocks |
-
-## Integration
-
-### With /flow:spec
-
-When `/flow:spec` modifies existing requirements, it can generate deltas:
-```
-PRD.md changes → deltas/{date}-{slug}/delta.md
-```
-
-### With /flow:release
-
-Before PR creation, `/flow:release` applies all approved deltas:
-```bash
-/flow:delta apply REQ-XXX --all
-```
-
-### With /flow:archive
-
-After release, `/flow:archive` includes applied deltas:
-```bash
-devflow/archive/{date}-REQ-XXX/deltas/
-```
-
-## Directory Structure
-
-```
-devflow/requirements/REQ-123/
-├── PRD.md                    # Main specification (SSOT)
-├── deltas/                   # Delta specs directory
-│   ├── 2026-02-01-add-2fa/
-│   │   ├── delta.md          # Delta specification
-│   │   └── tasks.md          # Delta-specific tasks
-│   └── 2026-02-05-fix-login/
-│       ├── delta.md
-│       └── tasks.md
-└── ...
-
-devflow/archive/
-└── 2026-02/
-    └── REQ-123/
-        └── deltas/           # Archived deltas
-            └── 2026-02-01-add-2fa/
-                └── delta.md
-```
-
-## Related
-
-- **Template**: `.claude/docs/templates/DELTA_SPEC_TEMPLATE.md`
-- **Parser**: `.claude/scripts/delta-parser.ts`
-- **Archive**: `devflow/archive/` - Historical delta specs

package/.claude/commands/flow/dev.md

@@ -1,40 +0,0 @@
----
-name: flow-dev
-description: 'Execute task-manifest with checkpointed parallel dispatch. Usage: /flow:dev "REQ-123" [--parallel 3] [--resume] [--max-retries N]'
-skill: workflow/flow-dev
----
-
-# Flow-Dev Command (Harness Dispatch)
-
-> 触发入口：执行细节由 `.claude/skills/workflow/flow-dev/SKILL.md` 定义。
-
-## User Input
-
-```text
-$ARGUMENTS = "REQ_ID [--parallel N] [--resume] [--max-retries N]"
-```
-
-## Usage
-
-```bash
-/flow:dev "REQ-123"
-/flow:dev "REQ-123" --parallel 3
-/flow:dev "REQ-123" --resume --max-retries 2
-```
-
-## Internal Execution
-
-- Normal: `npm run harness:dispatch -- --change-id <REQ_ID> --parallel <N> [--max-retries <N>]`
-- Resume: `npm run harness:resume -- --change-id <REQ_ID> --parallel <N> [--max-retries <N>]`
-
-## Output
-
-- `devflow/requirements/<REQ_ID>/task-manifest.json` (状态更新)
-- `.harness/runtime/<REQ_ID>/<TASK_ID>/events.jsonl`
-- `.harness/runtime/<REQ_ID>/<TASK_ID>/checkpoint.json`
-
-## Next Step
-
-```bash
-/flow:verify "<REQ_ID>"
-```

package/.claude/commands/flow/fix.md

@@ -1,217 +0,0 @@
----
-name: flow-fix
-description: 'One-shot BUG fix flow with systematic debugging. Usage: /flow-fix "BUG-123|登录时报 500"'
-scripts:
-  prereq: .claude/scripts/check-prerequisites.sh
-  recover: .claude/scripts/recover-workflow.sh
-  validate_constitution: .claude/scripts/validate-constitution.sh
-agent_scripts:
-  sh: .claude/scripts/update-agent-context.sh __AGENT__
-  ps: scripts/powershell/update-agent-context.ps1 -AgentType __AGENT__
-skills:
-  debugging: .claude/skills/flow-debugging/SKILL.md
-  verification: .claude/skills/verification-before-completion/SKILL.md
-  tdd: .claude/skills/flow-tdd/SKILL.md
----
-
-# Flow-Fix - 系统化 BUG 修复流
-
-## The Iron Law
-
-```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
-```
-
-## User Input
-```text
-$ARGUMENTS = "BUG_ID|TITLE"
-```
-BUG_ID 必须满足 `BUG-\d+`；TITLE 为简洁现象描述。
-
-## 命令格式
-```text
-/flow-fix "BUG-123|登录时报500"
-```
-
----
-
-## 核心理念
-
-Bug 修复不是猜测游戏。系统化调试 = 更快修复 + 更少回归。
-
-```
-错误方式: 看到错误 → 猜测原因 → 尝试修复 → 失败 → 再猜...
-正确方式: 看到错误 → 调查根因 → 理解问题 → 写测试 → 修复 → 验证
-```
-
-### Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "我知道问题在哪" | 证明它。先调查。 |
-| "快速修复一下" | 快速修复 = 快速回归。系统化调试。 |
-| "没时间写测试" | 没测试 = 不知道是否真的修好了。 |
-| "这个改动很小" | 小改动也能引入大 bug。测试它。 |
-| "先修复，后调查" | 不理解问题就修复 = 猜测。 |
-| "试试这个" | "试试"不是调试。形成假设，验证它。 |
-
-### Red Flags - STOP
-
-如果你发现自己:
-- 没有复现就开始修复
-- 在"试试这个，试试那个"
-- 3+ 次修复尝试失败
-- 没写测试就说"修好了"
-- 改了很多文件来修一个 bug
-
-**STOP. 回到阶段 1. 调查根因。**
-
----
-
-## 执行流程
-
-### 阶段 0: Entry Gate
-```
-1. 解析 BUG_ID、TITLE
-2. {SCRIPT:prereq} --json 验证:
-   → devflow/bugs/${BUG_ID}/ 是否存在（首次执行将创建）
-3. 初始化 devflow/bugs/${BUG_ID}/ 结构与 orchestration_status.json
-4. 检查 quickstart.md
-   → 若需求目录已有 quickstart.md，复制引用用于测试执行
-```
-
-### 阶段 1: Root Cause Investigation (NO FIXES YET)
-
-**Iron Law**: 在这个阶段，**禁止写任何修复代码**。
-
-参考 `{SKILL:debugging}` Phase 1:
-
-```
-Step 1: 完整阅读错误信息
-  → 不要跳过任何细节
-  → 记录: 错误类型、消息、堆栈跟踪
-  → 记录: 发生时间、频率、影响范围
-
-Step 2: 稳定复现
-  → 找到可靠的复现步骤
-  → 记录: 输入、环境、前置条件
-  → 如果无法复现 → 收集更多信息
-
-Step 3: 检查最近变更
-  → git log --oneline -20
-  → git diff HEAD~5
-  → 问: 什么变了？何时开始出问题？
-
-Step 4: 逆向追踪数据流
-  → 从错误点向上追踪
-  → 找到数据来源
-  → 识别数据在哪里变坏
-```
-
-**输出**: ANALYSIS.md（现象、复现、根因假设、影响范围）
-
-### 阶段 2: Pattern Analysis & Planning
-
-参考 `{SKILL:debugging}` Phase 2:
-
-```
-1. 找到正常工作的例子
-   → 类似功能哪里正常工作？
-   → 对比: 正常 vs 异常
-
-2. 与参考实现对比
-   → 官方文档怎么说？
-   → 其他项目怎么做？
-
-3. 调用 planner
-   → 输入 ANALYSIS.md、现有 quickstart、代码结构
-   → 产出 PLAN.md、tasks/ (TDD 顺序: Root Cause → Failing Test → Fix → Regression)
-
-4. 调用 qa-tester / security-reviewer
-   → 生成 TEST_PLAN.md、SECURITY_PLAN.md
-```
-
-**输出**: PLAN.md, tasks/, TEST_PLAN.md, SECURITY_PLAN.md
-
-### 阶段 3: 修复执行 (TDD)
-
-参考 `{SKILL:tdd}` + `{SKILL:debugging}` Phase 3-4:
-
-```
-1. 先写失败测试用例
-   → 测试必须复现 bug
-   → 运行测试，确认失败
-   → 这是你的"红灯"
-
-2. 主代理按 tasks/ 顺序执行:
-   → Phase 1: 重现/Root Cause (分析日志、添加监控)
-   → Phase 2: Tests First (根据 quickstart 运行失败测试)
-   → Phase 3: Fix Implementation (最小化改动)
-   → Phase 4: Regression hardening
-
-3. 每个任务完成后:
-   → 运行 quickstart 中相关测试命令
-   → Git 提交 (一任务一提交)
-   → 更新 TASKS.md (checkbox 标记)
-
-4. 3+ 次修复失败 → STOP
-   → 停下来，质疑架构
-   → 可能问题比想象的更深
-```
-
-### 阶段 4: 验证与发布
-
-参考 `{SKILL:verification}`:
-
-```
-1. qa-tester 生成 TEST_REPORT.md（必须全部通过）
-2. security-reviewer 生成 SECURITY_REPORT.md
-3. release-manager 生成 RELEASE_PLAN.md
-4. {SCRIPT:validate_constitution} --type bug_fix --severity warning
-5. orchestration_status: status="fix_complete"
-
-验证清单:
-  □ 根因已记录
-  □ 失败测试已写
-  □ 修复已实现
-  □ 测试通过
-  □ 无回归
-  □ 文档已更新 (如需要)
-```
-
----
-
-## 产物结构
-```
-devflow/bugs/${BUG_ID}/
-  ANALYSIS.md              # 根因分析
-  PLAN.md                  # 修复计划
-  tasks/                   # TDD 任务
-  TEST_PLAN.md / SECURITY_PLAN.md
-  TEST_REPORT.md / SECURITY_REPORT.md
-  RELEASE_PLAN.md
-  quickstart.md (引用或增量说明)
-  orchestration_status.json
-  LOG.md
-```
-
-## 错误处理
-- 任意阶段失败 → status 标记为 `*_failed`，可使用 `/flow-fix --resume`（由 recover 脚本处理）。
-- 找不到 quickstart → 提示读取主需求目录的 quickstart 或补充测试命令。
-- 宪法检查失败 → 输出违规项并阻断发布。
-
-## 下一步
-1. 提交 PR：`fix(${BUG_ID}): <summary>`
-2. 通知相关需求负责人回归验证。
-3. 评估是否需更新研究/技术设计文档以反映修复影响。
-
----
-
-**Related Documentation**:
-- [flow-debugging](.claude/skills/flow-debugging/SKILL.md) - 4 阶段调试法
-- [flow-tdd](.claude/skills/flow-tdd/SKILL.md) - TDD 原则
-- [verification-before-completion](.claude/skills/verification-before-completion/SKILL.md) - 验证技能
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/commands/flow/ideate.md

@@ -1,214 +0,0 @@
----
-name: flow-ideate
-description: 'Intent-driven requirement development. Usage: /flow:ideate "我想做一个用户管理系统" or /flow:ideate "REQ-123|我想要一个数据分析的东西"'
-scripts:
-  prereq: .claude/scripts/check-prerequisites.sh
-  create_requirement: .claude/scripts/create-requirement.sh
-  manage_constitution: .claude/scripts/manage-constitution.sh
-agent_scripts:
-  sh: .claude/scripts/update-agent-context.sh __AGENT__
-  ps: scripts/powershell/update-agent-context.ps1 -AgentType __AGENT__
----
-
-# Flow-Ideate - 意图驱动需求开发
-
-## User Input
-```text
-$ARGUMENTS = "REQ_ID?|IDEA|LINKS?"
-```
-允许纯自然语言、半结构化、“REQ|标题|链接”三种形式。缺省 REQ_ID 时会生成新的 ID。
-
-## 命令格式
-```text
-/flow:ideate "我想做一个用户管理系统"
-/flow:ideate "REQ-123|我想要一个用户管理的东西"
-/flow:ideate "|数据分析功能|一些想法和计划链接"
-/flow:ideate "REQ-123|支持用户下单|https://plan.example.com/Q1"
-```
-
-## 执行流程
-
-### 阶段 1: 输入解析
-- 解析 `$ARGUMENTS`：
-  - 如果匹配 `REQ|TITLE|LINKS` → 进入 `/flow:init`（随后执行 `/flow:spec`）。
-  - 如果包含 `REQ-XXX` 且标题为空 → 视为已有需求再澄清。
-  - 纯自然语言 → 进入意图澄清模式。
-- 对于新需求生成候选 `REQ-${YYYYMMDD}-${seq}`。
-
-### 阶段 2: 意图澄清（模糊/半结构化）
-```
-1. 调用 prd-writer agent:
-   → 输入原始描述、链接、历史上下文
-   → 输出澄清建议、初始理解、关键问题列表
-
-2. 对话轮数最多 4 轮：
-   → 每轮 3-5 个关键问题
-   → 优先顺序：领域/目标 → 核心用户 → 功能范围 → 验收标准 → 约束
-   → 识别安全/合规/性能需求时必须追问
-
-3. 会话产物:
-   → .claude/temp/intent-session-*.json (记录问答与提取信息)
-   → 置信度 ≥ 80% 且关键信息完整时结束澄清
-```
-
-### 阶段 3: 结构化与初始化
-```
-1. 生成最终 `REQ_ID|TITLE|PLAN_URLS` 字符串
-2. 调用 {SCRIPT:create_requirement} --title "${TITLE}"
-   → 创建 devflow/requirements/${REQ_ID}/
-3. 写入 README.md，附上原始描述与澄清纪要
-4. 调用 {SCRIPT:prereq} --json --paths-only 校验结构
-5. orchestration_status.json 初始化 status="initialized"
-```
-
-### 阶段 4: 标准流程对接
-- 对于模糊输入：推荐自动触发 `/flow:spec` 或提示用户继续。
-- 对于已有 REQ-ID：在 README 中记录追加需求并提示 `/flow:upgrade`。
-- 将澄清会话摘要写入 `research/intent-log.md` 供后续引用。
-
-## 错误处理
-- 输入仅为链接或空字符串 → 提示提供最少“谁/做什么/目标”信息。
-- 澄清达到上限仍不完整 → 输出未决事项并建议人工介入。
-- 生成 REQ 目录失败 → 回滚已创建文件，提示用户检查权限/路径。
-
-## 输出
-```
-✅ 新需求目录 (若生成 REQ)
-✅ research/intent-log.md (记录澄清问题与回答)
-✅ README.md 更新（含最终意图总结）
-✅ orchestration_status.json 初始化
-```
-
-## 下一步
-- 对新需求执行 `/flow:init "REQ_ID|TITLE"` 完成初始化。
-- 若是已有需求的变更，使用 `/flow:upgrade` 创建版本升级。
-- 通过 `/flow:status REQ_ID --detailed` 查看澄清结果与推荐动作。
-
-### 3. 这是新系统还是现有系统的改进？
-**Why this matters**: 影响技术方案和实施策略
-**Examples**: 全新开发、现有系统增强、系统替换
-
-## Next Steps:
-Once you provide these answers, I'll generate more specific questions about功能细节和技术要求.
-```
-
-**用户回答**:
-```text
-主要是内部员工使用，需要权限管理、部门管理、角色分配这些功能。是现有系统的增强。
-```
-
-**系统澄清轮次2**:
-```markdown
-# Requirement Clarification for 内部员工权限管理系统
-
-## Updated Understanding:
-- **Domain**: 企业内部用户权限管理
-- **Users**: 内部员工 + 管理员
-- **Core Function**: 权限管理、部门管理、角色分配
-- **Context**: 现有系统增强
-- **Confidence**: 70%
-
-## Additional Questions:
-
-### 1. 现有系统是什么技术栈？
-**Why this matters**: 确保技术兼容性
-**Examples**: Java Spring, Node.js, Python Django
-
-### 2. 权限管理需要多细粒度？
-**Why this matters**: 影响权限模型设计复杂度
-**Examples**: 页面级、功能级、数据级、字段级
-
-### 3. 大概有多少员工会使用这个系统？
-**Why this matters**: 影响性能设计和架构选择
-**Examples**: <100人, 100-1000人, >1000人
-
-## Next Steps:
-基于您的回答，我将生成完整的PRD并启动开发流程。
-```
-
-### 示例2: 数据分析功能
-
-**用户输入**:
-```text
-/flow:ideate "需要一个数据分析功能来帮助业务决策"
-```
-
-**系统澄清过程**:
-- 识别数据来源和类型
-- 明确分析维度和指标
-- 确定目标用户和使用场景
-- 了解数据可视化需求
-
-## 输出产物
-
-### 临时文件
-```text
-.claude/temp/
-├── intent-session-${timestamp}.json    # 对话会话状态
-├── clarification-${session_id}.md      # 澄清问题文档
-└── extracted-requirements.json        # 提取的需求信息
-```
-
-### 最终需求结构
-```text
-devflow/requirements/${auto_generated_req_id}/
-├── INTENT_ANALYSIS.md          # 意图分析和澄清过程
-├── PRD.md                      # 标准产品需求文档
-├── EPIC.md                     # Epic 规划
-├── tasks/                      # 任务分解
-└── [其他标准文档...]
-```
-
-## 配置选项
-
-### 环境变量
-```bash
-# Intent-driven 特定配置
-export FLOW_MAX_CLARIFICATION_ROUNDS=4
-export FLOW_MIN_CONFIDENCE_THRESHOLD=80
-export FLOW_AUTO_REQ_ID_FORMAT="REQ-%Y%m%d-%03d"
-export FLOW_QUESTION_SELECTION_STRATEGY="adaptive"
-```
-
-### 设置文件扩展
-```json
-{
-  "flow": {
-    "intentDriven": {
-      "enabled": true,
-      "maxClarificationRounds": 4,
-      "minConfidenceThreshold": 80,
-      "autoReqIdGeneration": true,
-      "questionSelectionStrategy": "adaptive"
-    }
-  }
-}
-```
-
-## 智能特性
-
-### 学习和优化
-- **问题效果追踪**: 记录哪些问题类型最有效
-- **域模型优化**: 基于历史数据优化业务域识别
-- **用户习惯学习**: 适应不同用户的表达习惯
-
-### 上下文感知
-- **项目历史**: 参考项目历史需求，提供上下文相关的问题
-- **技术栈感知**: 基于现有技术栈生成相关的技术约束问题
-- **团队偏好**: 学习团队的开发偏好和标准
-
-## 质量保证
-
-### 澄清质量检查
-- 问题覆盖度检查（确保涵盖所有PRD必需信息）
-- 问题清晰度验证（避免模糊或容易误解的问题）
-- 轮次效率监控（确保每轮都有实质性进展）
-
-### 结果验证
-- 生成需求的完整性验证
-- 与原始意图的一致性检查
-- 技术可行性初步评估
-
----
-
-**核心价值**: /flow:ideate 将 cc-devflow 的能力边界从"明确需求的快速实现"扩展到"模糊想法的完整转化"，显著降低了使用门槛，支持更多探索性和创新性的开发场景。