| 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 は「初見の人が全添付物の正体を判別できるか」を出荷前チェックに入れる。
手順（毎回）
- デザイン / タイポ / レイアウト / 色に触るなら、着手前に該当スキルを Read する（Skill-First Gate、CLAUDE.md §0）。中央揃えの本文・フッター、装飾区切り、左バー選択などはスキルで否定されている。
- 変更は上のサーフェス全部へ同時適用する。1つ直したら残りも直す。
- 出す前に 旧表現を全リポ grep して残存ゼロを確認する。1件でも残っていたら未完。ja / en 両方を対象にする。
- 非テキスト派生物を明示列挙して再生成する（超重要・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）。
- 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 両方）。
- 同名アセットを更新したら
?v= キャッシュバスターを上げ、<img> の width / height を再生成後の実寸に合わせる。実寸は sips -g pixelWidth -g pixelHeight で取る。ずれると CLS 予約枠が狂って画像が歪む。バージョンクエリは毎リリースのスクショ再生成時に一緒に上げる（放置すると却って永続キャッシュになる）。
- 変更後は指摘される前に自分で
/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 / スクショを漏らす。
