指示書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. 何が起きているか

★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 のとき「触らない」指定だったため手を出さず、記録に残したもの★です。 ★判断は妥当でした。★ ★今回片付けます。★

★★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/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 だけ取り残されています。★

やること

★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 — 記録

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

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. ★実装者へ — 特に踏みやすい落とし穴★

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