Insurance claim status updated

Source: App\Mail\InsuranceClaimStatusChanged, app/Mail/InsuranceClaimStatusChanged.php:19–36; resources/views/emails/insurance/claim_status_changed.blade.php:1–12, originally mail::message. Native subject: **Your insurance claim status changed!** Suggested preheader: Your insurance claim status changed from {{previous_status}} to {{current_status}}.

Token	Existing source	Handling
{{first_name}}	Explicitly bound user = claim.user; user.first_name ?? ''	Optional complete greeting. Omit only if null/absent/empty string; preserve supplied 0.
{{previous_status}}	Constructor previousStatus	Required original status captured before the update, not inferred from current status.
{{current_status}}	claim.status	Required supplied status, displayed without turning completed into paid/approved.
{{cancellation_reason}}	claim.reason	Render the complete reason section only when claim.status == 'cancelled', matching the source view. Status, not reason truthiness, controls visibility; retain string 0, blank values and line breaks. Never show stale cancellation reasons for processing/completed.
{{app_name}}	config('app.name')	Required sign-off name.
{{preheader}}	Proposed summary from the same previous/current statuses	Escape text. No payout, approval or processing-time assertion.

The source does not render policy ID, claim ID, claim amount, bank data, scopes, uploaded files or a workflow action URL. Do not copy policy information from the order-status template into this email. No email attachment/PDF, completed-policy branch or legacy duplicate action-link field exists. Default logo/optional {{logo_url}}, footer links, actual CID embeddings and approved absolute HTTPS requirements: [shared footer](../shared-footer.md).

Trigger, queue and channels

InsuranceClaimController::changeStatus (:242–308), POST insurance-claims/{id}/change-status (routes/api.php:226), loads claim.user/policy/order. Cancelled/completed cannot be changed. Allowed normal transitions: pending → processing or cancelled; processing → completed or cancelled. Cancelled requires a string reason (:251–260). It captures previousState (:268), updates status, sets reason only when cancelled and creates an activity in a transaction (:270–284). After success it queues this Mailable to claim.user.email with the existing internal BCC (:293–294). Preserve queue(), exact native subject, recipient/BCC and configured From/Reply-To; no explicit sender override or attachment exists.

SMS at :296–303 is separate and has its own text. NewInsuranceActivity records are not email notifications. Customer destroy/cancel (:211–239) updates pending claims and creates an activity, but does **not** invoke this Mailable or send an email; update (:161–204) likewise does not. Do not imply every cancellation/update endpoint currently notifies the customer. Static references are usage evidence, not delivery proof.

The redesigned table presents the existing previous/current statuses separately and retains the original conditional reason. Completed is only the application's supplied state; no settlement, refund, approval, coverage or payout verification is asserted. No new business behavior, queue or provider action is introduced.

Integration and safe optional sections

Keep the existing Mailable and use a complete HTML Blade view plus the proposed plain-text view. Portable {{placeholder_name}} tokens are not automatically Blade expressions; map aliases to constructor/claim/user/config values explicitly. Do not nest the full document in mail::message or add a new framework. Native Blade should escape text/attributes, preserve reason line breaks safely, and remove whole optional greeting/reason sections in both formats. For replacement, apply those conditions first, escape dynamic text, validate image URL scheme/host/path separately and replace in **one pass**. Never trust reason/status/name as raw HTML or recursively evaluate inserted token-like strings. The ready HTML contains both optional blocks as documented integration scaffolding, not runtime logic.

There is no separate source project-owned plain-text alternative; .txt supplies proposed equivalent information. Nine fictional states cover every allowed transition, cancelled reason 0/empty, absent greeting, long cancellation and long generic statuses. Empty reason and arbitrary long statuses are view robustness checks; they do not assert accepted controller requests. Ready: public/ready/insurance-claim-status.html/.txt. Previews: previews/insurance-claim-status-*.html/.txt. Actual email-client/CID rendering and production delivery require separate integration verification.