UI Proposal — mirror-me (Manager Mirror) — Round 1

Generated: 2026-05-27 / Stage: 2 (translator) / Surface: /app/mirror/[managerId] / Variants: 3 (A 保守的 / B 中庸 / C 大胆) / Source research: 01_research/mirror-me__references.html (6 refs, 5 strong patterns, 3 canon-conflict exclusions)
このドキュメントの読み方: Manager mirror (最優先 persona) の Round 1 提案。 3 variant はそれぞれ独立して読めるよう、 IA / 採用パターン / canon 適合 / トレードオフを完備しています。 Justine は末尾「推奨」 section を読んで pick mirror-me=A|B|C を orchestrator に返答してください。 全 variant とも Stage 1 で抽出された 3 つの canon-conflict パターン (AI risk バナー / 名前付き感情スコア / リーダーボード) は採用していません

0. 共通前提 (全 variant に適用される Kashi 固有制約)

制約根拠3 variant で守る方法
Manager は自己 mirror のみ閲覧可 DATA_VISIBILITY_MATRIX.md §3 全 variant の URL は /app/mirror/[managerId]。 他 Manager mirror への遷移パス 0 件。 H1 に「あなたの Manager Mirror」 と固定。
Manager は名前付き subordinate データを見られない DATA_VISIBILITY_MATRIX.md §3 / 永続原則 §4 全 variant で reveal-names UI は Admin/CEO ロールゲートのまま (Manager 視点では非表示)。 PositiveCount / IgnoredTurnCount は集計値のみ。
Manager は自分宛 dispute を見られない (anti-retaliation) DATA_VISIBILITY_MATRIX.md §4 ルール 2 全 variant で Dispute UI は「あなたが提起する」 方向のみ。 「あなたへの dispute 一覧」 は表示しない。
Evidence Grade は色 + テキスト両方 design_system_v1.md §1 / a11y 全 variant で grade バナーに STABLE 等のテキストラベル + --kashi-grade-* 色トークン両用。
「問題なし / オールクリア」禁止 wording 永続原則 §2 / §6 / CANONICAL_PRODUCT_TRUTH §2 positive 系セクションでは「観測された構造シグナル」 と限定的 wording のみ使用。 「No qualifying signal in this observed window」 が canonical safe copy。
監視・予測フレーム絶対 NG 永続原則 §1 / §13 全 variant で eye/camera/police アイコン 0 件、 red alert 0 件、 「あなたのチームは危険」 系コピー 0 件。 残るは observation + 自己認識 (鏡) フレーム。

Variant A — 保守的 (Visual Cleanup Only)

Risk: Low Impl: S (1-2日)

概要

現状の Information Architecture / ナビゲーション / セクション順序を一切変えずdesign_system_v1.md のトークン (color / typography / spacing / badge) を全 component に正しく適用するだけの提案。 r19 audit が指摘する 35 件の UI 不整合 (色 hex 直書き 18 件、 タイポ階層不統一、 Card variant 混在、 開示パターン不統一) を解消し、 「散らかって見える」 視覚的雑音を消す。 Manager の操作フロー・記憶モデルは 100% 維持されるため、 既存ユーザーへの再学習コスト 0。 数値的な情報量・密度・順序は変えないので、 Justine の不満 (推定) のうち 「文脈が把握しにくい」 「empty が怖い」 「back が CEO に向く」 は解消されない。 「視覚的に amateur」 不満のみを解消する。

Information Architecture (現状維持 — wireframe)

