name: qcsd-development-swarm description: “QCSD 开发阶段群集，用于在 sprint 中通过 TDD 遵守、代码复杂度分析、覆盖度差距检测和缺陷预测进行代码质量保证。消费精炼输出（BDD 场景、SFDIPOT 优先级）并为验证阶段生成信号。” category: qcsd-phases priority: critical version: 1.0.0 tokenEstimate: 3400
DDD 领域映射（来自 QCSD-AGENTIC-QE-MAPPING-FRAMEWORK.md）
domains: primary: - domain: test-generation agents: [qe-tdd-specialist] - domain: coverage-analysis agents: [qe-coverage-specialist] - domain: code-intelligence agents: [qe-code-complexity] conditional: - domain: security-compliance agents: [qe-security-scanner] - domain: chaos-resilience agents: [qe-performance-tester] - domain: test-generation agents: [qe-mutation-tester] - domain: enterprise-integration agents: [qe-message-broker-tester, qe-sap-idoc-tester, qe-sod-analyzer] analysis: - domain: defect-intelligence agents: [qe-defect-predictor]
代理清单
agents: core: [qe-tdd-specialist, qe-code-complexity, qe-coverage-specialist] conditional: [qe-security-scanner, qe-performance-tester, qe-mutation-tester, qe-message-broker-tester, qe-sap-idoc-tester, qe-sod-analyzer] analysis: [qe-defect-predictor] total: 10 sub_agents: 0 skills: [tdd-london-chicago, mutation-testing, performance-testing, security-testing]
执行模型（任务工具为主）
execution: primary: task-tool alternatives: [mcp-tools, cli] swarm_pattern: true parallel_batches: 3 last_updated: 2026-02-03 enforcement_level: strict tags: [qcsd, development, tdd, complexity, coverage, security, performance, mutation, defect-prediction, swarm, parallel, ddd] trust_tier: 3 validation: schema_path: schemas/output.json validator_path: scripts/validate-config.json eval_path: evals/qcsd-development-swarm.yaml
QCSD 开发群集 v1.0
左移质量工程群集，用于在 sprint 中保证代码质量。
概述
开发群集接收精炼后的故事（已通过精炼阶段），并在 sprint 执行期间验证代码质量。其中，构思群集询问“我们应该构建这个吗？”，精炼群集询问“我们应该如何测试这个？”，而开发群集询问“代码质量是否足以交付？”
QCSD 阶段定位
| 阶段 | 群集 | 问题 | 决策 | 时间 |
|---|---|---|---|---|
| 构思 | qcsd-ideation-swarm | 我们应该构建这个吗？ | GO / CONDITIONAL / NO-GO | PI/Sprint 规划 |
| 精炼 | qcsd-refinement-swarm | 我们应该如何测试这个？ | READY / CONDITIONAL / NOT-READY | Sprint 精炼 |
| 开发 | qcsd-development-swarm | 代码质量是否足够？ | SHIP / CONDITIONAL / HOLD | 在 Sprint 期间 |
| 验证 | qcsd-cicd-swarm | 这个变更是否安全发布？ | RELEASE / REMEDIATE / BLOCK | 预发布 / CI-CD |
与精炼群集的关键区别
| 维度 | 精炼群集 | 开发群集 |
|---|---|---|
| 框架 | SFDIPOT（7个因素） | TDD + 复杂度 + 覆盖度 |
| 代理 | 10（3核心 + 6条件 + 1转换） | 10（3核心 + 6条件 + 1分析） |
| 核心输出 | BDD Gherkin 场景 | 代码质量评估 |
| 决策 | READY / CONDITIONAL / NOT-READY | SHIP / CONDITIONAL / HOLD |
| 标志 | HAS_API, HAS_REFACTORING, HAS_DEPENDENCIES, HAS_SECURITY, HAS_MIDDLEWARE, HAS_SAP_INTEGRATION, HAS_AUTHORIZATION | HAS_SECURITY_CODE, HAS_PERFORMANCE_CODE, HAS_CRITICAL_CODE, HAS_MIDDLEWARE, HAS_SAP_INTEGRATION, HAS_AUTHORIZATION |
| 阶段 | Sprint 精炼 | 在 Sprint 开发期间 |
| 输入 | 用户故事 + 验收标准 | 源代码 + 测试文件 |
| 最终步骤 | 测试想法重写转换 | 缺陷预测分析 |
参数
SOURCE_PATH: 要分析的源代码目录（必需，例如src/auth/）TEST_PATH: 用于覆盖度分析的测试目录（可选，例如tests/auth/）OUTPUT_FOLDER: 保存报告的位置（默认：${PROJECT_ROOT}/Agentic QCSD/development/）
执行规则 - 首先阅读
这些规则不可协商。违反意味着技能执行失败。
| 规则 | 执行 |
|---|---|
| E1 | 你必须在第2阶段生成所有三个核心代理（qe-tdd-specialist、qe-code-complexity、qe-coverage-specialist）。没有例外。 |
| E2 | 你必须将所有并行任务调用放在单个消息中。 |
| E3 | 你必须在每个批次后停止并等待。不要提前进行。 |
| E4 | 如果标志为 TRUE，你必须生成条件代理。不要跳过。 |
| E5 | 你必须严格按照第5阶段的指定应用 SHIP/CONDITIONAL/HOLD 逻辑。 |
| E6 | 你必须生成完整的报告结构。不要省略版本。 |
| E7 | 每个代理在分析前必须阅读其参考文件。 |
| E8 | 你必须在第8阶段对所有代码变更应用 qe-defect-predictor 分析。总是如此。 |
| E9 | 你必须执行第7阶段的学习持久性。在第8阶段之前将开发发现存储到内存中。不要跳过。 |
禁止行为：
- 总结而不是生成代理
- 为了简洁而跳过代理
- 在后台任务完成前进行
- 提供自己的分析而不是生成专家代理
- 省略报告部分
- 使用占位符文本如“[details here]”
- 跳过缺陷预测分析
- 跳过学习持久性（第7阶段）或将其视为可选
- 自己生成代码分析而不是使用专家代理
第1阶段：分析代码上下文（标志检测）
强制性：你必须在第2阶段之前完成此分析。
扫描源代码、测试文件和故事上下文以设置这些标志。不要跳过任何标志。
标志检测（检查所有六个）
HAS_SECURITY_CODE = FALSE
如果代码包含以下任何内容，则设置为 TRUE：auth、authentication、authorization、
password、credential、token、JWT、OAuth、session、encrypt、decrypt、
hash、salt、PII、GDPR、HIPAA、secret、private key、certificate、
RBAC、ACL、sanitize、XSS、CSRF、injection、eval(
HAS_PERFORMANCE_CODE = FALSE
如果代码包含以下任何内容，则设置为 TRUE：loop、while、for、recursion、
query、SELECT、JOIN、aggregate、cache、memoize、concurrent、
parallel、async、await、Promise.all、batch、stream、buffer、
pagination、lazy load、debounce、throttle、worker、thread、
O(n^2)、O(n log n)、large dataset、bulk operation
HAS_CRITICAL_CODE = FALSE
如果代码包含以下任何内容，则设置为 TRUE：payment、billing、invoice、
transaction、charge、refund、subscription、medical、health、
patient、diagnosis、compliance、audit、regulatory、financial、
accounting、tax、legal、contract、SLA、insurance、claim、
safety-critical、life-critical
HAS_MIDDLEWARE = FALSE
如果代码包含以下任何内容，则设置为 TRUE：middleware、ESB、message broker、MQ、
Kafka、RabbitMQ、integration bus、API gateway、message queue、pub/sub
HAS_SAP_INTEGRATION = FALSE
如果代码包含以下任何内容，则设置为 TRUE：SAP、RFC、BAPI、IDoc、OData、
S/4HANA、EWM、ECC、ABAP、CDS view、Fiori
HAS_AUTHORIZATION = FALSE
如果代码包含以下任何内容，则设置为 TRUE：SoD、segregation of duties、
role conflict、authorization object、T-code、user role、
access control matrix、GRC
验证检查点
在进行第2阶段之前，确认：
+-- 我已阅读正在分析的源代码文件
+-- 我已阅读相关的测试文件
+-- 我已评估所有六个标志
+-- 我已记录哪些标志为 TRUE
+-- 我理解哪些条件代理将被需要
在确认所有复选框之前，不要进行第2阶段。
强制性：输出标志检测结果
在进行之前，你必须输出标志检测结果：
+-------------------------------------------------------------+
| 标志检测结果 |
+-------------------------------------------------------------+
| |
| HAS_SECURITY_CODE: [TRUE/FALSE] |
| 证据: [触发的具体代码] |
| |
| HAS_PERFORMANCE_CODE: [TRUE/FALSE] |
| 证据: [触发的具体代码] |
| |
| HAS_CRITICAL_CODE: [TRUE/FALSE] |
| 证据: [触发的具体代码] |
| |
| HAS_MIDDLEWARE: [TRUE/FALSE] |
| 证据: [触发的具体代码] |
| |
| HAS_SAP_INTEGRATION: [TRUE/FALSE] |
| 证据: [触发的具体代码] |
| |
| HAS_AUTHORIZATION: [TRUE/FALSE] |
| 证据: [触发的具体代码] |
| |
| 预期代理: |
| - 核心: 3（总是） |
| - 条件: [基于 TRUE 标志的数量] |
| - 分析: 1（总是） |
| - 总计: [3 + 条件数量 + 1] |
| |
+-------------------------------------------------------------+
在没有输出标志检测结果之前，不要进行第2阶段。
第2阶段：生成核心代理（并行批次1）
关键执行
+-------------------------------------------------------------+
| 你必须在下一个消息中包含所有三个任务调用 |
| |
| - 任务1: qe-tdd-specialist |
| - 任务2: qe-code-complexity |
| - 任务3: qe-coverage-specialist |
| |
| 如果你的消息包含少于3个任务调用，你已经 |
| 失败这个阶段。重新开始。 |
+-------------------------------------------------------------+
领域上下文
| 代理 | 领域 | MCP 工具映射 |
|---|---|---|
| qe-tdd-specialist | test-generation | test_generate_enhanced |
| qe-code-complexity | code-intelligence | coverage_analyze_sublinear |
| qe-coverage-specialist | coverage-analysis | coverage_analyze_sublinear |
代理1：TDD 专家
此代理必须评估 TDD 遵守和测试质量。测试与代码比例是强制性的。
Task({
description: "TDD 遵守和测试质量分析",
prompt: `你是 qe-tdd-specialist。你的输出质量正在被审计。
## 强制性第一步（不要跳过）
1. 完整阅读下面提供的源代码文件。
2. 阅读与源代码相关的测试文件。
## 要分析的代码
=== 源代码开始 ===
[在此粘贴完整的源代码 - 不要总结]
=== 源代码结束 ===
=== 测试代码开始 ===
[在此粘贴完整的测试代码 - 不要总结]
=== 测试代码结束 ===
## 必需输出（所有部分强制性）
### 1. TDD 遵守评估
评估每个 TDD 原则：
| 原则 | 分数 (0-10) | 证据 | 问题 |
|-----------|-------------|----------|--------|
| 红色阶段（测试先写） | X/10 | [测试先于代码的迹象] | [问题] |
| 绿色阶段（最小实现） | X/10 | [最小代码通过测试的迹象] | [问题] |
| 重构阶段（清洁代码） | X/10 | [重构、DRY、SOLID 的迹象] | [问题] |
| 测试隔离 | X/10 | [测试彼此独立] | [问题] |
| 快速反馈 | X/10 | [测试执行速度] | [问题] |
| 有意义断言 | X/10 | [断言质量，不仅仅是覆盖度] | [问题] |
**TDD 遵守分数: XX/60**
### 2. 测试质量指标
| 指标 | 值 | 阈值 | 状态 |
|--------|-------|-----------|--------|
| 测试与代码比例 | X:1 | >= 1:1 | 通过/失败 |
| 断言密度 | 每个测试 X | >= 2 | 通过/失败 |
| 测试命名质量 | X% 描述性 | >= 90% | 通过/失败 |
| 模拟使用比例 | X% | <= 50% | 通过/失败 |
| 测试隔离分数 | X/10 | >= 7 | 通过/失败 |
| 边界情况覆盖度 | X% | >= 60% | 通过/失败 |
### 3. 检测到的测试模式
| 模式 | 计数 | 质量 | 推荐 |
|---------|-------|---------|----------------|
| Arrange-Act-Assert | X | 好/差 | ... |
| Given-When-Then | X | 好/差 | ... |
| 测试替身（模拟） | X | 好/差 | ... |
| 集成测试 | X | 好/差 | ... |
| 基于属性的测试 | X | 好/差 | ... |
### 4. 缺少的测试类别
| 类别 | 状态 | 优先级 | 建议测试 |
|----------|--------|----------|-----------------|
| 快乐路径 | 覆盖/缺少 | P0/P1/P2 | [具体测试] |
| 错误处理 | 覆盖/缺少 | P0/P1/P2 | [具体测试] |
| 边界值 | 覆盖/缺少 | P0/P1/P2 | [具体测试] |
| Null/未定义 | 覆盖/缺少 | P0/P1/P2 | [具体测试] |
| 并发 | 覆盖/缺少/不适用 | P0/P1/P2 | [具体测试] |
### 5. 推荐
| 优先级 | 推荐 | 影响 |
|----------|---------------|--------|
| P0 | [必须在合并前修复] | [改善什么] |
| P1 | [应该在此 sprint 修复] | [改善什么] |
| P2 | [最好有] | [改善什么] |
**最低要求：评估所有 6 个 TDD 原则并识别至少 3 个缺少的测试类别。**
## 输出格式
将完整分析保存为 Markdown 到：
${OUTPUT_FOLDER}/02-tdd-adherence.md
使用 Write 工具在完成前保存。
报告必须完整 - 无占位符。
## 提交前验证
+-- 我是否阅读了所有源代码和测试文件？
+-- 我是否对所有 6 个 TDD 原则评分？
+-- 我是否计算了测试与代码比例？
+-- 我是否识别了缺少的测试类别？
+-- 我是否提供了具体推荐？
+-- 我是否将报告保存到正确的输出路径？`,
subagent_type: "qe-tdd-specialist",
run_in_background: true
})
代理2：代码复杂度分析器
此代理必须计算环复杂度和认知复杂度。热点是强制性的。
Task({
description: "环复杂度和认知复杂度分析",
prompt: `你是 qe-code-complexity。你的输出质量正在被审计。
## 要分析的代码
=== 源代码开始 ===
[在此粘贴完整的源代码 - 不要总结]
=== 源代码结束 ===
## 必需输出（所有部分强制性）
### 1. 函数级复杂度
对于代码库中的每个函数/方法：
| 函数 | 文件:行 | 环复杂度 | 认知复杂度 | LOC | 风险 |
|----------|-----------|------------|-----------|-----|------|
| 函数名 | file.ts:42 | X | X | X | 高/中/低 |
**阈值：**
- 环复杂度: <=10（好）, 11-20（警告）, >20（关键）
- 认知复杂度: <=15（好）, 16-25（警告）, >25（关键）
- LOC: <=50（好）, 51-100（警告）, >100（关键）
### 2. 热点检测
识别前 5 个复杂度热点：
| 排名 | 函数 | 环复杂度 | 认知复杂度 | 变更频率 | 优先级 |
|------|----------|------------|-----------|------------------|----------|
| 1 | ... | X | X | 高/中/低 | P0 |
| 2 | ... | X | X | 高/中/低 | P0/P1 |
| ... | ... | X | X | ... | ... |
### 3. 代码异味检测
| 异味 | 位置 | 严重性 | 重构建议 |
|-------|----------|----------|----------------------|
| 长方法 | file:line | 关键/主要/次要 | 提取方法: [具体建议] |
| 深度嵌套 | file:line | 关键/主要/次要 | 保护子句，提前返回 |
| 上帝类 | file:line | 关键/主要/次要 | 分割为: [具体类] |
| 特征嫉妒 | file:line | 关键/主要/次要 | 移动到: [目标类] |
| 重复代码 | file:line | 关键/主要/次要 | 提取: [公共抽象] |
**最低要求：识别至少 3 个代码异味或明确声明“在彻底分析后未发现显著的代码异味”。**
### 4. 可维护性指数
| 组件 | MI 分数 (0-100) | 评级 | 备注 |
|-----------|-----------------|--------|-------|
| 总体 | X | A/B/C/D/F | ... |
| 模块 1 | X | A/B/C/D/F | ... |
| 模块 2 | X | A/B/C/D/F | ... |
**评级标准：**
- A (85-100): 高度可维护
- B (65-84): 中等可维护
- C (40-64): 难以维护
- D (20-39): 非常难以维护
- F (0-19): 不可维护
### 5. 复杂度总结
| 指标 | 值 | 阈值 | 状态 |
|--------|-------|-----------|--------|
| 平均环复杂度 | X | <= 10 | 通过/警告/失败 |
| 最大环复杂度 | X | <= 20 | 通过/警告/失败 |
| 平均认知复杂度 | X | <= 15 | 通过/警告/失败 |
| 最大认知复杂度 | X | <= 25 | 通过/警告/失败 |
| 函数 > 50 LOC | X% | <= 10% | 通过/警告/失败 |
| 嵌套深度 > 4 | X | 0 | 通过/警告/失败 |
**复杂度分数: X/100** (反向：较低复杂度 = 较高分数)
## 输出格式
将完整分析保存为 Markdown 到：
${OUTPUT_FOLDER}/03-code-complexity.md
使用 Write 工具在完成前保存。
报告必须完整 - 无占位符。
## 提交前验证
+-- 我是否分析了每个函数/方法？
+-- 我是否计算了环复杂度和认知复杂度？
+-- 我是否识别了前 5 个热点？
+-- 我是否检测了代码异味？
+-- 我是否计算了可维护性指数？
+-- 我是否将报告保存到正确的输出路径？`,
subagent_type: "qe-code-complexity",
run_in_background: true
})
代理3：覆盖度专家
此代理必须使用 O(log n) 次线性分析检测覆盖度差距。差距计数是强制性的。
Task({
description: "O(log n) 次线性覆盖度差距检测",
prompt: `你是 qe-coverage-specialist。你的输出质量正在被审计。
## 要分析的代码
=== 源代码开始 ===
[在此粘贴完整的源代码 - 不要总结]
=== 源代码结束 ===
=== 测试代码开始 ===
[在此粘贴完整的测试代码 - 不要总结]
=== 测试代码结束 ===
## 必需输出（所有部分强制性）
### 1. 覆盖度概述
| 指标 | 值 | 阈值 | 状态 |
|--------|-------|-----------|--------|
| 行覆盖度 | X% | >= 80% | 通过/警告/失败 |
| 分支覆盖度 | X% | >= 70% | 通过/警告/失败 |
| 函数覆盖度 | X% | >= 90% | 通过/警告/失败 |
| 语句覆盖度 | X% | >= 80% | 通过/警告/失败 |
### 2. 覆盖度差距分析 (O(log n) 次线性)
对于每个检测到的差距：
| 差距 ID | 文件:行 | 类型 | 风险分数 | 描述 |
|--------|-----------|------|------------|-------------|
| G001 | file.ts:42-56 | 未覆盖分支 | 高/中/低 | [未测试的内容] |
| G002 | file.ts:78 | 缺少错误路径 | 高/中/低 | [未处理的错误] |
| G003 | ... | ... | ... | ... |
**差距类型：**
- 未覆盖分支: if/else 路径未测试
- 缺少错误路径: catch/错误处理程序未测试
- 未测试函数: 整个函数没有测试
- 部分覆盖度: 函数已测试但分支错过
- 死代码: 检测到不可达代码
### 3. 风险加权差距优先级排序
| 优先级 | 差距 IDs | 风险理由 | 建议测试 |
|----------|---------|---------------|----------------|
| P0 - 关键 | G001, G003 | [为什么关键] | [要编写的具体测试] |
| P1 - 高 | G002, G005 | [为什么高] | [要编写的具体测试] |
| P2 - 中 | G004 | [为什么中] | [要编写的具体测试] |
### 4. 模块级覆盖度热图
| 模块 | 行% | 分支% | 函数% | 风险级别 |
|--------|-------|---------|-----------|------------|
| 模块 1 | X% | X% | X% | 高/中/低 |
| 模块 2 | X% | X% | X% | 高/中/低 |
| ... | ... | ... | ... | ... |
### 5. 覆盖度趋势评估
基于代码结构分析：
| 维度 | 评估 | 推荐 |
|-----------|-----------|----------------|
| 测试与代码对齐 | 好/部分/差 | [具体行动] |
| 边界情况覆盖度 | 好/部分/差 | [具体行动] |
| 集成覆盖度 | 好/部分/差 | [具体行动] |
| 错误路径覆盖度 | 好/部分/差 | [具体行动] |
**覆盖度差距总计: X**
**关键差距 (P0): X**
**最低要求：识别至少 3 个覆盖度差距或明确声明“在彻底次线性分析后未发现覆盖度差距”。**
## 输出格式
将完整分析保存为 Markdown 到：
${OUTPUT_FOLDER}/04-coverage-analysis.md
使用 Write 工具在完成前保存。
报告必须完整 - 无占位符。
## 提交前验证
+-- 我是否计算了所有 4 个覆盖度指标？
+-- 我是否检测了具有具体文件:行引用的覆盖度差距？
+-- 我是否对差距进行了风险加权和优先级排序？
+-- 我是否为每个差距提供了具体测试建议？
+-- 我是否生成了模块级热图？
+-- 我是否将报告保存到正确的输出路径？`,
subagent_type: "qe-coverage-specialist",
run_in_background: true
})
生成后确认
发送所有三个任务调用后，你必须告诉用户：
我已并行启动 3 个核心代理：
qe-tdd-specialist [领域: test-generation]
- 评估 TDD 红-绿-重构遵守
- 计算测试与代码比例和断言密度
- 识别缺少的测试类别
qe-code-complexity [领域: code-intelligence]
- 计算每个函数的环复杂度和认知复杂度
- 检测热点和代码异味
- 计算可维护性指数
qe-coverage-specialist [领域: coverage-analysis]
- 运行 O(log n) 次线性覆盖度差距检测
- 风险加权和优先级排序差距
- 生成模块级覆盖度热图
等待所有代理完成后再进行...
在发送此确认之前，不要进行第3阶段。
第3阶段：等待批次1完成
执行：不要提前进行
+-------------------------------------------------------------+
| 你必须等待所有三个后台任务完成 |
| |
| 不要总结代理“将”找到什么 |
| 不要提前进行第4阶段 |
| 不要提供自己的分析作为替代 |
| |
| 等待实际代理结果 |
| 只有当所有三个都返回时才进行 |
+-------------------------------------------------------------+
结果提取清单
当结果返回时，提取并记录：
来自 qe-tdd-specialist:
[ ] tddAdherence = __/60 TDD 分数
[ ] testToCodeRatio = __:1
[ ] assertionDensity = __ 每个测试
[ ] missingCategories = __ 缺少的测试类别
来自 qe-code-complexity:
[ ] avgCyclomatic = __ 平均环复杂度
[ ] maxCyclomatic = __ 最大环复杂度
[ ] complexityScore = __/100 (反向复杂度)
[ ] hotspots = __ 识别的热点
[ ] codeSmells = __ 检测到的代码异味
来自 qe-coverage-specialist:
[ ] lineCoverage = __% 行覆盖度
[ ] branchCoverage = __% 分支覆盖度
[ ] coverageGaps = __ 总差距
[ ] criticalGaps = __ P0 差距
指标总结框
输出提取的指标：
+-------------------------------------------------------------+
| 批次1 结果总结 |
+-------------------------------------------------------------+
| |
| TDD 遵守: __/60 |
| 测试与代码比例: __:1 |
| 断言密度: __ 每个测试 |
| 缺少的测试类别: __ |
| |
| 平均环复杂度: __ |
| 最大环复杂度: __ |
| 复杂度分数: __/100 |
| 热点: __ |
| 代码异味: __ |
| |
| 行覆盖度: __% |
| 分支覆盖度: __% |
| 覆盖度差距: __ 总 |
| 关键差距 (P0): __ |
| |
+-------------------------------------------------------------+
在填写所有字段之前，不要进行第4阶段。
第4阶段：生成条件代理（并行批次2）
执行：不要跳过条件代理
+-------------------------------------------------------------+
| 如果标志为 TRUE，你必须生成那个代理 |
| |
| HAS_SECURITY_CODE = TRUE -> 必须生成 qe-security-scanner |
| HAS_PERFORMANCE_CODE = TRUE -> 必须生成 qe-performance-tester |
| HAS_CRITICAL_CODE = TRUE -> 必须生成 qe-mutation-tester |
| HAS_MIDDLEWARE = TRUE -> 必须生成 qe-message-broker-tester|
| HAS_SAP_INTEGRATION = TRUE -> 必须生成 qe-sap-idoc-tester |
| HAS_AUTHORIZATION = TRUE -> 必须生成 qe-sod-analyzer |
| |
| 跳过一个标志的代理是这个技能的失败。 |
+-------------------------------------------------------------+
条件领域映射
| 标志 | 代理 | 领域 | MCP 工具 |
|---|---|---|---|
| HAS_SECURITY_CODE | qe-security-scanner | security-compliance | security_scan_comprehensive |
| HAS_PERFORMANCE_CODE | qe-performance-tester | chaos-resilience | performance_benchmark |
| HAS_CRITICAL_CODE | qe-mutation-tester | test-generation | test_generate_enhanced |
| HAS_MIDDLEWARE | qe-message-broker-tester | enterprise-integration | task_orchestrate |
| HAS_SAP_INTEGRATION | qe-sap-idoc-tester | enterprise-integration | task_orchestrate |
| HAS_AUTHORIZATION | qe-sod-analyzer | enterprise-integration | task_orchestrate |
决策树
如果 HAS_SECURITY_CODE == FALSE 并且 HAS_PERFORMANCE_CODE == FALSE 并且 HAS_CRITICAL_CODE == FALSE 并且 HAS_MIDDLEWARE == FALSE 并且 HAS_SAP_INTEGRATION == FALSE 并且 HAS_AUTHORIZATION == FALSE:
-> 跳到第5阶段（不需要条件代理）
-> 状态: “基于代码分析，不需要条件代理”
否则:
-> 在一个消息中生成所有适用的代理
-> 计算你生成的数量: __
如果 HAS_SECURITY_CODE：安全扫描器（标志时强制）
Task({
description: "源代码的 SAST 安全扫描",
prompt: `你是 qe-security-scanner。你的输出质量正在被审计。
## 源代码
=== 源代码开始 ===
[在此粘贴完整的源代码]
=== 源代码结束 ===
## 必需分析（所有部分强制性）
### 1. OWASP Top 10 评估
对于每个适用的 OWASP 类别：
| OWASP ID | 类别 | 适用？ | 发现 | 严重性 |
|----------|----------|-------------|----------|----------|
| A01:2021 | 破坏的访问控制 | 是/否 | [发现] | 关键/高/中/低 |
| A02:2021 | 加密失败 | 是/否 | [发现] | 关键/高/中/低 |
| A03:2021 | 注入 | 是/否 | [发现] | 关键/高/中/低 |
| A04:2021 | 不安全设计 | 是/否 | [发现] | 关键/高/中/低 |
| A05:2021 | 安全配置错误 | 是/否 | [发现] | 关键/高/中/低 |
| A06:2021 | 易受攻击的组件 | 是/否 | [发现] | 关键/高/中/低 |
| A07:2021 | 身份验证失败 | 是/否 | [发现] | 关键/高/中/低 |
| A08:2021 | 软件完整性失败 | 是/否 | [发现] | 关键/高/中/低 |
| A09:2021 | 日志记录失败 | 是/否 | [发现] | 关键/高/中/低 |
| A10:2021 | SSRF | 是/否 | [发现] | 关键/高/中/低 |
### 2. 漏洞清单
| 漏洞 ID | 文件:行 | 类型 | 严重性 | CVSS | 修复 |
|---------|-----------|------|----------|------|-------------|
| V001 | ... | SQL 注入/XSS/等 | 关键/高/中/低 | X.X | [具体修复] |
### 3. 秘密检测
| 发现 | 文件:行 | 类型 | 状态 |
|---------|-----------|------|--------|
| ... | ... | API 密钥/密码/令牌/证书 | 暴露/安全 |
### 4. 依赖漏洞检查
| 依赖 | 版本 | 已知 CVE | 严重性 | 修复版本 |
|------------|---------|------------|----------|-------------|
| ... | X.Y.Z | CVE-XXXX-XXXXX | 关键/高 | X.Y.Z+ |
### 5. 安全分数
| 维度 | 分数 (0-10) | 备注 |
|-----------|-------------|-------|
| 输入验证 | X/10 | ... |
| 身份验证 | X/10 | ... |
| 授权 | X/10 | ... |
| 数据保护 | X/10 | ... |
| 错误处理 | X/10 | ... |
**安全分数: X/50**
**最低要求：评估所有 10 个 OWASP 类别并识别至少 3 个安全相关发现。**
## 输出格式
保存到: ${OUTPUT_FOLDER}/05-security-scan.md
使用 Write 工具在完成前保存。`,
subagent_type: "qe-security-scanner",
run_in_background: true
})
如果 HAS_PERFORMANCE_CODE：性能测试器（标志时强制）
Task({
description: "性能分析和瓶颈检测",
prompt: `你是 qe-performance-tester。你的输出质量正在被审计。
## 源代码
=== 源代码开始 ===
[在此粘贴完整的源代码]
=== 源代码结束 ===
## 必需分析（所有部分强制性）
### 1. 算法复杂度分析
对于每个重要函数：
| 函数 | 文件:行 | 时间复杂度 | 空间复杂度 | 关注 |
|----------|-----------|-----------------|------------------|---------|
| ... | ... | O(n)/O(n^2)/等 | O(1)/O(n)/等 | [如果有问题] |
### 2. 性能瓶颈检测
| 瓶颈 | 文件:行 | 类型 | 影响 | 推荐 |
|------------|-----------|------|--------|----------------|
| ... | ... | CPU/内存/I-O/网络 | 高/中/低 | [具体修复] |
**瓶颈类型：**
- CPU 绑定：嵌套循环、复杂计算、正则回溯
- 内存绑定：大分配、内存泄漏、无边界缓存
- I/O 绑定：同步文件操作、阻塞网络调用、N+1 查询
- 网络绑定：过多 API 调用、大负载、无批处理
### 3. 数据库查询分析（如果适用）
| 查询 | 位置 | 估计成本 | 使用索引？ | 优化 |
|-------|----------|---------------|-------------|-------------|
| ... | file:line | 高/中/低 | 是/否 | [具体修复] |
### 4. 资源使用估计
| 资源 | 当前模式 | 风险 | 推荐 |
|----------|----------------|------|----------------|
| 内存分配 | [模式] | 高/中/低 | [行动] |
| 连接池 | [模式] | 高/中/低 | [行动] |
| 缓存策略 | [模式] | 高/中/低 | [行动] |
| 并发模型 | [模式] | 高/中/低 | [行动] |
### 5. 性能分数
| 维度 | 分数 (0-10) | 备注 |
|-----------|-------------|-------|
| 算法效率 | X/10 | ... |
| 内存管理 | X/10 | ... |
| I/O 优化 | X/10 | ... |
| 并发安全 | X/10 | ... |
**性能分数: X/40**
**最低要求：分析至少 5 个函数的复杂度或解释为什么存在较少。**
## 输出格式
保存到: ${OUTPUT_FOLDER}/06-performance-profile.md
使用 Write 工具在完成前保存。`,
subagent_type: "qe-performance-tester",
run_in_background: true
})
如果 HAS_CRITICAL_CODE：变异测试器（标志时强制）
Task({
description: "测试套件有效性的变异测试",
prompt: `你是 qe-mutation-tester。你的输出质量正在被审计。
## 源代码
=== 源代码开始 ===
[在此粘贴完整的源代码]
=== 源代码结束 ===
=== 测试代码开始 ===
[在此粘贴完整的测试代码]
=== 测试代码结束 ===
## 必需分析（所有部分强制性）
### 1. 变异分析
对关键代码路径应用这些变异操作符：
| 操作符 | 应用的变异 | 杀死 | 存活 | 杀死率 |
|----------|------------------|--------|----------|-----------|
| 算术 (+,-,*,/) | X | X | X | X% |
| 关系 (<,>,==,!=) | X | X | X | X% |
| 逻辑 (&&, or, !) | X | X | X | X% |
| 条件 (if/else) | X | X | X | X% |
| 返回值 | X | X | X | X% |
| Null/未定义 | X | X | X | X% |
| **总计** | **X** | **X** | **X** | **X%** |
### 2. 存活的变异（测试套件弱点）
对于每个存活的变异：
| 变异 ID | 文件:行 | 原始 | 变异 | 为什么存活 | 缺少的测试 |
|-----------|-----------|----------|----------|-------------|-------------|
| M001 | file:42 | `a > b` | `a >= b` | 无边界测试 | 测试 a == b 情况 |
| M002 | ... | ... | ... | ... | ... |
### 3. 关键路径变异分数
| 关键路径 | 变异 | 杀死 | 分数 | 状态 |
|---------------|-----------|--------|-------|--------|
| 支付流 | X | X | X% | 通过/失败 (>= 95%) |
| 身份验证流 | X | X | X% | 通过/失败 (>= 95%) |
| 数据验证 | X | X | X% | 通过/失败 (>= 90%) |
| 错误处理 | X | X | X% | 通过/失败 (>= 85%) |
### 4. 测试套件有效性
| 指标 | 值 | 阈值 | 状态 |
|--------|-------|-----------|--------|
| 总体变异分数 | X% | >= 80% | 通过/失败 |
| 关键路径分数 | X% | >= 95% | 通过/失败 |
| 等效变异 | X | (信息性) | - |
| 测试强度指数 | X/10 | >= 7 | 通过/失败 |
### 5. 推荐
| 优先级 | 行动 | 影响 | 努力 |
|----------|--------|--------|--------|
| P0 | [关键路径变异逃脱] | [什么风险] | [努力] |
| P1 | [高价值缺少的测试] | [什么风险] | [努力] |
**变异分数: X%**
**最低要求：应用至少 20 个变异，跨越至少 3 个变异操作符。**
## 输出格式
保存到: ${OUTPUT_FOLDER}/07-mutation-analysis.md
使用 Write 工具在完成前保存。`,
subagent_type: "qe-mutation-tester",
run_in_background: true
})
如果 HAS_MIDDLEWARE：消息代理测试器（标志时强制）
Task({
description: "消息代理和中间件测试以集成可靠性",
prompt: `你是 qe-message-broker-tester。你的输出质量正在被审计。
## 源代码
=== 源代码开始 ===
[在此粘贴完整的源代码]
=== 源代码结束 ===
=== 测试代码开始 ===
[在此粘贴完整的测试代码]
=== 测试代码结束 ===
## 必需分析（所有部分强制性）
### 1. 消息代理清单
识别源代码中的所有中间件/消息代理组件：
| 组件 | 类型 | 协议 | 方向 | 状态 |
|-----------|------|----------|-----------|--------|
| [名称] | 队列/主题/交换 | AMQP/Kafka/JMS/MQ | 生产者/消费者/两者 | 活动/被动 |
### 2. 消息流分析
对于每个消息流：
| 流 ID | 生产者 | 代理 | 消费者 | 负载模式 | 排序 | 幂等性 |
|---------|----------|--------|----------|----------------|----------|-------------|
| MF-001 | [源] | [代理] | [目标] | [模式参考] | 保证/尽力而为 | 是/否 |
### 3. 错误处理和重试评估
| 模式 | 实现 | 正确 | 问题 |
|---------|-------------|---------|-------|
| 死信队列 (DLQ) | 是/否 | 是/否 | [问题] |
| 重试与退避 | 是/否 | 是/否 | [问题] |
| 断路器 | 是/否 | 是/否 | [问题] |
| 毒药消息处理 | 是/否 | 是/否 | [问题] |
| 重复检测 | 是/否 | 是/否 | [问题] |
### 4. Pub/Sub 验证
| 主题/交换 | 发布者 | 订阅者 | 扇出 | 过滤 | 测试覆盖度 |
|----------------|------------|-------------|---------|-----------|---------------|
| [名称] | [计数] | [计数] | [类型] | [规则] | [%] |
### 5. 消息合同验证
| 合同 | 模式验证 | 版本控制 | 向后兼容 | 破坏性变更 |
|----------|-------------------|------------|---------------------|------------------|
| [名称] | 是/否 | [策略] | 是/否 | [列表] |
### 6. 推荐
| 优先级 | 行动 | 影响 | 努力 |
|----------|--------|--------|--------|
| P0 | [关键中间件问题] | [什么风险] | [努力] |
| P1 | [重要改进] | [什么风险] | [努力] |
**中间件健康分数: X/50**
## 输出格式
保存到: ${OUTPUT_FOLDER}/10-middleware-testing.md
使用 Write 工具在完成前保存。`,
subagent_type: "qe-message-broker-tester",
run_in_background: true
})
如果 HAS_SAP_INTEGRATION：SAP IDoc 测试器（标志时强制）
Task({
description: "SAP IDoc 处理和 BAPI 测试以数据流验证",
prompt: `你是 qe-sap-idoc-tester。你的输出质量正在被审计。
## 源代码
=== 源代码开始 ===
[在此粘贴完整的源代码]
=== 源代码结束 ===
=== 测试代码开始 ===
[在此粘贴完整的测试代码]
=== 测试代码结束 ===
## 必需分析（所有部分强制性）
### 1. SAP 集成清单
识别源代码中的所有 SAP 集成点：
| 集成点 | 类型 | 方向 | SAP 系统 | 协议 | 状态 |
|-------------------|------|-----------|------------|----------|--------|
| [名称] | RFC/BAPI/IDoc/OData/CDS | 入站/出站 | S/4HANA/ECC/EWM | [协议] | 活动/被动 |
### 2. IDoc 处理分析
对于每个 IDoc 类型：
| IDoc 类型 | 消息类型 | 方向 | 段 | 合作伙伴配置文件 | 错误处理 | 测试覆盖度 |
|-----------|-------------|-----------|----------|-----------------|----------------|---------------|
| [类型] | [消息类型] | 入/出 | [计数] | [配置文件] | [策略] | [%] |
### 3. BAPI/RFC 调用评估
| BAPI/RFC | 参数 | 提交处理 | 错误代码 | 回滚 | 幂等性 |
|----------|------------|-----------------|-------------|----------|-------------|
| [名称] | 入:[n] 出:[n] | BAPI_TRANSACTION_COMMIT? | [处理的代码] | 是/否 | 是/否 |
### 4. 数据流验证
| 流 | 源 | 映射 | 目标 | 转换 | 验证规则 | 差距 |
|------|--------|---------|--------|----------------|------------------|------|
| [名称] | [字段映射] | [逻辑] | [SAP 字段] | [规则] | [验证] | [差距] |
### 5. SAP 特定测试覆盖度
| 测试类型 | 覆盖度 | 关键差距 |
|-----------|----------|---------------|
| IDoc 解析/生成 | [%] | [差距] |
| BAPI 调用/响应 | [%] | [差距] |
| RFC 错误处理 | [%] | [差距] |
| 数据映射准确性 | [%] | [差距] |
| 事务完整性 | [%] | [差距] |
### 6. 推荐
| 优先级 | 行动 | 影响 | 努力 |
|----------|--------|--------|--------|
| P0 | [关键 SAP 集成问题] | [什么风险] | [努力] |
| P1 | [重要改进] | [什么风险] | [努力] |
**SAP 集成健康分数: X/50**
## 输出格式
保存到: ${OUTPUT_FOLDER}/11-sap-idoc-testing.md
使用 Write 工具在完成前保存。`,
subagent_type: "qe-sap-idoc-tester",
run_in_background: true
})
如果 HAS_AUTHORIZATION：SoD 分析器（标志时强制）
Task({
description: "职责分离和授权冲突分析",
prompt: `你是 qe-sod-analyzer。你的输出质量正在被审计。
## 源代码
=== 源代码开始 ===
[在此粘贴完整的源代码]
=== 源代码结束 ===
=== 测试代码开始 ===
[在此粘贴完整的测试代码]
=== 测试代码结束 ===
## 必需分析（所有部分强制性）
### 1. 授权模型清单
识别源代码中的所有授权构造：
| 组件 | 类型 | 机制 | 粒度 | 状态 |
|-----------|------|-----------|-------------|--------|
| [名称] | 角色/权限/策略 | RBAC/ABAC/ACL | 资源/操作/字段 | 活动/被动 |
### 2. 职责分离矩阵
| 功能 A | 功能 B | 冲突类型 | 风险级别 | 缓解控制 | 测试覆盖度 |
|------------|------------|---------------|------------|-------------------|---------------|
| [创建订单] | [批准订单] | SoD 违规 | 关键/高/中 | [控制] | [%] |
### 3. 角色冲突检测
| 角色 | 权限 | 冲突与 | 冲突类型 | 修复 |
|------|-------------|---------------|---------------|-------------|
| [角色] | [权限列表] | [冲突角色] | [SoD/权限提升] | [行动] |
### 4. 授权测试覆盖度
| 测试类型 | 覆盖度 | 关键差距 |
|-----------|----------|---------------|
| 正向访问测试 | [%] | [差距] |
| 负向访问测试 | [%] | [差距] |
| 跨角色访问 | [%] | [差距] |
| 权限提升 | [%] | [差距] |
| SoD 执行 | [%] | [差距] |
### 5. 访问控制代码质量
| 指标 | 值 | 阈值 | 状态 |
|--------|-------|-----------|--------|
| 每个端点的授权检查 | [比例] | >= 1.0 | 通过/失败 |
| 硬编码角色/权限 | [计数] | 0 | 通过/失败 |
| 缺少的访问控制 | [计数] | 0 | 通过/失败 |
| 默认允许模式 | [计数] | 0 | 通过/失败 |
### 6. 推荐
| 优先级 | 行动 | 影响 | 努力 |
|----------|--------|--------|--------|
| P0 | [关键授权问题] | [什么风险] | [努力] |
| P1 | [重要改进] | [什么风险] | [努力] |
**授权健康分数: X/50**
## 输出格式
保存到: ${OUTPUT_FOLDER}/12-sod-analysis.md
使用 Write 工具在完成前保存。`,
subagent_type: "qe-sod-analyzer",
run_in_background: true
})
代理计数验证
在进行之前，验证代理计数：
+-------------------------------------------------------------+
| 代理计数验证 |
+-------------------------------------------------------------+
| |
| 核心代理（总是 3）： |
| [ ] qe-tdd-specialist - 生成？ [是/否] |
| [ ] qe-code-complexity - 生成？ [是/否] |
| [ ] qe-coverage-specialist - 生成？ [是/否] |
| |
| 条件代理（基于标志）： |
| [ ] qe-security-scanner - 生成？ [是/否] (HAS_SECURITY) |
| [ ] qe-performance-tester - 生成？ [是/否] (HAS_PERF) |
| [ ] qe-mutation-tester - 生成？ [是/否] (HAS_CRITICAL) |
| [ ] qe-message-broker-tester - 生成？ [是/否] (HAS_MIDDLEWARE) |
| [ ] qe-sap-idoc-tester - 生成？ [是/否] (HAS_SAP_INTEG) |
| [ ] qe-sod-analyzer - 生成？ [是/否] (HAS_AUTHORIZATION) |
| |
| 验证： |
| 预期代理： [3 + TRUE 标志的数量] |
| 实际生成： [计数] |
| 状态： [通过/失败] |
| |
| 如果实际 < 预期，你已经失败。在之前生成缺失 |
| 代理。 |
| |
+-------------------------------------------------------------+
如果验证失败，不要进行。
生成后确认（如果适用）
我已并行启动 [N] 个条件代理：
[如果 HAS_SECURITY_CODE] qe-security-scanner [领域: security-compliance]
- OWASP Top 10, SAST 扫描，秘密检测
[如果 HAS_PERFORMANCE_CODE] qe-performance-tester [领域: chaos-resilience]
- 算法复杂度，瓶颈检测，资源分析
[如果 HAS_CRITICAL_CODE] qe-mutation-tester [领域: test-generation]
- 变异测试，存活变异分析，测试有效性
[如果 HAS_MIDDLEWARE] qe-message-broker-tester [领域: enterprise-integration]
- 消息代理测试，队列验证，pub/sub 验证
[如果 HAS_SAP_INTEGRATION] qe-sap-idoc-tester [领域: enterprise-integration]
- IDoc 处理，BAPI 测试，SAP 数据流验证
[如果 HAS_AUTHORIZATION] qe-sod-analyzer [领域: enterprise-integration]
- 职责分离，角色冲突，授权分析
等待条件代理完成...
第5阶段：综合结果并确定推荐
执行：精确决策逻辑
你必须精确应用此逻辑。不要解释。
步骤1：导出复合指标
-----------------------------------------------------------
testCoverage = (lineCoverage + branchCoverage) / 2
complexityScore = avgCyclomatic （使用平均值，不是最大值）
coverageGaps = criticalGaps （仅 P0 差距）
criticalDefects = （来自安全扫描的关键漏洞，如果运行）
+ （来自覆盖度的关键差距）
+ （优先级 == P0 的缺少类别）
步骤2：检查 HOLD 条件（任何触发 HOLD）
-----------------------------------------------------------
如果 testCoverage < 50 -> HOLD（“测试覆盖度严重低”）
如果 complexityScore > 30 -> HOLD（“代码复杂度危险高”）
如果 coverageGaps > 5 -> HOLD（“太多关键覆盖度差距”）
如果 criticalDefects > 2 -> HOLD（“太多关键缺陷”）
步骤3：检查 SHIP 条件（所有需要 SHIP）
-----------------------------------------------------------
如果 testCoverage >= 80
且 complexityScore <= 15
且 coverageGaps == 0
且 criticalDefects == 0 -> SHIP
步骤4：默认
-----------------------------------------------------------
否则 -> CONDITIONAL
决策记录
指标：
- testCoverage = __% （行和分支的平均）
- complexityScore = __ （平均环复杂度）
- coverageGaps = __ （仅 P0 关键差距）
- criticalDefects = __
HOLD 检查：
- testCoverage < 50? __ （是/否）
- complexityScore > 30? __ （是/否）
- coverageGaps > 5? __ （是/否）
- criticalDefects > 2? __ （是/否）
SHIP 检查（仅在无 HOLD 触发时）：
- testCoverage >= 80? __ （是/否）
- complexityScore <= 15? __ （是/否）
- coverageGaps == 0? __ （是/否）
- criticalDefects == 0? __ （是/否）
最终推荐： [SHIP / CONDITIONAL / HOLD]
原因： ___
条件推荐
如果推荐是 CONDITIONAL，提供具体阻塞点：
| 阻塞点 | 当前值 | 要求值 | 所有者 | 行动 |
|---|---|---|---|---|
| … | … | … | [谁] | [做什么] |
如果推荐是 HOLD，提供强制修复：
| 修复 | 优先级 | 努力 | 截止日期 |
|---|---|---|---|
| … | P0 | [范围] | [合并前] |
第6阶段：生成开发报告
执行：完整报告结构
以下所有部分是强制性的。不要缩写。
# QCSD 开发报告： [功能/模块名称]
**生成时间**： [日期/时间]
**推荐**： [SHIP / CONDITIONAL / HOLD]
**执行代理**： [列出所有运行的代理]
**并行批次**： [2 或 3，取决于条件代理]
---
## 执行摘要
| 指标 | 值 | 阈值 | 状态 |
|--------|-------|-----------|--------|
| 测试覆盖度 | X% | >= 80% | 通过/警告/失败 |
| 平均环复杂度 | X | <= 15 | 通过/警告/失败 |
| 覆盖度差距 (P0) | X | 0 | 通过/警告/失败 |
| 关键缺陷 | X | 0 | 通过/警告/失败 |
**推荐理由**： [1-2句话解释为什么 SHIP/CONDITIONAL/HOLD]
---
## TDD 遵守分析
[嵌入或链接来自 qe-tdd-specialist 的完整报告]
### TDD 分数总结
| 原则 | 分数 | 状态 |
|-----------|-------|--------|
[来自 qe-tdd-specialist 的所有 6 个 TDD 原则]
### 测试质量指标
[来自代理输出的关键指标]
---
## 代码复杂度分析
[嵌入或链接来自 qe-code-complexity 的完整报告]
### 热点总结
| 排名 | 函数 | 环复杂度 | 认知复杂度 | 风险 |
|------|----------|------------|-----------|------|
[来自 qe-code-complexity 的前 5 个热点]
### 检测到的代码异味
[来自代理输出的列表]
---
## 覆盖度分析
[嵌入或链接来自 qe-coverage-specialist 的完整报告]
### 覆盖度指标
| 指标 | 值 | 状态 |
|--------|-------|--------|
| 行 | X% | 通过/警告/失败 |
| 分支 | X% | 通过/警告/失败 |
| 函数 | X% | 通过/警告/失败 |
### 覆盖度差距
[来自 qe-coverage-specialist 的所有差距]
---
## 条件分析
[仅当适用时包含 - 基于哪些条件代理运行]
### 安全扫描（如果 HAS_SECURITY_CODE）
[来自 qe-security-scanner 的完整输出]
### 性能分析（如果 HAS_PERFORMANCE_CODE）
[来自 qe-performance-tester 的完整输出]
### 变异分析（如果 HAS_CRITICAL_CODE）
[来自 qe-mutation-tester 的完整输出]
### 中间件测试（如果 HAS_MIDDLEWARE）
[来自 qe-message-broker-tester 的完整输出]
### SAP IDoc 测试（如果 HAS_SAP_INTEGRATION）
[来自 qe-sap-idoc-tester 的完整输出]
### SoD 分析（如果 HAS_AUTHORIZATION）
[来自 qe-sod-analyzer 的完整输出]
---
## 推荐行动
### 合并前 (P0 - 阻塞点)
- [ ] [基于发现的行动]
### Sprint 结束前 (P1 - 重要)
- [ ] [基于发现的行动]
### 技术债务待办列表 (P2 - 改进)
- [ ] [基于发现的行动]
---
## 附录：代理输出
[链接或嵌入每个代理的完整输出]
---
*由 QCSD 开发群集 v1.0 生成*
*执行模型：任务工具并行群集*
将执行摘要报告写入：
${OUTPUT_FOLDER}/01-executive-summary.md
报告验证清单
在呈现报告前：
+-- 执行摘要表完整，包含所有 4 个指标
+-- 推荐匹配决策逻辑输出
+-- TDD 部分包含所有 6 个原则分数
+-- 复杂度部分包含前 5 个热点
+-- 覆盖度部分包含所有差距详情
+-- 条件部分包含所有生成代理
+-- 推荐行动具体（不通用）
+-- 报告保存到输出文件夹
不要呈现不完整的报告。
第7阶段：存储学习和持久状态
执行：总是运行此阶段
+-------------------------------------------------------------+
| 学习持久性必须总是执行 |
| |
| 这不是可选的。它在每个开发扫描上运行。 |
| 它存储发现以用于跨阶段反馈循环、 |
| 历史代码质量跟踪和模式学习。 |
| |
| 不要因任何原因跳过此阶段。 |
| 不要将此视为“最好有”。 |
| 执行规则 E9 适用。 |
+-------------------------------------------------------------+
目的
存储开发发现以用于：
-
跨阶段反馈循环（开发 -> 验证 -> 下一个构思）
-
跨 Sprint 的历史代码质量跟踪
-
随时间变化的复杂度趋势分析
-
缺陷预测改进的模式学习
自动执行步骤（所有三个是强制性的）
步骤1：将开发发现存储到内存
你必须使用开发分析中的实际值执行此 MCP 调用：
mcp__agentic-qe__memory_store({
key: `qcsd-development-${featureId}-${Date.now()}`,
namespace: "qcsd-development",
value: {
featureId: featureId,
featureName: featureName,
recommendation: recommendation, // SHIP, CONDITIONAL, HOLD
metrics: {
testCoverage: testCoverage,
avgCyclomatic: avgCyclomatic,
complexityScore: complexityScore,
coverageGaps: coverageGaps,
criticalDefects: criticalDefects,
tddAdherence: tddAdherence,
mutationScore: mutationScore // 如果适用
},
flags: {
HAS_SECURITY_CODE: HAS_SECURITY_CODE,
HAS_PERFORMANCE_CODE: HAS_PERFORMANCE_CODE,
HAS_CRITICAL_CODE: HAS_CRITICAL_CODE,
HAS_MIDDLEWARE: HAS_MIDDLEWARE,
HAS_SAP_INTEGRATION: HAS_SAP_INTEGRATION,
HAS_AUTHORIZATION: HAS_AUTHORIZATION
},
agentsInvoked: agentList,
timestamp: new Date().toISOString()
}
})
步骤2：与学习协调器共享学习
你必须执行此 MCP 调用以跨领域传播模式：
mcp__agentic-qe__memory_share({
sourceAgentId: "qcsd-development-swarm",
targetAgentIds: ["qe-learning-coordinator", "qe-pattern-learner"],
knowledgeDomain: "development-patterns"
})
步骤3：将学习持久性记录保存到输出文件夹
你必须使用 Write 工具保存持久学习的 JSON 记录：
保存到: ${OUTPUT_FOLDER}/09-learning-persistence.json
内容：
{
"phase": "QCSD-Development",
"featureId": "[功能 ID]",
"featureName": "[功能名称]",
"recommendation": "[SHIP/CONDITIONAL/HOLD]",
"memoryKey": "qcsd-development-[featureId]-[timestamp]",
"namespace": "qcsd-development",
"metrics": {
"testCoverage": [0-100],
"avgCyclomatic": [N],
"complexityScore": [0-100],
"coverageGaps": [N],
"criticalDefects": [N],
"tddAdherence": [0-60],
"mutationScore": [0-100 或 null]
},
"flags": {
"HAS_SECURITY_CODE": true/false,
"HAS_PERFORMANCE_CODE": true/false,
"HAS_CRITICAL_CODE": true/false,
"HAS_MIDDLEWARE": true/false,
"HAS_SAP_INTEGRATION": true/false,
"HAS_AUTHORIZATION": true/false
},
"agentsInvoked": ["列表", "代理"],
"crossPhaseSignals": {
"toVerification": "作为验证基线的质量指标",
"toIdeation": "用于未来风险评估的复杂度模式"
},
"persistedAt": "[ISO 时间戳]"
}
备选方案：CLI 内存命令
如果 MCP memory_store 工具不可用，使用 CLI（仍然是强制性的）：
npx @claude-flow/cli@latest memory store \
--key "qcsd-development-${FEATURE_ID}-$(date +%s)" \
--value '{"recommendation":"[值]","testCoverage":[N],"avgCyclomatic":[N],"coverageGaps":[N]}' \
--namespace qcsd-development
npx @claude-flow/cli@latest hooks post-task \
--task-id "qcsd-development-${FEATURE_ID}" \
--success true
进行第8阶段前的验证
+-- 我是否使用实际值（非占位符）执行了 mcp__agentic-qe__memory_store？
+-- 我是否执行了 mcp__agentic-qe__memory_share 以传播学习？
+-- 我是否将 09-learning-persistence.json 保存到输出文件夹？
+-- JSON 是否包含第5阶段的正确推荐？
+-- JSON 是否包含第2-4阶段的实际指标？
+-- JSON 是否包含第1阶段的实际标志值？
如果任何验证检查失败，不要进行第8阶段。
跨阶段信号消费
开发群集既消费又为其他 QCSD 阶段生成信号：
消费（来自其他阶段）：
+-- 循环 2（战术）：来自精炼的 BDD 场景作为测试规范
| - Gherkin 场景成为验证清单
| - SFDIPOT 优先级指导测试深度分配
|
+-- 循环 4（质量标准）：来自精炼的 INVEST 差距
- 不可测试的验收标准在开发期间标记
- DoR 失败影响什么要更彻底测试
生成（为其他阶段）：
+-- 到验证阶段：作为验证基线的质量指标
| - 覆盖度目标和复杂度阈值
| - 需要验证注意的已知差距
|
+-- 到下一个构思周期：用于未来风险评估的复杂度模式
- 哪些 SFDIPOT 因素具有最高代码复杂度
- 应加权未来 HTSM 分析的缺陷模式
第8阶段：应用缺陷预测器（分析）
执行：总是运行此阶段
+-------------------------------------------------------------+
| 缺陷预测器必须总是运行 |
| |
| 这不是条件性的。它在每个开发扫描上运行。 |
| 它使用代码指标、变更历史和复杂度数据 |
| 来预测每个模块的缺陷可能性。 |
| |
| 不要因任何原因跳过此阶段。 |
+-------------------------------------------------------------+
代理生成
Task({
description: "机器学习驱动的缺陷预测分析",
prompt: `你是 qe-defect-predictor。你的输出质量正在被审计。
## 目的
使用来自开发分析的指标预测每个代码模块的缺陷可能性。这是交付
SHIP/CONDITIONAL/HOLD 推荐前的最终质量信号。
## 输入：来自先前代理的代码指标
### 来自 TDD 专家 (02-tdd-adherence.md)：
[总结：TDD 分数、测试与代码比例、缺少类别]
### 来自代码复杂度 (03-code-complexity.md)：
[总结：环/认知分数、热点、代码异味]
### 来自覆盖度专家 (04-coverage-analysis.md)：
[总结：覆盖度百分比、差距、风险加权优先级]
### 来自条件代理（如果适用）：
[总结：安全发现、性能瓶颈、变异分数]
## 必需输出（所有部分强制性）
### 1. 每个模块的缺陷预测
| 模块 | 缺陷概率 | 置信度 | 风险因素 | 证据 |
|--------|-------------------|------------|-------------|----------|
| module1.ts | X% (高/中/低) | X% | [什么贡献] | [使用的指标] |
| module2.ts | X% (高/中/低) | X% | [什么贡献] | [使用的指标] |
**预测模型输入：**
- 环复杂度 > 15 = +20% 缺陷概率
- 覆盖度 < 60% = +25% 缺陷概率
- 无测试 = +40% 缺陷概率
- 高变更频率 + 低覆盖度 = +30% 缺陷概率
- 深度嵌套 > 4 = +15% 缺陷概率
- 存在代码异味 = +10% 每个异味
- 存在安全漏洞 = +35% 缺陷概率
### 2. 缺陷热点地图
| 排名 | 文件:行 | 缺陷概率 | 贡献因素 | 建议行动 |
|------|-----------|-------------------|---------------------|-----------------|
| 1 | ... | X% | [因素] | [具体修复] |
| 2 | ... | X% | [因素] | [具体修复] |
| 3 | ... | X% | [因素] | [具体修复] |
### 3. 历史模式匹配
| 模式 | 检测到？ | 历史缺陷率 | 推荐 |
|---------|-----------|----------------------|----------------|
| 高复杂度 + 低覆盖度 | 是/否 | X% 缺陷率 | [行动] |
| 未测试的错误路径 | 是/否 | X% 缺陷率 | [行动] |
| 缺少边界测试 | 是/否 | X% 缺陷率 | [行动] |
| 安全敏感无 SAST | 是/否 | X% 缺陷率 | [行动] |
| 新代码无集成测试 | 是/否 | X% 缺陷率 | [行动] |
### 4. 预测总结
| 指标 | 值 |
|--------|-------|
| 分析的模块总数 | X |
| 高风险模块 (>50% 概率) | X |
| 中风险模块 (25-50%) | X |
| 低风险模块 (<25%) | X |
| 平均缺陷概率 | X% |
| 预测置信度 | X% |
**缺陷预测分数: X/100** (反向：较低概率 = 较高分数)
## 输出格式
保存到: ${OUTPUT_FOLDER}/08-defect-prediction.md
使用 Write 工具在完成前保存。
## 提交前验证
+-- 我是否分析了代码库中的所有模块？
+-- 我是否使用了所有先前代理输出的指标？
+-- 我是否按概率对缺陷热点进行了排名？
+-- 我是否检查了历史模式？
+-- 我是否提供了具体修复行动？
+-- 我是否将报告保存到正确的输出路径？`,
subagent_type: "qe-defect-predictor",
run_in_background: true
})
等待分析完成
+-------------------------------------------------------------+
| 等待 qe-defect-predictor 完成后再进行 |
| 第9阶段。 |
| |
| 缺陷预测是开发群集的最终质量信号 |
| - 它将所有指标综合为 |
| 可操作的缺陷风险预测。 |
+-------------------------------------------------------------+
第9阶段：最终输出
在群集执行结束时，总是输出此完成总结：
+---------------------------------------------------------------------+
| QCSD 开发群集完成 |
+---------------------------------------------------------------------+
| |
| 分析的代码： [功能/模块名称] |
| 生成的报告： [计数] |
| 输出文件夹： ${OUTPUT_FOLDER} |
| |
| 开发分数： |
| +-- 测试覆盖度： __% |
| +-- TDD 遵守： __/60 |
| +-- 复杂度分数： __/100 |
| +-- 覆盖度差距 (P0)： __ |
| +-- 缺陷概率： __% |
| [如果 HAS_SECURITY_CODE] |
| +-- 安全分数： __/50 |
| [如果 HAS_PERFORMANCE_CODE] |
| +-- 性能分数： __/40 |
| [如果 HAS_CRITICAL_CODE] |
| +-- 变异分数： __% |
| [如果 HAS_MIDDLEWARE] |
| +-- 中间件健康： __/50 |
| [如果 HAS_SAP_INTEGRATION] |
| +-- SAP 集成： __/50 |
| [如果 HAS_AUTHORIZATION] |
| +-- 授权健康： __/50 |
| |
| 推荐： [SHIP / CONDITIONAL / HOLD] |
| 原因： [1-2 句话理由] |
| |
| 交付物： |
| +-- 01-executive-summary.md |
| +-- 02-tdd-adherence.md |
| +-- 03-code-complexity.md |
| +-- 04-coverage-analysis.md |
| [如果 HAS_SECURITY_CODE] |
| +-- 05-security-scan.md |
| [如果 HAS_PERFORMANCE_CODE] |
| +-- 06-performance-profile.md |
| [如果 HAS_CRITICAL_CODE] |
| +-- 07-mutation-analysis.md |
| [如果 HAS_MIDDLEWARE] |
| +-- 10-middleware-testing.md |
| [如果 HAS_SAP_INTEGRATION] |
| +-- 11-sap-idoc-testing.md |
| [如果 HAS_AUTHORIZATION] |
| +-- 12-sod-analysis.md |
| +-- 08-defect-prediction.md |
| +-- 09-learning-persistence.json |
| |
+---------------------------------------------------------------------+
如果推荐是 HOLD，也输出此突出的行动框：
+---------------------------------------------------------------------+
| 需要行动：代码未准备好交付 |
+---------------------------------------------------------------------+
| |
| 以下阻塞点在合并前必须解决： |
| |
| 1. [阻塞点 1 带具体修复] |
| 2. [阻塞点 2 带具体修复] |
| 3. [阻塞点 3 带具体修复] |
| |
| 后续步骤： |
| - 解决上面列出的所有 P0 阻塞点 |
| - 修复后重新运行 /qcsd-development-swarm |
| - 目标：覆盖度 >= 80%，复杂度 <= 15，0 关键差距 |
| |
+---------------------------------------------------------------------+
如果推荐是 CONDITIONAL，输出此指导框：
+---------------------------------------------------------------------+
| 条件性：代码在合并前需要小改进 |
+---------------------------------------------------------------------+
| |
| 代码可以在以下条件下合并： |
| |
| 1. [条件 1 - 必须在合并前解决] |
| 2. [条件 2 - 必须在后续 PR 中解决] |
| |
| 风险接受： |
| - 技术负责人承认剩余的质量差距 |
| - 为延迟的改进创建后续问题 |
| |
+---------------------------------------------------------------------+
不要在没有显示完成总结的情况下结束群集。
报告文件名映射
| 代理 | 报告文件名 | 阶段 |
|---|---|---|
| qe-tdd-specialist | 02-tdd-adherence.md |
批次 1 |
| qe-code-complexity | 03-code-complexity.md |
批次 1 |
| qe-coverage-specialist | 04-coverage-analysis.md |
批次 1 |
| qe-security-scanner | 05-security-scan.md |
批次 2 (条件性) |
| qe-performance-tester | 06-performance-profile.md |
批次 2 (条件性) |
| qe-mutation-tester | 07-mutation-analysis.md |
批次 2 (条件性) |
| qe-message-broker-tester | 10-middleware-testing.md |
批次 2 (条件性) |
| qe-sap-idoc-tester | 11-sap-idoc-testing.md |
批次 2 (条件性) |
| qe-sod-analyzer | 12-sod-analysis.md |
批次 2 (条件性) |
| qe-defect-predictor | 08-defect-prediction.md |
批次 3 (分析) |
| 学习持久性 | 09-learning-persistence.json |
阶段 7 (自动执行) |
| 综合 | 01-executive-summary.md |
阶段 6 |
DDD 领域集成
此群集跨越 3 个主要领域，4 个条件领域， 和 1 个分析领域：
+-----------------------------------------------------------------------------+
| QCSD 开发 - 领域地图 |
+-----------------------------------------------------------------------------+
| |
| 主要领域（总是活动） |
| +-------------------------------+ +-------------------------------+ |
| | test-generation | | coverage-analysis | |
| | --------------------------- | | --------------------------- | |
| | - qe-tdd-specialist | | - qe-coverage-specialist | |
| | (TDD 遵守，测试 | | (O(log n) 差距检测， | |
| | 质量指标) | | 风险加权覆盖度) | |
| +-------------------------------+ +-------------------------------+ |
| |
| +-------------------------------+ |
| | code-intelligence | |
| | --------------------------- | |
| | - qe-code-complexity | |
| | (环/认知， | |
| | 热点，代码异味) | |
| +-------------------------------+ |
| |
| 条件领域（基于代码内容） |
| +-----------------------+ +-----------------------+ +------------------+ |
| | security-compliance | | chaos-resilience | | test-generation | |
| | ───────────────────── | | ──────────────────── | | ──────────────── | |
| | qe-security-scanner | | qe-performance- | | qe-mutation- | |
| | [如果 HAS_SECURITY_CODE]| | tester | | tester | |
| | | | [如果 HAS_PERF_CODE] | | [如果 HAS_CRITICAL]| |
| +-----------------------+ +-----------------------+ +------------------+ |
| |
| +-----------------------------------------------------------------------+ |
| | enterprise-integration | |
| | ----------------------------------------------------------------- | |
| | - qe-message-broker-tester [如果 HAS_MIDDLEWARE] | |
| | - qe-sap-idoc-tester [如果 HAS_SAP_INTEGRATION] | |
| | - qe-sod-analyzer [如果 HAS_AUTHORIZATION] | |
| +-----------------------------------------------------------------------+ |
| |
| 分析领域（总是活动） |
| +-----------------------------------------------------------------------+ |
| | defect-intelligence | |
| | ----------------------------------------------------------------- | |
| | - qe-defect-predictor (机器学习驱动的缺陷概率，热点地图) | |
| +-----------------------------------------------------------------------+ |
| |
+-----------------------------------------------------------------------------+
执行模型选项
此技能支持 3 个执行模型。根据你的环境选择：
| 模型 | 何时使用 | 优点 | 缺点 |
|---|---|---|---|
| 任务工具（主要） | Claude Code 会话 | 完整代理能力，并行执行 | 需要 Claude Code |
| MCP 工具 | MCP 服务器可用 | 舰队协调，内存持久性 | 需要 MCP 设置 |
| CLI | 终端/脚本 | 在任何地方工作，可脚本化 | 仅顺序 |
按模型快速开始
选项 A：任务工具（推荐）
只需按照上面的技能阶段 - 使用 Task() 调用带 run_in_background: true
选项 B：MCP 工具
// 为开发领域初始化舰队
mcp__agentic-qe__fleet_init({
topology: "hierarchical",
enabledDomains: ["test-generation", "coverage-analysis", "code-intelligence", "security-compliance", "chaos-resilience", "defect-intelligence"],
maxAgents: 7
})
// 协调开发任务
mcp__agentic-qe__task_orchestrate({
task: "qcsd-development-analysis",
strategy: "parallel"
})
选项 C：CLI
# 初始化协调
npx @claude-flow/cli@latest swarm init --topology hierarchical --max-agents 7
# 路由任务
npx @claude-flow/cli@latest hooks pre-task --description "QCSD 开发用于 [功能]"
# 执行代理
npx @claude-flow/cli@latest agent spawn --type qe-tdd-specialist
npx @claude-flow/cli@latest agent spawn --type qe-code-complexity
npx @claude-flow/cli@latest agent spawn --type qe-coverage-specialist
快速参考
执行总结
| 阶段 | 必须做 | 失败条件 |
|---|---|---|
| 1 | 检查所有 6 个标志 | 缺少标志评估 |
| 2 | 在一个消息中生成所有 3 个核心代理 | 少于 3 个任务调用 |
| 3 | 等待完成 | 在结果前进行 |
| 4 | 生成所有标志的条件代理 | 跳过 TRUE 标志 |
| 5 | 精确应用决策逻辑 | 错误推荐 |
| 6 | 生成完整报告 | 缺少部分 |
| 7 | 总是存储学习 + 保存 09-learning-persistence.json | 模式损失，缺少审计跟踪 |
| 8 | 总是运行缺陷预测器 | 跳过分析 |
| 9 | 输出完成总结 | 缺少最终输出 |
质量门阈值
| 指标 | SHIP | CONDITIONAL | HOLD |
|---|---|---|---|
| 测试覆盖度 | >= 80% | 50-79% | < 50% |
| 平均环复杂度 | <= 15 | 16-30 | > 30 |
| 覆盖度差距 (P0) | 0 | 1-5 | > 5 |
| 关键缺陷 | 0 | 1-2 | > 2 |
领域到代理映射
| 领域 | 代理 | 阶段 | 批次 |
|---|---|---|---|
| test-generation | qe-tdd-specialist | 核心 | 1 |
| code-intelligence | qe-code-complexity | 核心 | 1 |
| coverage-analysis | qe-coverage-specialist | 核心 | 1 |
| security-compliance | qe-security-scanner | 条件性 (HAS_SECURITY_CODE) | 2 |
| chaos-resilience | qe-performance-tester | 条件性 (HAS_PERFORMANCE_CODE) | 2 |
| test-generation | qe-mutation-tester | 条件性 (HAS_CRITICAL_CODE) | 2 |
| enterprise-integration | qe-message-broker-tester | 条件性 (HAS_MIDDLEWARE) | 2 |
| enterprise-integration | qe-sap-idoc-tester | 条件性 (HAS_SAP_INTEGRATION) | 2 |
| enterprise-integration | qe-sod-analyzer | 条件性 (HAS_AUTHORIZATION) | 2 |
| defect-intelligence | qe-defect-predictor | 分析 (总是) | 3 |
执行模型快速参考
| 模型 | 初始化 | 代理生成 | 内存存储 |
|---|---|---|---|
| 任务工具 | N/A | Task({ subagent_type, run_in_background: true }) |
N/A (使用 MCP) |
| MCP 工具 | fleet_init({}) |
task_submit({}) |
memory_store({}) |
| CLI | swarm init |
agent spawn |
memory store |
MCP 工具快速参考
// 初始化
mcp__agentic-qe__fleet_init({
topology: "hierarchical",
enabledDomains: ["test-generation", "coverage-analysis", "code-intelligence", "security-compliance", "chaos-resilience", "defect-intelligence"],
maxAgents: 7
})
// 任务提交
mcp__agentic-qe__task_submit({ type: "...", priority: "p0", payload: {...} })
mcp__agentic-qe__task_orchestrate({ task: "...", strategy: "parallel" })
// 状态
mcp__agentic-qe__fleet_status({ verbose: true })
mcp__agentic-qe__task_list({ status: "pending" })
// 内存
mcp__agentic-qe__memory_store({ key: "...", value: {...}, namespace: "qcsd-development" })
mcp__agentic-qe__memory_query({ pattern: "qcsd-development-*", namespace: "qcsd-development" })
mcp__agentic-qe__memory_share({
sourceAgentId: "qcsd-development-swarm",
targetAgentIds: ["qe-learning-coordinator"],
knowledgeDomain: "development-patterns"
})
CLI 快速参考
# 初始化
npx @claude-flow/cli@latest swarm init --topology hierarchical --max-agents 7
# 代理操作
npx @claude-flow/cli@latest agent spawn --type [代理类型] --task "[描述]"
npx @claude-flow/cli@latest hooks pre-task --description "[任务]"
npx @claude-flow/cli@latest hooks post-task --task-id "[ID]" --success true
# 状态
npx @claude-flow/cli@latest swarm status
# 内存
npx @claude-flow/cli@latest memory store --key "[密钥]" --value "[JSON]" --namespace qcsd-development
npx @claude-flow/cli@latest memory search --query "[查询]" --namespace qcsd-development
npx @claude-flow/cli@latest memory list --namespace qcsd-development
群集拓扑
QCSD 开发群集 v1.0
|
批次 1（核心 - 并行）
+-----------+---+-----------+
| | |
+-----v-----+ +---v--------+ +---v-----------+
| TDD | | 代码 | | 覆盖度 |
| 专家 | | 复杂度 | | 专家 |
| (R-G-R) | | (环/认知) | | (O(log n)) |
|-----------| |------------| |---------------|
| test-gen | | code-intel | | coverage-anly |
+-----+-----+ +-----+------+ +------+--------+
| | |
+--------------+---------------+
|
[指标门]
|
批次 2（条件性 - 并行）
+-----------+---+-----------+
| | |
+-----v-----+ +---v--------+ +---v----------+
| 安全 | | 性能 | | 变异 |
| 扫描器 | | 测试器 | | 测试器 |
| [如果 SEC]| | [如果 PERF] | | [如果 CRIT] |
|-----------| |------------| |--------------|
| sec-compl | | chaos-res | | test-gen |
+-----------+ +------------+ +--------------+
+-------------+---+-------------+
| | |
+-----v------+ +---v--------+ +------v-------+
| 消息代理 | | SAP IDoc | | SoD |
| 测试器 | | 测试器 | | 分析器 |
| [如果 MIDW]| | [如果 SAP] | | [如果 AUTH] |
|------------| |------------| |--------------|
| ent-integ | | ent-integ | | ent-integ |
+------------+ +------------+ +--------------+
|
[综合]
|
阶段 7（学习持久性 - 总是）
|
+-------v-------+
| memory_store |
| memory_share |
| 09-learning- |
| persistence |
| (总是运行) |
+-------+-------+
|
批次 3（分析 - 总是）
|
+-------v-------+
| 缺陷 |
| 预测器 |
| (总是运行) |
|---------------|
| defect-intel |
+-------+-------+
|
[最终报告]
清单总结
| 资源类型 | 计数 | 主要 | 条件性 | 分析 |
|---|---|---|---|---|
| 代理 | 10 | 3 | 6 | 1 |
| 子代理 | 0 | - | - | - |
| 技能 | 4 | 4 | - | - |
| 领域 | 8 | 3 | 4 | 1 |
| 并行批次 | 3 | 1 | 1 | 1 |
使用的技能：
tdd-london-chicago- TDD 方法论指导mutation-testing- 变异测试模式performance-testing- 性能分析框架security-testing- OWASP 扫描模式
应用的框架：
- TDD 红-绿-重构 - 测试优先开发评估
- 环/认知复杂度 - 代码复杂度测量
- 次线性覆盖度分析 - O(log n) 差距检测
- OWASP Top 10 - 安全漏洞评估
- 变异测试 - 测试套件有效性验证
- 机器学习缺陷预测 - 基于模式的缺陷预测
关键原则
代码在质量被证明时交付，而不是在截止日期到达时。
此群集提供：
- 是否实践 TDD？ -> TDD 遵守评估（6个原则）
- 代码是否可维护？ -> 复杂度分析（环 + 认知）
- 是否存在测试差距？ -> 覆盖度差距检测（O(log n) 次线性）
- 是否安全？ -> SAST 安全扫描（如果存在安全代码）
- 是否性能良好？ -> 性能分析（如果存在性能代码）
- 测试是否有效？ -> 变异分析（如果存在关键代码）
- 缺陷将出现在哪里？ -> 缺陷预测（总是）
- 我们应该交付吗？ -> SHIP/CONDITIONAL/HOLD 决策
- 我们学到了什么？ -> 内存持久性用于未来周期