Claude-Code-Workflow/PLANNING_GAP_ANALYSIS.md

Planning环节未考虑场景深度分析

分析日期: 2025-11-20 分析范围: /workflow:plan, /workflow:lite-plan, /workflow:tdd-plan, /workflow:replan, /cli:discuss-plan 分析目的: 识别软件开发生命周期中当前planning流程未充分支持的场景

---

执行摘要

当前planning系统设计完善，覆盖了标准软件开发流程的核心场景（新功能开发、TDD、重构、测试）。然而，通过对15类特殊开发场景的深入分析，发现以下关键空白：

高优先级缺失：

1. 遗留代码重构（无测试覆盖的安全重构）
2. 紧急修复流程（生产问题hotfix）
3. 数据迁移（需要回滚计划和验证）
4. 依赖升级（breaking changes处理）

中优先级缺失： 5. 增量式开发/Feature Flags 6. 多团队协作同步 7. 技术债务系统化管理 8. 性能优化专项（需要baseline和profiling）

---

1. 增量式开发/渐进式增强场景

场景描述

在现有功能基础上逐步增加复杂性，通过feature flags控制渐进式发布。

当前Planning的局限性

现有流程假设：

• /workflow:plan 生成的任务是完整的、独立的功能单元
• IMPL_PLAN.md 描述的是"一次性交付"的实现方案
• 验收标准(context.acceptance)是二元的（完成/未完成）

实际需求：

{
  "feature_strategy": "incremental",
  "phases": [
    {
      "phase": 1,
      "scope": "basic_functionality",
      "feature_flag": "new_auth_v1",
      "rollout_percentage": 5,
      "metrics": ["error_rate < 1%", "latency_p99 < 200ms"]
    },
    {
      "phase": 2,
      "scope": "advanced_features",
      "feature_flag": "new_auth_v2",
      "dependency": "phase_1_metrics_green",
      "rollout_percentage": 25
    }
  ],
  "rollback_trigger": "automated_on_metric_threshold"
}

Gap分析

维度	当前支持	缺失功能
任务分解	单阶段完整交付	❌ 多阶段渐进式任务链
验收标准	功能完成度	❌ 按阶段的指标监控
回滚计划	无	❌ Feature flag回滚策略
A/B测试	无	❌ 实验组/对照组配置

影响范围

• action-planning-agent.md: 需要支持phased_rollout策略
• workflow-architecture.md: flow_control.implementation_approach需要增加rollout_config字段
• Enhanced Task JSON Schema: 需要新字段deployment_strategy

建议改进

新增Planning模式: /workflow:plan --mode incremental

{
  "deployment_strategy": {
    "type": "feature_flag_rollout",
    "phases": [
      {
        "id": "alpha",
        "flag_config": {
          "name": "feature_x_alpha",
          "enabled_for": "internal_users"
        },
        "success_criteria": [
          "zero_critical_bugs",
          "positive_user_feedback > 80%"
        ],
        "duration": "1_week",
        "rollback_on": ["critical_bug", "negative_feedback > 30%"]
      }
    ],
    "monitoring": {
      "dashboards": ["feature_x_health"],
      "alerts": ["feature_x_error_rate"]
    }
  }
}

---

2. 遗留代码重构场景

场景描述

重构缺少测试覆盖的遗留代码，需要在不破坏现有功能的前提下逐步改进。

当前Planning的局限性

现有流程假设：

• Context gathering (/workflow:tools:context-gather) 假设代码库有良好的文档和测试
• TDD planning (/workflow:tdd-plan) 假设可以先写测试
• 验收标准假设可以通过测试验证

遗留代码现实：

Legacy System Characteristics:
├── No existing tests (coverage = 0%)
├── No documentation (last update: 5 years ago)
├── Original developers left
├── Critical business logic (cannot break)
├── Tightly coupled architecture
└── Unknown edge cases (production behavior is spec)

Gap分析

维度	当前支持	缺失功能
安全网构建	假设有测试	❌ Characterization tests生成
风险评估	基于代码分析	❌ 生产流量分析/影响范围评估
重构策略	直接重写	❌ Strangler Pattern/Branch by Abstraction
验证方法	单元测试	❌ 影子模式(Shadow Mode)/流量回放

影响范围

• test-context-gather: 当前假设tests/目录存在，需要处理coverage=0场景
• tdd-plan: Red-Green-Refactor不适用，需要Golden Master Testing
• conflict-resolution: 需要识别"遗留代码约束"类型的冲突

建议改进