┌─────────────────────────────────────────────────────────────┐
│  PortalHeader (現状のまま、 ナビ変更なし)                       │
├─────────────────────────────────────────────────────────────┤
│  H1: Manager Mirror  ← トークン: --text-h1 (40px, Fraunces)     │
│  back-link: ← /app/ceo  (現状維持、 変えない)            │
├─────────────────────────────────────────────────────────────┤
│  RevealNamesButton (Admin/CEO 時のみ; Manager 自身では空)       │
├─────────────────────────────────────────────────────────────┤
│  CoverageStrip: comparable=12 / total=20 / excluded=8         │
│    ← 色: --kashi-grade-stable / --kashi-grade-blocked         │
├─────────────────────────────────────────────────────────────┤
│  TimeWindowToggle: [30日] [90日] [180日]                       │
│    ← 色: --kashi-evergreen for active state                   │
├─────────────────────────────────────────────────────────────┤
│  Evidence Grade Banner: STABLE (例)                          │
│    ← 既存だが色トークン非統一 → 修正対象                       │
├─────────────────────────────────────────────────────────────┤
│  MetricCard ×6 grid (現状の順序維持)                          │
│   ├ Interruptions  ├ Concentration  ├ Directionality          │
│   ├ Gini           ├ Persistence    ├ Sustained-drop-days     │
│    ← Card spacing: --space-4 / radius: --radius-md            │
├─────────────────────────────────────────────────────────────┤
│  InterruptionBars chart                                       │
│  SpeakingTrendChart                                           │
│    ← 色: --kashi-evergreen + --kashi-ink-muted のみ (red 排除)  │
├─────────────────────────────────────────────────────────────┤
│  IgnoredTurnCount リスト (受信 / 送信)                          │
│  ChillingEvents リスト                                         │
│  GracePeriod パネル                                            │
│  PositiveCount グリッド ×5                                     │
│  AdaptationWatch アラート                                       │
│    ← 全 details/summary を統一 (現状: native と custom 混在)     │
├─────────────────────────────────────────────────────────────┤
│  Dispute ボタン (現状維持、 位置変えず)                          │
└─────────────────────────────────────────────────────────────┘

採用する Stage 1 パターン

P1 × P2 △ (一部) P3 × P4 × P5 ×

design_system_v1 トークン適用箇所

箇所現状適用するトークン
MetricCard 色 ×6インライン hex 18 件--kashi-grade-stable / --kashi-grade-weak / --kashi-grade-blocked
Card padding不揃い (16px / 18px / 24px 混在)--space-5 (24px) に統一
Card radius4px / 6px / 8px 混在--radius-md (8px) に統一
H1 / H2 / H3サイズ階層不統一--text-h1 / --text-h2 / --text-h4 (カード見出し)
chart 色赤を使ったケースあり--kashi-evergreen + --kashi-ink-muted のみ (§6 chart rule)
details/summarynative と custom 混在共通 Accordion component 1 種に統一 (§7 progressive disclosure)
focus ring未実装箇所あり--shadow-focus 全 interactive 要素に
Evidence Grade badge色のみのケースあり必ず色 + テキストラベル (a11y rule §1)

permanent-ui-principles 適合チェック

§判定根拠
§1 (no surveillance feel)PASSIA 変更なし、 既存の rev-names ゲート + GracePeriod + audit log 維持
§2 (forbidden wording)PASSコピー追加・変更なし。 既存 copy のみ視覚整形
§3 (role boundary first)PASSrole 表示 / 視認境界は現状維持。 H1 を --text-h1 化して role context を視覚的に明瞭化
§7 (progressive disclosure)PARTIALdetails/summary 統一は §7 を満たすが、 default visible layer の「3-5 cards」 要求は満たさない (現状 6 card 並列のまま)
§8 (cognitive load)PARTIAL視覚雑音は減るが、 「everything looks equally important」 問題は残る (順序変更しないため)
§9 (dashboard rules)PASS各 card に what window? を sub-text で追加することで §9 要件達成
§11 (internal screen)PASSrole label / visibility boundary / grade / reason code / window / safe action / dispute — 全て現状で実装済み、 視覚整形のみ
§13 (visual system)PASSVariant A の本旨そのもの。 off-white base / evergreen accent / outline icon / 大量 whitespace を design_system_v1 で統一

DATA_VISIBILITY_MATRIX 適合チェック

Manager 列の Y(self) / Y(self-mirror) / N (anti-retaliation) ルールはすべて現状の RLS + UI で実装済み。 Variant A はデータ表示範囲を一切変えない (視覚のみ) ため、 マトリクス上の cell 全て pass。 特に Y(self-team, k-anon) による team aggregates 表示も既存ロジックを変えず。

解決される Justine の不満 (推定)

