指示書AU — 第11回の回答を反映する（task_area = 0 は 0%・当期KPIをサマリの式に・「屋号」を「顧客」に・古いコメント4件）

日付: 2026-10-05 / 担当: Cursor / 基点: develop 74cffd5（指示書AR・AS・AT は実装済み） 前提: D-155 / D-156 / D-157 / ★D-158（本書の根拠）★ / CLAUDE.md §4.2・§4.3・§4.7・§6・§7・§9.4 / TeamWorks 第11回の回答（原文 docs/handoff/TeamWorks回答_第11回_20261005.md。設問は docs/handoff/TeamWorks確認事項_第11回_20261002_送付版.md）

★CLAUDE.md §4.2 は監督が直してある★（CLAUDE.md:159-182）。本書はそれにコードを合わせる作業。 ★期待値表（§3 の表1・表2）は監督が確定した正。変えないこと★（CLAUDE.md §0-2・§6-2・§9.4）。

0. 何をするか

★変えないもの★: 確定期間（サマリ *_summaries）の値の読み方（そのまま読む）／完了率の平均の取り方（meanCleanRatio()）／ 判定（◎○△×・L1〜L3・アドバイス・要レスキュー）の規則／未実施を departed で数えること（指示書AS 案A。D-156 項1）。

1. 背景 — 回答で何が分かったか

1-1. P-5（task_area = 0 の行）＝ B「0% として数える」

いまは runCompletionRate() が task_area === 0 で null を返し（lib/judge/kpi.ts:148）、分子にも分母にも入れていない（D-155 の暫定。D-156 項1）。 ★これを 0.0 にする★。帰結:

• ★completion_rate === null ⟺「レポートの行が無い（未実施）」が、再び両向きに成り立つ★（指示書AS で崩れた不変条件が戻る）
• ★それでも未実施は departed で数え続ける★（AS 案A を残す。理由は D3）
• 完了率の件数（cleanRatioCount / clean_ratio_count）は、実施と数えた回数と常に同じ値になる（task_area = 0 も件数に入るため）

1-2. P-6（サマリの3つの率）＝ A / A / B

★確定期間はサマリの値をそのまま読んでいる★（kpiFromSummaryRatios()。lib/db/report-mapping.ts:231-241）ので、 ★変えるのは当期だけ★。式が揃うので、前期比（サマリ）と当期（アプリ）の差が同じ式どうしの差になる。

1-3. P-15（customers の単位）＝ B「法人」

customers は法人の単位で確定。★画面の見出し語「屋号」を「顧客」に変える★（D-158 当方の対応3）。 ★DB の物理名（customers / customer_name）・API のキー（customer_id）は変えない★（見出し語だけ）。

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

3. ★期待値表（正）★

★表1・表2 は監督が確定した正である。Cursor は値を変えないこと★（CLAUDE.md §0-2・§6-2・§9.4）。 ★段階1 で、実装より先にこの表をテストにする★。表とテストが食い違ったら、テストを表に合わせる。実装の都合で表を直さない。

表1（runCompletionRate の変更分。AS 表1 の R9 を差し替え、R12 を追加。他の R1〜R11 はそのまま）★正・変えない★

表2（当期 KPI。予定・開始・正常終了・エラーは本清掃・予定 ID ありの行だけで数える。生値で持ち、表示は四捨五入）★正・変えない★

• ★K8: 正常終了は status で数える。面積は見ない（P-3=A は完了率0%の話）★。この清掃の完了率は 0.0（×）だが、稼働率には正常終了1回として入る。
• ★エラー発生率は上限で切らない（D9）★。K5 はエラー件数が予定回数と同じなのでちょうど 100.0。★予定回数より多ければ100を超える★（例: 予定3・エラー4 → 133.33…）。100 で止めないこと。
• ★K2 は「予定が1件も無い」★ので3つとも null（0% にしない。lib/judge/kpi.ts:22-23）。★K3 は「予定はあったが全部出発失敗」★なので 0.0。★エラー発生率も 0.0★（旧式では実施0回で null だった）。
• ★K6 の status=6★ は Pudu の値で意味は先方も不明（P-4）。★4 以外なので正常終了に数えない★。

テストの書き方の注意（表2）:

