# UI-077 Required Permissions

| Field | Value |
| --- | --- |
| Route | `/admin/workspaces/{workspace}/environments/{environment}/required-permissions` |
| Source | `EnvironmentRequiredPermissions` |
| Area / scope | Provider readiness / permission posture / environment |
| Archetype | Provider / Integration |
| Design depth | Domain Pattern Surface |
| Repo truth | repo-verified |
| Screenshot | `specs/353-provider-connections-resolution-guidance-v1/artifacts/screenshots/ui-077-required-permissions.png` |
| Browser status | Guidance-integrated; desktop screenshot saved under the Spec 353 artifact path. |

## First Five Seconds

The page now answers the operator case first: what blocks readiness, why it matters, and what the safest next step is before the raw matrix appears.

## Productization Review

- Decision-first: strong; provider-readiness guidance and permission handoff sit above the matrix.
- Evidence-first: counts, capability groups, freshness, and copy payloads still support the operator after the primary decision.
- Context: environment-owned; route scope stays authoritative.
- Customer/auditor safety: operator-only diagnostics, no fake remediation.
- Diagnostics: raw permission detail stays secondary and technical details stay collapsed by default.

## Information Inventory

Default content now includes:

- one dominant provider-readiness case
- one primary action
- permission handoff guidance
- permission counts and freshness
- capability-group posture
- copy payload actions
- the native permission matrix
- collapsed technical details

## Dangerous Actions

No direct consent execution or automatic repair is introduced. Verification starts only through the existing safe path and only when capability-gated.

## Scores

| IA | Density | User Clarity | Sellability | Disclosure | Hierarchy | DS Fit | A11y | Responsive | Components | UX Writing | Perf |
| ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| 4 | 4 | 5 | 5 | 4 | 5 | 4 | 4 | 4 | 4 | 4 | 4 |

## Top Issues

1. Summary and issues sections still carry some duplicate readiness language under the new top guidance.
2. The page still asks the operator to understand Microsoft permission semantics in the detailed matrix.
3. Browser artifacts should remain part of the spec evidence path because this page is highly hierarchy-sensitive.

## Target Direction

Implemented in Spec 353 as a bounded readiness-guidance layer over the existing permission-truth builder. Future work should refine copy and density, not rebuild the permission model.