propagate-changes-to-all-surfaces

name	propagate-changes-to-all-surfaces
description	用語・概念・UI・コピーを1箇所変えたら、全サーフェス（アプリ UI・トレイ・docs ja/en・README ja/en・LP ja/en・スクリーンショット・OG 画像）へ同時反映し、旧表現を全リポ grep で残存ゼロ確認する。スクショ等の非テキスト派生物は grep に映らないので明示列挙して再生成する。UI・用語・コピーを変えたら発動。

変更は全サーフェスへ伝播する

1つのサーフェスだけ直して他を放置すると、ユーザーには「書いてあることが嘘」に見える。 用語・概念・UI・コピーを1箇所変えたら、必ず全サーフェスへ同じ変更を伝播し、旧表現の残存を grep でゼロにしてから出す。 関連: docs_impl_consistency_audit（/audit-consistency）、csw_product_canon、CLAUDE.md §6.3（Global Terminology Enforcement）。

いつ発動するか

• 用語・環境名の例・オンボーディング説明・ボタンラベル・機能主張・切替 / 起動モデル・コピーを変えたとき。
• UI のラベル・レイアウト・見た目を変えたとき（スクリーンショットが古くなる）。

サーフェス一覧（変更時は上から順に全部点検する）

• crates/desktop/ui/（index.html / main.js / style.css）
• crates/desktop/src/main.rs（トレイ文言）
• docs/SPECIFICATION.md / docs/USER_GUIDE.md(JA) / docs/USER_GUIDE_EN.md(EN)
• README.md（EN + JA。tagline だけでなく手順・機能説明も）
• website/index.html(EN LP) / website/ja/index.html(JA LP)
• website/assets/ のスクリーンショット（scripts/appshot/gen-screenshots.mjs で ?lang= により ja / en を再生成）
• OG / Twitter カード画像
• GitHub Release ページ（ユーザー向け面なので日英併記）。3 つに分けて点検する: (1) 本文の「変更内容（What's changed / Features・Fixes）」= CHANGELOG 由来で既定は日本語のみ。リリース時に英語の変更内容を Release 本文へ併記する（手順・ガードは core_pr_merge_checklist の「リリース PR のマージ」節）。(2) 本文の「添付ファイルの説明」= .github/release-readme.md（日英併記済み）を release.yml の sbom ジョブが毎リリース展開して追記。(3) 添付の RELEASE-README.md。なお CHANGELOG.md 自体とコミット subject/body は開発者向け面なので日本語のままでよい（線引きは CLAUDE.md §コーディング規約 1「日英対応の線引き」）。

配布物を増やす・減らすときの追加ルール

リリースに添付するファイルを足す・外す・改名するときは、上の 2 テンプレートを同じ PR で更新する。説明のない新しいファイルがリリースページに並ぶと、事情を知らない人には漏洩や事故に見える（2026-07 に SBOM の json で実際に起きた）。ファイル一覧に変更が入る PR は「初見の人が全添付物の正体を判別できるか」を出荷前チェックに入れる。

手順（毎回）

1. デザイン / タイポ / レイアウト / 色に触るなら、着手前に該当スキルを Read する（Skill-First Gate、CLAUDE.md §0）。中央揃えの本文・フッター、装飾区切り、左バー選択などはスキルで否定されている。
2. 変更は上のサーフェス全部へ同時適用する。1つ直したら残りも直す。
3. 出す前に 旧表現を全リポ grep して残存ゼロを確認する。1件でも残っていたら未完。ja / en 両方を対象にする。
4. 非テキスト派生物を明示列挙して再生成する（超重要・grep の盲点）。テキスト面（app / docs ja-en / LP ja-en / README）は grep で残存確認できるが、スクリーンショット・図・OG 画像は grep に一切映らない。だから「この画面を写した画像はどれか」を毎回明示的に自問しないと永遠に取り残される。UI のラベル / レイアウト / コピーを変えたら、該当スクショを再生成して同一 PR に含める。crates/desktop/ui を触ったら、変更が特定の画面に写るか自分で判断せず、必ず node scripts/appshot/gen-screenshots.mjs で 8 枚を再生成し、差分を確認して同一 PR に入れる（再生成は既定状態の検証機会でもある）。使い捨ての headless キャプチャで描画を確かめただけで「検証済み」と扱わない。出荷される website/assets を再生成することが検証。この漏れは CI ゲート Verify screenshots（.github/workflows/verify-screenshots.yml）が機械的に止める: crates/desktop/ui を変えた PR が website/assets/*.png を更新しないと落ちる（純粋に非視覚の変更のみ、コミットに Skip-appshot: <理由> を足して外す）。再生成したら ?v= バスターと width/height を実寸（sips）に合わせて LP ja/en を更新する（step 6）。
5. OG 画像を確認項目に入れる。(a) 中身: OG カードはアプリのスクショではなく現行メッセージを写した独立デザイン。メッセージ / モード名 / コピーを変えたら再生成する（UI だけの変更なら中身は不変で再生成不要）。(b) 読み込み: og:image / twitter:image は絶対 https URL・1200×630・summary_large_image。SNS / メッセージアプリは URL 単位で強くキャッシュするので、画像を差し替えたら URL に ?v=<version> を付けて新 URL にし再取得させる（スクショの <img> と同じ。og / twitter 両方・ja / en 両方）。
6. 同名アセットを更新したら ?v= キャッシュバスターを上げ、<img> の width / height を再生成後の実寸に合わせる。実寸は sips -g pixelWidth -g pixelHeight で取る。ずれると CLS 予約枠が狂って画像が歪む。バージョンクエリは毎リリースのスクショ再生成時に一緒に上げる（放置すると却って永続キャッシュになる）。
7. 変更後は指摘される前に自分で /audit-consistency（docs_impl_consistency_audit）を回し、全サーフェス横断の用語・トーン・UI モデル整合を点検する。最終検証にも1観点として必ず入れる。

プロダクト全体で検証する（diff でなく）

• 「差分が入ったか」でなく「プロダクト全体が一つの正しい姿か」で検証する。変えた画面と、それを埋め込む面（LP のスクショ等）を実際にレンダして見比べる。diff の確認で止めない。
• 主張と実装の一致を実行時挙動で確かめる。サーフェス整合は「製品が実行時に実際にできること」まで含む。docs / LP が「日英対応」「〜モードあり」等を謳うなら、その主張の実体（アプリの i18n・そのモードの実装）がアプリ本体にあるかをコード / 実機で確認する。派生物（スクショ・docs）だけで「対応済み」と判断しない。スクショや docs は主張の証拠であって実装ではない。派生物だけで主張を満たすと、偽物を作ってしまう。

よくある取りこぼし

• README（ja / en）: tagline だけ直して手順・機能説明・GUI ワークフローの伝播を漏らす。
• スクリーンショット: ボタン名 / レイアウト / オンボーディング文言を変えたのに撮り直さず、LP / docs に旧 UI が残る。
• OG 画像: メッセージを変えたのに再生成・?v= bump を忘れ、SNS が旧カードをキャッシュし続ける。
• 相手言語: 片方の言語だけ直し、もう片方の LP / docs / スクショを漏らす。