指示書BH — 清掃詳細ログとエラー一覧の並べ替え（2026-11-04）

担当: Cursor。監督（Claude Code）がレビューする。 前提: develop の 38e8f5d 以降（施設ロボットマスタの並べ替え＝先行例が入っている版）。 先行例: 38e8f5d — lib/facilities/query.ts（FACILITY_SORT_KEYS・parseFacilityQuery() の sort/order・sortFacilities()）、 components/features/facilities/FacilitiesScreen.tsx（nextSort()・sortableTh()・changeSort()）、d-watch-api.yaml の /facilities の sort/order。 ★作業の前に必ず読むこと★。この指示書は「同じ形を2画面に広げる」もので、★先行例と違うところ（§2-1 の表）★に特に注意すること。

0. ユーザーの指示（原文）

• 2026-11-04「詳細ログやエラー一覧も項目でソートできるようにしたいです」
• 監督の質問への回答（2026-11-04）:
  • 清掃詳細ログの列: 「機種は含めて、事前チェックは除く」
  • 施設名: 「施設名は外す」（エラー一覧についても確認し「外す（6列）」）
  • 1回目のクリックの向き: 「悪いほうが上」
  • エラー一覧の「紐づく予定」: 並べ替えではなく ★絞り込みのプルダウン★ にする（軽いほう）。選択肢は ★3つ（すべて／予定あり／予定外）★
  • プルダウンの先頭の表示: 「予定：すべて」（監督の問い「今のまま／先頭だけ欄の名前を入れる」に「後者」。2026-11-04）
• 監督が示し、ユーザーが異を唱えなかった既定（このまま実装する）:
  • 並べ替えはサーバー側で全件に対して行う（ページ送りの前）
  • 同じ値どうしは、今の並び順（既定順）に従う
  • 空の値（完了率「-」・機種/シリアルなし・備考なし）は、向きに関係なく下
  • 日付・検知時刻は「新しい順 ↔ 古い順」の2状態
  • 完了率は丸める前の値で比べる
  • 清掃詳細ログの CSV は画面と同じ並び順
  • ダッシュボードの縮小表示には並べ替えを付けない
  • エラー一覧の編集中は並べ替えのボタンを押せない。保存直後は行を動かさない

1. 並べ替えられる列（これ以外は今のまま。見出しはボタンにしない）

1-1. 清掃詳細ログ（7列）

• ★並べ替えない列★: 施設名（ユーザー指示）・予定（日付と同じ値。日付の見出しで並べる）・事前チェック1回目/2回目（ユーザー指示）
• ★日付は2状態★: 既定順が「新しい順」なので、日付の見出しは「既定（▼ 新しい順）↔ 古い順（▲）」を行き来する。 ★既定順のときは日付の見出しに ▼ を出す★（aria-sort="descending"）。他の列で並べているあいだは日付は ⇅（★§12 で薄い △ に変更★）
• 「下に固定する行」は ★asc でも desc でも一番下★（向きで反転させない）。固定する行どうしは既定順
• そろえは今の CleanLogTable.tsx の見出しの textAlign を変えない（実物で確かめること。上の表と違ったら実物が正）

1-2. エラー一覧（6列）

• ★並べ替えない列★: 施設名（ユーザー指示）・紐づく予定（→ §4 の絞り込み）・詳細（JP と EN で並びが変わるため）
• ★検知時刻は2状態★（清掃詳細ログの日付と同じ。既定順のとき ▼）
• ★レベルは文字の順★。重大度の順位表を作らないこと（D-077: 値を解釈しない）。今の3つの値では文字の順が重大度の順と一致するだけ
• 見出しのそろえは6列とも左（今のまま）

1-3. 見出しの切り替え（両画面共通）

• ★1回目は必ず asc★（ユーザー指示「悪いほうが上」。完了率・判定・出発・清掃結果・対応状況は「asc ＝ 悪いほう」になるよう §2 で定義してある）。 ★施設ロボットマスタは今のまま（1回目 desc ＝ ○ が上）★ — 切り替えの部品を共通にしても、施設マスタの動きは変えない
• 印: asc ＝ ▲、desc ＝ ▼、並べていない列 ＝ 薄い ⇅（施設マスタと同じ）。★§12 で変更: 並べていない列は薄い △、印の色は白（ダーク）★
• 並べ替えを変えたら ★同じ操作の中で setPage(1)★（useEffect で後追いしない）。queryString の useMemo の依存に sort を入れる
• 並べ替えの状態は URL に載せない（再読み込みで既定に戻ってよい。今の絞り込みと同じ）

2. 並べ方の定義（API）

2-1. 共通の規則

• 比較は「主キーの比較 → 同じなら既定順の比較」。★desc は主キーの比較だけを反転する★。 ★asc の結果を reverse() して desc を作らないこと★（同じ値の中まで逆になる。lib/facilities/query.ts の sortFacilities() の注記と同じ）
• 「下に固定する行」は主キーの比較より前に分ける（向きの反転の外）。固定する行どうしは既定順
• 既定順:
  • 清掃詳細ログ ＝ compareCleanLogItems()（lib/db/clean-log-mapping.ts:394）
  • エラー一覧 ＝ compareErrorReportKeys()（lib/error-reports/query.ts:134）
• ★文字の比較は両画面とも < / >（コードポイント順）★。localeCompare を使わない（lib/masters/query.ts:62-66 の方針。実行環境で順が変わる）。大文字小文字は区別する
• 完了率は ★生値★ で比べる（CLAUDE.md §4.3。89.5 / 90.0 / 90.1 は表示がどれも 90% だが、生値で比べて別の順位になる）

★★先行例（施設マスタ）と違うところ — ここを写し間違えると既定順が壊れる★★

2-2. 清掃詳細ログの順位

• 出発: ✗（departed false かつ result_pending false）＝ 0、✓ ＝ 1。asc ＝ ✗ が上。結果待ち（result_pending true）は下に固定
• 判定: × ＝ 1、△ ＝ 2、○ ＝ 3、◎ ＝ 4。asc ＝ × が上。結果待ちは下に固定（grade は "×" のままなので ★result_pending を先に見る★）
• 清掃結果（task_status）。asc ＝ 順位の小さい順。結果待ちは下に固定:| 順位 | 行 | |---|---| | 1 | 出発失敗（task_status が null で結果待ちでない） | | 2 | 5 清掃異常終了 | | 3 | 2 清掃中断 | | 4 | 3 と 6 清掃キャンセル（★同じ順位★。表示名が同じため） | | 5 | 表に無い値（「不明(n)」。7 以上・負の値など） | | 6 | 0 清掃開始前 | | 7 | 1 清掃中 | | 8 | 4 清掃正常終了 |★この順位表は lib/config/index.ts の CLEAN_TASK_STATUS_LABELS の隣に定数で置く★（CLEAN_TASK_STATUS_SORT_RANK など）。 コードに数字を直書きしない。判定（◎○△×）には使わない（表示の並びだけ）
• 完了率: completion_rate の生値。null（出発失敗）は下に固定、結果待ちはさらにその下
• 機種・シリアル: 文字の比較。null は下に固定
• 日付: scheduled_at（予定外の行は started_at が入っている。今の既定順と同じ値）。Date.parse の差で比べる

2-3. エラー一覧の順位

• 対応状況: DB の status（0 未解消 / 1 対応中 / 2 解消）の数値。asc ＝ 未解消が上
• 備考: 前後の空白を除いた文字列。空なら下に固定
• 検知時刻・シリアル・種類・レベル: §1-2 の表のとおり

