description: D-Watch（清掃ロボット監視ビューアー）の作業を引き継いで再開する

D-Watch（清掃ロボット監視ビューアー）の作業を引き継ぎます。

★役割分担（最初に読むこと）★

このリポジトリでは2つの環境で Claude が動きます。担当が違います。

★自分がどちらか分からないときの判定★

• このスラッシュコマンド（/d-watch）から起動された → Claude Code 側（実装しない）
• ユーザーが docs/handoff/指示書*.md を指して「実行して」と言った → ★あなたが実装者です。実装してください★

「実装は Cursor 側」という記述を「Claude は実装しない」と読み違えないこと。 2026-09-07 に、Cursor 内の Claude がこの記述を読んで実装を拒否し、 代わりに文書作業のメニューを出す事故が起きました。

Claude Code 側が守ること: docs/handoff/指示書*.md は「作る」までが担当で、「実行」はしません。 2026-09-03 に指示書D を Claude Code 側で実行してしまい、24ファイルの変更を作ったうえで 全部差し戻した経緯があります（docs/handoff.md の「追記2」参照）。 サブエージェントを使うのは調査・検証まで。実装を委譲しないこと。

★例外: ユーザーが Claude Code に「ここで実装して」と明示したとき★は実装してよい（外出中で Cursor に渡せないため、指示書AR〜AT を Claude Code で実装した（git log の日時は 2026-10-02）。指示書AU も 2026-10-05 にユーザー指示「ここで実装してください」で同様。D-158 項9。★指示書AV・AW も 2026-10-06 にユーザー指示「ここで実装する」で同様（追記61・追記62）★。★D-161〜D-171・D-173 は指示書なしで、ユーザーの画面での指示をその場で実装した（追記63）★）。 その場合も ★指示書の期待値表は変えない★・★監督（メイン）が型チェック・テスト・差分を自分で確かめてから push★。

最初にやること

★入口はこの1枚です。先にこれを読んでください。★

• ★docs/handoff/セッション引き継ぎ_20260917.md★

そのうえで、必要に応じて次を読みます。いずれも本ファイルより優先される正の情報源です。

★★本ファイルの数字は書いた瞬間から古くなります。必ず実測してください。★★

★★最初に知るべきこと — 接続先はステージングです★★

★★133.125.238.144 / clean_watch はステージング。本番DBは別にある★★（D-152。D-148 は破棄）。

• ★★4カラム（status / comment / responded_at / resolved_at）の UPDATE は書き込んでよい（D-152）。それ以外は禁止★★
• ★2026-09-30〜10-01 に先方が実データ（ドン・キホーテ実店舗10件＋本社）を入れた。当方のダミーは消えている★
• ★2026-10-06 に接続が回復した★（.env.local 更新後。10-02〜10-05 は 1045。D-157）。★10-06 は予定と実績がつながっていなかった★（レポート54行すべて clean_timetable_id が NULL。D-158 末尾）が、★10-07 はレポート87行のうち80行が本清掃の予定に紐づいていた★（予定外7行。D-170 2026-10-07 実測・先方投入）。★投入が終わったかは未確認★
• ★4カラムの書き込みは 10-06 にエラー一覧（/errors）から確かめた★（1行を書いて戻し、4列は完全一致・権限エラーなし。先方投入データ。追記62 §3）。★エラー16行はすべて本清掃に紐づくので /alerts から書ける行は無い★
• ★事前チェックの予定は本清掃とは別の行（別の id・parent_id あり）★だが、★事前チェックで見つかったエラーにどちらの id が入るかは未確認★（第12回で聞く。D-172）

30秒で読む現在地（★2026-10-07 11:3x JST 実測★）

完成しているもの

★画面12枚中11枚が実装済み★（★エラー一覧 /errors を 10-06 に足した★）。★空なのは点検記録（F-05。docs/spec.md）だけ★。 ★2026-09-17 に全画面をブラウザで目視確認済み★（追記58）。★2026-10-05 に AR〜AT の変更（清掃結果の表示名・総清掃面積の注記・アラートの状態ボタンと備考）を fixtures で確認★。★AU（顧客の見出し・当期 KPI の式・予定の2表読み）は fixtures の API で境界値を確認済み、ブラウザ目視（EN・375px）は記録なし★（追記60）。★AV（ダッシュボードの直近モード・清掃詳細ログの既定を全期間）は fixtures の本番ビルドを撮影して確認、ステージングでも API を確認済み★（追記61）。★AW（エラー一覧）は fixtures の API と画面・ローカルDB・ステージング（1行を書いて戻した）で確認済み★（追記62）

★2026-10-06〜07 に足したもの（D-161〜D-171・D-173。追記63）★:

