指示書AJ — 要レスキューの見せ方を直し、サイドバーのスクロールを独立させる

作成: 2026-09-15 / ブランチ: develop / 前提: 指示書AI 完了（D-135 / D-136）

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

D-Watch の実装をお願いします。ブランチは develop です。

■ 最初に読むもの（この順で、全部）
  1. CLAUDE.md（全文。特に §0-3 フォント / §5 モックが正 / §7 禁止事項 / §9 実装規約）
  2. docs/handoff/指示書AJ_要レスキューの見せ方とサイドバーのスクロール.md（全文）
  3. docs/handoff/指示書AI_要レスキュー店舗と詳細ログの期間上限.md の §6-5
     （今回直すのは、ここで私が指定を誤ったところです）

■ やること
  指示書AJ の 段階1 から 段階4 までを、★番号順に★実行してください。
  前回、段階の順序が前後しました。今回は番号順でお願いします
  （段階2 はサイドバーの見た目に関わるので、段階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/dashboard/aggregate.ts / lib/judge/advice.ts / lib/db/prisma.ts

■ 絶対にやらないこと
  ・閾値・件数のハードコード — 必ず lib/config/index.ts に置いてください
  ・新しい CSS に font-family を書くこと
    （日本語フォントが落ちて漢字が中華字形になります）
  ・判定ロジック（lib/judge/rescue.ts）を変えること
    ★今回は「判定」ではなく「見せ方」だけを直します★
  ・仕様が不明なところを推測で実装すること

■ 動作確認
  ★テストDBのデータは 2026-09-13 で終わっています★。
  /api/dashboard?date=2026-09-13 と ?date=2026-09-12 で確かめてください。
  期待される結果は指示書AJ の §6 に書いてあります。
  ★段階2（サイドバー）は画面を見ないと確かめられません★。
  §6-3 に、目視以外の確かめ方（getComputedStyle / scrollTop）を書いてあります。

■ 終わったら
  ・段階ごとのコミットハッシュ
  ・tsc / lint / test の結果（テスト本数も）
  ・★§6 の動作確認を実際に行った結果★（前回はここが素通りになりました）
  ・指示書どおりにできなかったところと、その理由
  ・判断に迷って自分で決めたところ（あれば全部）

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

★指示書AI の実装は合格でした。★ 3本の査読が独立に検算し、★実装の誤りは1件も出ていません★。

★直すのは、私（監督）が指示書AI §6-5 で指定を誤った1箇所です。★

§6-5: 「並び＝連続問題日数の降順」「件数＝上限を設ける。詳細ログに揃えて5件」

★この2つの組み合わせで、急落だけで該当する施設が構造的に一覧から落ちていました。★

★加えて、ユーザーから新しい要望が1件★来ています（段階2）。

★★実装者に落ち度はありません。指示書AI §6-5 のとおりに作られています。★★

1. ★実データで何が起きているか（実測）★

テストDB（133.125.238.144:13306 / clean_watch）で確認した事実です。

1-1. 上限で切られている

★消えた4件は、すべて completion_drop 単独★でした。

急落 = 「昨日まで正常 → 今日落ちた」
     → consecutive_problem_days は 1〜2 にしかならない
     → 連続日数の降順で並べると、必ず L3（3以上）の後ろ
     → L3 が5施設ある日は、急落が1件も出ない

★★ユーザーがわざわざ新設を指示した条件が、実データでほぼ機能していません。★★

1-2. 件数の表示が、切ったあとの数になっている

components/features/dashboard/RescueRequiredCard.tsx:85

{t("{n}件").replace("{n}", String(items.length))}

items は切ったあとの配列です。★7件該当していても「5件」と出ます。★ ★運用担当は5件を全件として読みます。★ ★例外もテスト失敗も出ません。★

2. ★ユーザーが決めたこと（2026-09-15。原文）★

2-1. 件数

①上限は設けずに、表示は5件、もっと表示のようなのもので全件

★確定:★

