TenantAtlas/specs/397-receipt-page-reduction/spec.md

Feature Specification: Spec 397 - Receipt Page Reduction Pass v1

Feature Branch: 397-receipt-page-reduction
Created: 2026-06-22
Status: Draft
Input: User-provided "Spec 397 - Receipt Page Reduction Pass v1" candidate, plus repo truth from Specs 376, 377, 393, 395, 396, docs/product/spec-candidates.md, docs/product/roadmap.md, and docs/product/standards/product-surface-contract.md.

Candidate Selection Context

• Selected candidate: Receipt Page Reduction Pass v1.
• Source: User-provided attachment "Spec 397 - Receipt Page Reduction Pass v1"; also explicitly named as a deferred follow-up in specs/395-product-surface-gate/spec.md and specs/395-product-surface-gate/implementation-report.md.
• Why selected: The active auto-prep queue in docs/product/spec-candidates.md is empty, but this request provides an explicit manual productization candidate. The candidate is the first Product Surface Contract runtime-reduction pass after Spec 395 installed the workflow gate. It reduces visible complexity on existing receipt-style pages instead of adding another readiness adapter, semantic layer, or new persisted truth.
• Close alternatives deferred:
  • management-report-pdf-staging-runtime-validation: already represented by Spec 380; not a new prep target.
  • governance-artifact-lifecycle-retention-runtime: manual-promotion only and broader than the current receipt-reduction problem.
  • provider-readiness-onboarding-productization: optional/manual and provider-readiness focused, not a receipt-page reduction pass.
  • cross-domain-indicator-runtime-follow-through: broader guardrail follow-through; this spec is intentionally narrower and page-archetype based.
  • manual-system-panel-browser-fixture-or-audit-procedure: addressed by Spec 396 context and separate from /admin receipt pages.
• Roadmap relationship: Supports the roadmap's UI/Product Maturity Polish and Product Surface Contract runtime-reduction direction without reopening completed roadmap lanes.
• Completed-spec guardrail result: Specs 376, 377, 392, 393, 395, and 396 are context only. Completed close-out, validation, screenshots, browser evidence, and checked task history must not be rewritten. Spec 395 explicitly deferred this runtime reduction as a future candidate, so this package is a new preparation target rather than a rewrite of Spec 395.
• Smallest viable implementation slice: Reduce default visible complexity for existing receipt-style detail surfaces: Evidence Snapshot Detail, Baseline Snapshot Detail, Restore Run Detail, Review Pack receipt sections, and Stored Report receipt surfaces where the page is proving that an artifact was captured/generated/published. Do not redesign dashboards, decision pages, inboxes, wizards, generation flows, or navigation architecture.

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

• Problem: Receipt-style pages currently make operators reconstruct "what happened, can I trust it, and what should I do next?" from raw technical evidence, OperationRun proof, readiness fragments, long tables, source keys, detector details, payload labels, and competing actions.
• Today's failure: Evidence, baseline, restore, review-pack, and report receipt surfaces can appear as dashboards or diagnostics explorers rather than product receipts. This can create false confidence, confuse customer-safe output boundaries, and make the next action harder to identify.
• User-visible improvement: Operators see a compact receipt by default: status, timestamp, scope, outcome, coverage/result summary, and one next action. Internal audit detail remains available deliberately for authorized users.
• Smallest enterprise-capable version: A product-surface reduction pass over existing pages and components only. Move or collapse raw technical detail, cap long default tables, normalize top-level receipt statuses to the existing Product Surface Contract vocabulary, and verify via focused feature/browser coverage.
• Explicit non-goals: No new receipt engine, no new persisted entity, no new status enum family, no new dashboard, no new report generation, no restore behavior changes, no evidence generation changes, no broad technical-annex framework, no Product Surface Contract scanner expansion, no compatibility mode for old receipt layouts.
• Permanent complexity imported: Focused feature/browser tests and possibly small page-local or existing-shared helper usage if needed. No new database table, migration, provider framework, status taxonomy, presenter framework, or cross-domain UI framework is approved by this spec.
• Why now: Spec 395 added the Product Surface Contract gate and explicitly recorded receipt-page reduction as the next runtime-reduction candidate. Spec 377 browser evidence shows overloaded receipt-like pages, especially Evidence Snapshot, Review Pack, and Stored Report surfaces.
• Why not local: Multiple product receipt surfaces share the same failure mode. A purely local one-page fix would leave Product Surface Contract drift unresolved and could preserve competing action/status patterns on adjacent receipts.
• Approval class: Cleanup / Consolidation.
• Red flags triggered: Multiple surfaces. Defense: the scope reduces visible UI complexity across existing receipt pages, adds no new product truth, and forbids broad framework or compatibility layers.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 12/12
• Decision: approve as a bounded Product Surface Contract runtime-reduction slice.

