cc-devflow 4.3.0 → 4.4.1

package/.claude/guides/workflow-guides/bug-fix-orchestrator.md

@@ -1,217 +0,0 @@
----
-name: bug-fix-orchestrator-guide
-description: Standard Operating Procedure for main agent when executing /flow-fix command. Not an executable agent, but workflow guidance.
-type: workflow-guide
----
-
-# BUG修复流程标准作业程序
-
-当用户执行 `/flow-fix "BUG描述"` 时，主 Agent (Claude 本身) 应按以下标准流程操作：
-
-## 核心原则 (遵循 Claude Code 最佳实践)
-
-### 主 Agent 职责
-- **完整上下文管理**: 主 Agent 拥有项目全貌，负责所有代码修复
-- **Sub-agent 协调**: 调用研究型 sub-agents 收集专业信息和制定计划
-- **最终实施**: 基于所有研究报告和计划，主 Agent 直接执行代码修复
-
-### Sub-agent 定位
-- **研究员角色**: 仅提供研究报告、分析文档、修复计划
-- **无代码执行**: 不直接修改项目文件，只输出 Markdown 文档
-- **专业分工**: 各自在专业领域提供深度分析和建议
-
-### 工作流原则
-1. **快速响应**: BUG修复优先级高于新功能开发
-2. **谨慎操作**: 避免引入新问题和破坏性变更
-3. **充分测试**: 重点验证BUG修复和回归测试
-4. **安全第一**: 确保修复不引入安全风险
-
-## Rules Integration
-遵循与flow-orchestrator相同的规则集成，但适配BUG修复场景
-
-## 标准作业流程
-
-### 阶段1: BUG分析和规划
-1. **BUG技术分析**
-   ```bash
-   Task: bug-analyzer "Analyze BUG symptoms and investigate root cause for ${bugId}: ${description}"
-   ```
-
-   - bug-analyzer 深入分析BUG症状和根本原因
-   - bug-analyzer 输出: `ANALYSIS.md`
-   - 主 Agent 审查分析结果
-
-2. **修复规划**
-   ```bash
-   Task: planner "Based on BUG analysis, create detailed fix plan for ${bugId}"
-   ```
-
-   - planner 基于 ANALYSIS.md 生成详细的修复计划
-   - planner 输出: `PLAN.md` 和 `tasks/TASK_*.md`
-   - 主 Agent 审查修复计划的可行性
-
-### 阶段2: 修复准备
-3. **测试计划**（代码修复前）
-   ```bash
-   Task: qa-tester "Create comprehensive test plan for BUG fix ${bugId} based on analysis and plan"
-   ```
-
-   - qa-tester 输出: `TEST_PLAN.md`
-   - 包含: 回归测试策略、BUG复现测试、验证测试
-   - **触发词**: 包含 "test plan" 的提示词
-
-4. **安全评估计划**（代码修复前）
-   ```bash
-   Task: security-reviewer "Create comprehensive security plan for BUG fix ${bugId} based on analysis"
-   ```
-
-   - security-reviewer 输出: `SECURITY_PLAN.md`
-   - 包含: 安全风险评估、修复安全检查、防护措施
-   - **触发词**: 包含 "security plan" 的提示词
-
-### 阶段3: 主 Agent 代码修复
-5. **代码修复**
-   - 主 Agent 基于详细的 PLAN.md 和 TASK 文档直接修复代码
-   - 遵循现有项目模式和约定
-   - 实施所有 TASK 的修复要求
-   - 优先保证向后兼容性
-
-### 阶段4: 质量验证（代码修复后）
-6. **测试执行和报告**
-   ```bash
-   Task: qa-tester "Analyze BUG fix implementation and generate comprehensive test report for ${bugId}"
-   ```
-
-   - 主 Agent 基于 TEST_PLAN.md 编写和执行测试
-   - qa-tester 分析测试结果，输出: `TEST_REPORT.md`
-   - 包含: BUG验证结果、回归测试结果、质量评估
-   - **触发词**: 包含 "test report" 的提示词
-
-7. **安全检查和报告**
-   ```bash
-   Task: security-reviewer "Analyze BUG fix implementation and generate comprehensive security report for ${bugId}"
-   ```
-
-   - security-reviewer 分析修复代码，输出: `SECURITY_REPORT.md`
-   - 包含: 安全回归扫描、风险评估、修复验证
-   - **触发词**: 包含 "security report" 的提示词
-
-8. **发布准备**
-   ```bash
-   Task: release-manager "Create release plan for BUG fix ${bugId} based on quality reports"
-   ```
-
-   - release-manager 输出: `RELEASE_PLAN.md`
-   - 包含: 热修复发布流程、回滚计划、部署策略
-
-### 阶段5: 发布执行
-9. **质量闸检查**
-   - 主 Agent 确保所有质量要求满足
-   - 修复 TEST_REPORT.md 和 SECURITY_REPORT.md 中发现的问题
-   - 验证BUG确实已修复且无回归
-
-10. **发布和合并**
-   - 主 Agent 基于 RELEASE_PLAN.md 创建 PR
-   - 执行最终质量闸检查
-   - 处理代码合并流程（通常使用快速发布流程）
-
-### 阶段6: 总结和归档
-11. **文档更新**
-    - 更新相关文档和说明
-    - 记录修复过程和决策
-    - 更新 BUG 跟踪状态
-
-12. **执行日志**
-    - 在 LOG.md 中记录完整修复过程
-    - 包含时间线、决策点、问题解决
-
-## 文档结构
-
-```text
-devflow/bugs/${bugId}/
-├── ANALYSIS.md           # BUG分析报告
-├── PLAN.md               # 修复计划
-├── tasks/                # 修复任务分解
-│   ├── TASK_001.md
-│   ├── TASK_002.md
-│   └── ...
-├── TEST_PLAN.md          # 测试计划
-├── TEST_REPORT.md        # 测试报告
-├── SECURITY_PLAN.md      # 安全计划
-├── SECURITY_REPORT.md    # 安全报告
-├── RELEASE_PLAN.md       # 发布计划
-├── status.json           # BUG状态跟踪
-└── LOG.md               # 执行日志
-```
-
-## 分支策略
-
-- **分支命名**: `bugfix/${bugId}-${kebab-case-描述}`
-- **合并策略**:
-  - 紧急BUG: 直接合并到 main 分支
-  - 一般BUG: squash merge 到 main 分支
-- **分支清理**: 合并后自动删除
-
-## BUG修复特殊考虑
-
-### 优先级管理
-- Critical: 立即修复，可能需要热修复
-- High: 下一个sprint修复
-- Medium: 计划修复
-- Low: 后续版本修复
-
-### 回归预防
-- 必须包含回归测试
-- 修复范围最小化
-- 充分的代码审查
-
-### 紧急发布流程
-- 跳过部分质量闸（但不跳过安全检查）
-- 快速发布到生产环境
-- 后续补充完整测试
-
-## Agent Coordination Protocol
-
-### BUG Status Management
-```json
-// devflow/bugs/${bugId}/status.json
-{
-  "bugId": "${bugId}",
-  "description": "${description}",
-  "severity": "high",
-  "status": "fixing",
-  "progress": 60,
-  "currentPhase": "implementation",
-  "startTime": "2024-01-15T10:30:00Z",
-  "phaseStatus": {
-    "analysis": "completed",
-    "planning": "completed",
-    "implementation": "in_progress",
-    "testing": "pending",
-    "security": "pending",
-    "release": "pending"
-  },
-  "fixFiles": ["src/auth/login.js", "src/api/user.js"],
-  "testStatus": {
-    "bugReproduced": true,
-    "fixVerified": false,
-    "regressionPassed": false
-  }
-}
-```
-
-### 错误处理
-- 如果BUG无法复现，暂停并要求更多信息
-- 如果修复引入新问题，回滚并重新分析
-- 如果质量闸失败，阻止发布
-
-## Key Implementation Notes
-
-**REMEMBER**: 这是主 Agent 的工作流指南。主 Agent 应调用研究型 sub-agents 进行分析和规划，然后直接执行所有实际的代码修复、测试和git操作，基于从sub-agents收到的计划。
-
-BUG修复比新功能开发更注重：
-- 快速响应和修复
-- 最小化变更范围
-- 充分的回归测试
-- 安全性验证
-- 快速发布流程

