# 点検記録（F-05 / `inspections`）— 決まっていること / 決まっていないこと

**作成日**: 2026-09-17 / **ブランチ**: `develop` / **種別**: 調査。★指示書ではない★

---

## 0. この文書の位置づけ

ユーザーの言:「★点検記録はまだ色々決まってないので、指示書は作れない★」。
であれば ★何が決まれば指示書を書けるのか★ を先に確定させる、というのが本書の目的です。

**書き方の約束**

- ★すべての「決まっている」に `file:line` の実測根拠を付けた★。根拠を書けないものは
  「決まっていない」側に置いた（`CLAUDE.md` §6-6 / §7「推測で埋めない」）。
- ★「たぶんこうだろう」で埋めていない★。資料に無いものは「記述なし（実測）」と書いた。
- 本書の作成でコードは1行も触っていない。★新規作成したのは本ファイルのみ★。
- ★本番DB（`133.125.238.144`）には接続していない★（D-148）。

**件数（本書の結論）**

| 区分 | 件数 |
|---|---|
| ★決まっていること★ | ★34件★（決定5 / API契約16 / 画面7 / 既存コード6） |
| ★決まっていないこと★ | ★35件★ |
| うち ★着手をブロックするもの★ | ★5件★ |
| うち ★暫定で進められるもの★ | ★30件★ |
| ★API契約とモックの食い違い★ | ★8件★（うち1件は既に解消） |

---

## 1. 材料の所在（実測）

| 材料 | 場所 | 中身 |
|---|---|---|
| API契約 | `d-watch-api.yaml:1289-1401`（パス）/ `:2221-2256`（スキーマ）/ `:59-60`（タグ）/ `:20-22`（データソース注記） | 4本のエンドポイントとスキーマ2種 |
| 画面モック | `d-watch-mock.jsx:80`（点検7項目）/ `:81-89`（データ7件）/ `:1071-1145`（一覧画面）/ `:1976-2025`（詳細モーダル）/ `:2027-2085`（新規登録モーダル） | 画面の姿 |
| 機能一覧 | `docs/spec.md:16` / `:75-81`（F-05）/ `:128`（並走可）/ `:215-221`（M6） | 作るものと順序 |
| 決定 | `docs/decisions.md:38-41`（D-004）/ `:197-199`（D-031）/ `:1059-1066`（D-072 項7）/ `:2182`（D-079 項3）/ `:2642-2657`（D-083 項6）/ `:6666-6673`（D-111 項6）/ `:11359-11380`（D-143 項1） | なぜ今の状態か |
| fixtures | `lib/fixtures/inspections.ts`（全157行）/ `docs/fixtures.md:233-243`（§9） | 用意済みのサンプル6件 |
| 型 | `lib/types/index.ts:979-1009` | `InspectionItemName` / `InspectionPhoto` / `InspectionListItem` / `InspectionDetail` |
| 現在の実装 | `app/(dashboard)/inspections/page.tsx`（全5行、`PlaceholderScreen`）/ `components/layout/AppShell.tsx:17-22`（メニューのコメントアウト） | 画面は空 |
| データ層 | `lib/db/index.ts:310-311`（宣言）/ `:521-525`（fixtures 実装）/ `:1704-1708`（prisma は `notImplemented`） | 2メソッドだけ |
| ログ | `lib/logger/events.ts:225-232`（`InspectionLogEvent`） | 名前空間は確保済み |

★**要件定義書 P1 / UI仕様書 v6.0 には点検記録の記述が無い**★ — D-031（`docs/decisions.md:198`）が
「モックに存在していたが★要件定義書・画面要件整理シートに記載がなかった★」と明記している。
つまり ★この機能の一次資料はモックと `d-watch-api.yaml` の2つだけ★で、他画面のように
「UI仕様書に戻って裏を取る」ことができない。★これが本件の不確定性の根本原因★。

---

## 2. 決まっていること（34件）

### 2.1 決定として確定しているもの（5件）

| # | 決まっていること | 根拠 |
|---|---|---|
| D1 | ★点検記録はメインDBに保存しない★。DFA独自ストア（SQLite + オブジェクトストレージ）で管理する | `docs/decisions.md:38-40`（D-004）/ `CLAUDE.md` §3・§7 |
| D2 | ★P1スコープに含む★（モック由来で正式にスコープ入り）。★TeamWorks への確認・依頼は不要★ | `docs/decisions.md:197-199`（D-031） |
| D3 | ★実装順は最後★。他の実装が全部終わってから | `docs/decisions.md:1059-1066`（D-072 項7）/ `:6666-6673`（D-111 項6） |
| D4 | ★メニューからは一時的に隠す。ルート（`page.tsx`）と `lib/i18n.ts` のエントリは残す★。復活はコメント1行を外すだけ | `docs/decisions.md:2642-2651`（D-083 項6）/ `components/layout/AppShell.tsx:17-22` |
| D5 | ★モックの実在人名・店舗名・申し送り本文は1文字もコピーしない★ | `docs/decisions.md:2596-2601` / `CLAUDE.md` §7 |

