# 指示書V — 連続問題日数を施設単位に揃え、当期KPIの分母から未来の予定を外す | 項目 | 内容 | |---|---| | 実行環境 | ★**Cursor 内の Claude が実装します**★（`.claude/commands/d-watch.md` の役割分担表を参照） | | 実行状態 | ★**完了（D-110。2026-09-11）**★ | | 実行順 | ★**指示書T（D-108。`327682e`）完了後のレビューで出た不具合2件 + それに伴うユーザー確定5件の修正**★。★指示書M / P / R / S / T / U が作った `lib/db/clean-log-mapping.ts` / `lib/db/report-mapping.ts` / `lib/db/index.ts` の上に積む作業★です。★★`prisma/schema.prisma` と `lib/fixtures/` は**1文字も変えません**★★が、★★`d-watch-api.yaml` / `lib/types/index.ts` / 画面（`components/features/reports/`）/ `scripts/seed-local-db.ts` は**変えます**★★（★決定1 と決定5。起草版から変わった点★）。★触るコードが重なる未実行の指示書は着手直前に自分で確認すること★ | | 対象 | ★**不具合2件 + ユーザー確定5件**★。★★中心は「既存の関数を呼ぶだけ」「分割キーを変えるだけ」ですが、★決定1 だけは API契約・型・画面まで波及します★★★ | | 取得する決定番号 | ★**着手直前に `grep -nE "^### D-(0\|1)[0-9][0-9]" docs/decisions.md \| tail -3` で最終番号を実測すること**★。★★`^### D-0` だけでは3桁台（D-100 以降）を拾えない★★。★2026-09-07 に `D-068` の二重採番が実際に起きています★。★★本改訂の5決定は**別担当が `D-109` として追記済み**（`docs/decisions.md:6328`。★未コミット★）★★なので、本書の実行記録は **`D-110`** の見込み★。★それでも必ず自分で実測してから採番すること★ | | 前提 | ★**D-026**（`docs/decisions.md:122`。★「連続」はカレンダー日ではなくスケジュール存在日の連続★）★ / ★**D-103**（`:5222`。`consecutive_problem_days` はA案 ＝ `computeConsecutiveProblemDays()` を流用する）★ / ★**D-106**（`:5830`。★`clean_timetables` には1週間分の予定がまとめて登録される＝**未来の本清掃行が常時存在する**★）★ / ★**D-107**（`:5993`。指示書U の実行記録。★`isFutureSchedule()` は必須★）★ / ★**D-108**（`:6218`。指示書T の実行記録。★項3 が本書で直す `String(facility_id)` 詰め替えの出所★・★項7 に**誤りがある**（★D-109 §6 で訂正済み。段階7-2 で確認して参照する★）★）★ / ★★**D-109**（`:6328`。★本書に織り込んだ**ユーザー確定5決定**（2026-09-11）そのもの★。★着手時に行番号と内容を実測し、本書と食い違っていたら**実装を止めて確認を求めること**★）★★ / **D-102**（`:5139`。確定期間はサマリを読む・当期は詳細から算出）/ **D-091 項1**（`:3442`。猶予30分を当方で計算しない）/ **D-042**（`:226`。書き込み許可4カラム）/ **D-050**（`:308`。段階ごとに検証してからコミット）/ **D-056**（`:353`。`schema.prisma` は生成物）/ **D-077**（`:1847`。エラー値を変換しない）/ **D-089 項3・D-104**（★「その他」「不明」という語を使わない★） | | 段階数 | ★**8段階**★（段階0〜段階7）。★コミットは段階1 / 2 / 3 / 4 / 5 / 7 の**6つ**★ | | ★着手前確認★ | ★★**なし**★★ — ★判定の分かれ目（同一日に複数台の予定があるとき、**1台でも問題があればその日は問題日**／週の初めに施設を消さない／70.0 の扱い／正常終了行にも L3 が出ること／検証データを足すこと）は ★★すべてユーザーが 2026-09-11 に確定させています★★（後述「★ユーザー確定の5決定★」）。★★ユーザーの回答を待たずに段階0 から通しで実行してよい★★ | | 着手前の基準 | ★**着手直前に自分で `npm test` / `npx tsc --noEmit` / `npm run lint` を実行し、その実測値を基準にすること**★。★作成時点の実測（2026-09-11。★鵜呑みにしない★）: `npm test` = **45ファイル / 894テスト（全パス）** / `tsc` = **0** / `lint` = **0**★ | | 作成 | 2026-09-11（★改訂 2026-09-11。ユーザー確定5決定を反映★。作成時点の決定事項最終番号 **D-108**（★D-109 は別担当が `:6328` に追記済み・未コミット★）/ `docs/handoff.md` の最新は **追記32**（`docs/handoff.md:2662`）。★着手時に実測すること★） | > 実行後はこの表と、文書末尾の「実行状態」表を更新してください。 > ★**この指示書を読んでいるあなたへ**★ — `.claude/commands/d-watch.md` の「実装は Cursor 側」は > **2つの環境の役割分担**です。**Cursor の中で動いている Claude は実装担当**です。 > ★調査や改訂ではなく実装を行ってください。★ > ★★**うまくいかなければ段階の切れ目（コミット単位）で止めて構いません**★★ — > ★段階1（新ステータス）→ 段階2（当期の分母）→ 段階3（施設単位の連続日数）→ 段階4（70.0）→ > 段階5（検証データ）の順に、★どこで止めても単体で意味が通る形★に並べてあります★。 --- ## ★★冒頭に読むべきこと — 直すのは5つ★★ | # | 直すこと | 症状 / 理由 | 直し方 | |---|---|---|---| | ★1★ | ★★施設別パフォーマンスに「判定なし」ステータスを足す★★ | ★決定1 の手当て。★このあと#2 を入れると、週の初め・月の初めに `operation_rate` が `null` になる★。★現状 `judgeFacilityStatus(null)` は `"bad"` を返すので、★★全施設が赤い「要改善」バッジになる★★★ | ★`d-watch-api.yaml` の enum → 型 → `judgeFacilityStatus()` → 画面バッジの順に4つ目の値を足す★ | | ★2★ | ★★当期のKPIの分母に「まだ来ていない予定」が入る★★ | ★稼働率・出発成功率が実際より**低く**出る★。★実データでは常時1週間先までの本清掃行が存在する（D-106）ので、★★毎日発生する★★★ | ★`aggregateCleanStatsByFacility()` に `now` を渡し、★★未来の行は**バケットは作るが加算しない**★★★ | | ★3★ | ★★連続問題日数の集計単位が2画面で違う★★ | ★清掃詳細ログ（F-02）が ★**ロボット単位**★ で数えており、★`CLAUDE.md` §4.5 の R3/R4「**同一施設で**2日以上／3日以上連続」とずれている★★ | ★分割キーを `serial_number` → ★`facility_id`★ にし、★同一日は OR で1日に畳む★★ | | ★4★ | ★★完了率ちょうど 70.0 が「問題なし」になっている★★ | ★`CLAUDE.md` §4.1 は「△ = 10%以上70%以下」、§4.5 の R3/R4 は「△以下」★。★★70.0 は △ なので**問題あり**が正しい★★ | ★`isProblemCompletion()` を `<= GRADE_THRESHOLDS.good` 相当に直す★（★`judgeGrade()` は変えない★） | | ★5★ | ★★検証データが足りない★★ | ★「日替わりで別の台が問題 → 3日連続」を実データで再現できない★（★複数台の予定がある日が 2026-09-09 の1日しか無い★） | ★`scripts/seed-local-db.ts` に施設7 の複数日ぶんの複数台スケジュールと履歴を足す★ | --- ## ★★ユーザー確定の5決定（2026-09-11。★D-109（`docs/decisions.md:6328`）として別担当が台帳へ追記済み★）★★ ★★この5件は確定済みです。★★ ★迷ったらこの節に戻ること★。★★本書の他の記述とこの節が食い違っていたら、この節が正★★。 ### ★決定1 — 週の初め・月の初めに施設が一覧から消えるのを防ぐ★ ★起草版のまま（「範囲判定の直後に `continue`」）実装すると、★★実測で「日曜 00:30 に施設別パフォーマンスが 10施設 → 0施設」「1日 00:30 は今週も今月も 0施設」★★ になります★。 ★理由: `facilityPerformance()` の当期行は ★★バケットのキーからしか作られない★★（`lib/db/index.ts:1066` / `:1089`）ため、 その施設の当期予定が全部未来だと ★バケットごと生まれない★ → ★行が消える★。 ★★ユーザー回答（原文）★★: > ★Server・DB側では一度1週間分の予定を作成したら基本的に常にそれを保持してリクエストすると返してくる★ ★★確定した方針★★: - ★`aggregateCleanStatsByFacility()` は、★★期間内の行であれば**未来でもバケットを作る**★★★ - ★未来の行は `planned` / `executed` / `taskArea` / `cleanArea` / `errorCount` の ★**加算だけをスキップ**★ する★ - ★★起草版の「範囲判定の直後に `continue`」は**誤り**★★ — ★`continue` すると入れ物（バケット）が作られない★ - ★結果、週の初めは ★★`planned: 0` のバケットが並び、施設は消えない★★★。 ★稼働率・出発成功率は `null`（＝画面では「—」）になる★（`lib/judge/kpi.ts:19-23` が分母0で `null` を返す） ★★併せて必須の手当て（＝段階1）★★: - ★`judgeFacilityStatus()`（`lib/judge/kpi.ts:75-82`）が `operationRateValue === null` で `"bad"` を返す★。 ★このままだと ★★週の初めに全施設が「要改善」の赤バッジになる★★★ - ★★`null` のときは「判定なし」を返すように変える★★。★`FacilityStatus` に**4つ目の値**を足す★ （★名前は実装者判断★。★★「その他」「不明」という語は使わない★★ — D-089 項3 / D-104） - ★★API契約が先★★（`CLAUDE.md` §6 作業ルール1）: ★`d-watch-api.yaml` の enum を先に直してから★ ★型（`lib/types/index.ts`）→ 判定（`lib/judge/kpi.ts`）→ クエリ（`lib/reports/query.ts`）→ 画面（`components/features/reports/`）★ の順に追う - ★画面のバッジに4つ目の見た目（グレー等）を足す★。 ★★モックに無い表示を足すことになります★★（`d-watch-mock.jsx` は3値しか持たない） — ★★これは意図した逸脱であり、段階7 の記録に「モックに無い表示を足した」と明記すること★★ - ★★`FACILITY_STATUS_THRESHOLDS`（`lib/config/index.ts:159-164`）の閾値は変えない★★ ### ★決定2 — 同一ロボットが同じ日に2回清掃した場合も「1日」に畳む★ - ★現行は「2回とも失敗＝2日連続」★（`lib/db/__tests__/clean-log-mapping.test.ts:502-509` が固定している） - ★★施設×日で畳むので「1日」に統一する★★。★根拠は D-026「連続はスケジュール存在日の連続」＝**日単位**★ - ★★このテストは期待値を 2 → 1 に直す★★。★★意図した仕様変更であることをテスト名とコメントに書くこと★★ ### ★決定3 — 完了率ちょうど 70.0% は「問題あり」に直す★ - `isProblemCompletion()`（`lib/db/clean-log-mapping.ts:280-282`）が ★`< GRADE_THRESHOLDS.good`（＝ `< 70`）★ になっている - ★★`CLAUDE.md` §4.1 は「△ = 10%以上70%以下」、§4.5 の R3/R4 は「△以下」★★ → ★70.0 は △ なので問題あり★ - ★★`<= 70` 相当に直す★★。★★閾値は `lib/config/` の `GRADE_THRESHOLDS` から読む。`70` を直書きしない★★ - ★★`judgeGrade()`（`lib/judge/`）は変えないこと★★ — ★あちらは「○ = 70%超」で既に正しい★。 ★★今回直すのは「問題ありの日」の判定だけ★★ - ★実データへの影響（★実測済み 2026-09-11★）★: ★完了率ちょうど 70.0 の履歴は **1件**★ （`clean_timetable_id=1005` / ★施設5★ / 2026-09-10）。 ★★施設5 の期末連続日数が **0 → 2（L2）** に変わる★★（★前日 09-09 が未実施のため★） - ★`lib/db/__tests__/clean-log-mapping.test.ts:422` の `isProblemCompletion(70.0) === false` は **true** に変わる★ （★同ファイル `:404-414` の `it.each` 表の `[70.0, false]` も `[70.0, true]` に直す★） - ★fixtures（`lib/fixtures/clean-logs.ts:96`）は手書きで `consecutive_problem_days: 1` を与えており「△以下」派★。 ★★変更後は実装と整合する★★（★`lib/fixtures/clean-logs.ts:226` の生成式は `<` のままだが、 生成される率に 70.0 ちょうどは現れないので矛盾しない★） ### ★決定4 — 正常に終わった行にも L3 が出るのを許容する★ - ★施設単位にすると、★★完了率95%で正常終了した行にも R3/R4 が出ます★★★ - ★逆に、別の台のせいで施設の連続が2以上だと、★★その台にとって初回の出発失敗でも R1 が出なくなります★★★ （`lib/judge/advice.ts:61` の `consecutiveProblemDays <= 1` / `:71` の R3 / `:76` の R4） - ★★ユーザー承認済み。R3/R4 は「現場に行くか」の判断なので施設単位が正しい★★ - ★★この挙動を「意図した結果」として扱い、テストで固定すること★★（段階3 の (c) 表） ### ★決定5 — 検証データを足す★ - ★実測: ★★複数ロボットの施設は施設7（3台）だけ。しかも複数台の予定がある日は 2026-09-09 の1日だけ★★★ - ★施設5 は robots が2台いるが、section 106 に `clean_timetables` が1行も無く**実質1台**★ - ★★`scripts/seed-local-db.ts` に、施設7 の**複数日ぶんの複数台スケジュールと履歴**を足す★★。 ★ユーザー確定ケース（★1日目Aが問題 / 2日目Bが問題 / 3日目Aが問題 → 3日連続★）を ★★そのまま再現できる形にする★★ - ★★シードは冪等を保つこと★★（★乱数を使わない・id を明示採番する・既存行のローテーションをずらさない★） - ★★`lib/fixtures/` は1行も変更しない★★ --- ## ★不具合A — 当期のKPIの分母に「まだ来ていない予定」が入る（＝決定1・決定2の前半）★ ### 現状（★2026-09-11 実測★） `lib/db/report-mapping.ts` の `aggregateCleanStatsByFacility()`（★`lib/db/report-mapping.ts:170`★）は ★期間の範囲判定しかしていません★: ```ts const jstDate = toJstIso(row.start_at).slice(0, 10); if (jstDate < range.from || jstDate > range.to) continue; // ← ここだけ ``` ★`isFutureSchedule()`（`lib/db/clean-log-mapping.ts:263`）を掛けていない★ため、 ★★「今週の予定だが、まだ時刻が来ていない清掃」も `planned`（分母）に入ります★★。 ★実施していないので `executed`（分子）には入りません★ → ★稼働率・出発成功率が下がる★。 ### ★なぜ「毎日発生する」のか★ - ★`clean_timetables` には ★**1週間分の清掃予定がまとめて登録される**★（★ユーザー回答 2026-09-10。D-106★） - ★つまり実データでは ★**最大7日先までの本清掃行が常時DBに存在する**★ - ★今週の分母には「今日より後の今週ぶん」が丸ごと入る★ → ★週の頭ほど大きく下振れする★ ### ★非対称になっていることが問題の本体★ ★同じ `facilityPerformance()` の中で、★★連続日数の側だけは既に除外しています★★★（`lib/db/index.ts:934`）: ```ts const consecutiveEntries = mainRows .filter((row) => !isFutureSchedule(row.start_at, now)) // ← 除外している ``` ★`cleanLogs()`（`lib/db/index.ts:292`）と `prechecks()`（`:500`）も除外済み★です。 ★★除外していないのは `aggregateCleanStatsByFacility()` だけ★★ — ★同じ1つのメソッドの中で、連続日数は未来を外し、KPIは外していない★という状態です。 ### ★★ただし「行ごと捨てる」のは誤り（決定1）★★ ★`cleanLogs()` / `prechecks()` は「行を返さない」で正しい★（★一覧に未来の予定を出さないため★）。 ★★しかし `aggregateCleanStatsByFacility()` の戻り値は「施設 → バケット」の `Map` であり、 このキーが `facilityPerformance()` の**当期行そのもの**になります★★（`lib/db/index.ts:1066` / `:1089`）。 ★★したがって「未来の行しか無い施設」のバケットを作らないと、その施設が一覧から消えます★★ — ★週の初め（日曜）・月の初め（1日）に**全施設が消える**★。★実測済み★。 ★★正しい実装★★: ```ts // 範囲外だけ捨てる（バケットも作らない） if (jstDate < range.from || jstDate > range.to) continue; const facilityId = Number(row.facility_id); const bucket = result.get(facilityId) ?? emptyCleanStatsBucket(); // ★未来の予定は「期間内にある」ので★バケットは作る★が、★数えない★（決定1） if (isFutureSchedule(row.start_at, now)) { result.set(facilityId, bucket); continue; } // …以降は現状どおり加算する ``` ★★上の形（`result.set()` してから `continue`）でなくてもよい★★ — ★「未来の行でもバケットが必ず存在し、かつ1つも加算されない」ことが満たせれば書き方は実装者判断★。 ### ★実測での影響★ ★★作成時点のローカルDB（`dwatch_local`）には未来の本清掃行が **0件** です★★ （`SELECT COUNT(*) FROM clean_timetables WHERE precheck=0 AND start_at > NOW();` → **0**。 `MAX(start_at)` = **2026-09-10 18:00**）。 ★★つまり**今このままでは症状が出ません**★★ — ★段階6 で未来行を一時的に投入して実測すること★。 ★ユーザーの実測（2026-09-10）★: ★翌日の予定を12施設ぶん足すと稼働率・出発成功率が ★**78.57% → 55.00%**★ に落ちた★。 ★作成時点の当週（2026-09-06〜09-12）の素の値は `planned` = **26** / `executed` = **20**（= 76.92%）★ （★実測。着手時に自分で取り直すこと★）。 ### ★確定期間（サマリ由来）には影響しない★ ★`kpiFromSummaryRatios()` は TeamWorks のサマリ値をそのまま使うだけ（D-102）★なので無関係です。 ★★確定期間の値を当方の計算で上書きしないこと★★（禁止事項9）。 --- ## ★不具合B — 連続問題日数の集計単位が2画面で違う（＝決定2・決定4）★ ### ★仕様（`CLAUDE.md` §4.5）は施設単位★ | # | 条件 | |---|---| | R3 | ★**同一施設で**2日以上連続（出発失敗 or △以下）★ | | R4 | ★**同一施設で**3日以上連続（出発失敗 or △以下）★ | ★★「同一施設で」と明記されています。★★ ### 現状（★2026-09-11 実測★） | 画面 | 実装 | 分割キー | 仕様との一致 | |---|---|---|---| | ★レポート（F-04）★ | `lib/db/index.ts:934-946` | ★`String(row.facility_id)` を `serial_number` の欄に詰めている★ | ★**施設単位＝仕様どおり**★ | | ★清掃詳細ログ（F-02）★ | `lib/db/index.ts:348` → `computeConsecutiveProblemDays()`（`lib/db/clean-log-mapping.ts:317-325`） | ★`row.serial_number` ＝ ★**ロボット単位**★★ | ★★**仕様とずれている。こちらを直す**★★ | `lib/db/clean-log-mapping.ts:320-325`（★実測。原文★）: ```ts const bySection = new Map(); for (const row of rows) { const list = bySection.get(row.serial_number); // ← ロボット単位 if (list) list.push(row); else bySection.set(row.serial_number, [row]); } ``` ★「P1 は 1清掃エリア = 1ロボットなので `serial_number` で代用できる」（`ConsecutiveInput` の docstring） という前提で書かれていますが、★★**1施設に複数の清掃エリア（＝複数台）がある**★★ので代用になっていません★。 ### ★★ユーザーが確定させた判定（2026-09-11）— A案★★ ★★ユーザーの回答（原文）★★: > 2台のうち 1日目Aが問題 / 2日目Bが問題 / 3日目Aが問題 でも ★3日連続で問題発生と記録する★ ★★→ 同じ日に複数台の予定があるとき、**1台でも問題があればその日は「問題があった日」**とする（A案）★★ | 案 | 内容 | 採否 | |---|---|---| | ★**A** ✅★ | ★同一日の複数行を **OR** で畳み、1台でも問題ならその日は問題日★ | ★★**採用（ユーザー確定）**★★ | | B | ★全台が問題のときだけ問題日とする（AND）★ | ★**不採用**★ — ★★3台ある施設がほぼ永久にエスカレーションしなくなる★★ | ★★同じ畳み込みが「同一ロボットが同じ日に2回清掃した」ケースにも効きます★★（★決定2★）— ★現行テスト（`lib/db/__tests__/clean-log-mapping.test.ts:502-509`）が「2回とも失敗＝2日連続」を固定しているが、 ★★D-026（連続はスケジュール**存在日**の連続＝日単位）に照らして誤り★★なので ★期待値を 2 → 1 に直す★。 ### ★修正方針（これをそのまま実装すること）★ 1. ★`ConsecutiveInput` の分割キーを ★**`facility_id`**★ にする★ （★`serial_number: string` を `facility_id: number` に置き換える★。 ★`cleanLogs()` の `drafts`（`lib/db/index.ts:329` 付近）は既に `facility_id: Number(row.facility_id)` を 持っているので、呼び出し側は何も足さなくてよい★）。 2. ★★同一日に複数行があるとき、`isProblem` を **OR** で畳んでから `countConsecutiveProblemDays()` に渡す★★。 ★同関数（`lib/judge/escalation.ts:32`）の契約は「★スケジュール存在日1日分の結果★を日付昇順で渡す」＝ ★**1日1エントリ**★です。★★今は1行1エントリで渡しているので、同じ日付の要素が3つあると 「3日連続」と数えてしまいます★★（落とし穴1）。 3. ★★畳み込みも純粋関数として切り出し、テストで固定すること★★（例: `foldProblemDaysByDate()`）。 ★`lib/judge/` ではなく `lib/db/clean-log-mapping.ts` に置くこと★ — ★「どの日がスケジュール存在日か」の判断はデータ取得側の責任、という `lib/judge/escalation.ts` の契約（`:11-16`）どおり★。 ★★畳みは `computeConsecutiveProblemDays()` の**内部だけ**で行うこと★★ — ★呼び出し側でやると規則が2箇所に散る（D-103）★。 4. ★★戻り値は現状どおり「行id → 連続日数」の `Map`★★。 ★同じ日の全行に同じ値が入る★（★これが「行ごとに違う値が入る」現状との違い★）。 5. ★レポート側（`lib/db/index.ts` の `facilityPerformance()`）の**集計単位は変えない**★ （★既に施設単位で正しい★）。ただし ★`serial_number: String(row.facility_id)`（`:940`）という 詰め替えは紛らわしいので消し、★分割キーを明示的なフィールド名で渡す形に整える★★。 ★★これは動作を変えない整理です★★（同じ値で同じ分割になる）。 6. ★★`countConsecutiveProblemDays()`（`lib/judge/escalation.ts`）は**1文字も変えない**★★。 ### ★★注意: レポート側の**値**も変わります（意図した変化）★★ ★上の5は「集計単位を変えない」という話であり、★★2 の日単位畳み込みは レポート側の**値**にも効きます★★★。★同じバグ（同一日の複数行を複数日と数える）の修正なので、 ★★意図した変化として受け入れ、段階7 で記録すること★★。 ★実測（2026-09-11。ローカルDB。★段階3 まで適用した時点の期待値★）★: | 施設 | 日 | 行 | 完了率 | 現状の値 | ★段階3 後の期待値★ | |---|---|---|---|---|---| | ★施設7★ | 2026-09-09 | `id=1026`（section 107） | 62.0（★問題★） | 1 | ★1★ | | ★施設7★ | 2026-09-09 | `id=1027`（section 108） | 94.0 | ★0★ | ★★1★★ | | ★施設7★ | 2026-09-09 | `id=1028`（section 109） | 88.0 | ★0★ | ★★1★★ | - ★施設7 の前のスケジュール存在日は 2026-09-04（完了率 94.7 ＝ 問題なし）★なので ★連続は 1 日★ - ★レポート側★: `consecutiveProblemDaysAtPeriodEnd()`（`lib/db/report-mapping.ts:262`）は 「期間内の最終ログ」＝ `id=1028`（17:00）を選ぶため、 ★★施設7 の当週（2026-09-06〜09-12）・当月の `consecutive_problem_days` が **0 → 1** になります★★ - ★★段階4（70.0）を入れると、さらに**施設5** の当週・当月が **0 → 2** に変わります★★（決定3） - ★★段階5（検証データ）を入れると、さらに**施設7 が 1 → 4** に変わります★★ （★新しく足す3日ぶんが 09-09 の直前に連なるため。詳細は段階5★） - ★これ以外の施設・期間の値は変わりません★（★同一日に複数行があるのは施設7 の 09-09 だけ★） --- ## ★調査済みの事実（★現物で裏を取ってから使うこと★）★ ### 1. ★★段階5 の前後で変わる数字 / 変わらない数字（★2026-09-11 実測★）★★ | # | 項目 | 値 | 本書での扱い | |---|---|---|---| | ★1★ | `npm test` | ★**45ファイル / 894テスト（全パス）**★ | ★★増える★★（★減らないこと★） | | ★2★ | `npx tsc --noEmit` | ★**0**★ | ★変わらない★ | | ★3★ | `npm run lint` | ★**0**★ | ★変わらない★ | | ★4★ | `db.cleanLogs()` の件数 | ★**253**★ | ★★段階5 で**増える**（本清掃行を足すため）★★。★段階4 までは 253 のまま★ | | ★5★ | `db.prechecks()` の件数 | ★**27**★（★`precheck` **14** / `launch_failed` **13**★） | ★★**変わらない**★★（★段階5 で足す行はすべて実施済み・事前チェック行を作らないため★） | | ★6★ | `clean_status_histories.clean_error` の分布 | ★`0`=225 / `1`=13 / `2`=5 / `3`=5 / `4`=5★ | ★★段階5 で `0` だけ増える★★（★1〜4 は増やさない★） | | ★7★ | `/reports` の `facility-performance` | ★確定期間 **11件** / 当期 **10件**（`limit` を上げたとき。既定 `limit=10` で切れる。D-108 項6）★ | ★★当期の件数は本書では**変わらない**★★（★決定1 でバケットを作るので、未来行があっても件数は減らない★） | | ★8★ | `continuous-problems` | ★**500（未実装）**★（第6歩の範囲。★本書では直さない★） | ★変わらない★ | ★★4 が段階4 までで1件でも変わっていたら実装が違います★★（★連続日数は「値」であって「件数」ではない★）。 ★着手直前に自分で実測して基準にすること★。 ### 2. ★ローカルDBの現状（★2026-09-11 実測★）★ | 項目 | 値 | |---|---| | `clean_timetables` の本清掃（`precheck=0`） | ★253行★ | | ★未来の本清掃（`start_at > NOW()`）★ | ★★**0行**★★（★だから不具合A は今このままでは再現しない★） | | `MIN(start_at)` / `MAX(start_at)`（本清掃） | ★2026-08-11 16:30 / 2026-09-10 18:00★ | | ★複数台の施設★ | ★**施設5 = 2台**（section 105 / 106）★ / ★**施設7 = 3台**（section 107 / 108 / 109）★ / 施設12 = 0台 | | ★施設5 の `clean_timetables`★ | ★section 105 のみ★（★2台あるが予定は1台ぶんしかない → **実質1台**★） | | ★施設7 の `clean_timetables`★ | ★2026-08-11〜09-04 は section 107 のみ / ★**2026-09-09 だけ 107 / 108 / 109 の3行**★★ | | ★完了率ちょうど 70.0 の履歴★ | ★★**1件**（`clean_timetable_id=1005` / 施設5 / 2026-09-10）★★（決定3） | | ★2画面の食い違い★ | ★★現状は**偶然0件**★★（★施設7 の 09-09 でレポート側が最終ログ `id=1028`（連続0）を選ぶため、詳細ログの `id=1028`（0）と一致してしまう★）。★★ログが増えれば食い違う★★ | ### 3. ★落とし穴（★踏むとテストが通ったまま壊れます★）★ | # | 落とし穴 | |---|---| | ★1★ | ★★`countConsecutiveProblemDays()` は「配列の要素」を後ろから数えます★★（`lib/judge/escalation.ts:32-41`）。★**日付を見ていません**★。★同じ日付の要素を3つ渡すと「3日連続」と返ります★。★★だから畳み込みが必須★★ — ★分割キーを `facility_id` に変えるだけで畳み込みを忘れると、★★施設7 の 09-09 が「3日連続」に化けます★★★ | | ★2★ | ★★`isFutureSchedule()` を消さないこと★★（D-107 設計3-C。★消すと未来の清掃が全部「出発失敗」になる★）。★本書は `isFutureSchedule()` を**足す**方向の作業であり、既存の3箇所（`:292` / `:500` / `:934`）は1文字も変えない★ | | ★3★ | ★★`now` を1回だけ作って使い回すこと★★。★行ごとに `new Date()` を作ると境界の行の扱いがぶれ、★テストが実行時刻で揺れます★★ | | ★4★ | ★★`isFutureSchedule()` の境界は `>`（`start_at === now` は「来ていない」に入れない）★★。★変えないこと★（`lib/db/clean-log-mapping.ts:263`） | | ★5★ | ★★猶予30分（`LAUNCH_GRACE_MINUTES`）を足さないこと★★（D-091 項1）。★足すと設定値を変えたときに過去のログの判定まで変わる★ | | ★6★ | ★★`aggregateCleanStatsByFacility()` で未来の行を `continue` で捨てないこと★★（★決定1★）。★★捨てるとバケットが作られず、週の初め・月の初めに施設が一覧から消えます★★。★捨ててよいのは「範囲外の行」だけ★ | | ★7★ | ★★`judgeFacilityStatus(null)` を `"bad"` のままにしないこと★★（★決定1★）。★決定1 の分母修正だけ入れて `judgeFacilityStatus()` を放置すると、★★週の初めに全施設が赤い「要改善」になります★★★。★だから段階1（ステータス）を段階2（分母）より**先**にやる★ | | ★8★ | ★★`??` を `||` に書き換えないこと★★（`0` が別の値に化けます） | | ★9★ | ★★判定は丸める前の生値で行うこと★★（`CLAUDE.md` §4.3。`completion_rate` に `Math.round()` を掛けない） | | ★10★ | ★`consecutiveProblemDaysAtPeriodEnd()`（`lib/db/report-mapping.ts:262`）の「期間内の最終ログを選ぶ」規則は変えないこと★。★畳み込み後は同じ日の全行が同じ値になるので、どの行が選ばれても結果は同じになります（決定性が上がるだけ）★ | | ★11★ | ★★段階4 で `judgeGrade()` を触らないこと★★（決定3）。★あちらの「○ = 70%超」は既に正しい★。★直すのは `isProblemCompletion()` だけ★ | | ★12★ | ★★段階5 で追加する行を既存のループの中に混ぜないこと★★。★`scripts/seed-local-db.ts` の本ループは `historyIndex`（`:869` 付近）と `errorReportCount` の**通番の剰余**で `clean_error` と対応状況を決定的に散らしています★ — ★★途中に行を差し込むと既存行の値が全部ずれ、`clean_error` 分布（225/13/5/5/5）が変わります★★。★★追加行は本ループの**後ろ**に独立したブロックとして足すこと★★ | | ★13★ | ★★段階5 で追加する行に事前チェック行・エラー行を作らないこと★★。★作ると `prechecks()` の 27 件が変わります★ | --- ## ★禁止事項（この指示書の全段階に効きます）★ | # | ★してはいけないこと★ | 理由 | |---|---|---| | ★1★ | ★★**`git add -A` を使うこと**★★ | `CLAUDE.md` §7。★過去に別作業の途中ファイルを巻き込む事故が起きている★。★★必ずファイルパスを明示すること★★ | | ★2★ | ★★**`README.md` / `docs/code-map.md` / `docs/handoff/管理画面_設計検討_20260910.md` / `.claude/worktrees/**` に触ること**★★ | ★★**すべて別作業のもの**★★。`README.md` は未コミットの変更あり、`docs/code-map.md` と `管理画面_設計検討_20260910.md` は未追跡（`git status` に `M` / `??` で出る）、`.claude/worktrees/**` には★別作業のコード地図★が入っている。★**本指示書のコミットに含めない・編集しない・削除しない**★ | | ★3★ | ★★**メインDBのスキーマ変更（`prisma migrate` / `db push` / `db pull` / `prisma/schema.prisma` の手書き）**★★ | `CLAUDE.md` §7 / D-056 / D-059。★★本書はスキーマ変更を1つも必要としません★★（★段階5 は**既存テーブルへの行追加**だけ★） | | ★4★ | ★★**書き込み許可4カラム（`status` / `comment` / `responded_at` / `resolved_at`）以外への DB 書き込み**★★ | D-042。★アプリコードの読み出しは**読むだけ**★。★段階5 の追加行は `scripts/seed-local-db.ts`（＝ローカル検証用シード）からの投入であり、アプリの実行時書き込みではない★。★段階6 の検証用 INSERT は `dwatch_local` の**一時行**のみ（★必ず削除する★）。★メインDB / `dwatch_ddl` に接続しないこと★ | | ★5★ | ★★**閾値（90/70/10、猶予30分、L2=2日/L3=3日）をハードコードすること**★★ | `CLAUDE.md` §7。★`lib/config/` から読む★。★★段階4 も `GRADE_THRESHOLDS.good` から読むこと。`70` を直書きしない★★ | | ★6★ | ★★**表示用に丸めた値で判定すること**★★ | `CLAUDE.md` §4.3 / 落とし穴9 | | ★7★ | ★★**`isFutureSchedule()` を消すこと・猶予を足すこと・境界（`>`）を変えること**★★ | D-107 設計4 / 落とし穴2・4・5。★★消すと未来の清掃が全部「出発失敗」になります★★ | | ★8★ | ★★**レポート側の連続日数の「施設単位」を崩すこと**★★ | `CLAUDE.md` §4.5（R3/R4 は「同一施設で」）/ D-103。★`facilityPerformance()` の分割単位は施設のまま★。★整えるのは**渡し方（フィールド名）だけ**★ | | ★9★ | ★★**確定期間（サマリ由来）の値を当方の計算で上書きすること**★★ | D-102 / `CLAUDE.md` §2。★`kpiFromSummaryRatios()` に手を付けない★ | | ★10★ | ★**`prisma/schema.prisma` / `lib/fixtures/` / `lib/reports/query.ts` の絞り込みロジック / APIルート（`app/api/`）の処理 を変更すること**★ | ★★本書が触ってよいのは、データ層の内部＋「判定なし」ステータスの追加に必要な最小限だけ★★。★`lib/reports/query.ts` は ★**`FACILITY_STATUS_FILTERS` の配列に4つ目の値を足すだけ**★（`:29-34`）。★`filterFacilityPerformanceByStatus()`（`:176`）の実装は汎用なので触らない★ | | ★11★ | ★**`prismaSource` の `facilities` / `schedules` / `dsDevices` / `dsAlerts` / `errorBreakdown` / `continuousProblems` / 点検記録2本に手を付けること**★ | ★範囲外★。★触るのは `cleanLogs` / `reportKpis` / `facilityPerformance` の3本の**内部**だけ★ | | ★12★ | ★**`lib/db/prisma.ts` / `local-guard.ts` / `use-fixtures.ts` / `ds-status.ts` / `precheck-mapping.ts` を変更すること**★ | ★完成しており、そのまま効く★ | | ★13★ | ★**テストを DB 依存にすること**★ | ★遅く・不安定になり、DB が空の環境で落ちる★。★テストは純粋関数と手書きの入力だけ★ | | ★14★ | ★**`continuousProblems`（第6歩）を実装すること**★ | ★別の指示書の範囲★。★`USE_FIXTURES=false` で 500 のままが正しい★ | | ★15★ | ★**タイムゾーン（DBがJSTかUTCか）の話に手を付けること**★ | ★★別件★★（D-106 項8）。★`toJstIso()` の既存の使い方を1文字も変えない★ | | ★16★ | ★**`npm run dev` を Bash で起動すること**★ | ★Browser pane の `preview_start` を使う★。★無ければ curl で代替し、その旨を記録する★ | | ★17★ | ★**`.env.local` をコミットすること / DB の認証情報を文書やコードに書くこと**★ | `CLAUDE.md` §9.3。★検証後は `USE_FIXTURES=true` に戻す★ | | ★18★ | ★**エラー種別を7分類に変換すること・「その他」「不明」という語を使うこと**★ | D-077 / D-089 項3 / D-104 項2。★★段階1 で足す4つ目のステータス名にも効きます★★。★段階7 の記録訂正でも語彙を作らないこと★ | | ★19★ | ★**`FACILITY_STATUS_THRESHOLDS` の閾値（good=90 / warning=75）を変えること**★ | ★決定1 の明示指示★。★足すのは「分母0のときの4つ目の値」だけで、閾値そのものは触らない★ | --- ## 作業の順序（★崩さないこと★） ★段階0（前提の確認。★読むだけ・コミットなし★） → 段階1（★決定1 の手当て★: 「判定なし」ステータスを足す。★API契約 → 型 → 判定 → 画面★） → 段階2（★不具合A★: 当期の分母から未来を外す。★バケットは作る★） → 段階3（★不具合B★: 連続日数を施設単位にし、同一日を OR で畳む） → 段階4（★決定3★: 完了率ちょうど 70.0 を「問題あり」にする） → 段階5（★決定5★: 検証データをシードに足して再シード） → 段階6（実測での検証。★コミットなし★） → 段階7（記録と push）★ ★★段階1・2・3・4・5・7 でそれぞれ1コミット（計6コミット）★★。 ★**段階ごとに `npx tsc --noEmit` / `npm run lint` / `npm test` を実行し、 通ってからコミットすること**★（D-050。`docs/decisions.md:308`）。 > ★★**期待値表 → テスト → 実装 の順序を崩さないこと**★★（`CLAUDE.md` §6-2 / §9.4）。 > ★★特に段階3 は「テストを先に書き、**落ちることを確認してから**実装する」こと★★ — > ★★分割キーを変えただけで畳み込みを忘れても、既存テスト（1台ぶんの入力しか無い）は > 全部通ってしまいます★★（落とし穴1）。★先に落ちるテストを作らないと、壊れたまま緑になります★。 > ★★**なぜこの順番なのか**★★ > - ★段階1 が先頭なのは ★★`CLAUDE.md` §6 作業ルール1「API契約を変えたくなったら先に YAML を直す」★★ と、 > ★段階2 だけ先に入れると週の初めに全施設が赤バッジになる★（落とし穴7）から > - ★段階2 と段階3 を分けるのは、「引数を1つ足す」修正と「分割キー変更 + 畳み込み新設」で > ★★触るファイルも壊し方も別物★★だから。★1コミットにまとめると段階6 の実測でどちらが効いたか分からなくなる★ > - ★段階4（70.0）を段階3 の後に置くのは、★★段階3 の期待値表を 70.0 の変更で二度書き直さないため★★ > - ★段階5（シード）を最後の実装段階に置くのは、★★件数が変わるので、それまでの段階を > 「件数は1件も変わらない」で検証できるようにするため★★ --- ## 段階0 — 前提の確認（★読むだけ・コミットなし★） ### 読むもの | # | 対象 | 見る点 | |---|---|---| | 1 | ★`CLAUDE.md` 全文★ | ★特に ★**§4.1（△ = 10%以上70%以下）**★ / ★**§4.5（R3/R4 は「同一施設で」）**★ / §4.3（丸め）/ §6（API契約が先）/ §8（用語）/ §9.4（判定ロジックの作法）★ | | 2 | ★`docs/decisions.md` の **D-026**（`:122`）★ | ★「連続」はスケジュール存在日の連続★。★★畳み込みで日を1つにまとめても、清掃予定のない日は依然として飛ばされる（連続が途切れない）ことを確認する★★ | | 3 | ★**D-103**（`:5222`）/ **D-106**（`:5830`）/ **D-107**（`:5993`）/ **D-108**（`:6218`）/ ★**D-109**（`:6328`）★ | ★A案の出所 / 1週間分の予定 / `isFutureSchedule()` の必須性 / `String(facility_id)` 詰め替えの出所 / ★本改訂の5決定★★。★行番号は自分で取り直すこと★。★★D-109 が本書と食い違っていたら実装を止めて確認を求める★★ | | 4 | ★`docs/handoff.md` の末尾（★追記32★。`:2662`）★ | ★指示書T の完了内容と申し送り★ | | 5 | ★`docs/handoff/指示書T_ローカルDBで動かす第5歩_レポートサマリ.md` / `指示書U_清掃結果をclean_errorで判定する.md`★ | ★段階の切り方・期待値表の書き方・記録の作法★ | | 6 | ★`lib/db/clean-log-mapping.ts` 全文（346行）★ | ★`isFutureSchedule()`（`:263`）/ `isProblemCompletion()`（`:280`）/ `ConsecutiveInput`（`:285`）/ `computeConsecutiveProblemDays()`（`:317`）★ | | 7 | ★`lib/db/report-mapping.ts` 全文（369行）★ | ★`aggregateCleanStatsByFacility()`（`:170`）/ `kpiFromCleanStats()`（`:208`）/ `FacilityConsecutiveEntry`（`:241`）/ `consecutiveProblemDaysAtPeriodEnd()`（`:262`）★ | | 8 | ★`lib/db/index.ts:270-360`（`cleanLogs()`）★ / ★`:780-830`（`reportKpis()` 当期）★ / ★`:910-1100`（`facilityPerformance()`）★ | ★`now` が既にどこで作られているか（`:289` / `:493` / `:932`）★ / ★`serial_number: String(row.facility_id)`（`:940`）★ / ★★当期行がバケットのキーから作られていること（`:1066` / `:1089`）★★ | | 9 | ★`lib/judge/kpi.ts` 全文★ | ★`rate()` が分母0で `null` を返すこと（`:19-22`）★ / ★`judgeFacilityStatus()`（`:75-82`）が `null` を `"bad"` にしていること★ | | 10 | ★`lib/judge/escalation.ts` 全文★ | ★★`countConsecutiveProblemDays()` が**日付を見ていない**こと（落とし穴1）を自分の目で確認する★★。★★この関数は変更しないこと★★ | | 11 | ★`lib/judge/advice.ts:50-80`★ | ★決定4 の影響箇所（R1 の `consecutiveProblemDays <= 1` / R3 / R4）★。★★この関数も変更しない★★ | | 12 | ★`lib/db/__tests__/clean-log-mapping.test.ts:392-512` / `lib/db/__tests__/report-mapping.test.ts:113-174` / `:238-281`★ | ★既存テストの書き方（ヘルパー `row()` 等）に揃えるため★ | | 13 | ★`scripts/seed-local-db.ts:704-925`★ | ★清掃ログ系4テーブルの投入ループ★。★★`historyIndex` / `errorReportCount` の通番ローテーション（落とし穴12）を自分の目で確認する★★ | ### 接続先の確認とこの段階の完了条件 - ★`.env.local` の `DATABASE_URL` が `dwatch_local` を指していることを確認する★。 ★**値そのものを画面・ログ・文書に出さないこと**★（`CLAUDE.md` §9.3） - ★`.env.local` に `ALLOW_DIRECT_ACCESS=true` があることを確認する★（D-101 項2。★無いと段階6 で詰まる★） - ★★着手前の基準値を自分で実測して控えた★★（`npm test` のファイル数・テスト数 / `tsc` / `lint`） - ★★DBの現状を実測して控えた★★: ``` "/c/Program Files/MySQL/MySQL Server 8.4/bin/mysql.exe" -u root --default-character-set=utf8mb4 dwatch_local -e " SELECT COUNT(*) AS main_rows FROM clean_timetables WHERE precheck=0; SELECT COUNT(*) AS future_main FROM clean_timetables WHERE precheck=0 AND start_at > NOW(); SELECT MIN(start_at), MAX(start_at) FROM clean_timetables WHERE precheck=0; SELECT facility_id, DATE(start_at) d, COUNT(*) c FROM clean_timetables WHERE precheck=0 GROUP BY facility_id, DATE(start_at) HAVING c > 1 ORDER BY facility_id, d; SELECT clean_timetable_id, clean_ratio FROM clean_status_histories WHERE clean_ratio = 70.0; SELECT t.facility_id, t.section_id, DATE(t.start_at) d FROM clean_timetables t WHERE t.precheck=0 AND t.facility_id=7 ORDER BY d, t.section_id;" ``` ★作成時点の実測★: `main_rows` = ★253★ / `future_main` = ★**0**★ / `MIN`〜`MAX` = ★2026-08-11 16:30 〜 2026-09-10 18:00★ / ★同一日に複数行がある施設・日 = ★**施設7 の 2026-09-09（3行）だけ**★★ / ★`clean_ratio = 70.0` = ★**1件（`clean_timetable_id=1005`）**★★ / ★施設7 は ★**09-04 まで section 107 のみ・09-09 だけ 107/108/109**★★ - ★★修正前の連続日数を全施設ぶん控えておくこと★★（★段階6 の突き合わせに使う★）: ``` USE_FIXTURES=false DATABASE_URL="mysql://root@localhost:3306/dwatch_local" npx tsx -e " import { db } from './lib/db'; const fp = await db.facilityPerformance(); console.log(fp.map(r => [r.period, r.year, r.month, r.week, r.item.facility_id, r.item.consecutive_problem_days, r.item.status])); " ``` - ★★決定番号を実測した★★（`grep -nE "^### D-(0|1)[0-9][0-9]" docs/decisions.md | tail -3`）。 ★★`D-109`（`:6328`）が既に入っていることを確認したら、本書の記録は `D-110`★★。★入っていなければ空き番号を採る★ --- ## 段階1 — ★決定1 の手当て: 「判定なし」ステータスを足す★（1コミット） ### 1-0. ★なぜ最初にやるのか★ ★段階2（当期の分母から未来を外す）を入れると、★★週の初め・月の初めに `planned = 0` の施設が出ます★★★。 ★`operationRate(0, 0)` は `null`（`lib/judge/kpi.ts:19-23`）★ → ★★`judgeFacilityStatus(null)` は現在 `"bad"` を返すので、全施設が赤い「要改善」バッジになります★★。 ★★先にステータスを足しておけば、そのような中間状態を作らずに済みます★★。 ★★`CLAUDE.md` §6 作業ルール1 のとおり、`d-watch-api.yaml` から直すこと★★。 ### 1-1. ★★期待値表（★これをそのままテストにすること。実装より先に書く★）★★ 対象: `judgeFacilityStatus(operationRateValue)`（`lib/judge/kpi.ts:75`） ★4つ目の値の名前は実装者判断★。★★「その他」「不明」という語は使わないこと★★（D-089 項3 / D-104）。 ★以下の表では仮に `no_data`（画面表示「判定なし」）と書きます★ — ★別名にした場合は表の値を読み替えること★。 | # | 入力（稼働率） | ★期待★ | 備考 | |---|---|---|---| | ★1★ | 96.3 | `"good"` | ★既存テスト（`lib/judge/__tests__/kpi.test.ts:95`）★ | | ★2★ | 90.0 | `"good"` | ★境界（以上）。既存★ | | ★3★ | 89.9 | `"warning"` | ★既存★ | | ★4★ | 75.0 | `"warning"` | ★境界（以上）。既存★ | | ★5★ | 74.9 | `"bad"` | ★既存★ | | ★6★ | 0 | ★`"bad"`★ | ★★0% は「判定なし」ではない★★（★実施予定があって1回も実施できていない＝要改善★） | | ★7★ | ★★`null`★★ | ★★`no_data`（＝**`"bad"` ではない**）★★ | ★★`lib/judge/__tests__/kpi.test.ts:104` の期待値を差し替える★★。★意図した仕様変更であることをテスト名とコメントに書く★ | ★★#6 と #7 を両方入れること★★（★「分母0」と「分子0」を取り違えると静かに壊れます★）。 ### 1-2. テストを書く - ★`lib/judge/__tests__/kpi.test.ts:93` の `describe("judgeFacilityStatus（良好/注意/要改善）")` に足す★ （★`describe` の名前も4値に合わせて直すこと★） - ★★`:104` の `expect(judgeFacilityStatus(null)).toBe("bad")` は**期待値を差し替える**★★。 ★★消さずに、テスト名とコメントに「決定1（2026-09-11 ユーザー確定）で `null` は判定なしに変えた」と書くこと★★ - ★この時点で #7 が**落ちる**ことを確認してから実装に進む★ ### 1-3. 実装（★この順序で★） 1. ★★`d-watch-api.yaml`（**先に直す**）★★ - `FacilityPerformance.status` の enum（★`d-watch-api.yaml:1294`★）に4つ目を足す - `GET /reports/facility-performance` の `status` クエリパラメータの enum（★`:524`★）にも足す （★`all` は残す★） - ★`description` に「稼働率が算出できない（その期間の清掃予定が0件、または予定が全部これから）ときの値」と書く★ 2. `lib/types/index.ts` - ★`FacilityStatus`（`:238`）に4つ目を足す★ 3. `lib/judge/kpi.ts` - ★`judgeFacilityStatus()`（`:75-82`）の `if (operationRateValue === null) return "bad";` を ★4つ目の値を返す★ に変える★ - ★★docstring の「`null`（分母0＝その期間に清掃予定が1件もない）は「要改善」に寄せる」という説明を 書き換えること★★: ★「分母0は**評価できない**ので判定なしにする（決定1。2026-09-11）」★ / ★「`clean_timetables` には1週間分の予定がまとめて登録される（D-106）ため、 週の初め・月の初めは『予定はあるが実施0件』が正常な状態になる」★ - ★★`FACILITY_STATUS_THRESHOLDS` は触らない★★（禁止事項19） 4. `lib/reports/query.ts` - ★`FACILITY_STATUS_FILTERS`（`:29-34`）に4つ目を足す★（★`FacilityStatus` の定義順 + `all`★） - ★★`filterFacilityPerformanceByStatus()`（`:176`）は汎用なので触らない★★ 5. `components/features/reports/FacilityPerformanceTable.tsx` - ★`STATUS_LABEL`（`:116-120`）に4つ目のラベルを足す★（★「判定なし」。★「その他」「不明」は禁止★） - ★`statusColor()`（`:129-133`）に4つ目の色を足す★ — ★★グレー系（`THEME_TOKENS[theme]` の既存トークンから選ぶ。16進のカラーコードを渡すこと。 `var(--…)` を渡すと `Pill` の `${color}22` が壊れる。同ファイル `:122-128` のコメント参照）★★ - ★★「モックに無い表示を足している」ことをコメントに1行残すこと★★ （★`d-watch-mock.jsx` は3値しか持たない。決定1 で承認済み★） 6. `components/features/reports/ReportsScreen.tsx` - ★`:259-262` の `