UI Research — app-reviewer — Round 1

Generated: 2026-05-27T00:00:00+09:00 by kashi-ui-researcher  |  Stage 1 / 3 (research only, no proposals)

1. Kashi 現状サマリ — /app/reviewer

ロール定義 (canon より)

DATA_VISIBILITY_MATRIX.md §1 の表記では 「HR / Compliance Reviewer」。 実装上の許可ロール: admin / hr_compliance / restricted_investigator（page.tsx:21-23）。 Kashi 固有の persona としては 人事部の中立観察者、産業医・産業カウンセラー、外部メンター等。 共通する立場は 第三者的中立レビュアー：自らが当事者ではなく、割り当てられた個別ミーティングの構造データを確認し、介入要否を判断する役割。

現在の画面構造 (ソースコード読取)

主タスク: 4 つのヒューマンレビューキューの全体把握と個別キューへのナビゲーション 副タスク: ReviewerCockpitDoctrineSection（VA Prompt 11）による doctrine 確認——キュー入室前に「governed human review」フレーミング、判断ポリシー、visibility boundary、required caveats を提示する。

データ密度と IA

Kashi canon によるスコープ制約 (DATA_VISIBILITY_MATRIX.md §3 より)

閲覧可能フィールド 閲覧不可フィールド
bounded review queue 内の per-meeting structural metrics
per-pair / dyad metrics (bounded review queue)
pattern summaries (bounded review queue)
team aggregates (under procedure)
evidence grades / reason codes
dispute queue
notices naming a person (in review queue) 		universal transcript browsing (NG — raw transcript は never persisted)
unrelated private content
private employee notes
raw meeting archive as casual browsing
全社俯瞰・他チームデータ（assigned scope 外）
重要 canon 制約: 閲覧行為は即座に affected person の /app/me/audit に audit log として書き込まれる（DATA_VISIBILITY_MATRIX.md §7）。UI は「Reviewer がデータを見ると Member に即時通知される」という現実を隠蔽してはならない。

対応する Justine の不満 (仮説駆動)

complaints.md 未提供のため、既存 canon・r19 知見・ソースコード読取から推論。

2. 参照リファレンス (N=7)

Archetype: Queue / Inbox / Triage — structured human decision with evidence, reason code, and audit trail requirement。 Scope 制約上 authenticated SaaS UI は直接閲覧不可のため、公開ドキュメント・ヘルプページ・公式 changelog・技術記事を一次ソースとして使用。

Ref ID サービス URL (参照) Archetype 調査ソース種別
R1 Linear — Triage linear.app/docs/triage
linear.app/now/how-we-built-triage-intelligence		 Shared inbox / staged acceptance queue 公式 Docs + 公式 Blog（2025）
R2 Stripe — Dispute Response docs.stripe.com/disputes/responding Evidence-graded decision + structured submission workflow 公式 Docs（2026）
R3 GitHub — PR Review docs.github.com/articles/about-pull-request-reviews Structured 3-state decision (approve / request-changes / comment) with audit trail 公式 Docs
R4 Zendesk — Agent Home support.zendesk.com/hc/en-us/articles/5064623131418 Multi-category work queue with priority, status, SLA filter 公式 Helpセンター（2024）
R5 AllDaysTech — Human-in-the-Loop Review Queue Guide alldaystech.com/guides/artificial-intelligence/human-in-the-loop-ai-review-queue-workflows Structured decision code + role-tiered queue + SLA timer pattern 技術ガイド（2026）
R6 SaaS UI Workflow Patterns (mpaiva-cc Gist) gist.github.com/mpaiva-cc/d4ef3a652872cb5a91aa529db98d62dd Inbox View / Notification → Deep Link → Inline Action / Confirmation Dialog pattern catalog キュレーション一覧（2023-2024）
R7 Vercel — Deployment Management vercel.com/docs/deployments/managing-deployments Filter-by-status list view with per-item contextual action menu 公式 Docs（2026-02）

3. 強信号パターン (≥3 references で観察)

以下 5 パターンは全て 3 以上の参照で観察。各パターンを「現 Kashi 課題との対応」「互換性」とセットで記載。