### 2.2 API契約から読み取れること（16件）

★`d-watch-api.yaml` は「API契約の正」（`CLAUDE.md` §5）なので、以下は確定として扱ってよい★。

| # | 決まっていること | 根拠 |
|---|---|---|
| A1 | ★エンドポイントは4本★: `GET /inspections` / `POST /inspections` / `GET /inspections/{id}` / `DELETE /inspections/{id}` | `d-watch-api.yaml:1290` / `:1340` / `:1380` / `:1393` |
| A2 | 一覧のクエリは ★`date_from` `date_to` `customer_id` `facility_name` `q` `page` `per_page` の7つ★ | `:1297-1321` |
| A3 | `date_from` / `date_to` は ★訪問日（`visited_on`）の範囲★ | `:1300` |
| A4 | `facility_name` は施設名の部分一致。★実装時は `includesFoldName` を通す（記号・大文字小文字を無視）★ | `:1308-1313` |
| A5 | `q` は ★記入者名 or シリアル番号★の部分一致。★`includesFoldPlain`（大文字小文字だけ無視）★ | `:1317-1319` |
| A6 | 一覧のレスポンスは ★`summary` + `items` + `meta`★。`summary` は ★`total`（記録数）/ `facilities`（施設ユニーク数）/ `with_notes`（申し送りあり件数）の3値★ | `:1330-1339` |
| A7 | `InspectionListItem` は ★8フィールド★（`id` `visited_on` `inspector_name` `inspector_company` `customer_name` `facility_name` `serial_number` `has_notes`） | `:2221-2232` |
| A8 | ★「ブランド」列は `customer_name`。facility → customer 経由で導出する★ | `:2223` / `:2229` |
| A9 | `InspectionDetail` = `InspectionListItem` + ★`notes`（nullable）+ `photos[]`★ | `:2234-2256` |
| A10 | 写真1件は ★`item_type` / `phase` / `url` の3フィールド★。`item_type` は ★英語 enum 7値★（`brush` `dust_box` `filter` `squeegee` `suction_hose` `waste_tank` `brush_back`）、`phase` は ★`before` / `after`★ | `:2246-2252` |
| A11 | ★未撮影の組み合わせは `photos` 配列に含めない★（空要素を返さない） | `:2242` |
| A12 | 詳細の写真URLは ★署名付き一時URL（有効期限あり）★ | `:1387` / `:2256` |
| A13 | 登録は ★`multipart/form-data`★。写真のフィールド名は ★`photos[{item_type}][{phase}]`★ | `:1344-1346` / `:1351` / `:1365-1370` |
| A14 | ★必須5項目★: `visited_on` `facility_id` `robot_id` `inspector_name` `inspector_company`。★`notes` と写真は任意★ | `:1354` |
| A15 | ★上限値★: 写真 ★1枚10MB / jpeg・png / 最大14枚★、`inspector_name` ★100★、`inspector_company` ★100★、`notes` ★2000★ | `:1347` / `:1362-1364` |
| A16 | ★削除は論理削除（誤登録対応）で 204★。`{id}` の検証は ★`PathId`（1以上の整数、0・負値・非整数は422）★ | `:1393-1401` / `:1444-1448`（`PathId`） |

補足（契約として確定している周辺事項）:

- ★ロボットは「施設選択後に `GET /facilities` の `robots` から選ばせる」★（`:1361`）。
  ★モックの空セレクトを契約側が補っている★。
- ★認証は cookie 方式（`dwatch_session`）がグローバルに適用される★（`:35-36` の `security`）。
  ★IP制限も `proxy.ts` が全ルートで判定する★（`proxy.ts:112-114` の matcher は
  静的ファイル以外すべてを通す）。★点検記録だけを除外する記述は無い（実測）★。

### 2.3 モックから読み取れる画面の姿（7件）

| # | 決まっていること | 根拠 |
|---|---|---|
| U1 | 一覧画面は ★見出し + サマリカード3枚 + フィルタ + 8列の表★ | `d-watch-mock.jsx:1071-1145` |
| U2 | サマリカードは ★総点検数（期間内）/ 点検施設数（ユニーク）/ 申し送りあり（要確認）★ | `:1097-1110` |
| U3 | フィルタは ★日付範囲（from〜to）/ グループ選択 / 会社選択 / フリーテキスト（プレースホルダ「施設名 / 記入者」）★の4つ | `:1083-1096` |
| U4 | 表の列は ★訪問日 / 記入者 / 所属会社 / 店舗名 / ブランド / シリアル / 申し送り / 操作★ の8列。申し送りは ★「あり」/「ー」★の2値表示 | `:1114-1122` / `:1134` |
| U5 | 詳細はモーダル。★上段に記入者・所属会社・ブランド・シリアル、その下に Before / After の2列★、各列に ★7項目★が縦に並ぶ。★申し送りは本文があるときだけ表示★ | `:1976-2025` |
| U6 | 新規登録もモーダル。★入力欄は 訪問日* / 店舗* / 記入者氏名* / 所属会社* / ロボット* の5つ＋Before/After×7項目の写真アップロード＋申し送り事項★ | `:2027-2085` |
| U7 | 点検7項目の ★日本語名と並び順★: ブラシ / ダストボックス / フィルター / スクイジー / 吸引ホース / 汚水タンク / ブラシ裏面 | `d-watch-mock.jsx:80` / `docs/spec.md:77` / `d-watch-api.yaml:2249` |

