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
1.7 KiB
1.7 KiB
Follow-Up Recommendations
Status: complete.
No Immediate Follow-Up Required
Spec 374 closes the active entrypoint ambiguity without adding a hub, navigation branch, provider checks, repair logic, or new framework.
Deferred Candidates
| Candidate | Trigger | Recommended Handling |
|---|---|---|
| Provider/Permission Diagnostic Productization | Fresh evidence shows Provider Connections or Required Permissions no longer answer provider readiness questions clearly. | Separate follow-up spec; do not place provider readiness inside Repair Diagnostics. |
| Evidence/System Browser Fixture Coverage | Browser reachability remains blocked for Evidence Snapshot or /system surfaces and product priority warrants proof. |
Separate fixture/auth coverage spec. |
| UI Bloat Regression Guard | Repeated specs keep adding diagnostic/support entrypoints without shared review automation. | Separate guard/spec after one more confirmed recurring pattern. |
| Support Desk / PSA Handoff Productization | Support diagnostics needs lifecycle or external handoff behavior beyond current redacted context. | Separate support workflow spec; do not expand Support Diagnostics modal inside this slice. |
| Repair-Blocker Browser Fixture | Manual review requires screenshot proof for duplicate membership or missing-owner repair states. | Add only if an existing fixture pattern can create the state safely; otherwise keep Feature/Livewire coverage. |
Explicitly Not Recommended From This Spec
- Do not build a Diagnostic Hub.
- Do not add Environment Repair Diagnostics to top-level navigation.
- Do not move provider, permission, evidence, customer review, system, or OperationRun truth into the repair page.
- Do not add Graph/provider HTTP calls to render paths.