• ★対応状況はプルダウン（D-161）、対応状況と備考は「編集モード」でだけ変えて「保存（N件）」でまとめて送る（D-165）★ — エラー一覧とアラートの両方。即時保存は無くなった
• ★レポートの施設別パフォーマンスを CSV で出す★（GET /reports/facility-performance/export。D-163）／★CSV の値が無い率は空欄★（D-164）
• 一覧の見た目（分類のプルダウン固定幅・期間の枠全体でカレンダー・備考を1行。D-162）／列幅（エラー一覧 D-166・余りを全列に配る D-167）／見出しと中身の寄せ（D-168）
• ★事前チェックの結果も有無も判定に使わない★ことを確かめ、テストで固定（D-170）／表示する事前チェックの回は後で設定値で運用（D-169。いまは 60/30）
• ★事前チェックの予定が無い回の「1h前ST / 30分前ST」は「-」★（API は null、CSV は空。予定があって異常なしは "Standby."）／★本清掃が成功した事前チェック異常はアラートで薄く表示し「本清掃は成功」の Pill★（main_run_succeeded。対応状況・件数は変えない）／D-Secログの備考の文字の頭を見出しに揃えた（D-171）
• ★レポートがまだ無い清掃は、予定の終了から2時間（RESULT_WAIT_MINUTES）まで「結果待ち」で、失敗に数えない★（D-173）— 詳細ログは出発「…」・「結果待ち」・判定なし／ダッシュボードに「結果待ち」カード（成功率の分母に入れない）・直近の清掃は予定が終了した最後の清掃（settleMinutes は削除）／アラートの出発失敗・連続日数・要レスキュー・当期の率も数えない

次にやること

外部待ち — ★第11回は 2026-10-05 に回答受領（D-157 / D-158）。第12回は送付版を作成済み★

• ★第12回は送付版を作成済み★（docs/handoff/TeamWorks確認事項_第12回_20261007_送付版.md・04f974a。R-1 事前チェックで見つかったエラーの clean_timetable_id は事前チェックの行と本清掃の行のどちらの id か（D-172 P-9）／R-2 clean_task_reports は清掃の終了から最大どれくらい遅れて書かれるか（RESULT_WAIT_MINUTES の見直し。D-173）／R-3 お願い: データ投入（予定と実績の紐づけを含む）が終わったら一言ほしい）。★実際に送ったかは未確認★ → ★送付の確認と回答待ち。回答が来たら受領日を docs/decisions.md に記録★。★serial_number の拡張の再依頼は第12回には入れていない（急がない。D-172）★。P-13 と「予定が履歴に移る時期」も外した（D-172）
• ★先方のデータ投入の完了★（10-06 は clean_task_reports 54行すべて clean_timetable_id が NULL（D-158 末尾）→ 10-07 は 87行中 80行が予定に紐づく（D-170））。★ログインできない件（1045）は 10-06 に解消★
• ★DDL の取り込み★: robot_id は NULL 可になった（10-06 構造で確認）が、★serial_number は varchar(20) のまま★（第11回 P-8 c の拡張は未反映。10-07 も同じ。D-171）。★ユーザー判断: 急がない・db pull もそれまで待つ★（D-172）。それまでは robot_error_reports を select で絞って読む（lib/db/robot-error-select.ts）
• ★clean_ratio の訂正（N-3）は待たなくてよい★: 第11回 P-1・P-2=A で★今の式のまま確定★（D-158）。訂正後の列も同じ値になる
• 第11回で解決: 屋号 → customers は法人で「顧客」（P-15）／本番DBも JST（P-11）／task_area = 0 は 0%（P-5）／当期 KPI はサマリの式（P-6）。★どれも指示書AU で実装済み★
• ★次フェーズ★: エラーの3区分・D-Sec アラートの取得元の切り替え（P-8〜P-10。D-158 当方の対応5）

★回答が来たら受領日を docs/decisions.md に記録すること★。

進めるときの注意

★引き継ぎ書 §6 の地雷を必ず読むこと。★ 特に★例外もテスト失敗も出ないまま結果だけ間違う★もの:

1. ★facility_ids の null（全件）と []（0件）は別物★
2. ★facilities.contract は varchar(10) の桁位置★（数値比較すると全施設が「契約なし」）
3. ★表示用に丸めた値で判定しない★
4. ★DATETIME は JST の壁時計値★（素で読むと9時間進む）
   • ★生の値に9時間を足さない★。★先方が 2026-10-02 に DB のタイムゾーンを JST に統一し再登録した（N-14）。本番も JST（第11回 P-11）。アプリのコードは変えない。再実測は未了★（CLAUDE.md §3）
