指示書AV — ダッシュボードを「各清掃エリアの直近の清掃（7日以内）」にする

日付: 2026-10-06 / 担当: Cursor（★実装は Claude Code（2026-10-06。ユーザー指示「ここで実装する」）。§13★）/ 基点: develop 6c944cf（D-159 を記録したコミット） 前提: ★D-159（本書の根拠。docs/decisions.md:12578-12591）★ / D-049（スケジュール進捗。docs/decisions.md:300-310）/ D-091 項1（出発の判定に「予定＋猶予」を当方で計算しない。docs/decisions.md:3449 以降）/ CLAUDE.md §4.3・§4.4・§6・§7・§9.4・§9.6

★期待値表（§3 の表1）は監督が確定した正。変えないこと★（CLAUDE.md §0-2・§6-2・§9.4）。 ★表2・表3 は本書で表1 から導いたもの★。★監督の確認が要る★（§11）。 ★§11 の質問に回答が来て本書の暫定が変わったら、§11 の各行に書いた「直す場所」を本文と同時に直すこと★ （本文と末尾の決定が食い違ったまま渡さない）。

★行番号はすべて 2026-10-06 の 6c944cf で確かめたもの★。段階が進むとずれるので、関数名・文で探すこと。

0. 何をするか

★変えないもの★（D-159 末尾）: ★スケジュール進捗（schedule_progress。当日。D-049）★／★要レスキュー（rescue_required。基準日は当日）★／ ★セキュリティバナー★／★?date= を指定したとき★／★1行ごとの判定（◎○△×・出発・L1〜L3）★／★/api/clean-logs の契約★。

1. 背景

• ダッシュボードは「昨夜の清掃結果サマリー」と出しながら、★当日の日付（todayJst()）の清掃★を数えていた （app/api/dashboard/route.ts:55 / :90 / :117）。画面のコンパクト版の表も ★当日だけ★ を引いている （components/features/dashboard/DashboardScreen.tsx:77-85。date_from = date_to = today）。
• サンプルデータは深夜 1:30〜3:30（当日の日付）なので合っていたが、★ステージングの実データは 10:00 や 19:00〜22:00（前日の日付）★で、 翌朝に開くと ★空★ になる（D-159。2026-10-06 ステージング: 当日0件／前日指定で成功9・失敗1・未実施7）。
• ユーザー指示（2026-10-06）「①で、出発失敗も含めて7日まで」。★「終わった予定だけ」は監督の判断★（D-159 項4）。

2. 決定（Cursor は従うこと）

D7 の理由（/api/clean-logs?latest=true を採らなかった理由）

• ★数値カードと表が ★同じ now・同じ行の集合★ から作られる★。別々の API にすると2本のリクエストが別々に「現在」を取るので、 境界（終了＋30分ちょうど付近）で ★カードと表の母集団がずれうる★（例外もテスト失敗も出ない）。
• 変更が小さい: /clean-logs に足すと parseCleanLogQuery()（lib/clean-logs/query.ts:80）・CleanLogQuery の型・ ★/clean-logs/export が同じパーサを共有している★ ので CSV 側の扱い・date_from / date_to との同時指定の規則まで決める必要がある。 /dashboard に足すなら、ルートが既に持っている行を返すだけ。
• ★YAML の「コンパクト版清掃詳細ログは本APIに含めない」（d-watch-api.yaml:219-220）を覆す★ことになる。あれの趣旨は 「既存の一覧APIで足りるものを二重に作るな」（同 :313-316）で、★「各エリアの直近1件」は既存の一覧APIでは表せない★ので趣旨には反しない。 ★YAML の記述は段階4 で書き直す★（★§11 Q3 で監督に確認★）。

D9 の理由（CleanLogItem に内部用の列を足さない理由）

• CleanLogItem は /clean-logs・/clean-logs/export・/clean-logs/{id}/advice など ★多くの経路が共有★ し、YAML のスキーマ名と揃えてある（CLAUDE.md §9.2）。 内部用の列を足すと ★どこかで剥がし忘れた瞬間に API に漏れる★（例外もテスト失敗も出ない）。
• prismaSource.cleanLogs()（lib/db/index.ts:765-1037）は約270行の繊細な関数（指示書AC 禁止事項14「レスポンスを1バイトも変えない」）。 ★中身に手を入れず★、where を1つの関数に切り出して2本で共有するだけにする（段階3）。
• 代わりに ★id → { 清掃エリア, 予定の終了 }★ を返す軽いメソッドを足し、純粋関数の中で id で突き合わせる。★突き合わせに失敗したら例外★（D9 の不変条件。段階2）。

3. ★期待値表（正）★

表1（pickLatestRunPerSection()。★監督確定・正・変えない★）

★条件★: 現在 ＝ 2026-10-06 09:00 JST、遡り 7日、落ち着き 30分。

