# セッション引き継ぎ（★2026-10-06 指示書AW 実装後に更新★・ブランチ `develop`）

## この文書の位置づけ — ★最初に読むこと★

- ★**これが入口です**★。`docs/handoff.md` は全履歴（★追記62まで★）、`docs/decisions.md` は
  決定の台帳（★D-160まで・148件★）で、どちらも読み切るには大きすぎます。
- 本文書は ★**「現在地」と「次の一手」だけ**★ を1枚にまとめたものです。
  ★ファイル名は 20260917 のまま★（`/d-watch` スキルがこの名前で指しているため）。中身は 2026-10-06（指示書AW の実装後）に書き直しました。
- ★★本文書と `docs/handoff.md` / `docs/decisions.md` が矛盾したら、後者2つが正★★です。
- ★前々版は `docs/handoff/セッション引き継ぎ_20260916.md`★（★内容は古い★）。
- ★★本書の数字も書いた瞬間から古くなります。必ず自分で実測してください★★。

---

## 0. 30秒で読む現在地（★2026-10-06 実測★）

| 項目 | 値 | 測り方 |
|---|---|---|
| ブランチ | `develop`（★`main` へ直接 push しない★）。測った時点の HEAD は `f02eb1d`（本書を更新したコミットは含まない）。★origin/develop は `19dbe38`。★未 push は指示書AW の8コミット（`fc9b3cf`〜`f02eb1d`）と、その後の資料のコミット（`a8b2943` 以降）★ | `git log -1` / `git rev-list --count origin/develop..develop` |
| 最終決定番号 | ★D-160★（148件。D-160 に AW の「実装の記録」を足した） | `grep -n "^### D-" docs/decisions.md \| tail -3` / `grep -c` |
| 最新の追記 | ★追記62★（指示書AW の実装） | `grep -n "^## 追記" docs/handoff.md \| tail -1` |
| `main..develop` | ★499コミット★（`origin/main..origin/develop`。手元の develop は＋8（AW）＋資料のコミット）。★fetch はしていない（手元の参照。PR #6 の head は `gh` で `19dbe38` と一致）★ | `git rev-list --count origin/main..origin/develop` |
| ★PR★ | ★#6 が open・CI緑（SUCCESS。head `19dbe38`）・**レビュー未了**（`reviewDecision` 空）★ | `gh pr view 6 --json state,reviewDecision,statusCheckRollup` |
| テスト | ★119ファイル / 2,790件 全パス★ / `tsc` 0 / `lint` 0 / `USE_FIXTURES=true` の `build` 成功（監督が `f02eb1d` で確認） | `npx vitest run` ほか |
| 指示書 | 45本（★次は `AX`★）。★AW まで実装済み★（AP は保留のまま） | `ls docs/handoff \| grep -c "^指示書"` |

---

## 1. ★★接続先はステージングです — 4カラムだけ書き込んでよい★★

★★`133.125.238.144` / `clean_watch` は**ステージング**。本番DBは別にある★★（D-152。D-148「本番DBそのもの」は破棄）。

