# PR #6 を分けてレビューする手順（レビュー: daichi）

作成: 2026-10-01。PR: https://github.com/DFARobotics/d-watch/pull/6 。決定: D-154。
数字の出所: `git diff --numstat origin/main origin/develop`（main=1f214cc / develop=a7b4614）。構造由来。

★コードは Claude Code / Cursor が書き、★daichi がレビューして main にマージする★（2026-10-01 ユーザー指示「コードレビューは自分がします」）。

---

## 0. 先に片づけること

| # | 内容 | 状態 |
|---|---|---|
| 0-1 | ステージングDBの実パスワード（URLエンコード形）がコメントの例に入っていた5箇所を、ダミー `p%40ss` に差し替える（`.env.example:12` / `lib/db/prisma.ts:30` / `docs/code-map.md:2006,2522` / `docs/handoff/セッション引き継ぎ_20260916.md:212`） | ★済（D-154）★ |
| 0-2 | ★履歴には残る★（2026-09-16〜10-01 の4コミット: 992a456 / d792067 / 2bf83cd / d23e203）。★TeamWorks にパスワードの変更を頼むか★ | ★daichi 判断待ち★。履歴の書き換え（force push）は下の区切りのコミット番号が全部変わるので勧めない |
| 0-3 | （任意）`.github/workflows/ci.yml` の `prisma generate` 追加（15行）だけを先に main へ入れる | 未。入れないと Part 3・4 の CI のビルドが赤になる（09-09〜09-17 の CI に生成の手順が無かったため。Part 5 の ebb0872 で直った） |

---

## 1. 分け方（積み上げ PR・7本）

★develop は一直線の履歴（マージコミット0件）なので、途中のコミットに枝を立てるだけで切れる★。

| Part | 枝の先端 | 期間 | 件数 | 本番コード / テスト（追加行） | docs（追加行） | 中身 | 向き先 |
|---|---|---|---|---|---|---|---|
| 1 | `9cd4b08` | 08-30〜09-03 | 29 | 6.8k / 2.3k | 18.8k | 開発用サンプルデータ上の画面（ダッシュボード・事前チェック・D-Secログ/アラート）、schema の db pull（D-047〜D-065） | main |
| 2 | `b2ec6ee` | 09-03〜09-08 | 73 | 5.2k / 3.1k | 12.1k | レポート、月跨ぎ週（TeamWorks方式）、JSON設定ストア、マスタ3画面（D-066〜D-084） | Part 1 |
| 3 | `327682e` | 09-08〜09-11 | 76 | 5.0k / 2.9k | 12.7k | ★実DBへの配線★、ローカルDBのシード、★認証（cookie）と IP 制限★、エラー種別の生値表示（D-085〜D-108） | Part 2 |
| 4a | `7db4a57` | 09-11 | 55 | 4b と計 7.4k / 10.5k | 4b と計 23.1k | 連続日数、事前チェックの読み方、DATETIME の扱い、エリア別完了率、ページ送り | Part 3 |
| 4b | `af11453` | 09-13〜09-15 | 59 | （同上） | （同上） | ★生SQL禁止の lint、CSV インジェクション対策★、検索の正規化、SQL への絞り込み（D-109〜D-134） | Part 4a |
| 5 | `7fdd822` | 09-15〜09-17 | 109 | 7.3k / 6.3k | 25.5k | 要レスキュー、分類の絞り込み、判定境界を「以上」に、総清掃面積、CI 修正（D-135〜D-150） | Part 4b |
| 6 | develop 先端 | 09-30〜10-01 | 22＋α | 2.0k / 2.9k | 5.9k | ★データ取得元の切替★（サマリ3粒度・`clean_task_reports` 一本化・完了率=`clean_ratio` 単純平均）、言語切替のずれ修正、0-1（D-151〜D-154） | Part 5 |

- どの切れ目も「直後に修正コミットが続く箇所」を避けている（直後から新しいテーマが始まる）
- ★各切れ目でビルド・テストが通るかは未確認★。PR を作れば CI が確かめる（`ci.yml` の `pull_request:` に枝の絞り込みが無いので、main 以外に向いた PR でも走る）
- 追加 +158k 行の内訳: ★docs 61%★ / テスト 17% / ★本番コード 19%（約3万行）★ / 生成物・データ 3%

### マージの手順

1. Part 1 から順に1本ずつレビュー → マージ
2. ★マージ方法は「Create a merge commit」★。★Squash / Rebase を使うと次の Part の差分がずれる★
3. マージ後に枝を削除すると、GitHub が次の Part の向き先を自動で main に付け替える
4. 全部入ったら PR #6 を閉じる
5. ★GitHub では PR の作成者（DFA-takeuchi）が自分の PR を「Approve」できない★。レビュー結果は PR へのコメントで残し、そのままマージする
   （main にブランチ保護が入っているかは未確認。管理者権限が要る。保護で承認必須になっていたらマージできないので、そのときは DGJAPAN さんに設定を見てもらう）