• ★aggregateCleanStatsByFacility() → sumCleanStatsBuckets() → kpiFromCleanStats() を通して★ ReportKpi の value を確かめる（lib/db/__tests__/report-mapping.test.ts に新しい describe）。自前で割り算を書かない。
• 予定はすべて期間内・過去（now より前）にする。1施設でよい。前期（prev）は undefined。
• 「開始」した予定にだけレポート行を入れる。★「うち status=4」以外の行の status は表に書いた値（K5=5 / K6=6）、K1 の残り2行は 5 と 2 にする★（4 以外なら何でもよいが、テストの中で固定する）。面積は 100/100（K8 だけ 0/100）。
• エラー件数は errorCount の Map（本清掃 id → 件数）で渡す。K1 は2件を別々の予定に、K5 は3件を1つの予定に寄せてよい。
• ★K7 は latestReportByTimetableId() を通して★レポートの Map を作る（予定外＝clean_timetable_id: null の行が Map に入らないことまで含めて確かめる）。予定 ID が NULL のエラー行も errorCountByMainTimetable() を通して落ちることを1件足してよい。
• 生値の比較は toBe。★K5 の稼働率だけ toBeCloseTo(200 / 3, 10)★。
• ★追加で1件★: K1〜K8 のすべてで 稼働率 ≤ 出発成功率（正常終了は開始の部分集合）を確かめる。

表3（本書で表1 から導いたもの。★監督が正として確定（2026-10-05）★）

AS の期待値表のうち、task_area = 0 に当たる行だけが変わる。★他の行は変えない★。

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

段階0 — 着手前

1. git status が clean で、develop が 74cffd5 以降であること（.claude/worktrees/ ではなく本体で作業する）。
2. 行番号は 2026-10-05 の 74cffd5 で確かめたもの。★段階3b（P-7）が先に当たるとずれる★ので、記述（関数名・文）で探すこと。
3. npx tsc --noEmit -p . と npm test が通る状態から始める（通らなければ着手前に報告）。
4. ★robotErrorReport の読み取りを select で必要な列だけにする（§11 Q6）★。先方の DDL では robot_id が NULL 可になった（第11回 P-8 b）が、Prisma のスキーマは NOT NULL のまま。★robot_id と robot リレーションを読まなければ、NULL の行が入っても読み取りで落ちない★。grep -rn "robotErrorReport\." app lib で全部の読み取りを洗い、select を付ける（書き込み lib/db/robot-error-write.ts は対象外）。★prisma/schema.prisma は変えない★（db pull は監督が行う）。テスト: スタブに robot_id: null の行を混ぜても落ちないこと

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

1. lib/judge/__tests__/run-completion-rate.test.ts:
   • 冒頭コメントの表1（:13-27）の R9 を表1 の行に差し替え、R12 を足す。:8 の「★暫定★」と :11 の「task_area = 0 は null（分子にも分母にも入れない）」を「task_area = 0 は 0（P-5=B。第11回）」に直す。★「本書 §3 が正。変えないこと」と出典に本書を足す★
   • it.each（:74-86）の R9 を ["R9 対象面積0は 0%（P-5=B）", 10, 0, 0.0] に、R12 を足す
   • 表2 の M7・M8 は null を meanCleanRatio() に渡すテストなので ★そのまま★（null は「未実施＝レポート行が無い」の意味で残る）
2. lib/judge/__tests__/kpi.test.ts:
   • 冒頭の式（:13-22）を CLAUDE.md §4.2 の新しい式に直す
   • operationRate（:24-35）: 引数の意味を「正常終了の回数 ÷ 予定回数」に。値のテストは変えなくてよい
   • launchRate（:37-46）: :38-39 の「定刻出発85件」の例を「開始できた回数 ÷ 予定回数（時刻の条件なし）」に書き直す
   • ★errorRate（:100-109）を逆の仕様に直す★: 「分母は清掃予定回数」errorRate(9, 100) === 9／予定0は null／★上限で切らない★ errorRate(4, 3) が toBeCloseTo(400 / 3, 10)
   • ★isCompletedTask() のテストを足す★: undefined → false／status 4 → true／0・1・2・3・5・6・255 → false／★期待値の 4 は CLEAN_TASK_STATUS.completed から読む★
