/performance-engineering

name: performance-engineering
description: 性能工程专家 Owner — 当任务涉及性能优化、性能预算、benchmark、profiling、p95/p99、吞吐、延迟、资源效率、容量规划、压测或性能回归时使用；要求先建立可比较基线，再定位瓶颈、评估容量并形成统计可信的回归结论。

Performance Engineering

职责

把“更快”转化为可复现的 workload、预算、基准、profiling、瓶颈归因、容量与回归合同。dev-optimization 负责开发流程，SRE 负责生产运行；本 Skill 负责性能证据的专业可信度。

PerformanceEngineeringGate

| 字段 | 要求 | |---|---| | workloadModel | 用户路径、数据规模、并发、读写比、缓存状态、突发与稳态 | | performanceBudget | latency percentile、throughput、resource、error/saturation 阈值 | | benchmarkProtocol | 环境、版本、warmup、sample、duration、重复次数、噪声控制 | | profilingEvidence | CPU/heap/I/O/lock/network/GC 等证据和采样边界 | | bottleneckAttribution | 症状→资源→调用路径→因果实验，区分相关与因果 | | capacityModel | 单实例能力、扩展曲线、饱和点、headroom、成本 | | regressionThresholds | 绝对/相对阈值、置信区间、噪声带和阻断条件 |

执行流程

1. 冻结当前基线、目标用户路径和不可牺牲的正确性/稳定性。 2. 建立代表 workload；区分 cold/warm cache、steady/burst 和 local/CI/prod-like。 3. 先测基线，再 profiling；禁止先改代码后寻找支持结论的数据。 4. 一次改变一个主要变量，保留版本、硬件、配置、数据和命令。 5. 同时看 latency distribution、throughput、errors、CPU/memory/I/O/GC 和尾延迟。 6. 输出 capacity/headroom 与成本权衡；优化不能靠隐藏限流或丢请求。 7. 用同协议重跑对照，达到阈值才判 accepted。

ModulePerformanceCoverageAndMaintenanceGate

当框架、SDK、CLI、runtime 或公共包声称“完整性能覆盖”时，单一 benchmark、全局 DIM 或一个 release gate 不足以通过。必须先为每个功能判定 performance applicability，再为每个适用模块建立：

| 维度 | 必填证据 | |---|---| | moduleProtocol | workload、budget、immutable baseline、candidate comparison | | capacityResource | capacity/headroom、CPU/memory/I/O/GC、饱和点和成本 | | stabilityRecovery | leak/pressure（适用时）、故障/冷却/恢复、正确性守恒 | | maintenanceTriggers | PR、main、scheduled、RC、post-release 的触发与升级关系 | | evidenceGovernance | retention、freshness、drift、owner、skip/N/A/flake 处理 | | coverageState | total/applicable/executed/accepted/failed/skipped/stale，清单完成与执行完成分开 |

全部适用模块 accepted 前只能报告 `partial`；不可变基线变更必须有授权和迁移证据，不能通过减少适用模块、删除 flake 或重写基线制造通过率。

ExecutionChainBenchmarkGate

DevCodex 自身的任务续接、上下文/Profile/Skill 读取、验证 DAG 与增量分析优化统一输出 `ExecutionChainBenchmarkResultV1`。四个 direct-benefit 维度为 validation wall time、delivered bytes、analysis recompute work、resume setup cost；baseline/candidate 必须使用同一环境 identity、单位和样本策略，等权计算几何平均，禁止把不同量纲直接相加。

只有 correctness 指标全为 0、综合改善至少 25%、至少 3/4 维度改善 20%、任一维度回归不超过 5%、instrumentation overhead 不超过 3% 时，结果才可 `accepted`。样本不足、环境不一致或宿主 token/TTFT 不可观测时保持 `provisional` / `N/A`；不得用 bytes 冒充 token。任何默认晋级还必须有 prospective trial（至少 3 个可比 WorkUnit 或 2 个独立上下文），历史样例只能证明基线。

性能 accepted 还必须证明 lifecycle 能控制真实执行路径：将每个受控 feature 置为 `rolled-back` 后，task index、Context cache、changed validation、Profile section、Skill bundle 与 ProjectKnowledge 都必须通过 `ExecutionOptimizationFeatureDecisionV1` 回到安全非优化路径；changed validation 必须保留显式 intent/route 并执行 `direct-validation-plan`，不得暗升 full，其余消费者回到完整读取路径。只有 status/doctor 投影变化、消费者仍走加速时属于 correctness failure，收益数据作废。

基准 evaluator 使用 `npm run benchmark:execution-chain -- --input <ExecutionChainBenchmarkInputV1.json>`；只有显式 `--output` 才可写结果。benchmark、website build 与 package smoke 串行执行，避免派生产物污染可比性。

输出字段

`workloadModel`、`performanceBudget`、`benchmarkProtocol`、`baselineEvidence`、`profilingEvidence`、`bottleneckAttribution`、`capacityModel`、`regressionThresholds`、`comparisonLimits`、`modulePerformanceCoverage`、`maintenanceTriggers`、`executionChainBenchmark`、`decision`、`evidenceMatrix`。

反模式

• 没有基线就声称提升、最快或无回归。
• 只报平均值，不报 p95/p99、错误率和资源饱和。
• 对比环境、版本、数据或缓存状态不同却给出百分比。
• benchmark 本身写文件、重建 dist 或污染后续 pack。
• 微基准变快就推断端到端用户路径变快。
• 通过降低正确性、持久性、审计或安全换性能而不披露。

验证

至少覆盖 warmup/measurement 分离、重复样本、噪声带、环境元数据、基线可比性、资源瓶颈、正确性守恒、容量拐点和回归阈值；不可比较时结论必须为 `inconclusive`。