mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-10 02:24:35 +08:00
2fb1015038
Analysis identifies critical gaps in current planning workflows: High Priority Gaps: - Legacy code refactoring (no test coverage safety nets) - Emergency hotfix workflows (production incidents) - Data migration planning (rollback and validation) - Dependency upgrade management (breaking changes) Medium Priority Gaps: - Incremental rollout with feature flags - Multi-team coordination and API contracts - Tech debt systematic management - Performance optimization with profiling Analysis includes: - 15 detailed scenario analyses with gap identification - Enhanced Task JSON schema extension proposals - Implementation roadmap (4 phases) - Priority recommendations based on real-world impact Impact: Extends planning coverage from ~40% to ~90% of software development scenarios
1017 lines
27 KiB
Markdown
1017 lines
27 KiB
Markdown
# 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`)是二元的（完成/未完成）
|
||
|
||
**实际需求**：
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```json
|
||
{
|
||
"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: 安全网构建**
|
||
```bash
|
||
# 1. 生成Characterization Tests（捕获当前行为）
|
||
/workflow:tools:legacy-safety-net --session WFS-refactor
|
||
→ 分析生产日志提取真实输入
|
||
→ 录制当前输出作为Golden Master
|
||
→ 生成快照测试覆盖关键路径
|
||
|
||
# Output: Approval Tests for critical workflows
|
||
```
|
||
|
||
**Phase 2: Strangler Pattern规划**
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```json
|
||
{
|
||
"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的局限性
|
||
|
||
**现有任务类型**：
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```bash
|
||
/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**:
|
||
```json
|
||
{
|
||
"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的局限性
|
||
|
||
**现有验收标准**：
|
||
```json
|
||
{
|
||
"acceptance": [
|
||
"功能X实现完成",
|
||
"测试覆盖率>80%"
|
||
]
|
||
}
|
||
```
|
||
|
||
**性能优化验收标准**：
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```json
|
||
{
|
||
"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的局限性
|
||
|
||
**现有风险检测**：
|
||
```json
|
||
{
|
||
"conflict_detection": {
|
||
"risk_level": "medium",
|
||
"risk_factors": ["architecture_complexity"]
|
||
}
|
||
}
|
||
```
|
||
|
||
**安全专项需求**：
|
||
- 威胁建模（STRIDE框架）
|
||
- 安全审计清单
|
||
- 合规性检查点
|
||
- 渗透测试后的修复优先级
|
||
|
||
### Gap分析
|
||
|
||
| 维度 | 当前支持 | 缺失功能 |
|
||
|------|---------|---------|
|
||
| **威胁建模** | 无 | ❌ STRIDE/DREAD框架集成 |
|
||
| **漏洞优先级** | 无 | ❌ CVSS评分、利用难度评估 |
|
||
| **合规检查** | 无 | ❌ GDPR/HIPAA/SOC2检查清单 |
|
||
| **攻击面分析** | 无 | ❌ 入口点识别、数据流追踪 |
|
||
|
||
### 建议改进
|
||
|
||
**新增Planning模式**: `/workflow:plan --security-hardening`
|
||
|
||
```json
|
||
{
|
||
"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**：
|
||
```json
|
||
{
|
||
"implementation_approach": [
|
||
{"step": 1, "title": "实现功能"},
|
||
{"step": 2, "title": "编写测试"}
|
||
]
|
||
}
|
||
```
|
||
|
||
**数据迁移流程**：
|
||
```
|
||
1. 备份生产数据
|
||
2. 在staging环境验证迁移脚本
|
||
3. 准备回滚脚本
|
||
4. 制定停机时间窗口
|
||
5. 执行迁移
|
||
6. 验证数据一致性
|
||
7. 监控应用健康
|
||
8. 必要时执行回滚
|
||
```
|
||
|
||
### Gap分析
|
||
|
||
| 维度 | 当前支持 | 缺失功能 |
|
||
|------|---------|---------|
|
||
| **回滚计划** | 无 | ❌ 强制要求回滚脚本 |
|
||
| **数据验证** | 无 | ❌ 一致性检查、数据抽样对比 |
|
||
| **分阶段迁移** | 无 | ❌ 增量迁移、双写策略 |
|
||
| **停机窗口** | 无 | ❌ 时间预估、通知机制 |
|
||
|
||
### 建议改进
|
||
|
||
**新增Planning模式**: `/workflow:plan --data-migration`
|
||
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```bash
|
||
/workflow:hotfix --critical "修复支付失败问题" --incident INC-2024-1015
|
||
```
|
||
|
||
**简化流程**：
|
||
```json
|
||
{
|
||
"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的局限性
|
||
|
||
**现有依赖处理**：
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```bash
|
||
/workflow:plan --dependency-upgrade "React 17 → 18"
|
||
```
|
||
|
||
```json
|
||
{
|
||
"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`
|
||
|
||
```bash
|
||
/workflow:spike --timebox 2days "评估三种状态管理方案"
|
||
```
|
||
|
||
```json
|
||
{
|
||
"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个核心字段):
|
||
```json
|
||
{
|
||
"id": "...",
|
||
"title": "...",
|
||
"status": "...",
|
||
"meta": {...},
|
||
"context": {...},
|
||
"flow_control": {...}
|
||
}
|
||
```
|
||
|
||
**扩展字段建议**:
|
||
```json
|
||
{
|
||
"scenario_type": "legacy_refactor|data_migration|hotfix|...",
|
||
"scenario_config": {
|
||
// 场景特定配置，根据scenario_type动态验证
|
||
}
|
||
}
|
||
```
|
||
|
||
### 2. 命令层扩展
|
||
|
||
**新增参数**: `--scenario <type>` 或 `--mode <type>`
|
||
|
||
```bash
|
||
/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)
|
||
**审阅状态**: 待审阅
|