Show the unsubmitted-changes note for a ticket's own parked work

[juanmaguitar]

Why

The card's unsubmitted-changes note never appears for the work its own sentence describes. Link a
ticket, make a change, switch to another ticket, come back — the card says nothing, while the patch
modal shows the change exactly as it was left. For anyone using more than one ticket, that is all of
their work.

Observed on a real site, and the two readings disagree on disk:

git status                  ->  empty
git diff <baseOid>..HEAD    ->  src/wp-login.php, +3 lines

Both answers are correct. They answer different questions, and only one of them is the question a
contributor is asking. #239 has the reasoning.

What changes

Root cause. The note measured the worktree against HEAD. Under the ticket-as-branch model
(#108) a ticket parks its work in a WIP commit, so HEAD-relative is correctly "clean" for every
change that has survived a ticket switch — which is the work the note exists to speak about.
changes-note.cjs was written before tickets were branches, when "not written down" and "not
submitted" described the same edits. Splitting them is what opened the gap.

The fix is to make the note ask the patch's question, measured from the ticket's branch point
rather than from the last time anything was written down. That is the measurement
createMinimalPatchForDir already makes, so this is the two agreeing rather than a third answer
being invented.

Which reader wants which question — the part worth reviewing:

Reader	Question	Why
The card's note	wide — git:unsubmitted-work, from the branch point	Parked work is unsubmitted work. It is the whole subject of the sentence.
startTrunkUpdate's dirty dialog	narrow — git:worktree-dirty	It protects what a force checkout would overwrite. Parked work survives one; uncommitted edits do not.
The dirty-trunk switch refusal (sites:set-ticket)	narrow — countChangesAgainst	Same thing: it is about edits on trunk that have nowhere to go. Trunk is never committed to, so there is no parked work there to see.
git:preview-patch's collision scan	narrow — collectDirtyFiles	It lists the files an incoming patch would collide with in the working tree.

So the narrow signal is untouched and keeps its channel; the wide one is a new channel beside it,
and only the note reads it. Nothing was widened underneath a caller that did not ask for it.

Two consequences that are not obvious from that summary:

• A discard now reports what it left behind. On a ticket branch a discard rewinds to the last
  park — the WIP commit is not its to take, since destroying a ticket is what deleting its branch is
  for. The old code asserted "clean" locally after a discard, which would now hide the note over work
  that is still there. git:discard-changes replies with a recount and the card renders that.
• A branch change re-takes the measurement. A branch-point count is about a particular branch,
  so a stale one is not an old version of the new answer — it is about different work. Linking,
  unlinking, resuming and deleting a ticket now invalidate the note and walk again. This was a
  self-review finding, not part of the original design; see the review block.

Deliberately not in this PR: the note's wording is unchanged (it was already right — the
reassurance about unlinking is about work that outlives a link, which is exactly the parked work it
could not see), and #236's applied-patch record is untouched.

How to test this

Platforms: any. The change is git-graph logic through isomorphic-git, with no path, spawn or
line-ending surface. Buildkite has signed artifacts for this branch — check the build matches the
head commit.

Starting state: a site set up and built, with no ticket linked and a clean tree.

1. Link ticket 12345. Edit src/wp-login.php — add a comment line. Return focus to the app.
   → The ticket card reads "You have 1 unsubmitted change for ticket #12345."
2. Link ticket 54321 (a ticket this site has not worked on). The switch parks #12345's work.
   → The card names #54321 and shows no changes note. It must not say "1 unsubmitted change
   for ticket #54321" — that is the stale-count bug the second commit fixes, and it is the one thing
   here you have to be looking for to see.
3. Link 12345 again.
   → This is the bug. Before this PR the card is silent. Now it reads "You have 1 unsubmitted
   change for ticket #12345", with review and submit and discard your changes.
4. Click review and submit. → The modal's diff shows the same single change to wp-login.php.
   The note and the modal now agree, which is the whole point.
5. Close the modal and click discard your changes, confirm.
   → The note goes away and the tree is clean.
6. Make two edits on #12345. Switch to #54321 and back, then click discard your changes.
   → The note goes away. Nothing is left claiming changes that are gone.

Then the narrow readers, which must be unchanged:

7. On trunk, with an uncommitted edit, click Update to latest trunk.
   → The dirty-tree dialog still appears and lists the file.