3. 期待値表（★監督が確定。テストはこれをそのまま使う。数字・順番を変えないこと★）

表S1 — 清掃詳細ログ（sortCleanLogs() の純粋関数のテスト。行は CleanLogItem としてテストの中で作る。置き場所 lib/clean-logs/__tests__/sort.test.ts）

• R5 は予定外（unscheduled true・id null・report_id あり）。ほかは予定のある行（unscheduled false）
• 既定順（compareCleanLogItems()）: R4, R1, R2, R5, R3, R8, R6, R7

• S1-6 の × の中（R5・R3）と ◎ の中（R1・R7）は既定順のまま
• S1-4 で 89.5（R6）と 90.0（R7）が別の位置になる（表示は両方 90%）
• （S1-3 は欠番。scheduled_at desc はパースで null に畳むので §表S2 の S2-7 で見る）

表S2 — 清掃詳細ログのクエリとルート

表E1 — エラー一覧（filterSortErrorReportKeys() の純粋関数のテスト。include_resolved true）

★行は ErrorReportKeySource（DB の行の形。clean_timetable_id は BigInt(501) / BigInt(CLEAN_TIMETABLE_ID_UNSCHEDULED) / null）で作り、 ★errorReportKeyFromRow() を通してから★ filterSortErrorReportKeys() に渡す（0 と NULL がどちらも予定外になることを、キーを手で作らずに確かめるため）。 置き場所は lib/error-reports/__tests__/query.test.ts の新しい describe。既存の表1 の定数（E1〜E9 など）とぶつからない名前にする（例: BH_E1）。

既定順（compareErrorReportKeys()）: E-1, E-2, E-3, E-10, E-4, E-5（同じ 11-02 22:00 は "E-10" < "E-4"）

表E2 — エラー一覧のクエリ（parseErrorReportQuery()）

4. エラー一覧の「紐づく予定」の絞り込み（プルダウン）

• クエリパラメータ schedule: scheduled（予定あり）/ unscheduled（予定外）。省略 ＝ すべて
• ★判定は scheduledTimetableId()（lib/db/timetable-link.ts:20）の1本★。clean_timetable_id が 0 か NULL なら予定外（CLAUDE.md §4.7）。 ★=== null / { not: null } / === 0 を直書きしない★
• 「予定あり」には、本清掃・事前チェック・予定不明（予定の表に id が見つからない）の行がすべて入る（★予定の表は引かない★。軽くするための決定）。 つまり ★unscheduled ＝ 「紐づく予定」が「予定なし」（schedule_link: "none"）の行、scheduled ＝ それ以外★
• 絞り込みはアプリ側（filterSortErrorReportKeys()）で行う。meta.total は絞り込み後の件数
  • ★SQL の where に降ろさないこと★ — errorReportListWhere() は期間で既に OR を使っており、もう1つの OR を足すと条件が上書きされる事故が起きやすい。 1段目は今も条件に合う全件のキーを読んでいるので、アプリで振り分けても読む量は増えない
• 画面: 絞り込み欄（<fieldset> の中）に <select> を足す。aria-label・title は「紐づく予定」。 選択肢は ★「予定：すべて」（値は空＝送らない）「予定あり」「予定外」★（★文言はユーザー指示。変えない★。先頭だけ欄の名前を入れるのは、ほかのプルダウンと並んだときに何の欄か分かるように）
  • ★幅は固定★（既存の絞り込みの <select> と同じく styles.select ＋ 固定幅のクラス。いちばん長い表示（EN の "Schedule: All" か "Unscheduled"）と ▼ が収まる幅。JP/EN の切り替えでツールバーが動かないように。D-162）
  • 置く位置は「解消済みも表示」のチェックの左
  • 英訳: 「紐づく予定」"Schedule"（既存）、「予定外」"Unscheduled"（既存）、★「予定：すべて」"Schedule: All"・「予定あり」"Scheduled" を lib/i18n.ts に足す★（既にあるキーは足さない）
  • 変えたら setPage(1)（期間の入力と同じ書き方）。<fieldset disabled> の中なので編集中は自動で押せなくなる
• D-Sec アラート（lib/ds-alerts/query.ts の sortDsAlerts()）には関係させない

5. 実装の置き場所と変更点（★全件。漏らさないこと★）

段階1 — API 契約（★先に直す。CLAUDE.md §6-1★）

• d-watch-api.yaml
  • /clean-logs と /clean-logs/export: sort（enum 7値。★default は書かない★。説明に「省略時は既定順」）・order（enum [asc, desc]・default: asc。説明に「施設マスタ（desc）と違い、1回目は悪いほうが上のため asc」「sort が省略でも検証するが並びには効かない」「sort=scheduled_at&order=desc は既定順と同じ」）。 §1-1・§2-2 の定義、「並べ替えは絞り込みのあと・ページングの前」「同じ値は既定順」「下に固定する行」を説明に書く。422 の説明に sort/order を足す。 既定順の記述（:494 付近と CleanLogItem の説明 :2239 付近）は「sort を省略したとき」と書き足す
  • /errors: sort（enum 6値。default なし）・order（/clean-logs と同じ）・schedule（enum [scheduled, unscheduled]。説明: unscheduled ＝ schedule_link が none の行、scheduled ＝ main / precheck / unknown の行。予定の表は引かない）。 ★:909-910 の「ソート指定のクエリパラメータは無い」を書き換える★。422 の説明に sort/order/schedule を足す。sort=detected_at&order=desc は既定順と同じ、と書く

段階2 — 共通の部品

• lib/table-sort.ts（新規。純粋関数）
  • 型 TableSortOrder = "asc" | "desc"、SortState<K> = { key: K; order: TableSortOrder } | null
  • nextSortState(current, key, { first, twoState }) — §1-3 の表をそのまま実装。first は "asc" か "desc"（施設マスタは "desc"）
  • displayOrder(state, key, defaultKey?) — 見出しに出す向き。state が null で key === defaultKey なら "desc"（既定順のとき日付・検知時刻に ▼）、 state があれば state.key === key ? state.order : null、それ以外は null。施設マスタは defaultKey を渡さない（今のまま）
  • テスト lib/__tests__/table-sort.test.ts:
    • nextSortState: §1-3 の5行 ＋ 施設マスタの動き（first: "desc": 既定 → desc → asc → 既定）
    • displayOrder: 「null・日付 → desc」「null・他の列 → null」「{日付, asc}・日付 → asc」「{完了率, asc}・日付 → null」「null・defaultKey なし → null」
• components/ui/SortableTh.tsx（新規）
  • <th aria-sort> の中に <button type="button">。props: 見出しの文字、order（displayOrder() の値）、onClick、disabled、ariaLabel（「○○で並べ替え」）、 ★align: "left" | "center" | "right"★（th の text-align とボタンの justify-content に反映。今の見出しのそろえを変えないため）、 ★children★（見出しの中に並べ替え以外のボタンを置く。清掃詳細ログの「判定」の「?」）
  • ★ボタンの中にボタンを入れない（HTML として不正）★。children があるときは、ボタンを width: auto にして、th の中でボタンと children を inline-flex で1行に並べる （width: 100% のままだと「?」が押し出されて、折り返さない見出しからはみ出す）
  • 印は aria-hidden。CSS は施設マスタの .thSortable 系（FacilitiesScreen.module.css:135-166 付近）を components/ui/SortableTh.module.css に移し、そろえを props で変えられるようにする