新增Planning模式: /workflow:plan --legacy-refactor

Phase 1: 安全网构建

# 1. 生成Characterization Tests（捕获当前行为）
/workflow:tools:legacy-safety-net --session WFS-refactor
  → 分析生产日志提取真实输入
  → 录制当前输出作为Golden Master
  → 生成快照测试覆盖关键路径

# Output: Approval Tests for critical workflows

Phase 2: Strangler Pattern规划

{
  "refactor_strategy": "strangler_pattern",
  "steps": [
    {
      "step": 1,
      "action": "Create abstraction layer",
      "legacy_code_untouched": true,
      "new_interface": "PaymentGateway",
      "routing_logic": "feature_flag_controlled"
    },
    {
      "step": 2,
      "action": "Implement new module behind abstraction",
      "parallel_run": true,
      "comparison": "assert_output_parity(legacy, new)"
    },
    {
      "step": 3,
      "action": "Gradual traffic migration",
      "rollout": [1, 5, 25, 50, 100],
      "rollback_automatic": true
    }
  ]
}

---

3. 多团队协作场景

场景描述

跨团队开发，存在API依赖、共享代码库、并行开发同步等协作需求。

当前Planning的局限性

现有session管理假设：

.workflow/active/WFS-feature/  # 单团队单功能

多团队现实：

Teams:
├── Team A (Frontend) → 依赖 Team B的API
├── Team B (Backend) → 依赖 Team C的数据模型
└── Team C (Data) → 依赖 Team A的UI需求

Coordination Points:
├── API Contract定义 (需要提前锁定)
├── 集成测试环境 (需要协调部署窗口)
├── 共享组件库 (需要版本兼容性管理)
└── 代码review (需要跨团队审查)

Gap分析

维度	当前支持	缺失功能
依赖表达	task.depends_on (同session内)	❌ 跨session/跨团队依赖
API契约	代码实现后确定	❌ Contract-first设计
同步点	无	❌ Integration milestones
冲突预防	同一代码库检测	❌ 共享模块版本协调

影响范围

• workflow-session.json: 需要external_dependencies字段
• conflict-resolution: 需要检测跨session的模块冲突
• IMPL_PLAN.md: 需要"Coordination Points"章节

建议改进

新增命令: /workflow:plan --multi-team

{
  "session_id": "WFS-checkout-flow",
  "team": "frontend",
  "external_dependencies": [
    {
      "team": "backend",
      "session_id": "WFS-payment-api",
      "contract": {
        "type": "OpenAPI",
        "spec_path": "shared/contracts/payment-api-v2.yaml",
        "locked_at": "2025-10-15",
        "status": "approved"
      },
      "blocking_tasks": ["IMPL-1", "IMPL-2"],
      "ready_by": "2025-10-20"
    }
  ],
  "coordination_points": [
    {
      "milestone": "API Contract Freeze",
      "date": "2025-10-15",
      "attendees": ["frontend", "backend"],
      "deliverable": "OpenAPI spec v2 approved"
    },
    {
      "milestone": "Integration Test",
      "date": "2025-10-25",
      "environment": "staging",
      "cross_team_test_suite": "e2e/checkout_flow.spec.ts"
    }
  ]
}

---

4. 技术债务偿还场景

场景描述

系统化管理技术债务，在功能开发中平衡债务偿还，评估ROI和风险。

当前Planning的局限性

现有任务类型：

{
  "meta": {
    "type": "feature|bugfix|refactor|test|docs"
  }
}

技术债务特性：

• 非紧急但长期累积会造成严重影响
• 需要量化（利息成本、偿还成本）
• 需要优先级排序
• 可能跨越多个模块

Gap分析

维度	当前支持	缺失功能
债务识别	手动发现	❌ 自动检测（复杂度、重复代码、过时依赖）
债务量化	无	❌ 技术债务指标（利息成本、偿还工时）
优先级评估	主观判断	❌ ROI评分（影响×紧迫度/偿还成本）
穿插策略	无	❌ 在功能开发中配额式偿还债务

影响范围

• workflow:plan: 需要--tech-debt-mode识别债务
• action-planning-agent: 需要债务优先级算法
• Enhanced Task JSON: 需要debt_metrics字段

建议改进

新增命令: /workflow:debt:assess

/workflow:debt:assess --session WFS-feature
  → Scan codebase for debt indicators:
    - Cyclomatic complexity > 15
    - Duplicated code blocks > 50 lines
    - Dependencies with CVEs
    - TODO/FIXME comments > 6 months old
  → Generate debt inventory with ROI scores
  → Recommend debt paydown tasks

