Audit after change

Features that are rarely reached in ordinary use, so a regression goes unnoticed until someone lands on the one page that exercises them. After any change touching the areas named, walk the relevant checklist by hand — the automated coverage is listed where it exists, and its gaps are the point of this page.

Add an entry when you build something that (a) only shows up on unusual data, (b) has a no-script or progressive-enhancement path, or (c) depends on a browser behaviour a unit test cannot see.

---

1. Large-diff windowing (check-in page, /diff, /diff.frag)

Why rare: only a check-in with more than ~3,000 diff lines triggers it. Most check-ins render in one window and the whole mechanism is invisible.

Canonical case: fossil 62b38332f7e0d122dd5d6b19b6a89033ea7612a3d38876972015db876cb34b44 — a 600-file, 216K-line merge.

• Check-in page: /r/fossil/checkin/62b38332…
• Single file, 54K lines: /r/fossil/checkin/62b38332…/diff?file=extsrc%2Fsqlite3.c

Touch points: internal/diff.Window / LastWindow, checkin.diff op (offset, maxLines, file, nextOffset, lastOffset, totalLines), diffWindow() and the diff-body / diff-more / diff-pager templates in internal/web/web.go, the #diff-more sentinel, diffBudget.

Checklist

• [ ] With JS: first window renders; scrolling the ⋯ sentinel into view appends the next window in place (row count grows, a (continued) section appears when a window opens mid-file); repeat to the end; no pager visible; no "continue" link visible.
• [ ] Without JS (DevTools → "Disable JavaScript", reload): no "the rest loads as you scroll" note; pager shown at top and bottom of page 1; Next › goes to ?after=N&prev=M; ‹ Previous returns; « Start and Last » land on the first and final windows.
• [ ] Line readout Lines a–b of T: T is identical on every page of the chain, and on the Last » page b == T.
• [ ] A hand-typed mid-hunk ?after= snaps back to a hunk boundary (readout still sums to T).
• [ ] ?file= with a slash in the path renders that file, not the file list (watch for double-encoding, %252F).
• [ ] ?view=split survives Next/Previous/fragment URLs.
• [ ] Response time: warm page < 300 ms; cold first hit is bounded by zit diff itself (zit#110 tracks path-filtered diffs).

Automated: internal/diff/window_test.go (contiguous chain, snapping, LastWindow agreement). Not automated: the intersect fetch, the <noscript> swap, the attribute name data-on-intersect (the data-on:intersect spelling silently does nothing in Datastar RC.7).

---

2. Changed-file list on very large check-ins

Why rare: same data as §1; lists under ~30 files look fine as a flat list, so a broken grouping only shows at scale.

Planned shape: directory tree with <details> groups collapsed past a threshold, A/M/D summary strip with status filters, multi-column rows inside open groups. When built, add its checklist here: groups collapsed/open by threshold, single-child directory compression, anchors still reach the diff sections (including not-yet-loaded windows), <details> works with scripting off.

---

3. Fleet fragment parity (/fleet.frag, /fleet.rev)

Why rare: the live fragment replaces the server-rendered listing moments after load; a field the fragment omits flashes and vanishes, which is easy to miss and looks like flicker.

Checklist

• [ ] Signed-in admin: "New repository" link, "N of M repositories" count, filter and sort all persist after the first live refresh.
• [ ] Anonymous: no admin-only controls appear at any point.
• [ ] Filter typed with JS on updates the list without a page load; with JS off, Enter submits a GET that lands on the explore view.

Automated: TestFleetFragmentCarriesEverythingThePageDoes.

---

4. Explore vs. personal dashboard routing

Why rare: / is the explore listing for anonymous readers and the personal dashboard for signed-in ones, so links that say / behave differently depending on who clicks them.

Checklist

• [ ] Signed in: explore tabs (repositories ↔ people) and the filter's × clear link stay on ?view=explore, never drop to the dashboard.
• [ ] Anonymous: the same links land on the explore listing.

---

Conventions

• Keep the canonical repro URL for every entry; a feature that is hard to reach needs a shortcut to reach it.
• Prefer adding an automated test and then noting it here; leave the manual checks for what tests cannot see (scroll, no-script, timing).
• When a change makes an entry obsolete, delete it rather than leaving stale steps.