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
2.5 KiB
2.5 KiB
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
- Summary and issues sections still carry some duplicate readiness language under the new top guidance.
- The page still asks the operator to understand Microsoft permission semantics in the detailed matrix.
- 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.