# 指示書AM — 判定境界の変更に追随していない箇所を片付ける

**作成: 2026-09-16 / ブランチ: `develop` / 前提: 指示書AL 完了（D-139 / D-140）**

---

## ★Cursor への指示文（ここから下をそのまま貼ってください）★

> ```
> D-Watch の実装をお願いします。ブランチは develop です。
>
> ■ 最初に読むもの（この順で、全部）
>   1. CLAUDE.md の §4.1（判定基準）と §9.4
>   2. docs/handoff/指示書AM_判定境界の追随漏れを片付ける.md（全文）
>   3. docs/decisions.md の D-139（grep -nE "^### D-(0|1)[0-9][0-9]" docs/decisions.md で
>      位置を出してから読む。★番号順に並んでいません★）
>
> ■ やること
>   指示書AM の 段階1 から 段階5 までを、★番号順に★実行してください。
>   ★どれも小さい変更です★。判定ロジックは1行も変えません。
>
> ■ 段階ごとに必ずやること
>   1. npx tsc --noEmit    → 0 であること
>   2. npm run lint        → 0 であること
>   3. npm test            → 全パス
>   4. コミットする（★段階ごとに1コミット★。まとめない）
>
> ■ コミットの決まり
>   ・git add -A は使わないでください。必ずファイルパスを明示してください
>   ・コミットメッセージは日本語。「なぜそうしたか」を1〜2行入れてください
>   ・push はしないでください
>
> ■ 絶対に触らないファイル
>   README.md / docs/code-map.md /
>   docs/handoff/管理画面_設計検討_20260910.md / .claude/worktrees/** /
>   d-watch-mock.jsx / lib/db/prisma.ts
>
> ■ 絶対にやらないこと
>   ・★判定ロジックを変えること★
>     — lib/judge/grade.ts の比較演算子、GRADE_THRESHOLDS の数値、
>       lib/db/clean-log-mapping.ts の isProblemCompletion() は
>       ★すべて正しく直っています。1文字も変えないでください★
>   ・閾値のハードコード
>   ・新しい CSS に font-family を書くこと
>   ・仕様が不明なところを推測で実装すること
>
> ■ 終わったら
>   ・段階ごとのコミットハッシュ
>   ・tsc / lint / test の結果（テスト本数も）
>   ・★段階1 を実際に確かめた結果★（USE_FIXTURES=true で連続日数がどうなったか）
>   ・指示書どおりにできなかったところと、その理由
>   ・判断に迷って自分で決めたところ（あれば全部）
> ```

---

## 0. なぜこの指示書があるか

★指示書AL の実装は、査読2本とも合格でした。★

```
施設2（90.0）  ○ → ◎
施設5（70.0）  △ → ○   ★かつ 連続2日(L2) → 連続0★
施設8（10.0）  △ → △（変わらず）
当期KPI        顧客ごとに違う数字が出るようになった（SQLで検算済み）
```

★★判定ロジックと波及の連鎖は、実データで正しく動いています。★★

★★残っているのは、その変更に**追随していない**箇所です。★★
★どれも例外が出ません。静かにズレます。★

★★私（監督）が指示書AL の変更対象表に挙げ損ねたものが中心です。★★

---

## 1. 段階1 — ★fixtures のデータが1行、古い規則のまま★

### 1-1. 何が起きているか

```
lib/fixtures/clean-logs.ts:96   consecutive_problem_days: 1
```

★完了率 70.0 の境界ケースに、連続日数が**手書きで** `1` と入っています。★

★70.0 は △（問題あり）だったので `1` が正しかった★のですが、
★★いまは ○（問題なし）なので 0 が正しい★★です。

### 1-2. どうなるか

```
USE_FIXTURES=true   施設5 は ★判定 ○ なのに「連続1日・L1」★ と出る
Prisma 経路         同じ 70.0 の行が ★連続0・エスカレーションなし★
```

★`CLAUDE.md` §9.5 の「fixtures にも本番同等の判定を通す」が崩れています。★
★★切替で挙動が変わります。★★

★`row()` が `escalation_level: judgeEscalationLevel(consecutive)` を導出する★ので、
★連続日数を直せば L1 も自動で消えます。★

### 1-3. ★なぜテストで捕まらなかったか★

★この行を固定するテストがありません。★ ★2,048件すべて通ります。★

### 1-4. やること