### 2.4 既存コードとして用意済みのもの（6件）

| # | 決まっていること | 根拠 |
|---|---|---|
| C1 | ★TS型は定義済み★（`InspectionItemName` / `InspectionPhoto` / `InspectionListItem` / `InspectionDetail`） | `lib/types/index.ts:979-1009` |
| C2 | ★fixtures は用意済み★（6件。写真全14枚 / 一部欠け / なし、申し送り長文 / 空、同一施設の複数回） | `lib/fixtures/inspections.ts:24-157` / `docs/fixtures.md:233-243` |
| C3 | `DataSource` に ★`inspections()` と `inspectionDetail(id)` が宣言済み★ | `lib/db/index.ts:310-311` |
| C4 | ★`fixturesSource` 側は実装済み★（`:521-525`）、★`prismaSource` 側は `notImplemented()`★（`:1704-1708`） | 同上 |
| C5 | ★ログイベントの名前空間は確保済み★（`inspection.read` / `inspection.write` / `inspection.photo`。★メインDB系 `db.*` と分ける★） | `lib/logger/events.ts:225-232` |
| C6 | ★実装するときは最初から `Pagination` を入れる★（一覧にページ送りを後付けしない） | `docs/decisions.md:7910` / `:7998`（D-120 の申し送り） |

---

## 3. ★決まっていないこと（35件）★ — 本題

観点ごとに「決まっているか / いないか」を1つずつ判定した。
★「資料に記述なし」は grep の実測結果であり、見落としではなく不存在として扱っている★。

### 3.1 データの保存先（6件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N1★ | ★SQLite を本当に使うのか★（採否そのもの） | ★未決★ | D-004（`docs/decisions.md:39`）は「SQLite + オブジェクトストレージ」と書くが、★`package.json` に SQLite ドライバの依存が1つも無い★（`better-sqlite3` / `sqlite3` / `libsql` いずれも0件。実測）。Prisma 7 で2つ目のクライアントを立てるのか、`better-sqlite3` を直に使うのか、★どちらの記述も無い★ |
| ★N2★ | ★SQLite ファイルの置き場所★ | ★未決★ | 記述なし（実測）。★既存の独自ストアは `data/settings/*.json`★（`lib/settings/json-store.ts:8-10`）で、★`/data` は `.gitignore:50` に入っている＝ git のバックアップが無い★。同じ場所に置くのかも未決 |
| ★N3★ | ★オブジェクトストレージの実体★（さくらのオブジェクトストレージ / 他の S3互換 / VM のローカルディスク） | ★未決★ | ★grep で「オブジェクトストレージ」は12箇所ヒットするが、すべて「SQLite + オブジェクトストレージ」という同じ1文の引用★。★具体のサービス名は1箇所も無い（実測）★ |
| ★N4★ | ★バケットの用意・費用・アカウント発行を誰がやるか★ | ★未決★ | D-143（`docs/decisions.md:11366-11373`）は「★サーバー・ネットワークの用意と構築保守はすべて TeamWorks★」と確定したが、★対象として挙がっているのは「本番のアプリVM / DB / テスト環境」の3つだけ★。★オブジェクトストレージは名指しされていない★。→ §5 の「実は決まっているかもしれないもの」も参照 |
| ★N5★ | ★バックアップと復旧★（写真とSQLiteの両方） | ★未決★ | 記述なし（実測）。★VM の保守は TeamWorks（D-143）だが、DFA独自ストアがバックアップ対象に入るかは書かれていない★ |
| ★N6★ | ★`USE_FIXTURES` の切替をこのストアにも適用するか★ | ★未決★ | `CLAUDE.md` §9.5 は「APIルートは `USE_FIXTURES` で fixtures / Prisma を切り替える」と定めるが、★点検記録は Prisma を使わない★。`prismaSource.inspections()` が `notImplemented()` のまま（`lib/db/index.ts:1704-1708`）である現状をどう解消するかが未決 — ★「独自ストアを第3の実装として `DataSource` に足す」のか「`lib/db` の外に別系統を作る」のか★。`docs/handoff/analysis/prismaSource実装前チェックリスト.md:415` も ★「そもそも `prismaSource` で実装すべきものか要確認」★と書いている |

