セッション引き継ぎ（2026-09-16 時点・ブランチ develop）

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

• docs/handoff.md は★日付ごとに積み上がる全履歴★です（現在 追記52 / 4824行）。 全部読むと時間がかかるので、入口として本文書を作りました。
• 本文書は★2026-09-16 時点の「現在地」と「次の一手」だけ★を1枚にまとめたものです。 網羅性はありません。経緯・理由・破棄された案は一切書いていません。
• ★★本文書と docs/handoff.md / docs/decisions.md が矛盾したら、後者2つが正★★です。 本文書は入口にすぎません。判断を下す前に必ず出典元に当たってください。
• 仕様そのものの正は CLAUDE.md §4〜§9 と d-watch-api.yaml です（CLAUDE.md §5 の表）。

★★その後（2026-09-16 夜に追記。本書より新しい）★★

★本書 §2 の「次にやること」1〜4位は、すべて片付きました★。 ★最新の状態は docs/handoff.md の追記53・追記54、決定は D-142 / D-143★です。 ★以下の §0〜§5 は「2026-09-16 昼の時点」の記録として読んでください★。

★本書に書かれていない重大な変更★:

• ★責任分界が変わりました★ — ★DFA が作るのはビューアーだけ★。★サーバー・ネットワークの 用意と構築保守（本番のアプリVM / DB / テスト環境）はすべて TeamWorks★（D-143 項1）。 ★CLAUDE.md §2・§3 を更新済み★。★D-100 項5 は誤りなので従わないこと★
• ★origin/develop は push 済み★（本書 §0 の「未push」は解消）
• ★指示書AO を作成★（docs/handoff/指示書AO_…md。★Cursor に渡す★）

0. 30秒で読む現在地

★要点★: 実装はよく進んでいる（355コミット）が、★外部（TeamWorks）待ちが全件未回答のまま溜まっており、 main は3週間放置★。コードを書き足すより、詰まりを外す作業のほうが優先度が高い状態です（→ §2）。

1. 直近で終わったこと（新要件4件は★すべて実装完了★）

ユーザーが 2026-09-15〜16 に出した新要件4件は、すべて実装まで到達しています。

★★#3 の積み残し（唯一の実装上の穴）★★

ユーザー原文の4条件「出発失敗3日連続 / 連続問題レベル3 / 完了率急落 / 未実施3日連続」のうち、 ★「出発失敗」だけが実装されていません★。

• ★理由★: ★実際の清掃開始時刻がDBに無く★、猶予30分の計算材料が無いため「出発失敗」と「未実施」を 分けられない。現在のコードでは同じ判定（notExecutedFromHistory()）に潰れている。 出典: lib/judge/rescue.ts:20、lib/config/index.ts:54-59
• ★ブロッカー★: TeamWorks ★第9回 Q11-1★（未回答）。docs/handoff/TeamWorks確認事項_第9回_20260915.md
• ★回答が来たときの足し方は手順化済み★: docs/handoff.md:4426-4440 （①lib/judge/rescue.ts の RescueReason に識別子追加 → ②閾値は RESCUE_THRESHOLDS に足す 〈★ESCALATION_THRESHOLDS.level3Days を流用しない★〉 → ③d-watch-api.yaml の enum を先に直す → ④期待値表→テスト→実装の順）

併せて終わっていること

• ★判定境界の変更★ — ユーザー指示「◯、×は90%以上のように境はふくめてください」により、 ★90.0 → ◎ / 70.0 → ○ / ★10.0 は △ のまま★★ に確定。★D-139★（docs/decisions.md:10743）。 実装は 指示書AL 段階4 ＋ 指示書AM_判定境界の追随漏れを片付ける.md。★D-020b は破棄★（:89）。
• ★サイドバーのスクロールを本文と独立させた★ — ★D-137★（docs/decisions.md:10367）。 ただし★375px 幅は未対応のまま★（docs/decisions.md:10597）。

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

1位 — 第9回確認事項の★送付状況を確定し、docs/decisions.md に記録する★

• ★何を★: docs/handoff/TeamWorks確認事項_第9回_20260915.md（716行）を送付済みかを確認し、 ★未送付なら送る★。送った日を docs/decisions.md に必ず記録する。
• ★なぜ今か★: ★★全20問＋依頼9件が未回答で、これが全ての外部ブロッカーの根★★。しかも ★「送付した」記録が docs/decisions.md に1行も無い★。 ★★過去に第1回・第4回で同じ記録漏れを2回やっている★★（docs/handoff.md:1545-1549 に自戒あり）。 ★今回が3回目になりかけている★。
• ★最初の一歩★: grep -n "第9回" docs/decisions.md で記録の有無を確認 → 無ければ送付有無をユーザーに確認 → 送付日を docs/decisions.md に追記。