★★API 側の上限（RESCUE_LIST_LIMIT）は撤廃します。★★ ★これで「切ったのに気づけない」問題が根から消えます★ — ★切らないからです。★

★件数が青天井にならないか★: なりません。★要レスキューは施設ごとに最大1行★なので、 ★施設数（P1 の想定で200件程度）が上限★です。★ページ送りは要りません。★

2-2. 評価日の古さ

②これも上限無し

★確定: 評価日が何日前であっても出す。足切りをしない。★

★背景★: 「当該日以前で最も新しいスケジュール存在日」で判定するため（指示書AI §1-5）、 ★清掃予定が止まった施設は、遡り幅いっぱい（既定217カレンダー日 ≒ 7か月）出続けます★。

実測（今日 2026-09-15、日付なしで /api/dashboard）:

summary          success 0 / failed 0 / not_executed 0 / success_rate null
rescue_required  5件（evaluated_on は 2026-09-12 と 2026-09-13）

★★ユーザーはこの挙動を承知のうえで「上限無し」と決めました。★★ ★足切りの実装はしません。★

★★判断の根拠（記録に残すこと）★★: ★困っている店舗が、時間が経ったという理由だけで 一覧から消えるほうが危ない★。★カードには既に「判定日」が出ている★ので （RescueRequiredCard.tsx:116）、★いつの状態かは読み手が判断できます★。

3. ★触ってはいけないもの★

★★禁止★★: git add -A / 生SQL / 閾値・件数のハードコード / スキーマ変更 / ★新しいCSSへの font-family★ / 推測での実装

4. 段階1 — 上限を撤廃し、画面で「もっと表示」する

4-1. 設定値

lib/config/index.ts:81

export const RESCUE_LIST_LIMIT = 5 as const;

★この定数は「APIが返す上限」ではなくなります。★ ★画面の初期表示件数に役割を変え、名前もそれに合わせること★（例: RESCUE_INITIAL_VISIBLE）。

★★名前を変えずに意味だけ変えないこと★★ — ★次に読む人が「APIの上限」だと思い込みます。★

docstring に書くこと:

★これは API が返す件数の上限ではない★（上限は設けない。ユーザー指示 2026-09-15）。
★画面で最初に見せる件数であり、「もっと表示」で全件が開く★。
★API 側で切らない理由★: 切ると「切られたこと」に運用担当が気づけないため
（指示書AJ §1-2。実データで7件中2件が黙って消えていた）。
★件数が青天井にならない理由★: 要レスキューは施設ごとに最大1行なので、
施設数が自然な上限になる。

4-2. データ層 — ★上限を外す★

lib/db/rescue-mapping.ts:156-161

• ★.slice(0, limit) を外す★
• ★buildRescueRequired() の limit 引数を外す★（★呼び出し側から渡さない★）
• ★sort は残す★（§4-3 で並び順を変える）

★総数を別キーで返す必要はありません★ — ★配列の長さがそのまま総数★になります。 ★rescue_required_total のようなキーを足さないこと。★

4-3. ★並び順に「理由の数」を入れる★

★現在★: consecutive_problem_days の降順 → facility_id の昇順 ★変更後★:

1) reasons.length の降順          ← ★複数の条件に当たる施設ほど重い★
2) consecutive_problem_days の降順
3) facility_id の昇順             ← ★安定した順序にするため★

★なぜ理由の数を最優先にするか★を docstring に書くこと:

★連続日数だけで並べると、急落（連続日数が浅いのが当たり前）が下に沈む★
（指示書AJ §1-1）。理由の数を先に見ることで、
「L3 かつ急落」の施設が「L3 だけ」の施設より上に来る。
★★これでも「急落だけ」の施設は下のほうに来る★★ —
そこは上限を撤廃し、画面で全件を開けるようにしたことで補っている。

★★「急落だけ」の施設が上位に来るわけではありません。正直に書くこと。★★

4-4. 画面 — ★初期5件、「もっと表示」で全件★

components/features/dashboard/RescueRequiredCard.tsx

