Design Decisions — app-ceo (Variant A) — Round 001

Generated: 2026-05-27 by kashi-ui-mockupper | Surface: /app/ceo (ExecutiveBriefPage) | Picked variant: A (保守的 — 視覚整理のみ) | Companion: index.html

A の本質を 1 文で: 現状の 5-8 metric 平板 layout を維持しつつ、 design_system_v1 トークンを 100% 適用し、 suppression footer を verbatim で各 metric / table 下に常時表示し、 H1 直下に role boundary note を追加する 最小介入 mockup。

B との根本的違い: B は 「Review Candidates 北極星昇格 + Plan C/Positive 折りたたみ + governance 4 chips 圧縮 + governance sub-route + window infobar」 で IA を再構築 する。 A は IA に一切触らず、 視覚的にきれいに整えるだけ。 「どこを最初に見るか」 という Justine の仮説 pain は 解決を試みない — それは B/C の責務。 A は 「現状を壊さずに canon footer 明示 + token cleanup する」 という選択肢を提示する。

1. A 概要 — 何を、 何のためにこの形にしたか

決定 1.1: 「保守的」 と translator が呼ぶスコープを厳格に解釈

translator の 「Variant A — 視覚 / トークンのみ。 IA・ルート変更なし」 を文字通り守った。 具体的には:

canon: translator/02_proposals/app-ceo__variants.html Variant A 行 304-441「視覚 / トークンのみ。 IA・ルート変更なし」

決定 1.2: それでも追加するもの = 3 点のみ

A は 「何もしない」 ではない。 canon-fix として 3 点を必須追加した:

  1. Role boundary note (H1 直下、 1 行): permanent-ui-principles §3 §11 への canon 適合
  2. Suppression footer の常時可視化: 各 stat card 下端 + strip 下端 + Roster table 下 + Plan C panel 下 + Positive panel 下 = 計 5+ 箇所に WORKER_FACING_TRUST_CANON §6.2 verbatim copy
  3. design_system_v1 token 100% 適用: r19 の 35 件不整合のうち app-ceo 該当 8-10 件を解消

canon: permanent-ui-principles §3 (role boundary first) + §11 (visibility boundary visible) + §6 (suppression visible)

2. 平板 layout 維持の理由 — なぜ B 的 IA 再構築をしなかったか

決定 2.1: A の存在意義 = 「壊さずに整える」 の選択肢提示

Justine の Round 1 は friends/mentor に共有して具体 feedback を取得するフェーズ。 B (中庸) も並列で mockup 化される。 もし A も B 寄りの IA 再構築をすると、 Justine の選択肢が 「ほぼ同じ B 寄り 2 案」 になり、 「現状維持に近い案 vs 大きく変える案」 という意思決定軸が消える。 A は意図的に 「現状の muscle memory を壊さない」 を残し、 B と並べたときに hierarchy が見える形にした。

canon: translator pick-recommendation 「Variant A 単独 pick は非推奨」 だが orchestrator が A を選択 = 「現状維持寄りの選択肢を friends/mentor に見せたい」 意図と解釈

決定 2.2: 5 セクション順序は現状を踏襲

既存 ExecutiveBriefPage の実装 (kashi/src/app/app/ceo/page.tsx) の section 順序: stat strip → Roster → Plan C → Positive → ExecutiveAggregateSection を踏襲。 A の制約上、 順序入れ替えも IA 介入とみなして避けた。 token cleanup と footer 追加のみで再現可能なため。

canon: 現状 implementation 順序 (Stage 1 research mirror page 構造分析より)

決定 2.3: 4 stat card を equal weight にした (北極星化 NG)

Managers / Review Candidates / Insufficient / Adaptation の 4 card は全て同じ --shadow-sm + --border + --fs-h2 stat value。 B のように Review Candidates を --fs-display + 2px evergreen border で特権化することはしない。 これにより 「どこを最初に見るか」 という仮説 pain は 解決しないまま残る — それが A の意図的なトレードオフ。

canon: translator Variant A §残るリスク 「平板問題は A では解決しない」 (proposal 行 430-434)

3. design_system_v1 トークンの適用 — どこに何を使ったか

決定 3.1: ブランド色 = evergreen 系のみ、 emerald-700 はアクセント限定