Debt Task JSON Schema:

{
  "id": "DEBT-001",
  "title": "Refactor UserService god class",
  "meta": {
    "type": "tech_debt",
    "debt_category": "complexity"
  },
  "debt_metrics": {
    "interest_cost": {
      "description": "每次修改需要额外30%时间理解代码",
      "monthly_cost_hours": 8
    },
    "paydown_cost": {
      "estimated_hours": 16,
      "risk_level": "medium"
    },
    "roi_score": 6.0,
    "priority": "high"
  },
  "bundled_with_feature": "IMPL-003"
}

---

5. 性能优化专项场景

场景描述

系统性能优化需要baseline建立、profiling分析、多次迭代实验，与常规功能开发流程不同。

当前Planning的局限性

现有验收标准：

{
  "acceptance": [
    "功能X实现完成",
    "测试覆盖率>80%"
  ]
}

性能优化验收标准：

{
  "acceptance": [
    "P95延迟从500ms降低到100ms",
    "CPU使用率从80%降低到40%",
    "内存占用减少30%",
    "QPS提升至10000"
  ],
  "measurement_method": "load_test_with_k6",
  "baseline": "current_production_metrics",
  "confidence_interval": "99%",
  "sample_size": "10000_requests"
}

Gap分析

维度	当前支持	缺失功能
Baseline建立	无	❌ 自动收集当前性能指标
Profiling集成	无	❌ 集成profiling工具（flamegraph, perf）
实验流程	无	❌ 优化→测量→对比→迭代循环
A/B对比	无	❌ 性能回归检测

影响范围

• flow_control.pre_analysis: 需要establish_baseline步骤
• flow_control.implementation_approach: 需要支持迭代式优化
• verification: 需要性能测试集成

建议改进

新增Planning模式: /workflow:plan --performance-optimization

{
  "performance_optimization": {
    "phase_0_baseline": {
      "steps": [
        {
          "action": "Capture current metrics",
          "tools": ["k6_load_test", "flamegraph_profiling"],
          "output": "baseline_report.json"
        },
        {
          "action": "Identify bottlenecks",
          "analysis": "flamegraph analysis shows DB query N+1 problem",
          "target": "reduce_db_roundtrips"
        }
      ]
    },
    "phase_1_optimization": {
      "hypothesis": "Batch DB queries to reduce roundtrips",
      "implementation": "IMPL-001",
      "verification": {
        "load_test": "k6 run scenarios/checkout.js",
        "success_criteria": "p95_latency < 200ms",
        "comparison": "baseline vs optimized"
      }
    },
    "phase_2_iteration": {
      "condition": "if p95_latency still > 150ms",
      "next_hypothesis": "Add Redis caching layer",
      "max_iterations": 3
    }
  }
}

---

6. 安全加固专项场景

场景描述

安全审计发现的修复、威胁建模、合规性要求（GDPR、SOC2）等安全相关工作。

当前Planning的局限性

现有风险检测：

{
  "conflict_detection": {
    "risk_level": "medium",
    "risk_factors": ["architecture_complexity"]
  }
}

安全专项需求：

• 威胁建模（STRIDE框架）
• 安全审计清单
• 合规性检查点
• 渗透测试后的修复优先级

Gap分析

维度	当前支持	缺失功能
威胁建模	无	❌ STRIDE/DREAD框架集成
漏洞优先级	无	❌ CVSS评分、利用难度评估
合规检查	无	❌ GDPR/HIPAA/SOC2检查清单
攻击面分析	无	❌ 入口点识别、数据流追踪

建议改进

新增Planning模式: /workflow:plan --security-hardening

{
  "security_hardening": {
    "threat_model": {
      "framework": "STRIDE",
      "assets": ["user_credentials", "payment_data"],
      "threats": [
        {
          "id": "T-001",
          "type": "Spoofing",
          "scenario": "攻击者伪造JWT token",
          "likelihood": "high",
          "impact": "critical",
          "mitigation_task": "IMPL-001"
        }
      ]
    },
    "audit_findings": [
      {
        "id": "CVE-2024-1234",
        "severity": "high",
        "cvss_score": 8.5,
        "affected_component": "express@4.17.1",
        "remediation": "IMPL-002"
      }
    ],
    "compliance": {
      "framework": "GDPR",
      "requirements": [
        {
          "article": "Article 17 (Right to erasure)",
          "current_status": "non_compliant",
          "gap": "用户数据删除功能缺失",
          "implementation": "IMPL-003"
        }
      ]
    }
  }
}

