TenantAtlas/specs/263-auditor-pack-executive-export/spec.md

# Feature Specification: Auditor Pack Delivery & Executive Export v1

**Feature Branch**: `263-auditor-pack-executive-export`  
**Created**: 2026-05-02  
**Status**: Ready for implementation  
**Input**: User description: "Promote the top manual backlog item from `docs/product/spec-candidates.md` and `docs/product/roadmap.md` into a new Spec Kit package that turns current review-pack and governance-package truth into one auditor-ready and executive-readable delivery bundle without reopening the existing review, evidence, compliance-mapping, or governance-packaging foundations."

## Inherited Baseline / Explicit Delta

This package is an explicit delta follow-up over already prepared and partly repo-real foundations, especially `specs/109-review-pack-export/spec.md`, `specs/153-evidence-domain-foundation/spec.md`, `specs/155-tenant-review-layer/spec.md`, `specs/258-customer-review-productization/spec.md`, `specs/259-compliance-evidence-mapping/spec.md`, and `specs/260-governance-service-packaging/spec.md`.

Inherited baseline for 263:

- current customer-safe workspace and released-review delivery semantics remain owned by Specs 258-260 and current code
- current operator-side `export_executive_pack` generation path remains owned by the existing review-pack export contract
- current signed review-pack download route remains the only download seam
- current governance-package availability states remain the baseline delivery-state model

New delta introduced by 263 only:

- add one explicit executive-first entrypoint inside the current review-derived pack
- add explicit bundle metadata clarifying which current files form the structured auditor appendix
- make only the minimal workspace/detail wording changes required to describe that new bundle contract

Everything broader stays inherited and out of scope unless it must change solely to explain the new bundle artifact.

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

- **Problem**: TenantPilot already has a review-derived export path (`export_executive_pack`), a ready or partial governance-package surface in the customer review workspace, current signed review-pack downloads, and shared compliance interpretation. What is still missing is one explicitly audience-ordered delivery artifact that an operator can hand to executives or auditors without manually explaining which parts of the current review pack are safe for whom.
- **Today's failure**: Published reviews can already produce or reuse a review-derived pack, but the exported artifact still reads like a product-internal review pack rather than an externally deliverable package. Operators still need ad-hoc guidance outside the product to explain the executive story, the evidence basis, and which files form the auditor appendix.
- **User-visible improvement**: An entitled actor can open one released review context and download one clearly packaged bundle whose default entrypoint is executive-readable while the structured appendix remains available for auditor follow-up inside the same delivery path.
- **Smallest enterprise-capable version**: Keep one released-review-bound `ReviewPack` artifact and the current signed download seam. Extend that existing bundle with one human-readable executive export entrypoint plus explicit delivery metadata that explains the included auditor appendix files. No new package domain, no new panel, no new scheduling, no new customer portal, and no second artifact family ship in v1.
- **Explicit non-goals**: No standalone `AuditorPack` model or table, no new report engine, no PDF renderer requirement, no campaign or recurring delivery workflow, no email delivery automation, no branding or white-label system, no multi-review or multi-tenant package batch, no new review publication workflow, and no raw provider-payload dump as the default human-readable export.
- **Permanent complexity imported**: One bounded delivery-bundle contract over the existing `ReviewPack` artifact, one export-ready summary template or equivalent presentation layer for the executive entrypoint, localized copy updates, and focused feature plus browser coverage. No new persisted workflow state is introduced.
- **Why now**: `docs/product/roadmap.md` and `docs/product/spec-candidates.md` both rank this as the highest-priority manual-promotion gap, and `docs/product/implementation-ledger.md` still marks auditor-ready executive delivery as the clearest remaining blocker between repo-real review truth and a repeatable sellable outcome.
- **Why not local**: A local copy tweak on the customer review workspace or a one-off download rename would not turn the current artifact into a credible external deliverable. A larger portal or reporting engine would overshoot the repo's current need.
- **Approval class**: Core Enterprise
- **Red flags triggered**: New delivery vocabulary and export-bundle expectations over an existing artifact family. Defense: the slice stays fully derived from `TenantReview`, `ReviewPack`, `EvidenceSnapshot`, and shared interpretation truth; it does not add new persistence, new workflow state, or a second export subsystem.
- **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 workspace customer review registry at `/admin/reviews/workspace`
  - existing tenant-scoped released review detail route under `TenantReviewResource`
  - existing signed review-pack download route used by the current governance-package download path
  - existing operator-side published review detail export action on `ViewTenantReview`