2位 — DB接続経路のセキュリティ申し送り4項目を、★正式に外へ渡す★

• ★何を★: docs/handoff.md:3655 以降（追記41）の「TeamWorks / インフラ担当への申し送り」4項目を 正式に手渡す。内訳は次のとおり。 | # | 内容 | |---|---| | 1 | テストDB 133.125.238.144 が★公開IPに平文★（have_ssl=DISABLED / require_secure_transport=OFF / 接続元 参照用アカウント@%） | | 2 | npm audit が mariadb コネクタに「ssl: true でも平文パスワードが漏れる」を報告。★No fix available★ | | 3 | 実在DBユーザー名が★Git履歴に残存★（a5502ac。c832891 で除去済みだが★履歴は未書換★） | | 4 | 本番構成（VM＋DBアプライアンス）の★明示確認が未取得★（D-100 / CLAUDE.md §3） |
• ★なぜ今か★: ★★期限が「ステージングに実データが入る前」★★。★この期限を過ぎると作り直しになる★。 アプリコード側では直せない（追記41 の前提: ★アプリコードに危険な箇所は1件も見つかっていない★）。
• ★最初の一歩★: docs/handoff.md:3655-3697 をそのまま読み、宛先（TeamWorks か インフラ担当か）を決める。

3位 — ★未コミット4件を片付ける★

• ★何を★: lib/db/prisma.ts を★単独コミット★し、未追跡 md 3件の扱いを決める（→ §4 に詳細）。
• ★なぜ今か★: ★★4日間・5つの作業（追記48〜52）が連続で「触らない」と判断して回避し続けている★★ （docs/handoff.md:4463 / :4615 / :4682 / :4758 / :4823）。 ★実DB検証がこの変更に依存しており、すでに5コミットがこれを前提にしている★。放置すると事故る。
• ★最初の一歩★: git diff lib/db/prisma.ts を読む → ★git add lib/db/prisma.ts（★パス明示★）★ → 単独コミット。★git add -A は禁止★（CLAUDE.md §7）。

4位 — ★PR説明骨子を確定版に更新する★

• ★何を★: docs/handoff/PR説明_develop_to_main_骨子.md（383行）を最新化する。 | 直す点 | 現状 | |---|---| | 決定の反映 | D-050〜D-112 まで。★D-113〜D-141 の29件が未反映★ | | コミット数 | ★記載191 / 実測355★ | | 解決済みなのに「未完成」欄に残っている | #2 areas の501（D-119で実装）/ #3 continuousProblems（D-116）/ #4 ページ送り（D-120）/ #5 メモリ絞り込み（D-131でSQL化）/ #6 DATETIMEのTZ（D-115）の★5件★ | | §8 マージ前チェックリスト10項目 | ★1つも消化されていない★（うち「指示書X 完了」「指示書W 完了」は★実際は完了済み★） | | §6 マージ方式 | マージコミット vs squash の★合意が未取得★ |
• ★なぜ今か★: ★main が2026-08-27 で止まっており、355コミットの差がある★。 差が開くほどレビューが不可能になる。骨子が古いままだと PR を出せない。
• ★最初の一歩★: git rev-list --count main..develop と git diff --stat main..develop を実測し直し、 骨子の数字を置き換えるところから。

5位 — ★目視確認をまとめて1回やる★

• ★何を★: 追記50・51・52 で積み残した目視確認3件分（→ §5 に一覧）。
• ★なぜ今か★: ★★3追記連続で「ログインが要るため未確認」になっている★★ （docs/handoff.md:4663 / :4707 / :4795）。溜めるほど、どの変更が壊したか分からなくなる。
• ★最初の一歩★: ★「もっと表示」は USE_FIXTURES=true でないと踏めない★（実DBは施設10件ちょうど）ので、 ★fixtures 版と実DB版の2周を回す段取り★を先に決める。

次点（外部待ちではなく★社内判断で潰せる★もの）

3. 外部（TeamWorks）待ちの一覧 — ★全20問＋依頼9件が未回答★

出典: docs/handoff/TeamWorks確認事項_第9回_20260915.md（716行）

★★注意: この第9回を「送付した」という記録が docs/decisions.md に1行も無い★★。 docs/handoff.md:1545-1549 が★「送付したら必ず記録すること。第1回と第4回で同じ記録漏れを 2回やっている」★と明記している。★まず送付状況の確定から★（→ §2 の1位）。

★どの質問が何をブロックしているか★

その他の外部待ち（第9回に載っていない／継続中のもの）

