Design Decisions — app-reviewer (Variant A) — Round 1

Generated: 2026-05-27 / kashi-ui-mockupper / Stage 3 of 3 / Picked variant: A (保守的)
Companion to: index.html / Sibling mockup: ../B/index.html (Variant B)
Translator source: 02_proposals/app-reviewer__variants.html (Variant A section)

0. Variant A の本質 (TL;DR)

Variant A は 「衛生 (hygiene) Pass」 である。 現状の /app/reviewer ランディング (4-queue card 並び) は IA としては成立しているという仮定に立ち、 以下の 3 つの最小限の修正のみを適用する:

  1. EyeOff → FileSearch icon 差し替え (§13 surveillance metaphor 違反の解消)
  2. doctrine 5-section の <details> 折りたたみ (§7 progressive disclosure の充足)
  3. count=0 カードの dim 表示 (視覚的優先度 hint、 ただし並び替えはしない)

意図的に「しない」こと (これが A の本質):

1. 主タスクと上位構造

決定: 主タスク = 「4 つの human-review queue の pending count を一望し、 必要なものから開く」

現状の /app/reviewer page.tsx の主タスクをそのまま継承。 reviewer が assigned scope (12 meetings / 30 日 window) の中で、 どの queue lane に何件 pending があるかを 1 画面で把握し、 個別ページに drill-down する単純な triage 動線。

Variant B は主タスクを「今 attention を要する queue で最も古い 1 件は何か」に re-define したが、 Variant A はあえて re-define せず、 既存の「4 lane equal triage」モデルを維持する。 理由: Round 1 の hypothesis は 仮説駆動であり、 IA 変更を含む B/C は Round 2 以降に複数 surface 横断で議論する方が安全だから (translator §pick-section の推奨と整合)。

canon: permanent-ui-principles §3 (role boundary first) + §9 (dashboard rule) / source: translator proposal Variant A §「主タスク (unchanged)」

2. レイアウト

決定: above-fold = (1) PortalHeader (sticky 2-row) / (2) eyebrow + H1 + intro / (3) visibility notice + doctrine fold / (4) 4-queue grid (2×2) / (5) footer disclaimer

この順序は translator proposal の wireframe をほぼ完全に再現したもの。 1280px 想定で 4 queue card が 2×2 grid、 880px 以下で 1 列に折り返す (CSS grid)。

Variant B は 「Active Queues / Escalated / Inactive Queues」 の 3 section に分割していたが、 Variant A は 単一の「Review Queues (4 lanes)」section 1 つのみ。 これが「平板維持」の視覚的具象。

canon: permanent-ui-principles §7 (default visible layer: 1 H1 / 1 short explanation / 3-5 cards / 1 primary CTA / 1 trust note) / source: translator proposal Variant A §「レイアウト構造 (above-fold)」

決定: queue card は icon-tile (44px) + count (40px mono) + title (Fraunces 20px) + 1 行 description + 1 行 meta + CTA の 1 つだけ

card 内構造を 5 行で完結させる (Variant B は次のような複層構造を持つ: header + qc-summary + qc-decisions + qc-footer)。 A の card は <a> 全体クリッカブルにし、 hover で 1px lift する程度の affordance。

card 内に grade / reason / scope を出さない理由は § 4 (採用したトークン) で詳述。

canon: permanent-ui-principles §8 (cognitive load: consistent cards / whitespace / one primary CTA) / design_system_v1 §3 (8pt grid, card inner padding = space-5)

3. 採用した design_system_v1 トークン

箇所トークン
page background--bg-page#FAFAF7 (warm off-white, §13)
card background (active)--paper#FFFFFF
card background (dim count=0)--paper-tint#F7F8FA + opacity 0.65
card border (default)--border#E5E7EB (1px)
card border (hover)--color-kashi-evergreen#1F3D33
icon-tile background--paper-tint#F7F8FA
icon-tile color (active)--color-kashi-evergreen#1F3D33
icon-tile color (dim)--grade-blocked#6B7280
count number (active)--color-kashi-evergreen-deep#244A3D (40px mono)
count number (dim)--grade-blocked#6B7280
H1 page title--fs-h1clamp(28px, 3.2vw, 36px) Fraunces 600
card title20px Fraunces 600
eyebrow--fs-eyebrow + tracking-0.04em11px (r19 §6.4 fix: NOT 0.3em)
card spacing--space-5 inner / --space-5 grid gap24px / 24px
section block separation--space-848px (H1→notice, notice→queue)
radius--radius-md8px (card / button / icon-tile)
focus ring (a11y)2px evergreen outline + 2px offset(WCAG 2.4.7)

