指示書T — ローカルDBで動かす第5歩（レポートサマリ3本を実DB経由にする）

実行後はこの表と、文書末尾の「実行状態」表を更新してください。

★この指示書を読んでいるあなたへ★ — .claude/commands/d-watch.md の「実装は Cursor 側」は 2つの環境の役割分担です。Cursor の中で動いている Claude は実装担当です。 ★調査や改訂ではなく実装を行ってください。★ ★★うまくいかなければ段階の切れ目（コミット単位）で止めて構いません★★ — ★本書は API契約（d-watch-api.yaml）も型（lib/types/index.ts）も変えないので、 USE_FIXTURES=true に戻せば画面は元に戻ります★。

★★冒頭に読むべきこと — なぜ3本で、continuousProblems を含めないのか★★

★本指示書の範囲は reportKpis / facilityPerformance / errorBreakdown の3本です。★ ★★continuousProblems には手を付けません。★★ 理由は2つ:

★→ continuousProblems は 第6歩（別の指示書）で扱います★。 ★/reports 画面の「連続問題施設」セクションは、本書の作業後も USE_FIXTURES=false では notImplemented で 500 になります★（lib/db/index.ts:497-499）。★これは想定内★。 ★段階5 の動作確認では、この1本だけが落ちることを確認して記録すること★。

★★方針 — 確定期間のレポートはサマリテーブルをそのまま読む（D-102）★★

★★履歴（詳細テーブル）から率を再計算しないこと。★★ 理由は ★責任分界★ です。

CLAUDE.md §2「責任分界 — 何を作り、何を作らないか」（★CLAUDE.md:49★）の表:

★つまり「確定した期間の集計は TeamWorks の成果物であり、DFA はそれを読むだけ」「進行中の期間だけ DFA がその場で集計する」と、責任の線が既に引かれている★。★当方が確定期間を再計算すると、 TeamWorks のバッチ結果と当方の表示が食い違ったときに「どちらが正か」が決められなくなる★。

★errorBreakdown は facility 版か customer 版か — 実装時に最終確認すること★

★D-090 項11（docs/decisions.md:3397）が「customer 版と facility 版のどちらを読むか未決」と していた★。★★D-102 項4（docs/decisions.md:5181-5196）が「facility_error_summaries を読む。customer_error_summaries は P1 では読まない」と決めたうえで、なお「facility 版にするか customer 版にするかは実装時に画面の要求と突き合わせて最終確認すること」と留保している★★。

• ★customer_error_summaries（prisma/schema.prisma:735）と facility_error_summaries（:755）は ★customer_id / facility_id 以外まったく同じ構造★（実測して確認すること）
• ★画面（components/features/reports/ReportsScreen.tsx）が求めているのが 全社の内訳なら customer 版、施設別に足し上げた内訳なら facility 版★。 ★P1 の顧客はドン・キホーテ1社のみ（CLAUDE.md §1）なのでどちらでも同じ値になるはず★ — ★★だからこそ「どちらを読んだか」を決めて記録しないと後から追えなくなる★★
• ★推奨: facility_error_summaries★（★facilityPerformance と粒度が揃い、将来「施設で絞った エラー内訳」が要求されてもクエリを変えずに済む★）。★ただし画面を読んでから最終判断すること★

★★着手前確認 — ★★なし（回答済み。2026-09-10）★★★★

★以下は解決済みの記録です。★★確認を待つ必要はありません★★（★記録: D-103。D-104 項5 でも確認済み★）。

★FacilityPerformance.consecutive_problem_days をどうするか★ → ★★A案で確定★★

★★ユーザーの問い（2026-09-10。原文）★★:

Tはテーブル定義書を読んで該当しそうなテーブルの候補などないですか

★★指摘のとおり調べるべきだった。調べた結果、該当するテーブル・カラムは存在しない★★:

• ★テーブル定義書（docs/handoff/analysis/table-definitions-01-master.md / -02-clean-error.md / -03-schedule-summary.md。★全29テーブル★）を ★「連続」「consecutive」「continuous」「継続」★で全文検索した結果、★★ヒット0件★★ （2026-09-10 実測。★着手時に自分でも走らせて確認すること★）
• ★サマリ系4本（customer_summaries / facility_summaries / customer_error_summaries / facility_error_summaries）にも無い★ — ★持っているのは task_count / launch_count / error_count / task_area / clean_area と 率4本（operation_ratio / launch_ratio / clean_ratio / error_ratio）だけ★ （docs/handoff/analysis/table-definitions-03-schedule-summary.md:106-237 を実測）
• ★★これは当然でもある★★ — ★D-026（docs/decisions.md:122）が 「連続はカレンダー日ではなくスケジュール存在日の連続」と定めており、 ★これは DFA 側の判定仕様★。★TeamWorks がこの値を持つ理由が無い★

★確定内容 — A案★:

• ★computeConsecutiveProblemDays()（lib/db/clean-log-mapping.ts:112）を流用する★
• ★同関数は既に cleanLogs() から呼ばれている★（lib/db/index.ts:299）。 ★同じ関数を使えば /detail-log と /reports で連続日数が食い違わない★
• ★記録は docs/decisions.md の D-103★

選択肢（★当初の提示をそのまま残す。採用案に ✅★）:

★★懸念への手当て★★:

• ★全件走査が2回になる点（cleanLogs() と facilityPerformance()）は、 ★実データで遅ければ後から手を打てばよい★（結果を共有する / 期間で絞れるようにする 等）★
• ★★まず正しい値を出すことを優先する★★。★段階5 で体感が遅ければ、その事実を段階6 で記録すること★

★D-090 との関係★:

• ★D-090 項15（docs/decisions.md:3406）が挙げた「lib/db/index.ts:59-63 の方針コメントと consecutive_problem_days（全期間走査）の衝突」は、★A案の採用（＝判定も集計も prismaSource 内でやる）で 方向が決まった★。★方針コメントの書き換えを伴うので、段階3 で実施し段階6 で記録すること★
• ★D-090 項13（:3399。ContinuousProblem.summary の生成規則）は★第6歩の話★なので本書では扱わない★

★★回答済みなので、段階3 に進んでよい★★（★段階1・2 はもともと先に進めてよい★）。

★上記以外で実装者が判断できないものはなし★ — ★errorBreakdown の facility / customer は 画面を読めば決まる★し、★当期集計の置き場所は下記「調査済みの事実」5 で推奨を示している★。

★調査済みの事実（★現物で裏を取ってから使うこと★）★

1. ★サマリテーブルの構造（2026-09-10 実測。★自分で読み直すこと★）★

★facility_summaries（prisma/schema.prisma:701-733）★:

• ★customer_summaries（:667-699）は facility_id が customer_id になるだけで同一構造★ （★実測して確認すること★）
• ★facility_error_summaries（:755-773）は構造が違う★: id / facility_id / year / month / week / ★error_level（VarChar(20)）★ / ★error_type（VarChar(100)）★ / ★error_detail（Text）★ / ★error_count★ / created_at。 ★★updated_at が無い★★（:765 で終わり。★実測★）。★operation_ratio 等の率カラムも無い★
• ★4本すべて deleted_at を持たない★ → ★論理削除の絞り込みを書かない★（書くと型エラー＝安全側）

2. ★★重要: 率がもう小数になっている（D-094）★★

• ★実DDL の operation_ratio / launch_ratio / clean_ratio / error_ratio は ★tinyint unsigned（整数）→ double(4,1)（小数第一位）★に変更済み★ （★D-094 項1-A。docs/decisions.md:3851-3856 の表。customer_summaries:402-405 / facility_summaries:564-567 はDDLファイル内の行番号であってリポジトリの行ではない★）
• ★prisma/schema.prisma:686-689（customer）/ :720-723（facility）のコメントが 「Prisma型は Int → Float」と明記している★（★実測★）
• ★★帰結: D-090 項5・項12 は解消済み★★。★「サマリの率が整数なので面積から再計算する必要がある」 という以前の見立てはもう成り立たない★。★★サマリの値をそのまま KpiValue.value に入れてよい★★
• ★Decimal → number の変換も不要★（D-096 で Float に追従済み。★.toNumber() を書かないこと★）

