Optimize a spec

The deterministic translator always gives you a complete, runnable spec. The optimization pass is an optional second step: it lets an LLM read that spec and propose a polished version you accept via a diff — without ever rewriting the original behind your back.

What it improves

• Adds the assertions the run observed. The agent saw a "Welcome, alice" heading, an "Invalid email" error, a counter tick to 03 — the pass turns those observations into await expect(...) assertions.
• Completes multi-step shapes. Where the deterministic draft left a // hover:optimizable marker (a file upload, a download), the pass can fill it in, learning from Hover's built-in worked-example seeds.
• Flags buggy behaviour, doesn't hide it. When an observed outcome looks like a bug (a stale error that never clears), the pass still asserts what actually happened but marks the line // KNOWN BUG: …, so a human can find it and the test breaks loudly once the app is fixed.

You always keep the original

The pass writes a candidate to .hover/cache/optimized/<slug>.spec.ts.draft — a path the Playwright runner never collects. You review the diff (the candidate opens automatically in a diff view) and either promote it (it replaces the spec; the prior version is in git) or discard it. The deterministic original is the fallback, always.

When it runs

The optimization pass is off by default. Trigger it from the optional VS Code cockpit's Dashboard (the ✨ Optimize action). It writes a diff-reviewed candidate; the original is always kept and never auto-promoted.

Why it doesn't dent the moat

The pass is a local code-generation helper — its input is data Hover already holds (the draft, the sidecar, the built-in seeds), never live page content. It runs through the same validator as the deterministic path (no XPath, no waitForTimeout, must parse). And it never becomes the spec without a human diff. CI still runs plain Playwright, zero tokens.