• components/features/facilities/FacilitiesScreen.tsx と .module.css: 上の部品を使うように置き換える（align="center"・first: "desc"）。★動きも見た目も1つも変えない★。 置き換えたら施設マスタの画面で ▼ → ▲ → 既定 を確かめる

段階3 — 清掃詳細ログの API

• lib/types/index.ts: CleanLogSortKey（7値）を足す
• lib/clean-logs/query.ts: ★既存の CleanLogQuery（:15。parseCleanLogQuery() が返す QueryParseResult<CleanLogQuery> の query）★ に sort: CleanLogSortKey | null・order: TableSortOrder を足す（★lib/types に同じ名前の型を作らない★）。 parseCleanLogQuery() に検証（表S2）。受け付ける値は配列1か所（CLEAN_LOG_SORT_KEYS）。2状態の列の desc は sort: null に畳む
  • ★今の result パラメータは空文字で 422 になる（:122-127）が、新しい sort/order は施設マスタに合わせて空文字 ＝ 省略★。result の挙動は変えない
• lib/clean-logs/sort.ts（新規）: sortCleanLogs(items, sort, order)。表S1 のテストを lib/clean-logs/__tests__/sort.test.ts に
  • ★sort が null なら並べ替えず [...items] を返す★
  • ★filterCleanLogs() の中に入れないこと★（lib/clean-logs/__tests__/query.test.ts が「入力の順を保つ」ことに依存している）
  • ★データ層（db.cleanLogs()・compareCleanLogItems()）の既定順を変えないこと★ — ダッシュボードの problem_logs（先頭5件）がこの順に依存している（app/api/dashboard/route.ts）
• lib/config/index.ts: 清掃結果の順位表（§2-2）
• app/api/clean-logs/route.ts: filterCleanLogs() のあと、slice() の前に sortCleanLogs()。capCleanLogs() の位置は今のまま。 ルート冒頭の手順コメントに「並べ替え（sortCleanLogs()。sort 省略時は並べ替えない）」を足す。capCleanLogs() の docstring に「filterCleanLogs() → sortCleanLogs() → ページ切り出しの後」と書き足す
• app/api/clean-logs/export/route.ts: ★行数の上限の判定（filtered.length > MAX_CSV_ROWS の 422。:79 付近）の後、buildCleanLogCsv() の直前★に sortCleanLogs() （★入れ忘れると CSV だけ黙って既定順になる★。上限の判定より前に置くと、どうせ 422 で捨てる大量の行まで並べ替えることになる）
• ついでに直す古いコメント（「表に無い値（6 など）は数字のまま」→ 今は 6 は清掃キャンセル、7 以上は「不明(7)」）: lib/clean-logs/csv.ts:43 付近・lib/types/index.ts:316 付近・lib/i18n.ts:225 付近

段階4 — 清掃詳細ログの画面

• components/features/detail-log/DetailLogScreen.tsx: sort の状態（SortState<CleanLogSortKey>）。queryString に sort・order を載せる（既定のときは送らない）。 CSV のリンクは同じ queryString を使っているので自動で揃う（★揃っていることを確かめる★）。並べ替えを変えたら setPage(1)
• components/features/detail-log/CleanLogTable.tsx: props sort?: SortState<CleanLogSortKey> と onSort?: (key: CleanLogSortKey) => void を足す（★省略可能★）。 onSort が渡されたときだけ7列の見出しを SortableTh にする（向きは displayOrder(sort, key, "scheduled_at")）。 ★ダッシュボード（compact）は渡さない → 今のまま★。「判定」の見出しの「?」ボタンは SortableTh の children に入れる
• 列幅: table-layout: fixed・見出しは折り返さない。★印を足すと EN で見出しがはみ出す列がある★（出発 56px・日付 64px・完了率・清掃結果・判定など。事前調査の計算）。 並べ替える列の見出しの左右の余白を詰める（施設マスタは 12px → 6px）。★列の合計幅（最小 1134px）を広げないで収める★。収まらない列があれば監督に報告

段階5 — エラー一覧の API

• lib/db/robot-error-select.ts の ROBOT_ERROR_LIST_KEY_SELECT（1段目）に serial_number・error_level・comment を足す（clean_timetable_id は既にある）。 ★robot_id / robot は足さない★（robot-error-select.test.ts が見張っている）。 :69-71 付近のコメント「clean_timetable_id は並べ替えには使わない」を「予定あり／予定外の絞り込みに使う。serial_number・error_level・comment は並べ替えに使う」に直す
• lib/db/error-report-mapping.ts（★入力と出力で足すものが違う★）:
  • ErrorReportKeySource（DB の列名）に clean_timetable_id: bigint | null・serial_number: string・error_level: string・comment: string | null
  • ErrorReportKey に serial_number・error_level・note: string | null（comment の生値。空かどうかは並べ替えの側で trim して決める）・scheduled: boolean（scheduledTimetableId(row.clean_timetable_id) !== null）
  • errorReportKeyFromRow() で詰め替える
• lib/types/index.ts: ErrorReportSortKey（6値）・ErrorScheduleFilter（"scheduled" | "unscheduled"）を足す。 ★ErrorReportDbQuery（:807 付近。「引数は必須」の作法 :802）★ に sort: ErrorReportSortKey | null・order: TableSortOrder・schedule: ErrorScheduleFilter | null を足し、 :802-806 の docstring に「sort・order・schedule もアプリ側で処理する」と書き足す
• lib/error-reports/query.ts: ★既存の ErrorReportQuery（:19。camelCase）★ にも同じ3つを足す（★lib/types に同じ名前の型を作らない★）。 parseErrorReportQuery() に検証（表E2）。filterSortErrorReportKeys() に schedule の絞り込み（key.scheduled を見る）と sort/order の並べ替え（表E1）。 compareErrorReportKeys() は既定順としてそのまま残す
• lib/db/index.ts の errorReports()（Prisma 版 :1853 付近・fixtures 版 :715 付近）: 新しいフィールドを filterSortErrorReportKeys() に渡すだけ。2段目は変えない
• app/api/errors/route.ts: パース結果（camelCase）を ErrorReportDbQuery に詰め替えて渡す

段階6 — エラー一覧の画面

• components/features/errors/ErrorsScreen.tsx: sort の状態と §4 のプルダウン。queryString（:258-276 付近）に sort・order・schedule を載せる
  • 6列の見出しを SortableTh（align="left"。向きは displayOrder(sort, key, "detected_at")）に。 ★disabled={editing}★（見出しは <fieldset> の外なので、明示しないと編集中も押せてしまう。押すと別ページの下書きが保存されずに消える — lib/errors/edit-drafts.ts）
  • ★保存後は取り直さない（今のまま）★。並べている列の値を変えた行は、次に読み込むまで今の位置に残る（「解消にしても次に取り直すまで消さない」:374 と同じ考え方）
  • 列数 COLUMN_COUNT（:71）と <colgroup> は変わらない
• 列幅: 「DETECTED AT」は約113px で列は 120px。印を足すとはみ出す。段階4 と同じく余白を詰めて収める

段階4・6 共通 — lib/i18n.ts

• 並べ替えボタンの aria-label の英訳（「機種で並べ替え」"Sort by model" など）と §4 の2語。 ★両画面ぶんをまとめて1か所に足す。両画面に共通の「シリアルで並べ替え」は1回だけ。既にあるキーは足さない★（同じキーを2回書くと tsc エラーになる）

