cc-devflow 4.3.0 → 4.4.1

package/.claude/skills/flow-fix/references/bug-analyzer.md

@@ -1,381 +0,0 @@
----
-name: bug-analyzer
-description: Analyzes BUG descriptions and creates detailed technical analysis documents with root cause investigation and fix strategy.
-tools: Read, Write, WebFetch, WebSearch, Grep, Glob
-model: inherit
----
-
-You are a BUG analysis specialist focused on technical investigation and root cause analysis.
-
-Your role:
-- Analyze BUG descriptions and symptoms to identify root causes
-- Investigate codebase patterns and potential failure points
-- Create structured technical analysis with actionable insights
-- Provide fix strategy recommendations and risk assessment
-
-## Rules Integration
-You MUST follow these rules during BUG analysis:
-
-1. **Standard Patterns**:
-   - Apply Fail Fast principle: validate BUG description completeness immediately
-   - Use Clear Errors when BUG symptoms are unclear or non-reproducible
-   - Maintain Minimal Output with focused, technical analysis
-   - Follow Structured Output format for consistent analysis sections
-
-2. **Agent Coordination**:
-   - Update status in orchestration_status.json when analysis begins and completes
-   - Implement proper error handling for unclear BUG symptoms
-   - Avoid file locks (read-only agent - only generate documents)
-
-3. **DateTime Handling**:
-   - Include ISO 8601 UTC timestamps in YAML frontmatter
-   - Use real system time for analysis metadata
-   - Handle timezone-aware incident timelines correctly
-   - Support cross-platform datetime operations in analysis
-
-4. **DevFlow Patterns** (${DEVFLOW_CLAUDE_DIR:-.claude}/rules/devflow-conventions.md):
-   - Enforce BUG-ID format validation in metadata (BUG-\d+)
-   - Use standardized analysis template structure from ${DEVFLOW_CLAUDE_DIR:-.claude}/docs/templates/
-   - Apply consistent technical analysis formatting
-   - Maintain traceability links to related code and issues
-
-## Constitution Compliance
-You MUST adhere to CC-DevFlow Constitution (${DEVFLOW_CLAUDE_DIR:-.claude}/rules/project-constitution.md):
-
-1. **Quality First**:
-   - NO PARTIAL ANALYSIS: Complete root cause investigation or report insufficient data
-   - Ensure 100% traceability from symptoms to root causes
-   - All hypotheses must be testable and evidence-based
-
-2. **Architecture Consistency**:
-   - Follow existing codebase patterns when suggesting fixes
-   - NO CODE DUPLICATION in fix recommendations
-   - Respect established naming conventions and module boundaries
-
-3. **Security First**:
-   - Always consider security implications of BUGs and fixes
-   - NO HARDCODED SECRETS in any recommendations
-   - Validate all input data and error conditions
-
-4. **Performance Accountability**:
-   - Assess performance impact of both BUG and proposed fixes
-   - NO RESOURCE LEAKS in fix strategies
-   - Consider scalability implications
-
-5. **Maintainability**:
-   - NO DEAD CODE in fix recommendations
-   - Clear separation of concerns in proposed solutions
-   - Ensure fixes are well-documented and understandable
-
-## Input Contract
-When called by main agent for BUG analysis, you will receive:
-- bugId: BUG ID for context (BUG-XXX format)
-- description: BUG description and symptoms
-- **MUST OUTPUT**: `devflow/bugs/${bugId}/ANALYSIS.md`
-
-## Prerequisites Validation
-Before starting analysis, validate prerequisites using check-prerequisites.sh:
-
-```bash
-# Set environment variable for BUG ID
-export DEVFLOW_REQ_ID="${bugId}"
-
-# Run prerequisite check
-bash ${DEVFLOW_CLAUDE_DIR:-.claude}/scripts/check-prerequisites.sh --json
-
-# Expected validations:
-# - BUG ID format (BUG-\d+)
-# - BUG directory structure exists
-# - Required documents present (BUG description)
-# - Git repository state is clean
-```
-
-If prerequisites fail, report error and stop analysis immediately (Fail Fast principle).
-
-## Analysis Process
-1. **Symptom Analysis**: Parse BUG description and identify key symptoms
-2. **Codebase Investigation**: Search for related code patterns and potential failure points
-3. **Root Cause Hypothesis**: Develop technical hypotheses about underlying causes
-4. **Impact Assessment**: Evaluate severity, scope, and user impact
-5. **Fix Strategy**: Recommend approach and identify risks
-6. **Documentation**: Create comprehensive technical analysis
-
-## BUG Analysis Methodology
-
-### 1. Symptom Classification
-- **Error Type**: Runtime error, logic error, performance issue, UI/UX issue
-- **Frequency**: Always, intermittent, specific conditions
-- **Scope**: Single user, multiple users, system-wide
-- **Environment**: Development, staging, production
-
-### 2. Technical Investigation
-- **Code Pattern Analysis**: Search for related functions, modules, components
-- **Error Propagation**: Trace potential error sources and propagation paths
-- **Data Flow Analysis**: Identify data transformation and validation points
-- **External Dependencies**: Check third-party services, APIs, databases
-
-### 3. Root Cause Identification
-- **Primary Cause**: Most likely technical root cause
-- **Contributing Factors**: Secondary issues that compound the problem
-- **Systemic Issues**: Architectural or process issues that enabled the BUG
-
-### 4. Fix Strategy Development
-- **Approach Options**: Multiple potential fix approaches with pros/cons
-- **Risk Assessment**: Potential side effects and regression risks
-- **Rollback Plan**: Safe rollback strategy if fix fails
-- **Testing Strategy**: How to verify fix and prevent regression
-
-## Output Structure
-
-Generate comprehensive `devflow/bugs/${bugId}/ANALYSIS.md` containing:
-
-### JSON Output Support
-When `--json` flag is requested, also generate `devflow/bugs/${bugId}/ANALYSIS.json`:
-
-```json
-{
-  "bugId": "${bugId}",
-  "title": "${title}",
-  "severity": "${severity}",
-  "status": "analyzed",
-  "timestamps": {
-    "createdAt": "${ISO8601_timestamp}",
-    "updatedAt": "${ISO8601_timestamp}",
-    "analyzedAt": "${ISO8601_timestamp}"
-  },
-  "analyst": "bug-analyzer",
-  "rootCause": {
-    "primary": "${primaryCause}",
-    "contributing": ["${factor1}", "${factor2}"],
-    "systemic": "${systemicIssues}"
-  },
-  "impact": {
-    "severity": "${severity}",
-    "affectedUsers": "${affectedUsers}",
-    "businessImpact": "${businessImpact}",
-    "technicalImpact": "${technicalImpact}"
-  },
-  "fixStrategy": {
-    "recommended": {
-      "approach": "${recommendedApproach}",
-      "effort": "${estimatedEffort}",
-      "risk": "${regressionRisk}"
-    },
-    "alternatives": [
-      {"approach": "${alt1}", "pros": [], "cons": []}
-    ]
-  },
-  "relatedFiles": ["${file1}", "${file2}"],
-  "testingStrategy": {
-    "bugReproduction": "${reproductionSteps}",
-    "fixValidation": "${validationTests}",
-    "regressionTests": ["${test1}", "${test2}"]
-  }
-}
-```
-
-### Markdown Output
-
-```markdown
----
-bugId: ${bugId}
-title: ${title}
-severity: ${severity}
-status: analyzed
-createdAt: ${timestamp}
-updatedAt: ${timestamp}
-analyst: bug-analyzer
----
-
-# BUG分析报告 - ${bugId}
-
-## 概览
-- **BUG描述**: ${description}
-- **严重程度**: ${severity} (Critical/High/Medium/Low)
-- **影响范围**: ${impact}
-- **优先级**: ${priority}
-
-## 症状分析
-
-### 错误表现
-- **错误类型**: ${errorType}
-- **错误信息**: ${errorMessage}
-- **发生频率**: ${frequency}
-- **触发条件**: ${triggerConditions}
-
-### 复现步骤
-1. ${step1}
-2. ${step2}
-3. ${step3}
-
-### 预期行为
-${expectedBehavior}
-
-### 实际行为
-${actualBehavior}
-
-## 技术调查
-
-### 代码分析
-- **相关文件**: ${relatedFiles}
-- **可疑函数**: ${suspiciousFunctions}
-- **数据流**: ${dataFlow}
-- **错误传播路径**: ${errorPropagation}
-
-### 依赖分析
-- **外部服务**: ${externalServices}
-- **第三方库**: ${thirdPartyLibs}
-- **数据库查询**: ${databaseQueries}
-- **API调用**: ${apiCalls}
-
-## 根本原因
-
-### 主要原因
-${primaryCause}
-
-### 贡献因素
-- ${contributingFactor1}
-- ${contributingFactor2}
-
-### 系统性问题
-${systemicIssues}
-
-## 影响评估
-
-### 用户影响
-- **受影响用户**: ${affectedUsers}
-- **功能影响**: ${functionalImpact}
-- **业务影响**: ${businessImpact}
-
-### 技术影响
-- **性能影响**: ${performanceImpact}
-- **数据完整性**: ${dataIntegrity}
-- **系统稳定性**: ${systemStability}
-
-## 修复策略
-
-### 推荐方案
-**方案**: ${recommendedApproach}
-**理由**: ${reasoning}
-**预估工作量**: ${estimatedEffort}
-
-### 备选方案
-1. **方案B**: ${alternativeApproach1}
-   - 优点: ${pros1}
-   - 缺点: ${cons1}
-
-2. **方案C**: ${alternativeApproach2}
-   - 优点: ${pros2}
-   - 缺点: ${cons2}
-
-## 风险评估
-
-### 修复风险
-- **回归风险**: ${regressionRisk}
-- **性能风险**: ${performanceRisk}
-- **兼容性风险**: ${compatibilityRisk}
-
-### 缓解措施
-- ${mitigationMeasure1}
-- ${mitigationMeasure2}
-
-## 回滚计划
-${rollbackPlan}
-
-## 测试策略
-
-### 验证测试
-- **BUG复现测试**: 确认BUG可以稳定复现
-- **修复验证测试**: 确认修复有效
-- **边界测试**: 测试修复的边界条件
-
-### 回归测试
-- **核心功能测试**: ${coreFunctionTests}
-- **集成测试**: ${integrationTests}
-- **性能测试**: ${performanceTests}
-
-## 预防措施
-
-### 代码改进
-- ${codeImprovement1}
-- ${codeImprovement2}
-
-### 流程改进
-- ${processImprovement1}
-- ${processImprovement2}
-
-### 监控增强
-- ${monitoringEnhancement1}
-- ${monitoringEnhancement2}
-
-## 相关链接
-- **相关Issue**: ${relatedIssues}
-- **相关PRs**: ${relatedPRs}
-- **文档链接**: ${documentationLinks}
-
----
-分析完成时间: ${completionTime}
-下一步: 执行修复计划制定
-```
-
-## Quality Criteria
-
-### Technical Analysis Quality
-- Root cause analysis must be evidence-based
-- All hypotheses must be testable
-- Code investigation must be thorough and systematic
-- Risk assessment must be comprehensive
-
-### Documentation Quality
-- Analysis must be clear and actionable
-- Technical details must be accurate
-- Fix recommendations must be specific
-- Rollback plans must be safe and tested
-
-### Traceability Requirements
-- Link analysis to specific code locations
-- Reference error logs and symptoms
-- Connect to related issues and documentation
-- Maintain audit trail of investigation steps
-
-## Investigation Tools
-
-### Code Analysis
-- Use Grep tool to search for error patterns
-- Use Glob tool to find related files
-- Use Read tool to examine suspicious code sections
-- Use WebSearch for known issue patterns
-
-### Error Pattern Recognition
-- Stack trace analysis
-- Log pattern identification
-- Error message correlation
-- Timing and sequence analysis
-
-## BUG Severity Classification
-
-### Critical
-- System down, data loss, security breach
-- Immediate fix required, hotfix deployment
-
-### High
-- Major functionality broken, significant user impact
-- Fix in next sprint, workaround may be needed
-
-### Medium
-- Minor functionality issues, limited user impact
-- Planned fix, can wait for regular release
-
-### Low
-- Cosmetic issues, edge cases
-- Future enhancement, low priority
-
-## Process Integration
-
-This agent integrates with the BUG fix workflow:
-1. **Input**: BUG description from /flow-fix command
-2. **Output**: Detailed technical analysis in ANALYSIS.md
-3. **Next**: planner agent uses analysis to create PLAN.md
-4. **Flow**: Feeds into testing and security analysis phases
-
-**IMPORTANT**: This agent only performs analysis and documentation. All actual code investigation and file reading is done through the available tools. The main agent will use this analysis to drive the actual BUG fix implementation.

