Files
Ben Stull c94b9ccfe7 #46 (SLICE-3, accept): Accept all pending proposals in one gesture
Document-edit flow SLICE-3 — completes reach→review→accept
(specs/coauthoring-document-edit-flow.md §7.2, INV-42). A single "Accept all"
gesture applies every pending proposal on the current document through the
existing F4 acceptById seam (block proposals take the INV-40 word-precise path
automatically), in descending anchor order so an earlier accept never invalidates
a later one, skipping (never force-applying) proposals that can't anchor and
reporting applied-vs-skipped. Batched application of the existing accept path — no
new mechanism; the webview posts intent only (INV-35). No confirmation dialog
(undo restores).

- proposalController.ts: acceptAllProposals(document) → {applied, skipped}
  (descending order, orphan-skip); accept/acceptById gain a silent opt so the
  batch suppresses N per-proposal orphan warnings in favour of one report.
- trackChangesPreview.ts: ToolbarMsg += {type:"acceptAll"}; handleWebviewMessage
  routes it to a public acceptAll(document) that batches + reports.
- extension.ts + package.json: cowriting.acceptAllProposals command (active doc,
  markdown-gated palette entry) for the non-webview path.
- media/preview.ts + shellHtml: "✓✓ Accept all" toolbar button, posting the
  intent, shown only with ≥2 pending proposals (authorable, on-state).
- trackChangesModel.ts: diffToBlockHunks now emits one block-aligned hunk per
  CHANGED block even when changed blocks are ADJACENT (treats changed blocks as
  1:1 anchors alongside unchanged ones; gap-spans only cover add/remove runs
  between anchors) — fixes adjacent changed blocks collapsing into one proposal.
- f12Accept host E2E (apply-all reconstructs; orphan skip + report; single
  proposal; command registered/gated); MANUAL-SMOKE-F12 §3.

214 unit + 73/5 host E2E green. Completes the document-edit-flow cluster
(#42 reach + #47 review + #46 accept).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-13 08:15:55 -07:00

5.4 KiB
Raw Permalink Blame History

Manual smoke — F12 document-edit flow

Covers the document-edit-flow cluster (specs/coauthoring-document-edit-flow.md, #42 · #47 · #46). This file is filled in slice by slice.

SLICE-1 — #42 (reach): selection-aware Ask-Claude from body + tab (INV-38)

Run the extension (F5) on a markdown document under the sandbox workspace.

  1. Body, with selection (PUC-2). Select a paragraph, right-click the editor body. Expect Ask Claude to Edit Selection in the menu (and not "Edit Document"). Pick it → instruct → submit; a single proposal lands over the selection (existing F11 behavior, unchanged).
  2. Body, no selection (PUC-1). Clear the selection (click once), right-click the editor body. Expect Ask Claude to Edit Document (and not "Edit Selection"). Pick it → instruct → submit; the whole-document rewrite surfaces as F4 proposal(s) in the preview.
  3. Tab, with selection (PUC-3). With a selection active, right-click the editor tab. Expect Ask Claude to Edit Selection, acting on that tab's document.
  4. Tab, no selection (PUC-3). With no selection, right-click the editor tab. Expect Ask Claude to Edit Document, acting on that tab's document — even if a different editor is the active one. Open two markdown tabs A and B, make A active, right-click B's tab → Edit Document → the proposals land on B, not A.
  5. Markdown-gated. Open a non-markdown file (e.g. .txt). Right-click body or tab: neither Ask Claude to Edit Selection nor Edit Document appears.
  6. Single edit path. Both entries route through the same runEditAndPropose path — there is no second edit code path (INV-38). Nothing is written to the document or sidecar by merely invoking the menu (INV-10/20/35) until you accept.

Pass criteria

The body and tab menus show exactly one Ask-Claude edit entry, matching the live selection state (selection → Edit Selection; none → Edit Document); the tab gesture targets the clicked tab's document, not the active editor; both are absent on non-markdown docs; no console errors.

SLICE-2 — #47 (review): per-block proposals + word-precise attribution (INV-39/40/41)

On a markdown doc with several paragraphs, Ask Claude to Edit Document with a light copy-edit instruction (e.g. "tighten the prose, fix typos").

  1. One proposal per changed block (INV-39). Claude's pass surfaces as one ✓/✗ block per changed paragraph/header/bullet, not a flurry of word-level blocks. A paragraph with several word edits is a single proposal; the word-level <ins>/<del> still shows inside it. Untouched paragraphs show no proposal.
  2. Changed fence is atomic (INV-23). If Claude edits a code/mermaid fence, it is one whole-fence proposal.
  3. Accept attributes only the changed words (INV-40). Accept a block proposal, then toggle the preview to Authorship/colors (or re-open in the on-state): only the words Claude actually changed are Claude-colored; the unchanged words in that block keep their prior author. The block is the decision unit; the word is the attribution unit.
  4. Inserted block accepts cleanly (INV-41). If Claude adds a new paragraph, its proposal accepts (it is anchored to an adjacent block, never a born-orphaned/zero-width proposal).
  5. Undo. Accepting a block is currently N undo steps (one per changed run inside the block) — Ctrl+Z repeatedly restores it. (Spec deferred note: single-undo-step grouping is a possible follow-up.)
  6. Selection edits unchanged. Edit Selection still produces exactly one proposal over the selection (no block fan-out).

Pass criteria

A document edit yields one in-context proposal per changed block (fences atomic); accepting a block lands the whole block but Claude-attributes only the words it changed; inserted blocks accept; selection edits are unaffected; no console errors.

SLICE-3 — #46 (accept): Accept all (INV-42)

On a markdown doc, Ask Claude to Edit Document with a pass that changes several blocks, so the preview shows ≥ 2 pending proposals.

  1. Button appears at ≥2 (PUC-6). The preview toolbar shows ✓✓ Accept all only when there are 2 or more pending proposals (and the doc is authorable, annotations on). With 01 pending it is hidden.
  2. One gesture applies all. Click Accept all: every pending proposal lands (Claude-attributed per INV-40), the ✓/✗ blocks clear, and a status message reports how many were accepted. No confirmation dialog.
  3. Undo restores. Ctrl+Z walks back the applied edits (consistent with single accept; a block accept is itself N steps — see SLICE-2).
  4. Orphan-skip + report. If one proposal's target text was changed by hand first (so it can't anchor), Accept all applies the rest and the report says … , N skipped (target text changed — undo or reject); the orphaned proposal stays pending, its text untouched (never force-applied).
  5. Command path. With no preview panel open, the command palette Cowriting: Accept All Claude Proposals (markdown-gated) applies all proposals on the active doc with the same report.

Pass criteria

Accept all is offered only at ≥2 pending; one click applies every resolvable proposal and reports the tally; orphans are skipped (not mangled) and remain pending; the palette command works on the active doc; no console errors.