TenantAtlas/specs/385-evidence-review-readiness/plan.md

# Implementation Plan: Spec 385 - Evidence and Review Readiness Integration v1

**Branch**: `385-evidence-review-readiness` | **Date**: 2026-06-17 | **Spec**: [spec.md](./spec.md)
**Input**: Feature specification from `/specs/385-evidence-review-readiness/spec.md`

## Summary

Integrate Spec 383 baseline compare result semantics and Spec 384 provider-resource binding decisions into existing Evidence Snapshot, Environment Review, and Review Pack readiness paths. The implementation should derive one baseline readiness detail from existing OperationRun compare proof and `provider_resource_bindings`, then reuse existing evidence completeness, review readiness, review-pack readiness/guidance, disclosure, and badge/presentation helpers so customer output is honest about blockers and limitations.

The plan explicitly excludes new matching logic, new compare semantics, new resolution UI, new report/PDF runtime work, new workflow/approval engines, new persisted readiness truth, and legacy compatibility readers.

## Technical Context

**Language/Version**: PHP 8.4.15
**Primary Dependencies**: Laravel 12.52.0, Filament 5.2.1, Livewire 4.1.4, Pest 4.3.1, PostgreSQL via Sail/Dokploy
**Storage**: Existing OperationRun compare payloads, `provider_resource_bindings`, `EvidenceSnapshot`/items, `EnvironmentReview`/sections, `ReviewPack`, and `StoredReport`. No new primary table is approved.
**Testing**: Pest unit and feature tests; Filament/Livewire feature tests for changed surfaces; browser smoke for the customer/operator-visible readiness presentation changed by this spec.
**Validation Lanes**: fast-feedback, confidence, browser; PostgreSQL only if a migration/index/constraint is introduced after spec update.
**Target Platform**: Laravel monolith in `apps/platform`, Sail locally, Dokploy for staging/production.
**Project Type**: Laravel/Filament web application inside `apps/platform`.
**Performance Goals**: Readiness derivation uses DB-local OperationRun/evidence/review/pack data; no provider/Graph calls during UI render; keep derived counts bounded by existing compare payload windows.
**Constraints**: no old payload readers, no display-name readiness interpretation, no raw provider detail in customer-safe output, no OperationRun lifecycle transitions outside existing services, no new UI route/panel provider.
**Scale/Scope**: Existing Evidence Snapshot, Environment Review, Customer Review Workspace, and Review Pack surfaces.

## Existing Repository Surfaces Likely Affected

```text
apps/platform/app/Services/Evidence/Sources/BaselineDriftPostureSource.php
apps/platform/app/Services/Evidence/EvidenceCompletenessEvaluator.php
apps/platform/app/Services/Evidence/EvidenceSnapshotService.php
apps/platform/app/Services/EnvironmentReviews/EnvironmentReviewReadinessGate.php
apps/platform/app/Services/EnvironmentReviews/EnvironmentReviewComposer.php
apps/platform/app/Support/ReviewPacks/ReviewPackOutputReadiness.php
apps/platform/app/Support/ReviewPacks/ReviewPackOutputResolutionGuidance.php
apps/platform/app/Support/ReviewPacks/ReportDisclosurePolicy.php
apps/platform/app/Support/ReviewPacks/ReportProfileRegistry.php
apps/platform/app/Support/Badges/BadgeCatalog.php
apps/platform/app/Support/Badges/Domains/EvidenceCompletenessBadge.php
apps/platform/app/Filament/Resources/EvidenceSnapshotResource.php
apps/platform/app/Filament/Resources/EnvironmentReviewResource.php
apps/platform/app/Filament/Resources/ReviewPackResource.php
apps/platform/app/Filament/Pages/Reviews/CustomerReviewWorkspace.php
apps/platform/resources/views/filament/pages/reviews/customer-review-workspace.blade.php
apps/platform/app/Services/ReviewPackService.php
apps/platform/app/Jobs/GenerateEvidenceSnapshotJob.php
apps/platform/app/Jobs/ComposeEnvironmentReviewJob.php
apps/platform/app/Jobs/GenerateReviewPackJob.php
apps/platform/app/Support/Baselines/CompareSemantics/*
apps/platform/app/Support/OperationRunLinks.php
apps/platform/app/Support/ManagedEnvironmentLinks.php
docs/ui-ux-enterprise-audit/page-reports/ui-006-customer-review-workspace.md
docs/ui-ux-enterprise-audit/page-reports/ui-011-reviews.md
docs/ui-ux-enterprise-audit/page-reports/ui-042-review-pack-detail.md
docs/ui-ux-enterprise-audit/page-reports/ui-046-evidence-snapshot-detail.md
```

