Design Decisions — mirror-me (Manager) — Round 1 — Variant C (v2)

surface: mirror-me · role: MANAGER · round: 1 · variant: C (v2 — cross-role design unified) · baseline: app-me/C

本書は mirror-me/C v2 の設計意図、 採用 token、 IA 採用根拠、 Manager role 固有 adaptation、 そして v1 (overwrite 前) からの差分を記録します。 Justine の feedback 「app-me/C はけっこういい、 これを基礎として role を跨って同じ感じの雰囲気にする、 いま role によってデザインが違いすぎる」 に応答した cross-role design 統一版です。 将来の実装エンジニアおよび admin / ceo / reviewer surface 担当 mockupper が、 「mirror-me v2 はなぜこの形か」 を辿れることを保証します。

本案の核 (1 文)
app-me/C の design language を 100% inherit し、 Manager role 固有の adaptation (scope 範囲 / item kind 構成 / nav 2 番目) のみ差し替えた cross-role 統一の最初の実装

1. 主タスクと上位構造

決定: Manager のメインタスクを「自分が主催した meeting に閉じた reflection 確認」 と定義し、 inbox 形式に集約した

Manager は本来「部下を監視するための dashboard」 を欲しがる感情がある (典型 SaaS パターン)。 しかし Kashi canon (permanent-ui-principles §2) は surveillance を明示的に禁止。 よって Manager Mirror の主タスクは 「自分が主催した meeting において、 自分自身の facilitation パターンを reflection する」 こと一点に絞った。 app-me/C の Member 「My Reflection Inbox」 と完全に並列の構造 (「自分のために自分を見る」) で揃えた。

canon: permanent-ui-principles §2 (Product Truth Rules) + DATA_VISIBILITY_MATRIX §4 (Manager row) + WORKER_FACING_TRUST_CANON §2.3 (Manager notice)

決定: app-me/C の IA を 1:1 で移植 (privacy-banner → scope-banner / filter-bar 6 chip / inbox timeline 3 group / footer 3 block)

Justine feedback 「role によってデザインが違いすぎる」 への直接応答。 上位構造の論理は同じ (inbox-first / time-grouped / mixed-kind cards / footer trust-block 3 段) で、 Manager 固有データのみ差し替えた。 これにより 5 つの role surface 間で 「同じ Kashi の中にいる」 感覚を保てる。

feedback: 2026-05-28 Justine 口頭、 baseline: /tmp/kashi-mockup-share/03_mockups/app-me/C/index.html (49KB)

2. レイアウト

決定: PortalHeader 2-row sticky を app-me/C と完全同じ構造で採用

行 1 = brand (wordmark + org + role-badge + user-pill)、 行 2 = nav (3 items)。 色 / フォント / 間隔 / role-badge mono 表示 / avatar 円形 28px のすべてが app-me/C と一致。 違いは: role-badge 表示 = "ROLE: MANAGER"、 avatar 1 文字 = "田"、 user-pill 名前 = "田中部長 (営業部)"。

baseline: app-me/C lines 771-793

決定: nav の 2 番目を 「Reflection」 → 「Mirror」 に変更

Member の場合 nav-2 は 「Reflection」 (自分自身の振り返り = Member 個人ページ)。 Manager の場合 nav-2 は 「Mirror」 (自分が主催する meeting 群の facilitation mirror) と命名。 Inbox / Settings は同一。 意図的に nav-2 のみ role 固有の名称を許容することで、 全 role surface に共通の「inbox = 主タスクの集約点」 + 「nav-2 = role 固有の探索面」 のパターンを作る。

canon: WORKER_FACING_TRUST_CANON §5.2 (manager-subject-of-dispute) + DATA_VISIBILITY_MATRIX §4 row 2

決定: max-width 860px、 column 1 本の縦長 timeline、 sidebar なし

app-me/C と同じ value。 「inbox は読み物」 という mental model を強化するため。 sidebar (chart / filter tree) は意図的に削った: Manager に「dashboard」 感覚を与えると surveillance UI に傾く。

canon: permanent-ui-principles §7 (Progressive Disclosure) — fold-above は inbox 4-5 件 only

