# Historical Warranty Snapshot Design

## Goal

Warranty changes made after a sale must never alter the warranty shown on that sale's previous receipt or sale-detail view.

## Design

Each transaction sell line already has an `item_snapshot` JSON field. Extend that snapshot with the complete warranty record selected for the line: `id`, `name`, `business_id`, `description`, `duration`, `duration_type`, `created_at`, and `updated_at`. Also store `expires_at`, calculated once from the transaction's original sale date and the selected warranty duration.

New sale lines capture these values when saved. When an existing sale is edited, the saved warranty snapshot remains unchanged unless the warranty selected on that line is deliberately changed. Removing a warranty records a null warranty snapshot so the old warranty is not displayed accidentally.

Receipt assembly and the sale-detail view prefer the stored warranty snapshot. Lines created before this feature retain a live-record fallback until the backfill migration freezes their current warranty values.

## Existing Data

A new migration backfills warranty data into existing `item_snapshot` values using the current warranty record and each transaction's original date. It does not add another database column. Historical warranty values already changed before this migration cannot be reconstructed.

## Error Handling and Compatibility

Lines without a warranty continue to render normally. Missing or deleted warranty records produce no warranty details. Existing item-snapshot fields remain intact when warranty keys are merged. The original historical customer/product migration remains independently deployable.

## Verification

Tests cover immutable warranty fields, fixed expiry dates, deliberate warranty changes during sale edits, removal of warranties, legacy fallback, migration backfill, receipt snapshot preference, PHP syntax, Blade compilation, JavaScript syntax, and the full application suite.