### 3.2 写真（9件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N7★ | 枚数の上限 | ★決まっている★ | ★最大14枚（Before/After × 7項目）★（`d-watch-api.yaml:1347`） |
| ★N8★ | 1枚あたりのサイズ上限 | ★決まっている★ | ★10MB★（同上） |
| ★N9★ | 形式 | ★決まっている（ただし §3.2 の N10 参照）★ | ★jpeg / png★（同上） |
| ★N10★ | ★HEIC（iPhone の既定形式）をどうするか★ | ★未決★ | 記述なし（実測）。★現場がスマホで撮るなら必ず当たる★。「弾く」「サーバで変換する」「端末側の設定に任せる」のどれも書かれていない |
| ★N11★ | ★1リクエストの合計サイズ★（10MB × 14 = ★最大140MB★を1回の POST で受ける） | ★未決★ | 記述なし（実測）。Next.js の Route Handler の body サイズ制限、nginx の `client_max_body_size` のどちらにも触れた記述が無い。★「1枚ずつ送る」設計に変えるかどうかも未決★ |
| ★N12★ | ★縮小・サムネイル生成をするか★ | ★未決★ | 記述なし（実測）。★一覧・詳細グリッドで14枚をフル解像度で出すと重い★が、方針の記録が無い |
| ★N13★ | ★元画像を保持するか / EXIF（位置情報）を落とすか★ | ★未決★ | 記述なし（実測）。★`lib/logger/redact.ts` は個人情報13キーを弾く仕組みを持つが、画像のメタデータは対象外★ |
| ★N14★ | ★Before / After の対応づけ — 片方だけの登録を許すか★ | ★実質未決★ | 契約は「★未撮影の組み合わせは配列に含めない★」（`:2242`）としか書いておらず、★「Before だけ登録して保存してよいか」は書かれていない★。fixtures は片方だけのケースを作ってある（`lib/fixtures/inspections.ts:47-56`）ので ★許す前提に見えるが、明記は無い★ |
| ★N15★ | ★署名付きURLの有効期限★ | ★未決★ | 契約は「有効期限あり」としか書いていない（`:1387` / `:2256`）。★分か時間か日かが無い★。★誰が署名するか（ストレージ側の機能か、アプリが自前で発行して自分で配信するか）も未決★ — 後者なら `proxy.ts` の IP制限が写真URLにも掛かる（`proxy.ts:112-114`） |

### 3.3 点検項目（5件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N16★ | 項目は何か（7項目の名前と順序） | ★決まっている★ | `d-watch-mock.jsx:80` / `d-watch-api.yaml:2248-2249` / `docs/spec.md:77` の3つが一致 |
| ★N17★ | ★固定かマスタ化か★ | ★未決★ | 契約は ★enum（固定）★（`:2248`）。しかし ★P1 の対応機種は PUDU CC1 のみ★（`CLAUDE.md` §1）で、★MT1 / Keenon C30・C40 が入ると部位が変わる★（`lib/config/index.ts` の `ROBOT_MODELS`。D-087）。★機種が増えたときどうするかの記録が無い★ |
| ★N18★ | ★チェック式か自由記述か — 「点検結果」を記録する欄が無い★ | ★未決★ | ★契約にもモックにも、項目ごとの OK/NG・数値・コメントの欄が1つも無い（実測）★。★記録できるのは「写真」と「記録全体に1つの申し送り」だけ★。「点検記録」という名前に対して ★点検の合否がどこにも残らない★ |
| ★N19★ | ★写真が無い項目の意味★（「未実施」か「異常なし」か） | ★未決★ | 記述なし（実測）。★N18 が決まらないと決められない★ |
| ★N20★ | ★消耗品の交換記録を残すか★（ブラシ交換等） | ★未決★ | 記述なし（実測）。`CLAUDE.md` §4.5 の L2 が「★消耗品交換★」を想定対応に挙げているが、★点検記録との接続は書かれていない★ |

### 3.4 運用（5件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N21★ | ★誰が入力するか★（現場スタッフ / DFA の訪問担当 / DFA運用担当が代理入力） | ★未決★ | 記述なし（実測）。★モックの記入者は全件同一人物（`d-watch-mock.jsx:82-88`）で、所属会社の既定値が `DFA Robotics`（`:2050`）★なので ★DFA の訪問者を想定しているように見えるが、明記は無い★。`CLAUDE.md` §1 の P1 利用者は「★DFA社内のみ★」 |
| ★N22★ | ★入力端末★（PC / スマホ / タブレット） | ★未決★ | 記述なし（実測）。★モックはモーダル幅 640px の PC 前提★（`:1979`）だが、★写真はスマホで撮る★のが自然。★スマホ対応の記述はリポジトリ全体で点検記録には1件も無い★ |
| ★N23★ | ★社外から入力するか★ | ★未決。ただし決めないと詰む★ | ★IP制限が全ルートに掛かる★（`proxy.ts:112-114` / `lib/config/allowed-ips.ts:24-26`）。★`ALLOWED_IPS` は完全一致のみで CIDR 非対応★（`lib/config/allowed-ips.ts:14-16`）。→ ★現場のモバイル回線から入力させる運用は、いまの認証設計では成立しない★ |
| ★N24★ | ★オフライン入力が要るか★ | ★未決★ | 記述なし（実測）。★店舗のバックヤードは電波が弱い★という想定の有無自体が書かれていない |
| ★N25★ | ★いつ入力するか★（訪問中 / 帰社後） | ★未決★ | 記述なし（実測）。N24 と連動 |