- ★★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 Access denied`。D-157）。11:15 JST の再実測は D-158 末尾
- ★★先方は 10-06 時点でデータを投入している最中★★: `clean_task_reports` 54行がすべて `clean_timetable_id` が NULL（予定外扱い）で、★予定と実績が1件もつながっていない★。
  ★投入が終わったら再実測する★（D-158 末尾）
- ★★4カラムの書き込みは 2026-10-06 16:11 JST にエラー一覧（`/errors`）から確かめた★★（`1000013` の1行。権限エラーなし・4列は操作前と完全一致。先方投入データ。追記62 §3）。
  ★ステージングのエラー16行はすべて本清掃に紐づくので、アラート画面（`/alerts`）から書ける行は無い★
- ★`scripts/seed-local-db.ts` はステージングに絶対に向けない★（テーブルを消して入れ直す。`lib/db/local-guard.ts` が拒否する）

★**実測値を書くときは出所を必ず併記すること**★（`CLAUDE.md` §6-6）。
★当方のシード由来 / 先方投入 / 構造（`information_schema`・`SHOW`・`EXPLAIN`）のどれか★。
★出所を書けない数字は「実測」と呼ばない★。

---

## 2. ★次にやること（優先順）★

### 1位 — ★指示書AW の8コミットと資料のコミットを push する★

- ★未 push★: 指示書AW の実装（`fc9b3cf`〜`f02eb1d` の8件）と、その後の資料のコミット（`a8b2943` 以降）。origin/develop は `19dbe38`。★監督が差分を確かめてから push★
- push すると PR #6 の head が進むので、★CI が緑のままか確かめる★

### 2位 — ★ステージングの投入が終わったら再実測★

- 予定と実績のつながり（`clean_task_reports.clean_timetable_id`）・`clean_timetable_histories` の行と warn `db.timetable_conflict` の有無（指示書AU 段階3b）
- ★ダッシュボードの直近モードの内訳★（10-06 15:0x は11エリア・成功9・失敗1・未実施1。追記61 §3）
- ★`prisma db pull`★ — ★`serial_number` の拡張（varchar(100)）を確かめてから★（ユーザー指示 2026-10-06。10-06 は varchar(20) のまま）
- ★事前チェックに紐づくエラー行が入ったら、アラート画面（`/alerts`）からの書き込み（指示書AT 段階9）★。4カラムの書き込みそのものは `/errors` から確認済み（上の §1）

### 3位 — ★PR #6 のレビューを通す★

- ★積み上げ PR に分けて daichi がレビューし `main` に入れる★（`docs/handoff/PRレビュー手順_20261001.md`。D-154。区切りは数え直す）
- ★`main` は 2026-08-27 で止まったまま★。★差が開くほどレビューが不可能になる★

### 4位 — ★点検記録画面（F-05）の指示書を書く★

- ★唯一の未実装画面★（`app/(dashboard)/inspections/page.tsx` は `PlaceholderScreen` の5行）
- ★独自ストア＋写真管理。メインDBに保存しない★（`CLAUDE.md` §7）。★TeamWorks 待ちが無い★
- ★`customer_name` の説明に残した「ブランド」列★（`d-watch-api.yaml` の `Facility` / `InspectionListItem`、`lib/types/index.ts` の2か所）もここで合わせる（追記60 §6）

### 次点

| # | 内容 |
|---|---|
| A | ★次回（第12回）確認事項の候補★（D-158 項7）: 予定が `clean_timetable_histories` に移る時期／「清掃開始できなかった」エラーの `error_type` の値（10-06 に `NOT_STARTED` を観測。D-158 末尾）／P-9 の `clean_timetable_id` は本清掃・事前確認のどちらか／P-13「本日中に修正」の対象。★AV の §11 Q8（レポートが書かれるまでの遅れ。落ち着き30分で足りるか）も候補★ |
| B | ★次フェーズ★（D-158 当方の対応5）: エラーの3区分（ロボット／制御盤／セキュリティ・清掃開始失敗）・D-Sec アラートの取得元を `robot_error_reports` に切り替え（P-10）・出発失敗の対応状況の書き込み。★エラー一覧（`/errors`）は種類を生値のまま出している（区分は作っていない。D-160 項3）★ |
| C | ★指示書AV で範囲外にしたもの★（§10・§11）: 数値カードから移ったときの遷移先の条件／遡り日数・落ち着き時間を画面から変えること（Q6）／7日以内に予定が無いエリアを知らせること（Q7） |
| C2 | ★指示書AW で範囲外にしたもの★（§10）: 件数カード・メニューのバッジ・CSV／`Precheck*` の名前の一般化／`/alerts` と `/errors` の部品の共通化。★契約によるメニューの出し分けは P2（顧客に使わせる前に必ず。D-160 追記4）★ |
| D | ★375px 幅でサイドバーが畳まれない★（ダッシュボードの見出しが4行に折り返す・エラー一覧は右側が切れる。今回以前からの作り。追記61 §5・追記62 §5）／★AU の EN・375px のブラウザ目視★（追記60 §5。記録なし）／★エラー一覧のツールバーは JP で「解消済みも表示」が2行目に回る★（EN は1行。表の列幅は動かない） |
| D2 | ★i18n の「備考」→ "Note" を足した副作用で、D-Secログの備考列の見出しが EN で "NOTE" になった★（これまでは EN でも「備考」。追記62 §5）。誤訳ではないので直していない |
| E | ★指示書AP（レポート画面のエラー表示）★ — ★作成済み・**保留**★ |
| F | ★規模前提のコメント14か所★ / ★EN の抜け★（保留） |

### ★リリース直前にまとめて行う（D-154）★

一覧は `CLAUDE.md` §3。★`lib/config/allowed-ips.ts:35` の `ALLOW_ALL_WHEN_EMPTY` が `true`★（このままだと誰でも通る）／
★`AUTH_TOKEN` が `.env.example` で `changeme`★／接続元の制限・TLS／ステージングDBのパスワード変更／ログインの試行回数制限と cookie の中身。
★あわせて見直すもの★: 清掃詳細ログの期間なしの取得の性能（既定を全期間にした。Prisma 版は保持期間の予定を全部読んでからページ分けする。D-159 追記）／★エラー一覧の「解消済みも表示」の性能★（保持期間ぶんのキーを読む。D-160 追記2）／★契約によるメニューの出し分け★（顧客に使わせる前に必ず。D-160 追記4）。

---

## 3. 外部待ち — ★第11回は 2026-10-05 に回答受領（D-157 / D-158）★

| 待っているもの | ブロックされていること |
|---|---|
| ★先方のデータ投入の完了（10-06 は投入中）★ | ★予定と実績がつながった状態での確認すべて★（上の 2位） |
| P-13「本日中に修正予定」の対象（権限か、ログインできない件か） | 4カラム更新の権限の確認（★10-06 にステージングで `/errors` から書けた・権限エラーなし。追記62 §3★。どのアカウントの権限で通ったかは未確認） |
| ★DDL 変更の取り込み★: `robot_id` は NULL 可になった（10-06 構造で確認）。★`serial_number` は varchar(20) のまま★（P-8 c の拡張は未反映） | `prisma db pull`（★拡張を確かめてから★）。★それまでは `robot_error_reports` を `select` で絞って読む★（`lib/db/robot-error-select.ts`） |
| 第9回 Q6-2（サマリに実施回数の列） | ★確定期間の稼働率は検算できない★（第11回 P-6 で式は確定。分子＝正常終了の回数の列が無い） |
| 上の「次回の確認事項の候補」 | まだ送っていない |

★**第11回で決まったこと**★（D-158）: 完了率の式は確定（P-2=A）／`task_area = 0` は 0%（P-5=B）／当期 KPI はサマリの式（P-6）／
予定は `clean_timetables` と `clean_timetable_histories` の両方（P-7=C）／`customers` は法人（P-15=B）→ 見出しは「顧客」／本番DBも JST（P-11=A）。
★いずれも指示書AU で実装済み★（追記60）。

★回答が来たら**受領日を `docs/decisions.md` に記録すること**★（★送付と受領の両方を記録する★）。

---

## 4. ★完成しているもの★

★`app/(dashboard)/` の画面12枚中11枚が実装済み★（＋ログイン）。★空なのは点検記録だけ★（`find app -name page.tsx` と `PlaceholderScreen` の grep で確認）。

ダッシュボード / 清掃詳細ログ / アラート / ★エラー一覧（10-06）★ / レポート / 清掃面積 / D-Secログ / D-Secアラート /
施設ロボットマスタ / スケジュール管理 / システム管理（＋ログイン）。

- ★2026-09-17 に全画面をブラウザで目視確認済み★（追記58）
- ★AR〜AT の変更（清掃結果の表示名・総清掃面積の注記・アラートの状態ボタンと備考）は fixtures で確認済み★（`/d-watch` スキルの記述。日付は 2026-10-05）
- ★AU の変更は fixtures の API で境界値を確認済み・ブラウザ目視は記録なし★（追記60 §4・§5）
- ★AV（ダッシュボードの直近モード・清掃詳細ログの既定を全期間）は fixtures の本番ビルドを Edge ヘッドレスで撮影して確認、ステージングでも API を確認済み★（追記61 §3）
- ★AW（エラー一覧）は fixtures の API と画面（撮影）・ローカルDB（当方のシード由来。49行）・ステージング（先方投入。16行。1行を書いて戻した）で確認済み★（追記62 §3）

---

## 5. ★最近わかった重要なこと★

| # | 内容 |
|---|---|
| 1 | ★ダッシュボードの数値カードと表は「各清掃エリアの直近の清掃（7日以内・終わった予定のみ・出発失敗を含む）」★（D-159）。★スケジュール進捗・要レスキュー・セキュリティバナーは当日のまま★なので、★カードと進捗は母集団が違う★（`?date=` を指定したときは従来どおりその日） |
| 2 | ★実データの清掃は 10:00 や 19:00〜22:00（前日の日付）★。サンプルデータ（深夜 1:30〜3:30・当日の日付）とは時間帯が違う。★「当日の日付で数える」作りは、実データでは翌朝に空になる★（D-159 のきっかけ） |
| 3 | ★清掃詳細ログの既定は「期間を指定しない（全期間）」★（D-159 追記。ユーザー指示「C」）。★片方だけ日付を入れたら入っている側だけを送る★（追記61 §4） |
| 4 | ★当期の稼働率は以前より低く出る★（分子が「正常終了（status 4）」に変わった。例: 予定10・開始9・正常終了7 → 90% から 70%）。★施設ステータスの閾値（good 90 / warning 75。`lib/config/index.ts:565-570`。`137a94b`）は据え置き★（D-158 項8。D-158 は「90/80」と書いているが実物は 75） |
| 5 | ★予定は2表から読む★。★同じ id は `clean_timetables` 側を採る★（履歴の id は本表の id のコピー。ユーザー回答 2026-10-05） |
| 6 | ★制御盤・セキュリティ・「清掃を開始できなかった」エラーも `robot_error_reports` に入る★（P-8・P-10）。★区分の見分けは次フェーズ★。★それらを全部見る画面がエラー一覧（`/errors`）★（D-160。アラート画面は事前チェック＋出発失敗だけのまま） |
| 7 | ★`clean_task_reports.started_at` は、予定のある清掃では予定の `start_at` と同じ値★（ユーザー回答 2026-10-05「A」）。★期間の振り分けは画面どうしで一致する★ |
| 8 | ★エラー一覧は「2段階で読む」★（キーだけを SQL で絞って全件読み、アプリで並べてページ分け → そのページの行だけ読み直す）。★並びの `errored_at ?? created_at` を Prisma のクエリビルダで書けないため★（`nulls last` で近似すると `errored_at` が NULL の行が末尾に回る。D-160 追記2）。★4カラムの書き込みは `/alerts`（事前チェックの行だけ）と `/errors`（全行）の2本のルートから★ |

---

## 6. 触ると危ない場所（★次の人が踏む地雷★）

★前々版 §6 の14件（2026-09-16 時点の記述。接続先の呼び名など古い所がある）も読むこと★（`docs/handoff/セッション引き継ぎ_20260916.md`）。
★特に事故が起きやすいもの★（いずれも★例外もテスト失敗も出ないまま結果だけ間違う★）:

1. ★`facility_ids` の `null`（全件）と `[]`（0件）は別物★ — `?.length` で分岐すると★全件が静かに返る★
2. ★`facilities.contract` は `varchar(10)` の桁位置★ — 数値比較すると★全施設が「契約なし」になる★
3. ★表示用に丸めた値で判定しない★（判定は生値、丸めは表示層だけ）
4. ★DATETIME は JST の壁時計値★ — ★生の値に9時間を足さない★（`CLAUDE.md` §3）
5. ★★4カラム以外を書かない★★（書き込みは `lib/db/robot-error-write.ts` の1ファイルだけ。★ルートは `/prechecks/{id}/status` と `/errors/{error_id}/status` の2本になったが、どちらも `writeRobotErrorColumns()` を通る★）
6. ★★予定を `prisma.cleanTimetable` で直接読まない★★ — ★必ず `lib/db/timetable-source.ts` を通す★。直接読むと履歴の表が抜ける。★`count` / `groupBy` を2表にまたがって書かない★（同じ id の重複を引けない）
7. ★★`robot_error_reports` を `select` なし・`include` で読まない★★ — `robot_id` が NULL の行が1件入っただけで読み取りが落ちる（`lib/db/robot-error-select.ts` の定数を使う）
8. ★★`cleanLogs()` と `cleanLogRunMeta()` の `where` を別々に書かない★★ — 非公開の `mainTimetableWhere()`（`lib/db/index.ts`）を共有している。片方だけ直すと、ダッシュボードの行とメタの突き合わせが静かにずれる（対応が無ければ `pickLatestRunPerSection()` が例外）
9. ★ダッシュボードの「現在」はルートで1回だけ作る★（`app/api/dashboard/route.ts` の `const now`）。窓と選び方が別の「現在」を見ると、終了＋30分ちょうど付近で母集団がずれる
10. ★「実測」と書くときは出所を併記する★（`CLAUDE.md` §6-6）
11. ★新しいクローンでは `npx prisma generate` が要る★（`lib/generated/prisma` は gitignore 対象）
12. ★ワークツリーでは `npm run build` が落ちる★（Turbopack が node_modules のジャンクションを拒否。"Symlink [project]/node_modules is invalid"）。★ビルドは本体で行う★
13. ★vitest でモックした `@/lib/db/prisma` を2本同時に動的 import すると、片方に本物が返る★（テスト環境だけ。ルートが `Promise.all` で2つの `db.〇〇()` を呼ぶと500）。エラー一覧の GET のテストは `vi.spyOn` で差し替えた。★`/clean-logs` の Prisma 経路テストで施設名と分類を同時に試すと同じ罠を踏む★（追記62 §4）
14. ★i18n のキーは全画面で共有★ — エラー一覧で「備考」→ "Note" を足したら、D-Secログの見出しも EN で "NOTE" に変わった。★キーを足すときは同じ文字列を `t()` に通している画面を grep する★
15. ★Bash ツールはヒアドキュメントの中でも `\\` を `\` に縮める★（正規表現の `\S` 等を書くスクリプトは Write ツールで書く）

---

## 7. 作業の進め方（この案件の作法）

1. ★実装は自分で書かない。指示書を書いて Cursor に渡す★（★渡し方はファイル名を指すだけ★）。
   ★例外: ユーザーが Claude Code に「ここで実装して」と明示したとき★（AR〜AW はこれで実装した。`.claude/commands/d-watch.md`）
2. ★完了報告を受けたら**独立したエージェントで検証**してから受け入れる★
3. 検証が通ったら ★`docs/handoff.md` に追記★ ＋ ★`docs/decisions.md` に決定を記録★
   （★採番前に `grep -n "^### D-" docs/decisions.md | tail -3` で実測する★。
   ★`^### D-0` では3桁台を拾えない★）
