Design Decisions — mirror-me — Variant A

Surface: /app/mirror/[managerId]  |  Round: 1  |  Picked variant: A (保守的 / visual cleanup only)  |  Generated by: kashi-ui-mockupper  |  Date: 2026-05-27
このドキュメントの読み方: Variant A は「IA を一切変えず、 design_system_v1 のトークンを全 component に正しく適用するだけ」 の提案。 Justine から見ると 「現状の Kashi mirror-me を design system に揃えただけ」 が一目で分かる状態を目指している。 Variant B (中庸) との視覚的違いを最後 (§5) で明示し、 末尾 §8 の Justine 判断ポイントで「A で十分か / B が必要か」 を決められる構造。

1. Variant A の本質 — IA 不変、 token 適用のみ

決定: 現状の Kashi mirror-me ページの IA / ナビゲーション / セクション順序を 100% 維持。

具体的には以下 14 要素を、 現状と同じ順序・同じ階層構造で表示している:

  1. H1 「Manager Mirror」 + back-link (/app/ceo へ戻る — 現状のまま、 変更しない)
  2. RevealNamesButton 行 (Manager-self では空、 Admin/CEO で表示)
  3. CoverageStrip (comparable / total / excluded / last updated)
  4. TimeWindowToggle (30/90/180)
  5. Evidence Grade Banner (STABLE) — MetricCard の前に既存配置
  6. MetricCard ×6 grid (3×2): Interruption / Concentration / Directionality / Gini / Persistence / Sustained-drop-days
  7. InterruptionBars chart (flat、 fold-above)
  8. SpeakingTrendChart (flat、 fold-above)
  9. IgnoredTurnCount accordion
  10. ChillingEvents accordion
  11. GracePeriod panel
  12. PositiveCount grid ×5 (GracePeriod の後に配置 — 現状の順序)
  13. AdaptationWatch 行
  14. Dispute button (footer)

変更箇所は 視覚 token と整形のみ。 Manager の操作モデル・記憶モデル・URL 構造は完全に維持される。

canon: 02_proposals/mirror-me__variants.html Variant A 「IA は一切変えず、 トークンを全 component に適用」

2. なぜ IA を変更しないか (Variant A の意義)

決定: 視覚整形と IA 改善を 1 段階に統合せず、 視覚整形のみを先行させる。

Variant A の存在意義は 「視覚的に amateur に見える」 不満だけを切り離して低コストで解消する」 ことにある。 Round 1 の primary fix を Variant B (中庸 — IA 再構成) にしたとしても、 Variant B の構造は Variant A の token 統一を 前提として吸収 する。 つまり Variant A の作業はどの variant を最終採用するにせよ無駄にならない

また、 IA 変更を伴わないため:

一方、 「文脈把握困難」 「empty 怖い」 「back-link 行き先誤り」 といった構造起因の不満は解消されない。 これらは Round 2 で complaints.md を埋めた後の判定で、 Variant B/C を選ぶことで初めて解決される。

canon: permanent-ui-principles §13 (視覚整形の token 統一); 02_proposals 「Variant B/C を選ぶ場合でも Variant A の作業は前提として実施が必要」

3. 採用した design_system_v1 トークン

r19 audit が指摘した 35 件の UI 不整合のうち、 本 mockup で解消した範囲を以下に列挙。