Spec Scope Fields (mandatory)

• Scope: canonical-view over existing tenant-owned artifacts in the /admin panel.
• Primary Routes:
  • Evidence Snapshot detail: existing EvidenceSnapshotResource view route.
  • Baseline Snapshot detail: existing BaselineSnapshotResource view route.
  • Restore Run detail: existing RestoreRunResource view route.
  • Review Pack detail and receipt sections: existing ReviewPackResource view route and related rendered-report/download entry points where receipt metadata appears.
  • Stored Report detail and report receipt surfaces: existing StoredReportResource view route and customer-safe report receipt metadata where applicable.
• Data Ownership: Existing tenant-owned artifact records remain authoritative. No new data owner, table, entity, or persisted receipt state is introduced.
• RBAC: Existing workspace membership, managed-environment entitlement, and resource capabilities remain authoritative. Product receipt summaries stay visible only to already-authorized users. Technical annex/internal details require existing internal/operator capabilities and must never weaken deny-as-not-found boundaries.

For canonical-view specs:

• Default filter behavior when tenant-context is active: Receipt pages remain anchored to the concrete route record and its workspace/environment scope. Hidden remembered environment/session state must not change which receipt record is displayed.
• Explicit entitlement checks preventing cross-tenant leakage: Wrong workspace/environment access remains deny-as-not-found through existing policies/resource scoping. Technical annex or audit-detail access must apply the same record entitlement before exposing raw identifiers or internal links.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production for this product-surface behavior.

• Compatibility posture: canonical replacement.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no.
• Why clean replacement is safe now: There is no production customer-data compatibility requirement. Existing tests that assert overloaded receipt defaults must be updated to the canonical receipt behavior instead of preserving old visible technical sections.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• New table/form/state changed
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact")

Route/page/surface	Current/new archetype	Design depth	Repo-truth level	Existing pattern reused	New pattern required	Screenshot required	Page audit required	Customer-safe review	Dangerous-action review
Evidence Snapshot detail	Receipt Page	Domain Pattern Surface	repo-verified	EvidenceSnapshotResource, existing Evidence Snapshot tests/browser evidence, BadgeCatalog	none expected; use existing Filament sections/infolists	yes, focused browser proof	no full page audit unless default view expands	yes	yes for Expire snapshot if touched
Baseline Snapshot detail	Receipt Page	Domain Pattern Surface	repo-verified	BaselineSnapshotResource, baseline snapshot infolist entries, BadgeCatalog	none expected; use existing table/pagination/collapse patterns	yes	no full page audit unless default view expands	no customer default unless linked output exposes it	yes if destructive actions are touched
Restore Run detail	Receipt Page	Domain Pattern Surface	repo-verified	RestoreRunResource, RestoreRunDetailPresenter, existing restore detail tests/browser smoke	none expected; use existing proof/detail separation	yes	no full page audit unless default view expands	no	yes for delete/restore/rerun/archive actions if touched
Review Pack detail receipt sections	Receipt Page / Report Page boundary	Strategic customer/output surface	repo-verified	ReviewPackResource, output gate/guidance, rendered report controller, existing Spec 347/392 tests	none expected; reuse output guidance patterns	yes	no full page audit unless report page structure changes	yes	yes for regenerate/archive/download state if touched
Stored Report detail / receipt metadata	Receipt Page / Report Page boundary	Domain Pattern Surface	repo-verified	StoredReportResource, report disclosure/profile patterns, current report tests	none expected	yes if rendered receipt metadata changes	no full page audit unless report page structure changes	yes for customer-safe output	yes for delete/download state if touched