残るリスク / 未解決事項

トレードオフ

実装コスト

S (1-2日)。 component 単位の color/spacing/typography 置換のみ。 RLS / API / Server logic 不要。

学習コスト

0。 既存ユーザーは「あ、 見た目が綺麗になった」 だけで操作モデル変更なし。

既存ユーザー影響

positive のみ。 negative 影響リスクほぼ無し。

Variant B — 中庸 (Primary-Task Focus + IA Reorganization)

Risk: Med Impl: M (4-7日)

概要

Variant A の token 統一を前提として吸収した上で、 mirror-me ページ内のセクション順序と階層を Manager の primary task = 「直近主催ミーティング reflection」 を最上位にする再構成。 Stage 1 の P1 (summary-first) / P2 (window locked context) / P4 (3-layer progressive disclosure) を直接採用し、 Evidence Grade Banner を fold 上に昇格、 MetricCard を 6 → 3 に絞り (詳細は折り畳み)、 PositiveCount を GracePeriod 前に移動 (P5 partial、 boundary copy 付き)。 URL / nav / role ゲートは変えない。 ページ内構成のみ変更。 Manager は最初に「自分のシグナルの信頼度」 を見て、 次に「重要 3 指標」 を見て、 必要なら畳まれている詳細を開く、 という 3 層動線になる。 Round 1 の主要 fix。

Information Architecture (再構成 — wireframe)

┌─────────────────────────────────────────────────────────────┐
│  PortalHeader (現状維持)                                       │
├─────────────────────────────────────────────────────────────┤
│  H1: あなたの Manager Mirror  ← 「あなたの」 で role context 強化      │
│  back-link: ← /app/me  ← CEO ではなく自分のホームへ修正                │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ TIER 1: INTERPRETATION (fold-above) ━━━━━━━━━━━━━━━━     │
│                                                              │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │ 観測ウィンドウ: 直近 90 日 [30] [90] [180]              │ │
│  │ 対象ミーティング: 12 件 (除外 8 / 全 20)                  │ │
│  │                                                         │ │
│  │ シグナルの信頼度: STABLE  (色 + テキスト両方)      │ │
│  │ ┌───────────────────────────────────────────────────┐  │ │
│  │ │ この期間における観測パターンは安定的に観測されており、   │  │ │
│  │ │ 自己振り返りの材料として活用可能なレベルです。          │  │ │
│  │ │ これは判定ではありません。 別の問題の不在を意味しません。 │  │ │
│  │ └───────────────────────────────────────────────────┘  │ │
│  └─────────────────────────────────────────────────────────┘ │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ TIER 2: NUMERIC SIGNAL (3 cards, fold-around) ━━━━━━     │
│                                                              │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐         │
│  │ Interruption │ │ Directionality│ │ Sustained-   │         │
│  │ 受信:○↑     │ │ Gini: 0.34   │ │ drop-days: 0  │         │
│  │ last 90 days │ │ last 90 days │ │ last 90 days │         │
│  └──────────────┘ └──────────────┘ └──────────────┘         │
│                                                              │
│  ▸ 詳細指標 (3 件をさらに開く) ← Accordion                     │
│    └ Concentration / Persistence / Speaking trend            │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ TIER 3: POSITIVE OBSERVATIONS (新規順序) ━━━━━━━━━━━     │
│                                                              │
│  ※ 以下は観測されたポジティブな構造パターンです。           │
│    別の問題の不在を意味するものではありません。              │
│                                                              │
│  PositiveCount グリッド ×5 (Listen-through / Acknowledge etc.) │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ TIER 4: ATTENTION / GRACE / RAW (fold-below) ━━━━━━━     │
│                                                              │
│  GracePeriod パネル (現状維持、 位置のみ下げる)                  │
│  AdaptationWatch アラート (現状維持)                            │
│  ▸ チャート (Interruption / Speaking trend) ← Accordion        │
│  ▸ 個別イベント (IgnoredTurn / Chilling) ← Accordion           │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ TIER 5: NO-SIGNAL / EMPTY STATE 改善 ━━━━━━━━━━━━━━     │
│                                                              │
│  BLOCKED / INSUFFICIENT の場合のみ表示:                        │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │ シグナルの信頼度: INSUFFICIENT                       │ │
│  │ 理由:                                                    │ │
│  │  ・ 観測ウィンドウ内の比較可能ミーティングが 5 件未満       │ │
│  │  ・ diarization 品質が一部低い                           │ │
│  │                                                         │ │
│  │ 「No qualifying signal in this observed window」          │ │
│  │  — これは「問題なし」を意味しません。                    │ │
│  │                                                         │ │
│  │ 次のアクション:                                          │ │
│  │  → [チームのカバレッジを確認する] /app/admin/coverage     │ │
│  │  → [新規ミーティングを追加する] (upload)                  │ │
│  └─────────────────────────────────────────────────────────┘ │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  Dispute ボタン (現状維持、 footer 領域)                        │
└─────────────────────────────────────────────────────────────┘