---

## 2. 何を読むか

### 読む（約3万行のうち、特にここ）

| # | 観点 | 場所 | 見るところ |
|---|---|---|---|
| 1 | 認証・IP制限（Part 3） | `proxy.ts` / `lib/proxy/authenticate.ts:59-94` / `lib/auth/client-ip.ts:36-78` / `lib/auth/token.ts:22-41` / `lib/auth/cookie.ts:29-32` | XFF は末尾側（`parts[length - hops]`）を見ているか。★cookie の値は共有トークンそのもの・ログイン試行回数の制限なし★ — 社内利用でこれでよいか |
| 2 | ★IP制限の既定値★ | `lib/config/allowed-ips.ts:24-35` / `docs/deploy.md:117-121` | ★許可IPが空だと全部通す（`ALLOW_ALL_WHEN_EMPTY = true`）★。本番に出す前に許可リストを入れるか、既定を拒否に倒すか |
| 3 | DB書き込み | `app/` `lib/` | ★Prisma の update/create/delete と生SQLは1件も無い★（読み取りのみ）。生SQLは `eslint.config.mjs` で禁止。書き込む PATCH 3本はローカルの JSON（`lib/settings/json-store.ts:86-127`） |
| 4 | ステージングを消さない仕組み | `scripts/seed-local-db.ts:85-91,844-856` / `lib/db/local-guard.ts:10-31` | localhost の `dwatch_local` 以外を拒否するか |
| 5 | 判定ロジック | `lib/judge/grade.ts:29-35` / `kpi.ts` / `rescue.ts` / `escalation.ts` / `lib/config/index.ts` | 境界（90.0◎ / 70.0○ / 10.0△ / 9.9×）、丸める前の値で判定、閾値は設定から読む |
| 6 | 時刻 | `lib/format/date.ts` / `lib/db/date-range.ts:55-64` | DBの値に9時間を足していないか（CLAUDE.md §3） |
| 7 | 契約フラグ | `lib/format/contract.ts:26-41` | 文字で比べ、数値にしていないか（§4.6） |
| 8 | 環境変数の既定値 | `lib/db/use-fixtures.ts:17` / `.env.production.example` / `scripts/check-env.ts` | ★`USE_FIXTURES` は未設定だとサンプルデータで動く★。本番では `false` を明示 |
| 9 | ログ | `instrumentation.ts:39-80` / `lib/logger/redact.ts` | 接続文字列やトークンがログに出ないか |
| 10 | データ層の本体（Part 6 で作り直し） | `lib/db/index.ts` / `report-mapping.ts` / `clean-log-mapping.ts` / `consecutive-source.ts` / `clean-area-source.ts` | 量も仕様上の危険も最も多い。★Part 3〜5 の版は流し読みにし、Part 6 で読む★ |
| 11 | ルールの変更 | `CLAUDE.md` の差分（+274行） | ルールそのもの |

### 流し読みでよい

- `docs/handoff/` の全部（指示書・TeamWorks 照会・PDF 生成スクリプト）、`docs/decisions.md`、`docs/code-map.md`
- `lib/fixtures/` とそのテスト、`package-lock.json`
- `prisma/schema.prisma`（db pull の生成物。手で書いた行が無いかだけ）、`d-watch-api.yaml`（型との整合だけ）

### 後で置き換わるコード（その Part では流し読みでよい）

| 書かれた Part | 置き換えた Part | 何が |
|---|---|---|
| 1 | 1 | `prisma/schema.prisma` の手書き（`fac1a54`）→ db pull（`d20be80`） |
| 1 | 3 | エラー種別の enum と型（`67e7014` で撤去。D-077/088） |
| 1 | 5 | `lib/judge/grade.ts` の境界（`eb1cebc`。D-139） |
| 2 | 2 | 期間ヘルパー（`234987e` → 同日の `8a00ed0`。D-071） |
| 3 | 4a | 事前チェックの読み方（D-113） |
| 3〜5 | 6 | `lib/db/` のマッピング5ファイルと `lib/judge/kpi.ts` / `rescue.ts`。面積比の完了率と `clean_error` 判定は廃止 |

---

## 3. この後の作業

★**時期: 第10回の回答後に、指示書AR と4カラム UPDATE の実装が終わってから**★（ユーザー判断 2026-10-01。それまでに develop に積んだ分も Part 6 以降に含める）。その時点で区切りを数え直す。
0-3 の CI 修正の先行 PR も同じ時期に行う。

1. 0-1 をコミットして develop に push（D-154）
2. Part 1〜6 の枝（`review/part-1` 〜 `review/part-6`）を立てて push し、PR を7本作る。各 PR の説明に、中身・読むところ・置き換わる箇所を書く
3. PR #6 に7本へのリンクをコメントする