箇所現状の問題適用したトークン
MetricCard 色 ×6 インライン hex 18 件 (赤系混入を含む) --grade-stable / --grade-weak / --grade-blocked ドット + テキストラベル
Card padding 16px / 18px / 24px が混在 --space-5 (24px) に統一
Card radius 4px / 6px / 8px が混在 --radius-md (8px) に統一
H1 / H2 / H3 階層 サイズ・font-family が不統一 --fs-h1 / --fs-h2 / --fs-h3 + Fraunces 統一
Body / caption / meta フォント システム sans のみ、 Plex/Zen Kaku 未適用 IBM Plex Sans + Zen Kaku Gothic New + IBM Plex Mono (3 stack)
Chart 色 ×2 赤を使ったケースあり (canon §6 違反) --color-emerald-600 + --ink-soft のみ (canon §6 chart rule)
details/summary ×3 native と custom 混在 共通 .accordion component 1 種に統一
Button style ×3 (Dispute, signout, window toggle) border / padding / radius がばらばら 共通 token (--radius-md / --space-3 / 一定の color set) で揃え
Focus ring (a11y) 未実装箇所あり 全 interactive 要素に :focus-visible + --shadow-focus 風 outline
Evidence Grade badge 色のみのケースあり (a11y rule §1 違反) 必ず色ドット + テキストラベル (「STABLE」 文字必須)
背景色 純白多用、 cream tone 未活用 page bg = #fafaf7、 card bg = --paper、 toggle = --cream
Section spacing 32px / 40px / 60px が混在 --space-8 (48px) で section 区切り統一
Reason code 表示 普通の inline text、 視認性低 monospace + cream chip 化 (RC_* 全 6 件)

4. 採用した Evidence Grade 表現

決定: 全ての grade 表示で「色ドット + テキストラベル」 を verbatim 保証する。

permanent-ui-principles §5 (evidence semantics) と design_system_v1 §1 のルール 「badges must include both color AND text label」 に厳密に従い、 mockup 内では以下を実装:

現 Kashi で発生していた 「色だけで grade を示す」 ケース (a11y rule §1 違反) は本 mockup で 0 件。

canon: design_system_v1 §1; permanent-ui-principles §5 §12

5. B (中庸) との視覚比較ポイント — Justine が「同じか / 違うか」 を判定する材料

両 mockup を交互に開いて見比べた時、 以下 7 点が A と B の決定的な違い として観察できる。

比較点Variant A (現 mockup)Variant B (隣の mockup)
1. H1 の文言 「Manager Mirror」 (現状) 「あなたの Manager Mirror」 (role 強化)
2. back-link 行き先 /app/ceo へ戻る (現状維持) /app/me へ戻る (修正)
3. Tier 階層ラベル 無し (flat な section sequence) 「TIER 1 — interpretation」 等 eyebrow label 5 段
4. Grade Banner の位置 TimeWindowToggle と MetricCard の (小型 banner) H1 の直下 (大型 interpretation card with 「これは判定ではない」 説明文)
5. MetricCard の数 6 枚すべて 3×2 grid で表示 3 枚に絞り、 残り 3 枚は accordion 内
6. Chart の表示 2 chart が flat で常時表示 (accordion 化なし) chart は accordion 内に折り畳み
7. PositiveCount と GracePeriod の順序 GracePeriod → PositiveCount (現状順) PositiveCount → GracePeriod (P5 採用、 verbatim boundary copy 大型)
8. P5 boundary copy 1 行ミニ注釈のみ (§6 最小要件のみ満たす) 2-3 行の verbatim full copy block (P5 採用時必須化)
9. Tier 5 empty state 表示なし (現状の mirror-me は empty 改善未対応) 専用 empty state block (INSUFFICIENT 時の理由 + 次アクション)

Variant A 採用時に「直る」 不満

・「視覚的に amateur」 「散らかって見える」
・「色・サイズが揃ってない」
・「badge が色だけで読めない」 (a11y)
・「focus が見えない」 (a11y)

Variant A 採用時に「残る」 不満

・「何を見ればいいか最初にわからない」
・「back が CEO に行く」
・「empty が何もなさすぎる / 怖い」
・「ロール別ダッシュボード自体が直感的じゃない」 (← C のスコープ)

6. permanent-ui-principles 適合チェック