Coverage files to update or explicitly not needed during implementation:

• docs/ui-ux-enterprise-audit/route-inventory.md
• docs/ui-ux-enterprise-audit/design-coverage-matrix.md
• docs/ui-ux-enterprise-audit/page-reports/...
• docs/ui-ux-enterprise-audit/strategic-surfaces.md
• docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md
• docs/ui-ux-enterprise-audit/unresolved-pages.md
• N/A - no reachable UI surface impact

Spec-level coverage registry decision:

Coverage artifact	Decision	Reason
docs/ui-ux-enterprise-audit/route-inventory.md	Update during implementation for each target surface whose default rendered UI changes.	Receipt Page classification and Product Surface impact must be discoverable in the durable route registry.
docs/ui-ux-enterprise-audit/design-coverage-matrix.md	Update during implementation for each target surface whose default rendered UI changes.	The design coverage matrix must reflect the Receipt Page reduction and focused browser-proof expectation.
docs/ui-ux-enterprise-audit/page-reports/...	Not required by default.	This is a bounded reduction pass over existing surfaces; add or update page reports only if implementation changes archetype, expands default content, or finds the existing registry entry inaccurate.
docs/ui-ux-enterprise-audit/strategic-surfaces.md	Not required.	No new strategic surface or navigation prominence is introduced.
docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md	Not required.	Follow-up candidates are already recorded in this active spec.
docs/ui-ux-enterprise-audit/unresolved-pages.md	Not required unless implementation cannot classify a touched surface.	All planned target surfaces are classifiable as Receipt Page or Report Page boundary surfaces.

Product Surface Impact (mandatory for UI-affecting specs)

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: yes. This spec materially changes rendered product receipt pages.
• Page archetype: Receipt Page. Review Pack and Stored Report may retain Report Page behavior for the report content itself; only receipt metadata/default detail sections are in scope.
• Primary user question: What happened, when, what scope did it cover, can I trust it, and what is the one next action?
• Primary action: One state-based product action per touched page. Examples: Refresh evidence, Compare to current, Review restore blockers, Open customer workspace, Download customer output, or Open report.
• Surface budget result: planned pass. Any exception must be documented in this spec before runtime UI edits continue.
• Technical Annex / deep-link demotion: OperationRun proof, raw evidence links, raw IDs, source keys, detectors, payloads, renderer metadata, internal artifact paths, fingerprints, and long technical tables must be hidden, collapsed, or moved to authorized internal/audit paths by default.
• Canonical status vocabulary: Use Ready, Needs attention, Blocked, Running, Failed, Expired, Not configured, Unknown, Historical, Superseded, plus allowed severity states where needed. Existing domain labels may remain as lower-level diagnostic text when clearly not top-level product status.
• Visible complexity impact: decreased.
• Product Surface exceptions: none planned.

UI Action Matrix

