# Manual smoke — F10 interactive review in the preview (#29)

F10 makes the rendered preview the **single interactive review surface**: the
editor is clean (zero annotations), and you accept/reject Claude's proposals
*inside the preview*. The webview's *visual* rendering (theming, ✓/✗ buttons) is
verified here, not in the automated host E2E (the webview is a sealed sandbox).
Run once per change that touches F10. One live turn hits the SDK (or use the
`proposeAgentEdit` seam to stay key-free).

## Setup

1. `npm run build`
2. Launch the Extension Development Host (F5 in VS Code, or the Run panel) with
   `sandbox/` open.
3. Open a markdown document containing some prose (e.g. copy
   `test/e2e/fixtures/workspace/docs/preview.md`).

## Steps

1. **Clean editor.** Look at the source editor: there is **no attribution tint,
   no in-editor proposal comment threads, and no diff** — the editor is a plain
   text buffer (F10/INV-32). All review lives in the preview.
2. **Open the preview.** Run **"Cowriting: Open Review Preview"** (or
   `Ctrl+Alt+R`). A preview opens beside the editor. The header shows an
   **Annotations** switch (on by default) and a summary.
3. **Edit prose.** In the source editor, change a word in a paragraph. The
   preview updates (≈150 ms) in its on-state: the new word highlighted as a green
   insertion (`<ins>` / `cw-by-human`), the old word struck (`<del>` / `cw-del`);
   the summary increments. Your own typing is colored green (human).
4. **Ask Claude to edit a selection.** Select a sentence → **"Ask Claude to Edit
   Selection"** → instruct (or invoke the `proposeAgentEdit` seam). A **blue
   `cw-proposal` block** appears in the preview, showing the struck replaced text
   and the proposed replacement, with **✓ / ✗** buttons in a `cw-actions` span.
   The editor itself does **not** change (INV-10 — propose never mutates the doc).
5. **Accept one.** Click **✓** on the proposal. Expect: the replacement **lands
   in the document** (the editor text updates), the proposal block **clears** from
   the preview, and the landed Claude text is **not** marked as a change (the
   baseline advanced past the landing; INV-18).
6. **Reject another.** Propose a second edit, then click **✗** on it. Expect: the
   block **vanishes** from the preview and the **document is unchanged**.
7. **Toggle Annotations off.** Flip the header **Annotations** switch off. Expect:
   the preview shows **clean rendered markdown** — no green/blue author colors, no
   struck deletions, no proposal blocks (INV-33). Flip it **on** again: the marks
   and any pending proposal blocks return.
8. **Status-bar indicator (PUC-6).** Close the preview. With a **pending
   proposal** outstanding and **no preview open**, a status-bar item shows the
   pending count (e.g. "1 Claude proposal"). **Click it** — the review preview
   opens and the indicator disappears.
9. **Theme.** Toggle light / dark / high-contrast (`Ctrl+K Ctrl+T`). The proposal
   block and its ✓ / ✗ buttons, and the green/blue author colors, restyle to the
   theme and stay legible in each.
10. **Cleanliness.** `git status` shows nothing written to the document, sidecar,
    or repo by the preview (INV-20).

## Pass criteria

All ten steps behave as described; no console errors in the webview devtools;
the editor stays decoration-free throughout; nothing is persisted by the preview.