Provider permissions: UI — Permissions tab with tier cards

[jeonghun-jj-lee]

Important

Decision Surface

Problem: No UI exists for users to view or configure trust tiers and their directory permissions.

Approach: Add a 6th "Permissions" tab to the settings dialog. Renders one card per trust tier with a directory × action checkbox matrix, summary badges, and danger highlights on Execute/Network.

Scope: Tab + tier card rendering + checkbox interactions + badge computation. Does not include model assignment (slice #8) or tier CRUD (slice #9).

---

Acceptance Criteria

• A "Permissions" tab appears as the 6th tab in the settings dialog
• One card renders per configured trust tier, showing: tier label, summary badge, directory rules
• Each directory rule row shows 4 checkboxes: Read, Write, Execute, Network
• Checkboxes cycle through: allow (checkmark) → deny (x) → ask (tilde) → allow
• Checkbox changes persist to config immediately (same pattern as other settings)
• Execute and Network columns have a subtle orange/warning tint when set to "allow"
• Card-level summary badge auto-computes: "Full Access" (⚠️), "Read Only", "No Access", "Ask Everything", "Custom"
• The "Unassigned" tier card is visually distinct (always last, non-deletable indicator)
• Cards are collapsible for users with many tiers
• Tab is accessible and keyboard-navigable

Key Decisions

#	Decision	Rationale
1	Checkbox tri-state cycle (allow/deny/ask)	Three states map directly to the Effect type; cycling is discoverable
2	Badge auto-computed from rules	User gets at-a-glance posture without reading every checkbox
3	Danger highlights on execute/network only	These are the actions that enable code execution or data exfiltration

Testing Decisions

• Test tab renders with default tiers when no config
• Test checkbox click cycles through allow → deny → ask
• Test badge computation for each posture (full, read-only, no-access, ask-all, custom)
• Test danger styling applies to execute/network columns when "allow"
• Test "Unassigned" card is always last and shows non-deletable state

Constraints & Invariants

• Must follow existing settings dialog patterns (same component library, same persistence flow)
• Must be responsive / not break at narrow dialog widths

Source

Part of #163
Blocked by #164