★サマリ★: L1〜L10 で選ばれるのは ★A・B・D・F・G・H・I・J・K の9行★（I 以外は出発している）。 ★サマリのテストは、選ばれた9行を ★既存の computeSummary()（lib/dashboard/aggregate.ts:31）にそのまま渡した結果★ と、 pickLatestRunPerSection() の戻りを computeSummary() に渡した結果が ★等しい★ ことで確かめる★（computeSummary() は変えない）。 各行の grade は ★既存の判定★（judgeGrade(completion_rate)）で作る。完了率の値はテストを書く人が決めてよい（I は departed: false / completion_rate: null）。

★テストの書き方の注意★:

• ★入力には表に書いた予定を全部入れる★（L3・L5 の行、L6 の 10/6 08:00 の行、L8 の 10/6 06:00 の行も入れる。★選ばれないことを確かめるため★）。 ★L6 の 10/6 08:00 は「開始は過ぎているが終わっていない」★ので、cleanLogs() は実際にこの行を返す（isFutureSchedule() は開始しか見ない）。departed: false で入れる。
• ★エリア（section_key）は J と K で別、施設（facility_id）は J と K で同じ★にする。
• ★日時は +09:00 付きの ISO 文字列で書く★（"2026-10-05T19:00:00+09:00"）。now は new Date("2026-10-06T09:00:00+09:00")。

表2（本書で表1 から導いたもの。★監督の確認が要る★）

表3（latestRunWindow(now, lookbackDays)。本書で導いたもの。★監督の確認が要る★）

DB から読む日付範囲（JST の YYYY-MM-DD。両端を含む）。★窓は表1 の判定より広くてよい（細かい判定は純粋関数）★。

★W4 はルートのテスト（app/api/dashboard/__tests__/route.test.ts:243 の NOW）と同じ日時★。

4. ★落とし穴（全段階で読むこと）★

段階0 — 着手前

1. git status が clean で、develop が 6c944cf 以降であること（★.claude/worktrees/ ではなく本体で作業する★）。
2. npx tsc --noEmit -p . と npm test が通る状態から始める（通らなければ着手前に報告）。
3. 次の grep で「当日」に依存している箇所を確かめる（本書の段階4・5 で直すのはこのうち dashboard の2ファイルだけ）:

   grep -rn "todayJst" app/api/dashboard components/features/dashboard app/api/__tests__/master-filter-dashboard-reports.test.ts

段階1 — 期待値表をテストにする（実装より先）

1. ★lib/dashboard/__tests__/latest-run.test.ts（新規）★:
   • 冒頭コメントに表1・表2・表3 を写し、「★表1 は監督確定（D-159 / 指示書AV §3）。変えないこと★」「表2・表3 は指示書AV で導いたもの」と書く
   • describe("pickLatestRunPerSection — 表1"): it.each で L1〜L10 を1件ずつ（★選ばれた id の集合★を比べる）＋ ★全部まとめて渡したときに9行★
   • it("サマリは既存の computeSummary() に選ばれた行を渡したものと等しい"): §3 表1 の下の書き方どおり
   • describe("pickLatestRunPerSection — 表2"): E1〜E6
   • describe("latestRunWindow — 表3"): W1〜W4
   • ★設定値は DASHBOARD_LATEST_RUN から読む★（7 / 30 を直書きしない。表1 の前提が設定値と一致することも1件で確かめる）
2. ★lib/config/__tests__/dashboard-latest-run.test.ts（新規）★: lookbackDays は1以上の整数、settleMinutes は0以上の整数。 ★DASHBOARD_LATEST_RUN.settleMinutes が LAUNCH_GRACE_MINUTES の参照ではない★ことはテストにできないので、コメントで D6 を書く
3. ★この時点ではテストが落ちる（関数・設定値が無い）のが正しい★。コミットはテストだけで1つ（「テストだけ。この時点では落ちる」と明記）

段階2 — 設定値と純粋関数

2-1. lib/config/index.ts

LAUNCH_GRACE_MINUTES（:191-195）の ★直後★ に足す:

/**
 * ダッシュボード（F-01）の「直近の清掃」の選び方（D-159 / 指示書AV）
 * ★`LAUNCH_GRACE_MINUTES` とは別物。流用しないこと★ — あちらは出発失敗の猶予（D-091 項1 で使わないと決めた）。
 *   こちらは「どの予定を見せるか」だけに効き、1行の判定（出発・◎○△×・L1〜L3）には効かない。
 * ★消費者★: `app/api/dashboard/route.ts` と `components/features/dashboard/DashboardScreen.tsx`（見出しの日数）だけ
 */
export const DASHBOARD_LATEST_RUN = {
  /** 何日前の予定まで遡るか（予定の開始で数える。★ちょうどは含む★） */
  lookbackDays: 7,
  /** 予定の終了から何分たったら「終わった」とみなすか（★ちょうどは含む★）。レポートは清掃の後に書かれる（2026-10-01 ユーザー回答） */
  settleMinutes: 30,
} as const;

2-2. lib/types/index.ts — 内部用の型

CleanLogDbQuery（:117-166）の後に足す。★YAML には載せない（API に出ない）★ことを docstring に書く:

export interface CleanLogRunMeta {
  /** `clean_timetables.id`（＝ `CleanLogItem.id`） */
  id: number;
  /** 清掃エリアを区別するキー。Prisma: `section:${section_id}` / fixtures: `fixture-robot:${serial_number}`（D10） */
  section_key: string;
  /** 予定の終了。ISO8601（+09:00）。Prisma: `jstIsoFromDb(end_at)` / fixtures: `scheduled_at` と同じ（D10） */
  planned_end_at: string;
}

★section_key を文字列にした理由★: fixtures に清掃エリアの id が無く、数値を作り出すと実在の id と取り違えうるため。

2-3. lib/dashboard/latest-run.ts（新規）— ★純粋関数のみ★

export interface LatestRunOptions { now: Date; lookbackDays: number; settleMinutes: number }

export function latestRunWindow(now: Date, lookbackDays: number): { date_from: string; date_to: string }
export function pickLatestRunPerSection(
  rows: readonly CleanLogItem[],
  meta: readonly CleanLogRunMeta[],
  options: LatestRunOptions
): CleanLogItem[]

• latestRunWindow(): date_to = toJstIso(now).slice(0, 10)、date_from = toJstIso(new Date(now.getTime() − lookbackDays × 86_400_000)).slice(0, 10)。 ★toJstIso()（lib/format/date.ts:37）を使う★（実行環境の TZ に依存しない。getFullYear() 等を使わない）
• pickLatestRunPerSection():
  1. meta を id で引けるようにする。★同じ id が2回 → 例外★（E2）
  2. 各行について ★meta が無ければ例外★（E1。メッセージ例: [dashboard] pickLatestRunPerSection: clean_timetables(id=…) の予定の終了・清掃エリアがありません）
  3. 候補にする条件（★両方とも「含む」★。D4）: Date.parse(row.scheduled_at) >= now − lookbackDays × 86_400_000 かつ Date.parse(meta.planned_end_at) + settleMinutes × 60_000 <= now
  4. section_key ごとに、開始（Date.parse(scheduled_at)）が一番大きい行。★同じなら id が大きいほう★（D5）
  5. ★戻りは rows.filter(選ばれた id)★（入力の順を保つ。E4）。★行を書き換えない・丸めない★
• ★isFutureSchedule() をここで呼ばない★（未来の予定は cleanLogs() が既に外している。条件3 の「終わった」で足りる）

段階1 のテストが通ること。コミット。

段階3 — データ層（cleanLogRunMeta()）

3-1. DataSource（lib/db/index.ts:203-215）

cleanLogs() の直後に足す:

/**
 * ★清掃ログの id → { 清掃エリア, 予定の終了 }★（ダッシュボードの直近モード専用。D-159 / 指示書AV）。
 * ★`cleanLogs()` と同じ引数を渡すこと★（同じ `where`。突き合わせは `pickLatestRunPerSection()`）。
 * ★`cleanLogs()` が返さない id（未来の予定）を含んでよい★。逆（`cleanLogs()` の行に対応が無い）は呼び出し側の例外
 */
cleanLogRunMeta(query: CleanLogDbQuery): Promise<CleanLogRunMeta[]>;

3-2. fixtures 版（lib/db/index.ts:476-478 の cleanLogs() の直後）

async cleanLogRunMeta(query: CleanLogDbQuery) {
  return filterFixtureCleanLogs(cleanLogs, query).map((row) => ({
    id: row.id,
    section_key: `fixture-robot:${row.serial_number}`,
    planned_end_at: row.scheduled_at,
  }));
}

★docstring に D10 を書く★: 「fixtures には予定の終了も清掃エリアも無い。★終了＝開始★（落ち着き時間は開始から数える）、★清掃エリア＝ロボット★」。 ★filterFixtureCleanLogs() を通す★ので facility_ids の null / [] の扱いは cleanLogs() と同じになる。

3-3. Prisma 版

1. ★cleanLogs() の where（lib/db/index.ts:779-803）を関数に切り出す★（同じファイル内の非公開関数。例 mainTimetableWhere(query: CleanLogDbQuery)）。 const range = dbDateRange(...)（:774）も中に入れる。★中身は1文字も変えない★（コメントも一緒に移す）。 cleanLogs() は where: mainTimetableWhere(query) にする。★include / orderBy（:804-823）は動かさない★
2. cleanLogRunMeta() を足す:

   const rows = await findTimetables(prisma, {
     where: mainTimetableWhere(query),
     select: { id: true, section_id: true, end_at: true },
   });
   return rows.map((row) => ({
     id: Number(row.id),
     section_key: `section:${row.section_id.toString()}`,
     planned_end_at: jstIsoFromDb(row.end_at),
   }));

   • ★findTimetables()（lib/db/timetable-source.ts:233）を使う★（2表から読む・同じ id は本表が勝つ。指示書AU 段階3b）。★prisma.cleanTimetable.findMany を直接呼ばない★
   • ★select に id: true は必須★（型で強制されている。timetable-source.ts:57-74）
   • ★end_at は jstIsoFromDb()★（4-3）
