---
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` | 画面の正 |

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

---

## ★★最新 — 2026-10-30〜11-04 の作業（D-Watch 2セッション目のまとめ）★★

★この節が一番新しい★。下の「30秒で読む現在地」「最初の報告」の数字は 10-07 時点（古い）。

### 現在地（★2026-11-04 17:4x JST 実測★）

| 項目 | 値 |
|---|---|
| ブランチ | `develop`。★HEAD = origin/develop = `619e21d`★（未 push 0） |
| GitBucket | ★develop は1コミット★（11-04 にユーザー指示でまとめ直した。中身は GitHub develop の先頭と同じ。GitHub の履歴は含まない）。★以後はその上に1つずつ積むので、サーバーは普通の `git pull` で取れる★。下の「GitBucket への上げ方」 |
| テスト | ★157ファイル / 3,855件 全パス★（tsc・lint も緑） |
| 指示書 | ★BH・BI まで（次は `BJ`）★。BH・BI は Cursor が実装し、監督（Claude Code）が点検・コミット |
| 決定 | ★コミット済みは D-181 まで★（`docs/decisions.md`）。★BH・BI の決定は未記録★（下の「残り」1） |
| 未コミット | ★別セッションの作業中の6ファイル★（`docs/decisions.md`・`docs/handoff/指示書AY_*`・`docs/handoff/設計_制御盤ログの取り出し_*`・`components/features/errors/ErrorContentPicker.tsx`・`lib/errors/error-content-label.ts` とそのテスト）。★触らない・コミットに入れない★（コードの3つは改行コード以外の差なし） |

### この期間のコミット（古い順）

| コミット | 内容 |
|---|---|
| `a2e240a`・`a1e4b59`（10-30） | 清掃結果 `status = 6` は 3 と同じ「清掃キャンセル」。表に無い値（7 以上など）は「不明(7)」と数字を残す（`CLAUDE.md` §4.7） |
| `38e8f5d`（10-30） | 施設ロボットマスタを「監視」「D-Sec」列で並べ替え（1回目 desc ＝ ○ が上 → ▲ → 既定） |
| `4bb639e`（11-04） | ★指示書BH★: 清掃詳細ログ7列（機種・シリアル・日付・出発・清掃結果・完了率・判定）とエラー一覧6列（検知時刻・シリアル・種類・レベル・対応状況・備考）を見出しで並べ替え（1回目 asc ＝ 悪いほうが上。サーバー側・ページングの前・CSV も同じ並び）。<br>★「予定：すべて／予定あり／予定なし」の絞り込み★をエラー一覧と清掃詳細ログ（API・CSV・画面）に（`lib/api/schedule-filter.ts`・`components/ui/ScheduleFilterSelect.tsx` の1か所）。<br>★並べ替えの印★: 並べていない列＝薄い △、asc ▲・desc ▼。色はダーク白・ライト `#1e293b`（`--sort-mark`）。印の字は日本語フォント（`--font-ja`。body と共有）。<br>★表示の文言「予定外」→「予定なし」★（プルダウン・詳細ログの予定列・ダッシュボードの小さい表・CSV・清掃面積の注記。API の値 `unscheduled` は変えない。BH §13）。<br>YAML の清掃面積の行（`CleanAreaRow`）の説明を実装どおり「予定外も含む」に |
| `619e21d`（11-04） | ★指示書BI★: ★予定なしの △× の行にもアドバイスの ▼★（詳細ログ・ダッシュボード）。入口 `GET /clean-logs/unscheduled/{report_id}/advice`（`report_id` は varchar(20) の文字列。数値にしない）。エリア別詳細のボタンは予定ありの行だけ（`cleanLogRowView().areaDetail`）。データ層 `db.unscheduledCleanLog()`。応答づくりは `lib/clean-logs/advice-response.ts` に切り出し両ルートで共有 |

### このセッションで固めた手順

- ★GitBucket への上げ方★（★サーバー（ステージング）が `git pull` して使う★。公開設定なので★GitHub の履歴は出さない★ — 履歴にステージングの DB ユーザー名が14コミット入っている。D-177）:
  1. 先に GitHub（`git push origin develop` → `git fetch origin`）
  2. `git ls-remote https://git.d-sec.dfarobotics.com/git/develop/client_dwatch.git refs/heads/develop` で GitBucket の今の先頭 `<head>` を取る（知らない版なら止めてユーザーに聞く）
  3. ★`S=$(git commit-tree "origin/develop^{tree}" -p <head> -m "D-Watch develop <hash> のスナップショット。GitHub の履歴は含まない")`★（★`-p <head>` を必ず付ける★ — 付けないとサーバーで pull が効かない）→ `git branch -f gitbucket-snapshot $S`
  4. `gitbucket-snapshot^{tree}` と `origin/develop^{tree}` が一致、`git merge-base --is-ancestor <head> $S` を確かめる
  5. ★`git push <上の URL> gitbucket-snapshot:develop`（`--force` を付けない）★。拒否されたら誰かが積んだので止めてユーザーに聞く
  - 経緯: 11-04 まで毎回「親なし1コミット」を force push していたので、サーバーで pull が効かず古い版のまま残った（10-29・11-04）。11-04 にいったん合流コミット（`ecb9f68`）でつなぎ直したあと、ユーザー指示「rebase などでまとめて最新の状態に」で★1コミットにまとめ直した（最後の force push）★。サーバーはその1回だけ `git fetch origin` → `git reset --hard origin/develop`。★以後は force push しない★
  - ★サーバーへの反映★: サーバーで `git pull` → コンテナをイメージごと作り直して再起動 → ブラウザで Ctrl+Shift+R（`npm run build` だけではコンテナに届かない）
