UI Proposal — app-me (Employee Dashboard)

生成日時: 2026-05-27 / 担当: kashi-ui-translator / surface: /app/me / 上流: 01_research/app-me__references.html (6 refs / 5 strong patterns) / 下流: Justine pick → mockupper

Variant A. 保守的 SCOPE: visual / token cleanup only EFFORT: S

一文要約: 現状 IA・nav・9 ブロック構成・hierarchy をすべて維持。 design_system_v1 token の適用と r19 既知不整合 (§4.3 / §4.7) の解消だけを行い、「素人臭さ」を取る。

主タスク (page primary job)

現状と同じ: 自分の構造シグナル (発言機会 / 割り込まれ率 / 無視・未回答率) の確認 + エビデンス品質の把握 + 監査・異議申し立てへの導線確保。 IA は触らない。

レイアウト構造 (above-fold composition)

┌──────────────────────────────────────────────────────────┐
│ PortalHeader [Kashi]   …   [My Personal] [My Audit] [→]  │ ← nav 維持
├──────────────────────────────────────────────────────────┤
│  ROLE: Member   /  /app/me                               │ ← role-badge 維持
│  H1 — My Personal Patterns                               │ ← H1 1 つ厳守 (§12)
│                                                          │
│  ┌─ §A privacy banner ────────────────────────────────┐  │ ← 既存維持、 token のみ刷新
│  │ あなたのデータは…  [監査ログを確認 →]              │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ┌─ §B role-description ──────────────────────────────┐  │
│  │ Member ロールが見られるデータについて              │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ┌─ §C evidence readiness ────────────────────────────┐  │
│  │ [CoverageReadinessPill: STABLE / EMERGING / …]     │  │ ← grade token 統一
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ┌ §D speaking ┐ ┌ §E interruption ┐ ┌ §F ignored ┐    │ ← 3-up grid 維持
│  │ value       │ │ value           │ │ value      │    │
│  │ + grade pill│ │ + grade pill    │ │ + grade    │    │
│  └─────────────┘ └─────────────────┘ └────────────┘    │
│                                                          │
│  §G  What Kashi does NOT know  (7 bullet)                │ ← 同位置維持
│  §H  Notice history                                       │
│  §I  Audit link / Disputes                                │
└──────────────────────────────────────────────────────────┘

採用する研究パターン

パターン	出典	適用部位
P4 — status + confidence (color + text)	app-me__references.html §3 P4 (4/6 refs: Linear / Stripe / Lattice / Notion)	各 MetricCard (§D §E §F) の数値の隣に grade pill を貼り、「数値の確からしさ」を一目で出す。ただし IA / カード並び順は不変。
r19 §4.3 (visual density inconsistency 解消)	research §1 (r19 既知不整合)	governance/demo ページとの視覚言語を統一。カード padding / radius / shadow を `--space-5` / `--radius-md` / `--shadow-sm` に統一。
r19 §4.7 (color token system 適用)	research §1 (r19 既知不整合)	インライン `#1F4A33` 等を `var(--kashi-evergreen-deep)` に置換。 emerald-* Tailwind 直書きを token クラスに置換。

design_system_v1 トークン適用箇所

color: 全カード border = --kashi-border、 H1 = --kashi-ink、 grade pill = --kashi-grade-stable/weak/emerging/insufficient/blocked (color + text label 両方、 §1 a11y rule)
typography: H1 = --text-h1 (40px/48px/600)、 H2 セクション見出し = --text-h3 (24px/32px/600)、数値 = --text-h2 (32px/40px/600)、 grade pill text = --text-caption (12px/16px/500)
spacing: セクション間 = --space-8 (48px)、カード内 padding = --space-5 (24px)、 grid gap = --space-4 (16px)
radius: 全カード = --radius-md (8px)、 grade pill = --radius-sm (4px)
shadow: resting = --shadow-sm、 hover = なし (privacy page では interactive emphasis を控える)
font: H1 = Fraunces 600、 body = IBM Plex Sans / Zen Kaku Gothic New、 reason code = IBM Plex Mono

permanent-ui-principles 適合チェック

