benstull/vscode-cowriting-plugin
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Restore exact author attribution on undo/redo (follow-up to #38) #40

New Issue
Open
opened 2026-06-12 10:38:43 +00:00 by benstull · 3 comments
benstull commented 2026-06-12 10:38:43 +00:00
Owner
Copy Link
Copy Source

Summary

Follow-up to #38. On undo/redo, restore each re-inserted character's exact prior
author attribution, rather than leaving re-inserted text unattributed/neutral
(the #38 fix).

Problem / pain

#38 fixed the wrong-marks bug by treating undo/redo as history navigation, not
authorship: on e.reason === Undo|Redo the span geometry is reconciled but
re-inserted chars get no attribution. That removes the false "human" coloring,
but it's lossy in one direction — undoing a deletion of Claude's text shows it
neutral/unattributed rather than restoring its original agent (blue) span.
Likewise redo of authored text comes back neutral.

Desired outcome / value

After undo/redo, author-coloring reflects the true provenance at that point in
history — Claude's restored text is blue again, the human's is green — so the
preview is fully faithful across history navigation, not just non-misleading.

Acceptance — "done right"

  • Undo of a deletion of agent-authored text restores its agent span (blue), not neutral.
  • Redo re-applies the original author's spans.
  • A sequence of edits + undo + redo yields attribution identical to never having undone.
  • No regression to #38 (no false human attribution) or forward-edit attribution.

Scope / non-goals

In scope: an attribution history mechanism that restores prior spans on undo/redo.
Non-goals: changing forward-edit attribution; the diff/baseline behavior.

Assumptions · constraints · dependencies

  • Builds on #38 (shipped). The hard part is synchronizing an attribution
    history/snapshot stack with VS Code's editor undo stack, which coalesces
    edits (one undo can revert several change events) — a naive per-event snapshot
    stack desyncs. Likely needs reconciliation keyed on the actual contentChanges
    of each undo/redo event, or snapshotting attribution state keyed to document
    versions.

Source / signal

Self-originated — planning-and-executing session vscode-cowriting-plugin-0034
(2026-06-12) while fixing #38; the minimal fix deliberately deferred exact
provenance restoration. Follows #38.

Priority (WSJF)

Value low (the #38 fix already removes the misleading marks; this is fidelity
on undo of cross-author edits) · Time-criticality low · Opportunity low ÷
Size medium (undo-stack sync is fiddly) → priority/P3.

Decomposition

Task. Checklist:

  • Decide the attribution-history mechanism (snapshot stack vs. version-keyed reconciliation).
  • Restore prior spans on undo/redo, staying in sync with editor undo coalescing.
  • Tests: undo of agent-text restores blue; edit→undo→redo round-trips attribution; no #38 regression.
## Summary Follow-up to #38. On undo/redo, restore each re-inserted character's **exact prior author attribution**, rather than leaving re-inserted text **unattributed/neutral** (the #38 fix). ## Problem / pain #38 fixed the wrong-marks bug by treating undo/redo as history navigation, not authorship: on `e.reason === Undo|Redo` the span geometry is reconciled but re-inserted chars get **no** attribution. That removes the false "human" coloring, but it's lossy in one direction — undoing a deletion of **Claude's** text shows it **neutral/unattributed** rather than restoring its original `agent` (blue) span. Likewise redo of authored text comes back neutral. ## Desired outcome / value After undo/redo, author-coloring reflects the **true** provenance at that point in history — Claude's restored text is blue again, the human's is green — so the preview is fully faithful across history navigation, not just non-misleading. ## Acceptance — "done right" - Undo of a deletion of agent-authored text restores its `agent` span (blue), not neutral. - Redo re-applies the original author's spans. - A sequence of edits + undo + redo yields attribution identical to never having undone. - No regression to #38 (no false human attribution) or forward-edit attribution. ## Scope / non-goals **In scope:** an attribution history mechanism that restores prior spans on undo/redo. **Non-goals:** changing forward-edit attribution; the diff/baseline behavior. ## Assumptions · constraints · dependencies - Builds on #38 (shipped). The hard part is synchronizing an attribution history/snapshot stack with VS Code's editor undo stack, which **coalesces** edits (one undo can revert several change events) — a naive per-event snapshot stack desyncs. Likely needs reconciliation keyed on the actual `contentChanges` of each undo/redo event, or snapshotting attribution state keyed to document versions. ## Source / signal Self-originated — planning-and-executing session vscode-cowriting-plugin-0034 (2026-06-12) while fixing #38; the minimal fix deliberately deferred exact provenance restoration. Follows #38. ## Priority (WSJF) Value **low** (the #38 fix already removes the misleading marks; this is fidelity on undo of cross-author edits) · Time-criticality **low** · Opportunity **low** ÷ Size **medium** (undo-stack sync is fiddly) → **priority/P3**. ## Decomposition Task. Checklist: - [ ] Decide the attribution-history mechanism (snapshot stack vs. version-keyed reconciliation). - [ ] Restore prior spans on undo/redo, staying in sync with editor undo coalescing. - [ ] Tests: undo of agent-text restores blue; edit→undo→redo round-trips attribution; no #38 regression.
benstull added the type/taskpriority/P3 labels 2026-06-12 10:38:43 +00:00
benstull commented 2026-06-13 15:57:07 +00:00
Author
Owner
Copy Link
Copy Source

Implemented on branch s40-undo-provenance (session 0048) — NOT merged, verification-blocked. Mechanism: per-doc text-keyed attribution snapshots (Map<documentText, spans>), captured after each forward edit + at load; on undo/redo, after the #38 geometry reconcile, restore the snapshot whose text equals the current buffer (offsets valid, identical text). Robust to VS Code undo coalescing; bounded history; far-back states fall back to #38 neutral. 222 unit + typecheck green.

Blocker: the #40 host E2E (and the pre-existing #38 undoMarks E2E) drive executeCommand("undo"), which is broken in the current local test instance — the untouched #38 test fails identically on clean main (the known undoMarks flake, now deterministic). The usual remedy (clearing .vscode-test/user-data) is permission-blocked in this session. Please verify in a working E2E environment, then merge. Keep open until verified.

Implemented on branch `s40-undo-provenance` (session 0048) — **NOT merged, verification-blocked.** Mechanism: per-doc text-keyed attribution snapshots (`Map<documentText, spans>`), captured after each forward edit + at load; on undo/redo, after the #38 geometry reconcile, restore the snapshot whose text equals the current buffer (offsets valid, identical text). Robust to VS Code undo coalescing; bounded history; far-back states fall back to #38 neutral. 222 unit + typecheck green. **Blocker:** the #40 host E2E (and the pre-existing #38 undoMarks E2E) drive `executeCommand("undo")`, which is broken in the current local test instance — the **untouched #38 test fails identically on clean `main`** (the known undoMarks flake, now deterministic). The usual remedy (clearing `.vscode-test/user-data`) is permission-blocked in this session. Please verify in a working E2E environment, then merge. Keep open until verified.
benstull commented 2026-06-13 16:05:18 +00:00
Author
Owner
Copy Link
Copy Source

Conclusive undo-E2E diagnostic (session 0048). executeCommand("undo") is non-functional in the local .vscode-test harness right now — proven by an isolated probe: open doc, showTextDocument (verified activeTextEditor === doc), delete via editor.edit() (the active editors own undo stack), then executeCommand("undo") → text NOT restored (alpha charlie, deletion stands). So it is not stale user-data (moving it aside to force a fresh one did not help), not the edit mechanism (workspace.applyEdit vs editor.edit — both fail), and not focus. Likely a VS Code-version / headless behavior of the undo command in this harness. This blocks ALL undo-driven E2E (incl. the untouched #38 test, which fails identically on clean main). Recommend: try a different VS Code test version, or trigger undo differently, in a known-good environment — then verify+merge s40-undo-provenance.

**Conclusive undo-E2E diagnostic (session 0048).** `executeCommand("undo")` is non-functional in the local `.vscode-test` harness right now — proven by an isolated probe: open doc, `showTextDocument` (verified `activeTextEditor === doc`), delete via `editor.edit()` (the active editors own undo stack), then `executeCommand("undo")` → text NOT restored (`alpha charlie`, deletion stands). So it is **not** stale user-data (moving it aside to force a fresh one did not help), **not** the edit mechanism (`workspace.applyEdit` vs `editor.edit` — both fail), and **not** focus. Likely a VS Code-version / headless behavior of the `undo` command in this harness. This blocks ALL undo-driven E2E (incl. the untouched #38 test, which fails identically on clean `main`). Recommend: try a different VS Code test version, or trigger undo differently, in a known-good environment — then verify+merge `s40-undo-provenance`.
benstull commented 2026-06-13 16:06:43 +00:00
Author
Owner
Copy Link
Copy Source

Verification blocker now tracked as #54 (host E2E undo non-functional in .vscode-test). #40 (branch s40-undo-provenance) is parked until #54 is resolved.

Verification blocker now tracked as #54 (host E2E `undo` non-functional in `.vscode-test`). #40 (branch `s40-undo-provenance`) is parked until #54 is resolved.
benstull added priority/P1 and removed priority/P3 labels 2026-06-26 20:22:04 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
priority/P0
Priority: highest — drop everything
 priority/P1
Priority: high
 priority/P2
Priority: medium
 priority/P3
Priority: low / someday
 type/bug
A defect in shipped behavior
 type/epic
Type: a large body of work spanning many features
 type/feature
Type: a deliverable capability under an epic
 type/story
Type: a user story — the smallest valuable increment
 type/task
Type: a concrete unit of work under a story
No Label priority/P1 type/task
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
benstull
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: benstull/vscode-cowriting-plugin#40
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?