@aiquants/daily-report 0.43.0 → 0.44.0

package/CHANGELOG.md

@@ -2,6 +2,173 @@
 
 All notable changes to `@aiquants/daily-report` are documented here.
 
+## Unreleased
+
+### Added
+
+- **テストの入口 `@aiquants/daily-report/testing`**: `createDailyReportTestInstrumentation()` を、ホストのテストのビルドがクライアントの入口の
+  `DailyReportInstrumentationContext` (既定は null) で画面の周りに配る。計測されたビューだけが試験の口 (`__virtualScroll`) を載せ、行の 2 段目の描画の出来事を数える
+  (`rowPass.counters()` の 6 つの数: 同期の描画 `syncReleases`・待たせた見える単位 `deferredVisible`・分け前を超えたフレーム `oversizeFrames`・飛ばした遅れたフレーム
+  `lateFrames`・遅れても当てはめたフレーム `lateForcedFrames`・単位のフレーム `unitFrames`。`rowPass.unitKinds()` は単位の種類ごとの最新の p50・p90・予算 (判定の上限:
+  表示のフレームの間隔を速い表示では 60 Hz の間隔で下から押さえ、2 ms を引いた時間))。
+  見積もりの動かしの数 (`estimate.counters()`: `reEstimates` とそのうちビューが動いていたもの `reEstimatesInMotion`) も読める。本番のビルドは何も配らないので、試験の口と数の
+  コードはクライアントの束に入らない (`dist/testing.mjs`。gzip で 1,713 B)。型は testing の入口から読む (`DailyReportViewTestHandle`・`DailyReportViewTestReadHandle`・
+  `DailyReportRowPassCounters`・`DailyReportRowPassKindReading`・`DailyReportReEstimateCounters`・送り手の出来事 `DailyReportRowPassEvent` と
+  `DailyReportRowPassUnitFrameEvent`・`DailyReportRowPassUnitKind`・`DailyReportRowBoxSizing`・`DailyReportRowUnitChange`)。計測を差し込む文脈の型はクライアントの入口
+  (`DailyReportInstrumentation`・`DailyReportInstrumentedView`・`DailyReportViewInstrumentation`)。下の Breaking。
+- **行の 2 段目の描画の出来事** (`DailyReportRowPassEvent`): 判定を読むための押し続けの始まり (`hold-start`: そのときのフレームの間隔と、送り手がその keydown の中で聞く
+  フレームを求めたか `listening`。測る箱の行を持つビュー (DetailList) だけが真になりうる)・キーのフレームの証拠の標本 (`key-frame`: フレームの時刻・標本・p50・標本の数・
+  間隔・p50 を比べる上限 `limit`)・押し続けの終わり (`hold-end`) が加わり、単位のフレーム (`unit-frame`) はフレームの時刻 (`frameTime`) と当てはめた行の日報 id (`rows`) を、
+  飛ばした遅れたフレーム (`late-frame`) と遅れても当てはめたフレーム (`late-forced-frame`) もフレームの時刻 (`frameTime`。ウィンドウの時計の ms) を持つ。計測は出来事を
+  知らせた時刻でなくフレームの時刻でフレームと照らし、遅れて飛ばしたフレームと単位の無いフレームを見分ける。単位のフレームの予算 (`budget`) は判定の上限。
+- **選択の段階の型 `DailyReportSelectionPhase`** (client エントリ。`"held"` / `"settled"`): ビューの `onSelectItem(id, phase)` の 2 つ目の引数 (下の Changed)。
+- **ID でまとめた詳細の答えの型** `DailyReportSearchDetailsAnswer` (`{ outcomes }`) と `DailyReportSearchDetailOutcome` (共有の入口。下の Breaking)。
+
+### Changed
+
+- **押し続けのキーはホストもビューも描き直さない**: 画面の選択のストアは最新の選択 (`get`) と落ち着いた選択 (`getSettled`) を分け、書き込みは段階を必ず持つ
+  (`set(id, phase)`)。長押しの流れの中のキー 1 つの選択は `held` で、最新の値だけを変えて誰にも知らせず、ビューはキーの移動の数と選択の見当を流れの終わりまで
+  確定しない。流れの終わりに最後の選択を `settled` で 1 回だけ発行し、ホストとビューは 1 つの `flushSync` で 1 つの揃った状態を確定する (流れの最後のキーが揃えた行は
+  揃え直さない)。ビューの `onSelectItem` は押し続けのキーごとに `(id, "held")`、流れの終わりとほかのどの選択で `(id, "settled")` で呼ばれる (`settled` だけを描くホストは
+  押し続けの間に描き直さない。どの呼び出しも描くホストも、今までどおり動く)。押し続けのキー 1 つの確定は、DetailList も List もホスト 0・ビュー 0・`VirtualScroll` 1・
+  変わった行の枠 2 つで、キーを離した確定はホスト 1・ビュー 1。1 回の押下は長さ 1 の流れで、今までどおり 1 回で確定する。
+- **行の操作部品の Tab 順は登録が書く**: アクティブな行が動いても操作部品の葉 (★・既読・編集・削除・添付の繋がり・コメントの欄) を描き直さず、ビューの登録
+  (`createRowControlRegistry`) が前と新しいアクティブな行の操作部品の `tabindex` だけを書く。部品は `useRowControl()` の `{ tabIndex, ref }` を広げ、マウントの時点の
+  値 (サーバーの描画ではスナップショットの値) で描き、後からマウントした操作部品 (本体・編集の形・届いたコメント) も今の状態で入る。描くマークアップは変わらない。
+- **遅い端末の押し続けは、フレームを超える行を名前の付いた殻で入れる** (DetailList): 送り手は装置の定数を持たず、測ったものから判定する。単位の種類の測った p50 が
+  判定の上限 (表示のフレームの間隔から 2 ms を引いた時間。60 Hz より速い表示では間隔を 60 Hz の 16.67 ms として読むので、60・120・144 Hz のどの表示でも 14.67 ms) を超えるか、
+  押し続けの間に DetailList のカードについて、押し続けのキーのフレームの重さの中央値 (3 件から。知らせの busy か、上限を超えて vsync を逃したフレームの拍子の差。送り手が
+  眠った後のフレームの遅れた知らせは数えない) が超えると、その押し続けの間に見える範囲へ入る行は名前の付いた殻のまま入り (送り手は描かずに眠る)、キーを離すと
+  アクティブな行のカードから、見えている殻を見える順に描く。名前の付いた殻はカードと同じ名前と、カードの説明のうち描画に依らない部分 (状態の文・件数付きの添付の目印・
+  種別のバッジの文・List のプレビュー・当たったキーワードの数の文) を画面に出さずに持つので、アクティブな行の読み上げは押し続けの間もカードと同じ (当たりを描いた欄の文と
+  表示外の文はカードと一緒に加わる)。表示のフレームの間隔は押し出されなかったフレームの差だけから測るので、4x の装置でも 33.3 ms ではなく 16.67 ms のまま。判定が付く前の
+  DetailList の押し続けは、押し続けの始まりの keydown の中で 1 つだけ素で求める聞くフレームから測る (その keydown の中では単位を当てはめず、DOM へ書かず、時計も読まない)。
+  決まった箱の行だけの List は押し続けを聞かない (キーのフレームの証拠が判定するのは測る行だけなので、押し続けの間も走れる単位が無ければ眠る)。
+  1x では 60・120・144 Hz のどの表示でもどの種類も超えないので、どの行も今までどおり入る確定でカードと印まで描く。List の行は 4x でもフレームに収まるので、List は変わらない。
+  - 性能の試験 (CPU を押し続けの直前に 4 倍遅くした DetailList の 40 回のキーの押し続け、3 回): 押し続けは 6・7・7 回目のキーで判定し、キーの確定の中で描いた本体は 0
+    (0.43.0 は 22・24・25)、名前の付いた殻で入った行は 26・23・26、次のフレームまでの p95 は 45.1・33.4・27.4 ms (中央値 33.4。0.43.0 は 108.6 ms) で、目標の 33 ms
+    には届かない (下の Known issues)。読み込みから 4 倍遅い装置も、押し続けの前に描いた行の先の最初の行が入る 16 回目のキーで判定する。
+- **行の高さの見積もりを測った高さから導く** (DetailList): 測っていない行の高さは、ビューが測った行の高さの中央値を 8 px の倍数へ切り上げた見積もり (1 つも測っていない間は
+  440 px) で並べる (0.43.0 は 352 px の決めた値で、測ったどの行より低かった)。見積もりは `@aiquants/virtualscroll` 3.18.0 の `estimatedItemHeight` と
+  `setItemHeightEstimate` で渡し、キーの押し続けもスクロールも無いときにだけ当て直す (先頭に見えている日報はその場に留まる)。当て直しは測っていない行だけを動かす:
+  VirtualScroll はどの行も `getItemHeight` で読み直すので、測った高さが前の見積もりとちょうど同じ行も、描画の窓の外の測った行も自分の高さを保つ。測り終えるまでの
+  DetailList のスクロールバーのつまみの大きさと位置は、見積もりの分だけ 0.43.0 と違う。
+- **速いホイールの間は、ペインの進む先の行から描く**: アクティブな行が描く範囲の外に留め置かれているか無い間は、行の 2 段目の描画が行をペインの進む向きの前から、見える範囲の
+  端からの距離の順に並べ、ペインが動く間は進む先のビューポート 1 つ分の行を、遅れたフレームでも見える範囲へ入る前に描く。React の開発版のビルドで DetailList を 20,000 px
+  送って同じ量で戻す素のホイールは、0.43.0 の 644〜1,116 px から 156〜548 px のずれになった (List は始めの位置へ戻る。下の Known issues)。描いて測った中身は動かない:
+  送る行が描き終えるのを段ごとに待つホイールの往復は、0.43.0 と同じく始めの日報の位置へ戻る。
+- **ID でまとめた詳細は ID ごとの結末で答える** (`reports?ids=`。下の Breaking): 頼んだ ID ごとに頼んだ順の結末 1 つ (`ok` と届ける形の写しの日報・`not_found`・`failed`) で
+  答え、1 件の日報の組み立ての失敗 (表示の欄・写し方・JSON の写し・写しの厳しい読み) はその ID だけの `failed` になって、まとまりのほかの ID は答える (0.43.0 は 1 件の
+  失敗で要求全体が失敗した)。サーバーは `failed` の日報の ID と原因をロガーへ書く (読み取りと日報の組ごとに 60 秒の窓の最初の失敗だけを error で書き、窓の中の後の失敗は
+  数えて、窓の終わりに `failed_report_suppressed count=<数> since=<窓の始まり> read=<読み取り> report=<id>` の warn の 1 行にする)。読み取りは要求のシグナルで止まり、
+  日報ごとの写しを検索の印と同じく 5 ms の区切りごとに日報の境目で譲る (答えのいちばん長い同期の塊は答えの 1 度の直列化)。`not_found` は読めない・無い・削除済みの ID を
+  まとめ、区別しない (存在オラクルにしない)。
+  可視性の述語より前か述語にまたがる読み取りの失敗は、今までどおり要求全体の 500。クライアントは `not_found` を null (行の安全弁が一覧から外す)、`failed` をその ID の
+  読み手だけの誤り (`[daily-report] reports answered the outcome failed for report <id>`。新しい読み手が頼み直し、描いている日報は残す) にし、結末の欠けた・重なった・
+  頼んでいない・順の違う答えは答え全体の形の誤りにする。
+- **検索の印は 1 件の壊れた日報でまとまりの印を失わない**: 印の読み取りも ID でまとめた詳細と同じ日報ごとの読み取りを通り、組み立てに失敗した日報は読めない日報と同じく
+  答えに入れずに ID と原因を書く (上と同じ窓で、窓は読み取りごと。0.43.0 は 1 件の失敗で、最大 100 件のまとまりのほかの日報の印もその epoch の間付かなかった)。サーバーは
+  組み立てた最初の日報をいつも答える。
+  届ける形の読みは 5 ms の区切りごとに日報の境目で順を譲り、読み終えたら印の前に 1 回譲る (100 万単位の日報の写しも、印の区切りを 0.43.0 と同じ長さに保つ)。答えの形と
+  クライアントは変わらない。
+- **文字は 7:1 (WCAG 1.4.6 AAA)**: パッケージが塗るどの文字の色も、載りうるどの地の上でも、明暗どちらでもどの状態でも 7:1 以上 (文字でない色は 3:1)。控えめな文字
+  (節の見出し・メタ情報・置き文字・空のビューの文言・選ばれていないタブ・仮の面・コメントの日時・検索の失敗の行・状態の札ほか) は 1 つの式の色
+  (`--aqdr-text-quiet`: 明 `oklch(44% 0.046 257.417)`・暗 `oklch(77% 0.040 256.788)`。slate-500 と slate-400 の彩度と色相で、明度は載る面から求めた値) で、7.06〜9.75:1。
+  色の段を 1 つ濃くしたもの: ID の札 blue-800・区分の札と開発の札と再試行中の札 amber-900・失敗の札 rose-900・添付の名前 blue-800 (暗色 blue-300)・誤りの文言 red-800
+  (暗色 red-300)・既定の `Internal` のバッジ emerald-900・コメントの書き手の色 red-800・green-900・blue-800・yellow-900・orange-900 (暗色 red-300・blue-300)・暗色の
+  検索の印 yellow-900 (8.38:1)。白の文字を載せる塗り: コメントの送信 blue-800 (ホバー blue-900)・削除の確認 red-800・誤りの知らせ red-800 (どちらの配色も。閉じる字形は白、
+  ホバー red-900)・作成のボタン amber-800 (ホバー amber-900)・ストリームの再試行 rose-100 の地に rose-900 (暗色 rose-900 の地に rose-50)。検索の帯の切り替えの塗りの面は
+  明色が白の文字の blue-800 (8.82:1)、暗色が slate-950 の文字の blue-300 (11.12:1。暗色で白の文字の塗りは、文字の 7:1 と塗りとページの 3:1 を同時には満たせない)。
+  0.43.0 の AA の失敗 (自分のコメントの面の上の緑・黄・橙・赤の書き手、自分のコメントの日時、自動の既読の札の 4.43:1、知らせの閉じる字形) もこれで閉じる。
+  変わるのは色のクラスだけで、行の落ち着いた DOM は 0.43.0 と色のクラスの置き換え (と下の殻の面) のほかは同じ。
+- **殻はカードの面を描く**: 殻と名前の付いた殻の面 (`data-daily-report-row-shell`) は、行の箱を埋めたまま中身の無いカードの面 (角の半径・枠線・色・影) を描く
+  (0.43.0 は何も塗らない四角の面)。CPU の遅い端末の押し続けで殻のまま見える行でも、アクティブな行の選択の輪とフォーカスのアウトラインはカードと同じく枠と同心の角で
+  描かれ、カードが載っても休んでいる面の色・枠線・影は変わらない。要素は増えず、配る CSS のクラスの集合も変わらない。
+- **区分のバッジの略語は、見出しが名前を略すときだけ** (WCAG 3.1.4): 見出しが設定の `name` と同じバッジは `<abbr>` を描かない (何も略していない)。
+- **ids の行の `streamAnchor` は空の SSE のストリームで原点 `"0-0"`** (下の Fixed): `null` は位置が分からないとき (Redis のクライアントが無いか読み取りの失敗) と、内部ユーザーの
+  無い閲覧者だけ。SSE のカーソル `0-0` は、ストリームがエントリを 1 つも消していなければ (XINFO STREAM の `entries-added` が `length` と等しい) ストリームの最初のエントリから
+  catch-up し (`connected` は `id:` を持たない)、消していれば `resync-required` で答え、空のストリームではライブのエントリだけを配る。どのカーソルでも、空のストリームでは
+  catch-up のページを読まず、catch-up の間に届いたエントリで resync しない。
+- **区分のバッジの色はホストが 7:1 に保つ** (README の External Source Badge Configuration): パッケージの 7:1 の守りはパッケージ自身のクラスしか読まないので、ホストの
+  `badgeClassName` は文字をバッジの塗り (カードとオーバーレイに重ねたもの) に対して明暗どちらでも 7:1 に保つ。README と設計仕様書の例はその組 (emerald-900 と
+  emerald-400 (パッケージの既定)・red-900 と red-300・blue-800 と blue-300) に替わった (前の例の green-800・red-800 は明で、red-400・blue-400 は暗で 7:1 に届かない)。
+- **断られたコメントの投稿は下書きを残す** (WCAG 2.2.5 のパッケージの分): 送る間は欄を読み取り専用にして下書きを残し、受け入れられたら空にする。断られた投稿 (401・403・5xx)
+  は打った文字とキャレットをそのまま残す (0.43.0 は前後の空白を除いた文を戻し、キャレットを末尾へ動かした)。
+- 性能の試験 (9 つの条件、30 ms の繰り返しで 40 回のキーの押し続け、各 3 回): どの実行も 40 行を動かし、キーの処理の時間の p95 は最大 4.63 ms、keydown の中の強制したスタイルと
+  配置・届く範囲の内の keydown の中で描いた本体・キーの仕事と同じフレームで確定した単位はどれも 0。合成器の活性化から差し出しまでの待ちはどの条件もキーごとの中央値
+  0.20 ms 以下で 4 ms を超えたキーは 2 つ以下 (List の 80,000 行は、決まった箱の行のビューが押し続けを聞かなくなった後の 3 回で 0.125・0.169・0.135 ms と 0・1・0)。
+  表示の遅れの p95 は DetailList の行 110 から 20.67 ms、16,000 行から答えを
+  見せたまま 21.07 ms (0.43.0 は 21.95 ms)、次のフレームまでの p95 は 17.8〜19.7 ms。80,000 行から答えを見せた押し続けの割り当ては、計測器とカードの窓の中の描画を除いた 0.42.0 と同じ読みで
+  8,518 KiB から 6,849 KiB (19.6 % 減)。
+- **開発者向け**:
+  - バンドル: `client.mjs` は gzip で 102,470 B (0.43.0 は 98,384 B) で、3 % の予算 (101,336 B) を超える増えはこの版の実行時の機能 (行の 2 段目の描画の判定と聞くフレーム・
+    行の操作部品の登録・測った見積もり・名前の付いた殻・ID ごとの結末の読み取り) で、増加の台帳 (`bundle-growth-ledger.json`) がモジュールごとの理由を持つ。テストの計測は
+    `dist/testing.mjs` (1,713 B) へ出て、クライアントの束から 0.43.0 の試験の口のコードが抜けた。`index.mjs` は 5,522 B で変わらず、`server.mjs` は 53,149 B
+    (0.43.0 は 52,158 B。3 % の予算の内)。
+  - 仕様書の引用のガード (`spec-citations.guard.spec.ts`) は `src` のどのソースのコメント (JSDoc と行のコメント) の確かめる形の識別子 (`use…`・`create…`・`read…` ほか) も
+    `src` の名前と照らす (ほかのパッケージの指定子を所有でつないだ名前は除く。名前は型の位置の文字列のリテラル型も数える)。消した関数の名前を docstring が持ち続けると落ちる。
+  - 押し続けの下の行の 2 段目の描画の偽の時計の spec (`rows/hold-schedule.spec.ts`) は、仕事の後の最初の vsync に来るフレームと押し続けの前に変わる CPU の倍率の模型になり、
+    1x と 1.5x の押し続けを判定の無い送り手で記録した痕跡と比べ、アプリで記録した 4x と 1x の押し続けを主スレッドのとおりに再生する (`rows/__fixtures__/`)。
+  - 文字の 7:1 の守り `ui/aaa-text-contrast.spec.ts` は、配布するクライアントのどの色の字面も登録した地の上で測り、登録の無い字面を落とす。
+  - `VirtualScroll` の代役は、本物が宣言しない名前の props を描画で拒む (`TypeError`)。
+
+### Fixed
+
+- **上への押し続けが、眠っていた送り手のまま本体をキーの確定の中で描いた**: 送り手は進む向きを自分のフレームでしか読まなかったので、眠った送り手で始まった上への押し続けは
+  向きを下のまま持ち、上にマウントした行を後ろの行として待たせ、見えるようになったキーの確定の中で描いた (1x の模型で 1 回の押し続けに 4〜5 回)。進む向きは押し続けの
+  キーの段から決める。
+- **速いホイールの往復** (0.43.0 の既知の問題): List は始めの位置へ戻る。DetailList は小さくなったが残る (上の Changed と下の Known issues)。
+- **空の SSE のストリームで ids を読んだ後、SSE がつながるまでに公開した日報が届かなかった**: 空のストリームの ids のアンカーは null (位置不明) で、SSE はカーソル無しで
+  つながって接続の時点の最新のエントリから配ったので、ids の読み取りと接続の間に公開した日報を配り済みと取り違えた (Redis の再起動・ストリームの刈り込み・新しいワイヤの版の
+  後に起きる)。空のストリームのアンカーはストリームの原点 `"0-0"` で、その後に公開した日報は原点からの catch-up で届く (上の Changed)。
+
+### Breaking
+
+- **E2E の試験の口は testing の入口へ移り、テストのビルドでだけ載る**: `DailyReportViewTestHandle`・`DailyReportViewTestReadHandle` は client エントリから
+  `@aiquants/daily-report/testing` へ移った。ビューの `__virtualScroll` は、ホストが `DailyReportInstrumentationContext` で計測を配ったときだけ載る (0.43.0 はいつも載せた)。
+  Migration: E2E のビルド (たとえば `react-router build --mode test`) でだけ、画面の周りへ `createDailyReportTestInstrumentation()` を
+  `<DailyReportInstrumentationContext value={…}>` で配り、型は `@aiquants/daily-report/testing` から読む。本番のビルドは何も配らない。
+- **`reports?ids=` の答えは `{ outcomes }`**: 頼んだ ID ごとの結末の並び (`DailyReportSearchDetailsAnswer`)。サービスの `getDailyReportDetailsByIdsByExternalId` も
+  `DailyReportSearchDetailOutcome` の並びを返し、4 つ目の引数に要求のシグナル (`{ signal }`) を必ず取る (`markDailyReportSearchHits` と同じ: どの問い合わせよりも前に確かめ、
+  `options` か `signal` が無ければ `TypeError`、ほかの値は `RangeError`。中断されれば次の確かめでその `reason` を投げる)。パッケージのクライアントとサーバーは同じ版で揃える
+  (前の形の `{ reports }` はクライアントの読み取りが丸ごと拒む)。
+  Migration: 経路やサービスを直に読むホストのコード (結合試験など) は、`outcome` が `ok` の結末の `report` を読み、`not_found` を答えに無い日報として扱う。サービスを直に
+  呼ぶコードは要求のシグナルを渡す (`{ signal: request.signal }`。中断しない呼び出しは `{ signal: new AbortController().signal }`)。
+- **ホストの Redis の口 `DailyReportRedisClient` は `xInfoStream(key)` を必ず持つ**: SSE の catch-up は原点のカーソル `0-0` を確かめるのに XINFO STREAM の `length` と
+  `entries-added` を読み、`entries-added` を答えるのは Redis 7.0 以上 (それより古い Redis では、その接続を `producer-failed` で閉じる)。
+  Migration: node-redis 5 のクライアントは今のまま型を満たす。口を自分で組むホスト (試験の代役など) は `xInfoStream` を足し、存在するストリームの XINFO STREAM を欄の名前で
+  引ける値で返し、無いキーには拒否で答える。Redis は 7.0 以上にする。
+- **ピアの `@aiquants/virtualscroll` は 3.18.0 以上**: DetailList は行の高さの見積もりを `estimatedItemHeight` と `setItemHeightEstimate` (理由 `"re-estimate"`) で渡す。
+  Migration: `@aiquants/virtualscroll` を 3.18.0 以上へ上げる。
+
+### Known issues
+
+- **遅い端末の押し続けの次のフレーム**: CPU を 4 倍遅くした DetailList の押し続けの次のフレームまでの p95 は 45.1・33.4・27.4 ms (中央値 33.4) で、目標の 33 ms を満たさない。公開前の計測 (確定した 2 回) では 33.5・51.6 ms。
+  p95 のフレームはどれも機能自身のもので、スタイルと配置 5.3・3.9・2.9 ms、塗り 13.5・7.3・8.1 ms、残り (主にスクリプト) 25.4・23.1・14.9 ms。キーのフレームの塗りの変化を
+  無くす形 (合成だけで描く選択の印・先に置く端の行・自分の層のつまみの札) は画素を変えるので、次の版で配置の作業と一緒に試作し、画素の違いを測ってから決める。押し続けの
+  途中で 2 倍に遅くなった装置は、押し続けの中で判定しないことがある (模型の 12 の種のうち 2 つ)。そのときの行は 0.43.0 と同じく入る確定でカードまで描く。
+- **80,000 行から答えを見せた押し続けの表示の遅れ**: p95 は 22.62 ms (実行ごとに 22.59・22.62・23.36 ms) で、どの関門も判定しない。最初のキーの層の新しい塗りが決め、
+  DetailList の押し続けでは行の層がキーのフレームごとに新しい ID を取る (押し続けあたり 22〜40 回、新しい層のタイルは 43〜61 %)。画素を変えずに層の ID を留める形はまだ無い。
+- **上への押し続けの合成器の遅れ**: 80,000 行から答えを見せて行 110 から 40 回上へ押し続けると、合成器の待ちの中央値は 1.573 ms で、4 ms を超えたキーは 19 (82 の vsync の
+  うち定刻 43・1 フレーム遅れ 36・落とした 3)。上への押し続けは上の行の高さの配達が見える範囲より上の行を動かすので vsync ごとに確定し、休みのフレームが無い: 長いキーの
+  フレームか単位のフレームの後に 1 フレームを落とすと、合成器は押し続けの終わりまで 1 フレーム遅れたまま (この確定の形は 0.43.0 の作りのまま。行の描画を区切らない今の版で測った)。
+  遅いホストでは、上のアクティブな行を keydown の中で描くこともある (ある実行で keydown の中の本体 1 つと同期の描画 5 つ。ほかの実行では 0)。次の版で、押し続けの間の
+  高さの配達を待たせる形と、フレームの前の仕事 (ストリームの処理・大きさの無い画像・始まる `pulse`) を外す形を測る。
+- **4x の keyup の後の遅れたフレーム**: キーを離した後、アクティブな行のカードを先に、見えている殻を見える順に描くが、どの実行もカードの間に単位の無いフレームが 1 つある
+  (カードがフレームを超え、次のフレームが遅れて始まるので、遅れたフレームとして飛ばす)。アクティブな行のカードまで 3・4・4 フレーム、見えているどの殻のカードまで 5・6・6
+  フレーム。次の版で、keyup の後の待たせた見える単位は遅れで飛ばさない。
+- **120 回のキーの押し続け** (報告のみ): DetailList の 16,000 行から答えを見せた 120 回の押し続けは、46 回目のキーで落としたフレームから押し続けの終わりまで 1 フレーム
+  遅れたまま (合成器の待ちの中央値 7.77 ms、120 のキーのうち 4 ms を超えたもの 72)。同期の描画は 11 (120 回の押し続けの模型の帯 10〜13 の中)。List の同じ遅れは、
+  決まった箱の行のビューが押し続けを聞かなくなって消えた (80,000 行の 3 回で 4 ms を超えたキーは 0・1・0)。DetailList は判定が付くまで押し続けのフレームを聞くので、
+  次の版で、決めた停止を入れた DetailList の押し続けを 0.43.0 と比べる。
+- **List の答えを見せた行 110 の keydown の配送**: スクリプトが主の keydown の配送の時間 (計測器を除き、実行ごとのエンジンの探りで正規化) は 61.94 ms で、0.43.0 の
+  56.6 ms を上回る (実行ごとに 69.64・61.94・54.45 ms、0.43.0 は 93.58・56.57・54.55 ms。React の聞き手のスレッドの時間は 61.9・54.6・47.9 ms、0.43.0 は 71.0・49.9・
+  48.2 ms)。この版の変更のうち 1 つで押し続けあたり 1.4 ms を超えるものは無く、次の版でキーの道を測る。
+- **DetailList の素の速いホイールの往復**: 20,000 px を待たずに送って同じ量で戻すと、React の開発版のビルドの E2E で 6 回のどれも始めの位置から 156〜548 px ずれる
+  (0.43.0 は 644〜1,116 px。List は 3 回とも戻る)。開発版ではカードを描くのに 10〜26 ms かかるので通り過ぎた行が遅れて測られ、ペインの上で見積もりから測った高さへ
+  変わり、VirtualScroll の位置の補正が見えている行をその場に保つ (見えている行は動かない)。描いて測った中身は動かないので、送る行が描き終えるのを段ごとに待つ往復は
+  0.43.0 と同じく始めの日報の位置へ戻る。次の版で、可視の先頭より上の補正を測っていない行へ当てて、画素の往復を中身の往復にする。
+
 ## 0.43.0 (2026-10-14)
 
 ### Added