Pinning the baseline should leave the review panel fully un-annotated #48
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
As a writer, when I pin the baseline, the review panel shows a fully clean,
un-annotated document — no change marks and no authorship coloring — so
pinning reads as "this is my clean starting point."
Problem / pain
Pinning the baseline (
cowriting.pinDiffBaseline/ the F11 preview-toolbar Pinbaseline button) sets the baseline to the current document text, so there are
zero changes since baseline. The change axis correctly goes empty — no
<ins>/<del>/ strikethrough. But the panel is not clean: the F3authorship coloring (green = human, blue = Claude) still paints every
block, because the F10 "on" render (INV-33) author-colors all live text, not
just changed text — an unchanged block renders as
cw-blk cw-unchangedwithcolorByAuthorapplied (src/trackChangesModel.ts,renderReview→renderReviewOp).So immediately after a pin, the writer expects a clean slate and instead sees the
whole document painted green/blue. The panel refreshes correctly on pin
(
onDidChangeBaseline) — this is not a stale render; the persistent author colorsare the annotations. The result undercuts the "pin = clean baseline" mental
model that the pin gesture is supposed to convey.
Who feels it
Writers using the F10/F11 review preview who pin a baseline — the pin button is a
primary preview-toolbar gesture (alongside Ask-Claude, F11), so this is on a
high-traffic surface.
Desired outcome / value
A pin yields a fully clean panel: with no changes since baseline, the "on"
review render shows plain rendered markdown — no change marks and no authorship
coloring. Pinning visibly means "accepted as my clean baseline," reinforcing the
gesture instead of contradicting it.
Acceptance — "done right"
changes since baseline (every block unchanged — the state right after a pin),
the panel renders plain — no
cw-add/cw-del/ strikethrough and noauthorship (green/blue) coloring on any block.
immediately (the existing
onDidChangeBaselinerefresh already fires).added text is still author-colored and struck deletions still show (this issue
does not touch the with-changes render).
actionable
cw-proposal✓/✗ blocks — they are review actions, not "annotations,"and are out of scope for clearing.
renderPlain).Scope / non-goals
in the on render when there are no changes since baseline — the
just-pinned / zero-diff whole-document state.
an unchanged block inside a document that has other changes is left as-is
(that broader INV-33 revision was explicitly not chosen — see Source).
blocks.
Assumptions · constraints · dependencies
diffBlocks(baseline, current)yields all-unchangedops" — the natural place to branch the on-renderto
renderPlain-equivalent output (clean, but keep thedata-srcblock mappingso INV-36 selection→source still works, as
renderPlainalready does).#17/#19,DiffViewController), F10 interactivereview (
#29, INV-32..34,renderReview/renderReviewOp/colorByAuthor), F11preview toolbar (
#43, the Pin-baseline button, INV-35).combined-render behavior is unchanged. A one-line invariant clarification may be
warranted (e.g. "with no changes since baseline the on-render is clean").
Source / signal
Self-originated — capture session vscode-cowriting-plugin-0042 (operator ask:
"When I pin the baseline, there should be no annotations in the review panel").
Scope confirmed in-session: the desired behavior is pin → fully clean panel
(change marks and authorship colors gone in the zero-diff state), not the
broader "authorship never colors unchanged text." Arose while reviewing the
document-edit-flow Solution Design (brainstorming session 0041), which centers the
pin-baseline + review-panel surfaces.
Priority (WSJF)
Value (med — fixes a confusing, expectation-violating result on a primary
toolbar gesture) · Time-criticality (low) · Opportunity-enablement (low) ÷ Size
(small — a single zero-diff branch to clean rendering) → favorable-but-modest.
priority/P2. (Defect-flavored story — surprising behavior, but with aworkaround: toggle annotations off.)
Decomposition
diffBlocksops
unchanged) and render the body clean — no authorship coloring, nochange marks — while preserving the
data-srcblock mapping (INV-36).cw-proposalblocks rendering in that clean state (proposalsare actions, not annotations).
invariant set.
cw-add/cw-del/author-color classes; with a pending proposal → theproposal block still renders.
blue); make an edit → annotations return.
Solution notes (optional — NOT a design)
The narrow shape: in
renderReview, whendiffBlocks(baseline, current)isentirely
unchanged, short-circuit to the same clean per-block outputrenderPlainproduces (bare<div data-src…>+ rendered markdown, nocw-annotation classes), then append any pending
cw-proposalblocks. This reuses theexisting clean-render path rather than special-casing
colorByAuthor, and keepsthe two states (off / on-with-no-changes) visually identical by construction.
Non-binding.
Shipped (#52, session 0046). Pinning the baseline now renders the review panel fully clean — no change marks and no authorship coloring — when there are zero changes since the pin (
reason === "pinned"); a machine-landing-advanced baseline (accept) keeps its coloring so accepted Claude text stays blue (INV-33 preserved). Proposals still show; data-src mapping kept. 218 unit + 74/5 host E2E green. INV-33 clarification written to the F10 spec (content-repo working tree, pending push).