Perf issue

整套测量由你负责。你来规划、评审，并核实数字。 每个修复都要对应一次测量。不要拿读源码代替测量。

用对应的 control skill 采集一份基线 trace（性能追踪记录）。用 benchmark-checklist skill 核查这份基线，之后得到的每个数字也一样要核查。
用 how 给假设找依据。没实际跑过，不要断言性能已经到了上限。大多数修复出自下面八类策略。把它们当作提出假设的来源，不要当成清单逐项过。只有 trace 显示出某一类所说的信号，这一类才值得一试。
- 消除。 优化热路径之前，先问它是否非存在不可：没人用到结果的计算，对这个用户始终关闭的功能开关，把状态多余地镜像一份的同步，为了「以防万一」留着的旧代码路径。trace 只能显示哪里慢，从来不能显示哪里可以删。所以这一类要靠 how 走一轮分析，不靠性能分析器。
- 分而治之。 主要开销随输入规模增长。把工作拆开，让每一块处理的量更少（分块、分片、剪枝搜索空间），或者让互不依赖的几块并行跑。
- 缓存。 同样的输入反复触发同样的计算或数据拉取。把结果存下来复用。宣布有提升之前，先说清什么会让缓存失效。
- 间接层。 热路径上在做昂贵的工作，而一个更便宜的中间环节本可以接过去：用索引代替扫描，用队列把工作移出交互线程，用句柄让更便宜的实现替换进来。只有这一层从关键路径上省掉的比它自己增加的多，才加这一层。
- 批处理。 很多小操作各付一笔固定开销（RPC、查询、系统调用、绘制调用）。把它们合并起来，每一批只付一次。
- 冗余。 等待卡在某一个慢实例或某一次慢尝试上。把同一份工作多做几份（副本、对冲请求、推测执行），取最快的结果。trace 必须显示等待占了大头，而且系统还有余量。
- 惰性求值。 开销花在了永远用不上或暂时还用不上的结果上（启动路径上的提前初始化，渲染屏幕外的条目）。把工作推迟到第一次用到时再做。
- 调度。 这项工作非做不可，但不该在用户交互的那一刻做。把它挪到没人等待的时候：空闲回调，启动后的后台预热，用户到来之前的预计算，帧提交之后的清理。收益体现在感知延迟上，所以要测交互路径，而不是总工作量。
根据 trace 规划修复。修复跨函数边界时，先用 architect。把实现交给子代理，用你配置的 perf-issue 模型（默认 grok-4.7-xhigh-fast）。评审 diff。采集一份修复后的 trace。按 sequence-verifiable-units 原则 skill 推进，每次尝试都先验证，再试下一个。
解析并比较产物（把 JSON 导入 sqlite，做 diff）。结果是「Inconclusive」（没有定论），或者测错了界面，都不算通过。要把它标出来。
在 PR 里引用这次测量。
执行 Opening a PR。

如果要针对某个指标持续改进，而不是做一次性修复，用 Hillclimb playbook（playbooks/hillclimb.md）。

回复： 基线数字、修复后数字、差值、产物路径。