- ★`consecutive_problem_days` を `0` にする★
- ★★この行を固定するテストを足すこと★★ —
  ★「完了率 70.0 の fixtures 行は、判定 ○ かつ 連続0 かつ エスカレーションなし」★
- ★同じように手書きの連続日数を持つ行が他に無いか、★★全部確かめること★★★ —
  ★70 / 90 の境界に関わる行を重点的に★

### 1-5. ★確かめ方★

★`USE_FIXTURES=true` で `/api/clean-logs` を叩き、★★完了率 70.0 の行の
`consecutive_problem_days` と `escalation_level`★★ を見ること。★
★実DB（ローカルDB）の同じ行と突き合わせて、★★一致すること★★を確かめてください。★

---

## 2. 段階2 — ★画面の凡例が「90%超 / 70%超」のまま★

### 2-1. 何が起きているか

| ファイル:行 | 表示 |
|---|---|
| `components/features/detail-log/CleanLogTable.tsx:128` | `◎ {excellent}%超` |
| `components/features/detail-log/CleanLogTable.tsx:131` | `○ {good}%超` |
| `components/features/system/SystemScreen.tsx:83-84` | `完了率 {excellent}% 超` / `完了率 {good}% 超` |

★90.0 の行に ◎ が付いているのに、同じ画面の凡例が「◎ 90%超」と書いている★状態です。

### 2-2. やること

★「超」を「以上」に直す。★

★★数値は `GRADE_THRESHOLDS` から読んでいるので、そのまま。★★ ★文言だけです。★

### 2-3. ★ついでに直すもの★

`components/features/detail-log/CleanLogTable.tsx:134`

```
△ {poor}-{good - 1}%     →  「10-69%」と表示される
```

★★69.5 がどこにも該当しない読み方★★になります（★10-69% でも 70%以上でもない★）。
★これは D-139 以前からある表記の問題★です。

★「10%以上70%未満」のように、境界の含む/含まないが読み取れる表記にすること★
（★D-062 の趣旨★）。★`good - 1` のような計算をやめること。★

---

## 3. 段階3 — ★申し送り済みの3箇所を片付ける★

★実装者が指示書AL のとき「触らない」指定だったため手を出さず、記録に残したもの★です。
★判断は妥当でした。★ ★今回片付けます。★

| ファイル:行 | 残っている記述 |
|---|---|
| `lib/judge/advice.ts:23` | `| B1 | 完了率10%以上70%以下（マップ更新の確認） |` |
| `lib/judge/advice.ts:80` | `// B1: △判定（完了率10%以上70%以下）のとき…` |
| ★`lib/config/advice-rules.ts:101`★ | ★`condition: "完了率が10%以上70%以下（△判定）"`★ |
| `d-watch-api.yaml:477` 付近 | B1 の条件文 |

★★`advice-rules.ts` の `condition` は画面に出ます★★
（`components/features/system/SystemScreen.tsx` の2箇所、`GET /settings/advice` の応答）。
★★運用担当が読む文言です。★★

### やること

★「10%以上70%未満」に直す。★

★★`lib/judge/advice.ts` のコードは1行も変えないこと★★ —
★B1 は `judgeGrade(completionRate) === "△"` を見ているので、既に新しい規則に追従しています。★
★変えるのはコメントだけ。★

★`d-watch-api.yaml` を直したら、`lib/types/index.ts` の型と食い違わないか確かめること。★

---

## 4. 段階4 — ★コメントの古い言い回し★

★どれも動作に影響しません。★ ★次に読む人が古い規則を信じるのを防ぎます。★

| ファイル:行 | 残っている記述 |
|---|---|
| `lib/fixtures/clean-logs.ts:81` | `90.0 ○ 90% ← 「90%超」なので90.0は○` |
| `lib/fixtures/clean-logs.ts:84` | `70.0 △ 70%`（境界値の表） |
| `lib/fixtures/areas.ts:72` | `全体 90.1% = ◎（90%超）` |
| ★`lib/fixtures/areas.ts:78`★ | ★`ちょうど90.0% = ○（90%超が◎なので◎にならない）`★ |
| ★`lib/fixtures/areas.ts:84`★ | ★`ちょうど70.0% = △（70%超が○）`★ |
| `scripts/seed-local-db.ts:496,499,502` | `◎: 90%超` / `○: 70%超90%以下` / `△: 10%以上70%以下` |

★★`lib/fixtures/areas.ts:78` と `:84` は、同じモジュールのテストと逆のことを書いています★★
（テストは ◎ / ○ を期待している）。★注記だけが古い★です。