§判定根拠
§1 (no surveillance feel)PASSIA 変更なし、 RevealNamesButton ロールゲート維持、 監視 metaphor / アイコン 0 件
§2 (forbidden wording)PASS新規コピー追加なし。 「all clear」 「no problem」 「safe team」 等 0 件。 PositiveCount に §6 minimum boundary 注釈付き
§3 (role boundary first)PASSpage-subtitle に 「視聴者: 田中部長 (自分) / 他の Manager の mirror は表示できません」 明記、 RevealNamesButton 行で permission boundary 明示
§4 (visibility per role)PASS個別氏名 0 件、 「個別参加者の氏名は表示できません」 を accordion 内で明示、 受信/送信集計のみ
§5 (evidence semantics)PASSGrade Banner に grade + reason code + window + quality 全て同居 (色 + テキスト)
§6 (no-signal rule)PARTIALPositiveCount 上にミニ boundary 注釈あり (verbatim では無いが §6 最小要件は満たす)。 BLOCKED/INSUFFICIENT 時の empty state block は実装していない (これは B の Tier 5)
§7 (progressive disclosure)PARTIALaccordion 統一は §7 を満たすが、 「default visible layer 3-5 cards」 要求は満たさない (6 card flat のまま)
§8 (cognitive load)PARTIAL視覚 noise は大幅削減、 だが 「everything looks equally important」 問題は IA 不変のため残存
§9 (dashboard rules)PASS各 card に what / who / window / quality / grade / reason / action / NOT-prove sub を表示 (PASS only because A added these sub-fields to each card per §9)
§11 (internal screen)PASS13 要素 (role label / boundary / grade / reason / window / quality / safe actions / forbidden actions / audit-implicit / dispute) 全て配置済
§12 (a11y)PASS1 H1 / 見出し階層整理 / focus ring / badge 色+テキスト / accordion 共通化 / 1280px 900px 600px responsive
§13 (visual system)PASSoff-white / evergreen accent / outline icon / 大量 whitespace / 0 件 eye/camera/police アイコン / red 排除

PARTIAL が 3 件残っているのは Variant A の設計上の限界。 §6 §7 §8 のフル PASS は Variant B (IA 再構成) で初めて達成される。 Variant A は「視覚整形だけで届く範囲の改善」 を最大化する設計。

7. 解消した r19 既知 UI 不整合 (35 件のうち本 mockup でカバーされる範囲)

残る r19 不整合は IA 起因 (例: 「文脈ヒエラルキー無し」 「empty 改善未対応」) のため、 Variant A のスコープ外。 これらは B/C で扱う。

8. Justine 判断ポイント — A confirm / B redo の判定材料

本 mockup と隣の Variant B mockup を交互に開いて、 以下 4 つの問いに回答してください。 答え方によって 「A で十分」 か 「B が必要」 が決まります。

Q1: 「散らかって見える」 という不満が、 A で解消されたと感じますか?

Yes → A の token 整形で十分。 No → 視覚整形だけでは届かない別の問題 (情報密度・順序・優先度) が真因。 → B 必要。

Q2: 6 個の MetricCard を同列に並べることに違和感はありますか?

No → A で十分。 Yes (3 つに絞ってほしい、 重要度の差をつけてほしい) → B の 6 → 3 絞り込み + accordion 階層が必要。

Q3: 「最初に何を見ればいいか分からない」 という不満は A で解消されましたか?

Solved → A で十分 (おそらく問題は視覚雑音だった)。 Still unclear → A は IA 不変のため未解決。 B の Tier 1 大型 Interpretation banner (Grade + window + 1 行解釈) が必要。

Q4: back-link が /app/ceo に向くことは正しい挙動ですか?

Yes (Manager mirror は CEO ダッシュボードからの drill-down が main 経路) → A で十分。 No (Manager 自身の home /app/me に戻すべき) → B の back-link 修正が必要。

判断早見表

  • 4 問とも「A で十分」 寄り → orchestrator に confirm mirror-me=A を返答
  • 1 問でも「B 必要」 → orchestrator に switch mirror-me=B を返答 (既に B mockup 存在)
  • 「もっと根本的な再構成が必要」 と感じる場合switch mirror-me=C (Task Inbox 統合、 ただし 5 surface 連動再設計が必要)
  • 9. 実装フェーズへの引き継ぎ

    Variant A を React 実装する際の注意点 trace: kashi/src/app/app/mirror/[managerId]/page.tsx の現実装 + r19 audit report

    10. 既知のトレードオフ / 未解決