3. ★テスト★（lib/db/__tests__/ に足すか、段階4 のルートテストで兼ねる）:
   • fixtures 版: planned_end_at === scheduled_at、facility_ids: [] で []、null で全件
   • Prisma 版: ★cleanLogRunMeta() の where が cleanLogs() の where と toEqual★（4-8）／★2表の両方に同じ引数が渡る★／end_at が壁時計値のまま ISO になる（2026-10-05 21:10:00 → "2026-10-05T21:10:00+09:00"）
4. ★cleanLogs() のレスポンスが変わっていないこと★: 既存の app/api/clean-logs/__tests__/route.test.ts / app/api/dashboard/__tests__/route.test.ts（?date= のもの）が ★期待値を変えずに★ 通ること

コミット。

段階4 — API（YAML → 型 → ルート）

4-1. d-watch-api.yaml（★先に直す。CLAUDE.md §6-1★）

1. /dashboard の description（:218-220）を書き直す:
   • date を省略すると ★summary と problem_logs は「各清掃エリアの直近の清掃（7日以内・終わった予定のみ・出発失敗を含む）」★。D-159
   • ★schedule_progress / rescue_required / security_banner は省略時も当日★（D-049 / D-159）
   • ★コンパクト版の表は problem_logs で返す★（旧: GET /clean-logs を再利用）。理由は D7 の1行目
2. date の説明（:225）: 「対象日。指定するとその日の清掃で summary / problem_logs を作る。省略（空文字を含む）すると直近モード」
3. summary に説明を足す（母集団が date の有無で変わる）
4. rescue_required の説明の「★上の『コンパクト版清掃詳細ログは本APIに含めない』には抵触しない★」（:313-316）を、新しい説明に合わせて直す（その前提の文が無くなるため）
5. rescue_required の後（:357 の後）に problem_logs を足す:
   • type: array、items: { $ref: "#/components/schemas/CleanLogItem" }
   • 説明: summary と同じ母集団のうち判定が △× の行／並びは scheduled_at 降順 → id 昇順（データソースの順のまま）／★件数の上限は無い★（1エリア最大1行。画面が先頭5件を出す）／連続日数は表示上限で頭打ち（consecutive_problem_days_capped）

4-2. lib/types/index.ts の DashboardResponse（:1146）

• problem_logs: CleanLogItem[] を足す（★optional にしない★。0件は「問題の行が無い」という事実）
• summary の docstring に母集団（直近モード／date 指定）を書く。schedule_progress は「当日」のまま

4-3. 「問題あり」の規則を共有する（lib/clean-logs/query.ts）

• :180 の !["△", "×"].includes(r.grade) を ★export function isProblemGrade(grade: Grade): boolean★ に切り出し、filterCleanLogs() はそれを呼ぶ（★動作は変えない★）
• ★critical（:183）は触らない★

4-4. app/api/dashboard/route.ts

1. ★冒頭コメント :12-13★（「コンパクト版清掃詳細ログはこのAPIに含めません」）を D7 に合わせて書き直す
2. :48-55: ★const now = new Date() を1回だけ★ 作り、today = toJstIso(now).slice(0, 10)、const latestMode = !dateRaw、const date = dateRaw || today。 ★|| の理由のコメント（:49-54）は残し、「?date= は直近モードになる」に直す★
3. 取得（:80-102）:
   • 直近モード: const window = latestRunWindow(now, DASHBOARD_LATEST_RUN.lookbackDays)。 ★cleanLogs() と cleanLogRunMeta() に同じ { id: null, date_from: window.date_from, date_to: window.date_to, facility_ids: facilityIds } を渡す★（オブジェクトを1つ作って2本に渡す）
   • date 指定: 今までどおり cleanLogs({ id: null, date_from: date, date_to: date, facility_ids })。★cleanLogRunMeta() は呼ばない★
   • schedules() / dsAlerts() / rescueRequired({ date, facility_ids }) は ★そのまま★（date は直近モードでは当日）
   • ★loadConsecutiveDaysMax() を try/catch で読む★（app/api/clean-logs/route.ts:55-63 と同じ作法。読めなければ CONSECUTIVE_DAYS_DISPLAY.defaultMax）
   • ★pickLatestRunPerSection(logs, meta, { now, ...DASHBOARD_LATEST_RUN }) は try の中★（4-9）
4. 集計（:115-147）:
   • logsOfDay は ★今までどおり today（= date）の行★。computeScheduleProgress(logsOfDay, …) と data.anomaly は ★変えない★
   • const summaryRows = latestMode ? picked : logsOfDay
   • summary = computeSummary(summaryRows)
   • problem_logs = capCleanLogs(summaryRows.filter((r) => isProblemGrade(r.grade)), maxDays)
5. :66-72 / :85-89 のコメントの「当日」「4つすべてに同じ配列」を、cleanLogRunMeta() を含めて直す（★同じ facilityIds を5本に渡す★）。:82 の「約360行」には「直近モードは8日ぶん」を足す

4-5. テスト