採用する Stage 1 パターン

P1 ✓ P2 ✓ P3 ✓ P4 ✓ P5 ✓ (全 5 パターン採用、 ただし P5 は boundary copy 必須化で安全化)

Pattern採用方法採用理由 (research lineage)
P1 Summary-first Evidence Grade Banner を H1 直下の Tier 1 に昇格 (現状: MetricCard の後ろ) Stripe (R5) / Vercel (R4) / 15Five (R2) / Orbix B2B 分析 — fold 上に解釈を置くのが 4/6 ref attestation。 permanent-ui-principles §7 の "Default visible layer: one headline / one short explanation" が直接要請
P2 Window locked context TimeWindowToggle を Tier 1 内に固定、 全 MetricCard に last N days sub-text、 H1 直下に「対象ミーティング N 件」 を常時表示 GitHub / Vercel / 15Five / Stripe / Lattice — 5/6 ref。 permanent-ui-principles §5 §9 「every dashboard card must answer: what window?」 直接適用
P3 Honest empty state BLOCKED/INSUFFICIENT 時に 「理由 list + 次のアクション (coverage / upload) 1 つ」 を追加。 EMPTY_STATE_AND_NO_SIGNAL_COPY_LIBRARY.md の canonical wording 流用 Linear (R3) / 15Five (R2) / Vercel (R4) / Stripe (R5) — 4/6 ref。 §6 no-signal rule + CANONICAL_PRODUCT_TRUTH §4.3 直接要請。 「all caught up」 は禁止、 「理由 + 次アクション」 構造のみ採用
P4 3-layer disclosure Tier 1 (interpretation) → Tier 2 (3 metric card) → Tier 4 (折り畳まれた chart / 詳細 / 生イベント) という明示的 4 階層 6/6 ref で観察。 permanent-ui-principles §7 §8 直接要請。 r19 §7.1 でも mirror-me に対し同問題が指摘済
P5 Positive-first ordering (boundary copy 必須) PositiveCount を GracePeriod 前に移動 (Tier 3)。 必須: セクション頭に 「これは観測されたポジティブな構造パターンです。 別の問題の不在を意味しません」 を verbatim 表示 15Five / Lattice / HiManager / Notion / B2B coaching — 5/6 ref。 §6 no-signal rule 違反リスクを boundary copy で打ち消す。 これが無いと「no problem」 misleading 化
P5 採用時の必須 boundary copy (verbatim):
以下は観測されたポジティブな構造パターンです。 別の問題の不在を意味するものではありません。 観測ウィンドウ内における no qualifying signal は「問題なし」 ではなく、 観測できなかった (insufficient meetings / low quality / out of scope) 可能性を含みます。
典拠: permanent-ui-principles §6「No qualifying signal never means no issue.」 + EMPTY_STATE_AND_NO_SIGNAL_COPY_LIBRARY.md canonical wording。 このコピーが無いと P5 採用は canon §2 forbidden wording に抵触するリスク高。

design_system_v1 トークン適用箇所 (Variant A を継承 + Variant B 固有)

permanent-ui-principles 適合チェック

