dev-optimization

name	dev-optimization
description	性能优化子类型规范 — 基准测试前置 + autocannon 压测集成

Dev Optimization Skill

触发条件

用户要求性能优化、吞吐量提升、响应时间降低、内存/CPU 优化。

前置条件（必须满足）

项	要求
api-verification 已通过	优化前接口测试基线已建立（.http + .cjs 产物存在）
基准数据	优化前已有性能指标（QPS/P99/内存）作为对比基线
测试环境	压测在隔离环境执行，不影响生产
ServiceLifecycleCleanup	若 AI 启动压测 target、dev server、本地 API/mock、数据库代理或 SSH 隧道，必须记录 PID/job/端口并在验证完成后主动关闭
AdapterBenchmarkAttribution	adapter、provider、connector、SDK 或性能 benchmark 必须记录基线、环境、版本、负载、归因边界和不可比较因素

工具规范

默认候选工具：autocannon。解析顺序固定为项目既有压测脚本 → 项目已安装的本地依赖 → 经用户确认的隔离临时工具；缺失时先报告替代方案。npm i -g autocannon 或任何全局安装会修改用户环境，必须单独说明目标、影响、恢复方式并取得当前明确授权，不能由 optimization 路由、Auto、Profile 或工具缺失隐式授权。

# 基线测量
npx --no-install autocannon -c 100 -d 30 -j http://localhost:3000/api/target > baseline.json

# 优化后对比
npx --no-install autocannon -c 100 -d 30 -j http://localhost:3000/api/target > optimized.json
npx --no-install autocannon-compare baseline.json optimized.json

CP 流程

• CP1：确认优化目标（指标 + 目标值）+ 当前基线数据
• CP2：确认优化方案（无 Breaking Changes，或 BC 已评估） → dev-plan-review（PR-1 已自检，PR-2~PR-7 详细验证）→ CP3
• CP3：确认任务拆分、执行顺序、依赖、验证方式、ServiceLifecycleCleanup 与回滚策略；05-实施进度.md 对小任务不是默认产物，但跨多轮/多阶段、阻塞、用户要求持续跟踪、多批次、预计修改 ≥10 文件、控制面或模板-校验链任务必须启用

产出物

• 基准测试报告（优化前后对比）
• reports/optimizations/ 开发报告（含性能指标对比表）

关键规则

• 🔴 禁止无基线数据的"盲优化"
• 优化不改变外部接口行为（否则走 dev-default 流程）
• 启动性能优化或 dev 日志治理必须执行 StartupPhaseTrace：先把启动日志按阶段归类，并与 Profile / startup summary 使用同一套阶段命名，再决定减噪、lazy loading 或 background warmup；不得只隐藏扁平日志后宣告优化完成
• adapter、provider、connector、SDK 或框架适配 benchmark 必须执行 AdapterBenchmarkAttribution；不得把网络、缓存预热、依赖树、框架版本、测试环境或压测工具差异误归因给业务代码