# セッション引き継ぎ（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 昼の時点」の記録として読んでください**★。

| 本書 §2 の項目 | 結果 |
|---|---|
| 1位 第9回の送付状況を確定 | ★**未送付と確定**★（daichi 明言）。★申し送りを統合して1通にし、PDF（23ページ）まで完成★。★残るのは送付と送付日の記録だけ★ |
| 2位 申し送り4項目を外へ渡す | ★完了★。TeamWorks が動ける3項目は★第9回の12章に統合★。項目2（`mariadb`）は★DFA内部の判断として内部記録に残した★ |
| 3位 未コミット4件 | ★完了★（0件）。`lib/db/prisma.ts` から★実在DBユーザー名の既定値も除去★ |
| 4位 PR説明骨子 | ★完了★（383→561行）。★マージ方式はマージコミットで確定★ |
| 5位 目視確認3件 | ★未実施★（★5回連続で積み残し★） |

★**本書に書かれていない重大な変更**★:
- ★**責任分界が変わりました**★ — ★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秒で読む現在地

| 項目 | 値 | 出典 |
|---|---|---|
| ブランチ | `develop` | 実測 `git branch --show-current` |
| 最新コミット | `8d90ac4 docs: 指示書ANの決定を記録する(D-141追加)` | 実測 `git log -1` |
| 最終決定番号 | ★**D-141**★ | `docs/decisions.md:10964` |
| 最新の引き継ぎ追記 | ★**追記52**★（指示書AN＝清掃面積画面） | `docs/handoff.md:4763` |
| `main..develop` | ★**355コミット**★ | 実測 `git rev-list --count main..develop` |
| `main` の最終更新 | ★**2026-08-27**★（`1f214cc`。★3週間前★） | 実測 `git log -1 main` |
| 未コミット | ★4件★（`lib/db/prisma.ts` 変更1 ＋ 未追跡 md 3） | 実測 `git status --porcelain` |
| 次に使う指示書の記号 | ★**AO**★（AA〜AN 使用済み。※`AD` は欠番） | 実測 `ls docs/handoff/` |

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

---

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

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

| # | ユーザーの原文（要旨） | 指示書 | 決定 | 状態 |
|---|---|---|---|---|
| 1 | ★分類（ホールディングス / 各グループ＝屋号 / 店舗）の復活★ | `指示書AK_分類を復活させる.md` | ★**D-138**★（`docs/decisions.md:10593`） | ★完了★。当期KPIの積み残しは `指示書AL` → ★**D-140**★（`:10881`）で解決 |
| 2 | ★総清掃面積（期間絞り込み付き・モニタリングに新項目）★ | `指示書AN_総清掃面積の画面を作る.md` | ★**D-141**★（`:10964`） | ★完了★。画面名は「清掃面積」📐（モニタリングの4つ目） |
| 3 | ★ダッシュボードに要レスキュー店舗★ | `指示書AI_要レスキュー店舗と詳細ログの期間上限.md` / `指示書AJ_要レスキューの見せ方とサイドバーのスクロール.md` | ★**D-135**★（`:10002`）/ ★**D-137**★（`:10367`） | ★★4条件のうち「出発失敗」だけ未実装★★（下記） |
| 4 | ★詳細ログ2年分★ | `指示書AI_要レスキュー店舗と詳細ログの期間上限.md` | ★**D-136**★（`:10233`） | ★完了★。上限 **731日**、CSVは★行数★上限 **20,000行** |

### ★★#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周を回す段取り★を先に決める。

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

| # | 内容 | 出典 |
|---|---|---|
| C-1 | 同一エリア同日2回清掃の★二重計上★（`lib/clean-logs/areas.ts`）の仕様判断 | `docs/handoff.md:3760` |
| C-7 | ★本番の施設数・台数の見積もり★（社内資料に無い。D-132 が「DFA側で決める」と明記） | `docs/decisions.md:9602-9607` |

---

## 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位）。