Surface	Primary action	Secondary actions	Technical/audit actions	Dangerous/high-impact actions	Mutation scope
Evidence Snapshot detail	One state-based action such as Refresh evidence, Open current evidence context, Compare to current, or Review blockers.	Up to two contextual actions such as Open customer workspace or Open related review pack when authorized and relevant.	View audit trail and/or View internal evidence details, secondary and not default-dominant.	Expire snapshot only if the existing action is touched; must remain non-primary, confirmed, authorized, and audited.	Mostly read-only; refresh/expire actions affect TenantPilot evidence state and existing operation/audit paths only.
Baseline Snapshot detail	One state-based action such as Compare to current, View active baseline, Capture new baseline, or Review blockers.	Up to two contextual actions such as Open baseline profile or Open related findings.	View audit trail and/or View baseline internals, secondary and not default-dominant.	Any existing archive/delete/recapture action touched by implementation must remain non-primary, confirmed, authorized, and audited.	Mostly read-only; capture/recapture affects TenantPilot baseline artifact flow through existing operation/audit paths only.
Restore Run detail	One state-based action such as View validation summary, Review restore blockers, Review failure, or View progress.	Up to two contextual actions such as Open backup set or Open restored state when repo-real.	View audit trail and/or View technical run details, secondary and not default-dominant.	Existing delete/restore/rerun/archive actions touched by implementation must remain separated, confirmed, authorized, and audited.	Read-only for receipt viewing; rerun/restore/delete actions retain their existing TenantPilot/Microsoft tenant/simulation scope copy.
Review Pack receipt sections	One state-based action such as Open customer workspace, Download customer output, Review blockers, or Prepare customer output.	Up to two contextual actions such as Open source review or View report when customer-safe and authorized.	View audit trail and/or View internal details, secondary and absent from customer-safe defaults.	Existing regenerate/archive/delete/download-state actions touched by implementation must remain separated, confirmed where high-impact, authorized, and audited when mutating.	Viewing/downloading is read-only; regenerate/archive actions affect TenantPilot review-pack artifact state through existing operation/audit paths only.
Stored Report receipt metadata	Conditional: if T006 confirms a product-facing receipt surface, one state-based action such as Open report, Download customer output, or Review blockers.	Up to two contextual actions such as Open source review pack or Open customer workspace when customer-safe and authorized.	View audit trail and/or View internal report artifact, secondary and absent from customer-safe defaults.	Existing delete/download-state actions touched by implementation must remain separated, authorized, and audited where mutating.	Viewing/downloading is read-only; delete/archive actions affect TenantPilot stored-report artifact state only.

Browser Verification Plan

• Rendered UI changes expected?: yes.
• Required browser proof: focused smoke covering Evidence Snapshot detail, Baseline Snapshot detail, Restore Run detail, and every Review Pack or Stored Report receipt surface changed by implementation. If implementation narrows the slice to Review Pack only or Stored Report only, the implementation report must state why the other surface was not changed and therefore did not need browser proof.
• Proof must record: route opened, fixture/source record, primary receipt question visible, one primary action, technical details not default-visible, no console/runtime/network failure, and screenshot path or textual browser proof.
• No-browser path: not available for implementation because rendered UI changes are the purpose of this spec.

Human Product Sanity Check

Implementation must include a 5 to 15 minute human product sanity review over the focused receipt pages. The reviewer must confirm:

1. Each page immediately reads as a receipt, not a dashboard or diagnostics explorer.
2. Exactly one dominant next action is visible.
3. Technical detail is deliberate, secondary, and authorized.
4. Top-level status labels use the canonical Product Surface vocabulary.
5. Visible complexity decreased or stayed neutral.
6. Customer-safe paths do not expose raw receipt internals.

Shared Pattern Reuse

• Interaction classes: status messaging, detail page header actions, technical/audit links, evidence/report provenance, table caps, destructive action separation.
• Existing shared paths to reuse first: BadgeCatalog / BadgeRenderer, existing resource policies/scopes, UiEnforcement / WorkspaceUiEnforcement, existing Review Pack output guidance/gating, RestoreRunDetailPresenter, Filament infolists/sections/tables, existing browser fixture helpers.
• Allowed deviation: page-local collapsed internal detail may be used if a shared pattern does not already exist. Do not create a broad Technical Annex framework unless at least three concrete existing consumers require it and the proportionality review is updated.

OperationRun UX Impact

• Creates, queues, deduplicates, resumes, blocks, completes, or deep-links to OperationRun?: no new OperationRun behavior.
• Default OperationRun links: must be demoted from product receipt defaults. They may remain available as secondary/internal audit detail for authorized users.
• Notifications: no queued/running/terminal notification changes are in scope.
• Start UX Contract: unchanged. If implementation touches an OperationRun-starting action, it must reuse the existing OperationRun Start UX Contract and update this spec before continuing.

Proportionality / Anti-Bloat Review

