优化一个 spec

确定性翻译器总是给你一个完整、可运行的 spec。优化 pass 是一个可选的第二步：它让 LLM 读这个 spec，并提出一个打磨过的版本，你通过 diff 来接受它——绝不会在你背后重写原始版本。

它改进什么

• 补上运行中观察到的断言。 agent 看到过一个 "Welcome, alice" 标题、一个 "Invalid email" 错误、一个计数器跳到 03——这个 pass 会把这些观察转成 await expect(...) 断言。
• 补全多步骤形态。 在确定性草稿留下 // hover:optimizable 标记的地方（一次文件上传、一次下载），这个 pass 可以把它填上，方法是从 Hover 内置的实例范例种子中学习。
• 标记出有问题的行为，而不是掩盖它。 当某个观察到的结果看起来像 bug（一个永远不清除的陈旧错误），这个 pass 依然会断言实际发生了什么，但会把那一行标记为 // KNOWN BUG: …，这样人能找到它，而且一旦应用修好，测试会大声地失败。

你始终保留原始版本

这个 pass 会把一个候选版本写到 .hover/cache/optimized/<slug>.spec.ts.draft——一个 Playwright runner 永远不会收集的路径。你审阅 diff（候选版本会自动在 diff 视图中打开），然后要么提升（promote）它（它替换掉 spec；先前的版本在 git 里），要么丢弃它。确定性的原始版本始终是兜底。

什么时候运行

优化 pass 默认关闭。从可选的 VS Code cockpit 的 Dashboard 触发它（✨ Optimize 动作）。它会写出一个经过 diff 审阅的候选版本；原始版本始终保留，绝不会被自动提升。

为什么它不损害护城河

这个 pass 是一个本地代码生成助手——它的输入是 Hover 已经持有的数据（草稿、sidecar、内置种子），绝不是实时页面内容。它经过与确定性路径相同的 validator（不允许 XPath、不允许 waitForTimeout、必须能 parse）。而且没有人工 diff，它绝不会变成 spec。CI 依然运行纯 Playwright，零 token。