BookingDBのライブ数値と施設の正本から、施設別オーナーレポートを毎回生成する読み取りビュー。
SoT → 共通データ層 → ビルダ → 多階層サイト → capability-URL 配信 までの全体像。
手で直すのは左の SoT だけ。数値は同期DBから毎回ライブ算出され、ビルダが4ページの自己完結HTMLを生成し、capability-URLで配信される。
facilities/{slug}/_sot/scripts/occupancy/booking_data.py の load_bookings()data.py — 稼働/受取/ADR/RevPAR/前年比/推移/流入(会員OTA直接)/キャンセル率/リードタイム/カレンダー/タイムラインcharts.py — inline SVG(二軸推移・積み上げ・ドーナツ・年間ヒートマップ)render.py — 共有CSS+共通シェルで多階層HTMLbuild.py — CLI・トークン発行・画像複製・--all一括・--deployyamato-owner-reports.pages.dev/<token>/ — 推測不能トークンをパスに埋込(=鍵)・noindex数値は Markdownに焼き込まない。レポートHTMLは BookingDB+facility.md から 毎回ライブ算出する読み取りビュー。
だから「いつ開いても最新」で、二重管理が起きない。手で直すのはSoTだけ、HTMLは常に派生物。
予約・稼働・売上・内訳・傾向はすべてライブ連携済み。唯一ライブでないのが「施設の予定」(オーナー滞在・工事)。
facility.md の ## Owner & Events が予定の唯一の入力元。現在はサンプル3件。
ここに Slack → Claude → facility.md 更新 の経路を通せば、カレンダーとタイムラインに実予定が反映され、システムは「完全ライブ」になる。
パイプラインは施設非依存。新施設は data.SLUG_REGISTRY に物件名を1行、build.ASSET_SETS に写真を足すだけ。build.py --all --deploy が全施設を一括生成・配信する。
京都(The 禅 SPA Kyoto Suite)・渋谷(The SAUNA Escape Shibuya)等。facility.md と写真が揃えば即ページ化。
scripts/occupancy/booking_data.py — 共通データ層(テスト除外・会員判定)scripts/owner_report/data.py — 全指標・トレンド・カレンダー・予約一覧scripts/owner_report/facility_md.py — facility.md+Owner&Eventsscripts/owner_report/charts.py — inline SVG 各種scripts/owner_report/render.py — 共有CSS+4ページscripts/owner_report/build.py — --facility / --all / --deploy / --auditfacilities/{slug}/_sot/facility.md ・ assets/facilities/{slug}/outputs/owner/*.htmloutput/deploy/owner_reports/<token>/ → Cloudflare Pages土台は固まった。次の打ち手の候補(この図を見ながら選ぶ)。