要レスキュー店舗  7件           ← ★受け取った配列の長さ（＝総数）★
（… 5件ぶんの行 …）
もっと表示（あと2件）           ← ★押すと全件が開く★

• ★件数の表示は items.length（＝総数）のまま★でよい。★上限を外したので、これが正しい数になります★
• ★初期表示は先頭 RESCUE_INITIAL_VISIBLE 件★
• ★items.length > RESCUE_INITIAL_VISIBLE のときだけ「もっと表示」を出す★
• ★開いたあとは「閉じる」に切り替える★（★開きっぱなしで戻せないのは不便★）
• ★状態は画面のローカル state でよい★。★URL に持たせない★ （★D-131 申し送り⑤「ページ番号を URL に持たせる件」と混ざらないようにする★）
• ★文言は t() を通すこと★（JP/EN の器。§9.6）。★数値は画面側で差し込む★（D-111）
• ★lib/i18n.ts に新しい語を足すこと★（「もっと表示」「閉じる」など）

★★0件のときカードごと消さない★★ — 指示書AI の実装者判断（D-135）を維持すること。 ★「確認した結果0件だった」と「表示が出ていない／壊れている」を区別できる必要があります。★

4-5. 期待値表

★データ層（上限が無いこと）★

★1-2 が今回の眼目★です。★実データで確かめられます（§6）。★

★並び順★

★画面★

★1-9 と 1-10 の両方をテストに入れること★（> と >= の取り違えが通らないように）。

★★画面のテストは vitest.config.ts の include が lib/** と app/** なので走りません★★（D-120 項2）。 ★「何件表示するか」を決める部分は lib/ 側の純粋関数に切り出せば、テストできます。★ ★切り出すかどうかは実装者判断★ですが、★切り出さないならその旨を記録に残すこと★。

5. 段階2 — サイドバーのスクロールを本文と独立させる

5-1. ユーザー指示（原文）

サイドパネルはメインパネルとスクロールは独立させてください

★ユーザー確定（2026-09-15）: 案A（シェルを画面高に固定し、左右それぞれを独立させる）★

5-2. ★今どうなっているか（実測）★

.shell  { min-height: 100vh }   ← 高さが内容で決まる
.main   { overflow: auto }      ← ★書いてあるが効いていない★

.shell が min-height なので flex 子の .main が内容分まで伸び、 scrollHeight === clientHeight になってスクロールコンテナになりません。

実測（components/layout/AppShell.module.css の宣言を実ページ上で再現して測定）:

★下にスクロールすると、サイドバーは色のついた空の柱になります。★ ★メニュー・テーマ切替ボタン・フッター「DFA運用担当」が全部画面外へ流れます。★

5-3. 変更

components/layout/AppShell.module.css のみ。★JSX の構造変更は不要★です （aside と main は既に兄弟です）。

.shell {
  display: flex;
  height: 100vh;    /* ★min-height から height へ★ */
  height: 100dvh;   /* ★dvh 対応ブラウザではこちらが勝つ（モバイルのURLバー分）★ */
  ...
}

.sidebar {
  ...
  overflow-y: auto;   /* ★1行追加★ */
}

/* .main の overflow: auto はそのまま。これで初めて効く */

★height: 100vh を先に、height: 100dvh を後に書くこと★（2段指定）。 ★100dvh を知らないブラウザは後者を無視して前者が残ります。★

5-4. ★サイドバー自体のスクロールが要る理由★

★これは将来の話ではなく、もうすぐ起きます。★

今のメニューの高さ       約591px
点検記録を戻すと         約628px
総清掃面積の画面を足すと  約665〜699px

★ノートPCのブラウザ内寸は600〜700px★です。★overflow-y: auto が無いと、 下のメニューに手が届かなくなります。★

5-5. ★★印刷の退避を必ず入れること★★

★height: 100vh にすると、ブラウザの「印刷」で1画面分しか出ない可能性があります。★

@media print {
  .shell { height: auto; }
  .main  { overflow: visible; }
}