Likely new or extended support path if implementation keeps the planned shape:

```text
apps/platform/app/Support/Baselines/Readiness/
```

Do not create that namespace if existing helpers can absorb the mapping with less structure. If a new helper is added, keep it baseline-readiness-specific and do not turn it into a cross-domain readiness framework.

## UI / Surface Guardrail Plan

- **Guardrail scope**: existing evidence/review/review-pack/customer-safe readiness presentation changes.
- **Affected routes/pages/actions/states/navigation/panel/provider surfaces**: existing Evidence Snapshot detail/Evidence Overview, Environment Review detail/register, Customer Review Workspace, Review Pack detail/download/rendered output, and readiness/badge/guidance states inside those surfaces.
- **No-impact class, if applicable**: N/A.
- **Native vs custom classification summary**: reuse existing Filament resources, existing Blade composition in Customer Review Workspace, existing badge/disclosure helpers, and existing review-pack output helpers. No new design system.
- **Shared-family relevance**: status messaging, evidence/report viewers, publication blockers, action links, badges, customer-safe disclosure, internal technical details.
- **State layers in scope**: evidence item payload, review summary/blockers, review-pack readiness payload, rendered/customer-safe output, and page-level guidance. No shell/panel/provider state change.
- **Audience modes in scope**: customer-safe review consumer, operator-MSP, and support-platform.
- **Decision/diagnostic/raw hierarchy plan**: customer/operator default shows readiness, reason, limitation/blocker, and one next action; diagnostics and raw proof are secondary/internal.
- **Raw/support gating plan**: raw provider IDs, canonical subject keys, binding internals, internal enum names, DB IDs, and raw OperationRun JSON stay hidden from customer-safe output and diagnostics-only elsewhere.
- **One-primary-action / duplicate-truth control**: each affected surface should show one dominant next action: resolve baseline subjects, refresh evidence, rerun compare, review limitations, or download qualified package.
- **Handling modes by drift class or surface**: changed customer-safe readiness presentation is `review-mandatory`; existing page report updates are required or a checked no-new-route note must be recorded.
- **Repository-signal treatment**: UI-COV-001 applies because existing reachable customer/evidence/review surfaces change readiness presentation.
- **Special surface test profiles**: `shared-detail-family` for readiness/detail output; `standard-native-filament` relief for unchanged Filament layout/action hierarchy.
- **Required tests or manual smoke**: feature tests for mapping and rendered output; browser smoke is required for the changed customer-facing readiness rendering unless implementation updates spec/plan/tasks first to prove no rendered presentation changed.
- **Exception path and spread control**: none planned.
- **Active feature PR close-out entry**: Evidence and Review Readiness Integration.
- **UI/Productization coverage decision**: existing surfaces changed; update relevant page reports or record no-new-route/no-archetype notes.
- **Coverage artifacts to update**: relevant page reports under `docs/ui-ux-enterprise-audit/page-reports/`; `route-inventory.md`/matrix only if implementation changes route inventory or coverage matrix classification.
- **No-impact rationale**: N/A.
- **Navigation / Filament provider-panel handling**: no navigation or panel provider changes planned. Laravel 12 panel providers remain registered through `apps/platform/bootstrap/providers.php`.
- **Screenshot or page-report need**: screenshot/browser smoke for the affected customer-safe readiness state when implementation changes rendered customer output.