| 章 | 要約 | 待っている番号 |
|---|---|---|
| 1（:40） | ★索引7件の依頼★（うち2件は索引ゼロ列）。`EXPLAIN` 実測つき・★最優先★ | 依頼①〜⑦ |
| 2（:222） | サマリの `task_area`/`clean_area` は期間内合計か（★実データ全行1000固定★） | Q2-1 / Q2-2 / Q2-3 |
| 3（:307） | 第8回 Q4（サマリの率・分子・分母の関係）の再掲 | 第8回Q4 |
| 4（:321） | サマリ `error_count` の集計範囲 | Q4-1 / Q4-2 / Q4-3 |
| 5（:345） | ★面積の単位は㎡か★ | Q5-1 |
| 6（:361） | `group_summaries` が無い。グループ集計／「清掃実施回数」列の追加可否 | Q6-1 / Q6-2 |
| 7（:421） | `groups`/`customers` の本番データ投入依頼＋粒度 | Q7-1〜Q7-5 |
| 8（:536） | 本番規模の見積もり | Q8-1 / Q8-2 / Q8-3 |
| 9（:565） | 軽い確認2件＋★DDL未反映2件（4回目の依頼）★ | Q9-1 / Q9-2 ＋ DDL2件 |
| 10（:595） | ★DB更新用アカウント★（第5・6・8回からの継続） | 依頼 |
| 11（:611） | ★実際の清掃開始時刻はどこにあるか★（優先度高） | Q11-1 / Q11-2 / Q11-3 |

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

| 待っているもの | ブロックされていること |
|---|---|
| ★索引依頼①②★ | ★2年検索（D-136 で上限731日に拡大済み）が重いまま★。本文が「①②が入るだけで作業が進む」と明記（`:716`） |
| ★Q11-1（実開始時刻の所在）★ | ★要レスキューの4条件目「出発失敗」が実装できない★（§1 #3） |
| ★Q5-1（面積の単位）★ | ★清掃面積画面が「㎡」と主張し続けている根拠が無い★（`lib/config/index.ts:696` の `AREA_UNIT` 1行で直せる） |
| ★Q2-1（サマリ面積の合計性）★ | ★サマリ由来の面積を使えない★ので `clean_status_histories` から集計している（`lib/clean-area/aggregate.ts:16-18`） |
| ★DB更新用アカウント★（2026-09-03 から未受領） | ★★4カラム（`status`/`comment`/`responded_at`/`resolved_at`）の UPDATE が1本も書けない★★（`docs/handoff.md:2925-2943`、`CLAUDE.md` §3） |
| ★Q7-4★ | `group_id=0` が★実FK制約★でローカルDBに投入できない（`scripts/seed-local-db.ts`） |
| ★Q6-2★ | ★複数顧客の合算ができない★ |
| ★Q11-3★ | ★出発成功率の式が未確認★（`lib/reports/target-customer.ts`） |

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

| # | 内容 | 出典 |
|---|---|---|
| C-5 | `robot_error_reports.clean_timetable_id` に索引が無い | `docs/decisions.md:9384` |
| C-8 | `control_reports` の複合索引 `(control_id, reported_at)` 依頼 | `docs/handoff.md:4168` |
| C-9 | `link_schedules.intervals` の実運用値が不明 → `control_reports` が★1,100万行か7,000万行か決まらない★ | `docs/handoff.md:4214` |
| C-10 | セキュリティヘッダは★nginx 側の「約束」のみ★（実装ではない） | `docs/decisions.md:9504` |

---

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

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

| 観点 | 事実 |
|---|---|
| 中身 | `mariadbAdapterConfig()` を新設。`DATABASE_HOST`+`DATABASE_PASSWORD` があれば部品変数から接続、無ければ `DATABASE_URL` |
| 理由（コメントに明記済み） | パスワードに `@` が含まれると `DATABASE_URL` の `%40` が dotenv 展開で壊れる（`p%40ss`→`p`）／リモートDBは既定 ~1s の connectTimeout では pool timeout になるため `connectTimeout: 30_000` |
| ★秘密情報★ | ★★含まれない★★（環境変数を読むだけ） |
| ★依存★ | ★★これが無いとテストDBに繋がらない★★。追記52 の実測検算はこのDBで行われ、★すでに5コミットが依存★ |
| ★回避の履歴★ | ★★追記48〜52 の5作業が4日間連続で「着手前から未コミットの変更が乗っているので触っていない」と記録★★（`docs/handoff.md:4463-4464`〈追記48〉/ `:4615-4616`〈49〉/ `:4682-4683`〈50〉/ `:4758`〈51〉/ `:4823`〈52〉） |

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

### 未追跡 md 3件

