Fork: 0
develop / client_dwatch
Transfer to URL with SHA Find file
Newer
Older
client_dwatch / docs / handoff / セッション引き継ぎ_20260917.md
@DFA-takeuchi DFA-takeuchi 20 days ago 21 KB D-Watch ソース一式（GitHub DFARobotics/d-watch の develop f07f7bf 時点のスナップショット。履歴なし）
Raw Blame History

セッション引き継ぎ（★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