F10 SLICE-4: manual smoke checklist + README F10 section (#29)

Adds docs/MANUAL-SMOKE-F10.md (clean editor → edit → propose → ✓/✗ →
Annotations toggle → status-bar PUC-6 → theming → cleanliness) following the
F7/F9 smoke format. Adds the F10 "write left / review right" section to the
README feature list and notes F6's two-pane diff and F9's authorship view are
retained only as data layers, not separate user surfaces.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ben Stull
2026-06-12 00:32:46 -07:00
parent cdeb41ede4
commit 0f5bc1b4ce
2 changed files with 84 additions and 1 deletions
+26 -1
View File
@@ -14,7 +14,8 @@ catalog (a pure, key-free SDK call) in a notification and the
Features shipped so far: F2 region-anchored threads (Feature #4), F3 live Features shipped so far: F2 region-anchored threads (Feature #4), F3 live
human/Claude attribution (Feature #6), F4 propose/accept diff flow human/Claude attribution (Feature #6), F4 propose/accept diff flow
(Feature #12), F5 cross-rung sidecar contract (Feature #14), F6 diff-view (Feature #12), F5 cross-rung sidecar contract (Feature #14), F6 diff-view
toggle (Feature #17). toggle (Feature #17), and F10 interactive review — **write left / review
right** (Feature #29).
## Architecture ## Architecture
@@ -237,6 +238,30 @@ a plain PR revert with zero data migration.
Design: `vscode-cowriting-plugin-content/specs/coauthoring-out-of-workspace.md`. Design: `vscode-cowriting-plugin-content/specs/coauthoring-out-of-workspace.md`.
Live smoke: [`docs/MANUAL-SMOKE-F8.md`](docs/MANUAL-SMOKE-F8.md). Live smoke: [`docs/MANUAL-SMOKE-F8.md`](docs/MANUAL-SMOKE-F8.md).
## F10 — Interactive review: write left / review right (Feature #29)
A clean, **zero-annotation editor** on the left; the rendered preview on the
right as the **single interactive review surface**. The editor carries no
attribution tint, no in-editor proposal threads, and no diff — all review lives
in the preview, toggled by the **Annotations** switch in its header (on by
default). `Ctrl+Alt+R` opens **"Open Review Preview"**.
In the on-state the preview shows **green = human / blue = Claude /
strikethrough = deleted**, and surfaces each of Claude's pending F4 proposals as
a blue `cw-proposal` block with **✓ / ✗** buttons: **✓** accepts (the
replacement lands Claude-attributed via the seam and the baseline advances past
it), **✗** rejects (the block vanishes, the document untouched). With no preview
open, a status-bar indicator shows the pending-proposal count and opens the
review when clicked. Toggle **Annotations** off for clean rendered markdown.
Read-only, sealed webview, no new persistence (INV-32..34).
F6's two-pane diff and F9's authorship view are **retained only as data layers**
(the baseline the preview diffs against; the F3 attribution that colors it) —
they are no longer separate user surfaces.
Design: `vscode-cowriting-plugin-content/specs/coauthoring-interactive-review.md`.
Live smoke: [`docs/MANUAL-SMOKE-F10.md`](docs/MANUAL-SMOKE-F10.md).
## Develop ## Develop
- `npm run watch` — rebuild on change. - `npm run watch` — rebuild on change.
+58
View File
@@ -0,0 +1,58 @@
# 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.