§判定根拠
§1 (no surveillance feel)PASS解釈先出しでも「あなたのチームを監視している」 ではなく「あなた自身の facilitation pattern を観察するための鏡」 framing 維持。 reveal-names ロールゲートは Manager 視点では非表示のまま
§2 (forbidden wording)PASS新規追加コピーは全て canonical safe wording。 P5 の boundary copy が「no problem」 misleading を打ち消す。 「all clear」 「safe team」 一切使用なし
§3 (role boundary first)PASSH1 を「あなたの Manager Mirror」 に変更し role context を強化。 back-link を /app/me に修正 (自分のホームへ)
§5 (evidence semantics)PASSTier 1 Banner で grade + window + データ品質 + 「これは判定ではない」 全てを最初に表示。 §5 の「Evidence grade is not a verdict」 を視覚的に強制
§6 (no-signal rule)PASSTier 5 で reason codes + 次アクションを明示。 「all clear」 ではなく「no qualifying signal in this observed window + 理由」 という canonical 構造
§7 (progressive disclosure)PASSDefault visible layer = 1 headline (Grade Banner) + 1 short explanation + 3 cards + 1 CTA (Dispute)。 §7 が定義する構造そのもの
§8 (cognitive load)PASSTier 1-5 階層により「everything looks equally important」 問題が解消。 6 card → 3 card で grouping を強制
§9 (dashboard rules)PASS各 card に what shown / who / window / quality / grade / reason code / action / not-prove を sub で表示。 No rank / no health score / no individual subordinate
§11 (internal screen)PASS13 要素 (role label / boundary / grade / reason / window / quality / safe actions / forbidden actions / audit / empty / error / permission / dispute) 全て Tier 1-5 で配置
§13 (visual system)PASSVariant A 継承 + 新規 Banner が evergreen accent + off-white base + whitespace 豊富。 eye/camera/police 0 件、 red alert 0 件

DATA_VISIBILITY_MATRIX 適合チェック

FieldManager 視点 cellVariant B の対応
Self-mirrorY(self)Tier 1-3 全て自己 mirror データのみ表示。 他 manager 0 件
Per-meeting structural metricsY(self-mirror only)Tier 2 MetricCard / Tier 4 chart 全て自己 mirror 範囲
Affected-candidate identity (others)N (anti-retaliation)名前一切表示なし。 IgnoredTurn / Chilling リストは集計件数のみ
Individual risk alerts about this personN (anti-retaliation)表示なし。 Manager 自身に対する個別 risk alert を表示する UI 要素 0 件
Disputes filed about this personN (anti-retaliation)「あなたへの dispute 一覧」 0 件。 Dispute button は「あなたが提起する」 方向のみ
Team aggregatesY(self-team, k-anon)PositiveCount / CoverageStrip は team_size >= 5 floor 既存ロジックを継承
Audit log entries about this personN (anti-retaliation)Manager 視点では audit log セクション非表示 (Variant B でも変更なし)

解決される Justine の不満 (推定)

残るリスク / 未解決事項

トレードオフ

実装コスト

M (4-7日)。 Tier 構造 5 段の component reorganization + Accordion 化 + empty state コピー追加 + back-link 修正。 RLS / API 変更なし。

学習コスト

低-中。 既存 Manager は「最初に banner を見るようになった」 程度の変化。 数値 6 → 3 への絞り込みは Accordion 開けば見えるので可逆。

既存ユーザー影響

positive 強。 「文脈が見えた」 「何を見ればいいか分かる」 効果が大きい。 唯一のリスクは 6 → 3 絞り込みへの個別 Manager の好み差。

Variant C — 大胆 (Unified Task-Inbox Model)

Risk: High Impl: L (12-18日, A/B の 3 倍)
Variant C のみ: cross-surface 影響あり。 既存の「ロール別ダッシュボード」 概念 (/app/me / /app/admin / /app/ceo / /app/reviewer / /app/mirror) を一段廃止し、 全 user の post-login landing を「いまあなたが向き合うべき事項の inbox」 に統合する提案。 本提案は mirror-me 単独では完結せず、 5 surface すべての連動再設計が必要。 Round 1 で C を選ぶ場合、 他 4 surface の translator にも C のメッセージを通知して整合を取る前提。

