TenantAtlas/docs/ui-ux-enterprise-audit/page-reports/ui-006-customer-review-workspace.md

UI-006 Customer Review Workspace

Field	Value
Route	/admin/reviews/workspace
Source	CustomerReviewWorkspace
Area / scope	Customer review / workspace
Archetype	Customer Workspace
Design depth	Strategic Surface
Repo truth	repo-verified
Screenshot	Spec 351 browser proof: specs/351-review-output-resolve-actions-v1/artifacts/screenshots/01-published-blocked.png
Browser status	Reached through the local workspace route for executable and readonly-fallback states.

First Five Seconds

This is the most important customer-safe productization candidate. The page should answer what the customer can trust, what changed, what risks are accepted, which evidence supports the state, and what should happen next.

Spec 344 tightens the hierarchy so the Operator Summary (decision + acknowledgement + findings signal) comes first, while the review consumption flow and proof panels remain available as supporting details.

Productization Review

• Decision-first: improved by explicit Operator Summary-first hierarchy.
• Evidence-first: must anchor all claims to review/evidence artifacts.
• Context: workspace-level customer view.
• Customer/auditor safety: primary concern.
• Diagnostics: raw/internal details must stay hidden by default.

Information Inventory

Default content should include review readiness, review acknowledgement (attestation) state + action, evidence basis, accepted risk summary, decision summary, review-pack download, and a management-readable next action.

Dangerous Actions

Customer-facing surface should be read-first. Export/download and publish/review actions need clear scope, audit, and language. The acknowledgement action is a write/mutation action and must remain confirmation-gated, capability-gated, and auditable, without legal/e-signature semantics.

Scores

IA	Density	User Clarity	Sellability	Disclosure	Hierarchy	DS Fit	A11y	Responsive	Components	UX Writing	Perf
3	4	4	5	3	4	4	3	3	4	3	4

Top Issues

1. Acknowledgement copy must remain customer-safe and explicitly non-legal (no compliance certification semantics).
2. Evidence and accepted-risk meaning should be visible without raw diagnostics.
3. Sidebar proof panels can still compete visually with the main decision flow; keep them secondary and avoid duplicating “ready/available” signals at equal weight.

Target Direction

Spec 344 implements the first density/hierarchy polish wave. If the surface still feels too dense after real operator use, follow up with a targeted mockup and a second, narrower polish pass rather than adding new workflow surfaces.

Spec 347 Follow-up

Spec 347 hardens the Review Pack output contract and aligns the workspace with the review-pack ZIP semantics instead of collapsing everything into a generic "ready" claim.

• Decision-card status is now contract-backed and qualified:
  • Kundensicheres Review-Paket bereit / Customer-safe review pack ready
  • Veröffentlicht mit Einschränkungen / Published with limitations
  • Internes Review-Paket verfügbar / Internal review package available
  • Export nicht bereit / Export not ready
• Review-pack proof now exposes evidence basis state, section completeness, sharing boundary, PII visibility, protected-values status, disclosure presence, and operation proof in one bounded panel.
• Download labels are qualified by the same readiness contract instead of implying customer-safe sharing when evidence or section completeness is incomplete.
• The workspace continues to keep diagnostics collapsed and secondary.

Browser proof

• Spec347 screenshots: specs/347-review-pack-output-contract-readiness-semantics/artifacts/screenshots/
• Verified states:
  • customer-safe ready
  • published with limitations
  • internal-only / PII-bearing export

Deferred

• The review-pack detail resource and surrounding environment-review detail copy remain intentionally narrow; Spec 347 only touches the workspace/readiness path and supporting handoff copy where needed for contract consistency.

Spec 349 Follow-up

Spec 349 productizes the raw Spec-347 readiness semantics into bounded operator guidance instead of exposing a warning wall.

• The top decision card now resolves to one dominant output state and one dominant next action:
  • Output not customer-ready
  • Published with limitations
  • Internal review package available
  • Customer-safe review pack ready
• Multiple readiness limitations are grouped behind one compact disclosure instead of competing as peer alerts.
• Technical details stay collapsed by default and remain available as secondary proof.
• Download labels are now readiness-qualified across workspace and customer-workspace detail surfaces:
  • Download customer-safe review pack
  • Download internal review pack
  • Download review pack with limitations
