@aiquants/daily-report 0.40.0 → 0.41.0

package/CHANGELOG.md

@@ -2,6 +2,146 @@
 
 All notable changes to `@aiquants/daily-report` are documented here.
 
+## 0.41.0 (2026-10-11)
+
+### Added
+
+- **SSE のストリームのキーの組み立て `buildDailyReportSseStreamKey(streamKey)`** (server エントリ): サービスが SSE のエントリを書いて読む Redis Stream のキー (基のキーにワイヤ形式の版を付けた `<streamKey>:v3`) を作る。ストリームへ直接書き読みするホスト (結合試験など) は、版を書き写さずにこれでキーを作る (版を上げたときに、書き写したキーだけが古い版に残らない)。
+- **`DailyReportRowBatch.idAt(i)`・`businessDateAt(i)`・`sourceTypeAt(i)`** (client エントリ): 行のまとまりの行の ID・営業日・区分を、行のオブジェクトを作らずに 1 つずつ読む (下の Breaking)。
+- **一覧全体の公開の読み口 `readDailyReportIdsStreamRows()`** (client エントリ): セッションの一覧を最後の publish の時点で行のまとまり 1 つへ写して返す (セッションが無ければ空のまとまり)。
+  publish の状態は一覧を運ばず変化だけを運ぶので、32 の変化の履歴より遅れた購読者は一覧をこれで読み直す (セッションのクライアントのクラスは公開しない。下の Breaking)。
+- **検索の印の答えの厳格な読み手 `readDailyReportSearchMarksAnswer(payload, expected)` と、要求が求めるものの型 `DailyReportSearchMarksExpectation`** (共有エントリ): パッケージのクライアントが使う読み手そのもので、
+  `search-marks` を自分で呼ぶホスト (結合試験など) は答えを型の主張で読まずにこれで読む (頼んだ ID・見せている答えのキーワードの数・日報が当たったキーワードの組を持つかを渡し、合わない答えは null)。
+- **厳格な読み手が受けた行の列の型 `DailyReportIdsStreamRows`** (共有エントリ): `readIdsStreamChunkLine` の答えの `rows` の型で、`forEachIdsStreamRow` が受ける唯一の列 (下の Breaking)。
+
+### Changed
+
+- **ids の行は読み手が確かめた値で読む** (下の Breaking): 共有エントリの厳格な読み手 `readIdsStreamChunkLine(line)` は、受けた行を `DailyReportIdsStreamChunk` で答え、壊れた行には null を答える。答えは行の列 (`rows`。読んだ行そのもので写さず、型は受けた列の `DailyReportIdsStreamRows`)・`isLast` と、任意の項目をクライアントが採る規則で読んだ値を持つ:
+  再開のカーソル (`resumeCursor`。サーバーが読み返すカーソルだけで、ほかは null)・`total` (0 以上の安全な整数だけで、ほかは null)・`snapshot` (トークンの形だけで、ほかは null)・`provisional` と `restarted` (真偽の `true` だけが true)・`streamAnchor` (無い・値・受け取った値を持つ形の誤り)。任意の項目の形の誤りでは行を拒まない。答えのオブジェクトは行ごとに 1 つで、行のオブジェクトは作らない。
+  クライアントは行をこの読み手で 1 度だけ読み、答えの項目だけを使う (ワイヤの値を 6 か所で確かめ直さない)。再開の規則 (`isResumableIdsStreamCursor`・`isIdsStreamSnapshotToken`) は `src/shared/ids-stream.ts` に 1 つだけ置き、サーバーの再開の解釈 (`readIdsStreamQuery`) と行の読み手が共有する。
+  以前の `isIdsStreamChunkLine` は行を `DailyReportIdsStreamChunkLine` へ絞り込むのに任意の 5 つの項目を確かめず、`total: "9"`・`restarted: "no"`・`provisional: 0`・`snapshot: 42`・`streamAnchor: 7` の行も確かめた型のまま通した。
+- **営業日の符号は 32 ビット**: 常駐の行・変化の行のまとまり・プロバイダーの並びの営業日の符号は `Uint32Array` (行あたり 2 バイト増え、11 万行で約 220 KB) で、ワイヤが運べるどの営業日 (0001-01-01〜9999-12-31 の 3,652,059 日) にも符号がある。
+  以前は 16 ビットの符号が 65,535 日で尽き、閲覧者の行がそれより多くの別々の営業日を持つと (書き手 1 人が別々の日付の日報を作るだけで起きる)、どの ids のストリームも同じカーソルで試みを繰り返して `failed` で終わった。区分の符号は今までどおり 255 種類まで (区分はサーバーの連携が決め、閲覧者の操作では増えない)。
+- **SQL 結果キャッシュの見積もりは保持するヒープの上界**: `estimateRecordsBytes` は、たどった配列・オブジェクト・バイナリの view ごとに 32 バイトの頭、持つ値ごとに 8 バイトの欄、文字ごとに 24 バイトの頭と UTF-16 の単位ごとに 2 バイト、31 ビットの整数でない数 (小数・大きな整数・−0・NaN) ごとに 16 バイトの箱、view のバイト数を数える。
+  Node 24 の実測で、見積もりは 11 万行の ids のバケットの保持するヒープの 1.31 倍、詳細の形の行の 1.09〜1.16 倍、長い本文の 1.00 倍 (日本語)〜2.00 倍 (ASCII)。以前は頭と箱を数えず、よくあるバケットを 1.70〜1.89 倍少なく見積もった (既定の 512 MiB でワーカーあたり 0.9〜1 GB を持ちえた)。
+  上限 (`cacheMaxBytes`) はキャッシュ 1 つ、つまりプロセスごと: ワーカーを N 個持つホストは N 倍までを持つので、ワーカーの数を知って決める。
+- **単独で置いたストリームのバッジは、空のまま置いた領域で知らせる**: `DailyReportIdsStreamStatus` は `DailyReportPage` の中に無いとき (ページの中では、ページの常設の読み上げが知らせる)、入れ物の隣にパッケージの読み上げの部品 (`data-testid="daily-report-ids-stream-status-announcer"`) を置く。空のままマウントした `role="status"` と `role="alert"` の領域で、変わるのは文字だけ。
+  再接続中 (`labels.streamRetrying`) は状態、ストリームの失敗 (`labels.streamFailed`) は警告で知らせ、マウントの時点の文字は書かない。局面ごとの札は読み上げの領域ではない。ページの常設の読み上げ (`daily-report-stream-announcer`) も同じ部品 (`src/client/ui/live-announcer.tsx`)。
+  以前は、単独で置いたバッジの再接続中と失敗の札が、局面の変化で文字を持ったまま現れる `role="status"` で、読み上げられないことがあり (WCAG 4.1.3)、失敗をページの警告より弱い状態として伝えた。
+- **デスクトップの側面ペインのスクロールバーはビューと同じ配色**: ビューの休みのつまみと溝の組 (つまみ slate-500、溝 slate-100・暗色 slate-900。明 4.35・暗 3.74) を 2 つの独自プロパティ (`--aqdr-scroll-bar-thumb`・`--aqdr-scroll-bar-track`) で 1 度だけ名指し、VirtualScroll のバーの配色と、デスクトップの側面ペインのスクロールの箱のブラウザー自身のバーの `scrollbar-color` をその上に組む。
+  同じ中身を描くモバイルのオーバーレイの箱はブラウザー自身のバーのまま (組のつまみが、390×844・DPR 3 で右の列の添付のタイルのフォーカスの輪の右の縁の上に描かれるため)。
+  以前は側面ペインのブラウザーのバーが既定の灰色 (暗色で #2c2c2c / #9f9f9f、明色で #fcfcfc / #8b8b8b) のまま、隣の List の slate のバーと同じ画面に並んだ。バーの幅と §3 の幅は変わらず、Safari 17.4 は `scrollbar-color` を読まずに既定のバーを描く。
+- **行の同一性の控えは 2 つの世代**: 位置で読む行のオブジェクトの控えは 512 行の世代 2 つ (`REPORT_ROW_IDENTITY_CAPACITY` = 1,024) で、若い世代で当たる読み取りは何も書かず、古い世代で当たった行を若い世代へ移し、若い世代が 512 行になったら古い世代と入れ替える。
+  両ビューの行のキー (`getItemKey`) は行のオブジェクトを通さずに ID の列を読む (`reportIdAt`)。同じ窓の描き直しは最初の読み取りの後に控えを書かず、窓の行の控えの読み取りは描画あたり 2 回から 1 回になった。
+  Node での計測 (11 万行・60 行の窓・押し続けあたり 40 キー・キーあたり描画 1 回): 押し続けあたりの確保と時間は List が 266.8 KiB・0.47 ms から 6.6 KiB・0.066 ms、DetailList が 395.7 KiB・0.69 ms から 6.6 KiB・0.13 ms。以前は読むたびに `Map` の項目を消して足し直し、V8 が表を作り直し続けた。
+- **詳細はその場で読む 1 つの厳格な読み手で読む** (下の Breaking): 日報の詳細とその部品 (面談者・レガシー形式のコメント・ラベル・投稿したコメント) は 1 つの読み手 (`src/shared/detail-reader.ts`) が JSON の値を置かれた場所のまま確かめ、契約どおりなら同じ値を答える。
+  `dailyReportDetailSchema` はこの読み手の上に組み、SSE のメッセージ・action の答え・読み取りのエンドポイントの答えは同じ規則で読む。必須の鍵は補わず (`attachments` と添付の `hasThumbnail` も。下の Breaking)、知らない鍵の除去だけが変わる道のオブジェクトを新しく作り、渡した値は書き換えない。
+  合わない値の問題は zod の言葉 (`invalid_type`・`invalid_enum_value`・ID のスキーマの問題) で今までと同じパスと順に答え、`describeWireMismatch` の文も変わらない。
+  Node での計測 (3.5 KB の日報 30 件): 日報あたり `{ reports }` の答えは 34〜40 µs・50.6〜57.3 KiB から 10.8〜11.6 µs・8.6 KiB (`JSON.parse` だけで 7.0〜7.5 µs・6.7 KiB)、SSE の更新は 42〜44 µs・58.5 KiB から 16.5〜17.4 µs・11.7 KiB。以前は zod の `z.object` が日報ごとに木を丸ごと写した。
+- **検索の印は値の除去・行の分割・行の分け方の中でも区切る**: 印の歩みは値の除去・行の分割・行 1 つの分け方を、索引の文字の処理の段で進める版 (`stripInvisibleSearchCharactersMappedSteps`・`forEachSearchLineSteps`・`planSearchLineSteps`) で、見積もり 0.5 ms 以内の段ずつ進める。
+  段の版の結果は 1 回で行う版とどこで区切っても同じで、索引の保存と正規化の版は 1 回で行う版のまま (正規化の版の文字は変わらない)。行ごとに決まった仕事の見積もり (2 µs) も払うので、空の行だけの値でも計器が時計を読む。見積もり (ns) は除去 30・行の分割 200 (単位あたり)・行 1 つ 2,000・分け方 90 (仕事の単位あたり)。
+  100 万単位の値の最長の区切り (壁時計、ホストの負荷 0.4): 改行だけで 604 ms から 12.6 ms、見えない文字と改行の 50 万行で 326 ms から 9.4 ms、1 字の行の 50 万行で 61 ms から 10.9 ms、文脈によらない切れ目の無い全角の `ＡＢ` の行で 51 ms から 5.2 ms、空白の多い行で 69 ms から 8.0 ms。
+  行の多い値では歩み全体の時間は増える (改行だけの 100 万単位で 0.7 秒・2 つの区切りから 2.4 秒・458 の区切り。行あたりの段の用意の費用)。
+- **印の 429 の待ちは 60 秒まで**: 検索の印の 429 は、`Retry-After` が 60 秒 (`SEARCH_MARKS_MAX_RETRY_AFTER_MS`。サーバーのレートのバケットの窓 1 つ) の内ならその後に 1 回だけ頼み直し、`Retry-After` が無いか超える 429 は時計を置かずに、その epoch の間はその ID を印なしにする。
+  以前はどの `Retry-After` もそのまま時計へ渡したので、2,147,484 秒以上の待ちは時計が溢れてすぐに頼み直し、大きな待ちの間は記録を持ち続けた。
+- **日報を運ばない後回しの答えは拒む**: 検索の印の答えの読み手 (`readDailyReportSearchMarksAnswer`) は、日報を 1 件も運ばずに ID を後回しにする答えを丸ごと拒む (サーバーは最初の日報をいつも答えるので取り決めの破れで、頼み直しても前へ進まない)。以前は受け、store は前へ進まない答えとして扱った。
+- **後から届く日報のカードは後追いの描画で載せる**: List のカードと DetailList の本体は読み込んだ日報を `useDeferredValue` を通して描くので、読み込みの答えや SSE の更新で届いた日報のカードは、それを運んだ更新の中ではなく、キーの押下が割り込める後追いの描画で載る。
+  その描画が確定するまで、カードをまだ描いていない行はスケルトンのまま `aria-busy="true"` (描くのを待つ読み込み済みの日報は不在ではない)。遅らせるのは描くことだけで、判断は読み込んだ日報そのものを読む:
+  消えた日報の行を外す安全弁と、DetailList の本体の下書きか・自分の日報か・下書きを開く編集 (編集のボタンは確定した最後の読み込んだ日報を読み、無ければ何もしない)。
+  性能の試験で、答えを見せた List の押し続けの予算を超えるフレームは、行 110 からで 2 から 1、80,000 からで 3 から 1 になり、どちらの条件も目標を満たした。
+- **ID でまとめた詳細の読み手の後始末**: 詳細の読み手 (`useDailyReportDetail`) は、ID でまとめた読み込みを始めた実行だけが中断の合図の持ち主を作り、前もって作った 1 つの理由で止める。キャッシュの日報・営業日の読み込み・走らなかった待ちの再取得は何も作らず、何も止めない。
+  性能の試験の押し続けあたりの後始末は 8.5〜8.7 ms から 0.73〜1.06 ms (理由を渡さない中断が呼ぶたびにスタックごと作っていた `AbortError` の例外と、押し続けあたり 460〜822 KB の確保が無くなった)。
+- **検索の帯の件数は見出しの 1 つだけ**: 当たりの件数は見出しの件数 (`renderHeader` が受ける注記の中) にだけ出し、検索窓は件数を画面に書かない。検索窓の読み上げの領域は 1 つ
+  (`aria-live="polite"`。画面に出さない) で、検索中・件数 (見せている一覧の大きさ。ストリームが答えの日報を消せば下がる)・当たり無し・失敗を読む。注記を描かないホストでは件数は画面に出ない (総数と同じ)。
+  以前は見出しと検索窓の状態の行が同じ件数を 2 度描き、390 px の電話で入力欄が約 90 px 狭まった。
+- **検索の帯の失敗の行と欄の中の待ちの印**: 失敗 (検索語が正しくない・混み合っている・使えない・そのほか) は入力欄の下の失敗の行で見せ (読み上げの領域ではない)、入力欄の説明の先頭に入る。
+  入力欄が `aria-invalid` を持つのは検索語が正しくないときだけ。検索中は入力欄の中の自分の場所に回る印 (読み上げから隠し、動きを減らす設定では回らない) を描き、消去のボタンは隠れずに押せる。
+  入力欄は終わりの側に 24 px の場所を 2 つ空けておくので、検索の状態で入力欄の幅も文字の位置も変わらない (320 px の幅でも空の入力欄は全角 4 文字以上を持つ)。
+- **検索の帯の切り替えは幅を変えない**: AND/OR と絞り込みの切り替えは、今の文字と見えない取り置きの文字 (もう一方の文字、最も多い値の数の文字) を 1 つの格子の升に重ね、広い方の幅を
+  格子の最小の幅 (56 px・104 px) で切り上げる。押しても数が増えても入力欄の縁は動かず、既定の文言では入力欄の始まりと終わりが 4 px の格子に乗る。取り置きの文字は名前にも文字の内容にも入らない。
+  以前は AND (50 px) と OR (41 px) の幅の差で、押すたびに入力欄の始まりが 9 px 動き、DPR 1.25 で縁がにじんだ (2.91:1)。
+- **検索の答えの一覧は変わった日報から更新する**: 答えを見せている間の一覧は、publish の変化が答えの日報の項目を変えなければ作り直さない (性能の試験の押し続けあたりの確保は、一覧の導きが 827〜1,095 KB から 0、行の並びの読み取りが 448 KB から 0)。
+- **ID でまとめた詳細の要求は行の出入りが止んでから**: 答えを見せている間の行の詳細の ID は、行の出入りが止んだ後の最初のアニメーションフレームで送り手へ並ぶ。速いスクロールの途中で
+  載って外れる行の要求を始めず、止まった窓の行の待ちは 1 フレームまで。
+- **`SqlResultCache` の上限は省ける**: コンストラクターの `defaultTtlMs`・`maxBuckets`・`maxBytes` はどれも省け、省けばクラスの既定値 (60,000 ms・4,096・512 MiB。`createDailyReportServer` の
+  `cacheDefaultTtlMs`・`cacheMaxBuckets`・`cacheMaxBytes` と同じ) で、誤りはファサードの設定の名前を名乗る (`[daily-report] cacheMaxBytes must be an integer >= 1; got 0`)。ファサードは値をそのまま渡し、検証は 1 度だけ。
+- **`knownSourceTypes` は凍結した配列**: `createDailyReportServer` の `knownSourceTypes` は、パッケージ自身の区分 `Internal` を先頭に外部ソースの区分を順に並べた凍結した配列で、サービスの
+  `searchFilterSourceTypes` と同じ配列。
+- **開発者向け**:
+  - バンドルの増加の台帳はファイルごとの理由と、出荷した版を持つ: 項目は `{ recordedAfter, release, file, from, to, deltaPercent, reason }` (`recordedAfter` は記録した時の `package.json` の版、`release` は出荷する版で、公開のスクリプトが刻むまでは `"Unreleased"`)。
+    `--reason` はファイルごと (`--reason '<file>=<text>'`。繰り返す) で、理由の無い増えたファイル・予算の対象でないファイルの理由・同じファイルの 2 つの理由は何も書かずに exit 2。公開のスクリプトは `pnpm version` の直後に `--stamp-release` で `"Unreleased"` を新しい版に変え、`prepublishOnly` の `--released` は `"Unreleased"` の残る台帳で公開を止める。
+    既存の項目は `version` を `recordedAfter` へ改め、その項目を含む最初の公開のタグから `release` を付けた (0.35.0〜0.40.0)。
+  - 読み上げの領域の守り (`src/client/ui/live-regions.spec.ts`): 出荷するクライアントで読み上げの役割 (`status`・`alert`・`log`・`marquee`・`timer`)・`aria-live`・`<output>` を書くのは、パッケージの読み上げの部品 (`src/client/ui/live-announcer.tsx`) と、理由を付けてレビューした常設の 3 つの領域 (知らせの警告の領域・検索窓と絞り込みの行の状態の文字) だけ。
+  - ref の初期値の守り (`src/client/hooks/lazy-ref-initializers.guard.spec.ts`): 出荷するクライアントのどの `useRef` の引数も、描画のたびに何かを作らない (リポジトリの共有の走査 `.config/scripts/lib/lazy-ref-initializers.mjs`。`@aiquants/virtualscroll` の守りも同じものを使い、例外の一覧は無い)。
+    描画のたびに配列・`Map`・オブジェクトを作っていた ref (誤りの文脈・コメント・action の文脈・DetailList の高さ・検索窓・表示中の印の store・絞り込みの候補) は `useLazyRef` かモジュールの定数になった。
+  - 決まったクラスの重ね合わせの守り (`src/client/ui/class-merge-sites.guard.spec.ts`) は例外の一覧を持たない (検索窓と絞り込みの行の 3 か所はモジュールの定数)。種から決まる乱数の守り (`src/client/test-helpers/seeded-random-copies.guard.spec.ts`) は `src/server` も読み、サーバーの spec の生成器の写しは `createSeededRandom` を使う。
+  - 内部の `resolveTodayBusinessDateKey` は、不正な `Date` を現在時刻で埋めずに拒む (`[daily-report] resolveTodayBusinessDateKey needs a valid Date`)。
+  - 文書のガードは関心ごとの 8 つのファイル (`src/readme-examples.guard.spec.ts`・`src/readme-identifiers.guard.spec.ts`・`src/spec-citations.guard.spec.ts`・`src/testing-spec-index.guard.spec.ts`・
+    `src/peer-floor-sentences.guard.spec.ts`・`src/doc-schema-names.guard.spec.ts`・`src/plan-open-decisions.guard.spec.ts`・`src/docs-current-state.guard.spec.ts`) で、網羅率を測らない `guards` のプロジェクトで走る。
+    コードブロック・その外の行・インラインコードはリポジトリの 1 つの読み手 (`.config/scripts/lib/markdown-blocks.mjs`。CommonMark の規則で読み、閉じていないコードブロックは開く行を名乗って落ちる。
+    `src/markdown-blocks.guard.spec.ts` が確かめる) で、経緯を語る行はリポジトリの 1 つの今の状態の確かめ (`.config/scripts/lib/markdown-current-state.mjs`: 版か日付を持つ見出し・地の文の
+    パッケージの版・昔を語る語・レビューの周・実行の ID・issue の参照) で読む。README と仕様書はコードブロックの外で経緯を語らず (版ごとの変更はこの変更履歴、経緯は計画書)、
+    README はインラインコードで入口が公開しない SCREAMING_SNAKE と `DailyReport` で始まる識別子を名指さない (README はホストの契約で、内部の識別子は仕様書が持つ)。
+    以前は `src/docs-examples.spec.ts` の 1 つのファイルが 7 つのガードとコードブロックの読み手の 3 つの写しを持った。
+  - README はホストの契約だけを持つ: 目次・アンカーを持つ節 (設定・読み取りのポート・描画のポート・sharp の描画・`hasThumbnail`・縮小画像の経路・ログの水準・429 の行・
+    文字の検索の各部)・Server wiring の下の Streaming routes・The API route・Request values・Realtime architecture。パッケージの開発の門 (型の検査・網羅率・ガード・バンドルの予算・
+    公開の検査) はテストの仕様書 (§1.4) へ移し、内部の識別子と理由は設計の仕様書 (00) と検索の仕様書 (03) が 1 度だけ持つ。
+  - ゲートのスクリプトはリポジトリの共有のモジュール (`.config/scripts/lib` の `count-ratchet.mjs`・`ratchet-docstrings.mjs`・`ratchet-coverage.mjs`・`gate-cli.mjs`・`source-corpus.mjs`) を
+    `@aiquants/virtualscroll` と共有し、パッケージの `scripts/` はパッケージの値を渡す短い入口 (根はリポジトリの唯一の実装と 1 バイトも違わない `scripts/lib/repository-root.mjs` で見つける)。
+  - spec は置き場で 3 つのプロジェクトに入る (`vitest.config.ts`): 網羅率を測る `node` (`src` の直下・`src/server`・`src/shared`) と `jsdom` (`src/client`)、網羅率を測らない `guards`
+    (本番の処理を読み込まない `*.guard.spec.ts` と、乱択の軌跡の組の `*.traces.spec.ts`)。環境は置き場で決まり、違う環境が要る spec だけが 1 行目に指定を持つ。`verify` と `test:coverage` は
+    網羅率を測るプロジェクトを先に、`guards` を後に走らせる。
+  - モジュールの置き場: サービスは合成の根 `src/server/service.ts` と関心ごとの `src/server/service/` (設定・SSE の書き込み・hub の写し・添付の記録・読み取り・閲覧者の状態・コメント・
+    日報の書き込み)、アクションのプロバイダーの部品は `src/client/contexts/action/`、行は `src/client/rows/`、選択は `src/client/selection/`、ID のまとめは `src/client/batching/`。公開名は変わらない。
+  - 整数の設定のガード (`src/config-integer-settings.guard.spec.ts`): 公開の `*Config` の型のどの `number` の欄も、1 つの整数の検証でちょうど 1 度だけ読む。
+  - zod の読み込みのガード (`src/zod-imports.guard.spec.ts`): `src` のどのソースも zod を `zod/v3` の入口からだけ読む。
+
+### Fixed
+
+- **zod 4 でも公開の宣言が型検査を通り、食い違いの code が同じ**: パッケージは zod を `zod/v3` の入口からだけ読む。zod 4.4.3 で共有エントリの宣言の型検査が 47 の誤りで落ち、
+  食い違いの code が変わっていた (peer の範囲は zod 4 を受けていた)。
+- **収めた後に掛かった文字の間隔の上書きも、次のフレームで収め直す (WCAG 1.4.12)**: 添付の収めたファイル名の見える文字列は中身の幅の箱 (`width: fit-content`) で、名前の列の幅の観測器がその描いた幅も見る (`observeFittedNameWidth`)。
+  列へ最後に渡した列幅より広く描かれた文字列があれば、次のフレームでその列へ同じ列幅をもう一度渡し (溢れた文字列がいくつでも列ごとに 1 回)、列の名前は書体と間隔を読み直して収め直される。切り取りは無く、窓をずらすスクロールの 1 段の描き直しは今までどおり (Chromium 148 で、素の行 1 行・添付のある行 2 行)。
+  以前は、収めた後に掛かった上書き (ブックマークレットや利用者のスタイル) は列幅を変えないので次の収め直しまで残り、名前が列から 11〜64 px はみ出して隣のタイルに重なった (Chromium 148 の探り。アプリの見た目の契約では 22〜57 px)。今は 2 フレーム目から列の中に収まる。
+  上書きが掛かったフレームだけは名前を広く描き、外した上書きは次の収め直しまで名前を短いまま残す (README の **File name**)。
+- **見出しの件数は総件数と当たりの件数で同じ幅**: 見出しの件数は検索の答えの有無のどちらでも同じ箱に描き、箱の幅は総件数と当たりの件数の最も広い文字 (総件数と答えの件数の大きいほうの桁数の最大の数で作る) の広い方が取るので、狭い幅で注記が折り返しても、答えを見せる・解除するたびに検索の帯とビューが上下に動かない (答えの件数が総件数より桁が多いときを除く)。以前は当たりの件数 (`0 件ヒット`) が総件数 (`総件数: 228,223 件`) より狭く、320 px の幅では注記が 2 行から 1 行に減って見出しが 12 px 縮み、検索の帯が上へ動いた。
+
+### Breaking
+
+- **`isIdsStreamChunkLine` は `readIdsStreamChunkLine` に**: 共有エントリの行の読み手は真偽の絞り込みでなく、確かめた値 (`DailyReportIdsStreamChunk`) か null を答える。別名は無い。
+  Migration: `if (isIdsStreamChunkLine(line)) { … line.total … }` は `const chunk = readIdsStreamChunkLine(line)` と `if (chunk !== null) { … chunk.total … }` に書き換え、任意の項目は答えの値 (`resumeCursor`・`total`・`snapshot`・`provisional`・`restarted`・`streamAnchor`) だけを読み、行は `forEachIdsStreamRow(chunk.rows, visit)` でたどる。
+- **`DailyReportRowBatch` は読み口の型で、列を持たない**: client エントリの `DailyReportRowBatch` はクラスでなく読み口 (`length`・`idAt`・`itemAt`・`items`・`businessDateAt`・`sourceTypeAt`) で、
+  `ids` の列も `businessDateCodes` と `sourceTypeCodes` (ページの中で値が初めて現れた順に配る符号) も無い (パッケージが共有する書ける列を渡さない)。0 から `length` − 1 の整数でない位置の読み取りは
+  投げる (`[daily-report] A batch of <n> rows has no row <i>`)。
+  Migration: ID は `idAt(i)`、営業日と区分は `businessDateAt(i)`・`sourceTypeAt(i)` か `itemAt(i)` で読む (`batch.ids[i]` は `batch.idAt(i)`)。符号を読んでいたホストは値で読む。
+- **詳細のスキーマは `ZodObject` でない**: `dailyReportDetailSchema` は `z.ZodType<T, z.ZodTypeDef, unknown>` (読み手の上に組んだ変換) で、`.shape`・`.extend`・`.pick` は無い (部品のスキーマはもう公開しない。下の項)。
+  拒んだ詳細の問題は打ち切りの印 (`fatal: true`) を持ち、後の `.refine` や `.transform` へ値を渡さない。受ける値・出力・問題のパスと符号は今までどおり。
+  Migration: スキーマの形を広げたり選んだりしていたホストは、自分のスキーマを書く (詳細の型は `DailyReportDetail` ほか)。
+- **zod の peer の下限は 3.25.76**: peer の範囲は `>=3.25.76 <5.0.0` (パッケージは zod を `zod/v3` の入口からだけ読み、その入口を持つ版から)。
+  Migration: zod 3.25.76 以上 (zod 4 を含む) を入れる。
+- **サービスの数の設定は 1 以上の整数**: `idsTtlMs`・`businessDateTtlMs`・`streamMaxLen` は省いたときだけ既定値で、0・負の数・`NaN`・小数・2^53 以上は `createDailyReportService` と
+  `createDailyReportServer` で鍵を名乗る `RangeError` になる (`[daily-report] idsTtlMs must be an integer >= 1; got 0`)。以前はそのままキャッシュの TTL と Redis の MAXLEN へ渡った。
+  Migration: 3 つを 1 以上の整数で渡すか省く。
+- **大小文字によらず同じ区分の外部ソースは作成で止まる**: 2 つの外部ソースの `sourceType` が大小文字によらず同じ (同じ字面も) か、1 つが `Internal` と大小文字によらず同じなら、
+  `createDailyReportService` と `createDailyReportServer` は `RangeError` で止まる (`[daily-report] externalSources[1].sourceType must be a source type that differs, ignoring case, from …; got …`)。
+  以前は後の区分を絞り込みの候補から黙って落とした。Migration: 区分の名前を大小文字によらず別々にする。
+- **`DailyReportService` の 5 つの欄を外した**: `streamMaxLen` と、閲覧の範囲を当てない hub の部品 `findDailyReportHubById`・`updateDailyReportHub`・`updateDailyReportInternal`・`deleteDailyReportLabel` は無い。
+  Migration: ストリームの上限は自分の設定 (`streamMaxLen`) から読み、日報は公開のサービスの読み取りと書き込み (`getDailyReportDetailById`・`updateDailyReport` ほか) で扱う。
+- **SSE のエントリの区分と詳細の添付の欄は必須**: SSE のメッセージのスキーマは `comment-add`・`comment-delete`・`report-delete` の `sourceType` (文字) を求め、詳細の読み手は `attachments` と
+  添付の `hasThumbnail` を既定値で補わない (欠ければ合わない値)。版を焼き込んだストリームのキー (`<streamKey>:v3`) の前の形のエントリは読まれない。
+  Migration: 自分でエントリを書くホスト (結合試験など) は、3 つの知らせに日報の `sourceType` を、詳細に `attachments` と添付ごとの `hasThumbnail` を書く。
+- **`forEachIdsStreamRow` は厳格な読み手が受けた列だけを受ける**: 引数は `DailyReportIdsStreamRows` (`readIdsStreamChunkLine` の答えの `rows`) で、`encodeIdsStreamRows` の出力や
+  手で組んだ列 (`DailyReportIdsStreamRowColumns`) は型検査で渡せない。Migration: 行は `readIdsStreamChunkLine(line)` で読み、受けた答えの `rows` をたどる。
+- **ids のストリームのクライアントのクラスを公開しない**: client エントリの `DailyReportIdsStreamClient` と `DailyReportIdsStreamClientOptions` は無い (ホストが作ると 2 本目のストリームを開く)。
+  Migration: 一覧全体は `readDailyReportIdsStreamRows()`、状態は `useDailyReportIdsStream()`、読み直しは `resyncDailyReportIdsStream()` で扱う。
+- **共有エントリはメッセージと詳細のスキーマを 1 つずつだけ公開する**: メッセージごとのスキーマ (`connectedMessageSchema`・`reportCreateMessageSchema`・`reportUpdateMessageSchema`・
+  `reportPublishMessageSchema`・`reportDeleteMessageSchema`・`statusUpdateMessageSchema`・`commentAddMessageSchema`・`commentDeleteMessageSchema`)・部品のスキーマ
+  (`dailyReportInterviewerSchema`・`dailyReportExternalCommentSchema`・`dailyReportLabelDefSchema`・`dailyReportPostedCommentSchema`)・`mergeComments`・`isDailyReportSseStreamId` は無い。
+  server エントリの `DailyReportHubRow` と `DailyReportInternalRow` も無い (公開のどの宣言も参照しない)。
+  Migration: メッセージは `dailyReportSseMessageSchema` で読んで `type` で分け、詳細は `dailyReportDetailSchema` で読む。コメントは `useDailyReportComments` が合わせた並びを読む。
+- **型の公開名はどれも `DailyReport` を名乗る**: server エントリの `ExternalReportFields`・`StreamEntry`・`SharpLike` は `DailyReportExternalReportFields`・`DailyReportSseStreamEntry`・`DailyReportSharpLike`、
+  client エントリの `SourceTypeConfig` は `DailyReportSourceTypeConfig`。Migration: 型の読み込みの名前を改める (別名は無い)。
+
 ## 0.40.0 (2026-10-09)
 
 ### Added