8. On trunk with an uncommitted edit, link a ticket.
   → The "decide what happens to it" panel from Ask what should happen to loose trunk work before a ticket takes or refuses it #238 still appears, with the same three options.
   (This one shares the area with Ask what should happen to loose trunk work before a ticket takes or refuses it #238 — worth a look for that reason as much as this one.)
9. Delete a different ticket's work from the switcher while on #12345.
   → The note for #12345 stays on screen and does not blink out and back. Deleting the ticket you are
   on does clear it.

What must not have happened:

• No work discarded. Step 3 is the load-bearing one: the parked change must still be there and
  must still be the only thing in the patch. If the note appears but the patch is empty, or the patch
  gained files from another ticket, the base being diffed against is wrong.
• The note must not outlive its branch. A count from the ticket you just left, rendered under the
  number of the ticket you just arrived at, is the failure mode of this design — with a live
  discard your changes link under it. Steps 2 and 9 are what catch it.
• node_modules must not be rebuilt by any switch here.
• The trunk-update and ticket-switch guards must not have loosened. If step 7 or 8 stops asking,
  the narrow signal was widened and a force checkout can now land on uncommitted edits.

Which tests cover it, and the check that they fail without the fix: the 10 new tests in
test/ipc-wiring.test.cjs and test/changes-note.test.cjs. Verified by resetting src/ to the
stack base with the tests held at their new state — all 10 fail, 124 pass. The end-to-end one is
git:unsubmitted-work sees the parked ticket work a clean status hides (#239), which builds a real
repository in the parked state and asserts both readings on the same tree: git:worktree-dirty
clean, git:unsubmitted-work dirty.

What could not be tested by hand: nothing in this change; every path above is reachable in the
app. What is not covered by the suite is the wiring in index.jsx — reprobeAfterBranchChange
being called from the right places is a call, not a branch, so it is verified by steps 2 and 9 rather
than by a test (see Risks).

Risks and limitations

Review outcome: 5 [fix here] · 1 [follow-up] — all 5 fixed, 1 deferred. Two passes; the first
found a bug this PR introduced. Detail in the collapsed block.

• The focus probe costs more than it did. collectChangedFiles reads both sides of every changed
  row into buffers and decodes them, where collectDirtyFiles read a blob only for CRLF candidates —
  and the note probes on every window focus. statusMatrix still dominates, and the changed-row count
  is small for a normal ticket, so no user-visible path was identified. Deferred rather than fixed:
  the cheap version needs the buffers only up to the line-ending comparison, which is a change to the
  shared classifier and belongs on its own. Follow-up issue not yet filed — happy to file it.
• index.jsx wiring is not test-covered. The re-probe calls live in the component, which the
  suite cannot load. The decisions are all in changes-note.cjs with tests, per the repo
  invariant; what is untested is that they are called from the right four places. Steps 2 and 9 of
  the manual test are what stand in for that.
• branches:delete gained a reply field (movedToTrunk). Additive, and no stored shape changed,
  so there is no migration.
• This PR sits on Ask what should happen to loose trunk work before a ticket takes or refuses it #238, which touches the same handlers. Rebased onto its current tip (0c9902c)
  rather than merged, so the stack keeps one shape.

Related

Closes #239.
Sits on #238 (base branch), the tip of #168 → #185 → #198 → #205 → #218 → #238.
Related: #234 (the other decision that hangs on this reading of "changes"), #236 (the same shape
again — one thing moved to a branch, another stayed behind), #108 (the ticket-as-branch model that
split the two questions apart).

---

Design decisions and alternatives considered

Rejected: widen git:worktree-dirty so everyone gets the branch-point answer. The smallest diff
and the wrong one. It would have made the trunk-update dialog offer to save and discard parked
work, and made the dirty-trunk refusal fire for a ticket that has nothing loose in its tree at all
— a switch refused over work that is already safely committed. The issue calls this out directly, and
it is the finding I most expected to have to defend, so: two questions, two channels, and a table in
"What changes" saying which caller asks which.

Rejected: derive the note's count in the renderer from the patch text. The modal already fetches
a diff; counting its +++ lines would have needed no new channel. But it means generating and
transferring the full patch on every window focus to answer a yes/no, and it makes the note's truth
depend on the patch renderer rather than on the walk. The count and the diff should be two readings
of one walk, not one derived from the other's output.

Why the classifier was extracted rather than the count re-derived. collectUnsubmittedFiles
could have filtered on its own rules — "skip binaries, skip line-ending-only churn". It would have
drifted from the patch's rules within one change to either. classifyChangedFile now holds that
decision once and both read it, which is what makes "the note and the modal never disagree" a
property of the code rather than a promise. It also decides the count: a binary change counts,
because the patch names it above the diff and the contributor has to hear about it, while a
CRLF-only difference does not, because nothing would be in the patch.

Why a discard reports a recount instead of the renderer re-probing. It could have called
refreshDirty() after the discard. The reply is better: it is one walk instead of two, it cannot
race the probe already in flight, and it makes "what survived this" a fact the main process states
rather than something the renderer infers from a second question. The recount is non-fatal — if it
throws, the discard still succeeded and the reply just says less.