概要

Variant A の token + Variant B の階層化を内包しつつ、 最上位に「Manager Task Inbox」 という単一 entry point を置く設計。 「いまあなたが向き合うべきことは何か」 を 5-7 項目の actionable list として提示し、 各 task をクリックすると Variant B 相当の Mirror 詳細・GracePeriod 詳細・Dispute 詳細・upload flow 等へ drill-down。 Manager にとって「ログイン → 何を見るか」 という判断コスト 0 化を目指す。 Linear / Vercel / Stripe の summary-first + Lattice / 15Five の reflection prompt 一覧を組み合わせた task-inbox archetype。 URL 構造変更: /app/mirror/[managerId]/app/inbox?lens=mirror&managerId= の drill-down 化。 新規 default landing は /app/inbox。 実装工数は A/B の 3 倍、 既存ユーザーの記憶モデルを大きく書き換える。 Round 1 で Justine の不満が「ロール別 nav 自体が直感的じゃない」 という根本問題なら Variant C、 「mirror ページの中で混乱する」 だけなら Variant B で十分。

Information Architecture (新規 — wireframe)

┌─────────────────────────────────────────────────────────────┐
│  PortalHeader 簡素化:                                          │
│   [Kashi logo]   [Inbox] [Browse] [Help]   [account ▾]       │
│   ← nav 5 個 (me/admin/ceo/reviewer/mirror) → 3 個に減らす     │
├─────────────────────────────────────────────────────────────┤
│  H1: あなたのインボックス                              │
│  sub: ロール = Manager (鈴木一郎) /  最終更新: 5 分前             │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ TASK INBOX (最上位、 4-6 件、 優先度順) ━━━━━━━━━━━     │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ [1] STABLE mirror が更新されました (直近 90 日)        │ │
│  │     12 件のミーティングに基づく観測パターン                │ │
│  │     これは判定ではありません                          │ │
│  │     → あなたの Mirror を見る                          │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ [2] チームカバレッジに改善余地                              │ │
│  │     全 20 件中 8 件が比較不能 (品質 / 種類除外)            │ │
│  │     → カバレッジ詳細を確認                            │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ [3] あなたが提起した Dispute が 2 件                       │ │
│  │     Reviewer 確認待ち                                    │ │
│  │     → Dispute 状況を確認                              │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ [4] GracePeriod 中: 設定期限 2026-06-15                   │ │
│  │     → GracePeriod 詳細                                │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  ▸ 過去の通知 (Accordion で開く)                              │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ POSITIVE OBSERVATIONS (Inbox 下、 不変的 stripe) ━━━     │
│                                                              │
│  ※ 以下は観測されたポジティブな構造パターンです。          │
│    別の問題の不在を意味しません。                        │
│                                                              │
│  PositiveCount ×5 grid (Variant B 継承)                       │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│  ━━━━ LENS SWITCHER (旧 nav の代替) ━━━━━━━━━━━━━━━━━━━     │
│                                                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                     │
│  │ Mirror   │ │ Coverage │ │ Disputes │  ← 旧 admin/ceo相当   │
│  │ (現在)   │ │          │ │          │                     │
│  └──────────┘ └──────────┘ └──────────┘                     │
│                                                              │
│  各 lens をクリック → Variant B 相当の詳細 view へ              │
│                                                              │
└─────────────────────────────────────────────────────────────┘

  drill-down 後の Mirror 詳細 view (= Variant B の Tier 1-5 構成):
  /app/inbox?lens=mirror&managerId=xxx
  ↓
  Tier 1 (Banner) → Tier 2 (3 card) → Tier 3 (Positive) → Tier 4 (折り畳み) → Tier 5 (empty)
  ※ Variant B の構造をそのまま drill-down view として再利用

採用する Stage 1 パターン

P1 ✓ P2 ✓ P3 ✓ P4 ✓ P5 ✓ + 新規: cross-role task-inbox archetype