### 3.5 保持・削除（3件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N26★ | ★保持期間（何年）★ | ★未決★ | 記述なし（実測）。★メインDB側は「保持2年」という前提がある★（`lib/db/index.ts:176`）が、★点検記録に適用するとは書かれていない★。D-004（`docs/decisions.md:41`）は ★年間8,400枚★という規模想定だけを書いている |
| ★N27★ | ★論理削除した記録の写真をどうするか★ | ★未決★ | 契約は「論理削除」（`:1395`）とだけ。★ストレージ上の実ファイルを消すのか残すのかが無い★。★`InspectionDetail` に `deleted_at` 相当のフィールドも無い★（`:2234-2256`。実測） |
| ★N28★ | ★削除した記録の復元導線★ | ★未決★ | 記述なし（実測）。論理削除にした以上、★復元できないなら物理削除と運用上同じ★ |

### 3.6 認証・権限（3件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N29★ | ★誰でも登録・削除できてよいか★ | ★未決★ | ★P1 は共有トークン1本★（`d-watch-api.yaml:1406-1414` の `cookieAuth`）。★ユーザー管理・権限管理は P1 スコープ外★（D-032。`docs/decisions.md:201-204`）。→ ★ログインできる人は全員、誰の記録でも削除できる★。これでよいかの記録が無い |
| ★N30★ | ★記入者名が自己申告のテキストのままでよいか★ | ★未決★ | `inspector_name` は ★自由入力の文字列（maxLength 100）★（`:1362`）。★ログイン主体と紐づける仕組みが無い★（N29 の帰結） |
| ★N31★ | ★編集（更新）ができなくてよいか★ | ★未決★ | ★契約に `PUT` / `PATCH` が無い★（`:1290-1401`。実測）。★モックにも編集ボタンが無い★。「誤ったら削除して再登録」という運用を意図しているように読めるが、★記録が無い★ |

### 3.7 施設との紐づけ（2件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N32★ | ★★表示名（`facility_name` / `customer_name` / `serial_number`）をどう解決するか★★ | ★未決。★実装の核心★★ | ★保存するのは `facility_id` / `robot_id`（`:1354`）、返すのは名前3つ（`:2229-2231`）★。★独自ストアとメインDBは別物なので SQL の JOIN ができない★。取りうる案は ★(a) 読み取り時にメインDBを引いて突き合わせる / (b) 登録時に名前をコピーして独自ストアに保存する★ の2つで、★どちらとも書かれていない★ |
| ★N33★ | ★施設名・シリアルが変わったとき、過去の記録は「当時の値」と「現在の値」のどちらを見せるか★ | ★未決★ | N32 の (a) なら現在の値、(b) なら当時の値になる。★施設がメインDBから消えたときの表示も未決★ |

### 3.8 一覧・検索（2件）

| # | 論点 | 状態 | 判定の根拠 |
|---|---|---|---|
| ★N34★ | ★並び順★ | ★未決★ | ★契約に `sort` パラメータも既定順の記述も無い★（`:1296-1321`。実測）。★モックは配列順に出しているだけ★（`d-watch-mock.jsx:1126`） |
| ★N35★ | ★サマリ3値（`total` / `facilities` / `with_notes`）の集計範囲★ | ★未決★ | ★フィルタ適用後の全件か、ページング前か、フィルタ無視の全件かが書かれていない★（`:1330-1335`。実測）。モックは ★フィルタが効かない飾り★なので判断材料にならない |

---

## 4. ★ユーザーが決めるべき論点の一覧★（1論点1行・帰結つき）

### 4.1 ★★これが決まらないと1行も書けない（5件）★★

