TenantAtlas/docs/ui-ux-enterprise-audit/page-reports/ui-040-environment-review-detail.md
ahmido d4e4d2d109 feat: review output resolve actions v1 (spec 351) (#422)
Implemented the first version of review output resolve actions. Included a ReviewOutputResolveActionMapper, commands to seed browser fixtures, updated CustomerReviewWorkspace, EnvironmentReviewResource, UI enforcement, and related views. Also added extensive unit, feature, and browser tests, and updated the design coverage matrix.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #422
2026-06-04 00:55:02 +00:00

70 lines
3.7 KiB
Markdown

# UI-040 Environment Review Detail
| Field | Value |
| --- | --- |
| Route | `/admin/workspaces/{workspace}/environments/{environment}/environment-reviews/{record}` |
| Source | `EnvironmentReviewResource::view` |
| Area / scope | Reviews / environment detail |
| Archetype | Evidence / Audit |
| Design depth | Strategic Surface |
| Repo truth | repo-verified |
| Screenshot | `Spec 351 browser proof: specs/351-review-output-resolve-actions-v1/artifacts/screenshots/02-mutable-blocked.png` |
| Browser status | Reached through direct environment routes for mutable-blocked and ready-draft states, plus the existing customer-workspace handoff regression path. |
## First Five Seconds
The page should answer three questions without forcing the operator to reconstruct the review from raw sections:
1. what is the review status
2. what is the output readiness
3. what is the safe next step
## Productization Review
- Decision-first: improved by the shared resolution-case summary.
- Evidence-first: limitations and technical details remain visible below the summary.
- Context: environment-bound review detail with optional customer-workspace handoff context.
- Customer/auditor safety: high because this page explains whether the current released output is share-safe.
- Diagnostics: sections and raw detail stay secondary to the first-screen output guidance.
## Information Inventory
Default content should show lifecycle status, output guidance, publication/sharing boundary, evidence snapshot linkage, current export linkage, and section completeness.
## Dangerous Actions
Lifecycle actions such as refresh, publish, export, create-next-review, and archive remain source-owned. In customer-workspace detail mode, the repeated primary action rail should stay suppressed so the operator does not get duplicate or conflicting calls to action.
## Spec 349 Follow-up
Spec 349 separated review status, output readiness, and publication/sharing state while keeping the customer-workspace detail mode free of repeated CTA rails.
## Spec 350 Follow-up
Spec 350 adds the shared review-output resolution-case handoff:
- the first-screen summary now uses the same issue / reason / impact / next-action reading direction as the workspace
- source refs and evidence refs remain repo-backed in the underlying contract
- customer-workspace detail mode still suppresses repeated action buttons and keeps the limitations/technical-details path as the primary inspection flow
## Spec 351 Follow-up
Spec 351 aligns detail-surface next-step semantics to the same resolve-action mapper without creating a duplicate CTA rail inside the guidance card.
- mutable blocked reviews now resolve to the existing `refresh_review` header action
- ready mutable reviews now resolve to the existing `publish_review` header action with the current publication-reason flow
- published blocked reviews can align to `create_next_review` or `open_successor_review` only when the action/target is repo-real
- customer-workspace detail mode remains suppress-primary and keeps the explanation/proof path intact
- the workspace remains the only surface that groups supporting secondary actions; detail keeps a single dominant lifecycle rail and explanation/proof follow-through
### Browser proof
- Spec351 screenshots: `specs/351-review-output-resolve-actions-v1/artifacts/screenshots/`
- Verified states:
- `02-mutable-blocked.png` shows the `Refresh review` confirmation path
- `03-ready-draft.png` shows the `Publish review` modal with the existing reason field
## Target Direction
Keep this surface audit- and evidence-oriented. If future work broadens it beyond the review-output path, that should happen through a dedicated detail-surface spec rather than hidden incremental drift.