Variant C は「mirror ページの中の構造を整える」 (= Variant B) を scope 不足と判定し、
Justine の根本不満が「ロール別 nav 自体が複雑」 にあると仮定して、
全 user の post-login landing を 「いまあなたが向き合うべき事項の Inbox」 に統合する設計です。
Mirror は Inbox 内の 1 つの task として現れ、 クリックで Variant B 相当の drill-down view に展開されます。
既存 5 surface (/app/me, /app/admin, /app/ceo, /app/reviewer, /app/mirror) を
一段廃止し、 nav は 5 → 3 (Inbox / Discover / Settings) に減らします。
Justine の根本不満は「mirror の中」 ではなく「mirror へ辿り着くまで」 にある。 Round 2 hearing で「Inbox model が JP B2B SaaS culture に fit するか」 を必ず検証。
Variant C の drill-down view 自体は Variant B と同等構造のため、 「Inbox 廃止 → B に戻す」 移行コストは中程度。 Variant B mockup と並べて co-founder hearing 必須。
Picked variant: C — 大胆 (Unified Task-Inbox Model)。 Risk: High Impl: L (12-18日, A/B の 3 倍)
Variant A の token 統一 + Variant B の階層化 (Tier 1-5 構造) を 内包 しつつ、 最上位に「Manager Task Inbox」 という単一 entry point を置く設計。 「いまあなたが向き合うべきことは何か」 を 4-6 項目の actionable list として提示し、 各 task をクリックすると Variant B 相当の Mirror 詳細・GracePeriod 詳細・Dispute 詳細・upload flow 等へ drill-down します。 Manager にとって「ログイン → 何を見るか」 という判断コスト 0 化を目指します。
URL 構造変更:
/app/mirror/[managerId] → /app/inbox?lens=mirror&managerId=... の drill-down 化。
新規 default landing は /app/inbox。
既存 URL は redirect で保護 (mockup-only のため未実装)。
| 順 | Kind | Title | Grade / Status | Reason code |
|---|---|---|---|---|
| [1] | Pattern Update · Mirror | あなたの Manager Mirror が更新されました | STABLE | RC_INT_RECV_UP |
| [2] | Reflection Prompt | 直近主催ミーティング (経営会議, 2026-05-26) の振り返り | N/A | RC_REFLECT_INVITATION |
| [3] | Approval Pending · Dispute (あなたが提起) | あなたが提起した dispute 2 件、 reviewer 確認待ち | REVIEWER PENDING | RC_DISPUTE_PENDING |
| [4] | Coverage · Insight | チームカバレッジに改善余地 — 8 件が比較対象外 | WEAK | RC_QUALITY_LOW_DIARIZATION |
| [5] | Pattern Update · GracePeriod | GracePeriod 中: 設定期限 2026-06-15 | ACTIVE | RC_GRACE_PERIOD |
| [6] | Notification · Governance | tenant の visibility policy が更新されました (2026-05-25) | INFO | RC_NOTICE_POLICY_REFRESH |
Inbox 下には Variant B から継承した Positive observations stripe
(5 tile + boundary copy) を不変的 footer として配置。
さらに mockup 用 toggle で「Inbox が空のとき (canon §6 no-signal rule)」 の empty state も参考表示しています
(実 production では .task-list を完全置換)。
Drill-down 部分は task [1] (Mirror) でのみ展開を mockup 内に再現済み: Tier 1 banner (window + grade + 解釈 + 「これは判定ではない」) → Tier 2 (3 metric card: Interruption / Directionality / Sustained-drop-days) → Tier 3 (positive 5 tile, boundary copy 付き) → deep links (Tier 4 chart / Tier 4 個別イベント / Tier 5 比較不能理由)。
/app/inbox に統合し、 旧 5 surface (me / admin / ceo / reviewer / mirror) を drill-down 化Variant B が解決するのは 「mirror ページの中の構造」 までで、 「mirror へ辿り着くまでの nav cost」 「ロール往来時の breadcrumb 混乱」 は scope 外です。 Variant C は Justine の Round 1 不満候補 (推定) のうち 「back が CEO に行く」 「ロール別ダッシュボードを行き来する nav が複雑」 「何を見ればいいか最初にわからない」 の 3 件を nav レイヤーで根本解決 する戦略です。
Inbox model の本質は: ユーザーが どのロールであっても、 最初に見るのは「いま自分が向き合うべき task」 の list。 Manager は自分の Mirror 更新を task として受け取り、 Employee は自分の Mirror 更新を task として受け取る (= 同じ entry、 異なる data scope)。 RLS は変えず、 UI 層でのみ role-based task filter を新規実装。
根拠: research pattern P1 (summary-first 4/6 ref) の cross-role 拡張版 + Linear Inbox / Vercel Dashboard / Notion Inbox の cross-surface archetype + permanent-ui-principles §7 (default visible layer: one headline + 3-5 cards + 1 primary CTA per task) + canon §8 (cognitive load: ロール nav 5 個並列は「everything equally important」)
旧 nav (me / admin / ceo / reviewer / mirror) は 「ロール別の入口」 概念で構成されていましたが、 Inbox model 下では「入口は 1 つ (Inbox)、 中身は role + scope で filter」 という構造に変わるため、 nav 自体の数を減らせます。 Mockup では:
「ロール往来」 という mental model を捨てさせる代わりに、 nav は単純な「Inbox + 検索 + 設定」 の SaaS パターンに収束させました。 Linear / Notion / Vercel ヘッダーの構造と同型です。
根拠: Stage 1 ref Linear / Vercel / Notion の dashboard home shell。 canon §13 (calm pattern / generous whitespace) + canon §8 (cognitive load reduction)。
nav を 3 個に減らした代償として、 「Manager は今 mirror lens を見ている」 という context が薄れるリスクがありました。
軽減策として Inbox toolbar 内に lens switcher (tablist) を配置し、
active lens を --color-kashi-evergreen background で強調しています。
「自分が今どの lens を見ているか」 が常に視認可能。
Lens switcher と PortalHeader role chip (「Manager」) は併存することで、 「誰が 何の lens を 見ているか」 が page-subtitle (「視聴者: 田中部長 (Manager)」) と合わせて 3 重で示されます。 これは canon §3 (role boundary first) を nav レイヤーで強化する設計。
根拠: GitHub Projects view switcher / Linear filter tabs / Stripe dashboard view selector pattern。 canon §3 q1-q3 必須項目を Inbox 上で同時表示。
Inbox の sort dropdown は「新しい順 / 古い順 / イベント種別順 / Evidence Grade 順」 の 4 オプションのみ。 「Kashi が重要と判断した順」 「AI 推奨順」 「risk 順」 のような implicit ranking は 意図的に排除 しました。 canon §1「Kashi must NOT feel like: ... HR decision automation」 と canon §9「No dashboard may rank people morally」 が nav レイヤーでも適用されるべきという判断。
「AI が並べた順」 で task が並ぶと、 Manager は「Kashi の判定で重要なものから処理する」 という mental model になり、 「自分の自己振り返り」 から「Kashi 任せの consume」 にずれていきます。 これは Mirror の根本 framing から外れます。
根拠: canon §1 §9 + Linear / Vercel inbox の sort UI も user-explicit のみ (1/6 ref で AI rank 確認、 採用見送り)。
Variant B では「Banner 1 つ → MetricCard 3 つ → ...」 という縦長構造でしたが、 Inbox model では各 task card が 自己完結した summary である必要があります (ユーザーは drill-down 前に「これは何の task か」 を把握する必要がある)。 そのため各 card に必ず:
RC_INT_RECV_UP 等、 cream background mono)
+ boundary 行 (「これは判定ではない」 等の 1 行 disclaimer) を全 card で .task-card__boundary として
必須化。 これにより各 task が canon §5 評価 semantics の 7 要素のうち 5 要素
(grade / reason / window / what-not-prove / safe action) を card レベルで担保。
残り 2 要素 (data quality / scope) は drill-down に降格。
根拠: canon §5 §9 §11 必須項目を Inbox card レベルで担保 + Linear Inbox の task card archetype。
Inbox は「いま向き合うべきもの」 のみを表示し、 過去 30 日の確認済み task は
<details> accordion で畳んで「14 件」 のメタ数字のみ summary に表示。
Inbox を「鮮度のある entry」 として保ち、 archive は 1 クリックで取り出せるよう保持。
audit log への deep link を accordion 末尾に配置。
根拠: canon §7 progressive disclosure + Linear / Notion Inbox の archive pattern。
Variant C は research support の strong patterns (P1-P5, 4-6 ref) を全て継承していますが、 task-inbox archetype 自体は Stage 1 で 1-2 ref のみの弱信号 です。 この採用が Variant C を「Round 1 で選ぶには重い」 と評価される本質的な理由なので、 リスクと軽減策を逐一明示します。
| 確認されている ref | シグナル強度 | Kashi 文脈での適用 |
|---|---|---|
| Linear Inbox | strong / 1 ref | 「issue / PR / comment 全てが 1 つの Inbox に集約」 という cross-resource entry。 Kashi の「Mirror / GracePeriod / Dispute / Coverage / Notification」 を同パターンで統合。 |
| Vercel Dashboard (project list + activity feed) | weak / 1 ref | 「最新の deployment が Inbox 状に並ぶ」 archetype。 Kashi の「最新の Mirror 更新が Inbox 状に並ぶ」 に最も近い形。 |
| Notion Inbox (mentions / comments) | tangential / 1 ref | 「ロール横断の actionable item」 という framing 参考。 ただし Notion Inbox は単一データ種類 (mention) のみで、 cross-resource ではない。 |
対照: strong patterns (P1-P5) は 4-6 ref。 Inbox archetype はその 1/3 以下の根拠基盤。
日本の B2B HR SaaS は SmartHR / KAKEAI / カオナビ / ハイマネージャー 等、 いずれも「ロール別ダッシュボード」 型で Inbox model を主体採用しているケースは確認できていません。 Linear / Vercel / Notion は global SaaS (英語圏 dev tool 文化) のため、 JP HR persona (人事部長、 マネージャー、 顧問) が Inbox model に「これは私の道具」 と感じるかは未検証。 Manager 田中部長が初見で「Inbox は ToDo list か? Slack か?」 と混乱する可能性。
緩和 1 Inbox という英語表記の上に subtitle で「あなたが向き合うべき事項を、 1 つのタイムラインに集約しています」 という JA 説明文を必須配置 (mockup 反映済)。 緩和 2 各 task card の kind label を JA カタカナ / 漢字混在 (「Pattern Update · Mirror」 「振り返り」 「Approval Pending」) で「英語 SaaS 風」 にしすぎない。 緩和 3 Round 2 hearing で「Inbox という呼称 / model」 への反応を 最優先項目として測る。
根拠: project_kashi_dialogue_breakdown_doctrine.md + reference_jp_smb_ai_dx_market_facts.md (JP HR SaaS 文化観察)。
Inbox model の最大リスク。 「あなたは XX を解決すべき」 「至急 reply してください」 「未対応 task が 5 件あります」 のような todo-list 風コピーになると、 Kashi は canon §1 「employee surveillance」 / 「HR decision automation」 を 強く feel させる UI に変質します。 「Mirror が更新されました」 を「あなたは見ろ」 と書いた瞬間に Kashi ではなくなる。
緩和 1 全 task card のコピーを「受動 / 観察」 framing で統一: 「mirror が更新されました」 「振り返り することができます (任意)」 「dispute が 2 件、 reviewer 確認待ち」 「カバレッジに改善余地」。 強制感 / 命令形 / 期限プレッシャーは 0 件 (mockup 全 6 card 確認済)。 緩和 2 各 card の boundary 行で 「これは『あなたの主催の質』 を評価するものではありません」 「『あなたへの dispute』 はこの画面では表示されません (anti-retaliation rule §4 厳守)」 等の限定を毎回明示。 緩和 3 Inbox の sort オプションに「未対応 / 重要度」 系を入れない (前述、 user-explicit のみ)。
根拠: canon §1 §2 違反リスク高。 React 実装時には copy review (canonical wording 確認) を別途実施必要。
demo 組織のピロットユーザーは既に「mirror は /app/mirror/[managerId] にある」 という URL を覚えており、
bookmark や直リンクが存在している可能性。 突然 /app/inbox?lens=mirror に変わると初期 1-2 週間は混乱します。
緩和 1 旧 URL /app/mirror/[managerId] は 6 ヶ月間 redirect 保持 (React 実装時)。
緩和 2 初回 login 時に「Inbox にようこそ」 1 page tutorial を表示 (mockup-only 対象外、 React 実装時に追加)。
緩和 3 Inbox の「Mirror が更新されました」 task をクリックで drill-down 展開、 旧 mirror page と同等の Variant B Tier 1-5 構造が見える → 学習コスト最小化。
根拠: Linear が GitHub から移行時の UX (旧 URL redirect 保持 + 段階的 onboarding) を参考。
Variant B の Tier 5 empty state が「mirror ページの empty」 だったのに対し、 Variant C の empty state は 「Inbox 全体の empty」 になります。 「いま向き合うべき事項なし」 は「Kashi に問題視されていない」 ではないことを明示する必要があります。
緩和 1 「Inbox が空のとき」 mockup 内 toggle で参考表示済み (canon §6 no-signal rule)。 INSUFFICIENT grade chip + canonical verbatim copy「観察ウィンドウ内に新規 task はありません。 これは『問題なし』 を意味しません。 観測できなかった可能性 (録音不足 / 品質低下 / scope 外 / 比較対象不足) を含みます。」 + reason code 3 件 + 「カバレッジ確認」 「upload」 2 ボタンの honest empty state を構造化済み。 緩和 2 Inbox 下の Positive observations stripe は 常時表示 (Inbox が空でも表示) のため、 「Kashi が何も観測していない」 という錯覚を緩和。
根拠: canon §6 no-signal rule + EMPTY_STATE_AND_NO_SIGNAL_COPY_LIBRARY.md canonical wording 遵守。
translator の 推奨は Variant B でしたが、 Justine は C を pick しました。 この決定が後悔されないために、 B / C の差分を 12 axis で記録します。 Round 2 hearing で「B に戻すべきだった」 が分かった場合、 この表を逆引きで使えば移行コストの見積もりに直結します。
| 判定 axis | Variant B (中庸) | Variant C (大胆、 採用) |
|---|---|---|
| 解決する Justine 不満の数 | 5 件 (cognitive overload / no interpretation / empty fear / back-link / amateur visual) | 6 件 (B の 5 件 + ロール nav 複雑性)。 ただし 6 件目の確認は Round 2 hearing 待ち。 |
| scope | mirror-me ページ単独 (1 surface) | 5 surface 統合 (me / admin / ceo / reviewer / mirror すべて)。 他 4 surface translator にも C メッセージ通知必要。 |
| URL 構造 | 変更なし (/app/mirror/[managerId]) |
/app/inbox?lens=mirror&managerId=... 化。 旧 URL は 6 ヶ月 redirect。 |
| nav 構造 | 現状維持 (5 個) | 5 → 3 (Inbox / Discover / Settings) |
| 実装工数 | M (4-7 日) | L (12-18 日, A/B の 3 倍)。 PortalHeader 改修 + route 再配線 + inbox aggregation API 新規 + role-based task filter + migration script。 |
| RLS / API 変更 | 0 件 (UI 層のみ) | RLS 変更 0 件、 ただし inbox aggregation API は新規。 各 role の task filter ロジック新規。 |
| 学習コスト (既存 demo ユーザー) | 低 (「最初に banner を見るようになった」 程度) | 高 (1-2 週 tutorial + 旧 URL redirect + mental model 書き換え) |
| Research support 強度 | strong patterns 5/5 採用 (P1-P5, 4-6 ref) | strong patterns 5/5 採用 + 新規 archetype 1 個が弱信号 (1-2 ref) |
| canon §1 surveillance feel リスク | 低 (mirror ページの中だけ) | 中 (task = やるべきこと framing が滑る危険、 § 3 で 4 軽減策あり) |
| retreat-path (やり直しコスト) | 低 (mirror ページのみ rebuild) | 中 (5 surface migration の roll-back コスト、 ただし drill-down 自体は B 構造なので「Inbox 廃止 → B に戻す」 が部分的可能) |
| JP B2B SaaS culture fit (HiManager / SmartHR 観察) | fit (dashboard 型を継承) | 未検証 (Linear / Vercel / Notion は global dev tool 文化、 JP HR persona には未検証) |
| Round 2 hearing で測るべき項目数 | 3 件 (MetricCard 3 件選定 / 観測窓 default / grade pill 色) | 5 件 (B の 3 件 + Inbox model fit + lens switcher の発見性 + task copy の surveillance feel) |
Variant C を pick する妥当性は以下 3 条件が全て成立するときに最大化します。 Round 2 hearing で 1 つでも崩れたら Variant B への戻し検討:
| § | 判定 | mockup 内の根拠 |
|---|---|---|
| §1 core doctrine (no surveillance feel) | PASS WITH CAVEAT | eye / camera / police アイコン 0 件 (確認済)。 red alert 0 件 (semantic 色は warning B45309、 error B91C1C は未使用)。 surveillance verb 0 件。 CAVEAT: Inbox model は「task = やるべきこと」 framing が滑ると surveillance feel 化するリスクあり (§3 リスク 2 参照)。 軽減策として全 task card コピーは「受動 / 観察」 framing 統一 (「mirror が更新されました」 「振り返り することができます (任意)」 「dispute が reviewer 確認待ち」)、 強制 / 命令 / 期限プレッシャー 0 件 (mockup 全 6 card 確認済み)。 |
| §2 forbidden wording | PASS | 「検知」「予測」「健康スコア」「生産性スコア」「at-risk」「all clear」「no issue」 一切無し (mockup index.html grep 結果 0 件)。 Grade 用語のみで「STABLE = 観測の信頼度」 を必ず boundary 注釈。 「no qualifying signal in this observed window」 を canonical 採用 (empty state)。 |
| §3 role boundary first | PASS | 3 重 role context: (a) PortalHeader role chip 「Manager」 (常時表示)、 (b) page-subtitle 「視聴者: 田中部長 (Manager)」 (cream pill)、 (c) lens switcher active state (「現在 Mirror lens」 強調)。 「他の Manager の mirror へ遷移するパス」 0 件。 |
| §4 visibility per role (anti-retaliation 重点) | PASS | Inbox 内の Dispute task は「あなたが提起したもの」 のみ (REVIEWER PENDING 状態)。 「あなたへの dispute 一覧」 0 件。 task [3] の boundary 行で「『あなたへの dispute』 はこの画面では表示されません (anti-retaliation rule §4 厳守)」 を明示。 名前付き subordinate データ 0 件 (Inbox 全 task で氏名表示 0)。 IgnoredTurn / Chilling は drill-down deep link のみ、 集計件数表示が前提 (Variant B 継承)。 inbox-footer note でも anti-retaliation rule を再強調。 |
| §5 evidence semantics | PASS | 各 task card で 5 要素 (grade chip + reason code pill + window in meta + what-not-prove in boundary + safe action) を担保。 drill-down 展開時には Tier 1 banner で完全 7 要素 (window / 対象件数 / grade / quality / 解釈 / 「これは判定ではない」 / safe action)。 mockup で task [1] (Mirror) を default 展開済みで Tier 1-3 構造を視認可能。 |
| §6 no-signal rule (重点) | PASS | 2 段 で対応: (a) Inbox が空のとき (mockup 内 toggle で参考表示) — INSUFFICIENT grade chip + canonical verbatim copy「観察ウィンドウ内に新規 task はありません。 これは『問題なし』 を意味しません」 + reason code 3 件 + 2 つの次アクション ボタン (coverage / upload)、 (b) Positive observations stripe で常時 boundary copy「これは観測されたポジティブな構造パターンです。 別の問題の不在を意味しません」 を表示。 「all caught up」 「no problem」 「safe」 「clean」 0 件 (確認済)。 |
| §7 progressive disclosure | PASS | Default visible layer = 1 headline (H1「あなたのインボックス」) + 1 short subtitle + 1 toolbar + 1 context-pill row + 6 task cards (drill-down 折り畳み)。 Mirror task のみ default で drill-down 展開 (mockup 確認用、 production では default-collapsed)。 Past notifications + Empty state demo + Positive stripe で 3 段の disclosure 階層。 |
| §8 cognitive load | PASS | H1 1 個。 task card は同型 (kind / grade / reason / title / summary / boundary / meta / action の固定 8 要素) で「everything looks equally important」 を解消。 Lens switcher の active state が「自分が今どの lens を見ているか」 を視覚的に強調。 6 task の grade-coloured left border (STABLE 緑 / WEAK 黄 / INFO 青 / NEUTRAL 灰) で「種類で読む」 を支援。 |
| §9 dashboard rules | PASS | 各 task card が「what shown / who (自分のみ) / window / grade / reason / action / not-prove」 を内包。 ランキング 0 件 / health score 0 件 / 個別 subordinate データ 0 件 / AI suggested ranking 0 件 (sort はユーザー明示のみ)。 |
| §11 internal screen 13 要素 | PASS | role label (PortalHeader chip + subtitle) / visibility boundary (subtitle + task [3] boundary 行 + inbox-footer note) / grade (各 task chip) / reason (各 task pill) / window (context pill + drill-down) / quality (drill-down 内) / safe actions (各 task の 1 primary action + footer Dispute) / forbidden actions (anti-retaliation note 明示) / audit (Dispute → reviewer 確認待ち UI で内包) / empty (Inbox empty toggle + reasons) / error (mockup 対象外) / permission (anti-retaliation note) / dispute (footer + task [3])。 11/13 mockup 内、 残り 2 件は対象外 surface。 |
| §12 a11y baseline | PASS | H1 1 個。 heading 順序 (H1 → h2 = Positive stripe → h3 = empty state)。 全 interactive 要素 keyboard 操作可 (button / a / details/summary)。 focus visible (outline 2px evergreen)。 全 grade pill / chip に aria-label。 task card に role="listitem"、 task-list に role="list"、 lens switcher に role="tablist"。 Tablet 900px / phone 600px breakpoint で grid 折り返し。 color + text label 併用 (grade chip 全部)。 |
| §13 visual system (重点) | PASS | off-white base (#fafaf7) / evergreen + emerald accent / cream highlight / Lucide outline icon (SVG 簡略) / 大量 whitespace (--space-4..--space-12)。 eye / camera / police / red alert / AI glow / neon gradient / wellness pastel 0 件。 Inbox の task card は「Linear inbox の暗色」 ではなく off-white inbox として Kashi 色化 (Stage 1 §C 採用注意点に明示的に遵守)。 calm pattern / restrained cards / serious enterprise feel 維持。 |
kashi/src/app/app/mirror/[managerId]/page.tsx) からの diff本 mockup は static HTML/CSS のみで、 既存 React 実装には一切 write していません。 Round 1 翻訳者の C 提案 → mockup → 後続実装 phase で参照する差分は以下です。 Variant B 差分との 重複 diff (token 統一、 IgnoredTurn k-anon、 Dispute footer) は再記載省略 (B の DESIGN_DECISIONS 参照)。
| セクション | 現状 (line 番号は kashi/src/app/app/mirror/[managerId]/page.tsx) | Variant C mockup での変更 |
|---|---|---|
| URL / route | /app/mirror/[managerId] を default landing として持つ |
新規 default landing は /app/inbox。 旧 URL は /app/inbox?lens=mirror&managerId=... へ permanent redirect (6 ヶ月) または server-side rewrite。 |
| PortalHeader (5 → 3) | kashi/src/components/portal/PortalHeader.tsx に 5 nav item (me / admin / ceo / reviewer / mirror) |
nav item 3 個 (Inbox / Discover / Settings) に再構成。 旧 5 nav は 削除 (URL redirect で互換)。 role chip は維持。 |
| page.tsx 全体 | line 1-1000+ で mirror 専用 page を構成 (TimeWindow / RevealNames / EvidenceGradeBanner / MetricCard×6 / chart 2 種 / IgnoredTurn / Chilling / GracePeriod / PositiveCount / Dispute) | mirror 専用 page を 削除、 新 kashi/src/app/app/inbox/page.tsx を新設。 旧 page.tsx 内のロジックは drill-down view component (MirrorDrilldown.tsx) として再利用 — 構造は Variant B Tier 1-5 そのまま。 |
| Inbox aggregation | (未実装) | 新規 API: GET /api/inbox?role=manager&userId=...。 各 role の view-allowed task を aggregation するサーバーロジック新規。 RLS は変えない (= 各 task の source data に対しては既存 RLS をそのまま適用)。 |
| Task filter (role 別) | (未実装) | Manager 視点では: Pattern Update (own mirror only) + Reflection Prompt (own only) + Approval Pending (own-filed disputes only) + Coverage (own team) + GracePeriod (own status) + Notification (tenant-wide governance) の 6 種 task のみ。 「あなたへの dispute」 task は永久に表示しない (anti-retaliation rule §4)。 |
| Lens switcher | (未実装) | 新規 component LensSwitcher.tsx (Mirror / Coverage / Disputes の 3 lens、 tablist UI)。 active state を URL query param ?lens= に sync。 |
| Past notifications accordion | (未実装) | 新規 component PastNotificationsAccordion.tsx (確認済 task の archive、 default 折り畳み、 audit log への deep link)。 |
| Inbox empty state | (未実装) | 新規 component InboxEmptyState.tsx。 Variant B Tier 5 と 同等構造 (INSUFFICIENT grade chip + canonical verbatim copy + reason code 3 件 + 2 ボタン)。 |
| Sort dropdown | (未実装) | 「新しい順 / 古い順 / イベント種別順 / Evidence Grade 順」 の 4 オプションのみ。 「重要度」 「AI 推奨」 系オプション 意図的に排除 (canon §1 §9)。 |
| Mirror page back-link | line 444 周辺の back-link: /app/ceo に向くケースあり |
そもそも back-link 概念を 廃止。 Inbox に戻る単一動線のみ (lens switcher で同一画面内移動)。 「back が CEO に行く」 が根本解消。 |
| Drill-down view 内 (Variant B 構造の再利用) | (現状の Mirror page) | Variant B の Tier 1-5 構造をそのまま MirrorDrilldown.tsx として包む。 Tier 2 の MetricCard 6→3 厳選 / Accordion 化 / boundary copy 強制 / 「これは判定ではない」 注釈は Variant B から継承。 |
| Inbox の Positive stripe (Variant B Tier 3 を昇格) | line 535-539: H1 直後の高位置 PositiveCount | Inbox の 下部 footer stripe として常時表示。 boundary copy 必須表示。 「Inbox 空でも Kashi は観測している」 を視覚的に伝える役割。 |
| Variant A 継承差分 (token 統一 35 件) | (Variant A 差分参照) | Variant C も Variant A の全 token 統一を継承。 詳細は B の DESIGN_DECISIONS 「5. 既存実装からの差分」 参照。 |
| 新規 component | 役割 | RLS / API 影響 |
|---|---|---|
InboxLayout.tsx |
Inbox 全体の shell (subtitle / toolbar / context pills / task list / Positive stripe / footer) | 0 (UI 層のみ) |
TaskCard.tsx |
各 task card の atomic component (kind label + grade chip + reason code + title + summary + boundary + meta + action) | 0 (UI 層のみ) |
LensSwitcher.tsx |
Mirror / Coverage / Disputes の lens 切替 tablist | 0 (URL query param 駆動) |
PastNotificationsAccordion.tsx |
確認済 task の archive、 audit log への deep link | 0 (UI 層のみ) |
InboxEmptyState.tsx |
Inbox が空のとき canonical no-signal wording 表示 | 0 (UI 層のみ) |
MirrorDrilldown.tsx |
Variant B の Tier 1-5 構造を drill-down view として再利用 | 0 (UI 層のみ) |
/api/inbox route handler |
各 role の task aggregation API。 source data の RLS はそのまま適用 (= UI 層の aggregation のみ) | API 新規、 RLS 変更 0 |
BoundaryNote.tsx (Variant B 継承) |
verbatim copy 強制表示 + tampering 防止 | 0 |
cross-surface 影響: 旧 4 surface (/app/me /app/admin /app/ceo /app/reviewer) も
Inbox に統合される前提のため、 それぞれの translator にも Variant C のメッセージを通知して整合を取る必要があります。
Round 1 の kashi-ui-orchestrator に依頼: 他 4 surface の translator に「mirror-me が C を採用、 他 surface も C 相当に揃える」 旨を伝達。
Round 1 の他 3 surface (me / admin / reviewer) の variant pick は本 mockup と同期した cross-surface design 前提で行ってください。
以下の判断は Round 1 段階では mockupper が 妥当な default を選んだだけ です。
Justine が「これは違う」 と感じたら orchestrator に redo mirror-me C <feedback> で再構築指示してください。
Variant C 固有の弱信号性 (task-inbox archetype) を踏まえ、 Round 2 hearing で必ず検証すべき項目 も併記しました。
/app/inbox?lens=mirror&managerId=...) への遷移を想定していますが、
インライン展開のまま production 化する選択肢もあります (page 遷移 0、 SPA 感、 ただし URL が変わらないので bookmark しにくい)。
判断: 別 route 遷移 (現案、 URL bookmarkable) / インライン展開のまま (page 遷移 0、 SPA 感) / hybrid (1 click でインライン展開、 2 click で full route)
上記 6 項目のうち 1, 3 で否定的反応が複数出た場合は Variant B への retreat 検討。 Variant C の drill-down view 自体は Variant B 構造のため、 「Inbox 廃止 → mirror-me page 復活」 の移行コストは中程度です。