- **Data Ownership**:
  - `TenantReview`, `ReviewPack`, `EvidenceSnapshot`, `StoredReport`, `Finding`, `FindingException`, `FindingExceptionDecision`, and `AuditLog` remain the only persisted truth used by this slice
  - the delivered auditor-ready bundle remains one `ReviewPack` artifact tied to one released review; no new `AuditorPack`, `ExecutiveExport`, or delivery-campaign persistence family is introduced
  - v1 should prefer extending bundle contents and current `metadata.json` / `summary` data over adding new database columns; if implementation cannot stay inside existing artifact and JSON surfaces, it must stop and split scope
- **RBAC**:
  - workspace membership remains the first isolation boundary and stays `404` for non-members or out-of-scope tenant or review targets
  - operator-side export initiation on published review detail continues to require the current review-manage capability path used by `export_executive_pack`
  - read-only delivery download continues to reuse current released-review and review-pack visibility rules on the customer-safe detail route and signed download endpoint
  - in-scope capability denials remain `403` only where the current review or review-pack contract already does so; this slice must not invent a new capability family for auditor or executive delivery
  - the slice remains read-only for the customer-safe flow and does not introduce destructive actions

For canonical-view specs, the spec MUST define:

- **Default filter behavior when tenant-context is active**: `CustomerReviewWorkspace` keeps the current tenant-prefilter launch behavior. When launched from a tenant-context surface, the workspace prefilters to that tenant and opens the latest released review as the delivery context.
- **Explicit entitlement checks preventing cross-tenant leakage**: package availability, executive-export readiness, and review-pack access signals remain derived only for entitled tenants and released reviews. Inaccessible targets are omitted from aggregate lists and direct targeting resolves as not found.

## 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)**: download actions, delivery-status messaging, management-summary disclosure, review-pack delivery framing, navigation entry points, and audit-backed export/download flows
- **Systems touched**: `CustomerReviewWorkspace`, `TenantReviewResource`, `ViewTenantReview`, `ReviewPackService`, `ReviewPackDownloadController`, `GenerateReviewPackJob`, `TenantReviewComposer`, `TenantReviewSectionFactory`, `ArtifactTruthPresenter`, localization files, and existing audit infrastructure
- **Existing pattern(s) to extend**: current `export_executive_pack` generation path, current `download_current_review_pack` customer-safe action, current governance-package availability states, current signed download route, and the existing released-review detail summary contract
- **Shared contract / presenter / builder / renderer to reuse**: `ReviewPackService`, `ArtifactTruthPresenter`, `TenantReviewComposer`, `TenantReviewSectionFactory`, `ReviewPackDownloadController`, `WorkspaceAuditLogger`, and the current review-pack action and resource seams
- **Why the existing shared path is sufficient or insufficient**: the existing path is already sufficient for review anchoring, entitlement enforcement, current package readiness states, and signed download handling. It is insufficient only because the bundle itself still lacks an explicit executive entrypoint and explicit explanation of which files form the auditor appendix.
- **Allowed deviation and why**: none. The slice must extend the current review-pack family and current released-review surfaces instead of introducing a second package domain or a new export framework.
- **Consistency impact**: `Governance package`, `Export executive pack`, delivery availability labels, evidence-basis wording, and non-certification disclosure must stay aligned across workspace rows, released review detail, exported bundle metadata, and signed download copy.
- **Review focus**: reviewers must block any second artifact family, any direct raw-report export that bypasses released-review truth, any portal-specific duplication of package status, or any scope growth into recurring delivery automation.