§3 role boundaryPASS Member 単独ロール、他ロールはリダイレクト排除という現行 IA を維持。 role-badge も上部表示維持。

§7 progressive disclosurePARTIAL 既存 9 ブロック構成のため、 §7 が要求する「default visible: 3-5 cards」は満たさない (現状 9 ブロック)。 visual 統一によって "equally important 感" は緩和されるが、構造的に解消されるのは Variant B / C。

§8 cognitive loadPARTIAL 同上。 §8 「a screen fails if everything looks equally important」に対しては grade pill 導入で部分緩和。

§9 dashboard rulesPASS grade / reason code / window / "not a verdict" 表示は MetricCard 内に必ず維持。個人ランキング・ヘルススコアなし。

§11 internal screenPASS 役割ラベル / visibility 境界 / grade / reason codes / 異議申し立て path すべて維持。

§13 visual systemPASS off-white / dark green accent / restrained card / 監視アイコン無し。 Token 適用で正式準拠化。

§2 forbidden wordingPASS コピーは現状 i18n key 維持。検知 / 予測 / 健康スコア / 生産性スコア / at-risk は混入しない。

§4 employer exposurePASS このページは audit_log を書かない doctrine 維持。自分のページビューを employer に晒す要素はゼロ。

DATA_VISIBILITY_MATRIX 適合チェック

表示カード	Field category	Member 列	判定
§A privacy banner	(none — explanatory)	—	PASS
§B role-description	(none — explanatory)	—	PASS
§C evidence readiness	Pattern summaries (own)	Y(self)	PASS
§D speaking	Per-meeting structural metrics (own)	Y(self)	PASS
§E interruption	Per-pair / dyad metrics (own side only, anonymized source)	Y(self)	PASS AC-15 維持: source identity 非表示
§F ignored	Per-meeting structural metrics (own)	Y(self)	PASS
§G what Kashi doesn't know	(none — explanatory)	—	PASS
§H Notice history	Notices naming this person	Y(self)	PASS
§I Audit link / Disputes	Audit log + Disputes filed about this person	Y(self)	PASS

解決される Justine の不満

complaints.md は未提供 (kickoff §2 で skip 判断済み)。 research §1 で立てられた推定不満を引用:

推定不満 (1) — 9 ブロックのどこから読めばいいか分からない: PARTIAL Token 統一で視覚的な "ばらつき感" は減るが、 IA 自体は不変なので根本解決ではない。
推定不満 (4) — "What Kashi does not know" が法的免責文のように読める: PARTIAL Typography 整理で読みやすくはなるが、 §G の位置・内容は不変。
r19 §4.3 / §4.7 — visual density / color token 不整合: SOLVED Token 統一によって解消。

残るリスク / 未解決事項

IA を触らないため、「9 ブロック縦長」構造による情報過多は解消されない。 Justine が visual cleanup だけで OK と判断した場合の選択肢。
P1 (today-first) / P2 (progressive disclosure) / P3 (privacy ownership 強化) は本 variant では適用されない (B/C で適用)。
§7 / §8 への完全準拠は B 以上が必要。

実装工数感

S (small) — CSS / Tailwind class の置換のみ。 React コンポーネント構造変更なし。 i18n key 変更なし。 RLS 変更なし。推定 1-2 日。

Variant B. 中庸 (IA reorganization + primary-task focus) SCOPE: page IA restructure (nav unchanged) EFFORT: M

一文要約: nav は維持。 9 ブロックを「今の状態 (3-4 カード)」 + 「アクセス権の自分掌握 (banner 強化)」 + 「折りたたみ詳細」に再構成し、 P1 today-first / P2 progressive disclosure / P3 privacy ownership を 3 本柱で適用する。

主タスク (page primary job)

「今、自分のデータがどう扱われていて、構造的に何が見えているか」を 5 秒で把握する。 詳細・履歴・免責文は読みたいときに開く。過去の発言の振り返り / 次の 1on1 準備につながる action prompt は 1 つだけ最上部に。

レイアウト構造 (above-fold composition)