4. ★指示書を2本同時に走らせない★（決定番号の衝突事故あり）
5. ★判定ロジックは「期待値表の確定 → テスト作成 → 実装」の順を崩さない★
6. ★API契約を変えたくなったら、先に `d-watch-api.yaml` を直す★
7. ★★仕様が不明なら止まって確認を求める★★
8. ★`git add -A` は禁止★。★必ずファイルパスを明示する★
9. ★dev サーバーは Browser pane の `preview_start` で起動する★（fixtures は `d-watch-fixtures`、ポート3100）。
   ★サブエージェントが起動した dev サーバーは止めてから終わらせる★
10. ★別の Claude セッションが同じ develop に docs のコミットを積むことがある★（2026-10-06 に `7cb7660` が作業中に入った）。
    ★コミット直前に `git status --short` と `git log --oneline -3` を見て、自分のファイル以外を巻き込まない★

---

## 付録: よく使う出典

| 知りたいこと | どこを見るか |
|---|---|
| 全履歴 | `docs/handoff.md`（追記62まで） |
| 決定と理由 | `docs/decisions.md`（D-160まで） |
| 仕様の正・禁止事項 | `CLAUDE.md` |
| API契約 | `d-watch-api.yaml` |
| 画面の正 | `d-watch-mock.jsx` |
| 何がどこで決まっているか（非エンジニア向け） | `docs/code-map.md`（第4版。2026-10-06 に AU・AV・AW 分を改訂） |
| 最新の外部回答 | `docs/handoff/TeamWorks回答_第11回_20261005.md`（整理は D-158） |
| 最新の指示書 | `docs/handoff/指示書AW_エラー一覧ページを作る_20261006.md`（§13 に実装の記録） |
| サンプルデータでダッシュボードに何が出るか | `docs/fixtures.md` §12.3（直近モード） |
| サンプルデータでエラー一覧に何が出るか | `docs/fixtures.md` §13（既定10行・全11行） |
| PR の分け方 | `docs/handoff/PRレビュー手順_20261001.md` |