ahmido
0a1ecf99c9
Applied diagnostic surface contract rules to Audit Log inspect modal and Support Diagnostics action context, consolidating raw diagnostic data into safe modals according to Spec 374. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #445
3.5 KiB
UI-012 Environment Repair Diagnostics
| Field | Value |
|---|---|
| Route | /admin/workspaces/{workspace}/environments/{environment}/diagnostics |
| Source | EnvironmentDiagnostics |
| Area / scope | Repair diagnostics / environment |
| Archetype | Support / Diagnostics |
| Design depth | Domain Pattern Surface |
| Repo truth | repo-verified |
| Screenshot | specs/374-diagnostic-entry-point-support-diagnostics-consolidation/artifacts/screenshots/003-environment-repair-diagnostics-after.png planned after Spec 374 browser smoke; previous proof remains specs/373-diagnostic-surface-separation/artifacts/screenshots/001-environment-diagnostics-after.png. |
| Browser status | Spec 373 smoke-login fixture reached no-action state. Spec 374 narrows the canonical noun and copy to Repair diagnostics and adds secondary support-modal proof. |
First Five Seconds
The page now leads with one repair-diagnostics summary: current blocker count or no-action state, impact, recommended first check, and the dominant repair path when a repair is applicable. A secondary Open support diagnostics action is available for broader read-only support context.
Productization Review
- Decision-first: improved; the page no longer opens with a generic "all good" card, broad health claim, or competing repair messages.
- Evidence-first: blocker details remain visible below the summary with failed condition, impact, and next check.
- Context: environment-owned repair surface using DB-local tenant membership truth.
- Customer/auditor safety: internal/admin-only repair surface.
- Diagnostics: provider, evidence, system, and technical details stay out of the repair page unless they explain the active tenant membership blocker.
Information Inventory
Default content now includes:
- one calm repair-only no-action summary when no membership repair applies
- one secondary read-only
Open support diagnosticsmodal handoff for broader provider, operation, evidence, or audit context - one ordered summary when one or more blockers apply
- failed condition, impact, and next check for missing owner and duplicate memberships
- existing capability-gated repair actions in the Filament header
Dangerous Actions
Bootstrap owner and Merge duplicate access scopes remain destructive, confirmation-gated, capability-gated, and backed by the existing repair services. The UI change does not add automatic repair, provider calls, migrations, or new runtime dependencies.
Scores
| IA | Density | User Clarity | Sellability | Disclosure | Hierarchy | DS Fit | A11y | Responsive | Components | UX Writing | Perf |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 |
Top Issues
- Missing-owner runtime truth remains intentionally hidden by the current workspace-role recovery model; tests cover only the presentation path.
- Broader support workflows remain outside UI-012; the page can hand off to the support modal, but provider/evidence/system remediation should stay on separate specs.
- Future blocker-state browser proof would need a safe fixture that creates duplicate membership state without changing shared smoke setup.
Target Direction
Implemented in Spec 373 as a bounded hierarchy pass over the existing diagnostics page, then narrowed by Spec 374 into the Repair diagnostics entrypoint contract. Future work should address broader support workflows only through separate provider, evidence, system, or support-handoff specs.