3. ★期間キーの扱い（D-072 項4 / D-071）★

• ★★week = 0 が月次、month = 0 AND week = 0 が年次★★（★D-072 項4。docs/decisions.md:921 / 同 :927-931 の表★）。★年次は P1 では読まない★
• ★ReportPeriodKey.week は monthly のとき 0★（★lib/types/index.ts:241-255。特に :246★）
• ★API の week は 1以上のみ受け付ける★（lib/reports/query.ts:48 WEEK_MIN = 1 / :46-47）。★週次は 1〜6★（:49 WEEK_MAX = 6。★D-071 の下では第6週が発生する★）
• ★帰属ルールを知っているのは lib/format/period.ts の weekOfMonth()（:126）だけ★（D-071）。 ★★prismaSource の中で「1日から数えて何本目」のような計算を書き直さないこと★★
• ★サマリ行の year / month / week はそのまま ReportPeriodKey に写せる★ （★DB 側の規約と内部表現を揃えてあるのがこの設計の狙い。lib/types/index.ts:248-251★）。 ★period は week === 0 ? "monthly" : "weekly" で決まる★

4. ★prev（前期値）の作り方★

• ★★DB に前期値は無い★★。KpiValue は { value, prev, diff }（lib/types/index.ts:167-180）で、 ★diff は toKpiValue() が計算する★（★lib/judge/kpi.ts:58-64★）
• ★手順★: ★1つ前の期間の行を引き、toKpiValue(今期の値, 前期の値) を呼ぶ★。★前期の行が 無ければ prev = null（新規施設のケース。toKpiValue() が diff も null にする）★
• ★★1つ前の期間は shiftPeriod()（lib/format/period.ts:240）で求める★★ — ★★自分で week - 1 を書かないこと★★。★D-071 の下では週の長さが1〜7日で変わり、 第1週の前は「前月の最終週」になる★（:257 のコメント）。 ★shiftPeriod("monthly", y, m, 0, -1) は week: 0 を返す★（:247-255）
• ★fixtures が同じことをしている★: lib/fixtures/reports.ts:49-70（todayJst() → weekOfMonth() → shiftPeriod()）。★この並びをそのまま流用すること★
• ★実装のコツ★: ★全サマリ行を1回で取り、`${period}/${year}/${month}/${week}` をキーにした Map を作ってから、各行について前期キーを引く★（★N+1 クエリにしない★）

5. ★★当期（進行中の週・月）の扱い — ここが最大の論点★★

事実（★すべて実測★）:

★★これを段階2 の中で決め、記録すること（段階6）。★★

★推奨: prismaSource の中でやる★。理由:

• ★DataSource は引数を取らないので、API ルート側では「どの期間を集計すべきか」を データ層に伝えられない★（D-090 項15）
• ★★指示書R で cleanLogs() が既に同じことをしている前例がある★★ — ★lib/db/index.ts:299（computeConsecutiveProblemDays()）と :307・:309 （judgeGrade() / judgeEscalationLevel()）★。★実測して確認すること★。 ★D-090 項16（docs/decisions.md:3407）が「judge を prismaSource の中で呼ぶこと自体は妥当」と結論済み★
• ★lib/reports/query.ts:319-323 が「実DB接続時は、この分岐を『詳細テーブルからその場集計』に 差し替える」と書いている★。★★その実体を prismaSource に置くと決めれば、 lib/reports/query.ts は1文字も変えずに済む★★（selectKpiRow() は「行があれば返す」だけになる）
• ★決めたら lib/db/index.ts:70-75 の設計方針コメントに例外を明記すること★ （★D-090 項15 が「方針コメントの書き換えを伴う」と指摘★。★cleanLogs() と同じ扱いで1行足せばよい★）

