ui-mock-fidelitylisted

# ui-mock-fidelity — UI モック忠実性の機構 承認済みモックと UI 実装を **1ミリもずらさず同一** にするための規律。 契機 = native/plugin（dsp）で反復した「承認 mock ≠ 実装」事故（雰囲気移植で "近い" 止まり）。 実証 = MUEDlim UI（CSS 実値 1:1 移植 → conductor overlay/pixel-diff で 100% verify → notarized build sha `a832976a…` bit-identical）。 正本 = このスキル。課ローカル memory（dsp `feedback_render_verify_visual_fidelity` / `feedback_design_to_native_exact_pixel_transplant`）と差分が出たら **このスキルを正** とする。 --- ## 0. 適用境界（最初に判定する — 官僚化 creep 回避） **IN（本機構の対象）**: 承認モックが**存在する/すべき**作業。 - 新規 UI 面の実装 - re-skin（既存 UI の視覚的な貼り替え） - 視覚的再設計 **OUT（対象外・既存 Tier/review 規律のまま）**: - 既存実装の**微修正**: コピー1行の変更 / padding・margin 微調整 / バグ修正 - モックが承認物として存在しない・不要な作業 > 全課に薄く官僚を撒くのが目的ではない。**起きている native/plugin を厳格化**するのが目的。 > pattern は native/plugin UI（dsp）に集中し、web UI（React）は該当が薄い（§7 較正）。 --- ## 1. rule 1 — pinned mock = 単一の正 - UI dispatch は���ず**承認済みモックを pin** して行う。**モック無しの UI 実装依頼を禁止**。 - pin は **filename / hash 等の一意識別子**で行う。**「案A」「案B」等の曖昧ラベル禁止** （段階で再利用され衝突する。実際に初稿が「案A」参照で衝突した＝この rule の live 例）。 - 例: `muedlim_ui_lufs_hero_mockA_v2_20260713.png`（○） / 「案A の方向で」（×）。 --- ## 2. rule 2 — 数値仕様抽出（雰囲気移植 禁止） モックから以下を**数値表**として抽出し、そのまま移植する。**「雰囲気で寄せる」を禁止**。 - 座標（x/y）・寸法（w/h）・アスペクト比 - 色（hex） - フォント（種類・weight・size・字間） - 余白（padding / margin / gap） > ★**モックが自作 HTML/CSS なら、実 source 値を 1:1 移植する**（eyeball 不要で exact 到達可能 > ＝dsp ��� core insight）。「同じ CSS でやっていて��じものを使えない環境はあり得ない」（kimny）。 --- ## 3. rule 3 — 完了報告に diff 必須添付 完了報告には **render × mock の並置 + overlay / pixel-diff** を必須で添付する。 | 種別 | 期待 | |----