6. 既存テストの扱い

• ★新しい必須フィールド（sort・order・schedule、キーの serial_number など）を足したために、型エラーや toEqual の形の違いで壊れたテストは、 既定値（sort: null, order: "asc", schedule: null、行の新しい列）を足すだけなら直してよい★。★並び・件数・where の期待値は変えない★
• 分かっているもの（行番号は目安）:
  • lib/db/__tests__/fixture-clean-logs.test.ts:20-34 の memoryQuery()
  • lib/error-reports/__tests__/query.test.ts の key() ヘルパー（:30-40）・base（:55-63）・parse("") の toEqual（:207-221）。★表1（:70-166。監督確定）の期待値は変えない★
  • lib/db/__tests__/fixture-error-reports.test.ts の BASE
  • lib/db/__tests__/error-report-mapping.test.ts:390-399・:407-416・:440-448（キーと元の行の形）
  • app/api/errors/__tests__/route.test.ts:557-575（パース結果・1段目の select が定数と一致）
• ★並び順を固定しているテストは変わらないはず★: app/api/clean-logs/__tests__/route.test.ts（:418 など）・lib/db/__tests__/unscheduled-clean-log.test.ts:190-224・ lib/db/__tests__/fixture-clean-logs.test.ts:212-229・lib/db/__tests__/fixture-error-reports.test.ts:161-191。★変わったら実装の誤り★
• 既定値を足すだけでは直らないテストが出たら、直さずに監督に報告する

7. 既知の罠

1. ★fixtures 版と Prisma 版で、同じ時刻の行の既定順が違う★（fixtures 版は scheduled_at だけで並べ直すため。lib/db/index.ts:631-633）。 新しい並べ替えは「同じ値なら compareCleanLogItems()」なので、sort を指定したときは両方で同じになる。★既定順（省略時）の食い違いは今回直さない★（ダッシュボード・既存テストに波及するため）。 だから ★sort が null のときは並べ替え関数が何もしない★（§2-1 の表）。fixtures の画面で既定順の同時刻の並びが Prisma の規則と違って見えても、それは今回の不具合ではない
2. 結果待ちは要求ごとの「今」で決まるので、同じ並べ替えでも時間がたつと行が動く（仕様どおり）
3. grade は結果待ちでも "×"。★result_pending を先に見る★
4. 予定外の行の id は null。並べ替えの比較で id を使わない（既定順に任せる）
5. task_status の 3 と 6 は同じ順位。6 を「キャンセル」と別扱いにしない
6. 古い応答を捨てる仕組み（cancelled / result.query !== queryString）は、並べ替えを queryString に載せれば自動で効く。★別の取得経路を作らない★
7. エラー一覧の 1段目に comment（TEXT）が増えるので転送量が少し増える（P1 の件数なら問題ない。D-160 追記2「解消済みも表示の全件読みはリリース前に見直す」の範囲）
8. 清掃詳細ログは読み込み中に表ごと消える作りなので、見出しを押すとフォーカスが外れる（施設マスタも同じ。今回は直さない）

8. 画面で確かめること（fixtures）

★確かめ方★: USE_FIXTURES=true npm run build → USE_FIXTURES=true npx next start -p 3100 で開く（★:3000 のサーバーは触らない★）。終わったら :3100 を止める。

• 清掃詳細ログ: 7列それぞれ ▲ → ▼ → 既定（日付は ▲ ↔ 既定。既定のとき日付に ▼）。並べたまま CSV を出し、CSV の行の順が画面と同じ。2ページ目にも並べ替えが効く。 ★見出しのそろえ（左・中央・右）が今と変わっていない★。「判定」の「?」が押せて、見出しからはみ出さない。 ダッシュボードの縮小表示の見出しが押せないこと。JP/EN 切り替えで見出しが1行に収まり、列からはみ出さない（th.scrollWidth <= th.clientWidth）
• エラー一覧: 6列それぞれ同じ確認。編集中に見出しが押せない。 プルダウンで「予定外」→ ★予定外の行（fixtures の FX-ERR-04・FX-ERR-12（どちらも NULL）・FX-ERR-20（0）の3行）だけ★になり、件数も変わる。JP/EN で見出しとプルダウンの幅が動かない
• 施設ロボットマスタ: 今までどおり ▼ → ▲ → 既定、見た目も同じ

9. 共通ルール

• 期待値表（§3）を先にテストにする。数字・順番を変えない。合わないと思ったら実装を変えずに監督に報告
• git add -A 禁止。★コミットはしない（監督がまとめてコミットする）★
• 触らない: docs/decisions.md・docs/handoff/指示書AY_*・docs/handoff/設計_制御盤ログの取り出し_*・components/features/errors/ErrorContentPicker.tsx・lib/errors/error-content-label.ts とそのテスト・prisma/
• DB に書き込まない。サーバー（:3000）を止めない
• 完了したら tsc・lint（触ったファイル）・vitest 全件の件数と、段階ごとの変更ファイルを報告する

10. 決定の記録（監督が docs/decisions.md に後で書く。Cursor は書かない）

• 並べ替える列（清掃詳細ログ7列・エラー一覧6列）と、施設名・事前チェック・紐づく予定・詳細を外した理由
• 1回目は asc（悪いほうが上）。施設マスタは 1回目 desc のまま
• sort 省略は null。2状態の列の desc は null に畳む。sort が null なら並べ替えない（fixtures の既定順を変えないため）
• 清掃結果の順位表（§2-2）は監督の案（表示の並びだけ。判定には使わない）
• 「紐づく予定」は並べ替えではなく3択の絞り込み（予定の表を引かないので軽い）。先頭の表示は「予定：すべて」（ユーザー回答「後者」）
• 点検（2026-11-04）: 4観点のレビューで38件の指摘、35件を反映（棄却3件: 固定行どうしの順の追加行・読み込み中のフォーカス・行番号の1行ずれ）

11. 追補 — 実装のレビュー指摘（2026-11-04。Cursor の1回目の実装に対して）

監督の確認結果: tsc・lint・vitest 全件（154ファイル・3778件）は通過。fixtures の画面（:3100）で §8 の確認はほぼ通った（並びの切り替え・▼▲⇅・CSV のリンク・ダッシュボードに出ない・「予定外」で3件・編集中に押せない・施設マスタは今までどおり・JP/EN ではみ出さない）。 4観点のコードレビューで27件の指摘、検証して21件が本物（重複・指示書どおり・範囲外の6件は棄却）。★下の全件を直すこと★。直したら §8 をもう一度通し、tsc・lint・vitest 全件の件数を報告する。

11-1. 必ず直す（画面が崩れている）

• R1（high）components/ui/SortableTh.module.css・SortableTh.tsx: children があるとき（清掃詳細ログの「判定」だけ）、.thSortableWithChildren { display: inline-flex } が ★<th> そのもの★ に付いている。 監督が画面で実測: 「判定」の th が display: inline-flex になり、幅 69px（列は 96px）。th が表のセルでなくなり、見出しの下線が列の一部にしか引かれない。 → th には display を付けない。children があるときだけ th の中に <span className={styles.thInner}>（display: inline-flex; align-items: center; gap: 2px; max-width: 100%）を置き、その中にボタンと children を入れる。そろえは th の text-align に任せる。 直したら「判定」の th が display: table-cell・幅が列と同じ・中央そろえ・th.scrollWidth <= th.clientWidth を確かめる

11-2. 直す（仕様・契約・テストの縛り）