A. カテゴリ別 Count-First キューカード  R1, R2, R4, R7 (4/7)

パターン内容: 各キューカテゴリ（Disputes / Severity Exceptions 等）を独立したカードで提示し、pending count を最大フォントサイズで表示する。カード全体がリンクになっており、クリックで直接キューリストへ遷移する。

Reference 観察内容
R1 Linear Triage Triage は「shared inbox」として独立タブ。count バッジがサイドバーで常時可視。
R2 Stripe Disputes Disputes list に件数サマリーが header 領域に表示、open / under_review / won / lost 別カウント。
R4 Zendesk Agent Home "Your Work > Tickets" セクションに件数。最大 100 件上限を明示してパフォーマンス保護。
R7 Vercel Deployments Branch / Status / Environment フィルタで絞り込んだ後の件数変化でユーザーは優先度を判断。

Kashi 現課題との対応: 現在の Kashi /app/reviewer は既にこの構造を実装している（QueueCard コンポーネント + count バッジ）。課題は count=0 の場合の視覚的重みが同一であること。参照では count=0 カードを dim/collapse して優先度を自然に伝えるパターンが多い（R1, R4）。

Kashi 互換性: ✓ 直接適用 — count バッジは存在する。 △ 要調整: count=0 カードの視覚的デエンファシス（現行: text-stone-400 数字のみ。R1/R4 では dim 全体 or collapse）。 canon 制約なし。

B. 段階的状態マシン (Staged State Machine) + 明示的決定オプション  R1, R2, R3, R5 (4/7)

パターン内容: 各キューアイテムが明確な状態遷移モデルを持ち、Reviewer は 「受理 / 却下 / 保留 / エスカレーション」 等の名前付き決定オプションのみを取れる。自由形式の操作ではなく、構造化された決定選択肢が UI に固定されている。

Reference 観察内容（決定オプション）
R1 Linear Triage Accept / Mark as Duplicate / Decline / Snooze の 4 択。キーボードショートカット付き。
R2 Stripe Disputes Accept dispute / Contest（2 択 + 提出後は変更不可のチェックボックス確認）。ステータスは open → under_review → won / lost の明示フロー。
R3 GitHub PR Review Comment / Approve / Request Changes の 3 択。リポジトリ管理者は「required approvals before merge」で必須化可能。
R5 HITL Guide New → In review → Approved / Edited / Rejected / Escalated (specialist) → Resolved の状態マシン。決定コード (INCORRECT / INCOMPLETE / UNSAFE / FORMAT_FAIL / NEEDS_CLARIFICATION) による構造化ラベル。

Kashi 現課題との対応: 現在の Kashi 実装はキューリストへのナビゲーションのみで、各キューアイテム内の decision UI は別ページ（/app/reviewer/disputes 等）に委譲されている。ランディングページ（/app/reviewer）には決定 UI がないが、決定オプションが canon-compliant の language で表現されているかが translator への引き継ぎポイント。

Kashi 互換性: ✓ 直接適用 — 状態マシン構造は canon の「review → human judgment → audit log」と完全一致。 △ 要調整: 決定オプションの用語を canon-approved wording に整合させる必要（"Accept" → "No qualifying signal confirmed" 等。permanent-ui-principles.md §2 参照）。 ✗ 禁止: 「問題なし / All clear / Issue resolved」の決定オプションラベル（§6 No-Signal Rule 違反）。

C. Reason Code + 根拠付き決定 (Structured Rationale)  R2, R3, R5, R6 (4/7)

パターン内容: Reviewer の決定に対して reason code（構造化ラベル）+ short free-text note の組み合わせを必須とする。長文の自由記述は避け、予め定義された reason code カテゴリから選択後に補足テキストを追加するパターン。

Reference 観察内容
R2 Stripe Disputes Dispute reason code（カード会社指定）+ 証拠種別（file categories）を構造的に収集。提出前の確認チェックボックスあり。
R3 GitHub PR Review 3 択決定 + line-level comment（特定箇所への根拠紐付け）。Conversation thread を "resolved" でマーク。
R5 HITL Guide "Use structured decision codes and short notes rather than long free-form explanations to maintain throughput and consistency." 決定コードで failure mode を定量化。
R6 SaaS UI Workflow Gist Confirmation Dialog / Destructive Action パターン — 高インパクト決定に focused dialog、意図的確認を担保。