5. ★★4カラム（status / comment / responded_at / resolved_at）の UPDATE は書き込んでよい（D-152）。それ以外は禁止★★
6. ★「実測」と書くときは出所を併記する★（CLAUDE.md §6-6）
7. ★予定は lib/db/timetable-source.ts を通して読む★（clean_timetables と clean_timetable_histories の両方。直接 cleanTimetable を読むと履歴が抜ける）
8. ★robot_error_reports は lib/db/robot-error-select.ts の select で読む★（robot_id / robot を読まない）
9. ★ダッシュボードの数値カード・表は直近モード、スケジュール進捗・要レスキューは当日★（D-159）。★cleanLogs() と cleanLogRunMeta() は mainTimetableWhere() を共有する★（別々に書くと突き合わせが静かにずれる）
10. ★4カラムを書くルートは /prechecks/{id}/status と /errors/{error_id}/status の2本★（どちらも writeRobotErrorColumns() を通る）。★エラー一覧は2段階で読む★（errored_at ?? created_at の順を Prisma で書けないため。D-160 追記2）
    • ★画面からは「編集モード」で下書き → 「保存」でまとめて送る★（変えた行だけ1行ずつ順に。1行の失敗で止めず、失敗行の下書きだけ残る。D-165）。★下書きの扱いは lib/prechecks/edit-drafts.ts の1本★（エラー一覧とアラートが共有）。★巡回順の lib/prechecks/status-cycle.ts は削除済み★（D-161）
11. ★i18n のキーは全画面で共有★（「備考」→ "Note" を足したら D-Secログの見出しも変わった）。★vitest でモックした @/lib/db/prisma の同時の動的 import は片方に本物が返る★（テストだけ。vi.spyOn で避ける。追記62 §4）
12. ★事前チェックの結果も有無も、成功・失敗の判定に使わない★（判定は本清掃のレポート行の有無と完了率だけ。D-170 / CLAUDE.md §4.4。lib/dashboard/__tests__/aggregate.test.ts が見張る）
13. ★CleanLogItem.status_1h / status_30m の null は「その分数の事前チェックの予定が無い」、"Standby." は「予定あり・異常なし」★（別物。D-171）。★PrecheckItem.main_run_succeeded は見た目を薄くするだけで、対応状況・未解消の件数は変えない★（D-171）
14. ★結果待ち（CleanLogItem.result_pending）は departed / grade を変えない旗★（結果待ちの行も departed: false・grade: "×" のまま）。★行を数える・△×を拾う処理を足すときは必ず旗を見る★（見ないと出発失敗に数える）。判定は lib/clean-logs/result-pending.ts の isResultPending() 1本、待つ時間は RESULT_WAIT_MINUTES（★LAUNCH_GRACE_MINUTES とは別物・流用しない★。D-173）

作法:

• ★検証が通ったら即コミット★ / ★git add -A は禁止★
• ★決定番号は grep -n "^### D-" docs/decisions.md | tail -3 で実測★（^### D-0 では3桁台を拾えない）
• ★指示書を2本同時に走らせない★
• ★dev サーバーは preview_start★（fixtures は d-watch-fixtures、ポート3100）。★ログインは .env.example の開発用トークン★（ローカルの開発サーバーに限る）
• ★サブエージェントが起動した dev サーバーは止めてから終わらせる★（2026-10-02 に残ったサーバーの作業プロセスが落ち、PATCH が500になった）
• ★新しいクローンでは npx prisma generate が要る★
• ★ワークツリーでは npm run build が落ちる★（Turbopack が node_modules のジャンクションを拒否）。★ビルドは本体で★
• ★Bash ツールはヒアドキュメントの中でも \\ を \ に縮める★（正規表現の \S 等を書くスクリプトは Write ツールで書く）
• ★別の Claude セッションが同じ develop に docs のコミットを積むことがある★。コミット直前に git status --short と git log --oneline -3 を見る

最初の報告

★次を実際に実行して★現状を確認し、簡潔に報告してください。★推測で答えないこと。★

git log --oneline | head -10
git status
git rev-list --count origin/develop..develop
npm test

1. ★未コミットの変更があるか★（★別の Claude セッションの作業中の変更なら触らない・stash しない★）
2. ★テスト数と最終決定番号★が上の表（★125ファイル / 2,946件 / D-174★）と一致するか
3. ★未 push のコミットがあるか★ / ★PR #6 の状態★（★最新の head の CI は緑か / レビューが通ったか / head はどこか★）
4. ★第12回（送付版。R-1〜R-3）を送ったか / 先方のデータ投入が終わったか（予定と実績がつながったか） / 回答が来ているか★（★回答が来ていたら受領日の記録が最優先★。レポートの最大の遅れの回答が来ていたら RESULT_WAIT_MINUTES を見直す。D-173）

そのうえで、何から進めるかをユーザーに確認してください。

この文書について

引き継ぎメモとこのコマンド定義は、次の担当者の行動をそのまま決めます。 古い記述を残すと、次のセッションがその指示に従って誤った作業を始めます。 このファイルは要約と道案内に留めてあります。詳細は docs/handoff.md に書いてください。 方針が変わったら、引き継ぎメモへの追記と同時にこのファイルも直してください。