┌──────────────────────────────────────────────────────────┐
│ PortalHeader [Kashi]   …   [My Personal] [My Audit] [→]  │ ← nav 不変
├──────────────────────────────────────────────────────────┤
│  ROLE: Member  /  /app/me                                │
│  H1 — My Personal Patterns                               │
│                                                          │
│  ┌─ Privacy ownership banner (UPGRADED) ──────────────┐  │ ← P3 適用
│  │ あなたのデータはあなたが所有しています。           │  │
│  │ 過去 24 時間に 0 件のアクセスがありました。        │  │ ← 自分の audit を summarize
│  │ [アクセス履歴を確認 →] [異議申し立て →]            │  │ ← audit link を上部昇格
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ┌─ Today's Reflection card (NEW, P1) ───────────────┐  │ ← P1 today-first
│  │ 観察ウィンドウ: 直近 30 日  [30/90/180 切替]       │  │
│  │ Coverage readiness: [STABLE / 124 mtgs / E2]       │  │ ← grade pill 直貼り
│  │                                                    │  │
│  │ → 次の 1on1 で振り返ると良い構造的観察:            │  │
│  │   • あなたの発言機会 (3 mtgs で window 比 25% 減)  │  │ ← safe wording 厳守
│  │   • 割り込まれ率 (anonymized source、 2 mtgs 観察) │  │
│  │   観察ウィンドウ内に比較可能なミーティングが       │  │
│  │   増えるとカードは更新されます。                   │  │ ← P5 safe empty-state wording
│  │                                                    │  │
│  │   not a verdict / not an HR decision input         │  │ ← §5 必須
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ┌ §D speaking ┐ ┌ §E interruption ┐ ┌ §F ignored ┐    │ ← 3 シグナル カード
│  │ value + pill│ │ value + pill    │ │ value + pill│   │
│  │ reason code │ │ AC-15 anonymized│ │ reason code │   │
│  └─────────────┘ └─────────────────┘ └─────────────┘   │
│                                                          │
│  ─── [▼ 詳細を見る (1 アコーディオン)] ──────────────    │ ← P2 progressive disclosure
│  ▶ Kashi が見えていないこと (§G の 7 bullet)             │
│  ▶ 通知履歴 (§H、 空状態は actionable copy)              │
│  ▶ 過去の異議申し立て (§I)                                │
│  ▶ Member ロールが見られるデータについて (§B)            │
└──────────────────────────────────────────────────────────┘

採用する研究パターン

パターン	出典	適用部位
P1 — today-first hierarchy	app-me__references.html §3 P1 (4/6 refs: Linear / Lattice / Notion / Superhuman)	「Today's Reflection card」を最上部に新設。ただし監視 framing を避けるため、「今あなたが何をすべきか」ではなく「次の 1on1 で参照すると良い観察」と passive framing。
P2 — progressive disclosure (summary → detail)	app-me__references.html §3 P2 (5/6 refs: Linear / Stripe / Lattice / Notion / Superhuman)	§G (Kashi が見えていないこと 7 bullet) / §H (通知履歴) / §I (異議申し立て) を 1 つの 4-section アコーディオンに統合。 fold 上は 3-5 カードのみ (§7 default visible 準拠)。
P3 — privacy ownership framing	app-me__references.html §3 P3 (4/6 refs: Lattice / Stripe / GitHub / Superhuman)	Privacy banner を upgrade。「過去 24 時間のアクセス数 (自分が知らないところで誰かに見られたか)」を summarize して、 audit link を上部直下に昇格。 DATA_VISIBILITY_MATRIX §7 「single most important visibility surface」を実装的に体現。
P4 — status + confidence (color + text)	app-me__references.html §3 P4 (4/6 refs)	各 MetricCard に grade pill 直貼り (Variant A と同じ)。加えて Today's Reflection card にも window 内 grade summary を表示。
P5 — empty state as actionable next-step	app-me__references.html §3 P5 (5/6 refs)	BLOCKED/INSUFFICIENT カード + 空 notice history + 空 disputes に対し、 §6 「no-signal rule」準拠の safe wording 「観察ウィンドウ内に比較可能なミーティングが増えるとこのカードが更新されます」等を採用。「データが揃えば検知できます」等 §2 forbidden wording に抵触する表現は禁止 (researcher が指摘した最大リスク)。

