benstull/vscode-cowriting-plugin
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2a1d7623f5ceaddeb669bf5bfdd62d705c96b3e5
vscode-cowriting-plugin/docs/MANUAL-SMOKE-F10.md
T
Ben Stull 0f5bc1b4ce 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>
2026-06-12 00:32:46 -07:00

3.3 KiB
Raw Blame History

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.

Reference in New Issue View Git Blame Copy Permalink