• R2（medium）lib/clean-logs/sort.ts:18-19: 清掃結果の順位の「出発失敗＝1」「表に無い値＝5」が数字の直書き（§2-2 違反）。 → lib/config/index.ts の CLEAN_TASK_STATUS_SORT_RANK の隣に CLEAN_TASK_STATUS_SORT_RANK_NOT_DEPARTED = 1・CLEAN_TASK_STATUS_SORT_RANK_UNKNOWN = 5 を置き（または1つのオブジェクトにまとめ）、sort.ts はそれを読む。docstring に 1〜8 の表を全部書く
• R3（medium）lib/clean-logs/__tests__/sort.test.ts: 順位の 0（清掃開始前＝6）・1（清掃中＝7）・負の値（不明＝5）を縛るテストが無い。 → 表S1 は変えずに別の it を足す。task_status = 0, 1, 2, 3, 4, 5, 6, 7, -1, null と結果待ちの行を、わざと既定順と違う順で渡し、 asc: null → 5 → 2 → {3, 6} → {7, -1} → 0 → 1 → 4 → 結果待ち、desc: 4 → 1 → 0 → {7, -1} → {3, 6} → 2 → 5 → null → 結果待ち（{} の中は既定順のまま。desc でも逆にならない）
• R4（medium）lib/error-reports/__tests__/query.test.ts:474 付近: 表E1 の入力 BH_KEYS が既定順と同じ並びなので「同じ値どうしは既定順」を確かめられていない。 → 入力を既定順と違う順（例 [BH_E5, BH_E4, BH_E10, BH_E3, BH_E2, BH_E1]）にして E1-1〜E1-17 すべてに渡す。★期待値（表E1）は変えない★
• R5（medium）app/api/errors/__tests__/route.test.ts・lib/db/__tests__/fixture-error-reports.test.ts: ルート → データ層まで sort・order・schedule が届くことを確かめるテストが無い（既定値を足しただけ）。 → route.test.ts に include_resolved=true&schedule=unscheduled&sort=serial_number&order=desc のリクエストを1件（データ層に届いた query か items の順と meta.total）、sort=facility_name の 422 を1件。 fixture-error-reports.test.ts に db.errorReports({ ...BASE, include_resolved: true, schedule: "unscheduled" }) → FX-ERR-04・FX-ERR-12・FX-ERR-20 の3件
• R6（medium）d-watch-api.yaml の /clean-logs の sort（:552 付近）: 清掃結果の順位表が書かれていない（「悪い順↔良い順」だけ）。 → task_status の行に「出発失敗 → 5 清掃異常終了 → 2 清掃中断 → 3・6 清掃キャンセル（同じ順位）→ 表に無い値（不明(n)）→ 0 清掃開始前 → 1 清掃中 → 4 清掃正常終了。表示の並びだけで判定には使わない」。grade の行に「結果待ちは grade が × でも下に固定」
• R7（medium）d-watch-api.yaml の /clean-logs/export の 422（:645 付近）: sort/order の不正値が書かれていない。 → 「sort/order の不正値（details はパラメータ名と受け付ける値の一覧。/clean-logs と同じ形）」を足し、行数超過の { total, max } と形が違うことも並べて書く
• R8（low）d-watch-api.yaml の /errors の schedule（:1029 付近）: 「空文字・空白だけは省略と同じ（すべて）」を足す
• R9（low）d-watch-api.yaml:497・:961 付近: 「§下の」は意味が通らない → 「下のパラメータ sort / order の説明に従う」に直す
• R10（low）app/api/clean-logs/__tests__/sort-route.test.ts:30-32: result=all で8行を全部通しているので「meta.total は絞り込み後の件数」を縛れていない。 → 8行より少なくなる絞り込み（例 result=problem）と sort=grade&order=asc&per_page=2&page=2 のケースを足す
• R11（low）lib/clean-logs/__tests__/query.test.ts:662-674・lib/error-reports/__tests__/query.test.ts:363 付近: 422 の行が ok === false しか見ていない。 → S2-5・S2-6・E2-4・E2-5 に expect(parsed.status).toBe(422)。E2-6 で sort/order/schedule それぞれの details の形（キーがパラメータ名・中身が受け付ける値の一覧）。order=・order=%20・sort=%20 が省略と同じになるケース
• R12（low）lib/__tests__/table-sort.test.ts: §1-3 の2つの遷移が縛られていない。 → nextSortState({key:"grade",order:"desc"}, "scheduled_at", {first:"asc",twoState:true}) → {scheduled_at, asc}、 nextSortState({key:"monitoring",order:"asc"}, "d_security", {first:"desc",twoState:false}) → {d_security, desc} の2件
• R13（low）lib/clean-logs/__tests__/sort.test.ts と bh-s1-fixture.ts: 表S1 の8行が2か所に書かれている。 → sort.test.ts も bhS1RowsDefaultOrder() を import して使う（const [R4, R1, R2, R5, R3, R8, R6, R7] = bhS1RowsDefaultOrder();）。期待値は変えない
• R14（low）app/api/clean-logs/export/__tests__/route.test.ts:151: it() の中の await import() はこのファイルの作法（冒頭 :3-7）違反 → ファイル冒頭で静的に import する

11-3. 直す（書き方・コメント）

• R15（low）lib/clean-logs/sort.ts:72-103・lib/error-reports/query.ts:110 付近: (1) completion_rate の分岐の意味の無い if (aTier !== 0) return null; を消す。 (2) 両方 null の行どうしは、主キーの比較の前に明示的に 0 を返す（null < null や null - null に頼らない）。 (3) switch の default を { const _exhaustive: never = sort; return _exhaustive; } にする（キーを足して case を書き忘れたら tsc が止める）。sort.ts の2つと error-reports の1つ。 (4) コメントを足す: 結果待ちを先に見る理由（罠3: grade は "×" のまま）、desc は主キーだけ反転し reverse しない（§2-1）、完了率の固定行の段（0/1/2）の意味
• R16（low）docstring: app/api/clean-logs/export/route.ts の冒頭に「sort/order も受け付け、CSV は画面と同じ並び」。sortCleanLogs() の直前に「上限の判定の後（捨てる行を並べ替えない）・入れ忘れると CSV だけ既定順」。 parseCleanLogQuery()・parseErrorReportQuery() の docstring に「空文字・空白は省略と同じ／不正値は 422（入力値をエコーしない）／2状態の列の desc は sort null に畳む／sort が null でも order は検証する」。 ErrorReportQuery の3フィールドに JSDoc（「省略時 null（既定順）」「省略時 asc」「null = すべて」）
• R17（low）components/ui/SortableTh.module.css: 施設マスタから移したときに理由のコメントが落ちた。.sortButton・.sortMark・.thSortable の上に戻す — ★font: inherit を外さない（外すと日本語が中華字形に落ちる。CLAUDE.md §0-3）★・印の幅を固定する理由（⇅ と ▼▲ で文字が動かない）・余白 6px の理由。 CleanLogTable.module.css:15 付近と ErrorsScreen.module.css:252 付近の列幅の説明に「並べ替える見出しは SortableTh（左右 6px＋間隔 3px＋印 9px）」を1行足す
• R18（low）押せないボタンの見た目（監督の判断）: .sortButton:hover .sortMark { opacity: 1 } を .sortButton:hover:not(:disabled) .sortMark にする（押せないのに濃くならないように）。 ★編集中に並べ替える6列の見出しの文字だけが薄くなり、ほかの3列と濃さがまだらになる★ → ★見出しの文字は薄くしない★。押せないときは印（⇅▲▼）だけを薄くし、カーソルを default にする

