Four open PRs predate the toolkit migration and the HiDPI stack — merge status, measured

[tannevaled]

All eight open PRs were opened on 13–14 August and are 26 commits behind main (24 for #176). Since then the feed pane and the app chrome were rebuilt on go-widgets (#196, #200), internal/windowgw was deleted (#180), and the HiDPI stack landed (window v0.26.0 → v0.39.0, toolkit → v0.168.0).

Their green checks were run against the old base, so "mergeable" was not evidence of anything. I merged each onto today's main in a scratch worktree and ran the suite. Nothing was pushed and no branch was rewritten.

Safe to merge — verified against current main

PR	result
#166 per-tab lazy loading	merges cleanly, go build, go vet and the whole suite pass
#171 first web page at the pane's real width	merges cleanly, whole suite passes
#168 topbar Refresh button	merges cleanly, whole suite passes — but it adds cov.out, a coverage artefact that should come out before it lands

Need work — conflicts on today's main

PR	what conflicts
#165 deps: window v0.26.0	Obsolete. main is on v0.39.0, and the PR edits internal/windowgw/*, which no longer exists. Its subject — display density following a screen move — shipped in v0.24.2. Suggest closing.
#172 launch at full screen height	same internal/windowgw modify/delete conflict, plus go.sum. The feature is worth keeping; the branch needs redoing on main (the adapter it targets is gone).
#167 wide reading pane 2/3	ui/render.go and ui/preview_view.go, the two files most rewritten by the toolkit migration.
#169 preview keyboard focus	internal/window/run.go, rewritten for the repaint clock and the capability wiring.
#176 media cache mtime	conflicts and its own CI is red on its branch.

Nobody's branch was touched; this is a measurement, not a merge queue.

🤖 Generated with Claude Code

[tannevaled]

Correction, and it cost main twenty minutes of red.

I called #166, #171 and #168 "safe to merge — whole suite passes", merged #166 on that basis, and the race lane went red at once:

--- FAIL: TestViewSubMarksSeen   race detected during execution of test

The new per-tab refresh reached the scene through the mvvm binding on a background goroutine, and App.post ran the write inline instead of marshaling it — the very thing App.DeferSceneWrites exists for, and the reason this repository has a race lane at all.

My verification ran go build, go vet and go test ./.... It did not run -race. A check that skips the lane a defect lives in is not a check; it is a green tick with a hole in it. Reverted in #204, and main was green again ~10 minutes later. (#205 has since fixed the race properly, from the other side.)

Re-measured, with the lane's own command this time

CGO_ENABLED=1 go test -race -timeout 20m <the lane's package list>, each merged onto today's main:

PR	result
#171 first web page at the pane's real width	race lane passes, everything green
#168 topbar Refresh button	race lane passes, everything green — still carries cov.out, which should come out first

Those two now have the verification I claimed for them the first time. The four conflicting ones (#165, #167, #169, #172, #176) are unchanged from the table above.

[tannevaled]

Landed, all three, each verified with the race lane's own command against the main of the moment.

PR
#166 per-tab lazy loading	re-landed in #206 after my revert — the race was the test's, fixed by #205, and production already serialised
#171 first web page at the pane's real width	merged, main green
#168 topbar Refresh button	merged, main green. cov.out removed from the branch first, with .gitignore lines so the next one is caught by the repo rather than by a human

Still open, unchanged, and needing their authors: #165 (obsolete — see the comment there), #167, #169, #172, #176.