UI Proposal — app-reviewer

Variant A — 保守的 (Conservative): 視覚整理 + EyeOff 撤去

実装工数: S (small)

現 4-queue ランディング構造はそのまま、 EyeOff icon を FileSearch に差し替え、 design_system_v1 トークンを通し、 doctrine 5-section を progressive disclosure 化する「衛生 (hygiene) Pass」。

主タスク (unchanged)

Reviewer が /app/reviewer に到達 → 4 つの human-review queue (Disputes / Severity Exceptions / Manager Context Submissions / Inconclusive Grace Evaluations) の pending count を一望 → 担当が必要な queue にナビゲートする。

レイアウト構造 (above-fold)

┌───────────────────────────────────────────────────────────────┐
│ PortalHeader (sticky, evergreen bg, role=Reviewer)            │
├───────────────────────────────────────────────────────────────┤
│ [eyebrow] HR / COMPLIANCE REVIEWER COCKPIT                    │
│ Human Review Queues                                            │
│ ─────                                                          │
│ 4 件の human-review queue を割り当てられた scope の中で確認。   │
│ あなたの閲覧行為は対象者の audit log に記録されます。            │
│   ↳ [▸ 詳しい governance doctrine を読む] (折りたたみ)         │
├───────────────────────────────────────────────────────────────┤
│  ┌──────────────────────┐  ┌──────────────────────┐           │
│  │ [Scale]    12         │  │ [Flag]      3         │           │
│  │ Disputes             │  │ Severity Exceptions   │           │
│  │ 異議申立の queue       │  │ 重大度例外の queue     │           │
│  │ → 詳しく見る           │  │ → 詳しく見る           │           │
│  └──────────────────────┘  └──────────────────────┘           │
│  ┌──────────────────────┐  ┌──────────────────────┐           │
│  │ [MessageSquare]  5    │  │ [FileSearch]  0       │  ← dim    │
│  │ Manager Context      │  │ Grace Evaluations     │           │
│  │ 文脈提出の queue       │  │ 暫定期間判定未了        │           │
│  │ → 詳しく見る           │  │ pending 0 件           │           │
│  └──────────────────────┘  └──────────────────────┘           │
├───────────────────────────────────────────────────────────────┤
│ [footer] このページの閲覧範囲は割り当てられたミーティングのみ。  │
│         他チーム / 全社俯瞰は閲覧できません。                    │
└───────────────────────────────────────────────────────────────┘

採用する研究パターン