★★当期の集計元は詳細テーブル★★ — ★clean_timetables × clean_status_histories × robot_error_reports（cleanLogs() が既に読んでいるもの）を期間で絞り、lib/judge/kpi.ts の operationRate()（:26）/ launchRate()（:31）/ completionRate()（:36）/ errorRate()（:44）に通す★。 ★★期間の範囲は periodRange()（lib/format/period.ts:157）で求めること★★（自分で日付計算をしない）。 ★completionRate() は面積ベース（CLAUDE.md §4.2 / lib/judge/kpi.ts:35）★。

6. ★落とし穴（★現物で確認すること★）★

★禁止事項（この指示書の全段階に効きます）★

作業の順序（★崩さないこと★）

★段階ごとに npx tsc --noEmit / npm run lint / npm test を実行し、通ってからコミットすること★ （D-050。docs/decisions.md:308）。

段階0 — 前提の確認（★読むだけ・コミットなし★）

読むもの

接続先の確認とこの段階の完了条件

• ★.env.local の DATABASE_URL が dwatch_local を指していることを確認する★。 ★値そのものを画面・ログ・文書に出さないこと★（CLAUDE.md §9.3）
• ★.env.local に ALLOW_DIRECT_ACCESS=true があることを確認する★（★作成時点では キーの存在を実測済み。値は確認していない★。D-101 項2。★無いと proxy.ts が全ルートを止める★）
• ★着手前の基準値（npm test のファイル数・テスト数 / tsc / lint）を自分で実測して控えた★
• ★★着手前確認（consecutive_problem_days）の回答を得た★★（段階3 の前までに） / ★D-102 の存在を確認した（無ければ方針をユーザーに確認した）★

段階1 — ★サマリ3テーブルのシードを足す★

1-1. 作るもの

★scripts/seed-local-db.ts に3テーブルの投入を足す★。★★挿入順（FK依存）★★:

1. ★customer_summaries★ ← 親は ★customers（シードは1件のみ。scripts/seed-local-db.ts:411-415。★customer_id = 1★）★
2. ★facility_summaries★ ← 親は ★facilities★
3. ★facility_error_summaries★ ← 親は ★facilities★

★customer_error_summaries は投入しない★（★errorBreakdown を customer 版にすると決めた場合のみ代わりに投入する★）。

1-2. ★lib/fixtures/reports.ts から変換して INSERT する★

★第1〜4歩と同じ方針（fixtures を DB の形に落とす）★:

• ★*_count / *_area は「率と辻褄が合う値」を作ること★（★検算できるようにするため。 例: task_count=100, launch_count=94 なら launch_ratio=94.0★）。 ★★規則をコメントに書くこと★★
• ★★率は小数第一位に丸めて入れること★★（double(4,1)。★91.43 は入らない★）
• ★実在の住所・電話番号・社名・人名を入れないこと★（CLAUDE.md §7 / D-043）

1-3. ★★当期（今週・今月）はサマリに入れないこと★★

• ★fixtures は4期間（今週 / 先週 / 今月 / 先月）を持つ★（lib/fixtures/reports.ts:111-116 の PERIOD_KEYS。★実測して確認すること★）
• ★★シードに入れるのは「先週」と「先月」の2期間だけ★★。★今週・今月は入れない★ — 理由: ★実データでは当期の行が存在しない（CLAUDE.md:193）のでそれを再現する★。 ★★入れてしまうと段階2 の当期集計が一度も走らず、実装を検証できない★★
• ★期間キーは実行日から相対で作ること★（★todayJst() → weekOfMonth() → shiftPeriod(..., -1)。 lib/fixtures/reports.ts:49-70 と同じ★）。★★日付を固定すると時間が経って「先週」が 当期になったり2期間前になったりする★★
• ★week は月次なら 0、週次なら 1〜6★（D-072 項4）

1-4. ★冪等にすること・検算★

• ★deleteMany を挿入の逆順で先頭に足す★（scripts/seed-local-db.ts:392-405 の並びを崩さない。 ★facilityErrorSummary → facilitySummary → customerSummary の順で、 facility.deleteMany() / customer.deleteMany() より前★）
• ★件数を console.log に出す★（:762-774 の完了ログに足す）/ ★2回続けて実行して結果が同じであること★

この段階の完了条件