11-4. 棄却した指摘（直さない）

• 並べ替える見出しの余白 6px で、左・右そろえの列の文字が下のセルより 6px 外にずれる → §5 段階4 の指示どおり（承知のうえ）
• 重複4件（th の inline-flex・await import・表S1 の2か所・CSS コメント）→ R1・R14・R13・R17 にまとめた
• d-watch-api.yaml が js-yaml で読み込めない（bad indentation）→ ★今回の変更より前（HEAD 38e8f5d）からある★。範囲外。別の作業として監督が扱う

12. 追補2 — 並べ替えの印を白に・清掃詳細ログにも「予定あり／予定外」の絞り込み（2026-11-04）

§11 の修正は監督が確認済み（tsc・lint・vitest 154ファイル・3788件が通過、fixtures の画面で §8 を再確認）。その上に次の2つを足す。

12-0. ユーザーの指示（原文）と回答

• 「並び替えのアイコンがわかりにくいので白い△で表示してください」
  • 監督の問い「白い△はどれか」への回答: ★「塗りのまま色だけ白」★ — 並べていない列は薄い △、昇順 ▲・降順 ▼ は塗りのまま白
• 「詳細ログもエラー一覧と同じで予定外・予定ありでできるようにしてください」

12-1. 並べ替えの印（components/ui/SortableTh.*。3画面共通）

• ★色はトークン --sort-mark を新しく作る★（app/globals.css）:
  • ダーク（:root, [data-theme="dark"]）: ★#ffffff★（ユーザー指示の「白」）
  • ライト（[data-theme="light"]）: ★#1e293b（ライトの --tx と同じ値）★ — ライトの表の背景は --sf = #ffffff なので、白にすると印が背景に溶けて消える（コントラスト 1.0:1）。★監督の判断★
  • ★.sortMark に #fff を直書きしないこと★（ライトで消える）。テーマは data-theme 属性だけで切り替わる（prefers-color-scheme は使っていない）
• ★印の字のフォントをそろえる★: 今の ▲▼ は Geist Fallback（Arial）で描かれ、△ と ⇅ は Arial に無いので日本語フォント（Windows では Yu Gothic UI）で描かれる（監督が Windows のフォントの cmap で確認）。 このままだと並べていない △ と並べた ▲▼ で三角の大きさ・太さ・高さがそろわない。 → ★日本語フォントの並びを app/globals.css のトークンにして1か所にまとめる★（CLAUDE.md §0-3「globals.css のフォントスタックを正とする」。並びの写しを CSS モジュールに作らない）:
  • app/globals.css に、テーマのブロックとは別に :root { --font-ja: "Hiragino Sans", "Hiragino Kaku Gothic ProN", "Yu Gothic UI", "Yu Gothic", "Noto Sans JP", Meiryo, sans-serif; } を置く（フォントはテーマによらないので、ライトのブロックには書かない）
  • body の font-family を var(--font-geist-sans), var(--font-ja); にする（並びの中身は今と同じなので body の見た目は変わらない）。:55-57 のコメントは残す
  • SortableTh.module.css の .sortMark, .sortMarkActive に font-family: var(--font-ja); を付ける。理由をコメントに書く（▲▼ を Geist Fallback（Arial）ではなく △ と同じ日本語フォントで描かせるため。並びの正は globals.css の --font-ja）
  • ★日本語フォントを外さない・中国語フォントを足さない★（CLAUDE.md §0-3）
• ★幅 9px の箱（width: 9px・font-size: 9px・text-align: center）は残す★（印が変わっても見出しの文字が動かない）
• aria-sort・aria-label・title は変えない（印は aria-hidden）
• 詳細ログの行を開く印（CleanLogTable.tsx の chevron ▼▲。--tx-m・10px）は★変えない★
• コメントの ⇅ を直す: SortableTh.module.css（2か所）、lib/table-sort.ts:46（「▲▼⇅」→「▲▼△」）

承知のうえの点（直さない）:

• 施設マスタは1回目が desc なので、△（上向き）を押すと ▼ になる。詳細ログ・エラー一覧は △ → ▲
• 詳細ログの「判定」の見出しの印 △ は、判定バッジの △（同じ字 U+25B3）と同じ形になる（色と大きさで見分ける。ユーザーが選んだ形）

12-2. 清掃詳細ログの「予定あり／予定外」の絞り込み

エラー一覧（§4）と同じ3択を、清掃詳細ログの API・CSV・画面に足す。

意味（エラー一覧とは中身が違う。YAML にもそう書く）:

• unscheduled（予定外）＝ ★CleanLogItem.unscheduled が true の行★（予定外タスク。clean_task_reports.clean_timetable_id が 0 か NULL。判定はデータ層で scheduledTimetableId() 済み）
• scheduled（予定あり）＝ ★それ以外の行★（予定の表＝本清掃の行。レポートの無い未実施・結果待ちの行も入る）。★clean_timetable_id の値では決めない★ — clean_timetable_id が 0 以外なのに予定の表に無いレポートは、今までどおり一覧に出ない（予定ありにも予定外にも入らない。エラー一覧の「予定あり」はこの形も含むので、中身が違う）
• 省略・空文字・空白だけ ＝ すべて

共通にするもの（★1か所にまとめる★。2画面で規則がずれないように。既知の罠「表示と関門は同じ道具を通す」）:

• 新規 lib/api/schedule-filter.ts（lib/api/master-id.ts と同じ置き場所・同じ書き方の純粋関数）:
  • export const SCHEDULE_FILTERS = ["scheduled", "unscheduled"] as const（★この順★。details の文言に使う）
  • export function parseScheduleFilter(searchParams: URLSearchParams): QueryParseResult<ScheduleFilter | null> — searchParams.get("schedule")?.trim() || null。配列に無い値は fail(422, "validation_failed", "scheduleの値が不正です", { schedule: ["scheduled / unscheduled のいずれかを指定してください"] })。★入力値をエコーしない★。大文字小文字は区別する（Scheduled は 422）。 判定は今の lib/error-reports/query.ts:187 と同じく SCHEDULE_FILTERS.includes(raw as ScheduleFilter)（★キャストを外すと as const の配列では TS2345★）。 呼び出し側の受け方は parseMasterIdFilters() と同じ: const schedule = parseScheduleFilter(searchParams); if (!schedule.ok) return schedule;、戻り値の query には schedule: schedule.query
  • export function matchesScheduleFilter(isScheduled: boolean, filter: ScheduleFilter | null): boolean — filter === null なら true、"scheduled" なら isScheduled、"unscheduled" なら !isScheduled。switch に never の網羅チェック
  • ★引数は「予定あり＝true」で固定★。呼び出し側: エラー一覧は key.scheduled、清掃詳細ログは ★!r.unscheduled★（向きが逆。取り違えても型エラーにならないので、両方向をテストで縛る）