★`scripts/seed-local-db.ts` は生成値が境界を 0.5 避けているので、★★挙動は正しい★★。
★文言だけ直すこと。★

---

## 5. 段階5 — ★`docs/handoff.md` の印の付け忘れ★

★`docs/decisions.md` 側は作法どおり印が付いています★（D-020b `[破棄]` / D-109 / D-062 / D-138 の残課題）。
★`docs/handoff.md` だけ取り残されています。★

| 箇所 | 何が書かれているか |
|---|---|
| ★`docs/handoff.md:2989-2993`★ | ★★「完了率ちょうど70.0%は『問題あり』です」「`judgeGrade()`（○=70%超）は変えていません」★★（指示書V 当時の記述） |
| `docs/handoff.md:28-29`（冒頭の「最新の追記」ブロック） | 追記50 の要約に「★残課題: 当期のKPIはまだ顧客/施設で絞り込んでいません★」 |
| `docs/handoff.md:4625-4628`（追記50 §2 残課題の1番） | 「★当期…KPIが顧客/施設で絞られていない…対応方針は未決定★」 |

### やること

★3箇所とも、★★元の文は消さずに★★ 印と行き先を足すこと。★

```
★【D-139 で変更】★ 完了率ちょうど70.0% は、現在は「問題なし」（○）です。
★【D-140 で解決済み】★ 当期のKPIも顧客で絞られるようになりました。
```

★★消して書き換えないこと★★ — ★当時そう判断した経緯そのものが記録★です。
★D-020b / D-053 / D-133 / D-135 / D-138 で使っている作法と揃えること。★

### 5-2. ★D-140 と追記51 の「触ったファイル」一覧の漏れ★

★次の2つが一覧から落ちています。★

```
components/features/reports/ReportsScreen.module.css
lib/db/fixture-reports.ts
```

★足すこと。★ ★一覧が実際の差分と食い違うと、次の人が差分を追えません。★

---

## 6. 段階6 — 記録

★★採番の前に必ず実測すること★★:

```bash
grep -nE "^### D-(0|1)[0-9][0-9]" docs/decisions.md | tail -3
```

★番号順に並んでいません。★

★今回は新しい決定を作るほどの内容ではありません。★
★**D-139 に追記する形でよい**★（「追随漏れを AM で片付けた」）。
★新しい D 番号を切るかどうかは実装者判断★ですが、★切るなら理由を書くこと★。

書くこと:

- ★fixtures の 70.0 の行が古い規則のまま残っていたこと★と、★★テストが無かったこと★★
- ★画面の凡例が追随していなかったこと★ — ★指示書AL の変更対象表に挙げ損ねた（監督の漏れ）★
- ★`docs/handoff.md` に印を付けたこと★

---

## 7. ★実装者へ — 特に踏みやすい落とし穴★

| # | 落とし穴 | どうなるか |
|---|---|---|
| ★1★ | ★判定ロジックを「ついでに」直す★ | ★★すべて正しく直っています。触ると壊れます★★ |
| ★2★ | ★`lib/judge/advice.ts` のコードを直す★ | ★B1 は `judgeGrade()` 経由で既に追従★。★変えるのはコメントだけ★ |
| ★3★ | ★fixtures の連続日数を直したが、テストを足さない★ | ★同じ見落としがまた起きる★ |
| ★4★ | ★境界に関わる他の手書き行を確かめない★ | ★:96 だけ直して他が残る★ |
| ★5★ | ★`docs/handoff.md` の古い記述を消して書き換える★ | ★当時の判断の経緯が失われる★。★印を足すこと★ |
| ★6★ | ★`△ {poor}-{good - 1}%` を数値だけ直す★ | ★69.5 がどこにも該当しない表記のまま★。★表記そのものを変えること★ |
| ★7★ | ★`GRADE_THRESHOLDS` の数値を触る★ | ★90 / 70 / 10 のまま★ |

---

## 8. やらないこと（★この指示書の範囲外★）

| 項目 | なぜ |
|---|---|
| ★判定ロジックの変更★ | ★AL で完了・査読済み★ |
| ★総清掃面積の新画面★ | ★次の指示書★ |
| ★分類の画面の目視★ | ★ログインが要る。ユーザーにお願いする★ |
| ★複数顧客の合算★ | 第9回 6章で照会中 |
| ★`group_id = 0` の投入★ | 第9回 Q7-4 で照会中 |
| ★スマートフォン幅のレイアウト★ | 別課題 |