--- description: D-Watch（清掃ロボット監視ビューアー）の作業を引き継いで再開する --- D-Watch（清掃ロボット監視ビューアー）の作業を引き継ぎます。 ## ★役割分担（最初に読むこと）★ **このリポジトリでは2つの環境で Claude が動きます。担当が違います。** | どこで動いているか | 担当 | 指示書を渡されたら | |---|---|---| | **Cursor の中**（エディタに統合された Claude） | ★**実装担当**★ `.ts` の実体（ロジック・型・テスト）を書く | ★**実装してください**★ | | **Claude Code**（デスクトップアプリ / ターミナル。このスラッシュコマンドを使う側） | 調査・検証・指示書の作成、`docs/*.md` などの文書 | **作るところまで。実行しない** | ★**自分がどちらか分からないときの判定**★ - このスラッシュコマンド（`/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`★ そのうえで、必要に応じて次を読みます。**いずれも本ファイルより優先される正の情報源です。** | 資料 | 何の正か | |---|---| | `CLAUDE.md` | ★仕様・規約・禁止事項の正★ | | `docs/decisions.md` | ★決定の正★。★D-174 まで（162件）★。★番号順に並んでいません★ | | `docs/handoff.md` | ★全履歴★。★追記63 まで★ | | `d-watch-api.yaml` | API契約の正 | | `d-watch-mock.jsx` | 画面の正 | ★★**本ファイルの数字は書いた瞬間から古くなります。必ず実測してください。**★★ --- ## ★★最初に知るべきこと — 接続先はステージングです★★ ★★`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 実測★） | 項目 | 値 | |---|---| | ブランチ | `develop` | | 最終決定番号 | ★D-174★（アドバイス B2 の根拠の進め方。記録のみ）。最後の実装は ★D-173★（レポートがまだ無い清掃は予定の終了から2時間「結果待ち」。`08ba9e9`） | | 最新の追記 | ★追記63★（D-161〜D-171・D-173 の実装と D-172・D-174 の記録） | | `main..develop` | ★533コミット★（`origin/main..origin/develop`。fetch 済み）。★HEAD = origin/develop = `04f974a`（第12回の送付版）。未 push 0★ | | ★PR★ | ★#6 open（`develop`→`main`）・レビュー未了★。★CI「Lint / Test / Build」は `04f974a` で緑（11:4x 確認）★。★レビュー担当は daichi（D-154）★。★積み上げ PR に分けて出し直す予定★（`docs/handoff/PRレビュー手順_20261001.md`。区切りは数え直す） | | テスト | ★125ファイル / 2,946件 全パス★（`8a657a2`。`929c5b9`・`04f974a` は資料だけ） | | 指示書 | 45本（★次は `AX`★）。★AR・AS・AT（2026-10-02。`git log` の日時）・AU（2026-10-05）・AV・AW（2026-10-06）は Claude Code で実装済み★。★D-161〜D-171・D-173 は指示書なし★ | ### 完成しているもの ★画面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` は削除）／アラートの出発失敗・連続日数・要レスキュー・当期の率も数えない --- ## 次にやること | 順 | 内容 | |---|---| | ★1★ | ★資料のコミットを push したあと、PR #6 の CI が緑のままか確認する★（`04f974a` では緑。11:4x 確認） | | ★2★ | ★第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）。R-1 で本清掃の id が入るなら、アラートの「◯分前異常」は出なくなる（D-104）。R-2 の回答で `RESULT_WAIT_MINUTES`（120）を見直す | | ★3★ | ★ステージングの投入が終わったら再実測★: 予定と実績のつながり（10-07 は 87行中 80行が予定に紐づく。D-170）・`clean_timetable_histories` と `db.timetable_conflict`・ダッシュボードの直近モードの内訳・事前チェックに紐づくエラー行が入ったらアラートからの書き込み（指示書AT 段階9）と `main_run_succeeded`・結果待ち（D-173）の出方。★`prisma db pull` は `serial_number` の拡張を確かめてから・急がない★（D-172） | | ★4★ | ★PR #6 を積み上げ PR に分けて daichi がレビューし `main` に入れる★（先に CI 修正の PR。`main` は 2026-08-27 で停止中。D-154）。★ユーザー回答: レビューが終わったら全部 push する★（D-171 末尾） | | 5 | ★点検記録画面（F-05）の指示書を書く★（★唯一の未実装画面★。独自ストアなので TeamWorks 待ちが無い。`customer_name` の説明に残した「ブランド」列もここで合わせる） | | 6 | ★契約（`facilities.contract`）によるメニューの出し分け★（★P2。顧客に使わせる前に必ず★。D-160 追記4） | | 7 | ★セキュリティ強化はリリース直前にまとめて★（D-154。一覧は `CLAUDE.md` §3: `ALLOW_ALL_WHEN_EMPTY`・`AUTH_TOKEN` が `changeme`・パスワード変更・TLS 等） | | 8 | ★次フェーズ★: エラーの3区分・D-Sec アラートの取得元の切り替え（第11回 P-8〜P-10。D-158 当方の対応5）。★アドバイス B2 の根拠を本清掃のエラー内容に切り替える★（D-174 で決定。エラーコード（ユーザーが情報収集中）が決まってから） | | 9 | 後で・要望があれば: 表示する事前チェックの回を設定値で（D-169）／施設別パフォーマンスの CSV の追加列（D-163）／D-160 追記の残り（「解消済みも表示」の性能・375px でサイドバーが畳まれない）／★EN の文言と D-Secログの備考の見出しが EN で "NOTE" の件は、運用が始まって必要になったら直す★（D-171 末尾のユーザー回答）／指示書AV・AW で範囲外にしたもの（AV: 遷移先の条件・Q6・Q7 / AW §10: 件数カード・バッジ・名前の一般化・部品の共通化）／★fixtures で `data.anomaly` の「実績が予定を上回る」側を再現し直す★（D-173 で有効スケジュールが 11件になり再現できなくなった。追記63 §5） | --- ## 外部待ち — ★第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` に書いてください。** 方針が変わったら、**引き継ぎメモへの追記と同時にこのファイルも直してください。**