3. lib/db/__tests__/report-mapping.test.ts に ★表2 の K1〜K8 と「稼働率 ≤ 出発成功率」★を新しい describe で書く（§3 の注意どおり）
4. ★この時点ではテストが落ちる（isCompletedTask が無い・completed が無い・R9 が null を返す）のが正しい★。コミットはテストだけで1つ

段階2 — task_area = 0 を 0% にする（P-5）

2-1. 本体

lib/judge/kpi.ts:144-153 の runCompletionRate():

• if (report.task_area === 0) return 0;（★割る前に★。4-8）
• 戻り値の型を number にする（D1）
• docstring（:112-143）を直す:
  • :120-123「★★暫定（D-155。ユーザー判断「一旦B」）★★ — 第11回で…見直す」→ ★確定★（第11回 P-2=A「今の式のまま」・P-1「訂正後の clean_ratio 列もこの式と同じ値」。D-158）。「clean_ratio 列に戻すときはこの関数の中身だけを直す」「呼び出し側は行をそのまま渡すこと（D6）」は ★残す★（1関数に閉じ込める作法として今も正しい）
  • :125-126「task_area === 0 は null（…暫定・第11回で確認）」→ ★0（P-5=B。第11回）★。★clean_area > 0 でも 0★（D2）。旧は null だったことを1行
  • :142 の @returns から「task_area === 0 なら null」を消す
• 冒頭（:4-24）の :12 の「（暫定）」を「（第11回で確定。D-158）」に

lib/config/index.ts:27-36 の RUN_COMPLETION_RATE の docstring: :34-35 の「暫定…第11回で…見直す」を ★確定（第11回 P-2=A。D-158）★ に。★値（cap: 100 / decimals: 1）は変えない★。

2-2. 「null なら足さない」分岐を消す（★runCompletionRate() の戻りを直接受けている所だけ★）

2-3. 説明を直す（★動作は変わらない。null の意味が「未実施だけ」に戻ったことを書く★）

★最後に次の grep を流し、残ったものが「経緯（旧: …）」の説明だけになっていること★:

grep -rn "task_area = 0\|task_area === 0\|task_area=0\|task_area が 0" app lib components d-watch-api.yaml docs/fixtures.md --include=*.ts --include=*.tsx --include=*.yaml --include=*.md | grep -v "lib/generated" | grep -v __tests__

2-4. テストを直す（★面積から完了率を作っているテストだけ期待値が変わる★）

段階3 — 当期の KPI をサマリと同じ式にする（P-6）

3-1. 判定層（lib/judge/kpi.ts）

1. 冒頭（:4-24）の式を CLAUDE.md §4.2（CLAUDE.md:161-166）と同じ4行に直す。「★3つの率はサマリと同じ式（第11回 P-6）★」と、旧の式（実施回数 ÷ 予定・定刻出発 ÷ 予定・エラー ÷ 実施）を1行で残す
2. operationRate()（:32-35）: 引数を (completed, planned) に。docstring「稼働率 = 正常終了（status = 4）の回数 ÷ 清掃予定回数（P-6=A）」
3. launchRate()（:37-40）: 引数を (started, planned) に。docstring「出発成功率 = 開始できた回数（レポート行がある回数）÷ 清掃予定回数。★時刻の条件なし（P-6=A）★」
4. errorRate()（:155-158）: 引数を (errors, planned) に。docstring「エラー発生率 = エラー発生回数 ÷ ★清掃予定回数★（P-6=B）。★上限で切らない（D9）★。旧: 分母は実施回数」
5. ★isCompletedTask() を足す★（D5）:

   import { CLEAN_TASK_STATUS, FACILITY_STATUS_THRESHOLDS, RUN_COMPLETION_RATE } from "@/lib/config";
   /** その清掃が正常終了したか（稼働率の分子。P-6=A）。★status だけで決める。面積は見ない★ */
   export function isCompletedTask(report: { status: number } | undefined): boolean {
     return report !== undefined && report.status === CLEAN_TASK_STATUS.completed;
   }

   docstring に: 出所（第11回 P-6=A・送付版 :87）／★「最新の1行」で見る★（呼び出し側が latestReportByTimetableId() で選んだ行を渡す）／★◎○△× の判定には使わない★（D-155 項2 は変わらない）／★面積は見ない（表2 K8）★
6. judgeFacilityStatus()（:178-203）は ★中身を変えない★。ただし docstring に「★当期の稼働率は P-6 で『正常終了 ÷ 予定』になった（以前は出発成功率と同じ値）。当期の施設ステータスは以前より低めに出る★」と1行足す