branches:delete gained movedToTrunk rather than the renderer inferring it. current reports
trunk both when the delete took the checkout with it and when the delete was simply made from
trunk. The renderer cannot tell those apart, and it now re-walks the tree on this answer, so main
states the fact instead. Pinned by a test that asserts current is trunk on a path where
movedToTrunk is false — the exact ambiguity that made the field necessary.

Review outcome (required — see AGENTS.md)

5 [fix here] · 1 [follow-up] — all 5 fixed, the follow-up deferred with a reason.

Run per .claude/skills/self-review, dispatching the judgement pass to a subagent with the diff and
.github/instructions/code-review.instructions.md and nothing else from the authoring session. Run
twice: the first pass found a bug the fix itself introduced, so the second pass reviewed the
corrections. Deterministic layer clean throughout — npm run lint passes, and the suite is green on
.nvmrc's Node (24.18.0) and on Electron's bundled Node.

First pass — 2 [fix here] · 1 [follow-up]:

1. 🟡 architecture, index.jsx — the note was never re-taken when the branch changed. Introduced
   by this PR: with a HEAD-relative probe the post-switch answer was always "clean" and a stale
   value was harmless; a branch-point measurement changes with the branch. So resuming a ticket
   showed the previous ticket's count next to the new ticket's number, with a working discard
   link, until the window lost focus. Fixed — reprobeAfterBranchChange on every path that moves
   the checkout, clearing the note while the new walk runs so no wrong sentence is ever rendered. The
   probe's inFlight guard also silently dropped a request made mid-walk, which was safe only while
   the answer could not change without the window losing focus; it now queues and re-runs.
2. 🔵 architecture, index.jsx — an inline second answer to a question the module already
   answered. noteAfterDiscard decided "does this reply carry a recount" inline, slightly
   differently from discardOutcome, and its three call sites disagreed about whether they passed a
   raw reply or a normalised one. Exactly the shape of "Show in Explorer" and "Open in editor" fail with "unknown error" while a new site is still being set up #180, and against the §1 invariant. Fixed —
   the decision is noteAfterDiscard in changes-note.cjs with its own tests; the component holds
   a state assignment and a call.
3. 🔵 performance, main.js — the focus probe reads and decodes more than it used to.
   Deferred, see Risks.

Second pass — findings 1 and 2 confirmed resolved; 2 new [fix here], both 🔵, both fixed:

4. architecture — deleteTicketWork re-walked unconditionally. Deleting a ticket you are not on
   does not move the checkout, so the note blanked and rebuilt the identical sentence, paying a full
   walk for a tree that never changed; and the walk was started before loadStatus(), so a fast
   answer could render trunk's count under the ticket number the delete had just cleared. Fixed —
   movedToTrunk (new, tested) gates it, and it runs after the status reload.
5. architecture — the discard behind "discard them and start clean" dropped its recount. Harmless
   on the happy path, since the switch that follows re-walks; but a switch that fails returns
   without re-probing, leaving the note offering to discard trunk work that was already gone —
   finding 1's shape on a narrower path. Fixed.

The second pass also verified the parts most likely to be wrong and found them sound: the do/while
probe queue cannot spin or leak inFlight (the only await is inside the inner try, and no await
separates the loop test from the finally), the useCallback dependency arrays are complete,
setWorktreeDirty(null) is safe for its single reader, and classifyChangedFile preserves the
original precedence exactly so patch output is byte-identical.

Implementation notes

• src/main.js — classifyChangedFile extracted from createMinimalPatchForDir, preserving its
  precedence (unreadable workdir → unreadable base → binary → line-ending-equal → text) so the patch
  is unchanged. collectUnsubmittedFiles runs patchBaseOid + collectChangedFiles and keeps
  everything the patch would speak about. New git:unsubmitted-work handler beside
  git:worktree-dirty, same reply shape. git:discard-changes appends the recount.
• src/preload.js — hasUnsubmittedWork, a named bridge function; the surface is not widened.
• src/renderer/changes-note.cjs — discardOutcome passes a recount through when there is one;
  new noteAfterDiscard decides the post-discard card state, falling back to clean when a reply
  carries no recount (what the old markTreeClean asserted unconditionally).
• src/renderer/index.jsx — the probe reads the new channel; markTreeClean becomes
  applyDiscardToNote; reprobeAfterBranchChange added and called from saveTicket (which every
  link, unlink, resume and carry funnels through) and deleteTicketWork.
• On trunk patchBaseOid returns null and the walk falls back to HEAD, so a site that never
  linked a ticket gets exactly the answer it always got. Pinned by
  git:unsubmitted-work matches git:worktree-dirty on trunk (#239).