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.