package/.claude/guides/workflow-guides/flow-orchestrator.md

@@ -1,48 +0,0 @@
----
-name: flow-orchestrator-guide
-description: Standard Operating Procedure for main agent when executing canonical /flow:* delivery chain.
-type: workflow-guide
----
-
-# 需求开发流程标准作业程序（主链版）
-
-当用户执行需求交付时，主 Agent 按显式主链推进：
-
-```text
-/flow:init -> /flow:spec -> /flow:dev -> /flow:verify -> /flow:release
-```
-
-## 主 Agent 职责
-- 维护全局上下文与最终实现。
-- 仅把研究/规划/审查任务分发给对应子代理。
-- 在每个阶段结束后写入状态与审计日志。
-
-## 阶段作业
-
-### 1) 初始化 `/flow:init`
-- 创建需求目录与运行时上下文。
-- 写入初始 `orchestration_status.json`。
-
-### 2) 规格与任务 `/flow:spec`
-- 统一完成 PRD、技术方案、UI 约束（按模式可裁剪）。
-- 产出可执行 `TASKS.md`，进入 `spec_complete`。
-
-### 3) 开发执行 `/flow:dev`
-- 按 task manifest 执行并更新进度。
-- 失败任务通过 `--resume` 增量恢复。
-
-### 4) 质量闸 `/flow:verify`
-- 快速模式用于日常检查。
-- `--strict` 作为发布前唯一准入门禁。
-
-### 5) 发布收口 `/flow:release`
-- 仅在 verify 通过后创建发布产物。
-- 收尾清理 runtime/worktree 噪音。
-
-## 失败恢复原则
-- 不回退整条链，优先从失败阶段重试。
-- 优先命令：`/flow:status`、`/flow:dev --resume`、`/flow:verify --strict`。
-
-## 约束
-- 必须遵循项目宪法与质量门禁。
-- 禁止把旧链路命令（如 `/flow-new`）作为主流程推荐。