★これを入れ忘れると、印刷したときに初めて気づきます。★ ★★画面では絶対に分かりません。★★

5-6. ★画面遷移で本文が先頭に戻るか、必ず確かめること★

Next.js は遷移時に document.documentElement.scrollTop = 0 を試し、 ダメなら scrollIntoView() に落ちます。 ★.shell を height: 100vh にすると前者が効かなくなり、後者頼みになります。★

★実機で確かめること★（§6-3 の (5)）。★動かなければ報告してください。★ ★勝手に scrollTo を画面に足さないこと★ — ★アプリコードに scrollTo / scrollIntoView / scrollY は現在1件もありません★。1つ足すと、全画面の遷移の挙動を1箇所で背負うことになります。

5-7. ★スマートフォン幅は今回スコープ外★

★実測: 375px 幅でサイドバーは 220px のままで、本文は 155px に潰れます。★ ★横スクロールは出ません。★

★★今回の変更は、これを改善も悪化もさせません。★★ ★直したくなっても、今回は触らないこと★ — ユーザー指示はスクロールのみで、 ★レイアウトを変えるとモックからさらに外れるため、別の判断が要ります★。 ★申し送りに書くこと。★

5-8. ★モックから意図的に外れることの記録★

d-watch-mock.jsx:426 minHeight: "100vh" / :429 サイドバー（position 指定なし）/ :468 overflow: "auto"。

★★モックにも同じ overflow: "auto" が、同じ理由で効かないまま置かれています。★★ ★実装はモックの 1:1 移植で、外れていません。★ ★今回が「外れる」最初の変更です。★

CLAUDE.md §5 は「モックが画面レイアウト・文言・遷移の正」と定めています。★前例が2件★:

★同じ作法を踏襲すること:★

1. ★d-watch-mock.jsx は1文字も書き換えない★
2. docs/decisions.md に ★「CLAUDE.md §5 の例外。ユーザーの明示指示（2026-09-15）に基づく」★ と記録し、★指示の原文を引用する★
3. ★AppShell.module.css の該当箇所の直上に、理由コメントを残す★ — ★★書かないと、次にモックと突き合わせた人が「モックと違う」と判断して戻します★★

6. ★動作確認（前回ここが素通りになりました）★

★★前回の実装では、実データでの確認が行われませんでした。★★ ★記録に「本作業では実施していない」と正直に書かれていたので分かりましたが、 その結果、上限で2件消えている問題は査読まで見つかりませんでした。★

★今回は必ず行い、結果を報告してください。★

6-1. 前提

.env.local は既にテストDB（133.125.238.144:13306 / clean_watch）を向き、USE_FIXTURES=false です。 ★★テストDBのデータは 2026-09-13 で終わっています。今日の日付では数値カードが全部0になります。★★

6-2. 確かめること

GET /api/dashboard?date=2026-09-13

GET /api/dashboard?date=2026-09-12

GET /api/dashboard        （日付なし＝今日 2026-09-15）

★6-9 はユーザーが承知のうえで決めた挙動★です（§2-2）。 ★★「0件になるべきでは」と考えて足切りを入れないこと。★★

6-3. 段階2（サイドバー）の確かめ方

★★画面のログインにはアクセストークンが要ります。★★ ★ログインできる場合は、縦に長い画面（/detail-log で期間を広げる）で確かめてください。★

ブラウザのコンソールで:

// (1) スクロールコンテナがどれか
const info = e => { const c = getComputedStyle(e); return {
  overflowY: c.overflowY, position: c.position, height: c.height,
  clientH: e.clientHeight, scrollH: e.scrollHeight,
  scrollable: e.scrollHeight > e.clientHeight + 1 }; };
({ html: info(document.documentElement),
   sidebar: info(document.querySelector('aside')),
   main: info(document.querySelector('main')) })

★合格条件★: main.scrollable === true ★かつ★ html.scrollable === false