| # | 論点 | ★この選択をするとこうなる★ |
|---|---|---|
| ★B1★ | ★そもそも点検記録をサービスとして出すのか★（`docs/decisions.md:6670-6671` で「★サービスとして展開するかも保留中です★」とユーザー自身が述べている） | ★「出さない」なら以下の全論点が不要になり、`AppShell.tsx:22` のコメントアウトを恒久化して終わり★。★「出す」なら B2 以降に進む★。★ここが未決のまま B2 以降を決めると、決め損になる★ |
| ★B2★ | ★オブジェクトストレージの実体は何か★（さくらのオブジェクトストレージ / 他の S3互換 / VM のローカルディスク） | ★S3互換なら★ SDK を1つ足して署名付きURLはストレージ側の機能で済む（★アプリは URL を返すだけ★）。★VM のローカルディスクなら★ ストレージ課金は不要だが ★署名付きURLを自前で実装することになり、写真配信が `proxy.ts` の IP制限の内側に入る★（＝社外からは写真が見えない。N23 と連動）。★どちらでも「写真のURL」という契約（`:2256`）は守れるが、実装量が桁で違う★ |
| ★B3★ | ★誰がストレージを用意し、費用を払い、保守するのか★ | ★TeamWorks なら★ 第10回の確認事項に1問足すだけで、DFA は使うだけになる（★ただし回答待ちの分だけ着手が遅れる★）。★DFA なら★ 今日から契約して進められるが、★D-143 で確定した「DFA はビューアーのみ」から外れる★ので、責任分界を1件上書きする決定が要る |
| ★B4★ | ★点検記録に「点検結果」を持たせるか（N18）★ | ★持たせないなら★ いまの契約のまま（写真＋申し送りだけ）で書ける。★持たせるなら★ `d-watch-api.yaml` のスキーマ変更が先（`CLAUDE.md` §6-1）で、★`InspectionDetail` に項目別の結果配列が増え、fixtures と型も作り直し★になる。★後から足すと既存レコードが全部「結果なし」になる★ |
| ★B5★ | ★誰がどこから入力するか（N21 / N22 / N23）★ | ★DFA社内のPCからだけなら★ モックのモーダルをそのまま移植でき、IP制限も現行のままでよい。★現場スタッフがスマホから入れるなら★ ①スマホ幅のレイアウトを新規に設計（★モックに無い＝「モックが正」の原則から外れる決定が要る★）②IP制限の設計変更（`ALLOWED_IPS` は完全一致のみで CIDR 非対応。`lib/config/allowed-ips.ts:14-16`）③共有トークン1本で現場に配るかの判断（N29）— ★3つとも別々の決定になる★ |

### 4.2 暫定で進められるもの（30件）— ★決め方の提案付き★

★以下は「決めないと止まる」ではなく「決めずに始めて、後で差し替えられる」もの★。
★ただし ★印を付けた4件は、後から変えると作り直しになる★。

| # | 論点 | 暫定で進める場合の置き方 | 後から変えると |
|---|---|---|---|
| N1 / N2 | SQLite の採否と置き場所 | ★`data/inspections/` に置き、読み書きを `lib/inspections/` の1モジュールに閉じ込める★（`lib/settings/json-store.ts` と同じ作法） | 中で差し替え可 |
| ★N15★ | 署名付きURLの有効期限 | 設定値として `lib/config/` に外出し（`CLAUDE.md` §7 の閾値ハードコード禁止と同じ扱い） | 設定変更で済む |
| ★N11★ | 1リクエスト合計サイズ | ★先に「1枚ずつアップロードする」設計にしておくと後で困らない★ | ★一括POST前提で作ると作り直し★ |
| N12 / N13 | 縮小・EXIF | 保存時に原本＋長辺1600pxの2枚を持つ | ★既存写真の再処理が要る★ |
| N10 | HEIC | 当面は弾いて 422 | 追加は容易 |
| N14 | 片方だけの登録 | 許す（fixtures がそうなっている） | — |
| N17 | 項目のマスタ化 | ★P1 は enum 固定★（契約どおり） | ★マスタ化は作り直し★ |
| N19 / N20 | 写真なしの意味 / 消耗品 | B4 に従属。B4 が「持たせない」なら記録しない | — |
| N24 / N25 | オフライン / 入力タイミング | ★P1 はオンライン前提★ | ★オフライン対応は全面的な作り直し★ |
| N26 | 保持期間 | ★メインDB に合わせて2年を暫定値、設定値として外出し★ | 設定変更で済む |
| N27 / N28 | 削除時の写真 / 復元 | 論理削除では写真を消さない。復元導線は作らない | — |
| N29 / N30 | 権限 / 記入者 | P1 は共有トークンのまま。`inspector_name` は自己申告 | P2 のユーザー管理と同時 |
| N31 | 編集機能 | ★作らない（削除→再登録）★ | ★API 追加が要る★ |
| ★N32★ | 表示名の解決 | ★登録時に名前をコピーして保存する（(b)案）★を推す — ★メインDBが読めない場面でも一覧が出る／過去の記録が「当時の店名」で残る★ | ★(a)案から(b)案への移行は既存レコードの埋め戻しが要る★ |
| N33 | 施設の改名・消滅 | N32 の帰結として自動的に決まる | — |
| N34 | 並び順 | ★訪問日の降順、同日は id の降順★（他一覧と同じ作法） | — |
| N35 | サマリの集計範囲 | ★フィルタ適用後・ページング前の全件★（他画面と同じ） | — |
| N5 | バックアップ | `/data` ごと VM のバックアップ対象に含めるよう申し送る | — |
| N6 | `USE_FIXTURES` | ★`DataSource` に足さず、`lib/inspections/` を独立させる★ | 中で差し替え可 |
| N23 | 社外からの入力 | B5 に従属 | — |
| その他 | CSVインポート（§6 の M3）/ `group_id` 絞り込み（M2）/ 写真の見せ方（M6） | いずれも ★P1 では作らない★ で進められる | — |

