ahmido
d2876af95b
Implemented the first version of provider readiness resolution guidance. Added the ProviderReadinessResolutionAdapter, provider readiness guidance card, and updated EnvironmentRequiredPermissions, ProviderConnectionResource, and ListProviderConnections/ViewProviderConnection. Added tests and updated the design coverage matrix. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #424
58 lines
2.5 KiB
Markdown
58 lines
2.5 KiB
Markdown
# 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.
|