• New persisted entity/table?: no.
• New enum/status family?: no. The spec uses the existing Product Surface Contract vocabulary as a display contract.
• New DTO/presenter/envelope?: no broad new layer approved. Small local view helpers may be used only if they reduce duplication without creating a cross-domain framework.
• New interface/registry/resolver?: no.
• New taxonomy/classification system?: no.
• New cross-domain UI framework?: no.
• Current operator problem: overloaded receipts hide the trusted outcome and next action behind technical detail.
• Why existing structure is insufficient: Existing pages already have the data, but the default presentation violates the Product Surface Contract budgets and deep-link demotion rules.
• Narrowest correct implementation: reduce existing pages and tests; do not introduce new receipt truth.
• Ownership cost: focused tests, browser proof, and page-specific cleanup only.
• Alternative intentionally rejected: a reusable receipt engine, persisted receipt state, or broad Product Surface scanner.
• Current-release truth or future prep?: current-release productization cleanup.

Problem Statement

TenantPilot has strong evidence, restore, review, and report artifact truth, but several detail pages surface too much technical implementation detail by default. A page that should prove a captured/generated/restored/published result can instead expose internal object graphs, OperationRun proof, raw evidence links, technical metadata, long tables, and multiple competing actions.

This spec converts the target pages into strict receipt-style product surfaces. A receipt page must answer:

1. What happened?
2. When did it happen?
3. What scope did it cover?
4. Can I trust it?
5. What is the one next action?

Technical depth remains available, but only as deliberate secondary/internal detail for authorized users.

Business / Product Value

• Improves operator trust by separating product outcome from raw technical proof.
• Reduces review and click work on artifact/detail pages.
• Makes customer-safe receipt/report paths less likely to leak internal implementation detail.
• Turns Spec 395's Product Surface Contract into visible runtime product value.
• Reduces UI bloat without adding new persistence or broad abstractions.

Primary Users / Operators

• MSP operator reviewing evidence, baseline, restore, review, or report artifacts.
• Manager validating whether an output can be trusted or shared.
• Read-only/customer-safe reviewer consuming published review/report context.
• Internal support/platform user who may need deliberate audit or technical detail after the receipt outcome is understood.

User Stories & Testing (mandatory)

User Story 1 - Evidence Snapshot reads as a receipt (Priority: P1)

As an operator, I want Evidence Snapshot detail to show what evidence was captured, for which environment, whether it is current/trustworthy, and the one next action, so I do not have to parse source keys, detector output, or technical dimensions first.

Independent Test: Open an Evidence Snapshot detail page with a realistic fixture. The default view shows receipt status, captured timestamp, scope, outcome/coverage summary, and one primary action. It does not show raw source keys, detector output, raw IDs, payloads, or OperationRun proof by default.

Acceptance Scenarios:

1. Given a current usable Evidence Snapshot, When an authorized operator opens the detail page, Then the top-level status maps to Ready or Needs attention, the receipt summary is visible, and one primary action is dominant.
2. Given a historical, superseded, expired, blocked, or failed Evidence Snapshot, When an authorized operator opens the page, Then the status and next action reflect that state without exposing raw technical detail by default.
3. Given an authorized internal operator, When they intentionally open internal details, Then technical evidence remains available without becoming default-visible.

User Story 2 - Baseline Snapshot reads as a receipt (Priority: P1)

As an operator, I want Baseline Snapshot detail to show what baseline was captured, what it covers, whether it is still relevant, and what to do next, so I do not have to scan long governed-subject or payload tables before understanding the outcome.

Independent Test: Open a Baseline Snapshot detail page with more than eight governed subjects or coverage rows. The default view shows receipt status, captured timestamp, scope, baseline profile, coverage/risk summary, and one primary action. Any default table is capped to eight rows or moved behind deliberate expansion/internal detail.

Acceptance Scenarios:

1. Given an active/current Baseline Snapshot, When an operator opens the detail page, Then the page emphasizes receipt outcome and Compare to current or equivalent next action.
2. Given long subject/coverage inventories, When the page renders by default, Then at most eight rows are visible before show-more/pagination/technical detail.
3. Given fidelity, payload, or support-limit details, When the default view renders, Then those details remain diagnostic/internal and do not replace the receipt status.