- ★コミットの作法★: ファイルを名前で指定（`git add -A` 禁止）・別セッションの6ファイルを入れない・★コミット前に差分へテスト用トークン／本物の `AUTH_TOKEN`／DB のパスワード／接続先 IP が入っていないことを grep で確かめる★（値は表示しない）
- ★fixtures の画面確認★: `USE_FIXTURES=true npm run build` → `AUTH_TOKEN=<テスト用トークン> USE_FIXTURES=true npx next start -p 3100` → アプリ内ブラウザでログイン（★テスト用トークンはスクラッチパッドに乱数で作る。本物のトークンは打たない★）→ 終わったら止め、3100 を listen しているプロセスのコマンド行を確かめてから kill
- ★ステージングでユーザーがローカル確認★: `preview_start` の `d-watch`（:3000。`.env.local` が `clean_watch`）で立て、★ログインはユーザー自身★。「止めて」と言われたら `preview_stop` → 3000 が空いたか確かめる
- ★ステージングを監督が画面で見るとき★: `USE_FIXTURES=false` とテスト用トークンで :3100 を立てる（読むだけ）。API だけなら `.env.local` の `AUTH_TOKEN` を cookie に付けて curl（値は表示しない）
- ★指示書と実装の点検★: Workflow で4観点（コードとの食い違い／期待値の実計算／画面の流れ／漏れと矛盾）→ 指摘ごとに別エージェントが反証 → 本物だけ反映（BH §12: 12件中6件、BI: 29件中26件、BI の実装: 14件中13件・全部軽微）。★結果ファイルは途中で切れるので `journal.jsonl` から組み立てる★（`started` の `agentId`→`label` で指摘と判定を対応づける）
- ★Cursor の担当と「こちらで直して」★: 指示書の実装は Cursor。★ユーザーが「こちらで直して」と言ったものだけ Claude Code 側でサブエージェントに直させる★（文言の統一・BI の軽微5項目）。メインは担当を分けて委譲し、差分とテストを自分で確かめる

### このセッションで分かった罠

1. ★ステージングは予定なしの行が大半★（詳細ログ 636件中 596件が予定なし。予定ありは40件で全部出発失敗。11-04 実測・先方投入）→ ★「予定あり」が少ない・▼ が少ないのは不具合ではない★（ユーザーが「アドバイスが消えた」と感じた原因。BI で予定なしにも出すようにした）
2. ★詳細ログのツールバーは 1366px で2行になる★（予定のプルダウン 160px を足したため。承知のうえ。BH §12-2）
3. ★開いた行の見出し（`adviceHead()`）とアドバイス本文は EN でも日本語★（前から。本文は運用設定の日本語）
4. ★`d-watch-api.yaml` は js-yaml で読めない箇所が1つある★（`precheck_minutes` の説明の「(旧: …」の `: `。HEAD 以前から）。新しい変更で増えていないかは「この1件だけか」で確かめる
5. ★`clean_task_reports.report_id` は varchar(20) の文字列★（19桁で安全な整数を超える。`Number("1315386034733453312")` は `…300` に丸まる）。`parsePathId()` を流用しない（`parsePathReportId()`）
6. ★`UNSCHEDULED_TIMETABLE_ID_WHERE` はトップレベルの `OR`★。他の条件は展開して並べる（`AND` で包むのは OR が2つになるときだけ）。★`app/api/clean-logs/__tests__/route.test.ts` のスタブの `matchesWhere` は `AND` を黙って無視する★
7. ★予定あり／予定なしの向き★: エラー一覧は `key.scheduled`（true＝予定あり）、詳細ログは `r.unscheduled`（true＝予定なし）。`matchesScheduleFilter()` には必ず「予定あり＝true」を渡す
8. ★アドバイスを開けるかは表の側（`view.expandable`）が決める★。`cleanLogAdviceUrl()` は ID が欠けた行だけ null（◎・結果待ちでも URL を返す）

### 残り（次にやること）

| 順 | 内容 |
|---|---|
| 1 | ★`docs/decisions.md` に BH・BI の決定を記録★（D-182 以降。★別セッションが decisions.md を編集中なので、そのコミットを待ってから★）。中身は指示書BH §10・§12-8・§13、BI §9（10-29〜10-30 の「0 は予定外」「A案」「アラートは事前チェックだけ」「進み具合は前日」「status 6・不明(n)」「施設マスタの並べ替え」も） |
| 2 | ★`d-watch-api.yaml` を YAML として読めるように直す★（上の罠4。別タスク） |
| 3 | 必要なら: 開いた行の見出しの EN 対応（罠3） |
| 4 | ★施設69（MEGAUNY稲沢東店・ロボット2台）のデータが入ったら表示を確かめる★（10-30 の確認では問題なし。データ待ち） |
| 5 | 下の「次にやること」（10-07 時点）の PR #6・第12回の回答・点検記録画面（F-05）・契約によるメニューの出し分け・セキュリティはリリース直前、は★まだ残っている前提で、実測してから★進める |

---

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

★★`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 実測。古い — 最新は上の「2026-10-30〜11-04 の作業」★）

| 項目 | 値 |
|---|---|
| ブランチ | `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. ★テスト数と最終決定番号★が上の表（★2026-11-04 時点: 157ファイル / 3,855件 / コミット済みの決定は D-181。HEAD `619e21d`★）と一致するか
3. ★未 push のコミットがあるか★ / ★PR #6 の状態★（★最新の head の CI は緑か / レビューが通ったか / head はどこか★）
4. ★第12回（送付版。R-1〜R-3）を送ったか / 先方のデータ投入が終わったか（予定と実績がつながったか） / 回答が来ているか★（★回答が来ていたら受領日の記録が最優先★。レポートの最大の遅れの回答が来ていたら `RESULT_WAIT_MINUTES` を見直す。D-173）

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

## この文書について

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