## 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?**: yes
- **Shared OperationRun UX contract/layer reused**: the existing `ReviewPackGenerate` start and completion flow reused by `TenantReviewResource::executeExport()` remains the only run path
- **Delegated start/completion UX behaviors**: queued toast, already-available pack reuse, active-run dedupe messaging, existing terminal `OperationRunCompleted` delivery, and current signed-download follow-up stay on the shared review-pack export path
- **Local surface-owned behavior that remains**: the internal published review detail continues to decide when `export_executive_pack` is visible or primary; the customer-safe released-review detail continues to expose download only when a ready pack already exists
- **Queued DB-notification policy**: unchanged from the current review-pack export contract
- **Terminal notification path**: unchanged; the current `OperationRunCompleted` path remains authoritative
- **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 seam is widened. Provider-specific report names and evidence details remain secondary appendix content and do not become the primary delivery language.

## 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-package primitives | delivery availability, package wording, navigation entry points | page, table, disclosure state | no | Existing row action remains `Open review`; delivery state stays informational on the workspace surface |
| Released review detail in customer-workspace mode | yes | Native Filament detail surface plus shared summary and artifact-truth primitives | delivery summary, package entrypoint, appendix disclosure | detail sections, disclosure state | no | Existing `Download governance package` remains the dominant safe action |
| Published review detail in operator mode | yes | Native Filament detail surface | export initiation, queued/reused package messaging | header actions, detail context | no | Existing `export_executive_pack` initiation path remains the only generation entrypoint |

## 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 | Operator decides which released review is ready for external delivery | released review state, package readiness, evidence-basis presence, and current next step | released review detail and appendix context after explicit open | Primary because it remains the calm workspace selection surface for customer-safe delivery | Keeps delivery anchored to the existing review-consumption workflow | Removes the need to inspect operator-only review-pack pages before the first decision |
| Released review detail in customer-workspace mode | Secondary Context | Operator or entitled reader confirms what the delivered bundle means and downloads it | executive-ready summary, evidence basis, package readiness, and the dominant download action | appendix semantics, deeper proof links, and review lineage after explicit drilldown | Secondary because the review has already been selected on the workspace surface | Keeps delivery centered on one released review | Avoids duplicate summaries across workspace and detail surfaces |
| Published review detail in operator mode | Secondary Context | Operator decides whether to generate or reuse the current export bundle | current review status, export readiness, and queued/reused package outcome | review-pack detail or run detail only after explicit follow-up | Secondary because this is the operator-only generation context, not the customer-safe delivery registry | Preserves the current operator workflow while clarifying the final bundle purpose | Prevents the operator from bouncing between review detail and review-pack resource just to know what will be delivered |

## 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 | operator-MSP, customer-admin, auditor-read-only, customer-read-only | delivery availability, released review state, executive-ready teaser, and evidence-basis presence | none beyond current review state and next-step copy | raw appendix files, provider payloads, fingerprints, and operator-only diagnostics stay off the list surface | `Open review` | raw/support detail stays off the workspace page by default | workspace rows say only whether delivery is ready; detail owns the actual delivery summary |
| Released review detail in customer-workspace mode | operator-MSP, customer-admin, auditor-read-only, customer-read-only | executive summary, evidence basis, top findings, accepted risks, governance decisions requiring awareness, and current delivery readiness | review lineage, interpretation freshness, and artifact availability descriptions in secondary sections only | raw provider payloads, fingerprints, internal reason ownership, and platform reason families stay hidden or gated | `Download governance package` | appendix file structure and operator-only proof links remain secondary | the delivery summary appears once in the governance-package block; later sections add evidence rather than restating the same outcome |
| Published review detail in operator mode | operator-MSP | export readiness, existing package state, and bundle purpose | run details and review-pack detail remain secondary | raw appendix files remain on the pack resource, not the primary review detail block | `Export executive pack` | customer-facing download copy stays off operator-only generation states until a pack is ready | generation context explains bundle purpose once and defers proof to the pack detail or download |

