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