Give a site's tickets their own card between the ticket and the patch panels

[juanmaguitar]

Why

The Trac ticket card carries four different things once a ticket is linked: which ticket you are
on, the other tickets you have work on in this site, the pull requests that cite the ticket, and its
Trac attachments. Three of those describe the ticket in front of you. The fourth is a list of
everywhere else you could be instead — and switching between tickets is one of the main things a
contributor does on a site, which is the whole point of tickets being cheap. It read as a
sub-section of something else, set in a smaller heading than the card it sat inside.

Closes #240.

What changes

The list of a site's tickets gets a card of its own, at the same level as the Trac ticket card and
the "Apply a patch or PR" card, positioned between them. The reading order now matches what someone
is actually deciding: which ticket am I on, which of my tickets do I want, bring in work from
elsewhere.

This is placement and heading level, not a rewrite of the list. The row markup, the switch links,
"Delete this ticket's work" and its confirm, the ticketActionsBlocked disabling and the ordering
are byte-identical — renderBranchRows moved, it did not change. What is new is one exported
helper, ticketListCard in src/renderer/ticket-branch-list.cjs, holding the two decisions the
card makes: which heading the state calls for, and that no rows means no card rather than an empty
one.

It moves in both states, deliberately. Linked ("Other tickets on this site") and unlinked
("Your tickets on this site") both leave the ticket card. Making it conditional would mean the same
list jumps between two places depending on where you are, and unlinking would move it. The
consequence is accepted: on a site with no ticket linked, the Trac ticket card is left holding
little more than the field to type one into — which is honest, because on that site typing a ticket
number is the only thing there is to do there.