研究 §6 で指摘された最大リスクへの translator 判断:
P5 (empty state copy) は §2 forbidden wording に抵触するリスクがあると研究で指摘されている。本 variant では safe wording の雛形を明示 する:

OK 「観察ウィンドウ内に比較可能なミーティングが増えると、このカードが更新されます」
OK 「現在のデータ品質では構造的シグナルが grade INSUFFICIENT です。 reason code: insufficient_comparable_meetings」
OK 「次の 1on1 で参照すると良い構造的観察があります」 (passive、 invite-not-prompt framing)
NG 「データが揃えば問題を検知できます」 (predicts/detects framing)
NG 「あなたのリスクレベル」「at-risk」「組織健康度」 (forbidden wording verbatim)
NG 「all clear」「問題なし」 (§6 explicitly forbidden)

design_system_v1 トークン適用箇所

Variant A の token 適用すべてに加え、
Today's Reflection card: 背景 = --kashi-paper-tint、 border-left 4px = --kashi-evergreen、 padding = --space-6 (32px)、内部の grade summary は --kashi-grade-stable badge (text label 必須)
Privacy banner upgrade: 背景 = --kashi-emerald-50、アクセス数表示 = --text-h4 (20px/600)、リンクボタン 2 つは --kashi-evergreen + --radius-sm
アコーディオン: Lucide outline icon (chevron-right → chevron-down、 16px、 1.5px stroke)、ヘッダー = --text-h4、 background = transparent、 hover = --kashi-paper-tint
focus state: 全 interactive element = --shadow-focus (0 0 0 3px rgba(47,107,74,0.4))、 a11y baseline 維持

permanent-ui-principles 適合チェック

§3 role boundaryPASS Member 単独。他ロールへの混在なし。 role-badge 上部表示維持。

§7 progressive disclosurePASS 「default visible: privacy banner + Today's Reflection + 3 シグナルカード = 5 要素」 = §7 「3-5 cards」準拠。詳細 4 section はアコーディオン (fold)。

§8 cognitive loadPASS H1 1 つ、 Today's Reflection が "primary CTA 相当" として明確、 grade pill で重み付け。「everything equally important」状態を解消。

§9 dashboard rulesPASS 全カードに grade / reason code / window / "not a verdict" 維持。ランキング・ヘルススコア・隠蔽なし。

§11 internal screenPASS 役割ラベル / visibility 境界 / grade / reason codes / 異議申し立て / empty state (P5 safe wording) / audit path すべて維持・強化。

§13 visual systemPASS off-white + dark green、監視アイコン無し、 calm badge、 generous whitespace。

§2 forbidden wordingPASS Today's Reflection card / empty state copy / privacy banner upgrade、すべて safe wording 雛形 (上 callout) で策定。検知 / 予測 / 健康スコア / 生産性スコア / at-risk 不使用。

§4 employer exposurePASS Privacy banner upgrade は「自分が自分のアクセス履歴を見る」方向のみ。自分のページビューを employer に晒す UI 要素なし。このページが audit_log を write しない doctrine は維持。

DATA_VISIBILITY_MATRIX 適合チェック

新規 / 変更カード	Field category	Member 列	判定
Privacy banner upgrade (「過去 24 時間のアクセス数」)	Audit log entries about this person (own)	Y(self, real-time)	PASS §7 worker-self access 強化
Today's Reflection card (window + grade + 観察 bullet)	Pattern summaries (own) + Per-meeting structural metrics (own)	Y(self)	PASS
§D §E §F カード (grade pill 追加)	同上	Y(self)	PASS AC-15 維持: §E source は anonymized
アコーディオン (§G §H §I §B 統合)	変更なし — 既存 cell 維持	Y(self)	PASS

解決される Justine の不満