Pattern採用方法採用理由
P1 Summary-first (拡張) ページ全体のサマリーを「task list」 として提示。 各 task = 1 行 summary + grade + action。 Variant B の Banner は drill-down view 内に保持 Stripe / Vercel / Linear / 15Five の summary-first を「ロール横断 summary」 に拡張。 Linear の inbox UI、 Vercel の dashboard home が直接 reference
P2 / P3 / P4 drill-down view (= Variant B 構造) でそのまま継承 Variant C の drill-down 部分は Variant B と同等品質を維持。 IA 変更による canon 違反 0
P5 Positive-first Inbox 下に Positive section を「fixed stripe」 として常時表示 (boundary copy 必須) Variant B 同様、 必須 boundary copy で「no problem」 misleading を打ち消す
NEW: Task-inbox archetype Linear Inbox / Vercel Dashboard / Notion Inbox の pattern を Kashi 文脈に翻訳。 「いま向き合うべき事項」 という framing で「surveillance verdict」 リスクを回避 1-2 ref のみで強信号ではないが、 Stage 1 §4 で「Manager は 1 週に 1 回参照する reflection ツール」 と明示されており、 inbox は使用頻度が低い user に対しても「何を見るか」 を即座に提示できる。 ただし弱信号採用のため Round 2 で検証必須

design_system_v1 トークン適用箇所 (Variant A/B を継承 + Variant C 固有)

permanent-ui-principles 適合チェック

§判定根拠
§1 (no surveillance feel)PASS WITH CAVEAT「task inbox」 という framing は適切 (= 「あなた自身がやること」 の自己駆動)。 ただし task card のコピーが「あなたは XX を解決すべき」 風になると「verdict」 misleading 化する。 全 task card のコピーは canonical wording 厳守必須
§2 (forbidden wording)PASStask card コピーは canonical safe wording (「mirror が更新されました」 「カバレッジに改善余地」 等)。 「あなたのチームに問題」 「at-risk」 等は 0 件
§3 (role boundary first)PASSInbox H1 直下に「ロール = Manager (氏名)」 を明示。 Lens switcher で表示中 lens を視覚化。 role context 強化
§5 (evidence semantics)PASStask card 内に grade + window + 「これは判定ではない」 を内包 (例: 「STABLE mirror が更新されました (直近 90 日) これは判定ではありません」)
§6 (no-signal rule)PASSInbox が空のときも Variant B Tier 5 同等の「理由 + 次アクション」 構造を流用。 「all caught up」 系コピー禁止
§7 (progressive disclosure)PASSInbox = 1 headline + 5-7 task + 1 primary action per task + 1 limitation note。 §7 default visible layer の理想形
§8 (cognitive load)PASS「いま見るべきこと」 が task として明示されるため、 「everything looks equally important」 問題が根本解消
§9 (dashboard rules)PASS各 task card が what shown / who / window / grade / action / not-prove を内包。 No rank / no health score / no individual subordinate
§11 (internal screen)PASS13 要素は Inbox + drill-down view の 2 段で配置。 drill-down が Variant B 相当のため §11 完全達成
§13 (visual system)PASSInbox UI は task list という calm pattern (eye/camera/red alert 一切なし)。 「Linear inbox の暗色」 ではなく「off-white inbox」 として Kashi 色化必須

DATA_VISIBILITY_MATRIX 適合チェック

FieldManager 視点 cellVariant C の対応
Self-mirrorY(self)Inbox 内 mirror task → drill-down で Variant B 構造
Affected-candidate identity (others)N (anti-retaliation)Inbox に名前付き task 0 件。 「あなた以外の Manager の mirror」 への entry 0 件
Individual risk alerts about this personN (anti-retaliation)Inbox に「あなたに関する risk alert」 task 0 件 (canon §4 厳守)
Disputes filed about this personN (anti-retaliation)Inbox の Dispute task は「あなたが提起したもの」 のみ。 「あなたへの dispute」 は 0 件
Team aggregatesY(self-team, k-anon)Inbox の Coverage task / PositiveCount stripe は既存の team_size >= 5 floor を継承
Audit log entries about this personN (anti-retaliation)Manager 視点 Inbox に audit task 0 件。 Manager 自身の操作 audit は Admin の領域

解決される Justine の不満 (推定)

