Cloudflare Pages 89プロジェクトの公開URLを実際に取得し、ページ内リンク507本すべての生死を照合しました（打ち切り0件）。死にリンク候補68件を仕分けた結果、実害21件・仕様/誤検知47件。最大の1件は、OTA予約ゲストが見る5施設のご案内で『デジタルキーの使い方を見る →』の遷移先が存在せず、しかも404にならず表紙に戻るため誰も壊れていると気づけない状態です。
Otakeさんにしか答えが無いものだけ。ここをお願いします。
OTA予約ゲスト向けの「デジタルキーの使い方」を、5施設で出しますか要判断
OTA予約ゲストの入室手順・5施設館山・京都・渋谷・軽井沢・南房総 の Pre-Stay Letter「ご到着とご入室」章に『デジタルキーの使い方（暗証番号の受け取り・解錠手順）を見る →』というリンクがありますが、遷移先 chapters/key.html は存在しません。しかも 404 ではなく表紙が 200 で返るため、ゲストは押しても表紙に戻るだけで、エラーにも見えません。原因は生成元 scripts/build_pre_stay_letter.py が body_key を import しておきながら章立て（CHAPTERS_META）に key を入れていないこと。会員向けの逗子葉山だけは別ビルダーで、Remote Lock 章が正常に存在します。
推奨 ① key章を生成して出す（会員版と同じ内容をOTA版にも） — ②は1章に情報が詰まりすぎて当日スマホで読めない、③は入室で詰まった時の逃げ場が公開面から消える。①なら会員版に実体があるので流用でき、追加の原稿執筆が要らない
無回答なら ①で章を生成し、5施設に再デプロイします
この棚卸しを、どこまで恒久監視に育てますか要判断
週次の実行コストと、鳴る音の純度今回のやり方（本番の実物を全部取りにいく）は「死にリンク」は捕まえますが、逗子葉山の型（消えたリンク）は捕まえません。それを捕まえるには、Frank の週次健診に入れた check_deploy_links と同じ型 — 生成元 config から『在るはずのリンク』を自動導出して本番と照合する — を、カレンダー12施設の外へ広げる必要があります。広げる範囲がコストを決めます。今回は89プロジェクトで509リクエスト・実行3分ほどでした。
推奨 ① 外向き（ゲスト/オーナー/会員が見る約40件）だけ週次で見張る — ②は社内ハブの死にリンクまで毎週鳴り、Frank の指摘が薄まって『どうせ鳴っている』状態を作る（実際、今回の実害21件のうち16件は社内向けで実害が小さい）。③はゲストが見る面に検知器が無いまま戻る
無回答なら ①で、guide / guide-ota / cal / owner / club 系だけを Frank の週次健診に足します
私が決めました。違うものだけ触ってください（無操作＝この通り進めます）。
社内ハブ yamato-admin の死にリンク11本を、実バインドから出し直す追認
社内のみ・30分推奨 ① 実バインド導出に張り替える — ②は同じドリフトをもう一度作る（今回まさにそれが起きた）。yamato- という空スラグのリンクが出ている点からも、生成側が実物を見ていないのが根本
無回答なら ①で実バインド導出に張り替えて再デプロイします
消えたプロジェクトへの参照1本を削除する追認
社内アーカイブのみ推奨 ① 削除する — ②はQ1の結論が出るまで張り替え先の中身が確定しない。死んだリンクを残すより先に消す方が、次に見た人が実在すると誤解しない
無回答なら ①で削除します
公開ページに残った開発PCのローカルパスへのリンク4本を解除する追認
個人用ページのみ推奨 ① リンク解除してテキスト表記に — ②だと押せてしまい、押した先が表紙に戻るだけなので毎回同じ徒労が発生する
無回答なら ①でテキスト表記に落とします
入口が404の2プロジェクトの扱い追認
オーナー配信の入口・要1行確認推奨 ① 据え置き＋退役扱い（推奨） — ③は誰も参照していない2件に時間を使うことになる。ただし owner-reports が『トークン付きURLで実際に開ける』ことだけは、次にオーナーレポートを配信する時に必ず実物で確認します
無回答なら ①で据え置き＋退役扱いにします
存在しないパスに「表紙を200で返す」設定をやめる追認
guide-ota 5件・要検証推奨 ① 404を返す設定に戻す — ②はゲストには親切に見えて、実際には『壊れていることを永久に隠す』装置として働く。①にすれば Frank の見張りも人の目も同時に効くようになる。※この挙動が _redirects 由来か Worker 由来かは未特定なので、実装時に現物で確かめます
無回答なら ①で404を返す設定へ戻します（Q1の対応と同じ回で）
実装・反映済みの事後報告。読むだけで大丈夫です。
89プロジェクトを全数、実物で照合しました（打ち切り0件）済
公開URL 89件を取得 → 各プロジェクト内を1階層辿って計321ページ → そこから見つかったリンク507本すべての生死を確認（合計509リクエスト・同時6・レート配慮あり）。上限は700件に設定していましたが到達せず、確認できなかったリンクは0件です。取得できなかったのは otake-handoff の2階層目25ページと各ガイド1ページずつ（1プロジェクト10ページの上限による）で、これらは階層が深いアーカイブ側です。
推奨 ① 範囲はこれでいい
死にリンク候補68件のうち46件は、正常として落としました済
内訳：index.html への相対リンク33件（/ と同じ中身が返るので正常）／Googleスプレッドシート4件（ログイン必須の401・正常）／Airbnb 7件（連続アクセスによる429・リンク自体は生存）／Booking.com 2件（bot対策の202・同上）。加えてルート異常5件のうち3件も正常でした — yamato-opemi は agenda.html への転送ページ、azabudai-wine-cellar と yamato-guide-karte は意図した認証ゲートです（社内統一パスでは通らない別体系）。
推奨 ① この仕分けでいい
回答テキスト（自動生成・差分だけ出ます）
下の枠内で Ctrl+A → Ctrl+C でコピー