## Shared Pattern & System Fit

- **Cross-cutting feature marker**: yes.
- **Systems touched**: baseline compare semantics, provider resource binding decisions, evidence snapshot completeness, environment review readiness, review-pack readiness/guidance, report disclosure policy, customer review workspace, badge/status presentation, OperationRun proof links.
- **Shared abstractions reused**: Spec 383 `CompareSemantics` values, `provider_resource_bindings`, `EvidenceCompletenessEvaluator`, `EnvironmentReviewReadinessGate`, `ReviewPackOutputReadiness`, `ReviewPackOutputResolutionGuidance`, `ReportDisclosurePolicy`, `ReportProfileRegistry`, `BadgeCatalog`, existing OperationRun link helpers.
- **New abstraction introduced? why?**: possibly one bounded baseline readiness mapper if needed to avoid duplicate interpretation across Evidence, Review, and Review Pack. It must derive from existing truth and remain baseline-specific.
- **Why the existing abstraction was sufficient or insufficient**: existing review-pack and review readiness helpers are the right integration points, but they currently do not consume baseline compare readiness impact and operator subject-resolution decisions.
- **Bounded deviation / spread control**: no generic readiness framework, no cross-domain indicator framework, no workflow engine, and no new persisted readiness entity.

## OperationRun UX Impact

- **Touches OperationRun start/completion/link UX?**: yes for source proof and next-action links only.
- **Central contract reused**: existing OperationRun proof/link helpers and existing baseline compare/evidence/review operation UX.
- **Delegated UX behaviors**: any rerun/refresh/open-operation behavior must delegate to existing baseline compare/evidence/review start/link paths.
- **Surface-owned behavior kept local**: readiness explanation, limitation/blocker text, and which existing link is shown as the primary action.
- **Queued DB-notification policy**: no new queued DB notification.
- **Terminal notification path**: unchanged.
- **Exception path**: none.

## Provider Boundary & Portability Fit

- **Shared provider/platform boundary touched?**: yes.
- **Provider-owned seams**: provider key/resource type/resource ID, canonical subject key, source descriptor, raw proof payload.
- **Platform-core seams**: baseline subject readiness, evidence completeness, limitation, exclusion, missing evidence, missing provider resource, publication blocker, customer-ready/internal-only/published-with-limitations semantics.
- **Neutral platform terms / contracts preserved**: provider resource, governed subject, baseline subject, accepted limitation, exclusion, trusted compare, missing evidence, unsupported coverage, readiness, publication blocker.
- **Retained provider-specific semantics and why**: provider identifiers may remain internal proof data needed for support diagnosis; they cannot become customer-safe wording or primary operator labels.
- **Bounded extraction or follow-up path**: document-in-feature for profile/copy choices; follow-up-spec for limitation expiry, broader lifecycle, or external portal work.

## Constitution Check