残るリスク / 未解決事項 (Variant C は重い)

トレードオフ

実装コスト

L (12-18日、 A/B の 3 倍)。 PortalHeader 改修 / route 再配線 / inbox aggregation API 新規 / role-based task filter / 5 surface 統合 / drill-down view (= Variant B) / migration script。

学習コスト

高。 既存 Manager は「mirror が /app/mirror にあった」 mental model を捨てる必要。 1-2 週間の tutorial / 案内 / 旧 URL → 新 URL redirect が必要。

既存ユーザー影響

初期は混乱 → 慣れれば大幅 positive。 「どこから見ればいいか分からない」 が根本解決。 ただし Round 2 hearing で「inbox model が JP B2B SaaS culture に fit するか」 を必ず検証 (HiManager や SmartHR は dashboard 型が多い)。

Justine への variant pick 推奨

推奨 Variant

Variant B (中庸 — Primary-Task Focus + IA Reorganization)

推奨理由

Round 1 の前提として complaints.md + screenshot を skip して進めているため、 「ロール別ナビ自体が複雑」 という根本不満が確認されていない段階で Variant C (大胆) を選ぶのは 過剰な賭け。 Variant C の cross-surface 改修は、 不満の根本原因が確定してからやる方が 実装 ROI が高い。 一方 Variant A (保守的) だけでは canon §7 §8 §9 (progressive disclosure / cognitive load / dashboard rules) の 要請を満たさず、 「ダッシュボードが judgment ではなく interpretation を支援すべき」 という Kashi コア doctrine に対し 現状の「6 card 並列スクロール」 が違反したままになる。

Variant B は: (a) Stage 1 で抽出された 5 強信号パターンを全採用 (P5 は boundary copy 必須化で安全化)、 (b) canon §1/§2/§3/§5/§6/§7/§8/§9/§11/§13 全て pass、 (c) Justine の主要不満 5 件 (cognitive overload / no interpretation / empty fear / back-link / amateur visual) のうち 5 件全てを解決、 (d) 実装工数 M (4-7 日) で Round 2 hearing を待たずに Round 1 mockup として共同創業者・友人・メンターに共有可能、 (e) Variant A の全 token 統一を内包しているため Variant A を別途実施する必要なし、 (f) Variant C への upgrade path も保持 (B の drill-down view 構造は C の drill-down 部分にそのまま再利用可能) — という 6 つの強みを併せ持つ。

Variant C は Round 2 以降の選択肢として保留。 Round 1 mockup を hearing → 「ロール別 nav が複雑」 が複数 hearing で複数回出てきたら Round 2 で C へ進む。 最大の懸念点 (task-inbox archetype が JP B2B SaaS culture に fit するか) を Round 2 hearing で同時検証できる。

pick 形式

Justine から orchestrator への返答形式:
pick mirror-me=B   (推奨)
pick mirror-me=A   (もし「視覚整形だけで十分」 と判断する場合)
pick mirror-me=C   (もし「Round 1 から根本不満が確実に分かっていて、 cross-surface 改修コストを許容する」 場合)

Canon-violation 検出 (translator 内部チェック)

全 3 variant とも、 Stage 1 で除外された 3 つの canon-conflict パターン (AI risk バナー / 名前付き感情スコア / リーダーボード) は採用していないCanon violation 0 件で translator 出力完成。

Variant C の唯一の懸念は「task-inbox archetype が弱信号 (1-2 ref)」 という点だが、 これは canon 違反ではなく research support の弱さ。 Round 2 hearing で検証する。


生成: 2026-05-27 / kashi-ui-translator / 出力: 02_proposals/mirror-me__variants.html
次 stage: Justine が pick → orchestrator が kashi-ui-mockupper を dispatch → 03_mockups/mirror-me/index.html
Stage 1 source: 01_research/mirror-me__references.html (6 refs / 5 strong patterns / 3 canon-conflict exclusions)
Canon source: permanent-ui-principles.md §1/§2/§3/§5/§6/§7/§8/§9/§11/§13 / design_system_v1.md §1-§9 / DATA_VISIBILITY_MATRIX.md §3 §4 §5