Ben Stull
c94b9ccfe7
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>
97 lines
5.4 KiB
Markdown
97 lines
5.4 KiB
Markdown
# 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 0–1 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.
|