Colour a linked pull request by its state, in GitHub's own colours

[juanmaguitar]

Why

A linked pull request's state renders as grey text, the same size and weight as the date beside it
and separated from it by a middle dot: closed · updated 08/08/2026. The one word that says what
happened to the work reads as part of the timestamp, so the panel answers "when was this touched"
loudly and "did this go anywhere" in a whisper.

Part of #227 — its "make the outcome legible" half.

What changes

The state gets the pill the "Latest" marker already uses, in GitHub's own three colours: green for
open, purple for merged, red for closed. Same shape, same size, same radius — only the word and the
colours differ, so the row keeps one visual vocabulary.

Merged is a third state the parser used to throw away. GitHub's state field only ever says open or
closed; a merge is visible solely in pull_request.merged_at, which the search/issues response the
app already fetches carries. Keeping the distinction therefore costs no extra request against the
shared unauthenticated 60/hour that src/patch-sources.cjs is careful with.

Three constraints the design is built under, all three load-bearing:

• The colour accompanies the word, it never replaces it. A bare coloured dot would tell a
  contributor who cannot separate red from green less than the plain text it replaced.
• The closed pill must not read as an error. Red means "something failed" everywhere else in this
  window — a half-done update, an error banner. A closed pull request is not a failure. So the pill
  wears GitHub's red (#ffebe9 / #82071e) rather than this app's error pair (#fcf0f1 on a
  #d63638 border), and it is a borderless pill rather than the bordered, alert-shaped box the
  errors use.
• No copy is added. The pill says open, merged or closed and nothing else.

The mapping lives in a new src/renderer/pr-state.cjs with its own test, per the renderer invariant
in the review standard; index.jsx is left holding the JSX and the call.

Deliberately not in this PR: anything about what a state means. This does not close #227 — its
other half, telling a pull request whose work landed from one that was abandoned, needs the ticket's
own state and is not solved by colour.

How to test this

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

Starting state: any initialized site, past the wizard. Needs network — the list comes from
GitHub's search API.

1. In Trac ticket, type 29798 and click Link ticket. (Chosen because it has one open and
   one closed linked pull request; any ticket with linked PRs works.)
   → Under Linked pull requests, #12943 shows a red CLOSED pill and #8913 a green OPEN
   pill, each on the line under the title, with updated <date> in grey beside it.
2. Read the two pills next to the error styling elsewhere in the app — e.g. trigger any error
   banner, or compare against the yellow rate-limit notice on the same card.
   → The CLOSED pill is visibly a label, not a warning: no border, no icon, a softer red than the
   bordered #d63638 alert boxes.
3. Turn off the network and click Refresh.
   → The cached list still renders, still with its pills. A row whose state the cache does not
   recognise renders as OPEN, which is what the row has always done — never blank, never
   unlabelled.

The merged/purple case cannot be reached against wordpress-develop. A repository-wide search
returns zero merged pull requests ever, against roughly ten thousand closed — pull requests there are
opened for review and the change lands as a commit. To see it, force it locally: in
src/patch-sources.cjs, make prState return 'merged' for a closed item, restart, and the row
shows the purple MERGED pill. It is covered by unit tests either way.

What must not have happened:

• The word must never disappear. Colour is added to the label, not substituted for it — a pill with
  a colour and no text is the regression to watch for.
• The list itself must not change: same pull requests, same order (newest first), same "Latest"
  marker, same Apply… behaviour. Only the state's rendering moved.
• No second GitHub request. The rate-limit budget is unchanged; merged_at comes from the response
  already being parsed.

Risks and limitations

• Presentation only. It does not close A ticket's pull request list says "closed" for work that landed in core and work that was abandoned #227.
• The purple/merged branch is real in the API and correct to implement, but it will essentially never
  render for wordpress-develop (see above). It is unit-tested rather than screenshotted from the real
  repo.
• After a GitHub failure the row falls back to the cached list, so a pull request merged since the
  last successful fetch keeps its old pill until the next successful lookup. The cache is already
  labelled "showing what was last seen …", so this is visible rather than silent.
• Self-review: 0 [fix here] · 1 [follow-up], deferred with a reason below.

Related

Part of #227. Stacked on #242.

---

Design decisions and alternatives considered

Why a pill and not coloured text. Coloured text at 11px next to a grey date is a contrast
problem before it is a legibility win, and it keeps the state looking like part of the timestamp
sentence. The pill separates the two: a label and a date, not one run of small print. latestPill
already established the shape in this exact row, so following it was cheaper than inventing one — the
two now share a pillStyle object rather than two copies of the same eight properties.

Why GitHub's colours and not the app's palette. The contributor's next click on that row is
through to GitHub, where the same three states are painted the same three ways. Borrowing an
in-house green would mean the same fact wears two different colours a second apart.

Why red for closed, given red means failure here. The alternative was grey — but grey is what the
state looks like today, and it collapses closed and merged into "not open", which is exactly the
distinction the parser change exists to keep. GitHub's red is a different red from this app's error
red, and the pill shape carries no alert affordance: no border, no icon, no role="alert". A test
pins the two apart.

Why merged rather than a boolean merged flag on the closed state. Three states is what the UI
renders and what GitHub itself models. A {state, merged} pair would push the same three-way
decision into every consumer.

Unknown states read as open. prStateBadge falls back to the open styling for anything it does
not recognise — a list cached by an older build carries only open/closed, and "not closed reads
as open" is the contract the row has always had. Failing to a blank or dropped label would be worse
than failing to the old behaviour.

Review outcome (required — see AGENTS.md)

/self-review (the procedure in .github/instructions/code-review.instructions.md, judgement pass
in a fresh context): 0 [fix here] · 1 [follow-up] — deferred.

Deterministic layer clean: npm run lint clean, npm test 762/762 on .nvmrc's Node 24.18.0,
npm run test:electron 762/762 on Electron's bundled Node.

The follow-up, tests · 🔵 low, on test/pr-state.test.cjs: two assertions read index.jsx's
source text rather than behaviour, so an unrelated change could turn this file red —
assert.ok(source.includes('#fcf0f1')) couples it to the error-banner background, and the
exactly-one-prStatePill(-call-site count would fail if a second, legitimate call site were added.

Deferred, consciously:

• The call-site count is the house pattern, adopted one commit ago in test/ticket-branch-list.test.cjs
  for the same reason — counting calls rather than bare names so a comment naming the helper is not a
  red suite. Departing from it here would leave two conventions.
• The #fcf0f1 assertion is a deliberate canary with its failure message written for exactly this
  case ("the error banner background moved; this test no longer compares against the real one").
  Without it, the "closed is not the error styling" comparison rots silently the day the banner is
  restyled — which is the more expensive failure of the two.

Both are cheap to revisit if the second call site or the restyle actually arrives.

Implementation notes

src/patch-sources.cjs — parseLinkedPrs calls a new prState(item): merged when
pull_request.merged_at is set, else closed/open from item.state. The pull_request guard the
function already had (it is what tells a PR from an issue in a search/issues response) means the
property access cannot throw on an issue item. merged_at presence in this response was verified
against the live API.

src/renderer/pr-state.cjs — new: PR_STATE_BADGES (label + background + colour per state) and
prStateBadge(state), case-insensitive with the open fallback. No React, no DOM; testable.

src/renderer/index.jsx — pillStyle extracted from latestPill; new prStatePill(state) beside
it; the PR row's second line becomes a flex row of pill + updated <date> instead of a single
dot-joined string.

Tests: test/patch-sources.test.cjs gains the merged/closed-unmerged/open trio;
test/pr-state.test.cjs is new. Both halves were verified to fail without the source change —
parseLinkedPrs: a merged PR is merged, not closed fails on the old parser, and
the row renders the state through the pill fails on the old index.jsx.

No new dependency, no IPC surface, no persistence-shape change, no platform-split code.

Screenshots or recording

Ticket #29798 on a real site, which has one closed and one open linked pull request.

Before — the state is grey 11px text, dot-joined to the date:

#12943 … / closed · updated 08/08/2026
#8913 … / open · updated 06/07/2026

After — a red CLOSED pill and a green OPEN pill, each followed by updated <date> in grey.

Merged, staged locally by forcing prState to return 'merged' (wordpress-develop has no merged
pull requests to screenshot): the same row with a purple MERGED pill.