Design Decisions — app-admin — Variant C (大胆 / Operational Task Inbox)

主タスク: 「admin の inbox にある operational task を順番に消化する」。 admin は 「何をすべきか」 を考えない。 inbox が priority 順に提示する。 Stripe Dashboard の 「tasks widget」、 Okta Admin の 「pending tasks section」、 Linear の inbox UX を operational task に転用した archetype。

この変更の含意は深い:

• 「11 アクションのうちどれを今やるべきか」 を admin が選ぶ必要が無くなる (C-A1 完全解決)
• 「何もしなくていい状態」 が明示的に可視化される (queue が空 = 観察ウィンドウ内に新規 task なし)
• HR SaaS dashboard との形式的差別化が最も明確 — kao나비 / SmartHR は 「全員データ俯瞰」、 Kashi は 「処理待ち 6 件」

根拠: app-admin__variants.html Variant C 「主タスク」 セクション · researcher §3 Okta R4 + Stripe R1 「tasks widget」 (N=2) · canon: permanent-ui-principles §7 progressive disclosure + §8 「one primary CTA」 の最強実装

Above-fold は以下が見える:

1. PortalHeader (簡素 nav 3 items) — 管理 Inbox (badge: 6) / 設定 / ヘルプ。 admin role の現状コンテキスト維持
2. H1 = 「処理待ちタスク」 + role chip — admin が今いる場所を即明示
3. Scope Boundary Banner (max strength) — evergreen filled bg、 cream text。 「意図的にこの画面から存在しません」 をベタ表記
4. Inbox state 3 カード — 処理待ち / 完了 (今週) / 保留。 数値のみ、 ドリル先は inbox 内 (operational 完結)
5. Priority queue 上位 2-3 行 — 「高 (オレンジ) ユーザー招待承認 3 件」 等が見える

スクロール後に: queue の残り行 → 「背景情報」 (組織概要 fold) → 「設定」 (8 項目 fold) → footer。

根拠: permanent-ui-principles §7 「default visible layer: 1 headline + 1 short explanation + 3-5 cards + 1 primary CTA + 1 trust note」 完全準拠。 Inbox row 上位 4 行が 「3-5 cards」 を充足、 Scope Banner が 「trust note」 を兼ねる。

B 版は white background + 3px left border + ink text の控えめ banner。 C 版は evergreen filled background + cream text + 大型 shield icon でページ上で最も目立つ要素にする。 これは canon §1 「The UI wins by showing less」 の物理実装 — 「不在」 を 「設計的選択」 として最強に明示する。

具体的文言差分:

根拠: orchestrator brief 「Scope Boundary Banner は max strength」 verbatim · researcher P-4 Stripe + GitHub + Okta + Google WS 由来の banner pattern を最強モードで適用 · canon §3 (role boundary first) + §8 (bypass forbidden)

canon: design_system_v1.md §1-§4 verbatim · invent した token は 0 件

design_system_v1 §1 「badges must include both color AND text label」 + permanent-ui-principles §12 「badges not color-only」 に従う。 優先度バッジは色だけでなく必ず日本語テキスト 「高 / 中 / 低」 を併記する。

意図的に red (--kashi-state-error) を使わない: design_system_v1 §1 「red は true error states only — never for risk detected or analyzer output」。 operational task は 「処理が必要な状態」 で 「赤色警告」 ではない。

evidence-grade 色との意図的整合: priority-mid に --kashi-grade-emerging (青系) を使うことで、 evidence-grade UI と統一感を作る。 これにより future surface (mirror-me 等) との視覚言語整合性が保たれる。

根拠: design_system_v1.md §1 (Evidence-grade badges + Rule) · permanent-ui-principles §12 (a11y baseline) · §13 「No red alert dashboards」

Kashi canon §6 「No Signal Rule」 は 「no qualifying signal」 never means 「no issue」。 「all clear」 「問題なし」 「健全」 系の表現は全て forbidden。

Inbox 空状態のテキスト (mockup-only phase switcher で確認可能):

観察ウィンドウ内に新規 operational task はありません

直近 7 日 (2026-05-20 〜 2026-05-27) で、 admin の対応が必要な operational task は検出されませんでした。 これは 「問題が無い」 ことを意味しません — operational task の検知対象外の状態 (例: 設定変更の提案がまだ無い、 アップロードが当該期間に存在しなかった、 等) も含みます。

重要な技術的選択:

• 「観察ウィンドウ」 という Kashi 固有用語を使う — permanent-ui-principles §2 approved wording
• 「問題が無いことを意味しません」 を明示 — canon §6 strict
• 「健全」 「問題なし」 「Clean」 「Healthy」 等の言葉は 0 件
• 完了タスクへのリンクは提供 (作業履歴は admin にとって operational 必要)

根拠: permanent-ui-principles §6 (No Signal Rule) verbatim · §2 「forbidden wording: no issue detected / all clear」 · orchestrator brief 「§6 『観察ウィンドウ内に新規 operational task はありません』 verbatim」 指示