3-2. 集計（lib/db/report-mapping.ts）

1. CleanStatsBucket（:245-299）:
   • ★冒頭の docstring :245-256 を書き直す★（D-157 の :249 もここで直る。段階5 を参照）。新しい中身:
     • 当期の3つの率はサマリと同じ式（第11回 P-6。D-158）。どれも ★分母は planned★
     • planned ＝ 期間内・過去の本清掃の予定の数／executed ＝ そのうちレポート行がある数（★開始できた回数＝出発成功率の分子★）／★completed ＝ そのうち最新のレポート行の status が正常終了の数（稼働率の分子）★／errorCount ＝ エラーの数（エラー発生率の分子）
     • ★時刻の条件は無い★（P-6=A）。clean_task_reports.started_at は、予定のある清掃では予定の start_at と同じ値が入る（ユーザー回答 2026-10-05。D-155 項5 の N-9）ので、★定刻かどうかはそもそも区別できない★
     • ★不変条件: completed ≤ executed ≤ planned★（だから 稼働率 ≤ 出発成功率 ≤ 100）
   • executed（:260）の docstring「清掃実施回数（＝定刻出発回数。上記コメント参照）」→「開始できた回数（レポート行がある回数）。出発成功率の分子」
   • ★completed: number を足す★（executed の直後）
   • errorCount（:266-282）の docstring: :278-280 は段階5 の文に差し替える。★分母は予定回数★になったことを書く
2. emptyCleanStatsBucket()（:301-311）・addCleanStats()（:313-323）に completed を足す
3. CleanStatsReportLike（:394-416）に ★status: number★ を足す（D7）。docstring に「★status は稼働率の分子（isCompletedTask()）にだけ使う★」
4. aggregateCleanStatsByFacility()（:460-505）:
   • const completed = executed && isCompletedTask(report);（isCompletedTask は @/lib/judge から import。:16-24 の import に足す）
   • completed: bucket.completed + (completed ? 1 : 0),
   • ★未来の予定は completed にも足さない★（:480-483 の continue の前に何も足さない。D10）
   • docstring（:418-459）の :422-424「稼働率・出発成功率が実際より下振れする」は ★エラー発生率も★ に
5. kpiFromCleanStats()（:507-535）:

   operation_rate: toKpiValue(operationRate(bucket.completed, bucket.planned), prev?.operation_ratio ?? null),
   launch_rate:    toKpiValue(launchRate(bucket.executed, bucket.planned),     prev?.launch_ratio ?? null),
   completion_rate: toKpiValue(meanCleanRatio(bucket), prev?.clean_ratio ?? null),   // ★変えない★
   error_rate:     toKpiValue(errorRate(bucket.errorCount, bucket.planned),    prev?.error_ratio ?? null),

   docstring :510-511「★エラー発生率の分母は「実施回数」のまま★（予定回数にしない）」は ★逆の仕様★。「★3つとも分母は予定回数（第11回 P-6。サマリと同じ）★」に
6. countMainErrorTypesInRange() の docstring :946-947「エラー率の分母は「清掃実施回数」…なので、分子も清掃を基準にする」→「エラー率の分母は清掃予定回数（P-6=B）なので、分子も予定（本清掃）を基準にする」。★中身は変えない★（期間の帰属は本清掃の start_at のまま）

3-3. データ層（lib/db/index.ts）

• reportKpis()（:2042-2140）・facilityPerformance()（:2330-2400）は ★コードを変えない★（findMany に select が無いので status は載っている。D7）。aggregateCleanStatsByFacility() の引数も変わらない
• errorBreakdown() の docstring :2493「エラー率の分母が「清掃実施回数」なので」→「清掃予定回数（P-6=B）なので」

3-4. 説明を直す

★lib/fixtures/reports.ts の KPI（:159-373）は作り値で、当期も「顧客単位の集計値」として置いてある★（lib/db/fixture-reports.ts:68-69）ので ★式を変えても画面の数字は変わらない★。 ★値は1か所だけ直す（§11 Q5）★: 新しい式では ★稼働率 ≤ 出発成功率★ が必ず成り立つが、:256-257（施設6 バリューマート南丘駅前店）だけが 稼働率 72.4（前期 70.1）＞ 出発成功率 65.0（前期 68.0）になっている（2026-10-05 監督が全行を走査。他の行は成り立っている）。

