Live Mode: Let the Browser Share the Decision

The control loop now reaches the point where a person must compare a rendered alternative, not merely read an agent's source diff. Impeccable's live mode is the mechanism for that comparison. It connects a browser, a localhost helper, and the agent so the user can select an element, request several real variants, cycle through them, and accept or discard one. The important design question is not whether the browser can show a preview. It is whether the chosen preview can return to the project's source without losing state, provenance, or cleanup.

Three parties, one local event loop

Live mode begins in a trusted local checkout with a running development server that supports HMR, or with a static HTML file that can be opened in the browser. The helper resolves the project roots and the page file, injects the live browser script, and waits for events. The browser is where the user points at an element and chooses an action. The localhost server relays messages. The agent performs the source work.

Those roles are separate because each side has a different job. The browser owns the immediate visual state: which element is selected, which variant is visible, whether the user presses Accept or Discard. The server owns the connection between browser and agent: it serves the helper, pushes events through Server-Sent Events, accepts browser messages through fetch requests, and holds the agent's polling queue. The agent owns the source transformation: it locates the selected element, writes the variant wrapper, produces the HTML and CSS alternatives, and cleans the source when the user decides.

The agent communicates through an HTTP long-poll rather than a harness-specific socket. A poll waits until the browser has something to say. When the user clicks Go, the browser posts a generate event to the local server. The server queues it. The agent's poll returns the event with the element, action, requested count, page URL, and any annotations. The agent then wraps the source selection and writes all variants in one edit. A reply tells the server that the variants are ready, and the server forwards that state to the browser through SSE.

sequenceDiagram participant B as Browser participant S as Localhost server participant A as Agent B->>S: Post generate event S->>A: Long-poll returns event A->>A: Wrap source and write variants A->>S: Reply done with source path S-->>B: SSE update B->>B: Cycle variants B->>S: Accept or discard S->>A: Poll returns decision A->>A: Clean source and journal state A->>S: Complete session

The event loop is deliberately mundane. It uses local HTTP, fetch, SSE, and a shell-visible poll because those mechanisms are available across AI coding harnesses without requiring every host to understand a new browser protocol. The architecture record describes the server as a zero-dependency local Node process, which matters for an installed skill that should work inside a project without adding a separate live-editing package.