package/.claude/hooks/CLAUDE.md

@@ -1,342 +0,0 @@
-# hooks/ - Claude Code Hooks
-
-> L2 | 父级: `.claude/CLAUDE.md`
-
-## Purpose
-
-Claude Code CLI 钩子脚本，在工具调用前后执行自定义逻辑。
-
-## Members
-
-| File | Purpose | Trigger |
-|------|---------|---------|
-| `inject-agent-context.ts` | Task 工具上下文注入 [v4.4] | PreToolUse(Task) |
-| `inject-skill-context.ts` | Skill 上下文注入 | PreToolUse(Skill) |
-| `pre-tool-use-guardrail.sh` | Edit/Write 前置检查 | PreToolUse(Edit\|Write) |
-| `post-tool-use-tracker.sh` | 文件修改追踪 | PostToolUse(Edit\|Write) |
-| `skill-activation-prompt.sh` | Skill 激活提示 | UserPromptSubmit |
-| `error-handling-reminder.sh` | 错误处理提醒 | Stop |
-| `ralph-loop.ts` | Ralph Loop 程序化验证 [v4.7 Team 模式] | SubagentStop |
-| `teammate-idle-hook.ts` | Team 任务调度器 [v4.7] | TeammateIdle |
-| `task-completed-hook.ts` | 任务完成验证器 [v4.7] | TaskCompleted |
-| `checklist-gate.js` | Checklist 质量门 | Custom |
-| `types/team-types.d.ts` | Team 状态 TypeScript 类型定义 [v4.7] | N/A |
-
-## Hook Registration (settings.json)
-
-```json
-{
-  "hooks": {
-    "PreToolUse": [
-      {"matcher": "Edit|Write", "command": "pre-tool-use-guardrail.sh"},
-      {"matcher": "Task", "command": "inject-agent-context.ts"}
-    ],
-    "PostToolUse": [
-      {"matcher": "Edit|Write", "command": "post-tool-use-tracker.sh"}
-    ],
-    "SubagentStop": [
-      {"command": "ralph-loop.ts"}
-    ],
-    "TeammateIdle": [
-      {"command": "teammate-idle-hook.ts"}
-    ],
-    "TaskCompleted": [
-      {"command": "task-completed-hook.ts"}
-    ]
-  }
-}
-```
-
-## inject-agent-context.ts (v4.4)
-
-借鉴 Trellis 的 `inject-subagent-context.py` 实现。
-
-### 工作流程
-
-```
-Task(subagent_type="dev-implementer", prompt="...")
-    ↓
-Hook 检测到 Task 工具调用
-    ↓
-获取 REQ-ID (环境变量 > .current-task > 分支名)
-    ↓
-查找 JSONL 文件:
-  1. devflow/requirements/{REQ}/context/dev-implementer.jsonl
-  2. .claude/skills/workflow/flow-dev/dev-implementer.jsonl
-  3. .claude/skills/workflow/flow-dev/context.jsonl
-    ↓
-解析 JSONL，读取文件内容
-    ↓
-注入到 prompt 参数中
-```
-
-### JSONL 格式 (Trellis 风格)
-
-```jsonl
-{"file": "devflow/requirements/{REQ}/TASKS.md", "reason": "Task list"}
-{"file": "devflow/spec/frontend/index.md", "reason": "Frontend conventions", "optional": true}
-{"file": "src/components/", "type": "directory", "reason": "Existing patterns"}
-```
-
-### Agent 映射
-
-| subagent_type | Skill Directory | JSONL File |
-|---------------|-----------------|------------|
-| dev-implementer | flow-dev | dev-implementer.jsonl |
-| prd-writer | flow-spec | prd-writer.jsonl |
-| tech-architect | flow-spec | tech-architect.jsonl |
-| planner | flow-spec | planner.jsonl |
-| qa-tester | flow-verify | qa-tester.jsonl |
-
-## ralph-loop.ts (v4.7 Team 模式)
-
-SubagentStop 钩子，支持单 Agent 和多 Teammate 两种模式。
-
-### 单 Agent 模式 (原有逻辑)
-
-```
-SubagentStop Event
-    ↓
-加载 .ralph-state.json
-    ↓
-检查超时/最大迭代
-    ↓
-执行 verify 命令
-    ↓
-通过 → allow | 失败 → block
-```
-
-### Team 模式 (v4.7 新增)
-
-```
-SubagentStop Event (with teammate_id)
-    ↓
-加载 orchestration_status.json
-    ↓
-检查 Team 模式是否启用
-    ↓
-检查 Teammate 迭代次数 / 全局迭代次数
-    ↓
-执行 Teammate 级别验证 (teammate_verify)
-    ↓
-验证失败 → block (更新 ralphLoop.teammates[id])
-验证通过 → 检查是否最后一个活跃 Teammate
-    ↓
-是最后一个 → 执行全局验证 (global_verify)
-    ↓
-全局通过 → allow | 全局失败 → block
-不是最后一个 → allow
-```
-
-### 输入格式 (Team 模式扩展)
-
-```typescript
-interface HookInput {
-  hook_event_name: 'SubagentStop';
-  cwd: string;
-  session_id: string;
-  // Team 模式扩展
-  teammate_id?: string;
-  teammate_role?: string;
-}
-```
-
-### 配置 (quality-gates.yml)
-
-```yaml
-ralph_loop:
-  max_iterations: 5
-  timeout_minutes: 30
-
-  team_mode:
-    enabled: true
-    scope: teammate
-
-    teammate_verify:
-      dev-frontend:
-        - npm run lint -- --files-changed
-        - npm run typecheck --if-present
-      dev-backend:
-        - npm run lint -- --files-changed
-        - npm test -- --changed
-
-    global_verify:
-      - npm run lint
-      - npm run typecheck --if-present
-      - npm test -- --passWithNoTests
-
-    max_iterations_per_teammate: 3
-    max_global_iterations: 10
-```
-
-### 状态存储
-
-**单 Agent 模式**: `.ralph-state.json`
-```json
-{
-  "agent_id": "session-xxx",
-  "iteration": 2,
-  "last_failures": [...],
-  "started_at": "2026-02-07T10:00:00Z"
-}
-```
-
-**Team 模式**: `orchestration_status.json` 中的 `ralphLoop` 字段
-```json
-{
-  "ralphLoop": {
-    "enabled": true,
-    "teammates": {
-      "dev-frontend": {
-        "iteration": 2,
-        "lastVerifyResult": "passed",
-        "lastVerifyAt": "2026-02-07T10:00:00Z"
-      }
-    },
-    "globalIteration": 5,
-    "maxIterations": 10,
-    "startedAt": "2026-02-07T09:00:00Z"
-  }
-}
-```
-
-## teammate-idle-hook.ts (v4.7)
-
-Team 模式下的任务调度器，在 Teammate 空闲时触发。
-
-### 工作流程
-
-```
-TeammateIdle Event
-    ↓
-验证 hook_event_name === 'TeammateIdle'
-    ↓
-如果有 last_task_id，执行 idle_checks 验证
-    ↓
-验证失败 → 返回 assign_task (继续修复)
-验证通过 → 标记任务完成
-    ↓
-查找下一个未分配任务
-    ↓
-有任务 → 返回 assign_task
-无任务 + 所有 Teammate 空闲 → 返回 shutdown
-无任务 + 有 Teammate 工作中 → 返回 wait
-```
-
-### 输入格式 (TeammateIdleInput)
-
-```typescript
-{
-  hook_event_name: 'TeammateIdle',
-  teammate_id: string,
-  teammate_role: string,
-  last_task_id?: string,
-  idle_reason: 'task_complete' | 'waiting_dependency' | 'no_tasks' | 'error',
-  cwd: string,
-  session_id: string
-}
-```
-
-### 输出格式 (TeammateIdleOutput)
-
-```typescript
-{
-  action: 'assign_task' | 'wait' | 'shutdown',
-  task_id?: string,
-  message?: string
-}
-```
-
-### 配置 (quality-gates.yml)
-
-```yaml
-teammate_idle:
-  idle_checks:
-    - npm run lint --if-present
-    - npm run typecheck --if-present
-    - npm test -- --passWithNoTests
-  assignment_strategy: priority_first
-```
-
-## task-completed-hook.ts (v4.7)
-
-任务完成时的质量验证钩子。
-
-### 工作流程
-
-```
-TaskCompleted Event
-    ↓
-验证 hook_event_name === 'TaskCompleted'
-    ↓
-加载 quality-gates.yml 配置
-    ↓
-执行 task_completed.verify 命令
-    ↓
-    ├── 通过 → accept + 更新 Team 状态
-    └── 失败 → block_on_failure?
-                ├── true → reject
-                └── false → accept (with warning)
-    ↓
-记录失败到 ERROR_LOG.md
-    ↓
-检查阶段转换
-```
-
-### 配置 (quality-gates.yml)
-
-```yaml
-task_completed:
-  verify:
-    - npm run lint --if-present
-    - npm run typecheck --if-present
-    - npm test -- --passWithNoTests
-  block_on_failure: true
-  max_retries: 3
-```
-
-### 输入格式
-
-```typescript
-interface TaskCompletedInput {
-  hook_event_name: 'TaskCompleted';
-  task_id: string;
-  task_subject: string;
-  completed_by: string;
-  completion_time: string;
-  cwd: string;
-  session_id: string;
-}
-```
-
-### 输出格式
-
-```typescript
-interface TaskCompletedOutput {
-  decision: 'accept' | 'reject';
-  reason: string;
-  next_actions?: string[];
-}
-```
-
-## types/ - TypeScript 类型定义 (v4.7)
-
-### team-types.d.ts
-
-Team 集成的核心类型定义，被 teammate-idle-hook.ts 和 task-completed-hook.ts 消费。
-
-**主要类型**:
-
-| Type | Purpose |
-|------|---------|
-| `TeammateState` | Teammate 状态 (id, role, status, currentTask, completedTasks) |
-| `TeamState` | Team 状态 (mode, lead, teammates, taskAssignments) |
-| `RalphLoopTeamState` | Ralph Loop Team 模式状态 |
-| `OrchestrationStatus` | 扩展的 orchestration_status.json 类型 |
-| `TeammateIdleInput/Output` | TeammateIdle Hook 输入/输出 |
-| `TaskCompletedInput/Output` | TaskCompleted Hook 输入/输出 |
-| `QualityGatesTeamConfig` | quality-gates.yml Team 配置 |
-
----
-
-[PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md