## 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 that is ready for delivery | full-row open via the existing `Open review` link | required | no peer download action on the list surface | none | `/admin/reviews/workspace` | existing tenant review detail route | workspace context, tenant prefilter, released review state, delivery availability | Customer review | whether a released review is delivery-ready | none |
| Released review detail in customer-workspace mode | Detail / Report / Management export | Read-only detail report | Download the current governance package | sectioned detail with one dominant safe header action | forbidden | appendix descriptions and proof links remain secondary in-body | none | `/admin/reviews/workspace` | existing tenant review detail route | workspace, tenant, release state, evidence basis, delivery availability | Governance package | what the exported bundle means and whether it is ready | none |
| Published review detail in operator mode | Detail / Report / Export initiation | Operator export surface | Start or reuse the review-derived export bundle | sectioned detail page with one primary export action | forbidden | review-pack detail or run links remain secondary | none | existing tenant review collection route | existing tenant review detail route | tenant context, review status, export readiness | Executive pack export | whether an export can start or be reused now | 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 | MSP operator or entitled reviewer | Decide which released review is ready for stakeholder delivery | Read-only workspace review overview | Which released review can I safely deliver right now? | released review state, delivery availability, evidence-basis presence, and next step | none beyond secondary review detail | release state, delivery readiness, evidence sufficiency | none | Open review | none |
| Released review detail in customer-workspace mode | MSP operator, customer admin, auditor with read access | Understand the delivery package and download it | Read-only detail report | What will this delivery bundle say, and is it ready? | executive summary, evidence basis, top findings, accepted risks, governance decisions, and delivery status | appendix structure, deeper evidence links, and lineage | delivery readiness, evidence sufficiency, released review status | none | Download governance package | none |
| Published review detail in operator mode | MSP operator | Generate or reuse the review-derived delivery bundle | Detail/export initiation surface | Can I prepare the current delivery bundle now, or is one already available? | review status, export readiness, and package reuse status | run detail and review-pack detail after explicit follow-up | review status, generation readiness, package availability | current `ReviewPackGenerate` run only | Export executive pack | none |

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

- **New source of truth?**: no
- **New persisted entity/table/artifact?**: no new persisted family; the existing `ReviewPack` artifact remains the delivery artifact
- **New abstraction?**: no new cross-domain abstraction by default; any implementation helper must stay local to current review-pack generation and delivery seams
- **New enum/state/reason family?**: no
- **New cross-domain UI framework/taxonomy?**: no
- **Current operator problem**: the repo can already generate a review-derived export and show a customer-safe governance-package summary, but it still cannot hand over one clearly audience-ordered delivery artifact without manual explanation.
- **Existing structure is insufficient because**: the current bundle is machine-oriented and the current UI summary is in-app only. Neither alone gives a stakeholder-ready delivery contract.
- **Narrowest correct implementation**: extend the existing review-derived `ReviewPack` bundle and current signed download path with one human-readable executive entrypoint and explicit delivery metadata instead of creating a second package family.
- **Ownership cost**: maintain one additional exported entrypoint, one bundle metadata contract, a small amount of localized copy, and focused delivery tests.
- **Alternative intentionally rejected**: a standalone `AuditorPack` domain, a PDF/reporting engine, or recurring delivery automation were rejected as broader than current-release truth requires.
- **Release truth**: current-release sellability follow-through, not future-release delivery automation.

### 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 extension of the current `ReviewPack` bundle is preferred over adding a new delivery artifact family.