Kashi 現課題との対応: Kashi canon は reason-code-registry.ts で bilingual reason code ライブラリを既に持つ（CANONICAL_PRODUCT_TRUTH.md §5）。UI 側でこれを Reviewer の決定フォームに surfacing できていれば pattern C は充足されるが、/app/reviewer ランディングには現状 reason code UI がない（各サブページに委譲）。

Kashi 互換性: ✓ 直接適用 — reason code 設計は canon で既に義務付けられている（permanent-ui-principles.md §5）。 △ 要調整: Reviewer の判断に使う reason code は Kashi 独自の evidence-grade taxonomy（BLOCKED / INSUFFICIENT / WEAK / EMERGING / STABLE / HIGH_CONFIDENCE_STABLE）に紐付ける必要。

D. Scope 限定型の Visibility Boundary 明示  R2, R3, R5, R4 (4/7)

パターン内容: Reviewer が「何を見ることができ、何を見ることができないか」を ページ入室時に一度だけ明示する。全画面通告ではなく、compact な visibility disclaimer をキュー上部に固定表示し、アクション開始前に visibility scope を意識させる。

Reference 観察内容
R2 Stripe Disputes 「不審請求の申し立て通知を受け取った場合、回答できる期間は限られています」という期限と行動範囲を先頭に明示。提出後は編集不可という限界も事前に伝える。
R3 GitHub PR Review Reviewer は assigned PR のみ表示。Repository-level permissions で明示的にスコープが決まる。レビュー権限の境界は UI に常時反映。
R4 Zendesk Agent Home "Your Work" / "Shared Work" / "Completed Work" のセクション分けで「自分が担当するもの」「CCのもの」「完了したもの」を明確に境界化。最大 100 件上限も明示。
R5 HITL Guide Priority lane (P0 / P1 / P2) で reviewer が見るべきスコープを先に決定。SLA timer でアクション可能窓を可視化。

Kashi 現課題との対応: Kashi は既に ReviewerCockpitDoctrineSection として visibility boundary を実装しているが、5 サブコンポーネントに展開される構造は情報過多の可能性がある。参照では compact な 1-2 行フッター or 折りたたみ可能なセクションで境界を提示するパターンが主流。

Kashi 互換性: ✓ 直接適用 — DATA_VISIBILITY_MATRIX.md §7 の「audit log は affected person に即時通知」を compact な visibility note として表面化することは canon 要件。 △ 要調整: 現行の 5 コンポーネント展開を progressive disclosure（details/summary）に折りたたみ、default では 1-2 行 boundary note のみ表示する。permanent-ui-principles.md §7 Progressive Disclosure に準拠。

E. Notification → Deep Link → Inline Action パターン  R1, R3, R4, R6 (4/7)

パターン内容: キュー一覧から個別アイテムへの遷移は Deep Link（カード全体クリック → 個別ページ）で行い、キュー一覧上では 主要アクション（Snooze / Mark as Duplicate 等）のみ Inline で提供する。すべての操作を別ページへ委ねるのではなく、「速攻処理できるもの」だけインライン化することで、Reviewer の context switch コストを下げる。

Reference 観察内容
R1 Linear Triage Triage 一覧でキーボードショートカット (H=Snooze / MM=Duplicate / 3=Decline) が使える — 個別ページ遷移なしで主要決定が完結。
R3 GitHub PR "View pull requests awaiting your review" 一覧から各 PR へ deep link。PR 一覧上でもラベル付け等のクイックアクションは可能。
R4 Zendesk Agent Home Ticket hover で latest comment + original request をプレビュー — 別タブ開かずに内容を確認してから遷移判断ができる。
R6 SaaS UI Workflow Gist "Notification → Deep Link → Inline Action or Details" パターンとして明示的に文書化。"context-driven and highly efficient" と説明。