すべて kashi/src/app/globals.css + design_system_v1.md に存在するトークンのみ。 新規トークン作成なし。 Variant B の --state-info / --state-warning 等の state-pill 系トークンは 使用しない (Variant A は state を表示しないため)。

4. 採用した evidence-grade 表現

決定: ランディングページに evidence-grade badge を一切表示しない

Variant B は card 内に EMERGING / WEAK / INSUFFICIENT / STABLE 等の grade badge を表示し、 next-actionable 1 件の reason code (PRESSURE_PATTERN 等) も surface していた。

Variant A は意図的にこれを surface しない。 grade と reason は queue 個別ページ内側 (drill-down 先) で表示する。 ランディングは「lane の存在と pending count」のみを示し、 各 lane の内容判断は drill-down 後に行う。

理由:

canon: permanent-ui-principles §5 (evidence semantics: 「make accessible」), §11 (internal screen) / DATA_VISIBILITY_MATRIX §3 row "evidence grades" — Reviewer = Y (bounded review queue 内)、 個別 queue ページで表示すれば充足

5. 削った要素 (Variant B から)

削除した要素 (B 由来)削除理由
scope-bar (assigned scope: 12 meetings / 4 lanes / 30 日 window のチップ) page intro 段落に統合し、 文章で表現。 専用 UI ブロックは Variant A の「最小限改修」スコープを超える。
section-divider × 3 (Active Queues / Escalated / Inactive Queues) Variant A は単一 section「Review Queues (4 lanes)」のみ。 active/inactive 分離 = Active-first 並び替えとセットの設計、 A の「平板維持」と矛盾する。
card 内 state-pill (pending / in_progress / escalated) Variant A は state を概念として導入しない。 reviewer が「触り中」かどうかは個別 queue ページ側で表現する。
card 内 qc-summary dl (next-actionable: 4 日前 / EMERGING / PRESSURE_PATTERN / 3 meetings / 14 日 window) scope-safe preview = B の中核機能だが、 k-anon suppression 設計とセットになるため A の「hygiene pass」スコープを超える。
card 内 qc-decisions chip × 4 (受理 / 却下 / 追加情報を要求 / エスカレーション) 4 決定 chip の inline 表示 = B の中核機能。 A は「ランディングは lane 一覧、 決定は個別ページ」の分離原則を維持する。
k-anon suppression block (#FCD34D 警告) preview が無いので suppression も無い。
Escalated 案件の専用 card section 同上、 単一 4-queue 並びを維持。 escalated は個別 queue ページ側で表示。
Inactive Queues (count=0) の 折りたたみ section A は count=0 card を 削除も折りたたみもせず、 4 並びの中に dim 表示で残置。 reviewer が「Grace lane は今 0 件」を 1 画面で確認できる方が衛生的、 という判断 (translator proposal A の wireframe に従う)。

6. 追加した要素 (現状にない)

追加要素根拠
<details> doctrine fold (5 サブセクション: 許可される閲覧 / 許可されない閲覧 / 取れる決定 / Audit log の動作 / Kashi が「しないこと」) permanent-ui-principles §7 progressive disclosure。 現状の ReviewerCockpitDoctrineSection は 5 セクション展開のため reviewer が情報過多になりやすい。 default = 2 行 (visibility scope + audit log 通知) のみ visible、 詳細は fold。
queue card の icon-tile (44×44 paper-tint, 1px border) 現行 reviewer page はアイコンを inline で表示。 design_system_v1 §7 (icon 16/20/24 grid) に揃え、 タイル化することで card の視覚 anchor を統一。
count=0 card の dim style (opacity 0.65 + paper-tint bg + grade-blocked color) translator proposal Variant A §「研究パターン」より: count=0 を自然に視覚デエンファシスしつつ非表示にはしない (「lane が存在することを示し続ける」+「今は対象なし」を同時に伝える)。
footer の §6 No-Signal Rule note (「pending 0 件は all clear を意味しません」) permanent-ui-principles §6 必須。 count=0 dim カードを残すなら、 その意味の canon 解説を併記する義務。

7. Variant B との視覚的・機能的比較

側面Variant A (本案)Variant B (sibling)
4 queue の並び canonical 順固定 (Disputes → Severity → Manager Context → Grace) Active-first 動的並び (count>0 を上、 count=0 を inactive 折りたたみへ)
card grid 2×2 grid (≥880px) / 4 lane equal weight 縦 1 列 / active 3 枚 + escalated 1 枚 + inactive 1 枚 (folded)
card 内 next-actionable preview 無し 有り (4 日前 / EMERGING / PRESSURE_PATTERN / 3 meetings)
card 内 evidence-grade badge 無し 有り (color + text label)
card 内 reason code chip 無し 有り (PRESSURE_PATTERN 等)
card 内 state pill (pending/in_progress/escalated) 無し 有り (3 状態)
card 内 4 決定 chip (受理/却下/追加情報/エスカ) 無し (doctrine fold 内に文章で記載) 有り (各 card 直下に inline)
k-anon suppression block 無し (preview 無いので不要) 有り (Grace lane の card で suppressed 状態を表示)
EyeOff → FileSearch icon 差し替え 有り (Grace lane の dim card に適用) 有り (Grace lane card + inactive section folded summary に適用)
doctrine 5-section の折りたたみ 有り (default = 2 行 boundary note + audit log 通知) 有り (default = 1 行 audit log 通知のみ、 boundary も fold)
実装工数 (translator 推定) S (~4-8h) M (~16-24h)
解決される hypothesis 不満 4/5 (EyeOff / doctrine / count=0 / r19 整合) 5/5 (上記 4 + 「4 queue 間の優先度判断が困難」)

8. permanent-ui-principles 適合チェック

§判定根拠
§3 Role Boundary First PASS PortalHeader に role=HR Reviewer 明示、 visibility scope (12 meetings / 30 日) と audit log 通知を default visible note 2 行で保持。
§6 No-Signal Rule PASS count=0 Grace lane に「all clear / 問題なし」表記なし、 footer に「pending 0 件 = no qualifying signal in this observed window」明示。 doctrine fold 内の「受理」決定も canon-approved wording で記載。
§7 Progressive Disclosure PASS doctrine 5-section を <details> 内に折りたたみ。 default visible = 2 行 boundary note + 4 queue cards + 1 footer disclaimer (約 1 スクリーン)。
§8 Cognitive Load PASS 1 H1 / 1 eyebrow / 1 intro / 1 notice / 4 equal cards / 1 footer。 全 card が equal visual weight (dim card のみ視覚デエンファシス)。 ランキングなし、 health score なし。
§9 Dashboard Rules PASS 各 card に「what is shown (queue name + description)」「who is this about (scope: assigned meetings, identity 出さず)」「what window (30 日、 footer で明示)」「what can the viewer do (詳しく見る → drill-down)」を answer。 grade/reason は drill-down 先で answer (§5 の「make accessible」充足)。
§11 Internal Screen PASS role label (header) / visibility boundary (notice + nav-scope-note) / audit behavior (notice + footer) を default visible。 evidence grade / reason code / safe actions / forbidden actions は doctrine fold + drill-down 先で accessible。
§12 A11y / Mobile PASS 1 H1 / sane heading order (H1 → H2 card titles) / keyboard-operable (details summary key event handler) / visible focus state (2px evergreen outline) / no color-only signaling (count=0 dim has bg + opacity + color tri-layered) / responsive 1280/880/768/480 breakpoints。
§13 Visual System PASS off-white base (#FAFAF7) / dark green accent (#1F3D33) / Lucide outline 1.5px / no eye icon (EyeOff → FileSearch 差し替え済み) / no red alert / no AI glow / no gradient。 §13 surveillance metaphor 違反の解消が本案の最重要 deliverable。

9. DATA_VISIBILITY_MATRIX 適合チェック

FieldVariant A で表示?Matrix § 根拠
queue pending count (assigned scope aggregate)Y§3 row "per-meeting structural metrics" Reviewer = Y (in bounded review queue)
queue lane name + canonical descriptionYstructural metadata、 識別情報を含まない
queue id (q_dispute_001 等)Ystructural identifier、 affected person を特定しない
evidence gradeN (ランディング) / Y (drill-down 後)§3 row "evidence grades" — bounded queue 内 Y、 ランディングでは出さない (§7 progressive disclosure に従い drill-down 先で表示)
reason codeN (ランディング) / Y (drill-down 後)同上 — drill-down 先で表示
affected_candidate / source_candidate identityN§4 anti-retaliation gate: ランディング・個別 queue page 両方で identity は RLS-gated。 ランディングには絶対に出さない
他チーム queue / 全社俯瞰N§3 "team aggregates" Reviewer = Y(under procedure) のみ。 ランディングには出さない、 nav にも導線なし
scope-safe meta (meeting count / earliest date)N (ランディング)k-anon suppression 設計の負荷を回避するため Variant A では preview そのものを出さない (Variant B では出すが suppression が必要)

Audit log 動作: ランディングページの単純閲覧 (queue count aggregate のみ) では audit_log row 発生なし。 「詳しく見る」 click で個別 queue ページに drill-down した瞬間に affected_user 側の audit log に即時記録 (既存挙動、 変更なし)。

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

トレードオフ 1: 4 queue の優先度差を視覚的に示すのは count 数値のみ

緊急 dispute (12 件 pending) と routine context submission (5 件) の判断負荷の差は count 表示だけでは伝わらない。 reviewer は「数字が大きい順に処理」または「lane 種別の優先度感覚」に頼ることになる。 これは Variant B/C で解決される問題であり、 A では 意図的に解決しない

translator proposal Variant A §「残るリスク」#1

トレードオフ 2: 「ポストログイン後どこに行けばいいか」が本ページ側で解決されない

これは /app/me 側 (mirror-me surface) の課題であり、 reviewer cockpit の責務ではない。 Variant A は scope を逸脱せず、 reviewer ランディングの hygiene のみに focus する。

translator proposal Variant A §「残るリスク」#2

トレードオフ 3: 4 queue 間のクロス参照を表示しない

同一 affected person が複数 queue にまたがる場合の集約 view は anti-retaliation §4 の都合で意図的に表示しない (Variant A/B/C 共通)。 ただし reviewer の throughput 観点では摩擦の可能性があり、 これは canon-modification 議論の領域。

translator proposal Variant A §「残るリスク」#3 + permanent-ui-principles §4 (anti-retaliation)

未解決: 「Inconclusive Grace Evaluations」 という long lane name が card 内で 2 行折り返す可能性

880px 以下の grid 1 列モードでは card 幅が広がるため 1 行で収まるが、 ≥880px の 2 列モードでは card 幅が狭く 2 行になる可能性がある。 現状の line-height: 1.3 + Fraunces 20px で許容範囲と判断したが、 mobile 設計時に再評価必要。

11. Justine 判断点 (Round 1 feedback collection 用)

判断点 A: 4-queue 平板維持で OK か?

A は「4 lane equal weight」モデルを意図的に維持する。 反対意見の典型: 「Disputes 12 件と Grace 0 件を同じ視覚重みで並べるのは reviewer の意思決定支援として弱い」。 → これに同意するなら Variant B (Active-first) を pick すべき。 A は「現 IA は OK」前提に立つ。

判断点 B: card 内に grade/reason/scope preview を出さないで OK か?

A は「ランディングは lane 一覧、 内容判断は drill-down 後」を維持する。 反対意見: 「drill-down するまで何が pending か分からないのは 1 クリック多い」。 → これに同意するなら Variant B を pick。 A は「drill-down 1 click のコスト」 を許容して preview 設計の複雑さ (k-anon suppression 等) を回避する。

判断点 C: 4 決定 chip を card 内に出さなくて OK か?

A は doctrine fold 内に文章で「受理 / 却下 / 追加情報を要求 / エスカレーション」を記載するのみ。 反対意見: 「chip 表示の方が決定オプションを reviewer が早期に意識できる」。 → これに同意するなら Variant B。 A は「決定は drill-down 後の文脈で示す方が誤操作リスクが低い」と判断。

判断点 D: count=0 dim card を 4-grid 内に残すか / 折りたたみに移動するか?

A は dim で残す (translator proposal A の wireframe に従う)。 反対意見: 「視覚ノイズが増える、 active 3 件だけ示せば十分」。 → これに同意するなら translator に再投げで「Variant A modified: count=0 を inactive fold に移動」とフィードバック。 A は「lane の存在を示し続ける」価値を優先。

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

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

Pick 確認

Justine の選択: pick app-reviewer=A

このモックアップは Variant A (保守的 / hygiene pass) を実装した。 sibling Variant B mockup は ../B/index.html に存在し、 翻訳者推奨は B だが、 Justine の最終判断は A。

Round 1 feedback collection 後、 必要なら redo mockup app-reviewer A <feedback> で再生成可能。