Pattern	Reference	Variant A での適用
A. Count-First Queue Cards	R1, R2, R4, R7	現行構造維持。ただし count=0 カードを `opacity-60` + 数字を `text-stone-400` から `text-grade-blocked` (#6B7280) に変更し視覚デエンファシス。
D. Compact Visibility Boundary	R2, R3, R4, R5	現 `ReviewerCockpitDoctrineSection` の 5 サブコンポーネントを `<details>` 内に格納。 default visible は 2 行 (visibility scope + audit log 通知の事実)。

design_system_v1 トークン適用箇所

Color: Card border = --kashi-border (#E5E7EB) / Card bg = --kashi-paper / Count number = --kashi-ink (active) or --kashi-grade-blocked (count=0) / hover border = --kashi-evergreen
Typography: H1 = --text-h1 (40px/48px) / Card title = --text-h4 (20px/28px) / Count = display-scale (48px, custom token within range) / eyebrow = --text-caption (12px) + tracking-[0.04em] (not 0.3em — r19 §6.4 fix)
Spacing: Card grid gap = --space-5 (24px) / Card inner padding = --space-5 (24px) / Section block separation = --space-8 (48px)
Radius: Card = --radius-md (8px)
Icon: Lucide outline 24px, 1.5px stroke / EyeOff → FileSearch (文書を確認する metaphor、監視 metaphor 排除)
r19 直接 fix: §4.7 inline hex 排除 / §6.4 eyebrow tracking 統一 / §6.5 card 種別を「nav card」として明確化

permanent-ui-principles 適合チェック

Canon section-by-section

§3 PASS Role boundary first: PortalHeader に role=Reviewer 明示、 visibility scope/audit log を default visible note に保持。
§7 PASS Progressive disclosure: doctrine 5-section を <details> 内に折りたたみ。 default = 2 行 boundary note + 4 queue cards + 1 footer。
§8 PASS Cognitive load: 1 H1 / 1 eyebrow / 4 equal cards (ただし count=0 dim で priority hint) / 1 footer disclaimer。 doctrine 詳細は fold。
§9 PASS Dashboard rule: 4 queue card 全てに count + label + description 表示 (何が / 誰について / どの window は queue 内側で答える)。ランキング / health score 一切なし。
§11 PASS Internal screen: role label / visibility boundary / audit behavior は全部表示。 reason code / evidence grade は queue 内側 (個別ページ) で表示。
§13 PASS Visual system: off-white base / dark green accent / Lucide outline / no eye icon / no red alert / no AI glow。 EyeOff 撤去で §13 surveillance metaphor 違反解消。

DATA_VISIBILITY_MATRIX 適合チェック

Role	このページで見えるもの	見えないもの
HR Reviewer (admin / hr_compliance / restricted_investigator)	4 queue の pending count (assigned scope 内 aggregate)。 individual identity は出ない。	他チーム queue 一覧 / 全社俯瞰 / raw transcript / 名前付き個別 alert (これらは queue 内側でも canon 範囲内のみ)。

Audit log 動作: このランディングページの単純閲覧自体は (queue count aggregate のみのため) /app/me/audit への row 追加なし。 queue の個別ページに drill-down した瞬間に audit row 発生 (既存挙動を変更しない)。

解決される Justine の不満 (researcher §1 末尾仮説リスト)

「doctrine 5-section が初回訪問で情報過多」 → progressive disclosure (<details>) で 2 行に圧縮、必要な reviewer のみ展開。

「count=0 カードが同重表示」 → opacity-60 + grade-blocked 色で自然に視覚デエンファシス。

「EyeOff icon の surveillance 感」 → FileSearch (文書確認 metaphor) に差し替え、 §13 違反解消。

r19 既知不整合 §4.7 / §6.4 / §6.5 を本面で確実に修正。

残るリスク / 未解決事項

4 queue の 優先度差を視覚的に示すのは count 数値の大きさのみ → 緊急 dispute と routine context submission の区別が default では曖昧。 Variant B/C で priority 解消候補。
Justine 不満「ポストログイン後どこに行けばいいか分からない」が本ページ側で解決されない (これは /app/me 側の課題)。
4 queue 間のクロス参照 (同一 affected person が複数 queue にまたがる場合) を表示しない。これは canon §4 anti-retaliation の都合で意図的だが、 Reviewer の throughput 観点では摩擦になる可能性。

実装工数感: S (small)

変更範囲は app/reviewer/page.tsx + ReviewerCockpitDoctrineSection.tsx の visual + structural 微調整のみ。 IA 変更なし、ルート変更なし、 visibility ルール変更なし、 DB 変更なし。 1 PR で完結可能。 ~4-8h 想定。

Variant B — 中庸 (Moderate): Active-First Queue + 命名された決定オプション + Reason-Code 露出

実装工数: M (medium)

Reviewer の primary task は「assigned scope の中で介入要否を判断する」。ランディングを「Active queues only / count=0 は折りたたみ」「各 queue card 直下に next-actionable 1 件のミニサマリー (evidence grade + reason code + meeting scope のみ)」「決定オプション 4 択は canon-approved wording で固定」に再構成。

主タスク (re-defined)

Reviewer が /app/reviewer に到達 → 「今 attention を要する queue の中で最も古い 1 件」がどれかを 1 スクリーンで把握 → そのまま queue 個別ページへ deep link。 4 queue を等価に並べるのではなく、 active な (count > 0) queue を上位に、各 queue card 直下に scope-safe ミニサマリー (evidence grade badge + reason code + meeting count + earliest pending date) を inline で表示。

レイアウト構造 (above-fold)

┌───────────────────────────────────────────────────────────────┐
│ PortalHeader (sticky, evergreen bg, role=Reviewer)            │
├───────────────────────────────────────────────────────────────┤
│ [eyebrow] HR / COMPLIANCE REVIEWER COCKPIT                    │
│ あなたの Review Queue                                          │
│ assigned scope: 12 meetings / 4 queue lanes / window: 30 日   │
│ ┌─────────────────────────────────────────────────────────┐   │
│ │ ⓘ あなたの閲覧行為は対象者の audit log に即時記録されます  │   │
│ │   [▸ 詳しい visibility & decision doctrine]              │   │
│ └─────────────────────────────────────────────────────────┘   │
├─ ACTIVE QUEUES ───────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────┐   │
│ │ [Scale]   12 pending   Disputes                          │   │
│ │ ─────                                                    │   │
│ │ next-actionable (oldest): 4 日前提出                      │   │
│ │ evidence grade: [EMERGING]  reason: PRESSURE_PATTERN     │   │
│ │ scope: 3 meetings / dyad bounded                         │   │
│ │ 取り得る決定: 受理 / 却下 / 追加情報を要求 / エスカレーション │   │
│ │  → このキューを開く                                        │   │
│ └─────────────────────────────────────────────────────────┘   │
│ ┌─────────────────────────────────────────────────────────┐   │
│ │ [Flag]    3 pending    Severity Exceptions               │   │
│ │ next-actionable: 1 日前  [WEAK]  reason: INSUFFICIENT_WIN │   │
│ │ scope: 1 meeting / single observed window                │   │
│ │ 取り得る決定: 例外承認 / 標準処理に戻す / 追加情報を要求    │   │
│ │  → このキューを開く                                        │   │
│ └─────────────────────────────────────────────────────────┘   │
│ ┌─────────────────────────────────────────────────────────┐   │
│ │ [MessageSquare] 5 pending  Manager Context Submissions   │   │
│ │ next-actionable: 6 時間前  scope: 2 meetings              │   │
│ │ 取り得る決定: context を受理 / 不十分として返却 / 質問追加 │   │
│ │  → このキューを開く                                        │   │
│ └─────────────────────────────────────────────────────────┘   │
├─ INACTIVE QUEUES (count = 0) ──────────────────────────────── │
│ ▸ Grace Evaluations (0)  [展開]                                │
└───────────────────────────────────────────────────────────────┘

採用する研究パターン

Pattern	Reference	Variant B での適用 (canon-adapted)
A. Active-First Count Queue	R1, R2, R4, R7	count > 0 queue を上位、 count = 0 は折りたたみ section に分離。 R1 Linear Triage / R4 Zendesk Agent Home パターン (researcher §3 Pattern A) を Kashi に直接適用、ただし Linear の "Auto-apply" 提案系は NG (researcher §5 4th item)。
B. Staged State + Named Decision Options	R1, R2, R3, R5	各 queue card 内に「取り得る決定: ◯ / △ / × / エスカレーション」を inline 表示 (実行 UI は queue 個別ページに deep link)。ただし "No issue" / "All clear" ラベルは禁止 (researcher §5 2nd item、 §6 No-Signal Rule)。「受理」 = "No qualifying signal confirmed in this observed window" を意味する canon-approved wording に内部紐付け。
C. Reason Code Surfacing	R2, R3, R5, R6	next-actionable 1 件の reason code (例 `PRESSURE_PATTERN` / `INSUFFICIENT_WIN`) を card 内に表示。 `reason-code-registry.ts` bilingual ラベル既存を流用。 long free-form なし、構造化コードのみ。
D. Compact Visibility Boundary	R2, R3, R4, R5	ヘッダー下に 1 行の audit log 通知 + 折りたたみ doctrine link。 default visible は scope (12 meetings / 4 queue lanes / window 30 日) のみ。
E. Inline Scope-Safe Preview (NOT hover)	R1, R3, R4, R6	hover preview ではなく card 内 inline preview として実装。表示できるのは evidence grade / reason code / meeting count / earliest date のみ。 affected_candidate / source_candidate identity は絶対に出さない (researcher §3 Pattern E の canon-conflict line を厳守、 anti-retaliation §4 違反回避)。

design_system_v1 トークン適用箇所

Evidence-grade badge: [EMERGING] = --kashi-grade-emerging (#2563EB) / [WEAK] = --kashi-grade-weak (#D97706) / [STABLE] = --kashi-grade-stable (#2F6B4A) — text label と色の併用 (a11y: color-only 禁止)
Reason code 表示: font-family --kashi-font-mono (IBM Plex Mono) / background --kashi-paper-tint / size --text-caption
Section divider: "ACTIVE QUEUES" / "INACTIVE QUEUES (count = 0)" は --text-caption uppercase tracking-[0.04em] (§13 eyebrow style 統一)
Spacing rhythm: queue card 間 = --space-4 (16px) / section block 間 = --space-8 (48px)
Icon: Scale / Flag / MessageSquare 維持 (canon-safe Lucide outline) / EyeOff → FileSearch (Grace Evaluations 用、 dim 状態でも §13 違反回避)
r19 fix: §4.7 / §6.4 / §6.5 + §8.5 (progressive disclosure 整合)

permanent-ui-principles 適合チェック

Canon section-by-section

§3 PASS Role boundary first: PortalHeader role 表示 + scope 数 (12 meetings / 4 lanes / 30 日 window) を H1 直下に明示。
§7 PASS Progressive disclosure: default visible = 3 active card + 1 折りたたみ inactive section + 1 折りたたみ doctrine link。詳細は drill-down で。
§8 PASS Cognitive load: H1 1 / eyebrow 1 / section 2 (active / inactive) / card 3 (active) + 1 collapsed (inactive)。 1 primary CTA per card = 「このキューを開く」。ランキングなし。
§9 PASS Dashboard rule: 各 card に「what is shown / who is this about (scope: N meetings, NOT individual identity) / what window / what grade / what reason codes / what can the viewer do」全部 inline で答える。健康スコアやランキング表示なし。
§11 PASS Internal screen: role label / visibility boundary / evidence grade / reason codes / observed window / safe actions (= 取り得る決定 4 択) / audit behavior 全部 surface。 forbidden action (例: 全社俯瞰) を実装側で route 自体存在させない。
§13 PASS Visual system: off-white base / dark green accent / Lucide outline / no eye icon / no red alert / no AI glow。 evidence-grade badge は color + label 併用 (a11y)。 EyeOff 撤去。
§6 PASS No-Signal Rule: 「取り得る決定」 4 択ラベルは「受理 (= 受理された判断、 no signal confirmed) / 却下 / 追加情報を要求 / エスカレーション」とし、 "問題なし" "All clear" "No issue" ラベルは絶対に使わない。 tooltip / hover text レベルでも禁止。

DATA_VISIBILITY_MATRIX 適合チェック

Field	Variant B で表示するか	Matrix § での根拠
queue pending count (assigned scope aggregate)	Y	§3 row "per-meeting structural metrics" Reviewer = Y (in bounded review queue)
earliest pending date	Y (scope-safe meta)	§3 row "per-meeting structural metrics" の派生情報、 identity 含まず
evidence grade (next-actionable 1 件)	Y	§3 row "evidence grades" — bounded review queue 内 Y
reason code (next-actionable 1 件)	Y	§3 row "reason codes" — bounded review queue 内 Y
meeting count + scope description	Y	§3 row "per-pair / dyad metrics" — bounded queue 内 Y、ただし "dyad bounded" 等の抽象表現に留める
affected_candidate identity (name / dept)	N	§4 anti-retaliation gate: card preview に identity を出さない。個別 queue ページに drill-down してから RLS-gated 表示 (audit row 発生)
他チーム queue / 全社俯瞰	N	§3 "team aggregates" Reviewer = Y(under procedure) のみ。ランディングには出さない

Audit log 動作: ランディングページ表示 = aggregate count + scope-safe grade/reason のみのため audit row なし。「このキューを開く」 click で個別 queue ページに drill-down した瞬間に audit_log row が affected person 側に即時書き込み (既存 RLS 挙動、変更なし)。

解決される Justine の不満

「4 queue 間の優先度が同重で介入意思決定支援が弱い」 → active-first 並び替え + next-actionable 1 件の grade/reason 露出で「どれが今 attention を要するか」をランディング 1 スクリーンで判別可能に。

「count=0 カードが同重」 → INACTIVE QUEUES セクションに折りたたみ分離。必要なら展開可能。

「doctrine 5-section 情報過多」 → 1 行 audit log 通知 + 1 link 折りたたみに圧縮。

「EyeOff icon の surveillance 感」 → FileSearch 差し替え。

r19 §4.7 / §6.4 / §6.5 / §8.5 を本面で fix。

残るリスク / 未解決事項

scope-safe preview の境界線が UI 実装上微妙: 「meeting count」「earliest pending date」は安全だが、「dyad bounded」「3 meetings」等の表現が affected person を間接的に特定できる小規模チームでは個人特定リスク。 → 実装側で k-anonymity-style suppression (queue 内の affected person 集合が小さい場合は preview を「scope: 概要のみ」表示) を追加すべき。 mockupper への引き継ぎ事項。
「next-actionable 1 件」を queue 内のどの順序で決定するか (FIFO / 最古 / 最高 grade) を product owner が決める必要あり。 default は FIFO (= researcher Pattern E "deep link → inline action" の Linear/Zendesk 慣例) を推奨。
各 card 直下の「取り得る決定」 4 択は説明のみ (実行は queue 内側) のため、 reviewer が「ここで決定できるはず」と誤解する UX リスク → mockupper で文言を「このキューに入ると次の決定が取れる」と明示。
active queue が 0 件 (everything 0) の状態の empty state copy が未設計。 §6 No-Signal Rule 準拠の「現時点で attention を要する queue はありません。これは "問題なし" を意味しません。」必須。 mockupper 引き継ぎ。

実装工数感: M (medium)

page.tsx + ReviewerCockpitDoctrineSection 改修 + 新規 QueueSummaryCard コンポーネント (next-actionable 1 件取得 + grade/reason/scope inline 表示) + reason-code-registry.ts から bilingual ラベル取得 + k-anon suppression ロジック。 DB スキーマ変更なし、ルート変更なし、 RLS 変更なし。 ~16-24h 想定。

Variant C — 大胆 (Bold): Unified Priority Inbox + 全 queue 統合 State Machine

実装工数: L (large) — A/B の ~3 倍

⚠ Variant C のみ: 既存ルートと挙動が大きく変わる。 4 queue 別ページ (/app/reviewer/disputes 等) は維持するが、ランディングが「単一の priority queue」に統合される。既存 reviewer の muscle memory が変わるため、 in-app onboarding tooltip + ヘルプ文章更新が必要。実装工数は A/B の約 3 倍 + RLS pattern の見直し (queue join view) 必須。

Disputes / Severity Exceptions / Manager Context / Grace の 4 queue を 単一の priority inbox に統合。各行が「review pending → review in progress → review escalated → review closed」の state machine で管理される。 Reviewer は queue 種別ではなく 「いま誰の判断を待っているか / 何の判断か」を主軸に作業。 4 queue 別ページは個別 deep link 先として残置 (canon RLS 維持のため)。

主タスク (re-architected)

Reviewer が /app/reviewer に到達 → 単一の priority-sorted inbox を見て、各行の state (pending / in_progress / escalated / closed) + queue type badge (Dispute / Severity / Context / Grace) + scope-safe meta (grade / reason / meeting count / earliest date) を一覧把握 → 行 click で個別 queue ページに deep link (state machine の遷移は個別ページで実行)。

レイアウト構造 (above-fold)

┌───────────────────────────────────────────────────────────────┐
│ PortalHeader (sticky, evergreen bg, role=Reviewer)            │
├───────────────────────────────────────────────────────────────┤
│ [eyebrow] HR / COMPLIANCE REVIEWER COCKPIT                    │
│ あなたの Review Inbox                                          │
│ assigned scope: 12 meetings / 30 日 window / 4 lane types     │
│ ⓘ あなたの閲覧行為は対象者の audit log に即時記録されます       │
│   [▸ visibility & decision doctrine]                          │
├─ FILTERS (sticky) ─────────────────────────────────────────── │
│ [全て 20] [pending 17] [in_progress 2] [escalated 1] [closed] │
│ [Dispute] [Severity] [Context] [Grace]   sort: [oldest first] │
├─ INBOX (sortable, max 100/page) ──────────────────────────── │
│ ┌─────────────────────────────────────────────────────────┐  │
│ │ ● pending     [Scale]  Dispute                           │  │
│ │ 4 日前 / [EMERGING] / reason: PRESSURE_PATTERN            │  │
│ │ scope: 3 meetings / window 14 日                         │  │
│ │  → 個別ページで処理する                                    │  │
│ ├─────────────────────────────────────────────────────────┤  │
│ │ ● pending     [Flag]   Severity Exception                │  │
│ │ 1 日前 / [WEAK] / reason: INSUFFICIENT_WINDOW             │  │
│ │ scope: 1 meeting / single observed window                │  │
│ │  → 個別ページで処理する                                    │  │
│ ├─────────────────────────────────────────────────────────┤  │
│ │ ◐ in_progress [MessageSquare]  Manager Context           │  │
│ │ 6 時間前 / scope: 2 meetings                              │  │
│ │ note: あなたが昨日 drill-down 済み (audit row 発生済み)   │  │
│ │  → 個別ページで続きを処理                                  │  │
│ ├─────────────────────────────────────────────────────────┤  │
│ │ ▲ escalated   [Scale]  Dispute                           │  │
│ │ 7 日前 / [STABLE] / reason: REPEATED_PATTERN              │  │
│ │ scope: 5 meetings / 別 reviewer にエスカレ済み            │  │
│ │  → 個別ページで状況を確認                                  │  │
│ └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘

採用する研究パターン

Pattern	Reference	Variant C での適用 (canon-adapted)
A. Count-First → Unified Inbox	R1, R2, R4, R7	R1 Linear Triage "shared inbox" + R4 Zendesk "Your Work" の inbox メタファーを採用、ただし Kashi では queue 種別を完全に解体しない (各行に queue type badge を残す) — RLS が queue 別 table 構造に依存するため。 Linear の auto-prioritization (AI suggestion) は採用しない (§1 AI magic NG)。 sort は明示的 user 操作のみ。
B. Unified State Machine	R1, R2, R3, R5	R5 HITL Guide "New → In review → Approved/Edited/Rejected/Escalated → Resolved" 状態マシンを 4 queue 横断で採用。 Kashi 命名: pending / in_progress / escalated / closed (4 状態のみ、 over-engineering 回避)。「resolved as no issue」状態は採用しない (§6 No-Signal Rule)。 closed は「決定が記録された」のみを意味し、内部内容は queue type ごとの canon-approved wording で表現。
C. Reason Code 統一表示	R2, R3, R5, R6	全行に reason code 表示 (queue 種別不問の統一形式)。 `reason-code-registry.ts` の bilingual ラベルを横断使用。
D. Filter-as-Visibility-Boundary	R2, R3, R4, R5	sticky filter row が「あなたの scope = この 20 件のみ」を視覚的に常時宣言。 R4 Zendesk "Your Work" / R7 Vercel filter-by-status 慣例。 visibility boundary doctrine は 1 link 折りたたみに圧縮。
E. Scope-Safe Inline Preview	R1, R3, R4, R6	各行に inline preview (grade / reason / meeting count / window)。 hover popover ではなく行内常時表示に変更 (researcher §3 Pattern E の canon-conflict 回避: hover preview だと identity 露出リスクが生じやすい)。 affected_candidate / source_candidate identity は絶対 inbox に出さない。

design_system_v1 トークン適用箇所

State badge: ● pending = --kashi-grade-emerging (#2563EB) / ◐ in_progress = --kashi-state-info / ▲ escalated = --kashi-grade-weak (#D97706) / ✓ closed = --kashi-grade-stable (#2F6B4A) — color + glyph + text 三重併用 (a11y、 §12)
Queue-type badge: Lucide icon + text label / background --kashi-paper-tint / 各 badge は同 size, equal visual weight (個別 queue を健康スコア的にランク付けしない)
Inbox row: bg --kashi-paper / border-top --kashi-border / hover bg --kashi-paper-tint / inner padding --space-4 (16px)
Filter sticky row: bg --kashi-paper / shadow --shadow-sm / 常時 visible (scope 宣言の役割)
Sort control: 「oldest first」 default、 user 選択肢に "newest first" / "highest grade" / "queue type" のみ (AI-suggested priority は NG)
r19 fix: §4.7 / §6.4 / §6.5 / §8.5 + card → row 構造移行で §6.5 card 種別混用も解消

permanent-ui-principles 適合チェック

Canon section-by-section

§3 PASS Role boundary first: PortalHeader role 表示 + scope 数 + filter sticky row が「あなたの scope」を常時宣言。他 role mix なし。
§7 PASS Progressive disclosure: default = filter + inbox row 表示。 doctrine 詳細 / 個別 queue の決定 UI は drill-down 先で。 inbox 上限 100 件 (R4 Zendesk 慣例) でパフォーマンス保護。
§8 PASS Cognitive load: H1 1 / eyebrow 1 / filter row 1 / inbox rows N。全 row が equal visual weight (priority 表示は state badge + sort 順のみ、ランキングなし)。 1 primary CTA per row。
§9 PASS Dashboard rule: 各 row に「what is shown (queue type + state) / who is this about (scope: N meetings, identity 出さず) / what window / what grade / what reason / what can the viewer do」全部 answer。全 reviewer 横断ランキングなし、個人別 throughput score なし。
§11 PASS Internal screen: role label / visibility boundary / evidence grade / reason codes / observed window / safe actions / audit behavior 全部 surface。 empty state / error / permission-denied state も filter 0 件状態として実装必須 (mockupper 引き継ぎ)。
§13 PASS Visual system: off-white base / dark green accent / Lucide outline / no eye icon / no red alert / no AI glow。 state badge は color + glyph + text 三重併用。 EyeOff 撤去。 red color は escalated に 使わない (escalated = grade-weak の amber)。
§6 PASS No-Signal Rule: state は pending / in_progress / escalated / closed の 4 状態のみ。 "resolved as no issue" "All clear" "No problem confirmed" は禁止。 closed state は「決定が記録された」意味のみで、内容は drill-down 先で確認。 inbox 全 0 件の empty state は「現時点で attention を要する案件はありません。これは "問題なし" を意味しません。 [boundary copy library から引用]」必須。
§1 PASS AI magic 回避: sort は 明示的 user 操作のみ (oldest / newest / highest grade / queue type)、 AI-suggested priority / auto-apply 一切なし。「Reviewer が確認してから実行」構造を保持。

DATA_VISIBILITY_MATRIX 適合チェック

Field	Variant C で表示するか	Matrix § での根拠
queue type badge (Dispute / Severity / Context / Grace)	Y (各行)	§3 row "notices naming a person (in review queue)" — Reviewer = Y、ただし person 名は出さず queue type のみ
state (pending / in_progress / escalated / closed)	Y	新規 derived state、 visibility matrix 上の既存 row の派生情報
evidence grade / reason code	Y	§3 row "evidence grades" / "reason codes" — bounded queue 内 Y
meeting count + window + scope description	Y	§3 row "per-meeting structural metrics" / "per-pair / dyad metrics" — bounded queue 内 Y、抽象化表現
"あなたが昨日 drill-down 済み" note (in_progress 行)	Y (self audit)	§3 row "audit log entries about this person" Reviewer = Y (their own actions)。これは reviewer 自身の audit 行為履歴であり、 affected person 情報ではない
affected_candidate / source_candidate identity	N	§4 anti-retaliation gate: inbox には identity を一切出さない。個別 queue ページ drill-down 後の RLS-gated 表示のみ。 audit row はそのときに発生
他 reviewer に escalated された案件の現在の reviewer 名	N (default) / Y (admin role のみ)	§3 row "audit log entries about this person" は admin = Y (system audit)。通常 reviewer は「別 reviewer にエスカレ済み」事実のみ閲覧
他チーム queue / 全社俯瞰	N	RLS が assigned scope のみを join view に流す。 filter で表示できる選択肢自体に他チームを含めない

Audit log 動作: inbox 表示 = scope-safe aggregate + grade/reason のみのため audit row なし (Variant B と同じ)。「個別ページで処理する」 click で drill-down 時に audit_log row 発生。

RLS 改修必要事項 (mockupper への警告): 4 queue を統合 inbox に表示するため、 4 個別 RLS-secured table を join した view (or materialized view) が必要。 RLS 自体は queue 別 table に維持しつつ、 view 層で scope filter + state derivation を行う設計が安全。 RLS test (test/rls/role-expansion) に inbox view 経由のアクセス path を追加必須。これが「実装工数 L (A/B の 3 倍)」の主因。

解決される Justine の不満

「4 queue 間の優先度判断が困難」 → 単一 inbox + 明示的 sort (oldest first default) + state badge で「いま処理待ち / 自分が触り中 / エスカレ済み」を 1 画面把握。

「ポストログイン後どこに行けばいいか分からない」 → Reviewer の場合、ログイン後 /app/reviewer = "あなたの inbox を見る" の 1 アクションに集約。「inbox に行く」がポストログイン全体の orchestrator 共通 metaphor となれば、他 surface (Manager / CEO 等) も同 metaphor で揃えられる可能性 (将来検討)。

「count=0 / doctrine 過多 / EyeOff」 → filter で active のみ default 表示 / doctrine 1-link 折りたたみ / EyeOff 撤去で全て解消。

「次にすべきことが見えない」 → 各 row の primary CTA「個別ページで処理する」 + state「pending / in_progress」が直接示唆。

r19 §4.7 / §6.4 / §6.5 / §8.5 を本面で fix + card → row 構造移行で §6.5 card 種別混用も解消。

残るリスク / 未解決事項

RLS 改修コスト大: 4 個別 RLS table を join view に集約する設計は RLS の保証境界を変える。 test/rls/ 全テストを再 audit 必須。 doctrine-modification process (CANONICAL_PRODUCT_TRUTH §8) の発動が必要かもしれない。 → orchestrator / 開発リードに事前確認推奨。
"individual queue context" 喪失リスク: 現在の 4-queue 構造は「Disputes は dispute 専用 doctrine、 Severity は別 doctrine」と明示的に separation できているが、 inbox 統合で「全部 review 一種」と誤読される UX リスク。 → 各 row の queue type badge を確実に視覚区別 + drill-down 先で個別 doctrine を引き続き表示する設計で緩和。
state 遷移の monitoring 機構が必要: in_progress 状態が放置されると stale。 SLA timer 表示 / 自動 closed 等は §1 AI magic 境界が微妙 → Round 2 で別途設計が必要。
onboarding コスト: 既存 reviewer は 4-queue メタファーに慣れている。 in-app tooltip + ヘルプ docs + migration period 必須。
k-anon-style suppression が一層重要: 1 行に「meeting count + window + scope description」が並ぶことで小規模チームでは個人特定リスクが Variant B より上がる。 row 内 scope description を「Team A の bounded review queue」程度に抽象化、個別 dyad / meeting 数の表示は queue 内側でのみ。 mockupper 厳重引き継ぎ。
inbox 100 件超過時の paging 挙動: R4 Zendesk 慣例の max 100 件を採用するが、 100 件超え時の「scope を絞ってください」プロンプトが必要。 mockupper 引き継ぎ。

実装工数感: L (large) — A/B の約 3 倍

app/reviewer/page.tsx 全面再設計 + ReviewerInbox + InboxRow + InboxFilter + StateBadge 新規 + queue 統合 view (SQL view / RPC) + RLS test 再 audit (test/rls/role-expansion + test/rls/isolation) + doctrine-modification process 確認 + in-app onboarding tooltip + 既存 4 queue 個別ページ ( /app/reviewer/disputes 等) は触らず deep link 先として残置。 ~60-80h 想定 (Variant A/B が ~16-24h)。

Variant	リスク	インパクト	工数	最適な状況
A. 保守的	低	小〜中	S (~4-8h)	「現 IA は OK、 surveillance metaphor (EyeOff) + doctrine 過多 + r19 不整合だけ確実に潰したい」
B. 中庸	中	中〜大	M (~16-24h)	「IA はそのまま、ただし Reviewer が "今どの queue が attention を要するか" を 1 画面で判断できる構造に変えたい」
C. 大胆	高 (RLS 改修)	大	L (~60-80h)	「4 queue 別概念を解体し、単一の priority inbox に統一したい。ポストログイン全体の "inbox" メタファー統一の試金石として」

Generated: 2026-05-27T+09:00 by kashi-ui-translator / Stage 2 of 3 / Inputs: 01_research/app-reviewer__references.html, permanent-ui-principles.md (§1, §3, §4, §6, §7, §8, §9, §11, §13), design_system_v1.md (§1, §2, §3, §4, §7, §8), DATA_VISIBILITY_MATRIX.md (§3, §4, §7), CANONICAL_PRODUCT_TRUTH.md (§2.1, §6), r19-ui-consistency-applicability.md (§4.7, §6.4, §6.5, §8.5).
Read-only on kashi/ source. No code edits.

UI Proposal — app-reviewer — Round 1

Variant A — 保守的 (Conservative): 視覚整理 + EyeOff 撤去

主タスク (unchanged)

レイアウト構造 (above-fold)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

Canon section-by-section

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満 (researcher §1 末尾仮説リスト)

残るリスク / 未解決事項

実装工数感: S (small)

Variant B — 中庸 (Moderate): Active-First Queue + 命名された決定オプション + Reason-Code 露出

主タスク (re-defined)

レイアウト構造 (above-fold)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

Canon section-by-section

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満

残るリスク / 未解決事項

実装工数感: M (medium)

Variant C — 大胆 (Bold): Unified Priority Inbox + 全 queue 統合 State Machine

主タスク (re-architected)

レイアウト構造 (above-fold)

採用する研究パターン

design_system_v1 トークン適用箇所

permanent-ui-principles 適合チェック

Canon section-by-section

DATA_VISIBILITY_MATRIX 適合チェック

解決される Justine の不満

残るリスク / 未解決事項

実装工数感: L (large) — A/B の約 3 倍

Justine への選択質問

translator の推奨

Pick 形式