• ★npm run seed:local が通り、3テーブルの件数が想定どおり★ （★customer_summaries = 2（先週・先月）/ facility_summaries = 施設数 × 2 / facility_error_summaries = 9 × 2 の見込み。★自分で数えること★）
• ★2回実行して同じ結果になること★ / ★★当期（今週・今月）の行が0件であること（SQL で確認）★★
• npx tsc --noEmit エラー0 / npm run lint 0 / npm test 全パス / ★ここで1コミット★

段階2 — prismaSource.reportKpis() を実装する

2-1. 作るもの

★lib/db/index.ts:491-493 の notImplemented("reportKpis") を実装に置き換える★。 ★cleanLogs()（:186）と同じ形にすること★（遅延 import → クエリ → 変換 → map）。

2-2. ★確定期間: customer_summaries を読む★

1. ★prisma.customerSummary.findMany()（★全件。DataSource は引数を取らない★）★
2. ★`${period}/${year}/${month}/${week}` をキーにした Map を作る★ （period は ★week === 0 ? "monthly" : "weekly"★）
3. ★各行について shiftPeriod() で1つ前の期間キーを求め、Map から前期行を引く★
4. ★toKpiValue(row.operation_ratio, prev?.operation_ratio ?? null) を4指標ぶん★
5. ★★month === 0 && week === 0（年次）の行は除外する★★（P1 では読まない。D-072 項4）

2-3. ★★当期: 詳細テーブルからその場集計する★★

★「調査済みの事実」5 の推奨（prismaSource の中でやる）に従う場合★:

1. ★todayJst()（lib/format/date.ts:19）から当週・当月の期間キーを作る★ （★weekOfMonth() / lib/fixtures/reports.ts:49-70 と同じ手順★）
2. ★periodRange()（lib/format/period.ts:157）で [from, to] を求める★
3. ★clean_timetables × clean_status_histories × robot_error_reports を読み、 その範囲の本清掃行を集計する★（★cleanLogs() の読み方（lib/db/index.ts:190-236）を流用★）
4. ★lib/judge/kpi.ts の4関数に通す★（★completionRate() は面積ベース★）
5. ★prev は「1つ前の期間」＝確定期間のサマリ行から取る★（★当期の前は先週/先月なので サマリに存在するはず★）
6. ★確定期間の行と当期の行を1つの配列にして返す★

★★この設計判断（prismaSource で当期集計を行うこと）をコードコメントに残すこと★★ — ★lib/db/index.ts:70-75 の設計方針コメントに例外として1行足す★（★cleanLogs() の 連続日数・judge と同じ扱い。D-090 項14 / 項15 の解決★）。

2-4. ★純粋関数に切り出してテストを書く★

• ★置き場所★: ★lib/db/report-mapping.ts を新設することを推奨★（★clean-log-mapping.ts と混ざらない★）
• ★切り出す候補★: ★サマリ行 → ReportPeriodKey（week===0 → monthly）★ / ★期間キー → Map のキー文字列★ / ★サマリ行 + 前期行 → ReportKpi★
• ★★期待値表を先に作ること★★（CLAUDE.md §9.4）。★境界値: week=0（月次）/ week=1（第1週。 前期は前月の最終週）/ week=6 / month=0 AND week=0（年次。除外される）/ 前期行が無い（prev=null）/ 率が 0.0★。★DB 依存のテストは書かない★（禁止事項13）

この段階の完了条件

• npx tsc --noEmit エラー0 / npm run lint 0 / npm test 全パス（★新規テストを含む★）
• ★lib/reports/query.ts / API ルート / 画面に差分が無いこと★
• ★当期集計をどこでやると決めたかがコードコメントに書かれていること★ / ★ここで1コミット★

段階3 — prismaSource.facilityPerformance() を実装する

★lib/db/index.ts:494-496 の notImplemented("facilityPerformance") を置き換える★。

3-1. クエリ

