TenantAtlas/specs/258-customer-review-productization/spec.md

# Feature Specification: Customer Review Workspace Productization v1

**Feature Branch**: `258-customer-review-productization`  
**Created**: 2026-04-30  
**Status**: Draft  
**Input**: User description: "Customer Review Workspace Productization v1 as the smallest follow-up slice that hardens the existing customer review workspace into a calmer customer-safe review consumption surface with clearer findings, accepted-risk, evidence-summary, and auditable pack-access semantics without adding a portal, new persistence, or write paths."

## Spec Candidate Check *(mandatory — SPEC-GATE-001)*

- **Problem**: TenantPilot already has repo-real review, evidence, review-pack, redaction, RBAC, and audit foundations plus an existing customer review workspace, but the current surface still reads more like an operator-led admin handoff than a fully customer-safe governance-of-record consumption path.
- **Today's failure**: Authorized customer reviewers, customer admins, and auditors can reach review truth, but they still have to infer meaning from operator-oriented wording, incomplete accepted-risk/accountability framing, uneven evidence proof semantics, and unclear access or absence states. That keeps the surface harder to sell and less trustworthy than the underlying repo truth.
- **User-visible improvement**: An authorized reader can open one existing workspace review surface and understand what was reviewed, what matters, what risk was accepted, what evidence exists, and what can be safely accessed or downloaded without seeing mutation paths, operator residue, or raw diagnostics.
- **Smallest enterprise-capable version**: Productize the existing customer review workspace and related released-review detail flow inside the current admin plane as a clearer read-only governance-of-record surface with calmer wording, findings and accepted-risk/accountability summaries, evidence proof pointers, explicit unavailable states, and auditable access/download semantics.
- **Explicit non-goals**: No new panel, no new provider registration path, no portal, no new identity plane, no new persistence, no review authoring or publishing engine, no remediation or mutation flow, no new review generation or regeneration flow, no AI summaries, no new global-searchable resource, no heavy new assets, and no destructive actions.
- **Permanent complexity imported**: One bounded productization pass over existing workspace and released-review surfaces, refined disclosure and access-state rules, explicit audit coverage for access/download behavior, focused feature-test expansion, and one bounded browser smoke check. No new models, enums, persisted artifacts, provider seams, or presentation frameworks are introduced.
- **Why now**: This remains the highest-priority active candidate in the roadmap overlay, and the implementation ledger still marks customer review productization as incomplete even though the underlying review foundations are already repo-real.
- **Why not local**: Isolated copy fixes or one-off detail-page tweaks would not establish a coherent customer-safe contract across workspace summary, released review detail, accepted-risk accountability, evidence proof pointers, and access/download semantics.
- **Approval class**: Core Enterprise
- **Red flags triggered**: Multi-surface disclosure contract and customer-facing wording inside an existing admin-plane surface. Defense: the slice stays read-only, derived, in-panel, and reuses current review/evidence/review-pack/RBAC/redaction/audit truth without adding new persistence or authoring behavior.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 11/12**
- **Decision**: approve

## Spec Scope Fields *(mandatory)*

- **Scope**: canonical-view
- **Primary Routes**:
  - existing admin-plane customer review workspace at `/admin/reviews/workspace`
  - existing tenant-scoped released review detail route for the selected review
  - existing review-pack access/download surface reached from released review context
  - existing evidence summary/proof routes reached from released review context when the actor is entitled
- **Data Ownership**: All visible truth remains derived from existing tenant-owned review, finding, accepted-risk, evidence, review-pack, and audit records in the current workspace. No new workspace-owned or tenant-owned persisted artifact, projection table, or publication store is introduced.
- **RBAC**:
  - this remains an admin-plane follow-up, not a new panel or plane
  - workspace membership remains the first isolation boundary
  - page entry requires an established workspace scope plus at least one entitled tenant the actor may read through the existing capability registry
  - proof pointers, evidence summaries, and review-pack downloads remain capability-gated through current review/evidence/pack authorization paths
  - non-members or out-of-scope tenant requests resolve as deny-as-not-found
  - member actors lacking an optional gated capability receive capability denial only for the gated deep link or access path
  - no new customer-only role family or identity model is introduced

For canonical-view specs, the spec MUST define:

- **Default filter behavior when tenant-context is active**: When the workspace is launched from a tenant-scoped review or related review context, it prefilters to that tenant and foregrounds the latest released review for that tenant. Without an incoming tenant context, the page shows only entitled tenants in the current workspace.
- **Explicit entitlement checks preventing cross-tenant leakage**: Aggregated lists, review detail entry, proof pointers, and pack access only resolve for tenants the actor is entitled to in the current workspace. Inaccessible tenant targets are omitted from aggregated lists and resolve as not found when directly targeted.

## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*

- **Cross-cutting feature?**: yes
- **Interaction class(es)**: status messaging, evidence/report viewers, action links, navigation entry points, access-state messaging, and review-pack access/download affordances
- **Systems touched**: existing `CustomerReviewWorkspace`, existing released review detail surfaces, existing review-pack access/download surface, existing evidence summary/proof presentation, existing redaction messaging, existing localization review copy, and existing audit infrastructure
- **Existing pattern(s) to extend**: the current customer review workspace, existing released review detail path, existing artifact-truth presentation, existing redaction notes, and current review-pack access semantics
- **Shared contract / presenter / builder / renderer to reuse**: `ArtifactTruthPresenter`, `ArtifactTruthEnvelope`, `SurfaceCompressionContext`, `ActionSurfaceDeclaration`, existing review/evidence/review-pack disclosure surfaces, and the current audit logging path
- **Why the existing shared path is sufficient or insufficient**: The underlying review, evidence, pack, and audit truth is already present and authoritative. What is insufficient is the current customer-safe product contract over that truth, not the underlying data model or access seams.
- **Allowed deviation and why**: none. This follow-up must tighten the existing shared path rather than introduce a second customer-review vocabulary or mirror presenter.
- **Consistency impact**: Review outcome wording, findings severity and status language, accepted-risk accountability phrasing, evidence proof terminology, pack availability states, redaction notes, and audit action labels must stay aligned across workspace and released-review detail flows.
- **Review focus**: Reviewers must block any new page-local taxonomy, raw-payload viewer, duplicate proof summary, or portal-only terminology that drifts from current review/evidence/review-pack truth.

## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*

- **Touches OperationRun start/completion/link UX?**: no
- **Shared OperationRun UX contract/layer reused**: `N/A`
- **Delegated start/completion UX behaviors**: `N/A`
- **Local surface-owned behavior that remains**: This slice stays read-only and does not add new run start, queue, resume, or completion behavior. Any existing deep provider or run diagnostics remain outside the default customer-safe path.
- **Queued DB-notification policy**: `N/A`
- **Terminal notification path**: `N/A`
- **Exception required?**: none

## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*

N/A - no shared provider/platform boundary touched. The slice consumes existing governance review truth and does not widen provider-specific semantics, identity scope, or shared platform taxonomy.

## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*

| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|---|---|---|---|---|---|---|
| Customer Review Workspace page | yes | Native Filament page plus shared review/evidence primitives | status messaging, evidence/report viewers, access-state messaging, pack access | page, table/filter, disclosure state | no | Existing page is materially productized rather than replaced |
| Released Customer Review detail | yes | Native Filament resource/detail surface plus shared review/evidence primitives | status messaging, proof pointers, pack access, progressive disclosure | detail sections, disclosure state | no | Existing detail flow becomes the secondary customer-safe context surface |

## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*

| Surface | Decision Role | Human-in-the-loop Moment | Immediately Visible for First Decision | On-Demand Detail / Evidence | Why This Is Primary or Why Not | Workflow Alignment | Attention-load Reduction |
|---|---|---|---|---|---|---|---|
| Customer Review Workspace page | Primary Decision Surface | Customer reviewer, customer admin, or auditor decides whether the released review answers the current governance question or needs a follow-up conversation with the workspace operator team | released review state, calm outcome summary, key findings summary, accepted-risk/accountability summary, evidence/proof availability, and pack access state | released review detail, review-pack metadata, and proof pointers only after explicit open | Primary because it is the first truthful customer-safe route and should answer the high-level question without requiring a detail drilldown | Follows review-consumption workflow, not storage-object or operator-workbench navigation | Replaces cross-surface reconstruction with one calm starting point |
| Released Customer Review detail | Secondary Context Surface | Reader inspects the chosen released review to understand why the current governance record looks the way it does and what proof or packaged artifact is available | narrative outcome summary, findings summary, accepted-risk/accountability explanation, evidence summary, proof pointers, and pack availability | redacted proof references, release history, and gated secondary diagnostics only after explicit expansion | Not primary because it is entered from the workspace summary and should deepen understanding rather than replace the decision-first landing surface | Keeps the operator journey centered on one review case after the workspace summary selects it | Preserves a focused second step instead of exposing every proof or diagnostic on the first page |

## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*

| Surface | Audience Modes In Scope | Decision-First Default-Visible Content | Operator Diagnostics | Support / Raw Evidence | One Dominant Next Action | Hidden / Gated By Default | Duplicate-Truth Prevention |
|---|---|---|---|---|---|---|---|
| Customer Review Workspace page | customer-read-only, customer-admin, auditor-read-only, operator-MSP | what was reviewed, current outcome, key findings, accepted risks, evidence/proof availability, pack availability, and clear access/unavailable states | release timing, review lineage, and secondary freshness detail only after opening the review | raw payloads, provider IDs, run internals, and unrestricted diagnostics stay out of the default path | `Open released review` | raw/support detail, deep diagnostics, and unavailable secondary access paths stay hidden until explicitly requested and entitled | Workspace summary states each tenant review truth once; the detail surface elaborates instead of restating the same overview blocks |
| Released Customer Review detail | customer-read-only, customer-admin, auditor-read-only, operator-MSP | calm narrative outcome, findings summary, accepted-risk/accountability context, evidence summary with proof pointers, pack access state, and explicit redaction/access explanations | release history, evidence freshness detail, and secondary metadata only in collapsible or separately gated sections | raw evidence payloads, provider-debug detail, and unrestricted audit internals remain hidden or capability-gated | `Download current review pack` | raw/support detail, broad diagnostics, and any operator-only sections remain excluded from the customer-safe default view | Workspace page provides the overview; detail adds explanation and proof pointers without duplicating full summary cards at equal priority |

## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*

| Surface | Action Surface Class | Surface Type | Likely Next Operator Action | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type / Justification |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Customer Review Workspace page | List / Table / Read-only workspace report | Read-only registry report | Open the released review for the selected tenant | full-row open to released review detail | required | one safe inline pack-access affordance only when already available and entitled | none | `/admin/reviews/workspace` | `/admin/t/{tenant}/reviews/{record}` | workspace context, tenant prefilter, release state, pack availability | Customer review | what was reviewed, the released outcome, key findings, accepted-risk/accountability, proof availability, and access state | none |
| Released Customer Review detail | Detail / Report / Evidence | Read-only detail report | Download the current review pack or inspect proof pointers | sectioned detail page with one dominant safe header action | forbidden | proof pointers live in secondary evidence sections and capability-gated safe surfaces after the pack action | none | `/admin/reviews/workspace` | `/admin/t/{tenant}/reviews/{record}` | workspace, tenant, review release state, evidence summary, pack availability | Customer review | why this is the current governance record and what proof or packaged artifact is available | none |

## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*

| Surface | Primary Persona | Decision / Operator Action Supported | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|---|---|---|---|---|---|---|---|---|---|---|
| Customer Review Workspace page | Customer reviewer, customer admin, or auditor with read access | Decide whether the released review is sufficient for current governance consumption or whether human follow-up is needed | Read-only workspace review overview | What was reviewed for my tenant, what matters now, what was accepted, and what can I safely open or download? | released outcome, key findings, accepted-risk/accountability summary, evidence/proof availability, pack access state, and explicit absence/unavailable messaging | release lineage, deeper evidence freshness, and secondary access metadata only after drilldown | review outcome, findings severity mix, accepted-risk lifecycle, evidence completeness, pack availability, access state | none | Open released review | none |
| Released Customer Review detail | Customer reviewer, customer admin, or auditor with read access | Understand the current governance record and consume proof or packaged artifacts safely | Read-only detail report | Why does the review say this, what evidence supports it, and what packaged artifact is available? | calm narrative summary, findings and recommendations, accepted-risk/accountability context, evidence summary and proof pointers, pack access state | release history, deeper proof metadata, and gated secondary diagnostics | review outcome, evidence freshness/completeness, accepted-risk timing, pack availability, redaction/access state | none | Download current review pack | none |