4. 未コミットの4件をどうするか

lib/db/prisma.ts（変更あり）— ★★単独コミット推奨★★

★★git add lib/db/prisma.ts のようにパスを明示してコミットすること★★。 ★git add -A は禁止★ — 過去に別作業の途中ファイルを巻き込む事故が起きている（CLAUDE.md §7）。 このファイル以外の3件が同時に未追跡なので、★まさにその事故が起きうる状況★です。

未追跡 md 3件

5. 誰も見ていないもの（★目視未確認★）

★★追記50・51・52 の3回連続で「ブラウザ目視は未実施」のまま積み残されています★★。 理由は追記ごとに少しずつ違い（追記50「環境上未実施」/ 追記51「ログインが要るので未確認」 「devサーバの二重起動ができず」/ 追記52「ログインが要る環境のため」）、 査読・実装のいずれのエージェントも★HTTPレベル（SSR HTML・API応答）の確認に留まっている★。

出典: docs/handoff.md:4663-4666（追記50 §3）/ :4717-4718（追記51 §2-3）/ :4795-4798（追記52 §2-6）

★★「もっと表示」は実DBでは踏めません★★ — ★実DBは施設10件ちょうど★なので この経路自体に到達しない。★USE_FIXTURES=true でないと確認できない★（docs/handoff.md:4795）。 ★fixtures 版と実DB版の2周を回す段取りを先に決めてから着手すること★。

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

★補足（本リポジトリの文書には規定がなく、セッション環境側の作法）★: dev server は Browser pane の preview_start で起動してください。 ★過去の追記は Browser pane が無い環境だったため npm run dev をバックグラウンド起動していますが★ （docs/handoff.md:2155 / :2223）、それは環境上の制約による回避策です。

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

1. ★★実装は自分で書かない。指示書を書いて Cursor に渡す★★。
   • 置き場: docs/handoff/指示書XX_….md
   • 渡し方は★この1行だけ★:

     docs/handoff/指示書AN_総清掃面積の画面を作る.md を実行してください

2. ★完了報告を受けたら、★★独立したエージェントで検証★★してから受け入れる★（自己申告を鵜呑みにしない）。
3. 検証が通ったら:
   • docs/handoff.md に★追記★する（日付・指示書名・やったこと・★やっていないこと★・残課題）
   • docs/decisions.md に★決定を記録★する （★採番前に grep -nE "^### D-(0|1)[0-9][0-9]" docs/decisions.md | tail -3 で最終番号を実測する★ — ★このファイルは番号順に並んでいないので末尾では最大値を判断できない★。docs/decisions.md:10370 参照）
4. ★指示書の記号は AA〜AN まで使用済み（AD は欠番）。★★次は AO から★★。
5. ★判定ロジックは「期待値表の確定 → テスト作成 → 実装」の順を崩さない★。 ★期待値表の確定だけは分担・委譲しない★（CLAUDE.md §0-2 / §9.4）。
6. ★API契約を変えたくなったら、先に d-watch-api.yaml を直す★（CLAUDE.md §6-1）。
7. ★★仕様が不明なら止まって確認を求める★★。推測で実装しない（CLAUDE.md §0-1 / §7）。

8. 用語と数値の早見表

判定基準（◎○△×）— ★★境界はすべて「上のランクに入る」（D-139）★★

出典: CLAUDE.md §4.1 / docs/decisions.md:10743（D-139）/ lib/config/index.ts:11-25 ★D-020b（境界は下のランクに落ちる）は破棄★（docs/decisions.md:89）。

★丸めの例★: 90.4 → 表示 90% だが判定は ★◎★ / 89.5 → 表示 90% だが判定は ★○★（CLAUDE.md §9.4）

KPI 4式（CLAUDE.md §4.2）

稼働率       = 清掃実施回数 ÷ 清掃予定回数 × 100
出発成功率   = 定刻出発回数 ÷ 清掃予定回数 × 100
清掃完了率   = Σ清掃面積 ÷ Σ清掃対象面積 × 100   ← ★面積ベース★（時間ベースではない）
エラー発生率 = エラー発生回数 ÷ 清掃実施回数 × 100

主要な設定値 — ★lib/config/index.ts で実測して照合済み★

★注記★: 前段の調査報告は AREA_UNIT を :689、MAX_CSV_ROWS を :372 としていましたが、 ★実ファイルの実測はそれぞれ :696 / :384★でした。★実ファイルを正★とし、上表は実測値に直してあります。

用語（CLAUDE.md §8）

★P1の前提: 1清掃エリア = 1ロボット★（テーブル構造は複数台対応可能だが、P1ではこの前提）。

付録: よく使う出典の索引