What is deliberately not in this PR: the switch feedback (ticketError, the switch progress
line, the carried/saved notices, and the "what should happen to your loose edits" panel from #234)
still renders in the Trac ticket card, not next to the rows that can now trigger it. See Risks.

How to test this

Platforms: any. Nothing here touches paths, spawning, line endings or signing.

Starting state: a site that is initialized and past the wizard, with work on at least two
tickets. Two runs, one per state.

With a ticket linked

1. Open a site that has a ticket linked and work on at least one other ticket.
   → Three cards in this order: Trac ticket, Other tickets on this site, Apply a patch or
   PR. The tickets card is a card in its own right — same white panel, same border, same
   heading size as the two around it — not a section inside the ticket card.
   → The Trac ticket card now holds only the ticket pill with Open in Trac / Unlink, Linked
   pull requests, and Trac attachments.
2. Click switch on a row.
   → The switch runs exactly as before. Nothing about the row behaviour changed.
3. Start a trunk update (or an install), and while it runs look at the tickets card.
   → Every switch link and every Delete this ticket's work button is disabled, and comes
   back when the operation ends.
4. Click Delete this ticket's work on a row and cancel the confirm.
   → Same confirm wording as before, nothing deleted.

With no ticket linked

5. Open a site with no ticket linked but work on at least one ticket.
   → Trac ticket (heading, one sentence, the input field and Link ticket, the "you will be
   asked what should happen to those edits" line, and the Browse-good-first-bugs link), then
   Your tickets on this site as its own card, then Apply a patch or PR.
6. Click Continue working on #NNNNN.
   → Switches as before. If trunk has uncommitted edits you get the Uncommitted work on trunk is taken into a new ticket without asking, but refused for a ticket that already exists #234 question panel — note it
   renders at the bottom of the Trac ticket card, immediately above the tickets card, not
   inside the card you clicked in.

The empty case

7. Open a site whose only ticket is the one currently linked (or a site with no ticket branches at
   all).
   → No tickets card at all — not a card with a heading and nothing under it. The Trac ticket
   card sits directly above the patch card.

What must not have happened:

• The list must not appear twice — once in the ticket card and once in its own. If you can see
  the same ticket offered in two places, that is the bug this change could most easily have
  introduced.
• The list must not vanish in either state. Unlinking a ticket must keep it on screen, in the
  same card, with only the heading changing from "Other tickets" to "Your tickets".
• An empty card must not be left behind after you delete the last other ticket's work — the
  card should disappear along with the last row, not linger as a heading.
• The switch and delete controls must not become clickable during a long operation. That guard
  moved with them and is easy to lose silently: a switch during an install is a checkout of a
  working directory something else is writing to.

What could not be tested by hand: the #234 question panel appearing above the rows when a
switch is blocked from the new card. I could drive the app and confirm both card layouts, but the
synthetic clicks I used would not fire that link's handler, so the proximity claim in Risks below
is argued from the rendered geometry (measured on the captured screenshots) rather than observed.
Worth a click by a human reviewer.

Risks and limitations

Self-review: 2 [fix here] · 2 [follow-up] — both [fix here] addressed, see the collapsed block.

The one real consequence is that the switch feedback did not move with the controls. ticketError,
the switch progress line, the carried/saved notices and the #234 "what should happen to your loose
edits" panel all still render at the bottom of the Trac ticket card, while the switch and delete
links that set them now live in the card below. Nothing is swallowed — the ticket card is the
immediately preceding sibling in a gap: 24 column, so the panel lands directly above the row you
clicked, about 30px away in the unlinked state. In the linked state proximity actually improves:
the panel used to sit at the bottom of a card that also held Linked pull requests and Trac
attachments, a long scroll from rows near the top; now it is adjacent. Moving the feedback into the
tickets card was rejected because the same panel is also raised by the Link ticket field in the
ticket card above, so it would have to render in two places or be threaded through a shared slot —
a behaviour change, and this issue is explicitly placement only.

Nothing pins where that feedback renders relative to the rows, so if it is later moved next to
them, no test will notice. That is the assertion to add if it moves.

Related

Closes #240. Follow-up to #185, where this list came from — a layout change on top of it, not a
correction to it.

---

Design decisions and alternatives considered

Moving it only in the linked state. Rejected in the issue and not revisited. With a ticket
linked the list is a secondary way to move; with none linked it is the primary way to start, sitting
directly above the field for typing a ticket number. Tempting to leave the unlinked one where it is
for that reason — but then the same list jumps between two cards depending on state, and unlinking
makes it move. A list that stays put is worth more than a list that is optimally placed in each
state separately.

Where the heading choice lives. In ticket-branch-list.cjs, not inline in the JSX. Two
literals in a component of this size drift; the module already owns which rows exist and in what
order, so which heading they sit under belongs with them. The test asserts index.jsx does not
contain either heading string, which is what keeps the two copies from reappearing.

Why ticketListCard returns null rather than the JSX deciding. The "no rows, no card" rule is
the kind of thing that gets lost in a conditional chain. It is a decision, it has a reason (an
empty card is worse than no card — and unlike the card it left, this one has no input field to
justify the space), and decisions with reasons get a test. The JSX guard is then just
skipInit && ticketsCard.

Testing layout with a source scan. There is no DOM harness in this repo, and the whole point of
#240 is where the list renders — untestable through the module's return value alone. So the third
test reads index.jsx as text and asserts the ordering of the three card headings and that
renderBranchRows( is called exactly once. It is not a substitute for looking at the app, and it
is written to fail loudly with a specific message rather than subtly.

Review outcome (required — see AGENTS.md)

2 [fix here] · 2 [follow-up] — both [fix here] resolved.

Run per .github/instructions/code-review.instructions.md, with the judgement pass dispatched to a
subagent that had the diff and the instructions file and nothing from the session that wrote the
code.

Fixed:

1. tests — the layout test asserted the inline style literal fontSize: 16 to pin the heading
   level. fontSize: 16 is repeated verbatim on all three card headings, so extracting them into a
   shared constant — an obvious, harmless cleanup — would have failed the test with the layout
   unchanged. Assertion dropped; the ordering assertion above it already covers the finding it was
   aimed at.
2. tests — the "renders once" assertion counted the bare string renderBranchRows, which
   includes occurrences in comments, so a documentation edit naming the helper would have turned the
   suite red. Now counts renderBranchRows( calls and expects exactly one.

Deferred, with reasons:

3. architecture — the switch feedback stayed in the Trac ticket card while its controls moved.
   Written up in Risks and limitations rather than fixed: the fix is a behaviour change (the
   same panel is raised from two places), and A site's tickets deserve their own card, not a sub-heading inside the ticket you are on #240 is explicitly placement only. The reviewer asked
   for a by-hand confirmation that the panel is still visible when a switch is blocked; I could not
   fire that handler under synthetic clicks, so it is called out as untested above.
4. tests — nothing pins where that feedback renders relative to the rows. Deferred with 3: the
   assertion to add is the one that would fail when the feedback moves, and it should be written
   then, not now against the state it is not yet in.

Checked and clean: no double or zero render (one renderBranchRows definition, one call site,
Boolean(tracTicket) reproducing the old linked argument in both states); ticketActionsBlocked
still closed over from the same component; the empty-list guard; skipInit gating matching the two
neighbouring cards exactly. Security, performance and cross-platform are out of scope — no IPC, no
spawn, no path handling, no dependency, no electron-store shape change.

Implementation notes

Three files.

• src/renderer/ticket-branch-list.cjs — adds ticketListCard({ rowCount, linked }), returning
  { heading } or null. Pure and dependency-free like the rest of the module, so node --test
  requires it directly.
• src/renderer/index.jsx — deletes the two mutually exclusive sections (the linked one at the top
  of the ticket card, the unlinked one above the Link ticket field) and adds one card between the
  ticket card and the patch card, gated on skipInit && ticketsCard. renderBranchRows itself is
  untouched.
• test/ticket-branch-list.test.cjs — three tests, all of which fail against the pre-change source.
  Proved by checking out the branch point into a detached worktree, copying the new test file in,
  and running it there: 3 failed, 15 passed. On the branch: 18 passed.

npm test 754/754 on Node 24.18.0 (.nvmrc) and 754/754 on Electron's bundled Node via
npm run test:electron, both re-run after the rebase onto #241. npm run lint clean.

Screenshots or recording

With a ticket linked — "Other tickets on this site" as its own card between the Trac ticket
card and the patch card:

(screenshot: ticket-linked)

With no ticket linked — "Your tickets on this site" as its own card; the Trac ticket card is
left with the field to type one into:

(screenshot: no-ticket-linked)