## Proportionality Review *(mandatory when structural complexity is introduced)*

- **New source of truth?**: no
- **New persisted entity/table/artifact?**: no
- **New abstraction?**: no
- **New enum/state/reason family?**: no
- **New cross-domain UI framework/taxonomy?**: no
- **Current operator problem**: The repo already holds released review truth, but the current surface still makes customer-safe governance consumption harder than it should be by leaving too much operator framing and too little explicit accountability/proof language in the default path.
- **Existing structure is insufficient because**: The current workspace and detail contract does not yet consistently separate customer-readable review summary from secondary diagnostics, nor does it make access, absence, and unavailable states explicit enough for a sellable governance-of-record surface.
- **Narrowest correct implementation**: Tighten the existing workspace and released-review detail surfaces, reusing current review/evidence/review-pack/redaction/RBAC/audit truth and adding no new persistence, panel, or workflow engine.
- **Ownership cost**: A bounded copy and disclosure pass, focused audit assertions, targeted feature-test expansion, and one bounded browser smoke.
- **Alternative intentionally rejected**: A separate portal, customer-specific persistence layer, or new review publication framework was rejected because the repo already has the necessary read-only review truth and access seams.
- **Release truth**: current-release sellability blocker, not future-release preparation

### Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*

- **Test purpose / classification**: Feature, Browser
- **Validation lane(s)**: confidence, browser
- **Why this classification and these lanes are sufficient**: Focused feature tests are the narrowest sufficient proof for entitlement boundaries, progressive disclosure, explicit absence/access states, localization-ready copy expectations, and auditable access/download semantics. One bounded browser smoke remains justified to prove the calm default-visible path and the one-dominant-action flow under real UI rendering.
- **New or expanded test families**: expand the existing `Reviews/CustomerReviewWorkspace` feature family; keep exactly one bounded browser smoke around the same surface
- **Fixture / helper cost impact**: low to moderate. Reuse existing workspace membership, tenant entitlement, released review, findings, accepted-risk/exception, evidence snapshot, review pack, redaction, and audit fixtures instead of adding new provider or queue-heavy defaults.
- **Heavy-family visibility / justification**: exactly one browser smoke stays explicit because this slice is mostly about customer-safe wording, disclosure, and safe action placement. No broader browser family is introduced.
- **Special surface test profile**: shared-detail-family
- **Standard-native relief or required special coverage**: ordinary Filament feature coverage is sufficient for routing, authorization, disclosure, and unavailable states; the existing bounded smoke is the only required browser proof.
- **Reviewer handoff**: Reviewers must confirm that the customer-safe default view never exposes operator-only or mutation actions, that unauthorized tenant targets do not leak presence, that access/download events stay auditable, that review/evidence/pack absence states are explicit, and that no new global search leakage is introduced.
- **Budget / baseline / trend impact**: low feature-local increase only
- **Escalation needed**: none
- **Active feature PR close-out entry**: Smoke Coverage
- **Planned validation commands**:
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Reviews/CustomerReviewWorkspacePageTest.php tests/Feature/Reviews/CustomerReviewWorkspaceAuthorizationTest.php tests/Feature/Reviews/CustomerReviewWorkspaceLaunchLinksTest.php`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Reviews/CustomerReviewWorkspaceNavigationContextTest.php tests/Feature/TenantReview/TenantReviewUiContractTest.php tests/Feature/TenantReview/TenantReviewExplanationSurfaceTest.php tests/Feature/Reviews/CustomerReviewWorkspacePackAccessTest.php tests/Feature/ReviewPack/ReviewPackDownloadTest.php tests/Feature/ReviewPack/ReviewPackResourceTest.php tests/Feature/Evidence/EvidenceSnapshotResourceTest.php tests/Feature/Evidence/EvidenceSnapshotAuditLogTest.php`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php`

## Scope Boundaries

### In Scope

- productize the existing admin-plane customer review workspace into a clearer customer-safe read-only governance-of-record surface
- tighten the released-review detail flow so it remains a customer-safe secondary context surface rather than an operator-heavy detail page
- findings summary in calm customer-safe language, including severity, status, impact, and recommendation
- accepted-risk/accountability summary using existing risk-acceptance truth, including decision reason, accountable person or role when available, timing, and expiry or re-review state
- evidence summary and proof pointers using existing evidence truth without raw payload default visibility
- explicit access, absence, unavailable, expired, and redaction states across workspace, review, evidence, and pack access
- auditable workspace access, review access, evidence-summary/proof access, and review-pack download behavior
- progressive disclosure boundaries that keep the default path calm and customer-readable
- reuse of existing localization, redaction, RBAC, audit, review-pack, and evidence truth

### Non-Goals

- a new panel, portal, standalone customer shell, or separate identity plane
- new persistence, new publication state families, or a customer-specific projection store
- review authoring, review publishing, review generation, pack generation/regeneration, remediation, or other write paths
- risk acceptance editing, finding triage, owner reassignment, or admin mutation flows
- AI-generated review summaries or AI-generated recommendation layers
- raw evidence payload viewers, provider-debug views, or new operator diagnostics in the customer-safe default path
- a new global-searchable review or evidence resource
- broader baseline/control overlays or cross-surface "next sensible step" orchestration beyond the existing released-review contract
- new heavy frontend assets or a standalone asset-loading strategy

## Dependencies

- existing `CustomerReviewWorkspace` route and navigation entry point
- existing released `TenantReview` detail surface and release-truth semantics
- existing `ReviewPack` access and download behavior
- existing `EvidenceSnapshot` summaries and proof context
- existing finding and accepted-risk/exception truth
- existing redaction behavior and safe review-pack disclosure
- existing workspace and tenant RBAC plus entitlement enforcement
- existing audit logging for access and artifact events
- existing DE/EN localization posture for review-facing copy

## Assumptions

- The existing Filament v5 and Livewire v4 admin-plane customer review workspace remains the canonical entry surface for v1; no new panel, portal shell, or provider registration change is required.
- Released review truth already exists and remains authoritative for what is customer-safe to consume.
- Accepted-risk/accountability summaries can be derived from existing risk-acceptance or exception truth without inventing a new customer-facing decision store.
- Review packs remain the primary packaged export/proof artifact, and this slice only clarifies access and wording around them.
- Existing panel assets are sufficient; this slice does not justify heavy new asset registration or on-demand asset infrastructure.
- Existing tenant-safe search behavior remains unchanged; this slice does not depend on introducing a new global search surface.

## Risks

- Some released reviews may not yet carry fully populated accountable-person or accountable-role data, which could force partial accountability summaries until the underlying product truth is present.
- If productization changes only the workspace page and not the released-review detail follow-through, the customer-safe contract could still feel inconsistent after drilldown.
- Over-eager implementation could try to smuggle in publication, regeneration, or remediation behavior because the surrounding review foundations already exist; this spec must block that scope growth.
- Access auditing for read-only views can be under-specified if the implementation focuses only on download events; the slice must treat access and download behavior as separate auditable moments.
- If access, absence, and unavailable states are not differentiated clearly, users may misread missing proof as a system error or hidden operator state rather than a truthful product condition.

## Candidate Selection Rationale

- **Selected candidate**: Customer Review Workspace Productization v1
- **Source locations**:
  - `docs/product/spec-candidates.md` active P0 candidate
  - `docs/product/roadmap.md` priority order item 1
  - `docs/product/implementation-ledger.md` open gap `Customer review productization remains incomplete`
  - `specs/249-customer-review-workspace/spec.md` as the immediate predecessor spec
  - existing repo surface and tests centered on the current customer review workspace
- **Why selected**: This is the highest-priority active unspecced follow-up that converts already repo-real review foundations into a more sellable customer-safe product surface without reopening foundations or requiring new persistence.
- **Why this is the smallest viable implementation slice**: The repo already has the workspace page, review detail, evidence, review-pack, redaction, RBAC, and audit truth. The missing piece is productization of wording, accountability summary, proof framing, and access-state semantics, not a new review engine.
- **Intentional narrowing from source candidate**: This slice deliberately defers broader baseline/control context overlays and richer cross-surface next-step guidance from the roadmap candidate. Those remain follow-up work for `Compliance Evidence Mapping v1` and `Governance-as-a-Service Packaging v1` after the customer-safe review contract is stable.
- **Why close alternatives are deferred**:
  - Governance Decision Surface Convergence already has `specs/257-governance-decision-convergence` and addresses a different operator convergence lane.
  - Remove Findings Lifecycle Backfill Runtime Surfaces already has `specs/253-remove-findings-backfill-runtime-surfaces` and is a cleanup lane, not the current customer-safe sellability blocker.
  - Remove Legacy Acknowledged Finding Status Compatibility already has `specs/254-remove-acknowledged-compat` and is a workflow semantics cleanup lane.
  - Enforce Creation-Time Finding Invariants already has `specs/255-enforce-finding-creation-invariants` and is a data-integrity hardening lane.
  - Cross-Tenant Compare and Promotion v1 already has `specs/043-cross-tenant-compare-and-promotion` and remains a separate refresh track rather than the next unspecced customer-review productization slice.

## Follow-up Candidates

- Governance-as-a-Service Packaging v1 once released reviews, proof pointers, and accepted-risk summaries are stable enough to package as a repeatable management deliverable
- Compliance Evidence Mapping v1 once the customer-safe review surface needs a stronger control/readiness and baseline/control-context overlay than this released-review productization slice intentionally provides
- Cross-Tenant Compare and Promotion v1 as the next MSP multiplier after customer-safe review consumption is calmer
- Broader risk acceptance and accountability reporting follow-through if customer-safe accountability views need portfolio or management-level rollups beyond the review surface

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Understand the latest released review at a glance (Priority: P1)

A customer reviewer, customer admin, or auditor wants one calm workspace route that shows the latest released review for each entitled tenant so they can understand the current governance record without reconstructing it from operator-oriented screens.

**Why this priority**: This is the core sellability gap. If the reader still has to search across internal review, evidence, and pack surfaces to understand the current state, the productization slice fails.

**Independent Test**: Sign in as an entitled read-only actor, open the customer review workspace, and confirm that each visible tenant shows a released review summary with findings, accepted-risk/accountability, evidence/proof, and pack availability in customer-safe wording.

**Acceptance Scenarios**:

1. **Given** an entitled actor has access to one or more tenants with released reviews, **When** they open the customer review workspace, **Then** they see only entitled tenants and only released review summaries in the default path.
2. **Given** a tenant has released findings, accepted risks, and proof-backed evidence, **When** the actor scans the workspace row or card, **Then** they can understand what was reviewed, what matters, and what proof or pack is available without opening a second page first.
3. **Given** the actor has no entitled tenant with a released review, **When** they open the workspace, **Then** they see a truthful absence state rather than leaked draft or hidden internal review states.

---

### User Story 2 - Understand why the review says what it says (Priority: P1)

A customer reviewer, customer admin, or auditor wants the released review detail to explain findings, accepted-risk/accountability, and evidence proof in calmer customer-safe wording so they can trust the review as the governance record without seeing admin or debug residue.

**Why this priority**: Productization is not complete if the workspace summary is calmer but the first drilldown still feels like an operator surface.

**Independent Test**: Open a released review from the workspace and verify that the default detail view shows summary, findings, accepted-risk/accountability, and evidence proof pointers while hiding mutation actions and raw diagnostics.

**Acceptance Scenarios**:

1. **Given** a tenant has a released review with findings and accepted risks, **When** the actor opens the released review detail, **Then** the page explains the outcome, recommendations, accepted-risk accountability, and proof pointers in customer-safe language.
2. **Given** deeper evidence or proof metadata exists, **When** the actor stays on the default detail view, **Then** raw payloads, provider-debug context, and broad diagnostics remain hidden until explicitly requested and entitled.
3. **Given** the actor lacks an optional capability for a secondary proof or pack action, **When** they view the released review detail, **Then** the review still remains readable while the gated access path is explicitly unavailable.

---

### User Story 3 - Safely consume packaged proof and understand unavailable states (Priority: P2)

A customer reviewer, customer admin, or auditor wants to access the current review pack or understand why it is unavailable so they can consume the released artifact without operator assistance or confusion.

**Why this priority**: The review workspace is more trustworthy when access and absence states are explicit instead of silent or operator-only.

**Independent Test**: Open the workspace and released review detail for tenants with and without available packs or proof access, then verify explicit access, unavailable, expired, or redacted states plus auditable access/download behavior.

**Acceptance Scenarios**:

1. **Given** a tenant has a current review pack and the actor is entitled to access it, **When** they choose the pack action, **Then** they can access or download the existing artifact without triggering any generation or mutation flow.
2. **Given** a tenant lacks a current review pack or proof access, **When** the actor views the workspace or released review detail, **Then** the surface shows a truthful unavailable state instead of implying a hidden operator path.
3. **Given** the actor tries to target a tenant outside their scope, **When** they open the workspace with that tenant context or a direct review link, **Then** the system resolves as not found and reveals no review or pack presence.

### Edge Cases

- What happens when a tenant has findings and accepted risks but no released review yet? The customer-safe workspace shows an explicit `No released review available yet` style state rather than leaking internal review lifecycle.
- What happens when a released review exists but accountability data is only partially populated? The summary shows only confirmed accountability truth and does not invent a placeholder owner or decision role.
- What happens when a review pack exists but access is unavailable because of entitlement or redaction posture? The UI shows a clear access or unavailable state and does not offer a generation or recovery action.
- What happens when a user enters through a saved filter or tenant-prefilter for an inaccessible tenant? The filter resolves safely without exposing the tenant or its review artifacts.

## Requirements *(mandatory)*

**Constitution alignment (required):** This feature introduces no Microsoft Graph calls, no write/change behavior, no new queue or scheduled behavior, and no new persistence. It changes customer-safe disclosure, authorization boundaries on read-only surfaces, and audit expectations for access/download behavior.

**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This follow-up must stay derived. It must not introduce new persistence, new presentation frameworks, new customer state families, or speculative abstractions.

**Constitution alignment (XCUT-001):** The feature must extend existing review, evidence, review-pack, localization, redaction, and audit paths rather than invent a page-local customer-review semantic layer.

**Constitution alignment (DECIDE-AUD-001 / OPSURF-001):** The default path must separate customer-readable decision content from deeper diagnostics and keep raw/support detail hidden by default.

**Constitution alignment (TEST-GOV-001):** The implementation must stay with focused feature coverage plus one bounded browser smoke and avoid creating a broader heavy family.

**Constitution alignment (RBAC-UX):** Workspace and tenant membership remain deny-as-not-found boundaries. Optional secondary disclosure remains capability-gated inside an established scope. No new role strings or raw capability strings are introduced by this spec.

**Constitution alignment (UI-FIL-001 / UI-NAMING-001 / DECIDE-001 / ACTSURF-001):** The slice must remain a native Filament read-only reporting flow with one dominant safe inspect action and no destructive or mutation actions.

### Functional Requirements

- **FR-001**: The system MUST keep this slice inside the existing admin-plane customer review workspace and released-review detail flow rather than creating a new panel, portal, or identity surface.
- **FR-002**: The system MUST derive every visible summary, access state, and proof affordance from existing review, evidence, review-pack, accepted-risk, redaction, entitlement, and audit truth without creating new persisted customer-review artifacts.
- **FR-003**: The default workspace path MUST show only entitled tenants and only released or otherwise customer-safe reviews as the governance-of-record path.
- **FR-004**: The default-visible workspace summary MUST answer, in calm customer-safe language, what was reviewed, the current outcome, key findings, accepted risks, available evidence or proof, and pack availability.
- **FR-005**: Findings shown through this slice MUST present severity, status, impact, and recommendation in customer-safe wording and MUST not depend on operator-only vocabulary to be understood.
- **FR-006**: Accepted-risk content shown through this slice MUST summarize decision reason, accountable person or role when product truth exists, decision timing, current expiry or re-review state, and linked proof context without exposing internal workflow residue.
- **FR-007**: Evidence shown through this slice MUST present a narrative summary and proof pointers and MUST not expose raw payloads, provider-debug data, or unrestricted diagnostics by default.
- **FR-008**: The workspace and released-review detail surfaces MUST make access, absence, expired, unavailable, and redaction states explicit and understandable without implying a hidden write path or missing internal admin permission.
- **FR-009**: The feature MUST use progressive disclosure so that default-visible content remains customer-readable while deeper review detail, evidence context, and any gated secondary diagnostics appear only after explicit user intent and capability checks.
- **FR-010**: The primary workspace action MUST be opening the released review, and any secondary safe proof or pack action MUST never compete with write, remediation, generation, or admin actions.
- **FR-011**: Review-pack access and downloads MUST reuse existing entitlement, redaction, and access rules and MUST never trigger generation, regeneration, publication, or any other mutation from this slice.
- **FR-012**: Every explicit workspace access, released-review access, evidence summary or proof access, and review-pack download exposed by this slice MUST remain auditable through the current audit infrastructure.
- **FR-013**: Non-members or out-of-scope workspace or tenant requests MUST resolve as deny-as-not-found, while actors inside an established scope MUST receive explicit capability denial only for gated secondary actions or deep links they are not allowed to use.
- **FR-014**: When launched from tenant-scoped context, the workspace MUST preserve a safe tenant prefilter and context return path without broadening discovery beyond entitled tenants.
- **FR-015**: The slice MUST NOT introduce a new global-searchable resource or broaden existing search discovery in a way that reveals review or evidence artifacts across tenant boundaries.
- **FR-016**: Any new or revised status, severity, availability, or redaction labels in this slice MUST stay aligned with existing centralized semantics rather than page-local mappings.
- **FR-017**: Customer-facing labels and guidance introduced by this slice MUST remain localization-ready for the existing DE/EN product language posture.
- **FR-018**: The slice MUST expose no destructive, remediation, authoring, publishing, generation, or admin-only actions.

## UI Action Matrix *(mandatory when Filament is changed)*

| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|---|---|---|---|---|---|---|---|---|---|---|
| Customer Review Workspace | existing `App\Filament\Pages\Reviews\CustomerReviewWorkspace` | `Clear filters` only | `recordUrl()` or full-row open to the released review | `Open released review`, `Download current review pack` when already available and entitled | none | `Clear filters` only when filters are active; otherwise explanatory no-data text with no create CTA | `N/A` | `N/A` | yes | Action Surface Contract satisfied: exactly one primary inspect model, no redundant view action, no empty action groups, no destructive actions |
| Released Customer Review detail | existing tenant-scoped released review detail surface | none by default | `N/A` | `N/A` | none | `N/A` | `Download current review pack` only; evidence summary remains in secondary in-body proof sections when entitled | `N/A` | yes | Customer-safe launch mode hides publish, refresh, generate, archive, remediation, and other operator-only actions while keeping one dominant safe header action |

Action Surface Contract is satisfied for this slice. Each affected surface keeps one primary inspect/open model, no empty `ActionGroup` or `BulkActionGroup` placeholder, and no destructive-action placement rules are needed because destructive actions are out of scope. `UI-FIL-001` and `UX-001` are satisfied by staying inside native Filament read-only surfaces, using explicit empty states, and keeping status emphasis aligned to shared review semantics rather than page-local visual language.

### Key Entities *(include if feature involves data)*

- **Customer Review Workspace Summary**: A derived workspace-scoped summary for one entitled tenant that combines the current released review, findings overview, accepted-risk/accountability summary, evidence proof availability, and pack access state without becoming a persisted entity.
- **TenantReview**: The existing released review artifact that anchors what was reviewed, the current governance outcome, and the released detail path.
- **Finding**: The existing issue-level governance truth that feeds the customer-safe findings summary and recommendation framing.
- **Accepted Risk Decision**: The existing accepted-risk or exception truth that explains why a risk was accepted, who is accountable when product truth exists, and when the decision should be revisited.
- **EvidenceSnapshot**: The existing supporting proof artifact that informs evidence summaries and proof pointers.
- **ReviewPack**: The existing packaged review artifact that remains the primary downloadable proof bundle.
- **AuditLog**: The existing audit trail used to record explicit access and download behavior without introducing a new audit store.

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-001**: An entitled read-only actor can answer what was reviewed, what matters, what was accepted, what evidence exists, and what artifact is available from the customer review workspace in two interactions or fewer.
- **SC-002**: In 100% of validated customer-safe scenarios, the default-visible workspace and released-review detail path shows no mutation, remediation, publication, or operator-debug actions.
- **SC-003**: In 100% of validated unauthorized workspace or tenant access scenarios, the feature reveals no cross-tenant review, evidence, or pack presence.
- **SC-004**: For tenants with a released review and available pack, entitled users can open the released review or access the pack on their first attempt without operator assistance.
- **SC-005**: For tenants without released review truth, proof access, or a current pack, the surface explains the absence or unavailability explicitly rather than showing a blank state or generic error.