## 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 prove bundle contents, current export reuse, signed-download continuity, customer-safe disclosure, and entitlement boundaries on the current review and review-pack surfaces. One bounded browser smoke remains justified because the customer-facing detail copy and dominant action are user-visible delivery surfaces.
- **New or expanded test families**: extend existing `apps/platform/tests/Feature/TenantReview/`, `apps/platform/tests/Feature/Reviews/`, and `apps/platform/tests/Feature/ReviewPack/` families plus the existing `apps/platform/tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php`
- **Fixture / helper cost impact**: low to moderate; reuse current released-review, evidence-snapshot, review-pack, and entitlement fixtures. No provider-sync, no new queue family, and no heavy-governance lane are needed.
- **Heavy-family visibility / justification**: none
- **Special surface test profile**: shared-detail-family
- **Standard-native relief or required special coverage**: customer-workspace list behavior keeps standard native coverage; the released-review detail and bundle contract need explicit shared-detail coverage plus the existing browser smoke
- **Reviewer handoff**: reviewers must confirm that the exported bundle stays on the current `ReviewPack` family, the executive entrypoint is human-readable and customer-safe, the appendix stays clearly secondary, the workspace surface keeps `Open review` as the only dominant row action, and no second delivery domain or new run type appears
- **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/TenantReview/TenantReviewExecutivePackTest.php tests/Feature/TenantReview/TenantReviewExportOperationsUxTest.php tests/Feature/TenantReview/TenantReviewExplanationSurfaceTest.php tests/Feature/TenantReview/TenantReviewUiContractTest.php tests/Feature/TenantReview/TenantReviewAuditLogTest.php tests/Feature/Reviews/CustomerReviewWorkspacePageTest.php tests/Feature/Reviews/CustomerReviewWorkspacePackAccessTest.php tests/Feature/Reviews/CustomerReviewWorkspaceAuthorizationTest.php tests/Feature/ReviewPack/TenantReviewDerivedReviewPackTest.php tests/Feature/ReviewPack/ReviewPackDownloadTest.php`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php`

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Deliver One Stakeholder-Ready Bundle From A Released Review (Priority: P1)

As an MSP operator, I want a published review to produce one delivery-ready package that I can hand to an executive or auditor without separately explaining which files matter.

**Why this priority**: This is the commercial core of the slice. Without one externally deliverable bundle, the feature remains an internal review surface only.

**Independent Test**: Trigger `export_executive_pack` for a published review, finish the existing review-pack generation job, download the resulting pack through the current signed download path, and verify that the bundle contains both the current structured appendix files and one human-readable executive entrypoint.

**Acceptance Scenarios**:

1. **Given** a published review with an eligible evidence basis, **When** an entitled operator runs `export_executive_pack`, **Then** the existing `ReviewPackGenerate` flow starts or reuses the current pack and the finished bundle contains one executive entrypoint plus the existing structured appendix files.
2. **Given** a ready current export pack for a released review, **When** an entitled reader opens the customer-safe released-review detail and chooses `Download governance package`, **Then** the same current pack is downloaded through the existing signed route rather than a second artifact family.
3. **Given** the current export pack already exists and is still valid, **When** an operator repeats the export action, **Then** the system reuses the existing pack instead of creating a second delivery artifact.

---

### User Story 2 - Read The Executive Story First And The Auditor Appendix Second (Priority: P1)

As an entitled reviewer, I want the delivered bundle and released-review detail to make the executive summary obvious first while keeping the structured appendix clearly secondary, so the package is usable without exposing internal diagnostics by default.

**Why this priority**: The product already exposes governance-package meaning in-app. The missing value is making that meaning the default entrypoint of the delivered bundle.

**Independent Test**: Open a released review in customer-workspace mode, confirm the default-visible package block is customer-safe and executive-readable, then inspect the downloaded pack to verify the executive entrypoint and appendix roles are explicit.

**Acceptance Scenarios**:

1. **Given** a released review in customer-workspace mode, **When** the detail page renders, **Then** it shows executive-ready summary, evidence basis, delivery readiness, and `Download governance package` without exposing fingerprints, raw payloads, internal reason ownership, or platform reason families by default.
2. **Given** the delivered bundle is opened, **When** the recipient inspects the archive, **Then** the executive entrypoint is obvious and the structured appendix files remain present but secondary.
3. **Given** delivery readiness is `partial`, `unavailable`, `expired`, or `blocked`, **When** the workspace row or detail page renders, **Then** the product explains that state truthfully without pretending a bundle is ready.

---

### User Story 3 - Keep Delivery Tenant-Safe, Auditable, And Bounded (Priority: P2)

As a platform owner, I want the new delivery bundle to stay on the current entitlement, audit, and review-pack seams so the sellability improvement does not create a second uncontrolled export surface.

**Why this priority**: The feature only improves trust if it stays on the current authorization and audit boundaries.

**Independent Test**: Verify non-members receive `404`, in-scope actors use the existing download/export capability paths, and export/download activity remains visible through the existing audit and `OperationRun` seams.