1. app/api/dashboard/__tests__/route.test.ts:
   • StubTimetable（:42-55）と timetable()（:186）に ★end_at★ を足す（例: 開始＋1時間）。★select はスタブの project() が処理する★
   • :300 「date 省略時は当日の1日ぶん」→ ★「直近モードは表3 W4 の窓（2026-09-23〜2026-09-30）で start_at が絞られる」★（gte = 2026-09-23T00:00:00.000Z、lt = 2026-10-01T00:00:00.000Z。壁時計値）
   • :305 「?date=（空文字）でも当日に倒れ…」→ ★「?date= でも直近モードの窓に倒れ、全件読みに戻らない」★（★start_at の条件が消えないこと★がこのテストの本題。残す）
   • :316 「?date= と省略が同じ結果」は ★そのまま★
   • ★新規★: 直近モードの summary が ★{ success: 1, failed: 0, not_executed: 1, success_rate: 50 }★（施設1の 09-30 02:00 ＝ 成功、施設2の 09-29 02:00 ＝ 未実施。★本書で導いた値★）。 ★同じデータで ?date=2026-09-30 は [1, 0, 0] のまま★（:346-352 の既存テスト）
   • ★新規★: 直近モードの problem_logs は施設2の 09-29 の1行だけ。?date=2026-09-30 の problem_logs は []
   • ★新規★: cleanLogRunMeta() の where が cleanLogs() の where（include 付きの1本目。mainQueryWhere() :252）と toEqual（4-8）。 ★メタの呼び出しは「select のキーがちょうど id / section_id / end_at の3つ」で見分ける★ — 要レスキュー（loadConsecutiveInputs() など）も cleanTimetable.findMany を select 付きで呼ぶので、「select 付き」だけでは見分けられない
   • ★新規★: ?date=2026-09-29 では上のメタの呼び出しが ★0回★（日付指定ではメタを読まない）
   • ★新規★: schedule_progress が直近モードと ?date=2026-09-30 で ★同じ★（4-1）