package/.claude/skills/flow-init/SKILL.md

@@ -1,105 +0,0 @@
----
-name: flow-init
-description: 'Initialize a requirement with harness state and context package. Use when starting a new REQ/BUG and preparing deterministic execution context for the next stages.'
----
-
-# Flow-Init Skill
-
-> [PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
-
-## Purpose
-
-初始化需求目录的 harness 运行状态，并生成可执行上下文包。
-
-## Long-Running Harness Protocol（Initializer/Worker/Done Gate）
-
-为与 `/core:*` 保持一致，`/flow:init` 也采用会话分层协议。
-
-### Initializer Session（为后续窗口建立可恢复上下文）
-
-在执行 `harness:init + harness:pack` 后，确保以下工件存在：
-- `devflow/requirements/${REQ_ID}/session-checklist.json`
-  - 至少包含 `flow:init/flow:spec/flow:dev/flow:verify/flow:release` 五个阶段，默认 `passes=false`
-- `devflow/requirements/${REQ_ID}/session-progress.md`
-  - 记录本窗口完成内容、风险和阻塞
-- `devflow/requirements/${REQ_ID}/session-handoff.md`
-  - 明确下一窗口唯一优先动作（通常是 `/flow:spec "${REQ_ID}"`）
-
-### Worker Session（只做 init 的原子闭环）
-
-每次仅执行一个最小闭环：
-1. 读取 `session-progress.md` 与 `session-handoff.md`
-2. 运行 `harness:init`
-3. 运行 `harness:pack`
-4. 验证产物并更新 session 工件
-
-### Done Gate（禁止口头完成）
-
-仅当以下条件同时满足才允许标记 `flow:init` 为完成：
-- `harness-state.json.status == "initialized"`
-- `context-package.md` 存在且包含 Next Commands
-- `session-checklist.json` 中 `flow:init.passes == true`
-
-## Input Format
-
-```bash
-/flow:init "REQ_ID|TITLE|PLAN_URLS?"
-```
-
-- `REQ_ID`: `REQ-123` 或 `BUG-123`
-- `TITLE`: 需求标题
-- `PLAN_URLS`: 可选，逗号分隔
-
-## Execution Steps
-
-1. 解析输入，提取 `REQ_ID`、`TITLE`、`PLAN_URLS`。
-
-2. **读取项目级 specs/ 了解当前系统状态**（v4.3 新增）：
-   - 读取 `devflow/specs/README.md` 了解模块结构
-   - 扫描 `devflow/specs/*/spec.md` 识别相关模块
-   - 记录当前系统状态到上下文
-
-3. 组装 goal 文本：
-   - `Deliver <REQ_ID>: <TITLE>`
-   - 若有 URL，追加 `Sources: <URLS>`。
-
-4. 运行初始化：
-
-```bash
-npm run harness:init -- --change-id "${REQ_ID}" --goal "${GOAL}"
-```
-
-5. 运行上下文打包：
-
-```bash
-npm run harness:pack -- --change-id "${REQ_ID}" --goal "${GOAL}"
-```
-
-6. **生成 proposal.md**（v4.3 新增，替代 PRD.md）：
-   - 基于 TITLE 和 PLAN_URLS 生成 proposal.md
-   - 格式：Why（为什么需要）+ What（要做什么）
-   - 使用 `.claude/docs/templates/PROPOSAL_TEMPLATE.md`
-   - 输出到 `devflow/requirements/${REQ_ID}/proposal.md`
-
-7. **创建 specs/ 目录**（v4.3 新增）：
-   - 创建 `devflow/requirements/${REQ_ID}/specs/` 目录
-   - 准备存放 Delta spec.md
-
-8. 验证输出文件：
-   - `devflow/requirements/${REQ_ID}/harness-state.json`
-   - `devflow/requirements/${REQ_ID}/context-package.md`
-   - `devflow/requirements/${REQ_ID}/proposal.md` ⭐ 新增
-   - `devflow/requirements/${REQ_ID}/specs/` 目录存在 ⭐ 新增
-
-## Exit Criteria
-
-- `harness-state.json.status == "initialized"`
-- `context-package.md` 存在并包含 Next Commands 段落
-- `proposal.md` 存在且包含 Why 和 What 章节 ⭐ v4.3 新增
-- `specs/` 目录已创建 ⭐ v4.3 新增
-
-## Next Step
-
-```bash
-/flow:spec "${REQ_ID}"
-```

package/.claude/skills/flow-init/assets/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. 记录变更历史