**Acceptance Scenarios**:

1. **Given** a non-member or an out-of-scope tenant or review target, **When** they attempt to open the workspace, released-review detail, or signed download route, **Then** the response remains deny-as-not-found.
2. **Given** an entitled read-only reviewer with access to the released review and current export pack, **When** they download the governance package, **Then** the bundle is accessible without exposing operator-only diagnostics in the default human-readable export.
3. **Given** an entitled operator exports a published review, **When** the bundle is created or reused, **Then** the current audit and `ReviewPackGenerate` observability signals remain intact and no new delivery workflow state is introduced.

### Edge Cases

- What happens when a released review exists but no ready current export pack exists yet? The customer-safe detail stays truthful about unavailability and does not fabricate a download link.
- What happens when the current export pack is expired? The workspace and detail surfaces show `expired`, and the reader must rely on the operator-side generation flow to prepare a new bundle.
- What happens when the released review is customer-safe but some supporting evidence remains partial or stale? The executive entrypoint must say so explicitly, and the bundle stays `partial` rather than falsely `available`.
- What happens when a workspace commercial lifecycle state blocks new export starts but an existing ready pack remains downloadable? The operator-side export action stays blocked while the current allowed download semantics remain intact.

## Requirements *(mandatory)*

**Constitution alignment:** This feature reuses the current `ReviewPackGenerate` `OperationRun` path and existing signed review-pack download route. It must not introduce a second export run type, a second artifact family, or any new write path outside current review-pack generation. UI visibility remains non-authoritative; current `404`/`403` semantics stay enforced server-side.

**Constitution alignment (PROP-001 / PERSIST-001 / BLOAT-001):** This feature must stay on the existing `ReviewPack` persistence family. If implementation requires a new table, new standalone package model, or new delivery workflow state, the scope fails readiness and must split.

**Constitution alignment (XCUT-001):** Delivery status messaging, download actions, and review-pack export reuse must extend the current review, review-pack, and artifact-truth paths rather than introducing a new package presenter stack or a parallel portal UX language.

### Functional Requirements

- **FR-001**: The existing review-derived `ReviewPack` bundle for a published review MUST become the auditor-ready delivery bundle for this slice; no second artifact family may be introduced.
- **FR-002**: Operator-side export initiation for published reviews MUST continue to reuse the current `export_executive_pack` action and current `ReviewPackGenerate` `OperationRun` semantics.
- **FR-003**: Customer-safe read-only download for a released review MUST continue to reuse the current signed review-pack download route reached from `download_current_review_pack`.
- **FR-004**: The delivered bundle MUST preserve the current review-derived ZIP baseline entries `metadata.json`, `summary.json`, and `sections.json`, and MUST add exactly one human-readable executive entrypoint file suitable for executive-first consumption.
- **FR-005**: The delivered bundle metadata MUST explicitly identify the released review context, the current export review pack identity, interpretation version, evidence basis, generation timestamps, and which file is the executive entrypoint versus the preserved appendix entries `metadata.json`, `summary.json`, and `sections.json`.
- **FR-006**: The executive entrypoint MUST be derived from current released-review truth and shared interpretation truth, including executive summary, key findings, accepted risks, governance decisions requiring awareness, evidence basis, and explicit non-certification disclosure.
- **FR-007**: The executive entrypoint MUST NOT expose raw provider payloads, fingerprints, internal reason ownership, platform reason families, or operator-only diagnostics by default.
- **FR-008**: `CustomerReviewWorkspace` and released-review detail MUST keep package availability states truthful (`available`, `partial`, `unavailable`, `expired`, `blocked`) and must not imply delivery readiness when the current pack or evidence basis is not sufficient.
- **FR-009**: The workspace surface MUST keep `Open review` as the only dominant row action. It may not add a peer download action or a second delivery-specific row action.
- **FR-010**: The customer-safe released-review detail MUST keep one dominant safe download action and must present the auditor appendix as secondary explanatory context rather than a competing primary action.
- **FR-011**: Existing export/download audit events and metadata MUST be reused or minimally extended. A new audit family specific to auditor packs is out of scope.
- **FR-012**: This slice MUST NOT add new panel providers, new globally searchable resources, or new asset registration. Existing Filament v5 / Livewire v4 admin surfaces remain the only UI path.