推定不満 (1) — 9 ブロックのどこから読めばいいか分からない: SOLVED Today's Reflection card が「最初に読む場所」として明確に最上部。 §G/§H/§I は fold 下。
推定不満 (2) — 「データが不足しています」系の空状態が冷たく next action が見えない: SOLVED P5 safe wording 雛形により、 empty state に「次に何を期待すべきか」を passive framing で明示。
推定不満 (3) — Audit ログ・Dispute が下部に埋もれている: SOLVED Privacy banner upgrade で audit link + dispute link を上部直下に配置。 DATA_VISIBILITY_MATRIX §7 が要求する worker-trust posture を視覚的に体現。
推定不満 (4) — "What Kashi does not know" が法的免責文のように読める: PARTIAL アコーディオンに移すことで法的免責の重さは緩和。ただし文言自体は touch しない (§14 legal copy rule 抵触リスクのため translator 単独では変更しない)。
r19 §4.3 / §4.7: SOLVED (Variant A と同じ)

残るリスク / 未解決事項

P1 「Today's Reflection card」の文言設計が最重要 — i18n 担当 + canon owner (haseruida@) のレビュー必須。 i18n key 新規 ~3-5 個追加。
Privacy banner の「過去 24 時間アクセス数」表示は audit_log table の集計クエリが必要 (現状 §A は static)。ただし read-only クエリで audit_log を write しない doctrine は守れる。
P5 で挙げた forbidden wording 候補は CI test (test/i18n-r17-forbidden-marketing.test.ts) に追加して保護を厚くする提案を mockupper に追記推奨。
アコーディオン化により、 §G (Kashi が見えていないこと) の可読性が一時的に低下する懸念 — open-by-default にするか、 §G を fold 上の trust note として最下部に残すか、 mockupper 段階で再判断。

実装工数感