---

7. 数据迁移场景

场景描述

数据库schema变更、数据格式转换、系统迁移等需要数据迁移的场景。

当前Planning的局限性

现有flow_control：

{
  "implementation_approach": [
    {"step": 1, "title": "实现功能"},
    {"step": 2, "title": "编写测试"}
  ]
}

数据迁移流程：

1. 备份生产数据
2. 在staging环境验证迁移脚本
3. 准备回滚脚本
4. 制定停机时间窗口
5. 执行迁移
6. 验证数据一致性
7. 监控应用健康
8. 必要时执行回滚

Gap分析

维度	当前支持	缺失功能
回滚计划	无	❌ 强制要求回滚脚本
数据验证	无	❌ 一致性检查、数据抽样对比
分阶段迁移	无	❌ 增量迁移、双写策略
停机窗口	无	❌ 时间预估、通知机制

建议改进

新增Planning模式: /workflow:plan --data-migration

{
  "data_migration": {
    "migration_type": "schema_change",
    "estimated_downtime": "30_minutes",
    "affected_tables": ["users", "orders"],
    "record_count": 10000000,
    "strategy": "online_migration",
    "phases": [
      {
        "phase": "pre_migration",
        "tasks": [
          "IMPL-001: 创建新schema",
          "IMPL-002: 实现双写逻辑（写旧表+新表）",
          "IMPL-003: 编写验证脚本"
        ]
      },
      {
        "phase": "migration",
        "tasks": [
          "IMPL-004: 批量迁移历史数据",
          "verification": "每1000条记录对比checksum"
        ]
      },
      {
        "phase": "post_migration",
        "tasks": [
          "IMPL-005: 切换读取到新表",
          "IMPL-006: 停止双写，删除旧表"
        ]
      }
    ],
    "rollback_plan": {
      "trigger": "data_inconsistency_detected",
      "steps": [
        "停止应用",
        "从备份恢复",
        "验证数据完整性"
      ],
      "script": "scripts/rollback_migration_001.sql"
    }
  }
}

---

8. 紧急修复场景

场景描述

生产环境严重问题需要立即修复，时间压力下简化流程。

当前Planning的局限性

现有最快流程: /workflow:lite-plan

• 仍然包含完整的exploration和planning阶段
• 没有"紧急模式"的流程简化
• 缺少hotfix分支管理

紧急修复实际需求：

时间线:
├── T+0: 生产故障告警
├── T+5min: 确认问题根因
├── T+15min: 代码修复完成
├── T+20min: 快速验证（非完整测试）
├── T+25min: 部署到生产
└── T+30min: 监控确认修复

Gap分析

维度	当前支持	缺失功能
流程简化	标准流程	❌ 紧急模式跳过非关键步骤
快速验证	完整测试套件	❌ Smoke test快速验证
Hotfix分支	标准分支策略	❌ 从production tag创建hotfix分支
事后补充	无	❌ 生成"技术债务"任务补充完整修复

建议改进

新增命令: /workflow:hotfix

/workflow:hotfix --critical "修复支付失败问题" --incident INC-2024-1015

简化流程：

{
  "hotfix_mode": true,
  "incident_id": "INC-2024-1015",
  "severity": "critical",
  "phases": [
    {
      "phase": "diagnosis",
      "max_duration": "10_minutes",
      "action": "快速根因分析",
      "skip": ["deep_code_exploration"]
    },
    {
      "phase": "fix",
      "branch_strategy": "hotfix_from_production_tag",
      "implementation": "IMPL-HOTFIX-001",
      "skip": ["comprehensive_testing", "code_review"]
    },
    {
      "phase": "verification",
      "test_level": "smoke_test_only",
      "acceptance": ["关键路径验证通过"]
    },
    {
      "phase": "deployment",
      "approval": "incident_commander",
      "monitoring": "real_time_error_rate"
    }
  ],
  "follow_up_tasks": [
    {
      "id": "IMPL-001",
      "title": "补充完整测试覆盖",
      "type": "tech_debt",
      "due_date": "within_3_days"
    },
    {
      "id": "IMPL-002",
      "title": "根因分析报告",
      "type": "docs",
      "due_date": "within_1_week"
    }
  ]
}

---

9. 依赖升级场景

场景描述

升级第三方库、框架或运行时版本，处理breaking changes和兼容性问题。

当前Planning的局限性

现有依赖处理：