User Story 3 - Restore, Review Pack, and Stored Report receipts demote internals (Priority: P2)

As an operator or reviewer, I want restore, review-pack, and stored-report receipt sections to show outcome, customer-safe state, output availability, and next action, so OperationRun proof, raw artifacts, and renderer metadata do not compete with product meaning.

Independent Test: Open representative Restore Run, Review Pack, and Stored Report detail pages. Each touched receipt section shows one receipt status and one primary action. OperationRun proof, raw restore/report payloads, internal artifact paths, renderer metadata, and raw evidence links are absent from the default view or clearly secondary/internal.

Acceptance Scenarios:

1. Given a completed Restore Run, When an operator opens the detail page, Then the default page shows restore outcome, source/target, validation/result summary, and a next action without default OperationRun proof.
2. Given a Review Pack that is ready, blocked, expired, or internal-only, When the receipt section renders, Then the customer-safe output state and next action are clear without raw evidence or operation proof links by default.
3. Given a Stored Report or rendered report receipt surface, When the page renders, Then report status, generated timestamp, scope, and output availability are visible, while raw artifact path and renderer metadata are internal-only.

User Story 4 - Customer-safe paths do not leak technical receipt internals (Priority: P2)

As a customer-safe reviewer, I want receipt links from Customer Review Workspace, Review Pack, reports, and dashboards to open clean product receipts, so I can trust the output without seeing raw technical TenantPilot internals.

Independent Test: Use an existing customer-safe review/report fixture or browser path. Customer-facing/default receipt surfaces do not expose raw Evidence Snapshot IDs, OperationRun links, source keys, detector names, fingerprints, payloads, or internal reason ownership.

Acceptance Scenarios:

1. Given a customer-safe or read-only actor, When they follow a receipt/report link, Then the default view is product-language only and internal technical detail is absent or inaccessible.
2. Given an ordinary operator without internal detail capability, When they attempt to access technical annex content directly, Then authorization remains enforced.
3. Given an internal operator with access, When they open the technical path, Then detail is available but labeled as internal/audit detail.

Functional Requirements (mandatory)

• FR-397-001: Each touched page MUST be classified primarily as a Receipt Page unless the implementation proves the surface is report content rather than receipt metadata.
• FR-397-002: Each touched default receipt view MUST show status, timestamp, workspace/environment scope, outcome, compact coverage/result summary, and one primary next action.
• FR-397-003: Each touched default receipt view MUST have exactly one dominant primary action. Technical, audit, related-record, and destructive actions must be secondary, grouped, or separated.
• FR-397-004: Default receipt views MUST NOT show OperationRun proof links, raw evidence snapshot links, raw IDs, source keys, detector output, fingerprints, payloads, renderer metadata, raw artifact paths, or long technical object graphs as primary/default content.
• FR-397-005: Technical/audit depth MUST remain available for authorized internal users through deliberate secondary, collapsed, grouped, or separate internal/audit paths where product requirements require it.
• FR-397-006: Customer-safe and read-only default paths MUST NOT expose raw receipt internals by default and MUST preserve deny-as-not-found or capability denial behavior.
• FR-397-007: Any default-visible table on touched receipt pages MUST be capped to eight rows, paginated, collapsed, or moved behind technical/internal detail.
• FR-397-008: Touched top-level receipt statuses MUST map to the Product Surface Contract vocabulary: Ready, Needs attention, Blocked, Running, Failed, Expired, Not configured, Unknown, Historical, or Superseded.
• FR-397-009: Existing domain diagnostic labels MAY remain only as secondary diagnostic text, not as competing top-level receipt status.
• FR-397-010: Destructive/high-impact actions touched by implementation MUST remain authorization-checked, confirmation-protected, visually separated, and audited where mutating.
• FR-397-011: The implementation MUST avoid new persisted receipt state, new status enums, new taxonomy systems, new provider abstractions, or broad new UI frameworks unless this spec and plan are updated with a proportionality review before code changes continue.
• FR-397-012: Existing global search behavior for touched resources MUST remain safe. If a resource lacks a safe View/Edit page or tenant-safe result handling, global search must remain disabled.
• FR-397-013: Receipt reductions MUST not perform Graph calls or remote work during UI render.
• FR-397-014: Browser proof MUST cover the changed default-visible behavior for the representative receipt pages and must record no console/runtime/network failures on the focused path.