| ファイル | 行数 | 中身 | 判断材料 |
|---|---|---|---|
| `docs/UI差分まとめ_20260915.md` | 263 | モックと実装の画面差分。画面数は10対10で一致。差分68件を4分類。第3章＝★要確認8件★、第4章＝★記録が残っていない差分26件★ | ★この文書にしか存在しない情報★。★コミット推奨★。同時に「★第3・4章を `docs/decisions.md` に落とす★」タスクが発生する |
| `docs/変更点まとめ_20260914.md` | 409 | 非エンジニア向けまとめ（D-001〜D-134） | ★D-135〜D-141 が未反映★。★「2026-09-14 時点のスナップショット」と明記する★か、★追補する★かの判断が要る |
| `docs/handoff/管理画面_設計検討_20260910.md` | 499 | F-10 システム管理の設計検討メモ（★未実装★）。★P1スコープ外のユーザー管理・監査ログを繰り上げる提案★を含む | 2026-09-10 から★6日間未追跡★。追記42・48〜52 が「★他作業の未コミット変更★」として回避し続けている。★★この「他作業」が誰かを確認しないと宙に浮く★★ |

---

## 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）

| 対象 | 何が見えていないか | 由来 |
|---|---|---|
| ★分類セレクトのカスケード★ | ホールディングス→屋号→店舗の連動操作 | 追記51 §2-3（`:4717`） |
| ★レポート画面の422時の挙動★ | ★1ブロックが422でも残り3ブロックが出ること★ | 追記51 §3（`:4734`） |
| ★清掃面積画面★ | 粒度タブの操作 / ダーク・ライト切替 / 「もっと表示」の展開 | 追記52（D-141） |

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

---

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

| # | 地雷 | 出典 |
|---|---|---|
| 1 | ★★`facility_ids` の `null`（条件なし＝全件）と `[]`（0件）は別物★★。`?.length` で分岐すると `in: undefined` になり、生成SQLが `WHERE 1=1` に化けて★★全件が静かに返る★★（エラーも出ず、テストも通ったまま、結果だけ間違う）。★型を `number[] | null` にし `!== null` で分岐する★ | `docs/decisions.md:8891-8903`（D-129 §5）/ `:9421` / `:9958` |
| 2 | ★★`facilities.contract` は `varchar(10)` の**桁位置**★★（1桁目=D-Security / 2桁目=D-Watch）。★数値として比較すると `Number("0000000000")` が例外を出さずに `0` になり、★★全施設が「契約なし」になってメニューが全部消えるが、例外もテスト失敗も出ない★★★ | `CLAUDE.md` §4.6（D-080） |
| 3 | ★★表示用に丸めた値で判定しない★★。判定は★生値★、丸めは★表示層だけ★（90.4 は表示90%でも判定は◎） | `CLAUDE.md` §4.3 / §9.3 |
| 4 | ★★閾値のハードコード禁止★★。90/70/10・猶予30分・L2=2日/L3=3日 はすべて `lib/config/` から読む | `CLAUDE.md` §7 / `docs/decisions.md:8973` |
| 5 | ★★生SQL禁止★★（`$queryRaw` / `$executeRaw` / `*Unsafe`）。★ESLint が `no-restricted-syntax` で落とす★。対象は `app/**` `lib/**` `components/**` `scripts/**` `proxy.ts` | `eslint.config.mjs:41-60` / `docs/decisions.md:8110`（D-122） |
| 6 | ★★テストDB `133.125.238.144` は読み取りのみ★★。参照用アカウントは全テーブル SELECT のみ。★書き込み禁止★ | `docs/handoff.md:4801` / `docs/decisions.md:11061` / `CLAUDE.md` §3 |
| 7 | ★★DATETIME は JST の壁時計値★★。素で読むと★画面の時刻が9時間進む★。必ず `fromDbJst()`（`lib/format/date.ts:67`）/ `jstIsoFromDb()`（`:95`）を通す | `docs/decisions.md:7167`（D-115） |
| 8 | ★★エラー種別を7分類に変換しない★★。`robot_error_reports.error_type` も `robots.status` も★DBの生値をそのまま表示★。帰結として画面に `EmergencyStop` 等の英語識別子が出るが★それが意図した挙動★。★`lib/theme-status.ts` の色分けは日本語6文字列の完全一致なので、生値では全部グレーに落ちる★ | `CLAUDE.md` §4.8（D-077） |
| 9 | ★★週の帰属を知っているのは `lib/format/period.ts` の `weekOfMonth()`（`:126`）★だけ★★。他所に帰属ロジックを書かない。月跨ぎ週は★月境界で分割★し、★週の長さは1〜7日で変わる／月の週番号は1〜6★ | `CLAUDE.md` §4.7 / `docs/decisions.md:770`（D-071） |
| 10 | ★★`lib/config/allowed-ips.ts:35` の `ALLOW_ALL_WHEN_EMPTY` が `true` のまま★★。★本番前に `false` にしないと誰でも通る★。IP制限は★`X-Forwarded-For` の**末尾**★を見る（★先頭は詐称可能★） | `lib/config/allowed-ips.ts:35` / `CLAUDE.md` §3（D-077 項5） |
| 11 | ★★4カラム以外へのDB書き込み禁止★★（`robot_error_reports` / `control_error_histories` の `status` / `comment` / `responded_at` / `resolved_at` のみ）。他は権限エラーになる | `CLAUDE.md` §3 / §7 |
| 12 | ★★`customers.contract` を参照しない★★（削除依頼済み）。★`facilities.contract` が正★ | `CLAUDE.md` §4.6 / §7 |
| 13 | ★施設200件超で `facility_id: { in: [...] }` の実行計画が静かに劣化★（`eq_range_index_dive_limit=200`）。★未対策★ | `docs/decisions.md:9395` / `:9610-9611` |
| 14 | ★`components/` に置いたテストは走らない★ — `vitest.config.ts` の `include` は `lib/**` と `app/**` のみ。判定は★純粋関数にして `lib/` に置く★ | `lib/clean-area/aggregate.ts:14` / `CLAUDE.md` §9.4 |