• lib/types/index.ts: ErrorScheduleFilter を ★ScheduleFilter★ に名前を変える（使っているのは lib/error-reports/query.ts・lib/types/index.ts・ErrorsScreen.tsx だけ。別名は残さない。★名前を変えたら同じ段階で3ファイルの参照も新しい名前に直す★）。注記を「GET /errors と GET /clean-logs・/clean-logs/export の schedule」に直す
• lib/error-reports/query.ts: ERROR_SCHEDULE_FILTERS（:36）は消し、:186-191 の検証を parseScheduleFilter() に（:218 は schedule: schedule.query）、:280-281 を matchesScheduleFilter(key.scheduled, query.schedule) に置き換える。 ★検証の順（sort → order → schedule）・message・details の形は変えない★ → エラー一覧の既存テスト（E2-1・E2-2・E2-5・E2-6、route.test.ts、fixture-error-reports.test.ts）は★1文字も変えずに通ること★
• 新規 components/ui/ScheduleFilterSelect.tsx: <select> と3つの選択肢・aria-label／title（「紐づく予定」）を持つ部品。 props は value: ScheduleFilter | null、onChange: (next: ScheduleFilter | null) => void、className: string（★CSS は持たない★。詳細ログの .select は余白 4px 8px、エラー一覧は 6px 10px と違うので、各画面の styles.select と固定幅のクラスを渡す）。 選択肢: 値 "" ＝「予定：すべて」、"scheduled" ＝「予定あり」、"unscheduled" ＝「予定外」（★文言は §4 のまま。変えない★）。t() の取り方は今の ErrorsScreen.tsx に合わせる
  • ErrorsScreen.tsx の今の <select>（:608-621 付近）をこの部品に置き換える（見た目・位置・<fieldset> の中は変えない）。画面ローカルの型 ScheduleFilterState は不要になれば消す

清掃詳細ログ側:

• lib/clean-logs/query.ts:
  • CleanLogQuery に schedule: ScheduleFilter | null（JSDoc「省略・空白は null＝すべて」）
  • parseCleanLogQuery(): ★sort・order の検証の後★に parseScheduleFilter()。失敗ならそれを返す。docstring に schedule を足す
  • filterCleanLogs(): if (!matchesScheduleFilter(!r.unscheduled, query.schedule)) return false;（機種・シリアルの後。result との AND）
  • ★CleanLogDbQuery（データ層）には足さない★（db.cleanLogs() はダッシュボードも使う。データ層で行を落とすとダッシュボードの数え方に波及する。絞り込みの正は filterCleanLogs()）。lib/types/index.ts の CleanLogDbQuery の「ここに入れないもの」に schedule を書き足す
• app/api/clean-logs/route.ts・export/route.ts: 本体は変えない（filterCleanLogs() を通るので一覧・meta.total・CSV・CSV の行数上限の判定のすべてに効く）。冒頭の手順コメントに「予定あり／予定外」を足す
• components/features/detail-log/DetailLogScreen.tsx:
  • state scheduleFilter: ScheduleFilter | null（既定 null）
  • queryString の useMemo で if (scheduleFilter) params.set("schedule", scheduleFilter)、★依存配列にも入れる★（入れ忘れると選んでも取り直さず、CSV のリンクも変わらない。例外は出ない）
  • ★置く位置: ツールバー左の結果ボタン「全件」の直後★（絞り込みのボタンと並べる。監督の判断。エラー一覧は文字入力の後）。 ★ツールバーは flex-wrap で、プルダウンを左右どちらに置いても1行の幅は同じだけ（約166px）増える★。ホールディングスのプルダウンが出るとき（fixtures でも出る）は、ビューポートがおよそ 1440px より狭いと右の組（施設名・機種・シリアル・CSV）が2行目の左端に落ちる（1366px では落ちる。変更前は1行）。 ★承知のうえ。CSS で1行に押し込まない（.toolbar の flex-wrap・幅・余白は変えない）★
  • className={${styles.select} ${styles.scheduleFilterSelect}}、変えたら★同じ操作の中で setPage(1)★（useEffect で後追いしない）
  • 並べ替えの状態と同じく URL には載せない
• DetailLogScreen.module.css: .scheduleFilterSelect（エラー一覧の .scheduleFilterSelect と同じ: 幅 160px 固定・overflow: hidden・text-overflow: ellipsis・white-space: nowrap）。JP/EN でツールバーが動かないこと（D-162）
• d-watch-api.yaml（★先に直す。CLAUDE.md §6-1★）:
  • /clean-logs の parameters（order の後、Page の前）と /clean-logs/export の parameters（order の後）に schedule（enum: [scheduled, unscheduled]、default は書かない）。説明: 上の「意味」・省略と空文字・空白だけはすべて・未知の値は 422
  • 両方の 422 の説明に「schedule の不正値（details はパラメータ名と受け付ける値の一覧。sort/order と同じ形）」
  • /errors の schedule の説明に「清掃詳細ログの schedule とは予定ありの中身が違う」と1行
• lib/i18n.ts: ★足すキーは無い★（「予定：すべて」「予定あり」「予定外」「紐づく予定」は既にある）

12-3. 期待値表（★監督が確定。テストはこれをそのまま使う★）

表P — parseScheduleFilter()（新規 lib/api/__tests__/schedule-filter.test.ts）と parseCleanLogQuery()（lib/clean-logs/__tests__/query.test.ts）

表M — matchesScheduleFilter()（同じテストファイル）

表F — GET /clean-logs（app/api/clean-logs/__tests__/sort-route.test.ts に足す。行は bhS1RowsDefaultOrder() の8行。予定外は rp-9001（×）の1行だけ）

• F-2・F-3・F-6 の「抜いた順」は、テストの中で schedule なしの応答から rp-9001 を filter して作ってよい（数字を手で書き写さない）。★件数（7・2）は直書きで縛る★

表X — GET /clean-logs/export（app/api/clean-logs/export/__tests__/route.test.ts に足す。同じ8行）

エラー一覧（回帰）: 既存のエラー一覧のテストは★変えずに★全部通ること。matchesScheduleFilter(key.scheduled, …) の向きは既存の fixture-error-reports.test.ts（FX-ERR-04・12・20 の3件）が縛っている

12-4. 既存テストの扱い

• lib/db/__tests__/fixture-clean-logs.test.ts:20-37 の memoryQuery() は CleanLogQuery の全フィールドを書いているので、schedule: null を足す（★入れ忘れると tsc と next build で落ちるうえ、vitest も落ちる★ — schedule が undefined だと matchesScheduleFilter() は filter === null を通らずに never の分岐へ入り、undefined（偽）を返す。そのため filterCleanLogs() が全行を落とし、#2（:52-69）の expect(sql).toEqual(memory) が赤になる。★段階4では query.ts の変更と同じ手順の中で足し、そのあとで vitest を回す★）
• それ以外の既存テストの期待値は変えない（schedule 省略＝すべてなので件数・並びは変わらない）。変えたくなったら実装を変えずに監督に報告

12-5. 既知の罠（§7 に追加）

1. ★向きが逆★: エラー一覧は key.scheduled（true＝予定あり）、清掃詳細ログは r.unscheduled（true＝予定外）。matchesScheduleFilter() には★必ず「予定あり＝true」を渡す★
2. schedule を result と同じ書き方（?? "all" で受ける）にすると schedule= が 422 になり、エラー一覧と規則が分かれる。parseScheduleFilter() だけを使う。清掃詳細ログ側は query.test.ts の表P（P-2・P-3・P-6）と表F の F-8 が縛る
3. fixtures の清掃詳細ログの予定外は2行だけ（rp-9200000000000000001＝施設1・◎、rp-9200000000000000002＝施設11・×・清掃キャンセル）。★画面の既定（△×のみ）で「予定外」を選ぶと1件★、「全件」で2件。1件しか出ないのは不具合ではない。★既定（△×のみ）は1ページしかないので、ページを戻す確認は「全件」で行う（12-6）★
4. ステージングでは清掃詳細ログ 636件のうち 596件が予定外、予定ありは 40件（2026-11-04 監督が API で数えた。先方投入のデータ。時間で変わる）。予定と実績がまだつながっていないため。「予定あり」が少ないのは不具合ではない
5. △ を描く日本語フォントが無い環境では sans-serif に落ちる。印も body も同じ --font-ja（日本語フォントを先に）を使うので、中国語フォントには落ちにくい。★--font-ja の並びを短くしない・CSS モジュールに写しを作らない★