## Scope Boundaries

### In Scope

- one auditor-ready delivery contract over the current review-derived `ReviewPack` bundle
- one human-readable executive entrypoint added to that current bundle while preserving `metadata.json`, `summary.json`, and `sections.json`
- delivery metadata clarifying executive entrypoint versus the preserved appendix roles
- only the truthful package-readiness and delivery wording changes on `CustomerReviewWorkspace` and released-review detail that are required to explain the new bundle contract
- reuse of current operator-side export initiation and current customer-safe signed download path
- focused localization, entitlement, audit, and browser-smoke follow-through for that delivery bundle

### Non-Goals

- a new `AuditorPack` model, table, or standalone delivery registry
- a new report engine, template system, or PDF-generation requirement
- recurring delivery schedules, campaigns, email delivery, or workflow automation
- white-label branding, customer-specific theming, or MSP profile variants
- a portal, new panel, or external identity plane
- multi-review or multi-tenant package batching
- raw provider-payload export as the default executive output
- any new destructive action or approval workflow

## Acceptance Criteria

- A published review can still generate or reuse one current export pack, and that pack now exposes a clear executive entrypoint plus a clearly secondary structured appendix.
- `CustomerReviewWorkspace` remains a calm selection surface with `Open review` as the only dominant row action, while released-review detail remains the package-owning context.
- Customer-safe delivery copy stays derived from existing review and interpretation truth and hides internal operator-only diagnostics by default.
- Existing `ReviewPackGenerate` and signed-download seams remain authoritative; no second artifact family or new run type is introduced.

## Success Criteria

- An operator no longer needs external instructions to explain which file in the current bundle is the executive-first entrypoint.
- An entitled customer-safe reader can download the same current bundle from released-review detail without seeing raw internal diagnostics by default.
- Review-pack delivery becomes closer to auditor-/executive-ready packaging without reopening the already prepared customer-safe workspace/detail delivery semantics from Specs 258-260.

## Assumptions

- The current `ReviewPack` ZIP artifact remains the acceptable v1 delivery container.
- A human-readable executive entrypoint can be produced inside the current export flow without introducing a new rendering subsystem.
- Existing review, review-pack, evidence, and interpretation truth are sufficient for v1 delivery framing; missing or stale basis is handled through truthful readiness states rather than by generating new data.

## Risks

- The slice could drift into a second export domain if implementation treats auditor delivery as a new artifact family instead of extending the current `ReviewPack` bundle.
- Scope pressure could try to add PDF tooling, branding, or recurring delivery automation even though those are explicitly deferred.
- The executive entrypoint could accidentally mirror internal diagnostics unless the delivery copy stays on the existing customer-safe interpretation path.

## Candidate Selection Rationale

- **Selected candidate**: Auditor Pack Delivery & Executive Export v1
- **Source locations**:
  - `docs/product/spec-candidates.md`
  - `docs/product/roadmap.md`
  - `docs/product/implementation-ledger.md`
- **Why selected**: The active queue is intentionally empty, and this is the top-ranked manual-promotion backlog item with no existing spec package. The repo already contains the prerequisite review-pack export, customer review workspace, compliance interpretation, and governance-package delivery foundations.
- **Why close alternatives were deferred**:
  - `Cross-Tenant Promotion Execution v1` already has Spec 043 for compare preview and preflight; the remaining gap is a later portfolio-action slice.
  - `Governance Decision Pack & Approval Workflow v1` depends on the broader decision-operating lane and is ranked behind auditor-ready delivery in current roadmap order.
  - `Customer-Facing Localization Adoption v1`, `Billing & Subscription Truth Layer v1`, `Stored Reports Surface v1`, `Workspace & Tenant Closure Lifecycle v1`, and `First Governed AI Runtime Consumer v1` remain valid manual promotions, but none is ranked above auditor-ready delivery in the current repo-backed backlog.