## Purpose

The rich preview that stands in for an invitation link wherever that link is shown — in a chat app that unfurls it, in the invitation email that carries it, and in the admin panel before it is sent — covering what the preview says, what picture it shows, and which surfaces may name the guest.

## ADDED Requirements

### Requirement: One preview model per event (P1)

The system SHALL derive an invitation link preview from the event alone: a title, a
description, an image, and a canonical URL. Every surface that renders a preview SHALL
render it from this one model, so that two surfaces cannot describe the same event
differently.

The description SHALL identify the occasion, its date in the wedding's local timezone, and
its venue. Neither the title nor the description SHALL contain a guest name, a phone number,
an email address, or an invitation token.

#### Scenario: Consistent across surfaces

- **WHEN** the same event's link is unfurled by a chat app, rendered in an invitation email, and shown in the admin compose panel
- **THEN** all three show the same title, the same description and the same image

#### Scenario: Venue and date present

- **WHEN** a preview is built for an event held on 12 December 2026 at Dhaka Club
- **THEN** the description names both the date and the venue

#### Scenario: Event details change

- **WHEN** an admin edits the event's venue
- **THEN** previews built after that edit carry the new venue with no separate republishing step

### Requirement: Uploaded preview image (P1)

An event's preview image SHALL be supplied as an uploaded raster image, not derived from the
card design's markup. The system SHALL accept only PNG and JPEG, SHALL refuse any file over
a fixed byte budget, and SHALL refuse an image below a minimum pixel size. The system SHALL
warn — but not refuse — when the image's aspect ratio is not approximately 1.91:1.

Rejections SHALL name the specific reason and the accepted values, so a designer can fix the
export without a second round trip.

#### Scenario: Vector artwork refused

- **WHEN** an admin uploads an SVG as the preview image
- **THEN** the upload is refused with a message naming PNG and JPEG as the accepted formats

#### Scenario: Oversized file refused

- **WHEN** an admin uploads a preview image above the byte budget
- **THEN** the upload is refused with a message giving the file's size and the budget

#### Scenario: Too small refused

- **WHEN** an admin uploads a preview image smaller than the minimum pixel size
- **THEN** the upload is refused with a message giving the image's dimensions and the minimum

#### Scenario: Wrong shape warned

- **WHEN** an admin uploads a square preview image of acceptable size and format
- **THEN** the upload succeeds
- **AND** the admin is warned that the image will be cropped by some chat applications

#### Scenario: Served immutably

- **WHEN** a preview image has been stored
- **THEN** it is served from a stable content-addressed URL
- **AND** replacing it with different bytes produces a different URL

### Requirement: Personalization is per surface (P0)

A preview SHALL be personalized only on surfaces where exactly one guest and the host can
see it. Surfaces rendered by the system for a single known recipient — the invitation email
and the admin panel — MAY name the guest. Surfaces rendered by third parties from published
metadata SHALL NOT, and SHALL be identical for every guest invited to the event.

#### Scenario: Email may name the guest

- **WHEN** an invitation email is composed for a guest
- **THEN** the preview block in that email may address them by name

#### Scenario: Unfurled link may not

- **WHEN** two guests invited to the same event paste their own invitation links into a chat application
- **THEN** both unfurl to byte-identical previews naming neither guest

#### Scenario: Forwarded link discloses nothing personal

- **WHEN** a guest forwards their invitation link into a group conversation
- **THEN** the preview shown to that group names the event and no person other than the couple

### Requirement: Degradation without an image (P1)

An event with no preview image SHALL still produce a preview. Surfaces the system renders
itself SHALL show the title, description and link without a picture rather than a broken or
placeholder image. Surfaces rendered by third parties SHALL omit the image entirely rather
than reference one that does not exist.

#### Scenario: Email without an image

- **WHEN** an invitation email is sent for an event with no preview image
- **THEN** the message shows a text preview block carrying the title, date, venue and link
- **AND** no broken image frame appears

#### Scenario: Meta tags without an image

- **WHEN** a link for an event with no preview image is unfurled
- **THEN** the preview carries a title and description and declares no image

#### Scenario: Event with no published card

- **WHEN** an event has no published card design at all
- **THEN** its links still preview with title, description and canonical URL