12-6. 画面で確かめること（fixtures。§8 と同じやり方で :3100）

• 3画面: 並べていない列の印が★薄い白の △★、押すと★白の ▲／▼★（施設マスタは △ → ▼ → ▲ → △）。△ と ▲▼ の大きさ・高さがそろって見える。見出しの文字は動かない（印を変えても th の幅が変わらない）
• ライトテーマ（表示設定で切り替え）: 印が★濃い紺★で見える（白で消えていない）
• エラー一覧の編集中: 印だけ薄くなり、見出しの文字は他の列と同じ濃さ（§11 R18 のまま）
• 清掃詳細ログ: 「全件」の右にプルダウン。既定（△×のみ）で「予定外」→ 1件（施設11の×）。「全件」にすると2件。「予定あり」→ 予定外の行（予定の欄が「予定外」）が消える。 ★ページの戻しは「全件」で確かめる★（既定の△×のみは48件で1ページしかない）: 「全件」（fixtures で283件・6ページ）で2ページ目を開き、プルダウンを「予定あり」（281件）に切り替えると1ページ目に戻ること。 ★「予定外」への切り替えで確かめないこと★ — 2件で1ページに収まるので、setPage(1) を入れ忘れていても DetailLogScreen.tsx:237-238 の保険（応答の page が総ページ数を超えたら最終ページへ寄せる）で1ページ目に戻って見える（件数は実行日で少し変わるが、全件と予定ありが2ページ以上・予定外が1ページという関係は変わらない）。 CSV のリンクに schedule= が付き、CSV の行も同じに絞られる。 ★ビューポート 1366px と 1536px の2つの幅で見る★: 1536px ではツールバーが1行。1366px では右の組が2行目に落ちるが不具合ではない（12-2）。 どちらの幅でも、プルダウン自身の幅（160px）が JP/EN や選んだ値で変わらないこと（左端の位置は、前の結果ボタンの文言の幅だけ JP/EN で数 px 動く。結果ボタンは今も JP/EN で幅が変わるので承知のうえ）
• フォント: git grep -n "Hiragino" -- app components lib のヒットが app/globals.css の --font-ja の1行だけであること。ダーク・ライトとも △ と ▲▼ の大きさ・高さがそろうこと
• エラー一覧のプルダウンは見た目も動き（「予定外」で3件）も今までどおり

12-7. 段階（この順で。§9 の共通ルールはそのまま）

1. d-watch-api.yaml（12-2 の YAML）
2. lib/api/schedule-filter.ts＋テスト（表P・表M）、lib/types/index.ts（名前の変更と注記）
3. lib/error-reports/query.ts を共通関数に置き換え → ★エラー一覧の既存テストが変えずに通ることを先に確かめる★
4. lib/clean-logs/query.ts、ルートのコメント、fixture-clean-logs.test.ts の schedule: null、表P（P-1〜P-8）・表F・表X のテスト。 ★表P の P-1〜P-7 は lib/clean-logs/__tests__/query.test.ts で parseCleanLogQuery() にも it.each で当てる★（ほかのパラメータは付けない）。ok のケース（P-1〜P-6）は parsed.query.schedule を見る。422 のケース（P-7）は status 422・message「scheduleの値が不正です」・details を toEqual で丸ごと見る
5. components/ui/ScheduleFilterSelect.tsx、ErrorsScreen.tsx の置き換え、DetailLogScreen.tsx・.module.css
6. app/globals.css（--sort-mark・--font-ja と body の font-family）、SortableTh.tsx・.module.css（印・色・フォント・コメント）、lib/table-sort.ts:46 のコメント
7. tsc・lint・vitest 全件の件数と、段階ごとの変更ファイルを報告（★報告は日本語★）

12-8. 決定の記録（監督が docs/decisions.md に後で書く）

• 並べ替えの印: 並べていない列＝薄い △、asc ▲・desc ▼ は塗りのまま。色はダーク＝白、ライト＝#1e293b（白は背景に溶けるため。監督の判断）。印の字は日本語フォントでそろえる
• 清掃詳細ログにも schedule（エラー一覧と同じ3択・同じ文言）。予定ありの中身は2画面で違う（エラー一覧＝clean_timetable_id が 0・NULL 以外、清掃詳細ログ＝予定の表の行）
• 検証と判定は lib/api/schedule-filter.ts の1か所、プルダウンは components/ui/ScheduleFilterSelect.tsx の1か所（CSS は各画面）
• 置き場所: 清掃詳細ログは「全件」の右（エラー一覧は「解消済みも表示」の左のまま）。1366px 前後の幅では詳細ログのツールバーが2行になる（承知のうえ）
• 日本語フォントの並びを app/globals.css の --font-ja にまとめ、body と並べ替えの印の両方がそれを使う（並びの写しを作らない）
• 点検（2026-11-04）: 4観点で12件の指摘。反証で確かめて6件が本物（12-4 の理由・ツールバーの折り返し・表P を parseCleanLogQuery にも当てる・フォントの並びの写し・ページの戻しの確かめ方）。棄却6件のうち、書き方の補足になる5件（includes のキャスト・:218 の受け方・名前変更と参照・予定ありの中身・JP/EN の数 px）は本文に一言ずつ足した。棄却: 段階ごとに tsc を通す決まりの追加（§9 は最後だけ求める）
• 却下: 白抜き △▽ にする案・並べた列だけ印を出す案（ユーザーが「塗りのまま色だけ白」を選んだ）。schedule をデータ層（SQL）に降ろす案（ダッシュボードに波及するため）

13. 追補3 — 表示の文言を「予定なし」に統一（2026-11-04。★Cursor ではなく監督側で直した★）

§12 の実装は監督が確認済み（tsc・lint・vitest 155ファイル・3826件、fixtures の画面）。そのあとのユーザー指示: 「文言を予定なし、予定ありに統一して／プルダウンだけじゃなくて、表の表示も、cursorでなくこちらで直して」

• ★画面・CSV に出る「予定外」を「予定なし」に変えた★: プルダウンの選択肢（components/ui/ScheduleFilterSelect.tsx）、清掃詳細ログ・ダッシュボードの小さい表・CSV の「予定」列（CLEAN_LOG_UNSCHEDULED_LABEL。lib/format/clean-result.ts）、清掃面積の注記（CleanAreaScreen.tsx）。英訳は既存の「予定なし」"No schedule"
• エラー一覧の「紐づく予定」列はもともと「予定なし」（予定のある行は「本清掃」「事前チェック（N分前）」「予定不明」と中身を出す。変えない）
• ★変えないもの★: API のパラメータ値（schedule=scheduled / unscheduled）・型名・関数名・CleanLogItem.unscheduled・コメントや仕様書の概念語「予定外タスク」（契約と内部の用語。画面に出る文字だけを変えた）
• §4・§12 の本文の「予定外」（選択肢の文言）は、この §13 で「予定なし」に読み替える