• ★出発成功率の側を上げる★: launch_rate: toKpiValue(65.0, 68.0) → ★toKpiValue(75.0, 71.0)★。★稼働率（72.4 / 70.1）・status・並び順は変えない★
• ★稼働率の側を下げないこと★（§11 Q5 の当初の例「72.4 → 60.5」は採らない）: 施設別成績は稼働率の昇順に並べてあり、 lib/fixtures/__tests__/reports.test.ts:212（「稼働率の昇順（ワースト順）に並んでいる」）が守っている。 60.5 にすると直前の施設9（68.0。:245）より小さくなり、このテストが落ちる。並べ替えると画面のワースト1位が変わる
• ★lib/fixtures/__tests__/reports.test.ts にテストを1件足す★: 施設別成績の全行と KPI の全期間で、operation_rate と launch_rate が ともに数値なら value も prev も ★稼働率 ≤ 出発成功率★（作り値が新しい式の不変条件を破らないことを固定する）
• ★65.0 / 68.0 を期待値に持つテストは無い★（2026-10-05 監督が grep で確認）。落ちるテストが出たら値を確かめてから報告する

段階3b — 予定を clean_timetables と clean_timetable_histories の両方から読む（P-7。D-158 項4）

★予定（本清掃・事前チェックの行）は2つの表を合わせて読む★。★同じ id は1件として扱い、clean_timetables 側を採る★。 ★実績は clean_task_reports だけのまま★（D-151。clean_statuses / clean_status_histories は読まない）。 ★期間の絞り込みは今と同じく start_at★（end_at で絞る経路は今も無い。足さない）。

3b-0. 2つのモデルの違い（prisma/schema.prisma:587-619 / :621-650）

★アプリが使う列は全部、履歴側にもある★。★where に inactive を書くと履歴側で型エラーになる★（それでよい。書かないこと）。 ★他のモデルから clean_timetables へのリレーションは無い★（clean_task_reports / robot_error_reports / clean_statuses の clean_timetable_id は FK 無し）ので、include 経由の読みは0件。

3b-1. 読んでいる箇所（★全12本。これ以外に無いことを grep -rn "cleanTimetable\." app lib で確かめる★）

★count / groupBy / skip / take で clean_timetables を読む箇所は0件★（take/skip は P1 では SQL に降ろさない決定。lib/db/index.ts:743-745）。 ★/schedules は clean_schedules だけを読む★（lib/db/index.ts:1759-1797）。予定表（timetable）は読まない → ★本段階の対象外★。

★12 は今のままだと静かに壊れる★: レポートの clean_timetable_id が履歴にしか無いと「本清掃に紐づかない行」になり、★完了率・実施回数から黙って落ちる★（面積だけ残る）。

3b-2. 共通の読み口を1つ作る（lib/db/timetable-source.ts。新規）

1. ★純粋関数★ mergeTimetableRows<T extends { id: bigint }>(mainRows: T[], historyRows: T[], shadowedIds: ReadonlySet<string>): T[]
   • mainRows を全部採る。historyRows は ★id.toString() が mainRows にも shadowedIds にも無いものだけ★足す
   • ★historyRows の中で同じ id が2回出たら例外★（履歴の主キーは id なので起きない。起きたら呼び出しの誤り）
   • ★並び順は保証しない★（下の 3 を参照）
2. findTimetables(prisma, args) — ★同じ args を cleanTimetable.findMany と cleanTimetableHistory.findMany に Promise.all で渡す★
   • args の型は ★両モデルの FindMany 引数の両方を満たすもの★（satisfies で両方に通す、または ConsecutiveSourcePrisma（consecutive-source.ts:105）と同じ「最小の形」の interface を書く）。★where を2回書かないこと★（片方だけ直すと静かにずれる）
   • ★args.select / args.include には id が必ず含まれること★（型で強制する）
   • ★「clean_timetables 側が勝つ」を厳密に守るための影チェック★: 履歴だけに出た id を chunkForInClause() で分けて cleanTimetable.findMany({ where: { id: { in } }, select: { id: true } }) を撃ち、★当たった id を shadowedIds にする★。 理由: 同じ id で start_at や precheck が2表で違うと、clean_timetables 側は where から外れ、履歴側だけが当たる。影チェックが無いと★負けるはずの履歴の行が出る★。★履歴だけの id が0件ならクエリを撃たない★
   • 戻りは mergeTimetableRows() の結果