Kashi 現課題との対応: 現在の Kashi ランディングは全カードが deep link のみ（Link href）。hover preview や inline quick action がない。Reviewer が「disputes が 12 件あるが、どれが緊急か」をランディングページで判断するための情報が不足している。

Kashi 互換性: △ 要調整: カード hover preview の情報は DATA_VISIBILITY_MATRIX.md §3 で許可されたフィールド（evidence grade + reason code + scope）のみ。affected_candidate identity は hover preview に出してはならない。 ✗ 禁止: preview で "who triggered this" を名前付きで表示するインタラクション（anti-retaliation gate 違反 — §4）。

4. 弱信号 (1-2 refs のみ、参考まで)

5. Kashi canon に反するため採用しないパターン

6. r19 UI 不整合との交差点

r19-ui-consistency-applicability.md より、/app/reviewer に特に影響する既知不整合を抜粋。

r19 Finding app-reviewer への影響
4.7 Missing unified color token system dispute-decision-form.tsx:177 に inline hex #244A3D の使用が確認されている（r19 より）。Reviewer 内サブページでも token 未整合が発生している可能性が高い。
6.4 Eyebrow styling inconsistency 現在の reviewer/page.tsx:55 に text-xs uppercase tracking-[0.3em] のキッカーが存在する。これは Section.tsx の tracking との微差があり r19 §6.4 に該当する。
6.5 Card language inconsistency QueueCard は rounded-lg border border-stone-200 bg-white — r19 が指摘する「同一 card スタイルが content / nav / dashboard に混用」パターンに該当。card 種別の明確化が必要。
8.5 Disclosure/interactivity inconsistency ReviewerCockpitDoctrineSection の 5 サブコンポーネントが一括展開される構造は progressive disclosure なし。r19 §8.5 および permanent-ui-principles.md §7 の両方に抵触する可能性。

7. translator への引き継ぎメモ

最も解決インパクトが大きいパターン上位 3 つ:
  1. Pattern B + C — 状態マシン × Reason Code 構造: 現行の 4 キューカード（ランディング）の下流に位置する各 /app/reviewer/* サブページの決定フォームが、canon-approved wording（"No qualifying signal in this observed window" 等）と evidence-grade taxonomy（BLOCKED / INSUFFICIENT / … / HIGH_CONFIDENCE_STABLE）に沿っているかを確認・整合させることが最優先。ランディングページのカード label が「どんな決定を内包するか」を implied する文言になっているかを translator がチェックすべき。
  2. Pattern D — ReviewerCockpitDoctrineSection の Progressive Disclosure 化: 現行の 5 サブコンポーネント一括展開を <details> / summary による段階開示に変換する。default visible = 1-2 行の visibility boundary note + "この閲覧行為は対象者の audit log に記録されます"（DATA_VISIBILITY_MATRIX.md §7）。これは translator が最初に提案すべき構造変更。
  3. Pattern A の count=0 デエンファシス + Pattern E の hover preview（scope-safe）: count=0 のカードを dim or collapse することで Reviewer の視線を active キューに誘導。hover preview に出せる情報は evidence grade + reason code + meeting scope のみ（affected_candidate identity は禁止）。この二点はセットで translator が提案する。
絶対に外せない Kashi 制約 (translator が守るべき hard stops):

参照日時: 2026-05-27 | ソース: linear.app/docs/triage, docs.stripe.com/disputes/responding, docs.github.com (PR reviews), support.zendesk.com/hc/en-us/articles/5064623131418, alldaystech.com/guides/artificial-intelligence/human-in-the-loop-ai-review-queue-workflows, gist.github.com/mpaiva-cc, vercel.com/docs/deployments/managing-deployments
Kashi canon 読取: permanent-ui-principles.md, DATA_VISIBILITY_MATRIX.md, CANONICAL_PRODUCT_TRUTH.md, design_system_v1.md, r19-ui-consistency-applicability.md
kashi/ ソース読取 (read-only): app/reviewer/page.tsx, components/reviewer/ReviewerCockpitDoctrineSection.tsx, app/app/layout.tsx, components/portal/PortalHeader.tsx