# 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 ## Spec 356 Follow-up Spec 356 keeps this detail page as the owner-side explanation surface but replaces the customer-workspace detail CTA with one dominant rendered-report handoff. - customer-workspace detail mode now opens the rendered stakeholder report instead of leading with ZIP download - the rendered-report affordance only appears when the current export review pack is ready, current, and not expired - ZIP contract truth and appendix semantics remain secondary proof, not a second competing primary CTA ## 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.