- Inventory-first: evidence readiness consumes last-observed inventory/compare/evidence truth; Microsoft remains external truth.
- Read/write separation: no write action is added by default. Existing publish/export/download actions keep existing rules.
- Graph contract path: no new Graph calls and no provider calls during render. Any evidence refresh/rerun uses existing jobs/services through `GraphClientInterface`.
- Deterministic capabilities: no new capability family by default.
- RBAC-UX: existing `/admin` workspace/environment rules remain; non-members 404; entitled but missing capability follows existing 403 policy behavior.
- Workspace isolation: all evidence/review/pack/source operation links remain workspace scoped.
- Tenant/environment isolation: all readiness inputs must be scoped to managed environment before display.
- Global search: no new resource is added. Existing global search behavior remains unchanged.
- Destructive-like actions: none added; existing actions keep existing confirmations/authorization/audit.
- Run observability: no new operation type; source proof links use existing OperationRun truth.
- OperationRun start UX: local readiness surfaces must not compose queued toasts/links/events.
- Ops-UX lifecycle: no direct `OperationRun.status` or `OperationRun.outcome` transitions.
- Ops-UX summary counts: no new OperationRun summary count key unless `OperationSummaryKeys::all()` and tests are updated.
- Data minimization: customer output excludes raw provider IDs, canonical keys, binding internals, raw OperationRun JSON, DB IDs, and internal enum names.
- Test governance: Unit, Feature, Filament/Livewire, and limited Browser lanes are planned explicitly.
- Proportionality: any mapper/helper must solve current false-green/false-red output risk and stay bounded.
- No premature abstraction: do not add a generic readiness engine, workflow engine, approval layer, profile framework, or cross-domain indicator framework.
- Persisted truth: readiness remains derived; no new table/artifact by default.
- Behavioral state: derived states must alter guidance, publication readiness, disclosure, or output boundary. Presentation-only labels should map from existing truth.
- UI semantics: use existing badge/disclosure/guidance helpers; do not create page-local semantic color systems.
- Shared pattern first: extend existing evidence/review/pack readiness helpers before adding a new helper.
- Provider boundary: primary readiness language stays provider-neutral.
- V1 explicitness / few layers: use a direct derived mapping and thin adapters.
- UI/Productization coverage: affected existing surfaces need page-report updates or checked no-new-route/no-archetype rationale.

Gate result for preparation: PASS.

## Test Governance Check

- **Test purpose / classification by changed surface**: Unit for baseline readiness mapping; Feature for Evidence/Review/ReviewPack integration; Filament/Livewire Feature for changed rendered surfaces; Browser for the customer-facing readiness smoke required by this presentation change.
- **Affected validation lanes**: fast-feedback, confidence, browser; pgsql only if schema/index behavior is added after spec update.
- **Why this lane mix is the narrowest sufficient proof**: the risk is deterministic readiness mapping and existing surface rendering; browser is needed to prove changed customer-facing output did not regress visually or leak raw details.
- **Narrowest proving command(s)**:
  - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/Baselines tests/Unit/Evidence tests/Unit/Support/ReviewPacks`
  - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Evidence/BaselineDriftPostureSourceTest.php tests/Feature/EnvironmentReview tests/Feature/ReviewPack`
  - `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/Spec347CustomerReviewWorkspaceOutputReadinessTest.php tests/Feature/Filament/Spec349CustomerReviewWorkspaceOutputGuidanceTest.php`
  - `cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec347ReviewPackOutputReadinessSmokeTest.php` or a new focused Spec 385 browser smoke covering changed customer-facing readiness rendering.
  - `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
  - `git diff --check`
- **Fixture / helper / factory / seed / context cost risks**: baseline compare/evidence/review fixtures may be broad. Keep any new setup local to Spec 385 tests and avoid widening shared defaults.
- **Expensive defaults or shared helper growth introduced?**: none planned.
- **Heavy-family additions, promotions, or visibility changes**: none planned.
- **Surface-class relief / special coverage rule**: existing native Filament resources can use standard-native relief unless layout/action hierarchy changes; customer-safe output needs browser smoke for the readiness rendering changed by this spec.
- **Closing validation and reviewer handoff**: verify no false-green/no false-red, no raw provider leakage, no old-payload compatibility, no new workflow/report/PDF scope, and no hidden heavy/browser cost.
- **Budget / baseline / trend follow-up**: none expected; document-in-feature if browser fixture cost grows.
- **Review-stop questions**: readiness duplicate truth, customer leakage, profile/disclosure ambiguity, new state bloat, old payload compatibility, and scope bleed into report/PDF/runtime.
- **Escalation path**: document-in-feature for contained profile/copy choices; follow-up-spec for limitation lifecycle, external portal, or structural readiness framework.
- **Active feature PR close-out entry**: Evidence and Review Readiness Integration.
- **Why no dedicated follow-up spec is needed**: this spec is the dedicated integration over completed Specs 381-384. Follow-up candidates remain listed for larger lifecycle/productization work.

## Project Structure

### Documentation (this feature)

```text
specs/385-evidence-review-readiness/
├── checklists/
│   └── requirements.md
├── plan.md
├── spec.md
└── tasks.md
```

### Source Code (repository root)

```text
apps/platform/app/
├── Services/
│   ├── Evidence/
│   │   ├── EvidenceCompletenessEvaluator.php
│   │   └── Sources/
│   │       └── BaselineDriftPostureSource.php
│   └── EnvironmentReviews/
│       ├── EnvironmentReviewComposer.php
│       └── EnvironmentReviewReadinessGate.php
├── Support/
│   ├── Baselines/
│   │   ├── CompareSemantics/
│   │   └── Readiness/        # only if existing helpers cannot absorb the mapping
│   ├── ReviewPacks/
│   │   ├── ReportDisclosurePolicy.php
│   │   ├── ReportProfileRegistry.php
│   │   ├── ReviewPackOutputReadiness.php
│   │   └── ReviewPackOutputResolutionGuidance.php
│   └── Badges/
├── Filament/
│   ├── Resources/
│   │   ├── EvidenceSnapshotResource.php
│   │   ├── EnvironmentReviewResource.php
│   │   └── ReviewPackResource.php
│   └── Pages/
│       └── Reviews/
│           └── CustomerReviewWorkspace.php
└── Jobs/
    ├── GenerateEvidenceSnapshotJob.php
    ├── ComposeEnvironmentReviewJob.php
    └── GenerateReviewPackJob.php