• ★prisma.facilitySummary.findMany({ include: { facility: true } })★ （★FK があるので include が使える。prisma/schema.prisma:726★）
• ★serial_number は facility_summaries に無い★ → ★robots を別途引いて facility_id で結ぶ★ （★facilities()（lib/db/index.ts:407）と同じ形★）。★P1 は1清掃エリア=1ロボットなので先頭1台★
• ★★ロボットが0台の施設（fixtures の施設12）をどう扱うか決めて記録すること★★ （★推奨: serial_number: "" ではなくその施設の行を返さない。cleanLogs() / schedules() は 例外を投げているが（lib/db/index.ts:258-262 / :465-469）、★レポートは「一覧の1行が欠ける」で 済むので例外は重い★）

3-2. 各フィールド

3-3. 当期

• ★段階2 と同じ★ — ★当期の施設別行はサマリに無いので、詳細テーブルから施設ごとに集計する★
• ★★段階2 で作った当期集計を「施設ごとに束ねる」形に一般化できるなら、共通化すること★★ （★reportKpis は全社1行、facilityPerformance は施設ごと1行。分母・分子の作り方は同じ★）

この段階の完了条件

• npx tsc --noEmit エラー0 / npm run lint 0 / npm test 全パス
• ★status が lib/judge/ 経由で決まっていること（good / warning / bad を直書きしないこと）★
• ★consecutive_problem_days の扱いがコードコメントに書かれていること★ / ★ここで1コミット★

段階4 — prismaSource.errorBreakdown() を実装する

★lib/db/index.ts:500-502 の notImplemented("errorBreakdown") を置き換える★。

4-1. クエリと集計

• ★「方針」章で決めたテーブル（推奨 facility_error_summaries）を findMany()★
• ★facility 版を選んだ場合、★★同じ期間・同じ error_type の行を全施設ぶん足し上げる★★ （★施設ごとに1行ずつ入っているため。★足し忘れると同じ種別が複数行出る★）
• ★rate はサーバ側で計算する★（★ErrorBreakdownItem.rate のコメント。lib/types/index.ts:214-219 「サーバが返す…フロントで再計算しない」★）。 ★★分母はその期間の全エラー件数の合計★★（lib/fixtures/reports.ts:478-483 と同じ作法。 ★合計を定数に置かず reduce で出すこと★）
• ★★rate は丸めない生値★★（CLAUDE.md §4.3）

4-2. ★error_type は生値のまま★

• ★★type と label の両方に同じ生値を入れる★★（★D-077 / D-088。 lib/types/index.ts:206-213 と lib/fixtures/reports.ts:455-462 のコメント★）
• ★7分類への変換をしない★ / ★日本語に変換しない★ / ★空文字も未知の値もそのまま通す★
• ★★帰結: 画面には EmergencyStop のような英語識別子が出る。それが意図した挙動★★

4-3. 当期

• ★当期のエラー内訳は robot_error_reports を期間で絞って error_type ごとに数える★
• ★periodRange() で範囲を求め、errored_at ?? created_at で期間判定すること★ （★指示書S で detected_at に採った規則と揃える。★指示書S の結論を実測して合わせること★）

この段階の完了条件

• npx tsc --noEmit エラー0 / npm run lint 0 / npm test 全パス
• ★type と label に同じ値が入っていること★ / ★rate の合計が 100 になること（テストで固定）★
• ★facility / customer どちらを読んだかがコードコメントに書かれていること★ / ★ここで1コミット★

段階5 — ★★動作確認（コミットなし）★★

5-1. 起動 / 5-2. ★USE_FIXTURES の true / false で突き合わせる★

• ★★npm run dev を Bash で起動しないこと★★ → ★Browser pane の preview_start を使う★
• ★★認証が入っている（D-101）★★ → ★.env.local の ALLOW_DIRECT_ACCESS=true が要る★。 ★★/login でトークンを入れる必要があるかも確認すること★★（★分からなければ止めて聞く★）

★/api/reports/kpi / /api/reports/facility-performance / /api/reports/error-breakdown / /api/reports/continuous-problems の4本を、period=weekly / monthly の両方で叩いて比べる★。

5-3. ★画面での確認★