3. 採用したトークン

すべて app-me/C の :root から verbatim でコピー。 1 token も変更・追加なし (cross-role consistency を保証)。

TokenValue使った場所
--color-kashi-evergreen#2F6B4Anav-active border、 avatar bg、 unread dot、 kind-pattern dot、 grade-stable dot
--color-kashi-evergreen-deep#1F4A33h1 / h3 / page-title、 role-badge bg、 filter-chip.active bg、 btn-primary bg、 boundary 帯 border-left
--cream#F5F0E6btn-secondary hover、 scope-chip bg、 inbox-item-boundary bg
--emerald-50#ECFDF5privacy-banner (scope-banner) bg、 grade-stable chip bg (近似)
--ink / --ink-soft / --ink-muted / --ink-faint#0A0E1A / #2A3A1E / #4A5160 / #6B7280本文 / 副題 / org-name / kicker、 mono code label
--kashi-grade-stable / -emerging / -weak / -insufficient / -blocked#2F6B4A / #2563EB / #D97706 / #9CA3AF / #6B72805 種類の grade-pill の dot のみ (色単独で意味を持たせない)
type scale: --text-h1 40 / --text-h2 32 / --text-body 16 / --text-body-sm 14 / --text-caption 12同上page-title (h1) / inbox-item-title (body 500) / inbox-item-desc (body-sm) / kicker (caption)

Font stack (3 family、 app-me/C と同じ)

4. 採用した evidence-grade 表現

色単独で意味を持たせない (a11y / color-blind safe)。 すべての pill が 色 dot + テキストラベル + 大文字 mono の三重 encoding。 本 mockup で実際に出現する grade は 4 種類:

Grade使用箇所意図
STABLE / E2明日の 1on1 prep (member_001) + Positive observation (turn-taking gini)「観測の信頼度が高い」 を示すだけ。 評価ではないことを boundary 帯で必ず添える。
EMERGING / E1開発チーム週次 Reflection prompt (interruption_self_emit_rise)「観測中、 まだ判断はしない」 段階。 Manager に「気にし始める」 だけを促す。
INSUFFICIENT1on1 prep (closed) member_004 (window 内 2 回のみ)母集団不足を 明示。 「データがあれば判定する」 という幻想を避ける。
BLOCKED2026-05-02 部長会議 (low_diarization_confidence)話者別溜まりが低いため abstain (押さえる)。 安全側に倒した no-signal。

意図的に出していない grade: WEAK (弱い兆候)、 HIGH_CONFIDENCE_STABLE (高信頼安定)。 Manager surface での過剰断定を避けるため、 v2 では STABLE 止まり (E2) としている。

5. Manager role 固有 adaptation の 4 点

(a) Scope banner (app-me/C の privacy-banner と同じ枠、 文言だけ Manager 用)

「このページはあなた自身の reflection 用です」 + 「可視範囲: 自分が主催した会議のみ・ 部下個人のスコア/登場回数などは表示されません」

Member 版 (app-me/C) は 「過去 24 時間に誰が自分のデータを見たか」 を見せる。 Manager 版は逆方向で 「あなたが何を見られないか」 を最初に提示。 これは canon DATA_VISIBILITY_MATRIX §4 Manager row + permanent-ui-principles §2.1 anti-surveillance の表面化。

canon: DATA_VISIBILITY_MATRIX §4 + WORKER_FACING_TRUST_CANON §2.3

(b) Filter chip 構成 (Member 版と 2 つ差し替え)

chipMember (app-me/C)Manager (本案)
1AllAll
2UnreadUnread
3PatternsReflection (自己振り返り prompt)
41on1 prep1on1 prep
5NoticesNotices
6DisputesApprovals (forwarded dispute)

Member は自分への dispute を 「filed」 として見る (自分が起こした)。 Manager は dispute を 「forwarded to reviewer」 として通知のみ受ける (自分は判定権限なし)。 意味が違うため chip 名を変更。

(c) Inbox item kind の 6 種類 (Member 5 → Manager 6)