2. app/api/__tests__/master-filter-dashboard-reports.test.ts:
   • todaysLogFacilityIds()（:83-90）は ★直近モードの母集団★ に直す。★pickLatestRunPerSection() を呼ばずに★ テストの中で素直に書く: 「fixtures の cleanLogs のうち、施設が allowed に入り、Date.parse(scheduled_at) >= now − 7日 かつ Date.parse(scheduled_at) + 30分 <= now の行の ★serial_number の種類数★」（7・30 は DASHBOARD_LATEST_RUN から読む）
   • ★/dashboard の describe だけ時計を止める★: vi.useFakeTimers({ toFake: ["Date"] }) → vi.setSystemTime(new Date(\${todayJst()}T12:00:00+09:00`))（★todayJst()は止める前に読む★）。afterEachでvi.useRealTimers()`。 ★理由★: 実時刻のままだと、深夜0時〜4時に走らせたとき当日の fixtures 行が「終わっていない」扱いになり、期待値が時刻で揺れる
   • :156 の分割の検査（4つの顧客を足すと絞らないときと一致）は ★そのまま★ 通ること
3. lib/clean-logs/__tests__/query.test.ts（既存の filterCleanLogs() のテスト）が ★期待値を変えずに★ 通ること（4-3）

YAML → 型 → ルート → テストの順でコミット（1つでも分けてもよい）。

段階5 — 画面

5-1. components/features/dashboard/DashboardScreen.tsx

1. ★/api/clean-logs の取得をやめる★（:75-86）。apiFetch<DashboardResponse>("/api/dashboard") だけにし、表には data.problem_logs を使う。
   • logs の state（:52）・setLogs（:88 / :97）・ListResponse の import は不要になれば消す
   • ★画面に出すのは先頭5件★（data.problem_logs.slice(0, 5)）。★「5」を新しい名前の定数にするか既存のまま直書きするかは、元のコード（per_page: "5"）と同じ扱いでよい★。RESCUE_INITIAL_VISIBLE（lib/config/index.ts:119）の docstring が「コンパクト版が5件（per_page: "5"）なので揃えた」と書いているので、★その文を「problem_logs の先頭5件」に直す★
   • :89-95 の「2本のうちどちらが失敗しても…」のコメントは1本になったので直す
2. ★見出し（:214）★: 昨夜の清掃結果サマリー — {today} を t("直近の清掃結果サマリー（各清掃エリアの最後の清掃・{n}日以内）").replace("{n}", String(DASHBOARD_LATEST_RUN.lookbackDays)) にする。
   • ★モック（d-watch-mock.jsx:476）と文言が違う★ので、D-120 / D-121 と同じく ★JSX コメントで「D-159 でユーザーが変えた。モックは書き換えない」★と残す
   • today（:49）と todayJst の import（:14）が使われなくなれば消す
3. :201-207 のコメント（「当日の清掃ログ行数」）を ★「直近モードでは、7日以内に終わった予定がある清掃エリアの数」★ に直す（sub={\/ ${totalLogsToday}件`}の変数名はtotalLogs` 等に変えてよい）
4. :260-273 の要レスキューのコメントの「★数値カード（上）とは母集団が違う★」に「数値カードは直近モード、要レスキューは当日基準」を足す

5-2. lib/i18n.ts

"直近の清掃結果サマリー（各清掃エリアの最後の清掃・{n}日以内）": "Latest cleaning results (last run per area, within {n} days)" を足す（★EN は暫定。ユーザーが後でまとめて見直す★）。★キーの全角括弧・中点を原文と揃える★。重複は lint が落とす。

5-3. 表の各行に日付を出す（components/features/detail-log/CleanLogTable.tsx）

• ★compact のときだけ★、「予定」のセル（:207）を ${formatMd(r.scheduled_at)} ${formatHm(r.scheduled_at)}（例 10/5 19:00）にする。★compact でないとき（清掃詳細ログ）は変えない★（日付列 :206 が別にある）
• ★列は増やさない★（<col> / <th> / <td> の3箇所と colSpan={compact ? 5 : 11} を変えずに済む）。compact の「予定」列は 200px（CleanLogTable.module.css:61）で、10/5 19:00 は収まる
• CleanLogTable の compact の docstring（:24-38）の「★落とす列★は … 日付 …」に「compact では日付を予定のセルに含める（D-159）」を足す
• ★暫定★（§11 Q2）。エリアモーダルの dateLabel（DashboardScreen.tsx:163）は既に formatMd(row.scheduled_at) なので変えない

5-4. 確認

• ★画面のテストは vitest で走らない★（vitest.config.ts の include は lib/** と app/**）ので段階7 の画面確認で見る

段階5b — 清掃詳細ログの画面の既定を「期間を指定しない（全期間）」にする（★ユーザー指示 2026-10-06「C」。D-159 追記★）

★背景★: ダッシュボードのカードと「全項目 →」は /detail-log に移るが、画面は開いたときに date_from = date_to = 今日（todayJst()）で API を呼ぶ（components/features/detail-log/DetailLogScreen.tsx の useState(today) 2つ。2026-10-06 時点で :60-61 付近）。 ★昨夜 19:00 の出発失敗はダッシュボードには出るのに、移った先には出ない★。

1. ★画面の初期値を「期間なし」にする★: dateFrom / dateTo の初期値を空文字にし、★空のときは date_from / date_to を URL に付けない★（API は期間なし＝全期間を返す。lib/clean-logs/query.ts の既存の挙動。★API は変えない★）。
2. 期間の入力欄は空で表示する。片方だけ入れた場合・期間の検証（MAX_DATE_RANGE_DAYS、開始 ≦ 終了）は★両方入っているときだけ★行う。既存の検証メッセージ（DetailLogScreen.tsx :167 / :175 付近）の条件をそれに合わせる。
3. ★絞り込みの既定「問題あり」（gradeFilter = "problem"）は変えない★。
4. ★CSV 出力も同じクエリを使う★ので、期間なしなら全期間の CSV になる。画面の件数表示・ページ送りは既存のまま。
5. 文言: 期間が空のときに「全期間」と分かる表示を入れる（例: 入力欄の placeholder「指定なし（全期間）」。EN「Not set (all)」。i18n 経由）。
6. テスト: 初回の取得 URL に date_from / date_to が付かないこと、片方だけ入れたとき検証エラーにならず送らない（または両方そろうまで送らない — ★既存の挙動に近いほうを採り、理由をコミットに書く★）、両方入れたときは従来どおり。
7. ★性能の注意（監督→ユーザーに伝えた）★: 期間なしの取得は、Prisma 版では ★保持期間（2年）の予定を全部読んでからページ分けする★（lib/db/index.ts の cleanLogs()。指示書AC で日付を必須にして避けていた形）。ステージングでは100行程度で問題ないが、本番の想定（約26万行）では重くなる。★本書では対策しない★（リリース前に見直す）。★ログ（db.query 系の所要時間）で観測できることだけ確かめる★。

段階6 — 資料（本書で直すのは次の2つだけ）

1. docs/fixtures.md §12（:363-）:
   • :371-372 の「date 省略時は当日＝daysBack=0」に「★schedule_progress は省略時も当日。summary と problem_logs は直近モード（D-159）★」を足す
   • ★§12.3 を新設★: 「date 省略時（直近モード）に何が出るか」。fixtures は ★終了＝開始・清掃エリア＝ロボット★（D10）。★JST 4:00 以降★ に開くと ★15行（ロボット15台）: 成功9 / 失敗5 / 未実施1 / 成功率60%★、△× は6行で表には当日の5行（施設12・10・6・9・8）が出る。 ★訂正（2026-10-06 実装時）: 並びは 12・10・★9・6★・8★。施設9 と施設6 は同じ 02:30 で、fixtures の cleanLogs の並べ替えは scheduled_at しか見ないため、 同じ時刻は実際には id の降順になる（Prisma 版は id 昇順なので DB では 6・9）。顔ぶれは同じ。docs/fixtures.md §12.3 が正（§13）★ ★4:00 より前は当日の行の一部が「終わっていない」扱いになり、前日以前の行が出る（施設12 は当日しか行が無いので消える）。それが正しい★ （★この数字は本書で fixtures から数えたもの。段階7 の画面確認で違えば、どちらが正しいかを報告★）
2. ★app/api/dashboard/route.ts / lib/types/index.ts / d-watch-api.yaml の説明★（段階4 で直したもの）

★CLAUDE.md / docs/decisions.md / docs/code-map.md / docs/spec.md は監督が直す★（§9）。

段階7 — 全体の確認

1. npx tsc --noEmit -p . — エラー0件
2. npm run lint — 指摘0件（i18n の重複キー・$queryRaw・any・未使用の import が無いこと）
3. npm test — ★全件通過★（表1〜表3 を含む）
4. ★USE_FIXTURES=true で npm run build★ — 成功（PowerShell なら $env:USE_FIXTURES='true'; npm run build）
5. ★画面で確かめる（USE_FIXTURES=true）★: .claude/launch.json の ★d-watch-fixtures（ポート 3100）★ で起動する（Claude Code なら preview_start の d-watch-fixtures）。 ★確かめ終わったら、自分で起動した dev サーバーは必ず止める★
   • ★見出し★が「直近の清掃結果サマリー（各清掃エリアの最後の清掃・7日以内）」。EN で "Latest cleaning results (last run per area, within 7 days)"
   • ★数値カード★が段階6 §12.3 の値（JST 4:00 以降）。★スケジュール進捗は今までと同じ値★（docs/fixtures.md §12.1 の「当日」の行: 予定10・実施9）
   • ★清掃詳細ログ（コンパクト版）★が5行で、各行の「予定」が M/D HH:mm。行を開くとアドバイスが出る・エリア別詳細のモーダルが開く（id は今までと同じ）
   • ★要レスキュー・セキュリティバナー★が変わっていないこと
   • ★ネットワーク★: 初期表示で /api/clean-logs が ★呼ばれない★こと（/api/dashboard の1本だけ）
   • ★JP/EN 切替で表の列幅が動かないこと★、モバイル幅（375px）で見出しが不自然に崩れないこと。崩れていたら直さずに報告
6. 最後の grep（★0件になること★）:

   grep -rn "昨夜の清掃結果サマリー" app components lib --include=*.ts --include=*.tsx
   grep -rn "api/clean-logs?" components/features/dashboard
   grep -rnE "(lookbackDays|settleMinutes)\s*[:=]\s*[0-9]" app components lib --include=*.ts --include=*.tsx | grep -v "lib/config/index.ts" | grep -v __tests__

8. テスト一覧（本書で足す・直すもの）

9. 触ってはいけないもの

• CLAUDE.md / docs/decisions.md / docs/code-map.md / docs/spec.md（監督が直す）
• d-watch-mock.jsx（文言の違いはコメントで残す。5-1）
• prisma/schema.prisma / lib/generated/prisma/**（★DB の定義は TeamWorks の領域。CLAUDE.md §7★）
• computeSummary() / computeScheduleProgress() / computeSecurityBanner() の中身（lib/dashboard/aggregate.ts）
• ★db.rescueRequired() とその基準日（当日）★・buildRescueRequired() の並び
• isFutureSchedule() / notExecutedFromReport() / latestReportByTimetableId() / completionRateFromReport() の中身（lib/db/clean-log-mapping.ts）
• ★prismaSource.cleanLogs() の include / orderBy / 行の組み立て / 連続日数★（★where の切り出し以外は触らない★。段階3-3）
• findTimetables() / mergeTimetableRows() の中身（lib/db/timetable-source.ts）
• LAUNCH_GRACE_MINUTES / GRADE_THRESHOLDS / judgeGrade() / displayRate()
• lib/fixtures/clean-logs.ts / lib/fixtures/schedules.ts のデータ（★終了時刻・清掃エリアを足さない★。D10）
• /api/clean-logs と /api/clean-logs/export の契約・parseCleanLogQuery()（★新しいパラメータを足さない★。D7）
• 清掃詳細ログ画面（DetailLogScreen.tsx）の既定の期間（当日）— §11 Q5 ★→ 段階5b で上書き（ユーザー指示「C」。D-159 追記）。既定は「期間を指定しない（全期間）」に変えた★
• 4カラム UPDATE（status / comment / responded_at / resolved_at）
• scripts/seed-local-db.ts の接続先とガード（lib/db/local-guard.ts）

10. 範囲外（本書ではやらない。監督が扱う）

• ★清掃詳細ログ画面の既定の期間★、★数値カード（失敗・未実施）を押したときの遷移先の条件★（§11 Q5） ★→ 段階5b で上書き（ユーザー指示「C」）。既定の期間は本書で扱った（全期間）。遷移先の条件（URL に絞り込みを載せること）は範囲外のまま★
• 遡り日数・落ち着き時間をシステム管理画面から変えられるようにすること（§11 Q6）
• 7日以内に予定が無い清掃エリアを画面に知らせること（§11 Q7）

11. 監督への質問 → ★監督の決定（2026-10-06）: Q1〜Q10 はすべて「本書の暫定」のとおりで確定★

★本文は暫定のまま正しい（直す箇所は無い）★。Q5・Q7・Q8 は範囲外としてユーザーに伝える（監督）。 ★→ Q5 はその後ユーザー指示「C」（2026-10-06）で段階5b として本書に入った（既定の期間を全期間に）★。

（以下は作成時の質問。記録として残す）

作成時の質問

★回答で暫定が変わったら、「直す場所」の列の箇所を ★同時に★ 直してから渡すこと★。

12. コミット

段階ごとに分ける（段階1 / 段階2 / 段階3 / 段階4 / 段階5 / 段階6）。★git add はファイルパスを明示する★（git add -A 禁止）。 メッセージには ★何を変えたか★ と ★なぜ（D-159。ダッシュボードを各清掃エリアの直近の清掃にする）★ を書く。 ★段階1 のコミットは「テストだけ（この時点では落ちる）」と明記する★。 ★PR の作成とマージは daichi がレビューしてから行う★（D-154）。

13. 実装の記録（2026-10-06）

★実装は Cursor ではなく Claude Code★（ユーザー指示 2026-10-06。本書の扱いを聞いた質問に「ここで実装する」と回答）。 監督がサブエージェント2本（★バックエンド: 段階1〜4★ / ★画面・資料: 段階5・5b・6★）に分け、ワークツリーで実装 → develop に cherry-pick。 ★期待値表（§3 表1）は変えていない★。記録の正は docs/decisions.md D-159 の「実装の記録」と docs/handoff.md 追記61。

13-1. コミット（develop。★push 済み。別セッションの f424689 の push に含まれた（2026-10-06）★）

939a2c5 のメッセージ本文の1行で t("…") の二重引用符が落ちている（中身に影響なし。直していない）。

13-2. 確認（監督。137a94b 時点）

• npx tsc --noEmit -p . 0件 / npm run lint 0件 / vitest ★111ファイル・2,601件 通過★（着手前 106・2,540）/ USE_FIXTURES=true npm run build 成功 / 段階7-6 の grep 3本とも0件
• ★画面（当方の fixtures 由来）★: 本番ビルドを next start -p 3100、Edge ヘッドレスで撮影（2026-10-06 15:1x JST）。 見出しは JP・EN とも本書どおり／数値カード ★9・5・1・60%（/ 15件）★／表の「予定」は 10/6 03:30 形式／ ★初期表示の API は /api/dashboard の1本だけ★／スケジュール進捗 予定10・実施9（従来どおり）／ 清掃詳細ログは「指定なし（全期間）」で date_from・date_to なしで取得し、前日の行も出る
• ★fixtures の /api/dashboard（当方の fixtures 由来）★: problem_logs 6行、先頭5件は施設 ★12・10・9・6・8★ → docs/fixtures.md §12.3 と一致。 ★段階6 に書いた 12・10・6・9・8 は誤り★（同時刻 02:30 の施設9・6 は、fixtures では id 降順。Prisma 版は id 昇順）
• ★ステージング（先方投入データ）★: 既存の dev サーバー :3000（USE_FIXTURES=false）、2026-10-06 15:0x JST。 直近モードで ★11エリア、成功9・失敗1・未実施1（成功率81.8%）★、problem_logs 2行（10/5 19:26 の未実施、10/5 10:00 の ×）。 ?date=当日 は従来どおり0件。スケジュール進捗は両モードで同じ（予定11・実施0）

13-3. 段階5b の「片方だけ日付を入れた」扱い

• ★入っている側だけを送る（検証エラーにしない）★。理由: 5b 以前の画面と同じ挙動（以前も片方を消すと空文字が飛び、API は空の側を指定なしと読んでいた）
• 却下: 「両方そろうまで送らない」（入力途中に古い結果が残る）／「片方だけなら捨てる」（入力した日付が黙って無視される）
• 検証と URL の組み立ては ★lib/clean-logs/detail-log-date-range.ts★（新規・純粋関数。appendDateRangeParams() / dateRangeError()。テスト20件）
• <input type="date"> の placeholder は多くのブラウザで出ないので、★両方空のあいだ入力欄の前にも「指定なし（全期間）」を出している★（§段階5b-5 の例より一歩踏み込んだ）

13-4. 残したもの

• ★375px 幅で見出しが4行に折り返す★。原因はサイドバーが畳まれず幅の大半を占めること（本書以前からの作り）。★直していない★（段階7-5「崩れていたら直さずに報告」）
• ★期間なしの取得の性能★（段階5b-7）— リリース前に見直す（D-159 追記）
• 運用上の知見: ★ワークツリーでは Turbopack が node_modules のジャンクションを拒否して npm run build が落ちる★（"Symlink [project]/node_modules is invalid"）。 ビルドは本体で行った（dev サーバーは .next/dev を使うので :3000 を動かしたままで可）