Non-Functional Requirements

• NFR-397-001: The default receipt view should be understandable within five seconds by an operator familiar with TenantPilot concepts.
• NFR-397-002: The reduction must decrease or maintain visible complexity on every touched page; any increase requires an explicit Product Surface exception before implementation continues.
• NFR-397-003: Page rendering must remain DB-only and must not introduce remote calls, expensive per-row service calls, or uncapped table growth.
• NFR-397-004: Browser smoke must remain focused and fixture-bounded. Do not introduce a broad visual regression suite.
• NFR-397-005: Test additions must stay in the smallest honest lane: Unit only for pure mapping helpers, Feature/Filament for page/action visibility, Browser only for focused rendered receipt proof.

UX Requirements

• Receipt pages answer one primary user question and show one dominant next action.
• Technical sections use labels such as View audit trail, View internal details, View internal evidence details, View technical run details, or View baseline internals.
• Default product copy must prefer business meaning, for example Evidence captured for this environment, This baseline is active, This receipt is historical, This output is ready for customer review, or This restore completed with validation warnings.
• Default product copy must avoid implementation-first labels such as OperationRun succeeded, Source family mismatch, Detector output, Fidelity metadata, or Artifact payload captured unless inside internal/technical detail.
• Header/action hierarchy must keep destructive actions separate from product navigation and technical/audit actions.

RBAC / Security Requirements

• Existing workspace and managed-environment entitlement checks remain authoritative.
• UI visibility is not authorization. Any technical annex/internal detail action must enforce policy/capability checks server-side.
• Non-members must continue to receive deny-as-not-found behavior.
• Members without a required capability receive 403 after scope is established.
• Technical paths must not leak raw IDs, payloads, source keys, or OperationRun proof to customer-safe/read-only actors.
• No authorization is weakened to keep an old receipt link working.

Auditability / Observability Requirements

• This spec does not create new operations or notifications.
• Existing audit and OperationRun records remain the source of execution/proof truth.
• Product receipt pages may summarize audit/execution truth, but must not conflate receipt outcome with execution lifecycle when they are different.
• Technical/audit detail must remain reachable for authorized internal users where it is needed for support, verification, or compliance evidence.
• Any touched mutating/destructive action must preserve existing audit logging behavior.

Data / Truth-Source Requirements

• Execution truth remains OperationRun.
• Artifact truth remains existing EvidenceSnapshot, BaselineSnapshot, RestoreRun, ReviewPack, and StoredReport records.
• Backup/snapshot truth remains immutable snapshot/backup records.
• Recovery/evidence truth remains existing evidence/report/baseline artifacts.
• Operator next action is derived from existing record state and capability, not persisted as a new receipt truth.
• No new table, column, migration, or persisted compatibility shim is approved.

Out Of Scope

• New dashboard, inbox, wizard, report center, or decision page behavior.
• New evidence generation, baseline generation, restore execution, review generation, report generation, or PDF rendering behavior.
• New provider integration, Graph endpoint, or remote call.
• New persisted receipt model, status enum, taxonomy, registry, resolver, presenter framework, or Technical Annex framework.
• Broad redesign of Customer Review Workspace, Evidence Overview, Baseline Compare, Operations Hub, or navigation.
• Rewriting completed specs or removing historical validation/browser evidence.
• Preserving old overloaded receipt layouts through compatibility toggles or duplicate UI.

Acceptance Criteria (mandatory)