(d) 各 item card の追加 chip = scope-chip

window / grade / reason 3 chip に加え、 必ず scope: self-hosted または scope: anonymized を併記

Member 版にはなかった 4 番目 chip。 Manager surface 固有の安全装置。 「この observation の根拠データは何の scope に閉じているか」 を 1 行で示し、 surveillance 連想を阻止。 cream 背景 + ink-soft 文字で目立たせすぎない。

canon: DATA_VISIBILITY_MATRIX §4 Manager row (self-hosted-only visibility) + NO_PAYLOAD_ARCHITECTURE §1 (anonymized rollups)

6. PositiveCount item の boundary copy (canon verbatim)

採用 verbatim copy: 「これは観測されたポジティブな構造パターンです。 別の問題の不在を意味しません。」

Justine 指示の verbatim 文言を inbox-item-boundary 帯 (cream bg + evergreen-deep border-left 3px) に <strong> 強調。 続けて 「別の構造点 (interruption / topic-shift) は独立して観測されます」 を補足。 これにより 「Kashi は良いことを言いたいだけの SaaS ではない」 という設計姿勢を 1 item で証明。

canon: WORKER_FACING_TRUST_CANON PositiveCount disavow pattern + permanent-ui-principles §6 (no-signal rule)

7. 削った要素 (v1 mirror-me/C との差分)

v1 (overwrite 前) には以下があったが、 cross-role consistency のため削除:

結果: v1 が複数の Variant B 要素を持ち込んだ 「複合 C」 だったのに対し、 v2 は app-me/C の純粋 inbox 構造に揃った 「scaffold C」。 Justine feedback 「同じ感じの雰囲気」 を満たすため、 機能の引き算側に倒した。

8. 追加した要素 (app-me/C に対する Manager 固有)

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

未解決 1: app-me/C の 「dispute filed (Member 自身が起こした)」 と Manager の 「approval pending (member からの dispute を forwarded)」 は 同じ ticket の両面。 Round 2 で 2 surface が同じ ticket を見たときの整合表示 (両者は別 view を見る必要あり) を別途検討する必要。
未解決 2: Manager nav の 「Mirror」 (nav-2) は本 mockup では link のみで、 詳細 page は存在しない。 Round 2 以降で 「Mirror」 詳細 page が必要かを判断。 仮に必要なら inbox item の 「詳細を見る」 が遷移先になる。
未解決 3: 田中部長 (営業部) の persona 設定は demo data。 本実装時には 8 名以上の team で k-anonymity floor (canon §6) を満たすメンバー構成を必ず確認。
トレードオフ: 引き算した結果、 v1 にあった drill-down accordion (1 click で Tier 1-5 展開) が消えた。 「inbox から離れず詳細を見たい」 power user には少し不便。 ただし「inbox = 入口」 のシンプルさを優先。

10. Canon-verify 結果 (forbidden patterns grep)

2026-05-28 LESSONS 適用、 完成時 self-audit:

パターン件数判定
¥[0-9]+,[0-9]{3} (金額)0OK
90 ?日 / 60 ?日 / 180 ?日0OK (window はすべて 30 日に統一)
Google Meet / Microsoft Teams / Webex0OK
SSO / SAML / OIDC / SCIM0OK
SOC 2 / ISO 27001 / ISO 27018 / ISO 304140OK
専任 CS / ソリューションエンジニア / カスタマーサクセス0OK
離職率.{0,3}[0-9]+ ?% / ROI ¥ / 生産性.{0,3}[0-9]+ ?%0OK
完全削除証明0OK

11. 実装フェーズへの引き継ぎ

このモックアップを実装する際の注意:

12. v1 → v2 の差分まとめ (1 行)

v1 (overwrite 前): dark portal-header + lens-switcher + drill-down accordion + positive-stripe + past-accordion = 「mirror-me 独自 design」
v2 (本案): app-me/C 完全継承 + scope-chip + boundary 帯 + 6 filter chip = 「cross-role 統一の最初の実装」

Generated by kashi-ui-mockupper · 2026-05-28 · baseline = app-me/C (49KB) · output 2 files only