• ★/reports で週次・月次の切り替えができること★ / ★前期比の増減（▲▼）が出ること★（★prev が入っていないと出ない★）
• ★★当期（今週・今月）が正しく出ること★★ — ★★サマリに行が無くても詳細テーブルから 算出されて表示されること★★。★期間ナビで「先週 → 今週」と動かして両方に値が出ることを見る★
• ★エラー種別の内訳に英語識別子が出ること★（生値方針の帰結）
• ★★連続問題施設のセクションだけが壊れる（または空になる）こと★★を確認し、記録する

5-4. ★検算（任意だが推奨）／ログの確認／復帰★

• ★サマリの launch_ratio と launch_count / task_count * 100 を突き合わせる★。 ★★食い違ったら記録するだけ。当方の計算値で上書きしない★★（禁止事項1 / 落とし穴7）
• ★サーバログにエラーが出ていないこと★
• ★★確認後 USE_FIXTURES=true に戻すこと★★。★戻したあと全画面が従来どおり動くこと★

この段階の完了条件

• ★5-2〜5-4 をすべて実施して結果を控えた★ / ★USE_FIXTURES=true に戻した★ / ★コミットしない★

段階6 — 記録と push

docs/decisions.md に追記

★★着手直前に最終番号を実測すること★★ — grep -nE "^### D-(0|1)[0-9][0-9]" docs/decisions.md | tail -3。 ★★^### D-1 も grep すること★★（★^### D-0 だけでは3桁台を拾えない★）。

★記録すること★:

★docs/handoff.md にも1追記★（★直前の追記番号を実測して採番★）。

push とこの段階の完了条件

• ★git add はファイルパスを明示★。★★git add -A は禁止★★（CLAUDE.md §7）
• ★git commit（メッセージは日本語。既存のログの書式に倣う）★ / ★git push origin develop★
• ★文書末尾の「実行状態」表と冒頭の表を更新した★

★やらないこと（第6歩以降）★

完了条件（全体）

1. ★★着手前確認1件（consecutive_problem_days）の回答を得てから段階3 に入った★★
2. ★★D-102（docs/decisions.md:5139）を読み、方針・読むテーブル・当期の扱いを確認した★★
3. 段階0〜6 をすべて実施した（★途中で止めた場合は、どこで止めたかを実行状態表に書くこと★）
4. npx tsc --noEmit エラー0 / npm run lint 0 / npm test 全パス
5. ★USE_FIXTURES=false で /reports が 200 で表示され、週次・月次とも KPI と前期比（▲▼）が出ること★
6. ★★当期（今週・今月）が、サマリに行が無い状態で正しく算出されて表示されたこと★★
7. ★エラー種別の内訳に英語識別子が出ること★（生値方針の帰結）/ ★/api/reports/continuous-problems が 500 のままであること（第6歩に残した）を確認した★
8. ★USE_FIXTURES=true に戻して全画面が従来どおり動くこと★
9. ★prisma/schema.prisma / lib/fixtures/ / lib/reports/ / API ルート / 画面 / lib/db/prisma.ts / local-guard.ts / use-fixtures.ts / ds-status.ts / clean-log-mapping.ts / prismaSource の既存6メソッド に差分が無いこと★ （★着手前確認で C案 を選んだ場合を除く★）
10. docs/decisions.md / docs/handoff.md の更新 / ★origin/develop へ push 済み★ / 文書末尾の「実行状態」表を更新した

実行状態

実行日: 2026-09-11 / 取得した決定番号: D-107（着手時点の最終番号）→ 本作業で D-108 を追加 着手前の実測値: tsc 0 / lint 0 / npm test 44ファイル/862テスト 当期集計の置き場所: ★prismaSource の中（決定。D-108項1）★ / errorBreakdown のテーブル: ★facility_error_summaries（決定。D-108項2）★ / consecutive_problem_days: ★★A案で確定・実装済み★★（computeConsecutiveProblemDays() を流用。D-103） / 検算の結果: ★24行中6行で最大0.5ポイントの食い違い（シードの丸め誤差。D-108項4）★ 詳細: docs/decisions.md の D-108 / docs/handoff.md 追記32 を参照