> ★補足（本リポジトリの文書には規定がなく、セッション環境側の作法）★:
> 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）★★

| 判定 | 条件 | 境界の扱い |
|---|---|---|
| ◎ | 完了率 ★90%以上★ | ★90.0 は ◎★ |
| ○ | 完了率 ★70%以上★ | ★70.0 は ○★ |
| △ | 完了率 ★10%以上 70%未満★ | ★★10.0 は △★★ |
| × | 完了率 ★10%未満★、または★未実施★ | ★× の境界だけは「未満」のまま★ |

出典: `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` で実測して照合済み★

| 定数 | 値 | 行 | 備考 |
|---|---|---|---|
| `GRADE_THRESHOLDS.excellent` | `90` | `:20` | ★以上★で ◎ |
| `GRADE_THRESHOLDS.good` | `70` | `:22` | ★以上★で ○ |
| `GRADE_THRESHOLDS.poor` | `10` | `:24` | ★下回る★と ×（10.0 は △） |
| `ESCALATION_THRESHOLDS.level2Days` | `2` | `:29` | 2日連続で L2 |
| `ESCALATION_THRESHOLDS.level3Days` | `3` | `:31` | 3日以上連続で L3。★要レスキューに流用しない★ |
| `COMPLETION_DROP.dropRatio` | `0.2` | `:50` | 前回比20%以上の下落で「急落」 |
| `RESCUE_INITIAL_VISIBLE` | `5` | `:102` | ★画面の初期表示件数★。★APIでは切らない★（D-137） |
| `MAX_DATE_RANGE_DAYS` | `731` | `:359` | 詳細ログの期間上限＝2年（D-136） |
| `MAX_CSV_ROWS` | `20_000` | `:384` | ★外挿の暫定値★。実データ＋索引が入ったら測り直す（D-136 §8） |
| `AREA_UNIT` | `"㎡"` | `:696` | ★TeamWorks 未確認（第9回 Q5-1）★。★画面やAPIに "㎡" を直書きしないこと★ |

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

### 用語（`CLAUDE.md` §8）

| 用語 | 意味 |
|---|---|
| 清掃エリア（sections） | 施設内の清掃対象区域。旧称「区画」。★「清掃エリア」に統一★ |
| 施設（facilities） | ロボットが配置される店舗・拠点。旧称「店舗」 |
| D-Sデバイス / D-S制御盤 | セキュリティ会社システムと制御サーバ間を中継する物理デバイス |
| 事前チェック | 清掃開始の60分前/30分前にロボット状態を確認する仕組み |
| Pudu Cloud | PUDU Robotics のクラウドAPI |

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

---

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

| 知りたいこと | どこを見るか |
|---|---|
| 全履歴・日ごとの経緯 | `docs/handoff.md`（4824行 / 追記52まで） |
| 決定とその理由 | `docs/decisions.md`（11079行 / D-141まで） |
| 仕様の正・禁止事項 | `CLAUDE.md` |
| API契約の正 | `d-watch-api.yaml` |
| 画面レイアウト・文言・遷移の正 | `d-watch-mock.jsx` |
| 機能一覧と開発フェーズ | `docs/spec.md` |
| サンプルデータの正 | `docs/fixtures.md` |
| デプロイ・nginx 側の申し送り | `docs/deploy.md` |
| 外部確認事項（最新） | `docs/handoff/TeamWorks確認事項_第9回_20260915.md` |
| PR を出すときの骨子 | `docs/handoff/PR説明_develop_to_main_骨子.md`（★要更新★） |