---

## 5. ★実は既に決まっているもの★（ユーザーが「未決」と思っている可能性があるもの）

| # | 「決まっていない」と思われがちなもの | ★実際には決まっている★ |
|---|---|---|
| 1 | 写真の上限（枚数・サイズ・形式） | ★決まっている★ — ★14枚 / 10MB / jpeg・png★（`d-watch-api.yaml:1347`）。★契約に書いてあるので、変えたければ先に YAML を直す★（`CLAUDE.md` §6-1） |
| 2 | 点検項目が何か | ★決まっている★ — ★7項目、英語 enum まで確定★（`:2248`）。★モック・spec・YAML の3つが一致している（実測）★ |
| 3 | 入力欄と必須項目 | ★決まっている★ — ★必須5項目★（`:1354`）。モックの入力欄（`d-watch-mock.jsx:2030-2060`）と一致 |
| 4 | 削除の方式 | ★決まっている★ — ★論理削除★（`:1395`） |
| 5 | 文字数上限 | ★決まっている★ — 記入者100 / 所属会社100 / 申し送り2000（`:1362-1364`） |
| 6 | メインDBに保存しないこと | ★決まっている★ — D-004（`docs/decisions.md:38-40`）。★`CLAUDE.md` §7 の禁止事項にも入っている★ |
| 7 | サンプルデータと型 | ★用意済み★ — `lib/fixtures/inspections.ts`（6件）/ `lib/types/index.ts:979-1009`。★書き始める段階でここは作らなくていい★ |
| 8 | メニューの復活方法 | ★決まっている★ — `components/layout/AppShell.tsx:22` のコメントを外すだけ（D-083 項6） |
| 9 | ページ送り | ★決まっている★ — ★最初から入れる★（`docs/decisions.md:7910` / `:7998`） |
| 10 | ★サーバーの用意と保守★ | ★決まっている（ただし射程に注意）★ — ★TeamWorks★（D-143。`docs/decisions.md:11366-11373`）。★★ただし名指しされているのは「アプリVM / DB / テスト環境」の3つで、オブジェクトストレージは含まれていない★★。→ ★「同じ扱いだろう」と推測せず、論点 B3 として出す★（`CLAUDE.md` §7） |

---

## 6. ★API契約とモックの食い違い（8件）★

| # | 食い違い | モック | API契約 | 状態 |
|---|---|---|---|---|
| ★M1★ | ★写真の項目名★ | ★TS型は日本語リテラル★（`lib/types/index.ts:979-986` の `InspectionItemName`、フィールド名は `item`） | ★英語 enum★（`d-watch-api.yaml:2246-2249` の `item_type`） | ★★未解決のまま残っている★★ — D-083 項3 #2（`docs/decisions.md:2579`）と D-084 項11（`:2745`）が ★「点検記録に着手する前に解決が必要」★と明記。★fixtures も日本語側（`lib/fixtures/inspections.ts:24-32`）なので、直すと fixtures も型も一緒に動く★ |
| ★M2★ | ★グループ絞り込み★ | ★「全グループ / PPIH」のセレクトがある★（`d-watch-mock.jsx:1089-1091`） | ★`group_id` パラメータが無い★（`:1296-1321`。実測。他の一覧11本は持っている） | ★契約の抜け。足すなら YAML が先★ |
| ★M3★ | ★CSVインポート★ | ★ボタンがある★（`d-watch-mock.jsx:1080`）。★ただし `onClick` が無い飾り★ | ★該当エンドポイントが無い★ | `docs/spec.md:220` は ★「過去のGフォームデータのCSVインポート（任意）」★。★D-083 項4 #3（`docs/decisions.md:2592`）の前例に従えば「動かないボタンは置かない」＝実装しない★ |
| ★M4★ | ★`customer_id` が実際には使われていない★ | 「全会社」のセレクトがある（`:1092-1094`） | ★契約が自分で「★`/inspections` の `customer_id` だけは例外で、まだ絞り込みに使っていない★」と書いている★（`d-watch-api.yaml:1452-1454`） | ★画面が復活したときに足す、と契約自身が指示している★ |
| ★M5★ | ★ページ送り★ | ★無い★（7件を一括描画。`:1126`） | `page` / `per_page` あり（`:1320-1321`） | ★契約が正。最初から入れる（C6）★ |
| ★M6★ | ★写真の見せ方★ | ★「📷 写真」は `onClick` の無い飾り★（`:2004`）。★押して何が起きるか定義されていない★ | 契約は URL を返すだけ（`:2253-2256`） | ★モーダルの中でモーダルを開くのか、サムネイルを並べるのかが未定義★。`docs/spec.md:77` は ★「写真グリッド」★と書くが、★モックはグリッドではなく項目名の縦並び★ |
| ★M7★ | ★ロボット選択★ | ★選択肢が空★（「店舗を選択すると表示」。`:2057`） | ★`GET /facilities` の `robots` から選ばせる★と明記（`:1361`） | ★契約側が補っている。食い違いではなく補完★ |
| ★M8★ | ★ブランド列に複数ブランドが出る★ | ★ドン・キホーテ / ユニーの2ブランド★（`:82-88`） | — | ★P1 の対象顧客はドン・キホーテのみ★（`CLAUDE.md` §1）。★モックの見た目と実データの見た目が違う★（他画面と同種の既知事項） |