3. orderBy: ★渡してよいが、合わせた後の順序は保証されない★。1（cleanLogs()）は :1017-1022 の .sort() が正なので問題ない。★他の11本は順序に依存しない★（集計・Map 化・ルート側の sortPrechecks()）。docstring の「orderBy はその写し」（:798-803）に「2表を合わせるので DB の順序はもう写しにもならない」と1行足す
4. ★count / groupBy を2表にまたがって書かない★（同じ id の重複を引けない）。必要になったら ★findTimetables() で id を取ってから数える★。今は該当0件
5. precheckItemById() 用に findTimetableById(prisma, id, select) を足す（clean_timetables を findUnique → 無ければ cleanTimetableHistory.findUnique）。7 は findTimetableById(row.parent_id) を引き、precheck === 本清掃 を JS で確かめる（findFirst の条件をそのまま移す）

3b-3. 各経路の書き換え

• 1・3・4・8・9・10・11: prisma.cleanTimetable.findMany(args) → findTimetables(prisma, args)。★where の中身は1文字も変えない★
• 2・5（parent_id IN）: 塊ごとに findTimetables() を呼び、★.flat() の後にもう一度 id で重複を落とす★ （2表で parent_id が違う同じ id は別の塊に入りうるので、塊の中の重複落としだけでは足りない）。 findTimetables() に { dedupeAcrossChunks } を持たせるより、★timetable-source.ts に findTimetablesByChunks(prisma, chunks, buildArgs) を置き、全塊を2表とも引いてから1回だけ mergeTimetableRows() を通す★ほうが規則が1箇所で済む
• 6・7: 3b-2 の 5
• 12: CleanAreaStatsSourcePrisma.cleanTimetable（clean-area-source.ts:147-153）の隣に cleanTimetableHistory を足し、findTimetables() を使う。★where: { id: { in }, precheck } は両表に同じものを渡す★
• 11: ConsecutiveSourcePrisma（consecutive-source.ts:105-125）に cleanTimetableHistory を足す
• robot_error_reports / clean_task_reports の引き直し（clean_timetable_id IN）は ★変えない★（合わせた後の id で引くので、履歴の予定に紐づく行も取れる）

3b-4. 性能

• ★往復は1本→2本（＋履歴だけの id があれば影チェック）★。Promise.all で並べる。両表とも start_at / facility_id / parent_id に索引あり（:612-617 / :641-648）
• ★古い予定が履歴へ移るなら、行の大半（保持2年）は履歴側★。★期間無指定の経路★（cleanLogs() の日付なし・CONSECUTIVE_RANGE_UNBOUNDED・12 の期間なし）は★履歴も全期間読む★。今と同じ性質なので新たに絞らないが、judge.* ログの行数が増えることを docstring に書く
• IN の分割は既存の chunkForInClause()（上限 DB_IN_CLAUSE_MAX_ITEMS = 1000。lib/config/index.ts:548）をそのまま使う

3b-5. fixtures とシード

• ★fixtures には予定の表の層が無い★（lib/fixtures/ は結合済みの CleanLogItem を持つ。lib/fixtures/clean-logs.ts:222 の history は★「過去の清掃ログ」の意味で、clean_timetable_histories とは無関係★。名前で取り違えないこと）。 → ★fixtures 版のデータソースは変えない★。USE_FIXTURES の true/false で数字は変わらない
• scripts/seed-local-db.ts: ★clean_timetable_histories を今は一切書かず、消してもいない★（:848-858）。
  1. cleanSchedule.deleteMany より前（:854 の隣）に cleanTimetableHistory.deleteMany({}) を足す（FK が clean_schedules に向いているため）
  2. 次の3種を入れる（★id は既存の採番と衝突しないことをコードで検査する。:1525-1532 の dangling 検査に履歴も足す★）: (a) ★履歴だけの予定★: 過去の本清掃1件とその事前チェック2行を clean_timetables に入れず履歴に入れる。clean_task_reports を1行紐づける (b) ★両方にある同じ予定（中身も同じ）★ (c) ★両方にある同じ id で中身が違う★（履歴側の start_at を1日ずらす）
  3. 末尾の件数ログ（:2062）に clean_timetable_histories= を足す