{
  "dependencies": {
    "internal": [...],
    "external": [...]
  }
}

仅列出依赖，不处理升级策略。

依赖升级实际需求：

Example: React 17 → React 18
├── Breaking Changes识别
│   ├── 自动批处理行为变更
│   └── Suspense API变化
├── 兼容性测试
│   ├── 运行完整测试套件
│   └── 手动测试关键流程
├── 渐进式升级
│   ├── 先升级dev dependencies
│   └── 再升级production dependencies
└── 降级回退方案
    └── package.json.backup

Gap分析

维度	当前支持	缺失功能
Breaking Changes分析	无	❌ 自动扫描changelog
兼容性测试	标准测试	❌ 依赖升级专项测试策略
降级方案	无	❌ 快速回退到旧版本
分阶段升级	无	❌ dev → staging → production策略

建议改进

新增Planning模式: /workflow:plan --dependency-upgrade

/workflow:plan --dependency-upgrade "React 17 → 18"

{
  "dependency_upgrade": {
    "package": "react",
    "from_version": "17.0.2",
    "to_version": "18.2.0",
    "breaking_changes": [
      {
        "change": "Automatic batching",
        "impact": "setState调用行为变更",
        "affected_files": ["src/components/Form.tsx"],
        "mitigation": "IMPL-001: 审查状态更新逻辑"
      }
    ],
    "testing_strategy": {
      "unit_tests": "全量运行",
      "integration_tests": "全量运行",
      "e2e_tests": "关键路径",
      "manual_testing": "regression_test_checklist.md"
    },
    "rollout_plan": {
      "stage_1": "dev_environment",
      "stage_2": "staging_environment",
      "stage_3": "production_canary_10%",
      "stage_4": "production_full_rollout"
    },
    "rollback_plan": {
      "backup": "package.json + package-lock.json",
      "quick_revert": "git revert <commit> && npm install"
    }
  }
}

---

10. 实验性探索场景 (Spike/POC)

场景描述

技术可行性验证、原型开发、快速失败的研究性工作。

当前Planning的局限性

现有验收标准：

• 假设任务有明确的成功标准
• 假设所有任务都会"完成"

Spike任务特点：

• 时间盒限制（固定时间后必须停止）
• 可能结论是"不可行"（这也是成功）
• 输出是"学习成果"而非"生产代码"

Gap分析

维度	当前支持	缺失功能
时间盒	无	❌ 固定时间预算（探索2天后必须决策）
成功定义	功能完成	❌ "获得足够信息做决策"即成功
输出形式	代码	❌ ADR (Architecture Decision Record)
并行探索	无	❌ 同时探索多个技术方案

建议改进

新增Planning模式: /workflow:spike

/workflow:spike --timebox 2days "评估三种状态管理方案"

{
  "spike_config": {
    "research_question": "选择合适的状态管理方案",
    "timebox": "2_days",
    "parallel_explorations": [
      {
        "id": "SPIKE-001",
        "approach": "Redux Toolkit",
        "success_criteria": "实现一个代表性功能，评估开发体验"
      },
      {
        "id": "SPIKE-002",
        "approach": "Zustand",
        "success_criteria": "同样功能对比代码量和性能"
      },
      {
        "id": "SPIKE-003",
        "approach": "Jotai",
        "success_criteria": "评估学习曲线和文档质量"
      }
    ],
    "decision_criteria": [
      "开发体验 (权重40%)",
      "性能 (权重30%)",
      "生态系统 (权重20%)",
      "团队熟悉度 (权重10%)"
    ],
    "output": {
      "type": "ADR",
      "path": "docs/adr/0005-state-management-choice.md",
      "includes": [
        "各方案优缺点对比",
        "推荐方案和理由",
        "POC代码链接"
      ]
    },
    "post_spike": {
      "decision": "proceed_with_zustand",
      "follow_up_task": "IMPL-001: 迁移到Zustand"
    }
  }
}

---

11-15. 其他场景简要分析

11. 多版本并行维护场景

Gap: 当前session管理假设单版本开发 需求: 需要支持version_branch字段，安全补丁向多版本移植 建议: /workflow:plan --version v2.x --backport-to v1.x,v1.y

12. 监控和可观测性增强场景

Gap: 当前planning关注业务功能，忽略运维需求 需求: SLI/SLO定义、日志/指标/追踪规划、告警规则设计 建议: /workflow:plan --observability 生成包含监控配置的任务

13. 文档补充场景