page background = --color-warm-tint (#FAFAF7) / card background = --color-paper (#FFFFFF) / card border = --border (#E5E7EB) / wordmark + h1 + h2 + h3 = --color-kashi-evergreen (#1F3D33) / accent (active nav border / drill link) = --color-emerald-700 (#2F6B4A)。 r19 の background 不統一 (§3.2)、 card border 不統一 (§3.5) を解消。

canon: kashi/src/app/globals.css + design_system_v1 §1 color tokens

決定 3.2: Type scale = clamp-based fluid (Fraunces + IBM Plex + Zen Kaku)

h1 = --fs-h1 clamp(2rem, 3vw, 2.75rem) Fraunces 600 / h2 = --fs-h3 (section heading は h3 size でも階層 OK) / stat value = --fs-h2 Fraunces 600 / body = IBM Plex Sans 400 + Zen Kaku fallback / mono = IBM Plex Mono 400-600 (reason code / label / count)。 r19 §4.1-4.2 type scale 未適用を解消。 JP body line-height = 1.75 (kanji breathing room +10% per design_system_v1 §2)。

canon: design_system_v1 §2 type scale + JP rule「JP body は line-height を 1.1× に」

決定 3.3: Evidence grade 6 token 全採用 + text label 必須

grade-blocked / insufficient / weak / emerging / stable / high-confidence-stable の 6 token を全て CSS に定義、 Roster table で使用例を 4 種類 (STABLE / HIGH_CONFIDENCE_STABLE / EMERGING / WEAK) 提示。 全 badge は color + text label (例: 「WEAK」 という文字を必ず併記、 a11y / color-blind safe)。 r19 §5.1 grade パレット未統一を解消。

canon: design_system_v1 §1 evidence-grade badges 「badges must include both color AND text label」 + permanent-ui-principles §12 「badges not color-only」

決定 3.4: Spacing rhythm = 8-point grid に厳格適合

card inner padding = --space-5 (24px) / section block separation = --space-8 (48px) / inline gap = --space-2 (8px) / compact stack = --space-3 (12px)。 r19 §2.1 spacing rhythm を解消。

canon: design_system_v1 §3 spacing rhythm

決定 3.5: Adaptation Watch icon = warning amber (NOT red)

現状 Kashi の AlertTriangle が誤って red 系になっている疑いを r19 §6.3 が示唆。 A では --kashi-state-warning (#B45309) に統一。 赤は true error のみ (permanent-ui-principles §13 + design_system_v1 §1 「never use for risk detected」)。 mockup 上では Adaptation Watch stat card の helper text に 「注視 (amber)」 と明示し、 「warning ≠ error」 を語彙で示した。

canon: design_system_v1 §1 「--kashi-state-error: NEVER use for risk detected or analyzer output」 + permanent-ui-principles §13 「avoid red alert dashboards」

4. Suppression footer 配置 — 5+ 箇所に常時可視化

決定 4.1: 各 stat card 下端に個別 footer (4 箇所)

Managers / Review Candidates / Insufficient / Adaptation の 4 card それぞれに .stat-suppress-footer を配置。 各 card 内で 「team_size < 5 のため抑制」 の理由を簡潔に記述。 これにより 「数字だけ見えて suppression が分からない」 という Justine の仮説 pain (proposal 行 425) を解消。

canon: WORKER_FACING_TRUST_CANON §6.2 (推定) + DATA_VISIBILITY_MATRIX §5 k-anon floor

決定 4.2: Strip 全体下に verbatim footer (1 箇所)

4 card の下に strip-level の verbatim footer を配置 (border-left 3px emerald-700 で視覚的に group footer であることを示す)。 文言は translator proposal 行 337 の verbatim: 「2 teams suppressed (team_size < 5、 観察ウィンドウ内でチーム規模が比較可能になると更新されます)」 を採用。

canon: translator proposal Variant A 行 337-338 verbatim suppression copy

決定 4.3: Roster table 下に footer (1 箇所、 k-anon < 5 sample 含む)

Roster table は 12 teams 表示、 残り 2 teams が k-anon 抑制されている。 footer で 「経営戦略室 / 監査室 が該当推定、 個別チーム名は安全のため非表示」 と記述、 k-anon < 5 のサンプルがどう扱われるか を読み手に理解させる。 さらに 「sort は alphabetical のみ、 grade 順 sort は moral ranking 化のため禁止」 を併記し X-02 violation 回避を可視化。

canon: DATA_VISIBILITY_MATRIX §5 k-anon + X-02 (translator proposal 行 348)

決定 4.4: Plan C / Positive panel 下にも footer (2 箇所)

Plan C panel 下: 「team_size < 5 のチームに紐づく Plan C 事象は集約から除外」。 Positive panel 下: 同様 + 「これは 『組織が健康』 という単一スコアではなく」 を併記して X-03 (org health score) violation 回避を明示。 計 5+ 箇所の suppression footer により、 ページ全体で 「数字の裏に抑制が存在する」 ことが常時 visible に。

canon: X-03 (translator proposal canon-violation-audit 行 845) + permanent-ui-principles §6 「No Signal Rule」

5. B との比較 — A は 「何を意図的にやらないか」

軸 A 保守的 (本 mockup) B 中庸 (siblings/B/)
北極星 metric なし。 4 stat card は equal weight (全 stat-card クラス) あり。 Review Candidates が .polaris-card で 2px evergreen border + display 56px font に昇格
Plan C / Positive full panel で並列表示 (5 cell grid x 2 panel) <details> accordion で折りたたみ (default 閉じ)
ExecutiveAggregateSection full panel 4 item grid、 各 item に status + label + meta + detail (最新更新 / 推奨アクション含む) 4 chips に圧縮 (status + label + meta のみ) + 「詳細を確認 (/app/ceo/governance)」 link で sub-route 提案
Window 表示 role boundary note の 1 行に含めるのみ (「観測窓: 直近 90 日固定」) polaris-card 内に専用 window-infobar (info-blue background + 詳細 reason)
Roster 表示 全 12 teams を 1 table で並列表示 (review-candidate 抽出フィルタなし) Review Candidate 3 teams を card で先頭表示、 残り 9 teams は accordion 内 table
Drill-down 表現 table cell 内 link + 「unlock 4 条件 未充足」 plain text 表示 card 内 emerald button + 「unlock 済」 pill / lock icon + dashed box で locked 表現
「どこを最初に見るか」 解決しない (これが A の意図的限界) 解決 (北極星 H1 metric が視線を捕捉)
新 sub-route 提案 なし あり (/app/ceo/governance を提案)
実装工数 S (1-2 day) — CSS + i18n + role boundary note 追加のみ、 ロジック変更なし M (4-6 day) — accordion component + sub-route + i18n 大量追加 + IA 再構築

6. permanent-ui-principles 適合チェック (A 観点)

§3 Role boundary first: PASS
H1 直下に role boundary note (「あなたは経営者として閲覧中 | 集約データのみ表示 | 個人識別情報なし | 観測窓: 直近 90 日固定」)。 §3 が要求する 「Who is viewing / What allowed / What forbidden / What action」 のうち 「Who」 と 「What allowed/forbidden」 を 1 行で answer。
§5 Evidence semantics: PASS
Roster table の各 row は evidence grade (badge) + reason code (RC-XXX) + observed window (table heading 内 「観察窓: 直近 90 日」) + topSignal (data quality を間接表現) を全て visible。 grade は verdict ではなく review-support signal であることが card helper text で示される。
§6 No-signal rule: PASS
Insufficient Window stat card は 「『問題なし』 ではなく 判定不可 状態です」 と明示。 Semantic Lane ExecutiveAggregateItem は 「現在 OFF (org 設定で意味内容解析が無効化中)。 これは 『問題なし』 ではなく 機能停止 状態」 と explicit に書く。
§7 Progressive disclosure: △ (Variant A の意図的限界)
A は折りたたみを採用しないため §7 「Fold or route」 は active には実装しない。 既存の Drill-down link が discovery path として残るのみ。 「Governance detail should be discoverable, not dumped」 を満たしているとは言いがたい — これが A の trade-off。 B/C はここを改善する。
§8 Cognitive load: △ (A の最大限界)
「A screen fails if everything looks equally important」 を A は 解消しない。 4 stat card + 5 セクション 全て equal weight。 Justine が friends/mentor からこの fail を指摘される可能性が高い → Round 2 で B/C に swing する判断材料になる。 これは「あえて残す」 意図的な構成。
§9 Dashboard rules: PASS
各 stat card は 「what is shown (label) / who about (集約 only) / what window (footer) / what data quality (helper) / what does this NOT prove (helper)」 を answer。 grade 順 sort 禁止 (alphabetical only)、 「show individual subordinate data to executives by default」 NG (Roster は team 単位、 個人 drill-down は unlock 4 条件後のみ link 表示)。
§11 Internal product screen rules: PASS
role label (header の CEO badge) / visibility boundary (role boundary note) / evidence grade (Roster) / reason codes (Roster) / observed window (role boundary note + section meta) / input quality (Insufficient stat card で間接表現) / safe actions (Drill-down link) / forbidden actions (unlock 未充足 表示) / audit (footer の audit-trace) すべて visible。
§13 Visual system: PASS
off-white base (FAFAF7) / dark readable text (#2A3A1E) / 緑系 accent (#1F3D33 + #2F6B4A) / restrained cards / no red alerts / no eye icons / no gradients / no animations / generous whitespace。 IBM Plex Mono を mono として採用 (JetBrains の代わり、 globals.css 既定に合わせる)。

7. Canon-conflict pattern 回避 (X-01〜X-05) — A 観点

X-01 (個人離職リスクスコア): NG / 未採用
個人スコアは一切表示しない。 Roster は team 単位の evidence grade のみ。 個人 drill-down は unlock 4 条件後の link 表示でゲートされ、 mockup 上では遷移先を toast 表示のみ。
X-02 (manager ranking): NG / 未採用
Roster は alphabetical sort のみ。 footer note で「grade 順 sort は moral ranking 化のため禁止」 と明示。 review-candidate 抽出フィルタも A は採用しないため、 grade による視覚的グルーピングも発生しない。
X-03 (組織健康スコア化): NG / 未採用
どこにも単一スコア (「組織健康 82/100」 等) を表示しない。 Positive panel footer に 「これは 『組織が健康』 という単一スコアではなく」 を明示記述、 X-03 への自己審査を可視化。
X-04 (AI narrative diagnosis): NG / 未採用
AI 生成テキストは一切なし。 全 helper text は固定テンプレート + 集計数のみ。 「narrative card」 等の AI 連想を呼ぶ命名も避ける (B も避けているが、 A は元々 narrative card 自体がない)。
X-05 (k-anon 未満 silent 表示): NG / 未採用
5+ 箇所の suppression footer により 「team_size < 5 が抑制された」 ことが常時 visible。 Roster footer note で k-anon < 5 該当 2 teams が抑制されている事実を具体的に記述 (経営戦略室 / 監査室 推定 + 個別 team 名は安全のため非表示 = 抑制された事実 + 抑制した理由 + 抑制対象の概数 を全て開示)。

8. 削った要素 / 追加した要素

削ったもの (現状の Kashi から)

追加したもの (現状にない)

9. 既知のトレードオフ / 未解決 (Round 2 への申し送り)

未解決 1 (最大): 「どこを最初に見ればよいか」 は A では解決しない。 4 stat card + 5 セクション equal weight のため、 CEO が friends/mentor に共有した際 「結局どこを見ればいい?」 という同じ不満が再出する可能性が高い。 これは A の意図的トレードオフ。 Round 2 で B/C swing の判断材料に。

未解決 2: trend / 前週比 / sparkline (P-07) は不在。 Kashi moat (structure-not-content + longitudinal across meetings) が画面から伝わらない問題は A では解決しない。

未解決 3: governance section の情報量過多 (経営判断に直接関係しない governance 詳細) は A では削減しない。 4 item full panel のまま。

未解決 4: 「window toggle が動いていない」 (AC-05 trust gate) は role boundary note の 1 行に統合したが、 専用 infobar での目立たせはしていない。 友人 / mentor が 「窓が動かない理由が分かりにくい」 と feedback する可能性あり。

潜在リスク: r19 35 件のうち app-ceo 該当分 (推定 8-10 件) は A で解消するが、 残り 25 件は他 surface (app-me 等) に分散しているため、 他 surface mockup と整合性が取れているか別途確認が必要。

10. Justine 判断点 — friends / mentor / 共同創業者に聞くべきこと

A 案を共有するときに必ず聞きたい 5 つの問い

  1. 「この画面を 30 秒見て、 どこを最初に注視しましたか?」
    → A は意図的に hierarchy を作らないため、 視線が散る・迷う という回答が予想される。 これが回答に出れば 「現状 layout の根本問題」 が再現できた = Round 2 で B/C に進む強い根拠になる。
  2. 「CEO がこの画面で取るべき次のアクションは何だと思いますか?」
    → A は CTA を強調しないため 「分からない」 と回答される可能性が高い。 これも B/C 評価の比較根拠。
  3. 「『集約データのみ』 と書いてあることは安心材料になりますか? それとも当然?」
    → role boundary note の有効性を判定。 安心材料と感じられれば A の追加価値が証明される。
  4. 「『2 teams suppressed (team_size < 5)』 という記述は意味が伝わりますか?」
    → suppression footer の語彙レベルを判定。 「k-anon」 等の用語が必要か、 もっと噛み砕いた表現が必要か。
  5. 「Kashi の独自性 (他社にない強み) はこの画面から伝わりますか?」
    → A は moat 可視化を試みないため、 「伝わらない」 という回答が予想。 これが出れば moat 可視化の必要性 (B/C 寄り) を確認できる。

もし friends/mentor 全員が 「A で十分」 と回答した場合: Round 2 で A の小幅改善 (suppression footer 文言調整など) で landable。
もし複数人が問 1/2/5 で曖昧回答した場合: Round 2 で B/C に swing する強い根拠 — 特に 「結局どこを見ればいい?」 が複数回出れば B (北極星北極星) が最有力候補。

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

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

Generated by kashi-ui-mockupper · 2026-05-27 · Round 001 / Stage 3 (mockup) · Surface: /app/ceo · Variant: A (保守的) · Companion: index.html · Sibling: B/index.html · Total mockup files: 2 (index.html + DESIGN_DECISIONS.html).