1. Evidence Snapshot detail behaves as a Receipt Page by default and hides technical dimensions/source keys/detectors/raw IDs/OperationRun proof unless intentionally opened by an authorized internal user.
2. Baseline Snapshot detail behaves as a Receipt Page by default and caps or demotes governed-subject, coverage, payload, fidelity, and technical inventory detail.
3. Restore Run detail behaves as a Receipt Page by default and demotes OperationRun proof/raw restore payload/details behind secondary/internal access.
4. Review Pack receipt sections and Stored Report receipt surfaces show customer-safe output state, provenance summary, generated/published timing, scope, and one next action without raw evidence/internal artifact details by default.
5. Every touched receipt page has exactly one dominant primary action.
6. Technical/audit detail remains available where product-required and authorized.
7. Customer-safe/default paths do not expose raw receipt internals.
8. Touched top-level receipt states use Product Surface Contract vocabulary or explicitly mapped equivalents.
9. Visible complexity decreases or stays neutral on every touched page.
10. Focused feature/Filament tests and focused browser proof pass, or unrelated failures are documented honestly.

Success Criteria (mandatory)

• SC-397-001: Each target page can be reviewed in under five seconds for receipt status, scope, and next action during human product sanity review.
• SC-397-002: Focused tests prove raw technical details are not default-visible on the representative receipt pages.
• SC-397-003: Focused browser smoke proves Evidence Snapshot, Baseline Snapshot, Restore Run, and every Review Pack or Stored Report receipt surface changed by implementation render with no console/runtime/network failure and no default-visible technical internals.
• SC-397-004: Default visible rows on touched receipt tables are capped to eight or moved behind explicit expansion/internal detail.
• SC-397-005: No new persisted receipt truth, compatibility shim, or broad UI framework is added.

Edge Cases

• A receipt may have no related report/review context; the summary must show a compact empty state rather than a raw technical table.
• A receipt may be historical but still valid as audit history; status should be Historical or Superseded, not Ready.
• A receipt may be current but incomplete; status should be Needs attention or Blocked, not Ready.
• A Restore Run may be preview-only; the receipt must not imply execution or recovery success.
• A Review Pack may be internal-only; default customer-safe routes must not present it as shareable output.
• Technical annex content may be absent for some pages; do not add fake sections to preserve symmetry.

Risks

• Operators lose technical detail: Mitigate by preserving authorized internal/audit paths.
• Tests expect old visible technical sections: Mitigate by updating tests to canonical receipt behavior, not compatibility behavior.
• Receipt pages become too sparse: Mitigate by requiring status, timestamp, scope, outcome, coverage/result summary, and next action.
• Technical Annex becomes a dumping ground: Mitigate by keeping it secondary, collapsed or separate, permission-aware, and unnecessary for the default receipt outcome.
• Browser full suite remains red: Mitigate by making focused receipt smoke blocking and documenting unrelated full-suite failures separately.

Assumptions

• 397 is the correct next normal product spec number because 396-system-panel-branding is the latest normal product spec and 999-seeder-external-id is out-of-sequence utility context.
• Existing resource policies and route scoping already provide the baseline entitlement checks; implementation should harden only where the reduction exposes gaps.
• Existing BadgeCatalog and domain status mappings are sufficient for v1 unless implementation proves a page-local mapping is needed.
• The first implementation should reuse existing tests/fixtures and add a named Spec 397 browser smoke only if current coverage cannot prove the contract.

Open Questions

• None blocking preparation.
• Stored Report runtime edits are conditional: implementation must first verify whether Stored Report receipt metadata is product-facing, report-facing, or both on each touched route, and must skip Stored Report runtime edits if the inspected surface is report content rather than receipt metadata.
• Implementation must verify whether any exact coverage registry file update is required by current route-inventory state, and document the decision in the implementation report.

Follow-up Spec Candidates

• Technical Annex standardization only if at least three receipt/detail families prove that local collapse/internal-detail patterns are diverging.
• Report Delivery Center / Stored Reports UX, if management report/report delivery work needs a new page rather than receipt cleanup.
• Cross-domain indicator runtime follow-through, if status/progress vocabulary drift remains after receipt pages are reduced.
• Governance artifact lifecycle retention runtime, if artifact hold/export/delete/read-only behavior needs productized lifecycle controls.