Gap: 文档任务缺少模板和验证标准 需求: API文档自动生成、ADR模板、代码注释覆盖率 建议: /workflow:plan --docs-type api|adr|inline 根据类型生成结构化任务

14. DevOps流程改进场景

Gap: Planning聚焦应用代码，忽略基础设施代码 需求: Terraform/Ansible代码规划、CI/CD pipeline优化 建议: /workflow:plan --infra-as-code 支持IaC任务规划

15. 可访问性(A11y)改进场景

Gap: 缺少WCAG标准合规检查 需求: 屏幕阅读器测试、键盘导航、ARIA标签审计 建议: /workflow:plan --a11y 生成可访问性测试任务

---

优先级建议

🔴 高优先级（建议立即实现）

1. 遗留代码重构支持 (/workflow:plan --legacy-refactor)

   • 理由: 大量实际项目面临遗留代码维护
   • 实现成本: 中等（新增safety-net工具 + strangler pattern模板）
   • 影响范围: test-context-gather, tdd-plan

2. 紧急修复流程 (/workflow:hotfix)

   • 理由: 生产问题需要快速响应
   • 实现成本: 低（简化现有流程 + hotfix分支策略）
   • 影响范围: 新增独立命令

3. 数据迁移专项 (/workflow:plan --data-migration)

   • 理由: 数据迁移风险高，需要强制回滚计划
   • 实现成本: 中等（新增migration-specific验证步骤）
   • 影响范围: flow_control schema, verification phase

🟡 中优先级（建议3个月内实现）

4. 依赖升级管理 (/workflow:plan --dependency-upgrade)
5. 增量式发布 (/workflow:plan --mode incremental)
6. 技术债务管理 (/workflow:debt:assess)
7. 性能优化专项 (/workflow:plan --performance-optimization)

🟢 低优先级（可选增强）

8-15. 其他场景

---

实现路线图

Phase 1: 核心场景支持（Sprint 1-2）

• /workflow:hotfix - 紧急修复快速通道
• /workflow:plan --legacy-refactor - 遗留代码安全重构
• Enhanced Task JSON Schema扩展（支持新场景字段）

Phase 2: 高级场景支持（Sprint 3-4）

• /workflow:plan --data-migration - 数据迁移规划
• /workflow:plan --dependency-upgrade - 依赖升级管理
• /workflow:debt:assess - 技术债务评估

Phase 3: 专项优化（Sprint 5-6）

• /workflow:plan --performance-optimization - 性能优化流程
• /workflow:plan --security-hardening - 安全加固
• /workflow:plan --multi-team - 多团队协作

Phase 4: 长尾场景（按需实现）

• /workflow:spike - 实验性探索
• 其他场景

---

技术实现建议

1. 扩展Enhanced Task JSON Schema

当前schema (5个核心字段):

{
  "id": "...",
  "title": "...",
  "status": "...",
  "meta": {...},
  "context": {...},
  "flow_control": {...}
}

扩展字段建议:

{
  "scenario_type": "legacy_refactor|data_migration|hotfix|...",
  "scenario_config": {
    // 场景特定配置，根据scenario_type动态验证
  }
}

2. 命令层扩展

新增参数: --scenario <type> 或 --mode <type>

/workflow:plan --scenario legacy-refactor "重构支付模块"
/workflow:plan --scenario data-migration "迁移用户表schema"
/workflow:hotfix --critical "修复内存泄漏"

3. Agent增强

action-planning-agent.md 需要支持:

• 场景识别逻辑
• 场景特定的pre_analysis步骤
• 场景特定的验收标准模板

---

结论

当前Planning系统在标准软件开发流程上设计优秀，但在以下15类特殊场景存在支持空白：

关键发现:

1. 遗留代码、紧急修复、数据迁移是最紧迫的缺失场景
2. 当前系统架构具备良好扩展性，可通过scenario_type字段扩展
3. 建议采用渐进式实现策略，优先支持高影响场景

影响评估:

• 高: 遗留代码重构、紧急修复、数据迁移（影响50%+实际项目）
• 中: 依赖升级、技术债务、性能优化（影响30%项目）
• 低: 其他场景（影响<20%项目，但对特定领域关键）

下一步行动:

1. 评审本分析报告，确认优先级
2. 设计Enhanced Task JSON Schema扩展方案
3. 实现Phase 1高优先级场景（预计2个sprint）
4. 迭代收集用户反馈，调整后续优先级

---

文档版本: 1.0 作者: Claude (Sonnet 4.5) 审阅状态: 待审阅