3b-6. テスト（★実装より先に書く★）

lib/db/__tests__/timetable-source.test.ts（新規。スタブの prisma で）:

既存のスタブ（★cleanTimetableHistory が無いと undefined で落ちる★）: app/api/{clean-logs,clean-logs/[id],dashboard,prechecks,prechecks/[id]/status,reports,clean-area}/__tests__/route.test.ts・lib/db/__tests__/{consecutive-source,clean-area-source,report-mapping}.test.ts。 履歴は空配列を返すスタブを足し、★calls.cleanTimetable の引数を見ているテストには calls.cleanTimetableHistory も同じ引数であることを足す★。 経路ごとに1本ずつ「履歴だけの予定が出る」ケースを足す（12 は「履歴だけの予定に紐づくレポートが完了率・実施回数に入る」）。

3b-7. 監督の決定（2026-10-05）

段階4 — 画面の見出し「屋号」を「顧客」にする（P-15）

4-1. i18n（lib/i18n.ts）— ★キーごと改名する（D12）★

• コメント :44-52 を書き直す: 「★第11回 P-15=B（customers は法人の単位）で確定。2026-10-05 に見出し語を『屋号』から『顧客』に変えた（D-158）★」。旧の経緯（2026-09-15「屋号でよいです…」）は1行で残す。★英語は仮（D13）★
• コメント :364 / :375 の 屋号 を 顧客 に（キー名を指しているため）
• :357 の 顧客を選んでください: "Select a customer" は ★そのまま★

4-2. 呼び出し側

• lib/hooks/use-classification-filter.ts:161 は t(ALL_CUSTOMERS_LABEL) なので ★直さなくてよい★
• ★t() に生の文字列 "屋号" を渡している所が他に無いこと★を最後に確かめる: grep -rn "\"屋号\|屋号\"\|'屋号" app lib components --include=*.ts --include=*.tsx | grep -v __tests__ が ★0件★

  4-3. データ・絞り込み条件の説明（★§11 Q2: 「顧客」にそろえる★）

P-15=B で customers は法人の単位と確定したので、「屋号（customers.id）」という説明は ★誤り★ になった。 ★次の行の中の「屋号」だけを「顧客」に直す★（所属屋号 → 所属顧客、屋号・施設は → 顧客・施設は など。★行の他の部分は変えない★）:

• lib/clean-area/query.ts:58・lib/clean-logs/query.ts:31・lib/ds-alerts/query.ts:25・lib/ds-devices/query.ts:21・lib/facilities/query.ts:28・ lib/prechecks/query.ts:32・lib/reports/query.ts:120・lib/schedules/query.ts:53・lib/api/master-id.ts:89 （どれも /** 屋号（\customers.id`）… */`）
• lib/types/index.ts:180 / :196 / :954 / :985 / :1299 / :1308-1310
• d-watch-api.yaml:1519-1520 / :1534 / :2086 / :2100-2101 / :2287

★経緯を書いた文（「旧: 屋号」「2026-09-15『屋号でよいです』」等）は残す★。★処理の理由を述べるコメント・fixtures の説明・テストは対象外★（§7 の表）。

• テスト lib/masters/__tests__/options.test.ts:157-181 の "全屋号" は ★引数で渡しているだけなので直さなくても通る★。直すなら "全顧客" に（任意）。"屋号A1" などはテスト用の名前なのでそのまま

段階5 — D-157 に控えた古いコメント4件（＋ status 6 の C5）

★どれもコメントだけで、動作は変わらない★（C5 も同じ）。行番号は 2026-10-05（74cffd5）で確かめた。

段階6 — 全体の確認

1. npx tsc --noEmit -p . — エラー0件
2. npm run lint — 指摘0件（重複キー・$queryRaw・any が無いこと）
3. npm test — ★全件通過★（表1・表2・表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 サーバーは必ず止める★
   • ★屋号→顧客★: 清掃詳細ログ・アラート・D-Sec ログ・D-Sec アラート・レポート・総清掃面積の6画面で、分類のセレクトの先頭が「全顧客」。総清掃面積の粒度タブと表の見出しが「顧客」。レポートで顧客を選ばずに KPI が 422 になる状態（fixtures は顧客4件）で「選べる顧客が4件あります」「顧客を選ぶ →」
   • ★JP/EN 切替★: EN で "All Customers" / "Customer" / "4 customers to choose from" / "Choose a customer"。★JP では幅が変わらないこと★（文字数が同じ）。★EN でツールバーが不自然に折り返さないこと★をデスクトップ幅とモバイル幅（375px）で見る。崩れていたら直さずに報告（4-12）
   • ★数字が変わらないこと★: fixtures には task_area = 0 で実施した行が無く（lib/db/fixture-clean-area.ts:20-25）、レポートの KPI は作り値（lib/fixtures/reports.ts）なので、★詳細ログ・エリア別詳細・総清掃面積・レポートの数字は変わらないのが正しい★。指示書AS 段階7-5 の境界値（施設2 = 90% ◎ / 施設3 = 90% ○ / 施設5 = 70% ○ / 施設8 = 10% △ / 施設9 = 10% × / 施設10 = 0% ×、エリア別詳細の施設7・1日前が全体 81% ○）がそのまま出ること
   • ★P-5・P-6 の効き目は画面では見えない★（上の理由）。★単体テスト（表1〜表3）で確かめる★。任意で、シードを入れたローカルDB（dwatch_local。USE_FIXTURES=false）のレポート当期で「稼働率 ≤ 出発成功率」になっていることを見てよい（★ステージングには向けない★）
6. 最後の grep（★0件になること★）:

   grep -rnE "status ?===? ?4([^0-9]|$)|定刻出発|清掃実施回数 ÷ 清掃予定|÷ 清掃実施回数" app lib components d-watch-api.yaml --include=*.ts --include=*.tsx --include=*.yaml | grep -v lib/generated
   grep -rn "t(\"屋号\|t(\"全屋号\|\"選べる屋号\|\"屋号を選ぶ\|選べる屋号がありません" app lib components --include=*.ts --include=*.tsx

7. 「屋号」の出現箇所の分類（2026-10-05。grep -rn "屋号" app lib components --include=*.ts --include=*.tsx。テストを除き約140件）

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

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

• CLAUDE.md / docs/decisions.md（監督が直す）
• prisma/schema.prisma / lib/generated/prisma/**（★DB の定義は TeamWorks の領域。CLAUDE.md §7★。P-8 の DDL 変更の取り込み（db pull）も本書ではやらない）
• docs/code-map.md（監督が直す）
• ★D-Security アラートの取得元（いまは control_error_histories）★ — robot_error_reports への切り替え（P-10）は ★次フェーズ★（D-158 当方の対応5）
• ★robot_error_reports の3区分（ロボット／制御盤／セキュリティ・清掃開始失敗）の見分け★ — ★次フェーズ★。error_type を推測で分類しない（CLAUDE.md §4.8）
• 4カラム UPDATE（status / comment / responded_at / resolved_at。指示書AT）
• kpiFromSummaryRatios() / SummaryRatios / periodOfSummaryRow()（lib/db/report-mapping.ts:99 付近・:218-241）
• meanCleanRatio() の中身・judgeGrade() / displayRate() / GRADE_THRESHOLDS / RUN_COMPLETION_RATE の値
• latestReportByTimetableId() / notExecutedFromReport() / isFutureSchedule() の中身（lib/db/clean-log-mapping.ts）
• launchFailedDaysInRun() / foldRescueDays() の中身（D3）
• scripts/seed-local-db.ts の ★接続先とガード★（lib/db/local-guard.ts を含む）
• d-watch-mock.jsx

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

• P-8〜P-10（エラーの集約・3区分・D-Sec アラートの取得元）— 次フェーズ
• 複数顧客の KPI の合算（出発成功率・エラー発生率は材料がそろった）— §11 Q3

11. 監督の決定（2026-10-05。D-158）

12. コミット

段階ごとに分ける（段階0 の 4 / 段階1 / 段階2 / 段階3 / 段階3b / 段階4 / 段階5）。★git add はファイルパスを明示する★（git add -A 禁止）。 メッセージには ★何を変えたか★ と ★なぜ（D-158。TeamWorks 第11回 P-5 / P-6 / P-15）★ を書く。★段階1 のコミットは「テストだけ（この時点では落ちる）」と明記する★。 ★分割 PR の作成とマージは daichi がレビューしてから行う★（D-154）。