// (2) 独立していることの証明
const m = document.querySelector('main'), a = document.querySelector('aside');
m.scrollTop = 500;
({ mainTop: m.scrollTop, docTop: document.documentElement.scrollTop,
   brandVisible: a.querySelector('div').getBoundingClientRect().top >= 0 })

★合格条件★: mainTop === 500 ★かつ★ docTop === 0 ★かつ★ brandVisible === true （＝★本文を動かしてもロゴが画面内に残っている★）

// (3) メニューが溢れたときサイドバー内だけが動く
//     先にブラウザの内寸を 1280×600 程度にすること
const a = document.querySelector('aside');
a.scrollTop = 9999;
({ asideScrollable: a.scrollHeight > a.clientHeight + 1, asideTop: a.scrollTop,
   mainTop: document.querySelector('main').scrollTop })

★合格条件★: asideTop > 0 ★かつ★ mainTop が変化しない

// (4) テーマ切替が壊れていない（🌙 を押してから）
({ theme: document.documentElement.dataset.theme,
   asideBg: getComputedStyle(document.querySelector('aside')).backgroundColor })

★合格条件★: ダーク rgb(26,35,50) ⇄ ライト rgb(255,255,255) で切り替わる

★(5) 画面遷移★: 本文を下までスクロール → サイドバーのリンクで別画面へ → ★document.querySelector('main').scrollTop === 0 になるか★

★(6) スマホ幅★: 375px にして ★横スクロールが出ていないこと★ （document.documentElement.scrollWidth === clientWidth）

★(7) 「もっと表示」★: 要レスキューが6件以上ある日で、★押すと全件出て、「閉じる」に変わるか★

★★ログインできない場合は、そう報告してください。★★ ★推測で「動いているはず」と書かないこと。★

7. 段階3 — 指示書AI §12 の期待値表を直す

★私が書いた期待値が間違っていました。★ ★直さないと、次に読む人が「実装が壊れている」と誤判定します。★

docs/handoff/指示書AI_要レスキュー店舗と詳細ログの期間上限.md の §12:

★★訂正であることが分かるように書くこと。★★ ★元の数字を消して上書きしないこと★ — ★「4件と書いていたが誤り。正しくは5件」という形にする★。 ★次に読む人が、この指示書を信じて数を合わせにいく可能性があります。★

★あわせて §6-5（並びと件数の指定）にも、★★指示書AJ で撤回した旨★★を1行足すこと。★

8. 段階4 — 記録

8-1. docs/decisions.md

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

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

★docs/decisions.md は番号順に並んでいません。★ 末尾を見て最大値を判断しないこと。

書くこと:

• ★API 側の上限を撤廃した理由★（★切ったことに気づけないのが問題だった。実データで7件中2件が黙って消えていた★）
• ★件数が青天井にならない理由★（施設ごとに最大1行）
• ★並び順に「理由の数」を入れた理由★と、★★それでも「急落だけ」の施設は下に来ること★★
• ★画面で初期5件＋「もっと表示」にしたこと★
• ★★評価日の古さに上限を設けないと決めたこと★★ — ★ユーザー判断（2026-09-15「これも上限無し」）。 原文を転記する★。★理由（困っている店舗が時間経過だけで消えるほうが危ない／カードに判定日が出ている）も書く★
• ★サイドバーのスクロールを独立させたこと。CLAUDE.md §5 の例外であること。★ユーザー原文を転記★
• ★印刷の退避を入れた理由★
• ★★指示書AI §6-5 と §12 が誤っていたこと★★（★監督の誤りとして残す★）

8-2. docs/handoff.md に追記

• ★スマートフォン幅（375px で本文が155px）は未対応のまま★
• ★「急落だけ」の施設が下に来る構造は残っていること★ — ★施設数が増えて一覧が長くなったら、並び順を見直す余地がある★
• ★評価日が古い施設が出続けること★ — ★ユーザー判断で上限を設けていない。 実運用で「古い行が邪魔」という声が出たら再検討する★
• ★画面遷移時のスクロール先頭復帰が Next の scrollIntoView 経路に依存するようになったこと★

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

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