現 /app/reviewer (4-queue card grid + 5-section doctrine 一括展開 + EyeOff icon) を Variant C: 4 queue を解体した単一 priority inbox + 4-state machine (pending / in_progress / escalated / closed) + sticky filter row (scope を視覚的に常時宣言) + 行単位 scope-safe inline preview + k-anon suppression 厳格化 に再構成。 Reviewer 「林さん」 が queue 種別ではなく「いま誰の判断を待っているか / 何の判断か」 を主軸に作業できるよう、 行 (row) を最小単位とする inbox メタファーへ移行。 4 queue 別ページ (/app/reviewer/disputes 等) は 削除せず deep link 先として残置、 doctrine も従来通り。 ただし RLS 改修必須 (4 個別 RLS-secured table を join した reviewer_inbox_view 新設 + test/rls/role-expansion + test/rls/isolation 全再 audit + canon-touching 可能性確認)、 加えて onboarding コスト発生 (in-app tooltip + 移行 docs)、 実装工数 A/B の 3 倍 (~60-80h)。 EyeOff は FileSearch に置換済み、 hover preview は廃止し inline 常時表示で identity 漏出経路を構造的に閉鎖。
Justine pick が app-reviewer=C。 translator §「pick 推奨」では translator 自身は Variant B を推奨していたが、 Justine が Variant C を picked。 mockupper は translator 推奨に逆らわず、 picked variant を忠実に視覚化 (variant 間の混合・別案折衷なし)。 translator §「Variant C」 の wireframe (L549-583) + 採用 pattern 表 (L587-612) + DATA_VISIBILITY_MATRIX 適合表 (L641-651) + 残るリスク (L666-674) を mockup 全要素の根拠とした。
trace: 02_proposals/app-reviewer__variants.html L528-680 (Variant C 全文) / orchestrator kickoff: Variant C picked, mockup-only, no react / Justine override (translator 推奨は B だったが C を pick)
Reviewer ロール = 「第三者的中立レビュアー」(researcher §1)。 「林さん」 は架空名 (現実の Kashi tenant には存在しない placeholder)、 「人事部の中立観察者」「産業医・産業カウンセラー」「外部メンター」を代表する surname として 2 文字標準。 Variant B mockup と人物像を揃えることで Justine が「同じ人物が新しい画面を見たらどう感じるか」を直接比較できる。
trace: permanent-ui-principles §3 (role-first) / canon: 実在 person 名禁止 / B 版 DESIGN_DECISIONS §1 と persona 同一
Variant C 仕様の「state machine + filter sticky + 行単位の oldest first」を 視覚的に 1 画面で検証できる ため、 9 行で 4 state × 4 queue × k-anon suppression を網羅:
値 (meeting count / window / reason code) は translator wireframe (L562-582) + Variant B mockup ROW pool を継承し、 過剰 dummy data 生成は scope 外。 filter chips の count (pending 5 / in_progress 1 / escalated 1 / closed 2) は 9 行から正確に逆算した値。
trace: 02_proposals L562-582 wireframe + Variant C 残るリスク §「k-anon-style suppression が一層重要」(L672) / orchestrator instructions「4 queue 統合 + state 4 種 + k-anon suppressed 1 件」
現実装 (page.tsx L89-118) は md:grid-cols-2 2x2 grid で 4 QueueCard を equal visual weight 配置。 Variant C ではこれを 完全に解体 し、 queue 種別を 「行内 chip」 に降格、 主軸を 「state + 時系列 + 行単位 evidence meta」 に変更。 これにより Reviewer は「Dispute だから先に見る / Grace は後回し」のような queue-type-first 判断から、 「いま処理待ち (pending) / 自分が触り中 (in_progress) / 委譲済み (escalated) / 記録済み (closed) を時系列で消化する」 判断パスに移行できる。 queue 種別は依然として行内 chip + filter chips で完全に保持されるため、 個別 lane doctrine が失われることはない (個別ページへの deep link も維持)。
trace: 02_proposals Variant C §主タスク (L544-547) / Pattern A. Count-First → Unified Inbox (L587-591) / R1 Linear Triage shared inbox + R4 Zendesk Your Work / 解決される不満「4 queue 間の優先度判断が困難」 (L660)
queue 統合は「全部 review 一種」と誤読されるリスク (Variant C 残るリスク L669) があるため、 mockup では queue type を視覚的に明示する 3 つの層を用意:
max-content で確実に幅を確保し、 chip が body に飲み込まれない構造。→ /app/reviewer/disputes 等の route を row-meta-line で明示し、 「個別ページで処理する」 click で 従来の個別 lane ページ + doctrine + 4 決定 UI に遷移。 個別ページ自体は無改変。この 3 層により、 inbox 統合は 「ランディング画面の view 統合」 のみで、 RLS / DB / 個別ページ / lane doctrine の構造改変は最小限に留まる。
trace: 02_proposals Pattern A 「Kashi では queue 種別を完全に解体しない (各行に queue type badge を残す)」 (L591) / 残るリスク §「individual queue context 喪失リスク」緩和策 (L669) / 4 queue 別ページは「個別 deep link 先として残置」(L541)
R1 Linear Triage 系の 「auto-apply triage suggestion」 は 採用不可 (§1 AI magic 境界違反)。 mockup の filter row 右側 sort select には「oldest first (default) / newest first / highest grade first / queue type」の 4 軸を明示配置。 default は oldest first (古い案件が放置されることを構造的に防ぐ)。 「AI が勧める」 のような文言 / glow effect / ML score 一切なし。 sort 変更時の挙動も client-side のみで instant、 server 側の ranking 関数は不要。
trace: 02_proposals Pattern A canon-adapted 「Linear の auto-prioritization は採用しない」(L591) / Variant C トークン §Sort control (L621) / permanent-ui-principles §1 AI magic NG
R4 Zendesk Your Work の慣例 (max 100 items per inbox view) を採用。 mockup の .inbox-footer に 「100 件上限 (R4 Zendesk 慣例) / 100 件超は filter 絞り込みプロンプトを表示」 を明示。 100 件超過時の挙動 (filter 絞り込み prompt の文言 / プロンプト UI 形) 自体は本 mockup では描画していないが、 実装フェーズで追加必須 (Variant C 残るリスク L673「mockupper 引き継ぎ」)。 これにより scope の極端拡張 (admin が全 reviewer の inbox を見ようとする等) でも UI / RLS の双方で抑止が効く。
trace: 02_proposals 残るリスク §「inbox 100 件超過時の paging 挙動」(L673) / R4 Zendesk Agent Home pagination 慣例 / §11 Internal Screen Rules pagination 要件
R5 HITL Guide では「New → In review → Approved/Edited/Rejected/Escalated → Resolved」 の 5-7 状態が一般的だが、 Kashi では over-engineering を避け 4 状態 に絞った:
意図的に 「resolved as no issue」「all clear」「no problem confirmed」 等の状態は 定義していない。 これは §6 No-Signal Rule の正面遵守 — 「決定が記録された」 ことを意味する closed のみで、 内容 (受理/却下) は drill-down 先で確認する設計。 mockup の footer + visibility-notice doctrine fold の両方でこの旨を明示している。
trace: 02_proposals Pattern B (L594-597) / canon §6 No-Signal Rule「'No qualifying signal' never means 'no issue'」 / 02_proposals 「'resolved as no issue' 状態は採用しない」(L596)
各 inbox-row の左端 (28px 列) に .row-state = state-dot (12px 円) + state-label (4-letter mono caps: PEND / PROG / ESC / CLSD) を縦並びで配置。 加えて行内 3 列目には .state-pill = color + glyph dot + text label (pending / in_progress / escalated / closed) を pill 形式で重複表示。 これにより色覚異常 / モノクロ印刷 / Screen Reader の何れでも state が伝わる。 さらに escalated 行は border-left: 3px solid var(--state-warning) で物理的に区別、 closed 行は opacity: 0.85 + 灰色 bg で 「操作不要、 参照のみ」 を視覚化。
state 色の token 割当 (canon の design_system_v1 + globals.css token のみ使用):
--state-info (#3B82F6) + state-info-bg (#EFF6FF) + #BFDBFE border--color-emerald-700 (#2F6B4A) + emerald-50 bg + #B8D4C7 border--state-warning (#B45309) + warn-bg (#FEF9EC) + #FCD34D border--ink-faint (#8A9579) + #F3F4F6 bg + border-strong--grade-blocked (#6B7280) + warn-bg + dashed #FCD34D border-top (suppressed-row 特別 style)red color (#B91C1C) は state 表現に一切使わない (§13 no red alert)。 escalated は amber (#B45309 / #FCD34D) で「注意喚起だが panic ではない」 トーン。
trace: 02_proposals トークン §State badge (L617) 「color + glyph + text 三重併用 (a11y、 §12)」 / canon §12 badges not color-only / §13 no red alert / globals.css token 値
全 lane 共通の 4 決定 (受理 / 却下 / 追加情報を要求 / エスカレーション) は inbox 上で常時表示するが、 state によって chip の muted 化を変える:
.muted 化 (chip-glyph: ⊘) + 「(handler 委譲済み)」括弧追加。 残る「追加情報を提供」「状況を確認する」 は active。 CTA を .row-cta.outlined (border-only) に切替えて視覚的に read-only-with-action を表現。.muted 化 (⊘ 記号)、 残る「記録を参照」 のみ active (ⓘ glyph)。 CTA も .row-cta.outlined + 「→ read-only / 操作不可」 meta line で記録参照のみ明示。この 3 パターン分岐により、 reviewer は「ここで何ができて何ができないか」 を chip の muted-vs-active で 一目で判別 できる。 全行で 4 chip を表示する一貫性は維持 (chip が消えると「何が選択肢か」が不明になり transparency 低下)。
trace: 02_proposals 残るリスク §「state 遷移の monitoring 機構」 / Variant B DESIGN_DECISIONS §2「queue 種別ごとに 4 決定 wording を変える」を Variant C で state-aware に拡張 / canon §6 No-Signal Rule (「受理」 != no issue を毎 chip muted ⊘ glyph で構造的に表現)
ROW 3 (in_progress / Manager Context) には .self-action-hint = emerald-50 bg + italic で 「あなたが昨日 drill-down 済み (audit row 発生済み)」 を summary-line-1 に inline 表示。 これは reviewer 自身の audit 行為履歴 (canon § DATA_VISIBILITY_MATRIX 上の「audit log entries about this person, Reviewer = Y (their own actions)」) であり、 affected person 情報ではない。 inbox 再訪時に「これは自分が既に触った案件」 と即時認識でき、 stale な in_progress 放置を防ぐ。 また「再訪では新規 audit row が発生しない (1 日 1 row)」 という挙動も footer で補足明示。
trace: 02_proposals DATA_VISIBILITY_MATRIX 行「あなたが昨日 drill-down 済み note (in_progress 行) — Reviewer = Y (self audit)」(L647) / wireframe ROW 3 (L573-576)
disputes / pattern_summaries [severity-exception flag] / manager_context_submissions / pattern_summaries [inconclusive grace]) を 単一 inbox view に join する設計は、 既存 RLS の保証境界を実質的に変える。 mockup 上では「impl-warning」 aside box で reviewer (Justine) 自身に 警告として常時 visible。 採用 confirm 前に下記を確認 / 設計しないと cookie monster (security regression) リスクが顕在化。
reviewer_inbox_view を作成、 RLS 自体は queue 別 table に維持実装フェーズで作成すべき view の概念図:
auth.uid() + org_id + assigned_meeting_ids で intersect)、 (b) state derivation (audit_log 結合で in_progress / escalated 算出)、 (c) k-anon threshold check (各行の affected_person cardinality > k-1)、 (d) queue type tagging (どの source table から来たか)SECURITY INVOKER (default) で各 source table の RLS が動作する形を維持。 これは Supabase の standard pattern。trace: 02_proposals 残るリスク §「RLS 改修コスト大」 (L668) / 02_proposals 「4 queue を統合 inbox に表示するため、 4 個別 RLS-secured table を join した view (or materialized view) が必要」 (L656) / mockup impl-warning aside box (1700-1705)
test/rls/role-expansion + test/rls/isolation 再 audit 必須inbox view 経由のアクセス path を 4 role (admin / hr_compliance / restricted_investigator / non-reviewer) すべてで scope 越境テスト を再追加。 具体的に必要なテストケース:
これら 6 テストケース + 既存 RLS test との regression 確認 (4 個別 table の direct read RLS が view 導入で意図せず緩まないこと) を満たさないと canary deploy 不可。
trace: 02_proposals 「test/rls/role-expansion に inbox view 経由のアクセス path を追加必須」 (L656) / mockup impl-warning aside box L1699 / r19 RLS test 既存パターン
Variant C の inbox 統合は単なる UI 改変ではなく 「visibility boundary の表面化方法」 の変更にあたる。 既存 canon では「4 queue が個別に存在する」前提で書かれている doctrine 箇所 (例: ReviewerCockpitDoctrineSection 内 4 lane 別 doctrine、 reason-code-registry の lane-specific セクション) があれば、 inbox 統合に合わせて canon-modification proposal を 事前に 提出する必要がある。 mockupper の現時点判断では 「Variant C は canon-touching 可能性中〜高、 orchestrator + 開発リードに事前確認推奨」。 仮に canon-touching なし (4 queue doctrine は個別ページに留まる、 inbox 統合は landing view のみ) と判断されれば、 doctrine-modification process 不要で直接実装可。
trace: 02_proposals 残るリスク §「doctrine-modification process (CANONICAL_PRODUCT_TRUTH §8) の発動が必要かもしれない」 (L668) / mockup impl-warning aside L1700
Variant B では k-anon suppression は 個別 card 単位 の demo 1 件のみだったが、 Variant C では 行単位で per-row 評価 が必要。 理由: 1 行に「queue type + meeting count + window + scope description」 が並列表示されることで、 小規模 dyad / small team では affected person を間接特定できる確率が Variant B より上がる (translator 残るリスク L672 明示)。 mockup の ROW 5 (Grace / k-anon SUPPRESSED) はこの suppression を視覚化したもので、 row 全体を suppressed-row 化 + dashed #FCD34D border-top + warn-bg + suppression-block で「閾値未満」を構造的に通知。
実装側で追加が必要な helper:
kashi/src/lib/next-actions/safety-gates.ts に新規 gateBoundedQueueRowVisibility(row, viewerScope) を追加、 row 内 affected_person_id set cardinality を計算し k=3 未満なら row 全体を suppressed flagtrace: 02_proposals 残るリスク §「k-anon-style suppression が一層重要」 (L672) / mockup ROW 5 suppression-block 文言 (L1428-1432) / Variant B DESIGN_DECISIONS §8 同様 helper を継承拡張
mockup の .onboarding-banner (黄色 #FFF8E7 → #FEF9EC gradient + #FCD34D border) を visibility-notice 直下、 filter row 直上に配置。 文言:
新しい unified inbox に変わりました (Variant C 試験運用中) — 以前の 4 個別 queue カード (Disputes / Severity / Context / Grace) は単一の priority inbox に統合されました。 各行に queue type chip を残しているので個別 lane の context は失われません。 個別 lane ページ (例 /app/reviewer/disputes) はそのまま残置されており、 行の「個別ページで処理する」 から従来通り遷移します。 RLS / audit semantics / 4 決定オプションも従来と完全互換です。
右端に 「了解、 閉じる」 button で dismiss 可。 実装フェーズでは localStorage または server-side user preference に dismiss state を保存し、 同一 viewer に二度 onboarding が出ない設計が必要。 文言中の「Variant C 試験運用中」 は本 mockup demo の文脈であり、 production 採用後は削除すべき (実装フェーズ引き継ぎ)。
trace: 02_proposals 残るリスク §「onboarding コスト」 (L671) 「in-app tooltip + ヘルプ docs + migration period 必須」 / mockup .onboarding-banner (L1096-1106)
/help/reviewer-inbox-migration ドキュメントを作成 (実装フェーズ引き継ぎ)
in-app tooltip だけでは情報量不足。 別途 help docs (route 案: /help/reviewer-inbox-migration) を新設し、 (a) なぜ統合したか / (b) 4 queue 個別ページは消えていないこと / (c) 4 決定 / RLS / audit semantics が無変更であること / (d) state machine の意味 / (e) k-anon suppression の挙動 / (f) onboarding tooltip dismiss 方法、 をすべて記載する必要がある。 mockup 自体には help docs route はないが、 実装フェーズで必須 (impl-warning aside box L1702 で明示)。
trace: mockup impl-warning aside box L1702 / 02_proposals onboarding コスト言及
各行右下の primary CTA は 「個別ページで処理する」 文言で統一 (escalated は「状況を確認する」、 closed は「記録を参照」)。 これは 意図的に 「インボックスは概観、 実際の決定操作は個別ページ」 という 2 段階モデルを明示化する文言。 既存 reviewer が「あれ、 ここで決定操作はできないのか」 と迷う可能性に対し、 全行で「→ 個別ページ」 ナビ動線を視覚的に予告。 row-meta-line に → /app/reviewer/disputes 等の route を明示するのも同目的 (URL を見て「ああ、 従来のあの画面に行くのか」 と既存 reviewer が直感的に理解できる)。
trace: mockup row-cta wording 全 9 行で一貫 / 4 queue 別ページ「個別 deep link 先として残置」(02_proposals L541) / muscle memory migration 設計
| 軸 | Variant B (中庸 / 4 queue card stack) | Variant C (大胆 / Unified Inbox) ← このページ |
|---|---|---|
| 主構造 | 4 queue card vertical stack、 各 card 内に next-actionable 1 件 mini-summary | 単一 priority inbox、 行 (row) を最小単位、 queue 種別は行内 chip + filter chip + deep link で保持 |
| 並べ替え単位 | queue 種別ごと、 各 card 内で next-actionable を抽出 | 行単位 (queue 横断)、 oldest first default、 sort 4 軸明示 (oldest/newest/grade/queue) |
| state 表現 | card 内 inline state pill (pending/in_progress/escalated 3 状態を「視覚ヒント」 で並列表示) | 正式 4-state machine (pending/in_progress/escalated/closed) + filter chips で state 別絞り込み + 専用 row style 差別化 |
| filter row | 無 (queue 別 card が事実上の filter として機能) | sticky filter row (state × queue × window × sort) を H1 直下に常時 visible、 scope を視覚宣言 |
| RLS | 無改変 既存 4 queue table のまま (各 page.tsx の direct query 維持) | 改修必須 reviewer_inbox_view 新設 + test/rls/role-expansion + test/rls/isolation 全再 audit + canon-touching 可能性確認 |
| k-anon suppression | 個別 card で 1 件 demo (mockup レベル) | 行単位で per-row 評価必須 (1 行に meta が並列で identity 間接特定リスクが高い)、 helper 新設必須 |
| onboarding コスト | 低 既存 4-queue メタファー保持、 muscle memory そのまま | 中〜高 in-app tooltip + 移行 docs + 個別ページ deep link 維持で軽減 |
| 4 決定 (受理/却下/追加情報/エスカ) | queue 種別ごとに wording 変化 (例 Severity「受理 (例外承認)」)、 全 chip active 表示 | queue 別 wording 継承 + state 別 chip muted 化 (escalated/closed で適切な chip を ⊘ 化) |
| EyeOff metaphor | FileSearch 置換済み (Inconclusive Grace card) | FileSearch 置換済み (Grace lane queue-chip / k-anon suppression block の両方) |
| doctrine-modification | 不要 (canon に手を入れない) | 事前確認推奨 (canon-touching 可能性中〜高、 4 queue 別 doctrine セクションの統合可否) |
| 実装工数 | M (~16-24h): page.tsx + 5 新規 component + i18n key 追加 | L (~60-80h, A/B の 3 倍): page.tsx 全面再設計 + RLS view + RLS test 再 audit + onboarding + help docs + doctrine 確認 |
| 仮説不満 5 個の解決率 | 5/5 | 5/5 (translator 評価では同等) |
| 他 surface への波及 | 無 (本 surface 局所改善のみ) | 有 — 「inbox メタファー」 がポストログイン全体 (Manager / CEO / Employee) の共通基盤になり得る (Round 2 で全 surface 横断検討) |
| 失敗時の rollback コスト | 低 (page.tsx を revert で済む) | 中〜高 (RLS view + test + i18n 変更を revert + onboarding tooltip 撤去 + help docs アーカイブ) |
<details class="doctrine"> で fold。 個別 row 詳細・実行 UI は drill-down (個別ページ) に委譲。 5 サブコンポーネント doctrine → 1 段落 + 1 link 圧縮済み。:hover での bg 色変化 (paper-tint) のみ、 識別情報の追加表示は一切なし。 これにより「hover した瞬間に名前を載せてしまうバグ」 を構造的に発生不可能にする。EyeOff import / L113 の <EyeOff className="w-5 h-5" /> 使用箇所を、 mockup では完全に FileSearch SVG (path: M14 2H6a2 2 0 0 0-2 2v16... circle cx=11.5 cy=14.5 r=2.5 ...) に置換。 Grace lane queue-chip (ROW 5) と k-anon suppression-icon の両方で FileSearch 使用。 EyeOff (eye + slash) の「監視を表象する」 metaphor を排除、 「文書を確認する」 metaphor で canon-safe。| Field | Variant C で表示 | Matrix § 根拠 |
|---|---|---|
| queue type chip (各行) (Dispute/Severity/Context/Grace) | Y | §3 lane 種別表示は Reviewer = Y、 person 名は出さず |
| state (pending/in_progress/escalated/closed) | Y | §3 audit log entries 派生 (Reviewer 自身の状態), §3 procedure status |
| evidence grade (各行) / reason code | Y | §3 bounded queue 内 grade/reason — Reviewer = Y |
| meeting count + window + scope description (dyad bounded) | Y | §3 per-pair/dyad metrics — bounded queue 内 Y、 抽象表現に留める |
| self-action audit hint (「あなたが昨日 drill-down 済み」) | Y (self audit のみ) | §3 audit log entries about this person Reviewer = Y (their own actions)。 affected person 情報ではなく reviewer 自身の行為履歴 |
| affected_candidate / source_candidate identity (name/dept) | N — 構造的不可 | §4 anti-retaliation gate, hover preview も廃止で漏出経路無し |
| 他チーム inbox / 全社俯瞰 | N (nav + RLS view 二重防御) | §3 team aggregates は under procedure のみ、 ランディング非露出 |
| 同一 affected person の複数 lane 横断参照 | N — 構造的不可 | §4 anti-retaliation, queue-chip は lane 種別のみで person id を行間連結しない |
| k-anon suppressed row の grade/reason/scope | N (suppression-block で明示) | §4 small group suppression — k=3 閾値 |
| escalated row の handler 名 (人名) | N — procedure_id のみ | §3 admin = Y, default reviewer = N (「別 reviewer 委譲済み」 事実のみ) |
| closed row の recorded_by | Y (自分の名前のみ「あなた (林さん)」表記) | §3 自身の action は self-audit として visible |
本 inbox 閲覧 (scope-safe meta + suppression 表示のみ) では audit_log row は 発生しない (Variant B と同挙動)。 各行の「個別ページで処理する」 click で drill-down した瞬間に affected person 側の audit log に 即時 1 row 記録。 in_progress 状態の行 (ROW 3) を再訪しても新規 row は発生せず (1 日 1 row 制限想定)。 sort 変更 / filter 操作 / onboarding dismiss は client-side のみ、 audit row 発生せず。 この挙動は visibility-notice doctrine fold (h4「あなた (HR/Compliance Reviewer) に許可される閲覧」) + footer の 3 箇所で明示。
| 項目 | 現実装 (page.tsx, 153 行) | Variant C mockup (~1855 行) |
|---|---|---|
| 主構造 | 4 QueueCard を md:grid-cols-2 2x2 grid 配置、 max-w-5xl (960px) |
単一 inbox-row 縦 stack (max-w 1180px) + sticky filter row + onboarding banner + impl-warning aside + 詳細 footer |
| per-row 単位 | queue 種別 = 1 card (icon + label + count + description のみ) | state-dot + queue-chip + state-pill + summary-line-1 + scope-line + 4 decision-chip + CTA + meta-line を grid-template-columns: 28px max-content max-content 1fr max-content で複合配置 |
| state 表現 | 無 (count = 0 のみ ink-faint 表示) | 4-state machine (pending/in_progress/escalated/closed) + state-dot + state-pill + 専用 row class (escalated-row / closed-row / suppressed-row) |
| filter | 無 (4 queue 別ページに移動して初めて filter 概念) | sticky filter row (state × queue × window × sort) を H1 直下、 JS で chip toggle + 行 visibility 制御 + 表示件数更新 |
| data fetch (server) | 4 separate count queries (disputes / pattern_summaries 2 種 / manager_context_submissions)、 各 head:true count | 新規 reviewer_inbox_view 経由の 1 query で全 row 取得想定 (mockup ではダミー HTML 直書き)。 state derivation + k-anon flag + queue type tagging を view 層で実行 |
| Doctrine | ReviewerCockpitDoctrineSection = Hero + EvidenceQualityFramework + DecisionPolicyPanel + VisibilityBoundary + Caveats 5 section 一括展開 |
.visibility-notice = 1 段落 default visible + <details> で 4 doctrine subsection を fold (5 section 圧縮) |
| Icon for Inconclusive Grace | EyeOff from lucide-react (§13 surveillance metaphor 違反) |
FileSearch SVG inline (Grace queue-chip + k-anon suppression-icon の両方)、 EyeOff 完全撤去 |
| Eyebrow tracking | tracking-[0.3em] (page.tsx L55、 r19 §6.4 不整合) |
letter-spacing 0.04em 統一 (全 eyebrow / state-label / mono ラベル) |
| onboarding | 無 (初回利用も 4-queue grid で完結) | dismissable banner (yellow gradient) + 移行 docs (実装フェーズ追加) |
| k-anon suppression | 無 | per-row 評価 (suppressed-row 1 件 demo) + suppression-block で文言 + FileSearch icon、 helper 新設必須 (gateBoundedQueueRowVisibility) |
| nav-scope-note | welcomePre + display_name の welcome 文のみ | PortalHeader-nav 右端に「scope: assigned meetings only / window 30d」 mono caption で常時表示 |
| RLS / DB / route | 既存 4 queue table、 4 separate RLS | 新規 reviewer_inbox_view 追加、 4 RLS は維持、 view 層は SECURITY INVOKER。 test/rls/role-expansion + test/rls/isolation 再 audit 必須。 4 queue 個別ページ (/app/reviewer/disputes 等) は touch せず deep link 先として残置 |
| i18n keys | reviewer.home: kicker / h1 / welcomePre / welcomePost / queueDisputesLabel 等 / footer | 上記 + 新規 namespace: reviewer.inbox.* (filter labels / state labels / decision chips / onboarding banner / suppression block / impl warning / empty state / b-vs-c comparison)。 39 i18n verbatim test 同期必須 (pre-commit hook auto-discover) |
ReviewerInbox (新規 shared) — inbox container, 100 件上限 + pagination promptInboxRow (新規 shared) — 行コンポーネント、 state-aware (pending/in_progress/escalated/closed/suppressed 5 variant)InboxFilter (新規 shared) — sticky filter row (state × queue × window × sort)、 chip group + selectStateBadge / StatePill (新規 shared) — 4 状態 + suppressed の color/glyph/text 三重EvidenceGradeBadge (もし shared として未存在なら新規) — 6 grade 対応QueueChip (新規 shared) — Lucide icon + label、 4 queue type 対応 (FileSearch を Grace に確実 mount)KAnonSuppressionRow (新規 shared, safety-gates と協調) — row 全体 suppress 時の専用 layout、 suppression-block + warn-bg + dashed border + 4 decision-chip は維持表示OnboardingBanner (新規 shared) — dismissable, localStorage / server-side preference 連携VisibilityNoticeCompact (新規, ReviewerCockpitDoctrineSection の代替) — 1 行 default + details foldInboxImplWarning (Variant C 限定、 production 削除可) — 採用試験中の備忘 asidesupabase/migrations/<timestamp>_reviewer_inbox_view.sql — 4 RLS-secured table の join + scope filter + state derivation + k-anon flagkashi/src/lib/next-actions/safety-gates.ts に gateBoundedQueueRowVisibility(row, viewerScope, k=3) 追加kashi/src/lib/analysis/role-adapters/reviewer-cockpit-adapter.ts 拡張 — viewModel に inbox rows + state derivation + suppression flag + pagination metatest/rls/role-expansion.test.ts + test/rls/isolation.test.ts に inbox view 経由 6 ケース追加 (§d 4 列挙)このモックアップを実装に進めるかどうかは、 以下 5 点を確認してから決定してください:
Variant C 採用は RLS 改修必須 です: 新規 reviewer_inbox_view + test/rls/role-expansion + test/rls/isolation 全再 audit + canon-touching 可能性確認 + doctrine-modification process 発動可否。 これらは「reviewer surface だけの改善」 のためには 明らかにオーバー投資 です。 もし採用するなら、 ポストログイン全体 (Manager / CEO / Employee) を inbox メタファーで揃える Round 2 の試金石として 投資する判断が前提。
判断軸:
(a) Round 2 で全 surface の inbox 統一を検討する予定がある → confirm 推奨
(b) reviewer surface 単独で C のメリットだけ欲しい → redo (Variant B に戻す or A の最小修正で済ます)
in-app onboarding banner (黄色 dismissable) + /help/reviewer-inbox-migration docs 追加 + 移行期間を運用しても、 「4 queue card に慣れた既存 reviewer が新しい inbox で混乱する」 リスクは確実に発生します。 ただし mockup では (a) 各行に queue type chip を明示残置、 (b) deep link 先 (個別ページ) を route として visible にする (例 → /app/reviewer/disputes)、 (c) 「個別ページで処理する」 CTA で 2 段階モデルを文言化、 で緩和しています。
判断軸:
(a) 既存 reviewer が 1-2 名のみ (pilot 段階)、 1 on 1 で説明可能 → confirm 推奨
(b) 既存 reviewer が複数組織にまたがる、 onboarding 工数が許容できない → redo (Variant B)
mockupper は意図的に 「resolved as no issue」「all clear」 を state に入れていません (§6 No-Signal Rule)。 closed は「決定が記録された」 意味のみで、 受理/却下の内訳は drill-down 先で確認する設計。 これにより「閉じた = 問題なかった」 と誤読される経路を構造的に閉鎖していますが、 一方で reviewer が「closed が 2 件あるけど何の決定だったか一覧で確認したい」 と思った時の cognitive overhead は drill-down 1 click 必要になります。
判断軸:
(a) §6 正面遵守の透明性が優先 → confirm
(b) closed の決定種別 (受理/却下) を行内に summary 表示したい → redo (closed-row 内に decision-summary 行を追加する派生案を再起動)
ROW 5 の suppressed-row + suppression-block (黄色 bg + 「k-anonymity 閾値未満のため、 inbox 行内 preview を suppress しています」) は、 reviewer に 「個別ページに行けば見られる」 こと + 「suppression 解除条件 (assigned scope に該当 lane の meetings が追加され k=3 を満たした時点)」 を文言で明示しています。 ただし「なぜ自分は見られないのか」 が transparently に伝わっているか、 「Kashi が秘密主義」 と感じる文言になっていないかは、 Justine の native-eye 判断が必要。
判断軸:
(a) suppression 文言が transparent、 「保護のため」 と理解できる → confirm
(b) 文言が抽象的すぎる / 「Kashi が隠している感」 が出る → redo (suppression-block の文言を Gemini に native-eye review routing)
(c) k 値の妥当性 (k=3 で良いか) を product owner doctrine 化したい → redo + canon-touching discussion
「あなたが昨日 drill-down 済み (audit row 発生済み)」 「k-anonymity 閾値未満のため、 inbox 行内 preview を suppress しています」 「assigned scope: 12 meetings / 4 lane types / window 30d」 等の文言は、 林さん (HR 中立観察者) にとって自然に響くか / 専門用語の英語 (drill-down / k-anonymity / scope / lane) と日本語の混在比率は適切か。 違和感があれば Gemini に native-eye review を routing して redo (multi-LLM routing protocol)。
判断軸:
(a) 専門 reviewer 想定なら英語混在 OK → confirm
(b) 一般 HR 担当者でも読めるよう日本語化が必要 → redo (Gemini routing で JA copy refinement)
Confirm 場合: confirm mockup app-reviewer C
Redo 場合: orchestrator: redo mockup app-reviewer C <feedback>
変更要望例:
redo mockup app-reviewer C suppression block 文言を Gemini で校正
redo mockup app-reviewer C closed-row に decision-summary 行追加
redo mockup app-reviewer C onboarding banner 削除 (production 採用後)
Variant 再選択場合: pick app-reviewer=B (Variant B mockup と比較して中庸案に戻す)
Generated: 2026-05-27T+09:00 by kashi-ui-mockupper / Stage 3 of 3 (post socket-error recovery) / Inputs: 02_proposals/app-reviewer__variants.html §Variant C (L528-680), 03_mockups/app-reviewer/C/index.html (1855 行, 既存), 03_mockups/app-reviewer/B/DESIGN_DECISIONS.html (template baseline), design_system_v1.md (token canon), permanent-ui-principles.md (§1-§14), globals.css (canonical tokens), kashi/src/app/app/reviewer/page.tsx (read-only diff baseline 153 行).
Read-only on kashi/ source. No code edits. Pure HTML/CSS, no JS in this DESIGN_DECISIONS file.