★既に解消していたもの★: D-083 項4（`docs/decisions.md:2609-2612`）が ★YAML の example に実在の人名が残っている★と指摘していたが、
★現在の `d-watch-api.yaml` は `"点検 太郎"` に置換済み★（`:1362` / `:2227`。★`grep "香原" d-watch-api.yaml` は0件。実測★）。

★契約そのものの抜け（モックとの食い違いではないが、実装時に必ず詰まる）★:

- ★`GET /inspections` に `422` の宣言が無い★（`:1322-1339`）。★他の一覧（例 `/schedules` の `:1287`）は宣言している★。
  ★`customer_id` / `page` / `per_page` の検証は共通で効くので、宣言だけが漏れている★
- ★`POST /inspections` に `413`（サイズ超過）の宣言が無い★（`:1371-1377`）。★10MB の上限を書きながら、超えたときの応答が未定義★
- ★`InspectionDetail` に `created_at` / `deleted_at` が無い★（`:2234-2256`）。★論理削除を謳いながら、状態を表すフィールドが応答に無い★

---

## 7. ★指示書の見取り図★（決まった場合にどうなるか。骨格のみ）

★どの決定がどの段階をブロックしているか★を示す。★詳細は決まってから書く★。

| 段階 | 内容 | ★ブロックしている決定★ |
|---|---|---|
| ★段階0★ | ★契約の食い違いを先に潰す★ — M1（`item_type` vs `item`）、M2 / M4（絞り込み）、`422` / `413` / `deleted_at` の宣言漏れ。★`CLAUDE.md` §6-1 により YAML が先★ | ★B4★（点検結果を持たせるならスキーマが大きく変わるので、B4 の後でないと二度手間） |
| ★段階1★ | ★独自ストアの土台★ — `lib/inspections/` にスキーマと読み書きを作る。fixtures と型は流用 | ★B2 / B3★（置き場所が決まらないと1行目が書けない）、N1 / N2 |
| ★段階2★ | ★写真の保存と取り出し★ — アップロード受け、保存、署名付きURL発行 | ★B2★（実体が S3互換かローカルかで実装が別物）、N11 / N15 |
| ★段階3★ | ★`GET /inspections` と `GET /inspections/{id}`★（読み取り2本） | ★N32★（表示名の解決方法）。★N34 / N35 は暫定で進められる★ |
| ★段階4★ | ★一覧画面★（サマリ3枚 + フィルタ + 8列の表 + ページ送り） | ★B5★（PC のみかスマホもか）。★モック移植で足りるのは PC のみの場合だけ★ |
| ★段階5★ | ★詳細モーダル★（Before/After × 7項目） | ★M6★（写真の見せ方）、★B4★（結果欄の有無） |
| ★段階6★ | ★`POST /inspections`（登録）と登録モーダル★ | ★B4 / B5 / N11 / N29★ |
| ★段階7★ | ★`DELETE /inspections/{id}`（論理削除）★ | ★N27 / N29★（写真をどうするか / 誰が消せるか） |
| ★段階8★ | ★メニューの復活★（`AppShell.tsx:22` のコメントを外す）と `docs/architecture.md:68` / `:130` の更新 | 段階4〜7 の完了 |

★要約★: ★B2（ストレージの実体）と B3（誰が用意するか）が決まれば段階1〜3 は書ける★。
★B4（点検結果を持たせるか）と B5（誰がどこから入力するか）が決まれば段階0 と段階4〜7 まで書ける★。
★B1（そもそも出すのか）が No なら、全段階が不要になる★。

---

## 8. 本書を書くにあたって触れていないもの（確認用）

- ★コードは1行も変更していない★（`lib/` `app/` `components/` `prisma/` `d-watch-api.yaml` `d-watch-mock.jsx` はすべて読み取りのみ）
- ★`docs/decisions.md` `docs/handoff.md` `CLAUDE.md` `docs/spec.md` も読み取りのみ★
- ★他の `docs/handoff/*.md` に触れていない★
- ★git のコミット・push・`git add` を実行していない★
- ★本番DB（`133.125.238.144`）に接続していない★（D-148）