apps/platform/resources/views/filament/pages/reviews/
└── customer-review-workspace.blade.php

apps/platform/tests/
├── Unit/
├── Feature/
│   ├── Evidence/
│   ├── EnvironmentReview/
│   ├── ReviewPack/
│   └── Filament/
└── Browser/
```

**Structure Decision**: Use existing Laravel/Filament monolith structure. Add only bounded support classes if existing helpers cannot represent baseline readiness consistently.

## Technical Approach

1. Confirm completed dependency guardrails for Specs 381-384 and inspect current compare semantic payload shape.
2. Add focused tests for false-green/false-red evidence readiness cases before changing runtime code.
3. Create or extend a baseline readiness derivation over Spec 383 compare semantics and active `provider_resource_bindings`.
4. Update `BaselineDriftPostureSource` to use the derived readiness detail and populate summary/fingerprint payloads with safe counts and source IDs.
5. Update `EvidenceCompletenessEvaluator` or its callers only if existing `complete/partial/missing/stale` cannot express blockers/limitations without losing detail.
6. Update Environment Review readiness/composition so baseline blockers/limitations become precise publication blockers, limitation states, and next actions.
7. Update Review Pack readiness/guidance/disclosure so customer-ready, published-with-limitations, internal-only, blocked/export-not-ready, stale, and failed states reflect baseline readiness.
8. Update rendered/customer-facing copy to use safe limitation wording and hide raw provider/internal details.
9. Update affected UI coverage page reports or record checked no-new-route/no-archetype notes.
10. Run focused unit/feature/browser validation, Pint, and diff check.

## Domain And Data Model Implications

- `OperationRun` compare payloads remain execution/proof truth.
- `provider_resource_bindings` remains durable decision truth.
- Evidence readiness details should be derived and stored only as part of existing evidence item summary/fingerprint payloads where needed.
- Environment Review blockers should remain derived from sections/evidence/review summary, not a new persisted blocker table.
- Review Pack output readiness remains derived through existing support helpers.
- No new migration, index, queue name, scheduler entry, route, panel provider, or storage path is planned.
- If implementation proves a new persisted field/table/index is required, stop and update spec/plan/tasks before adding it.

## Readiness Mapping Rules

| Input truth | Evidence/Review output behavior |
|---|---|
| Trusted no drift | complete/verified; customer-safe if all other required dimensions pass |
| Trusted drift | complete with findings; customer-visible finding where profile allows; not a blocker by itself |
| Unresolved required identity | action-required blocker; link to Baseline Subject Resolution |
| Missing local evidence | missing evidence or refresh blocker; not provider drift |
| Missing provider resource with trusted identity | governance finding/drift or missing-resource issue; may be customer-ready with finding |
| Unsupported required coverage | blocker unless accepted or profile allows disclosed limitation |
| Inventory-only/foundation-only coverage | limitation; never verified no drift |
| Accepted limitation | published-with-limitations when profile allows; never verified no drift |
| Excluded non-governed subject | excluded from governed claims; not counted as pass |
| Compare failed/coverage unproven | blocked/internal-only with rerun or investigate guidance; use existing output state plus failed reason/limitation code unless a narrow helper extension is justified before implementation |
| Stale source | stale/refresh guidance; use existing output state plus stale reason/limitation code unless a narrow helper extension is justified before implementation |

Default output-state strategy: do not introduce a new public readiness state family for stale/failed by default. Preserve distinct behavior through existing Review Pack output states, `primary_reason`, limitation codes, disclosure output, and next-action guidance unless the existing helpers cannot represent the consequence without ambiguity; if so, stop and update spec/plan/tasks before adding constants.

## UI / Filament Implications

- Filament v5 and Livewire v4.0+ compliance is required; project currently uses Filament 5.2.1 and Livewire 4.1.4.
- Provider registration remains unchanged in `apps/platform/bootstrap/providers.php`; no new panel provider is planned.
- No new globally searchable Filament Resource is planned. Existing resource global search behavior must remain tenant-safe.
- No new destructive/high-impact action is planned. Existing actions keep `->action(...)`, confirmation where applicable, authorization, audit, and tests.
- No new public readiness state family is planned by default. Stale and failed baseline readiness should map through existing output states with explicit reason/limitation codes unless this plan is updated first.
- No new Filament assets or heavy frontend assets are planned. Normal deploy can keep existing `cd apps/platform && php artisan filament:assets` behavior only if assets are registered elsewhere.
- Customer-safe output must avoid raw IDs, internal enum names, canonical keys, binding internals, and raw JSON.

## Implementation Phases

### Phase 1 - Dependency and Payload Discovery

Verify Specs 381-384 are completed, inspect current Spec 383 semantic payload keys, inspect Spec 384 binding decision modes, and confirm current evidence/review/pack readiness helpers.

### Phase 2 - Baseline Readiness Unit Coverage

Add tests for trusted no drift, trusted drift, unresolved identity, missing local evidence, missing provider resource, unsupported coverage, inventory-only coverage, accepted limitation, exclusion, compare failed, stale, and zero-findings-without-trusted-compare.

### Phase 3 - Evidence Integration

Implement the bounded readiness derivation and update `BaselineDriftPostureSource` plus evidence completeness/detail payloads. Keep source IDs safe and deterministic.

### Phase 4 - Environment Review Integration

Feed baseline readiness details into `EnvironmentReviewReadinessGate` and `EnvironmentReviewComposer` so blockers, limitations, and next actions become specific without adding workflow/task entities.

### Phase 5 - Review Pack Output Integration

Update `ReviewPackOutputReadiness`, `ReviewPackOutputResolutionGuidance`, `ReportDisclosurePolicy`, and rendered/customer workspace consumers to use the same baseline readiness details.

### Phase 6 - UI Coverage and Customer Safety

Update affected page reports or no-new-route notes, add customer-safe rendered-output tests, and run browser smoke for the changed customer/operator readiness rendering unless the implementation updates spec/plan/tasks first to prove no rendered presentation changed.

### Phase 7 - Validation and Close-Out

Run targeted tests, customer-facing readiness browser smoke, Pint, diff check, and record implementation close-out with explicit Filament/Livewire/global-search/actions/assets/testing/deploy impact.

## Risk Controls

- Stop if implementation needs a new table, durable readiness entity, new route, panel provider, capability family, provider call, workflow/approval engine, or report/PDF runtime changes.
- Stop if old payload compatibility readers seem required; pre-production posture rejects them unless this spec is updated.
- Keep readiness mapping provider-neutral and derived from Spec 383/384 truth.
- Keep diagnostics secondary and customer output sanitized.
- Add tests before broadening shared helpers.
- Use existing disclosure/profile helpers before local copy/mapping.

## Rollout And Deployment Considerations

- Staging validation is required because customer-safe readiness/output semantics change.
- No environment variables, migrations, queue names, scheduler entries, storage volumes, reverse proxy changes, route changes, panel provider changes, or asset build changes are planned.
- Queue workers should be restarted during normal Laravel deployment so evidence/review/pack jobs use current code.
- `filament:assets` remains the normal Filament deploy step only if registered assets exist; this spec does not plan new assets.
- Existing local/dev evidence snapshots, reviews, and review packs may be regenerated instead of compatibility-mapped.

## Complexity Tracking

| Potential complexity | Why needed | Simpler alternative rejected because |
|---|---|---|
| Bounded baseline readiness mapper/helper | Evidence, Review, and Review Pack need one interpretation of Spec 383/384 truth | Page-local labels would preserve duplicate truth and false-green/false-red risk |
| Derived blocker/limitation detail payload | Review and pack output need actionable guidance and customer-safe limitation summaries | `complete/partial/missing/stale` alone cannot distinguish identity blockers, limitations, findings, and missing evidence |
| Customer-safe disclosure updates | Customer output must explain limitations without leaking proof internals | Internal diagnostics cannot be reused directly for customer-ready output |

## Proportionality Review

- **Current operator problem**: Evidence/review output can misstate baseline posture after compare and resolution truth are known.
- **Existing structure is insufficient because**: downstream surfaces infer readiness separately from findings, evidence state, review sections, export status, and generic limitations.
- **Narrowest correct implementation**: one derived readiness detail consumed by existing evidence/review/pack helpers.
- **Ownership cost created**: mapper/helper tests, cross-surface regression tests, customer-safe copy checks, and UI coverage notes.
- **Alternative intentionally rejected**: update only the Customer Review Workspace label. That would leave Evidence Snapshot, Environment Review, Review Pack detail, and rendered output inconsistent.
- **Release truth**: current-release truth after completed Specs 381-384.

## Filament v5 Implementation Report

- **Livewire v4.0+ compliance**: confirmed. Project uses Livewire 4.1.4 and this spec did not add Livewire v3 references.
- **Provider registration location**: unchanged. Laravel panel providers remain in `apps/platform/bootstrap/providers.php`; no new panel provider was added.
- **Global search**: no new Filament Resource was added, so no new globally searchable resource contract was introduced.
- **Destructive/high-impact actions**: no new destructive or high-impact Filament action was added. Existing publish/export/download/refresh actions keep their existing confirmation, authorization, audit, notification, and test responsibilities.
- **Asset strategy**: no new Filament, Vite, or heavy frontend asset was added. No Spec 385-specific `filament:assets` or asset-build deploy step is required beyond normal deploy behavior.
- **Testing result**: focused Spec 385 unit, feature, Filament/Livewire, and browser coverage passed with 36 tests and 160 assertions. `php vendor/bin/pint --dirty` and `git diff --check` were also run successfully.
- **Deployment impact**: no new environment variables, migrations, persisted states/entities/enums, provider/Graph calls, scheduler entries, queue names, storage volumes, reverse proxy changes, routes, or asset steps. Normal code deploy plus queue worker restart remains sufficient.