• Environment Review detail now separates:
  • Review status
  • Output readiness
  • Publication/sharing state

Browser proof

• Spec349 screenshots: specs/349-customer-review-workspace-output-resolution-guidance/artifacts/screenshots/
• Verified states:
  • output blocked / publication-blocked guidance
  • internal-only / PII-bearing export
  • customer-safe ready
  • limitations and technical-details disclosures collapsed by default

Repo-truth note

• The user-draft audit-doc target ui-009-review-pack-output-contract.md conflicts with repo truth.
• ui-009 is already reserved for Provider Connections, so Spec 349 keeps the durable audit update on ui-006-customer-review-workspace.md.

Spec 350 Follow-up

Spec 350 keeps the review-output slice bounded but gives the workspace a shared resolution-case handoff:

• the top decision block now reads as issue / reason / impact / one dominant next action instead of a page-local interpretation only
• review-output truth still comes from ReviewPackOutputResolutionGuidance
• findings-follow-up and accepted-risk follow-up remain local workspace overrides and are not flattened into the shared adapter
• the primary action handoff now matches the review-detail contract without changing workspace/environment isolation or customer-safe disclosure rules

Spec 351 Follow-up

Spec 351 turns the workspace decision card into a resolve-action-first handoff only where the repo already owns a safe execution path.

• published blocked output now mounts the source-owned create_next_review Filament action with confirmation instead of exposing a fake link/action split
• Create next review remains the only dominant primary CTA; everything else is demoted into a secondary Supporting actions group
• the right-hand review-pack state card is now split into Package exists, Internal export, and Customer sharing
• acknowledgement copy now states explicitly that acknowledgement records review consumption and does not make the output customer-ready
• the review-consumption flow stays available, but only as a subordinate supporting reference below the main decision and package-index surfaces
• findings and accepted-risk follow-up overrides still sit above the base review-output mapper
• when the actor cannot execute the lifecycle mutation, the dominant CTA degrades honestly to Inspect review blockers
• the workspace still reuses repo-real lifecycle services, capability gates, notifications, and audit semantics rather than inventing a second action runtime

Browser proof

• Spec351 screenshots: specs/351-review-output-resolve-actions-v1/artifacts/screenshots/
• Verified states:
  • 01-published-blocked.png shows the executable Create next review CTA with confirmation, the Supporting actions group, and the split review-pack state semantics
  • 04-fallback.png shows the readonly/non-executable fallback to Inspect review blockers

Spec 356 Follow-up

Spec 356 keeps the workspace read-first and avoids adding a second dominant rendered-report CTA at the hub level.

• the workspace continues to state review-pack readiness and download truth directly
• rendered stakeholder-report launch is deferred to the released-review detail surface so the hub does not duplicate the dominant handoff
• customer-safe wording now states explicitly that the report can be opened from review detail when the current pack supports it

Spec 372 Follow-up

Spec 372 keeps the existing workspace layout but tightens the customer/auditor default evidence path.

• operation proof is no longer part of the default evidence path or review-pack side panel
• the first decision card remains one-primary-action-first with supporting actions below it
• evidence snapshot, review pack, and decision trail remain visible before diagnostics
• diagnostics and technical details stay collapsed

Browser proof

• Spec372 screenshot: specs/372-customer-auditor-surface-safety-pass/artifacts/screenshots/001-customer-review-workspace-after.png
• Browser smoke verified no JavaScript errors, no console logs, and no default Operation proof text in the workspace.

Spec 385 Follow-up

Spec 385 keeps the existing customer workspace layout and routes baseline readiness through the shared review-output guidance.

• baseline readiness blockers now appear as customer-output blockers in the existing decision card and limitation list
• trusted drift remains a finding-bearing ready state rather than a publication blocker
• accepted limitations, foundation-only coverage, and exclusions are shown as qualified limitations instead of verified no-drift proof
• raw provider-resource IDs, canonical subject keys, and baseline internal diagnostics remain out of the customer workspace rendering

Browser proof

• Spec385 screenshot target: specs/385-evidence-review-readiness/artifacts/screenshots/01-baseline-readiness-blocked.png
• Browser smoke target verifies baseline readiness guidance, no JavaScript errors, no console logs, and no raw binding internals in the workspace.