B 版で 「primary CTA カード」 + 「KPI strip」 + 「Secondary 4 cards」 + 「Tertiary fold」 + 「TeamRows」 として並んでいた要素を、 C 版は以下に再配置:

意図: admin の primary affordance を 「処理待ちタスク」 一極集中させる。 頻度の低い設定変更は意図的展開を要求 (cognitive load を queue 処理に集中)。

根拠: variants.html Variant C 「採用する研究パターン」 「組織概要」 「設定」 fold 化方針 · permanent-ui-principles §7 progressive disclosure 最強実装

B を pick: 着実に短期に出荷する。 既存 user を混乱させない。 後から C に進化させる余地は残せる (B の Primary CTA カードを inbox 0 番目 row と見做せば C へ連続)。

C を pick: Round 1 で 「方向性議論」 を最大化する。 co-founder/メンターから 「inbox 化は admin の認知モデルとして正しいか?」 という戦略 feedback を取りに行く。 実装 15-20 日のコストは、 設計討論の価値で正当化する。

中間案: Round 1 で C mockup を見せ、 「B を ship、 C を 6 ヶ月先の v2 北極星として記憶する」 という戦略判断もあり得る。

このモックアップを React 化する際の注意:

• 該当する Kashi コード: kashi/src/app/app/admin/page.tsx (全面書き換え)
• 影響を受ける共有コンポーネント:
  • kashi/src/components/portal/PortalHeader.tsx — role-aware nav の構造変更 (現状 6 item flat → role 別 3-5 item dynamic)
  • kashi/src/app/app/layout.tsx — role context provider が nav item を提供する責務に
• 必要な新規コンポーネント:
  • InboxQueue — priority queue rendering, sort, filter
  • InboxRow — task row with priority badge + action
  • ScopeBoundaryBannerMax — evergreen filled banner (B 版とは別 variant component に)
  • PriorityBadge — 高/中/低 + a11y label
  • FoldableSection — 既存があれば再利用、 なければ作る
• 必要な新規 backend service:
  • Operational Task Aggregator — ユーザー招待 pending / cron job 失敗 / 課金 alert / 設定変更承認待ち / speaker alias 未割り当て / データ品質 alert 等を統合 query する layer
  • 各 source (auth invitations / cron logs / billing webhooks / settings audit log / speaker_aliases / data_quality reports) からの aggregation spec
  • API: GET /api/admin/inbox?filter={...}&window=7d
• routing 互換性:
  • 既存 /app/admin/longitudinal /app/admin/coverage /app/admin/readiness 等は backward compat で 200 を返すが、 nav からは到達不能
  • direct URL アクセスには 「この画面は廃止予定」 banner を表示
• r19 既存課題のうち本案で同時解決されるもの:
  • §6.2 Color semantics inconsistent — priority badge + state strip の 3-tier 色階層で統一
  • §7 progressive disclosure violation — inbox 一極集中 + 2 fold で完全準拠
  • §8 cognitive load — equal-weight CTA spam が構造的に発生不可能に
  • §11 internal screen — role label / scope banner / safe action / audit semantics を inbox row 単位で自然に含む
• JA copy review が必要な箇所:
  • Scope Boundary Banner max 文言 (haseruida@ + Justine review)
  • Empty state 文言 (canon §6 verbatim、 修正禁止)
  • Task category タグ (USER PROV / JOB ALERT 等) — 英語/日本語のどちらに統一するか

1. 「admin の仕事 = inbox 処理」 という抽象は正しいか? — Kashi admin が実際の業務で 「キューを処理する」 ように働くなら C は適合。 「ダッシュボード俯瞰してから判断する」 タイプなら B が適合。
2. HR SaaS との差別化を 「banner で語る」 vs 「構造で語る」 のどちらが投資家・パイロット顧客に響くか? — C は demo で見せれば 「画面に何もない (= 監視ではない)」 が即伝わる。 ただし機能不足と誤解されるリスクもある。
3. 15-20 日の cross-surface 工数を Round 1-2 サイクルで負担できるか? — B (5-7 日) で着地し、 後で C へ進化させる選択肢が常にある。 C を直接選ぶのは 「もう B を経由する必要がない」 と判断できる場合のみ。
4. 「利用状況把握」 (C-A5) を fold 内に格下げすることに admin user が耐えられるか? — pilot 顧客 (人事部 鈴木さん dummy) に聞ける質問。 「Inbox 主役 + 利用状況は折りたたみ」 と 「KPI 並び主役 + Inbox は補助」 のどちらが日常 workflow に近いか。
5. 「PortalHeader 6 items → 3 items」 という変更が、 他 role (manager / reviewer / executive) に与える影響をどう受け止めるか? — admin 以外の role の nav は今回 mockup で触っていない。 他 surface の variant pick と整合性を取る必要あり。
6. 「処理待ち 0 件」 状態が頻発する pilot 初期に C で大丈夫か? — 「観察ウィンドウ内に新規 operational task はありません」 が毎日表示される顧客体験は、 「画面が空っぽに見える」 リスクがある。 完了履歴へのリンクや 「次の operational event を待っています」 等の補助 affordance を強化する選択肢あり。