Treat an applied patch as a named layer, not an undo blob

[juanmaguitar]

Why

An applied PR remains part of a ticket’s work, but the app described every touched file as the contributor’s own and a failed Revert could blame the PR author. That attribution is misleading and makes the safe exit hard to find.

What changes

The applied patch is retained as a named layer:

• conflict copy says a file includes changes from the named PR and may also contain the contributor’s edits;
• Revert remains available whenever the patch text was retained;
• pressing Revert performs the existing reverse-apply check and reports overlapping edits there;
• a patch too large to retain offers save-a-copy plus discard-to-base;
• the one-patch slot remains occupied until Revert or discard clears it.

Routine site:status no longer reads and diffs patch files synchronously. The proactive “absorbed” classifier/state and categorical “not by you” copy have been removed.

How to test this

Platforms: any.

1. Apply a PR on a linked ticket.
   Expected: its named banner appears with Revert this patch.
2. Preview another patch touching the same file.
   Expected: the warning says the file includes changes from the applied PR and may also contain your edits; it never says “not by you”.
3. Edit a line brought by the applied PR and press Revert this patch.
   Expected: Revert fails without touching anything and explains the overlap, offering save-a-copy/discard rather than asking the author for a rebase.
4. Undo that edit and press Revert again.
   Expected: it succeeds and clears the named layer.

What must not have happened: routine refreshes must not synchronously scan patch files; a failed Revert must not partially edit the tree or free the one-patch slot.

Risks and limitations

The banner does not predict whether a retained patch is still reversible; it answers only when the user requests Revert. This keeps routine main-process status reads cheap and keeps error details attached to the action they explain.

The desktop flow remains to be driven from the integration artifact.

Related

Fixes #306. Part of #309. Builds on #317 and sharpens #313.

---

Design decisions and alternatives considered

The previous version diagnosed every applied layer during site:status, adding synchronous file reads and an “absorbed” state. The simplified version uses the reverse apply operation as the diagnostic only when Revert is pressed.

Review outcome

2 [fix here] — both fixed: synchronous status-path diagnosis was removed, and same-file ownership now preserves uncertainty. Lint is clean and the branch’s full suite passes 979 tests.

Implementation notes

The simplification removed 310 net lines from the reviewed version. Patch text remains in the main process and never crosses IPC.

Screenshots or recording

No new layout. The existing applied-layer and failure banners render the revised copy/actions.

[juanmaguitar]

Rebased onto #313 and retargeted at its branch. Both changes add to describeApplyFailure and to the same call site in the renderer, so as siblings they collided; stacked, each diff stays its own.

The combination needed a decision rather than a mechanical merge, so it is stated here: a failed revert is asked about first, ahead of the pull-request framing. A revert only fails because the contributor's own edits are on the layer's lines, so "this pull request is behind trunk" is never the right sentence for it. The non-revert path keeps #313's ownWorkPaths.

Suite on the combined branches: 984 pass, 0 fail; lint clean.

[juanmaguitar]

Rebased into the stack: #313 → #317 → #318. All three rewrite the same two places — describeApplyFailure and the block above Apply — so as siblings they collided; stacked, each diff stays its own.

Two combinations needed a decision rather than a mechanical merge, and both are in the last commit:

• A failed revert is asked about first, ahead of the pull-request framing. A revert only fails because the contributor's own edits are on the layer's lines, so "this pull request is behind trunk" is never the right sentence for it.
• The notice above Apply is composed, not chosen. Tell the contributor's own edits apart from the patch they applied #306's attribution owns the file list; When a ticket's base is unknown, the app guesses instead of saying so #308's base status says how far that list can be trusted. describePreviewNotice returns both, the renderer only picks a style. The fuller hedge is used where files are named — that a list built against today's trunk can name files you never touched and miss ones you did is the actionable half — and the quiet one stays for the case where nothing collided. describeOwnWorkWarning is superseded by it and removed; its cases moved onto the composed answer rather than going with it.

Suite on the stacked branches: 999 pass, 0 fail; lint clean.

[juanmaguitar]

Final integration review found one ownership mismatch: a second PR failure could call a file the contributor's even when its only known provenance was the previously applied layer. Fixed in d90eb07 by carrying that layer into the failure framing; the regression names the first PR and preserves uncertainty. Full branch suite: 980 passing.

[juanmaguitar]

A further final-review pass found two truthfulness issues and both are fixed in 90d2bad: all-applied changes are now described as already in the checkout when ticket/layer provenance makes trunk unprovable, and a stale Revert record is cleared through writeWorkMeta so the active branch actually loses the banner/slot. Regressions cover both; Node and Electron suites pass.