M (medium) — React コンポーネント新規 2 個 (Today's Reflection card / アクセス数 summary)、既存 7 ブロックのアコーディオン化、 i18n key 5-8 個追加、 audit_log 集計 read-only query 1 つ。 RLS 変更なし。推定 4-6 日。

Variant C. 大胆 (unified reflection inbox model) SCOPE: cross-surface IA rethink EFFORT: L

⚠ Variant C は cross-surface 影響あり。実装工数 ≈ A/B の 3 倍。
Portal-level routing の再実装が必要 (member の post-login landing を /app/me から /app/inbox に変更)。他 4 surface (admin / ceo / reviewer / mirror-me) の inbox model 横展開も同時検討推奨 (本提案は member 単独でも成立するが、横展開せず member だけ inbox 化すると Kashi 全体の IA に分裂が起きる)。

一文要約: 「/app/me を 9 ブロックダッシュボードとして見る」という発想を捨て、「自分の reflection inbox」という単一 timeline に置き換える。過去の自分の発言 (構造シグナル) ・自分宛 notice ・自分が同意済みの summary ・次の 1on1 準備 task が、時系列で 1 つの inbox に流れる。

主タスク (page primary job)

「今、自分に向けて何が届いていて、何を確認すべきか」を inbox 1 本で把握する。 Linear Inbox / Superhuman Split Inbox の self-reflection 版。「ダッシュボード」という framing 自体を放棄し、「自分宛の構造的観察 stream」に書き換える。

レイアウト構造 (above-fold composition)

┌──────────────────────────────────────────────────────────┐
│ PortalHeader [Kashi]   …   [Inbox] [Patterns] [Audit]    │ ← nav 3 項目簡素化
│                              ↑ 新規   ↑ 詳細    ↑ 維持   │
├──────────────────────────────────────────────────────────┤
│  ROLE: Member  /  /app/inbox  (新ランディング)            │
│  H1 — My Reflection Inbox                                │
│                                                          │
│  ┌─ Privacy ownership banner ────────────────────────┐  │ ← Variant B から流用
│  │ 過去 24 時間に 0 件のアクセスがありました。       │  │
│  │ [アクセス履歴] [異議申し立て]                     │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ┌─ Filter: All / Unread / Patterns / Notices /     ─┐  │ ← Superhuman split-inbox 風
│  │            1on1 prep / Disputes                    │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  ─── 今週 ───────────────────────────────────────────    │
│  ⊙ 2026-05-26  Pattern update                            │
│     speaking opportunity: STABLE / 3 mtgs / E2           │
│     reason: insufficient_window_priors_resolved          │
│     [詳細を見る →]                                       │
│                                                          │
│  ⊙ 2026-05-24  1on1 prep prompt                          │
│     次の 1on1 で参照すると良い構造的観察:                │
│     • 割り込まれ率 (anonymized source、 2 mtgs)          │
│     not a verdict / not an HR decision input             │
│                                                          │
│  ─── 先週 ───────────────────────────────────────────    │
│  ⊙ 2026-05-19  Notice (notices.member.xxx)               │
│     あなたについて pattern threshold が cross されました │
│     [異議申し立て] [詳細]                                │
│                                                          │
│  ⊙ 2026-05-18  Pattern update                            │
│     ignored: INSUFFICIENT / reason: low_diarization      │
│                                                          │
│  ─── 過去 30 日 ─────────────────────────────────────    │
│  ⊙ … (timeline 継続)                                     │
│                                                          │
│  [もっと前の inbox を見る → /app/me/archive]             │
│                                                          │
│  ─── 詳細ビュー: 旧 /app/me 9 ブロックは ──────────────  │
│  [Patterns] tab (PortalHeader 2nd item) に保管           │
└──────────────────────────────────────────────────────────┘

採用する研究パターン

パターン	出典	適用部位
P1 — today-first hierarchy (最大限適用)	app-me__references.html §3 P1 (4/6 refs)	Inbox 全体が「今週」 → 「先週」 → 「過去 30 日」の時系列 grouping。 default scroll position は「今週」。過去データは scroll で自然到達。
P2 — progressive disclosure (最大限適用)	app-me__references.html §3 P2 (5/6 refs)	inbox row は 1 行 summary のみ (grade + reason code + 1 line)。詳細は drilldown 専用 sub-route (`/app/me/patterns/[id]`)。 §7 default visible 「3-5 cards」を「inbox row 5-10 件」に置換。
P3 — privacy ownership (Variant B と同じ強化)	app-me__references.html §3 P3 (4/6 refs)	Privacy banner は Variant B 同様。
P5 — empty state as actionable	app-me__references.html §3 P5 (5/6 refs)	Inbox 空 = 「観察ウィンドウ内に届いた構造的観察はありません。今のあなたのデータ品質: `insufficient_comparable_meetings`」 (Linear "You're all caught up" の Kashi safe version)。 §6 forbidden 「all clear」「safe team」は使わない。
(弱信号) Superhuman Split Inbox	app-me__references.html §4 R5 (2/6 refs — weak signal)	「All / Unread / Patterns / Notices / 1on1 prep / Disputes」の filter chip。ただし keyboard shortcut は本 variant でも見送り (member 用 ROI 低)。

X1 (監視感のある Activity Timeline) と C との違い (researcher §5 で示された forbidden pattern との衝突回避):
X1 が NG なのは「マネージャーがどの会議に出たか / 誰がいつ何を見たか」を時系列で見せる UI だから。 Variant C の inbox は 「あなたが受け取った構造的観察」「あなたが受け取った notice」「あなたが受け取った 1on1 prep」 のみで、 送り手 (誰がアクセスしたか) は含まない。送り手情報を見たい場合は Privacy banner の audit link から /app/me/audit に飛ぶ動線で、 inbox と audit を分離する。これにより X1 の懸念 (employer に page view が見える、監視 framing) は回避できる。

design_system_v1 トークン適用箇所

inbox row: padding = --space-4 (16px)、 separator = --kashi-border、 hover = --kashi-paper-tint、 unread indicator (⊙) = --kashi-evergreen
filter chip: active = --kashi-evergreen + white text、 inactive = --kashi-paper-tint + --kashi-ink-muted、 --radius-sm (4px)
grouping label (今週 / 先週 / 過去 30 日): --text-caption (12px/500)、 color = --kashi-ink-muted、 letter-spacing 0.08em (Plex Mono)
privacy banner: Variant B と同じ
nav 簡素化: PortalHeader の Inbox / Patterns / Audit 3 link = --text-body-sm、 active link = --kashi-evergreen underline

permanent-ui-principles 適合チェック

§3 role boundaryPASS Member 単独維持。 Inbox の内容はすべて「自分宛・自分のデータ」のみ。他従業員データは一切混入しない。

§7 progressive disclosurePASS Inbox row 1 行 summary + drilldown 別 route という最も progressive な disclosure。 §7 「default visible: 3-5 cards / one primary CTA」を inbox 形式に再解釈。

§8 cognitive loadPASS 「inbox 一本」 = 最大限の hierarchy 明示。「everything equally important」を完全に解消。

§9 dashboard rulesPASS Inbox row 各々が grade + reason code + window + "not a verdict" を保持。ただし「dashboards must support interpretation, not perform judgment」の精神を「inbox = passive receiver」 framing でより強く体現。

§11 internal screenPASS 役割ラベル / visibility 境界 / grade / reason codes / empty state / 異議申し立て path すべて inbox row 内に保持。

§13 visual systemPASS off-white / dark green、監視アイコン無し (⊙ は generic unread indicator、「目」や surveillance metaphor 不使用)。

§2 forbidden wordingPASS 「Reflection Inbox」「自分宛の構造的観察」はいずれも approved wording 範疇。検知 / 予測 / 健康スコア / 生産性スコア / at-risk は不使用。

§4 employer exposurePASS Inbox は read-only 自分閲覧。 inbox row への「既読/未読」状態は client-local state にし、 DB に書かない (= employer から見えない)。これにより §4 「page views を employer に晒さない」を明示的に守る。

DATA_VISIBILITY_MATRIX 適合チェック

Inbox row 種類	Field category	Member 列	判定
Pattern update	Pattern summaries (own) + Per-meeting structural metrics (own)	Y(self)	PASS
1on1 prep prompt	Pattern summaries (own)	Y(self)	PASS
Notice	Notices naming this person	Y(self)	PASS
Dispute filed (own)	Disputes filed about this person (own)	Y(self)	PASS
Privacy banner (audit summary)	Audit log entries about this person (own)	Y(self, real-time)	PASS
(混入禁止確認) 他従業員の inbox 内容	—	—	PASS 設計上ゼロ混入
(混入禁止確認) 上司・reviewer・admin の inbox 閲覧	—	—	PASS route guard で Member 以外は redirect

解決される Justine の不満

推定不満 (1) — 9 ブロックのどこから読めばいいか分からない: SOLVED (radically) 9 ブロックという発想を放棄。 Inbox 1 本に置換。
推定不満 (2) — 空状態が冷たく next action が見えない: SOLVED Inbox 全体に safe empty-state framing 適用。
推定不満 (3) — Audit ログ・Dispute が下部に埋もれている: SOLVED Privacy banner で audit / dispute を上部固定。加えて inbox filter に Disputes 専用 view 追加。
推定不満 (4) — "What Kashi does not know" が法的免責文のように読める: SOLVED 法的免責文セクション (§G) は /app/me/patterns 配下に移動。 Inbox には「Kashi が観察できなかったため insufficient grade になった」という個別 reason code が inbox row 内に出る形に置換。「読み物」ではなく「事象」に変換。

残るリスク / 未解決事項

最大リスク: Portal-level routing 変更。 member の post-login redirect が /app/me → /app/inbox に変わる。既存ユーザー (現在 demo tenant 含む) の bookmark / muscle memory に影響。
他 4 surface (admin / ceo / reviewer / mirror-me) も inbox model にしないと、「member は inbox / 他ロールは dashboard」という分裂 IA になる。ただし mirror-me (Manager 最優先 persona) は Variant C 風の inbox model がむしろ強い fit である可能性大 — orchestrator が 5 surface の cross-surface 整合を見て判断する材料。
「inbox 既読/未読」を DB に書かない設計 (§4 准拠) は実装的に意外と複雑 — client-local state (localStorage) は端末跨ぎで同期しない。「unread」概念自体を捨てて「最新 N 件を default 表示」に倒す案もあり、 mockupper 段階で再判断。
9 ブロック (現 §A-§I) が /app/me/patterns 配下に移動。 patterns route の設計が別途必要 (Round 1 では translator は触らない、 mockupper への TODO)。
i18n key 大幅増 (~15-20 個)、ルーティング変更、既存 e2e test の path 更新、 RLS は変わらないが route guard は更新必要。

実装工数感

L (large) — Portal routing 変更、新規 React コンポーネント 4-6 個 (Inbox / InboxRow / InboxGroup / FilterChip / 既存 banner 流用)、旧 /app/me を /app/me/patterns に移行、 e2e test 更新、 i18n key 15-20 個、 RLS 変更不要だが route guard 更新。 cross-surface 一貫性を取るなら他 4 surface の inbox 化 spike も必要。単独 surface 実装で推定 10-14 日、 cross-surface 整合まで含めると 4-6 週間。

Justine への選択質問

Variant	主な解決対象	残るリスク	実装工数
A. 保守的	r19 §4.3 / §4.7 (token 不整合) のみ	9 ブロック縦長による情報過多は残る	S (1-2 日)
B. 中庸	推定不満 (1)(2)(3) + r19 + §7/§8 完全準拠	i18n 文言レビュー (canon owner 必須)、 audit_log 集計クエリ 1 つ追加	M (4-6 日)
C. 大胆	推定不満 (1)(2)(3)(4) すべて + 「ダッシュボード」 framing そのもの	cross-surface IA 分裂リスク、 portal routing 変更、 unread 同期問題	L (10-14 日、 cross-surface 整合まで含めると 4-6 週間)

translator 推奨

本 surface 単独で見た場合: Variant B を推奨。

理由: (1) Variant A は r19 不整合解消 (visual cleanup) だけで主要不満 (1)(2)(3) を解決しない。「素人臭さを取る」だけなら採用するが、 Justine が UI 再設計を回す意義としては薄い。 (2) Variant C は inbox model として理想だが、本 surface 単独で適用すると他 4 surface との IA 分裂が起きる。 cross-surface で inbox 化するなら mirror-me (Manager 最優先 persona) で先に検討するほうが ROI が高い。 member 単独で大胆変更する戦略的理由は薄い。 (3) Variant B は P1/P2/P3/P4/P5 の 5 強信号パターンをすべて適用しつつ、 nav・routing は不変、 RLS 不変、工数 M。推定不満 (1)(2)(3) を SOLVED 判定にできる唯一の variant。研究 §6 で指摘された最大リスク (P5 empty state copy が §2 forbidden wording に触れる) も、本提案では safe wording 雛形を明示し canon 適合を保証している。

cross-surface 観点 (Justine への補足質問)

もし 5 surface 全体で「inbox model に統一」という方向性に Justine が魅力を感じるなら、 mirror-me で Variant C 採用 + app-me で Variant B 採用 の組み合わせが現実的 (mirror-me の inbox 設計が member に逆輸入される将来 Round 2 で /app/me も C に移行する 2 段階戦略)。 member 単独で C にする選択は、 surface 横断方針が固まる前は推奨しない。

pick 形式

orchestrator に以下のいずれかで回答してください:
pick app-me=A (visual cleanup のみ)
pick app-me=B (推奨 — IA 再構成、 5 強信号パターン適用)
pick app-me=C (inbox model 移行、 cross-surface 影響あり)

kashi-ui-translator | ROUND_001 Stage 2 | app-me surface | 出力先: workspace/strategy/ui-redesign/ROUND_001/02_proposals/app-me__variants.html

app-me — Employee Dashboard (3 Variants)

主タスク (page primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満

残るリスク / 未解決事項

実装工数感

主タスク (page primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満

残るリスク / 未解決事項

実装工数感

主タスク (page primary job)

レイアウト構造 (above-fold composition)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満

残るリスク / 未解決事項

実装工数感

Justine への選択質問

translator 推奨

cross-surface 観点 (Justine への補足質問)

pick 形式