## ADDED Requirements

### Requirement: Wedding modalities are managed as publishable ordered content
The system SHALL let an admin manage `WeddingPackage` records with name, unique slug, level, summary, ordered scope items, CTA label, sort order and `published_at`. Only published records SHALL appear in public wedding card sections, in ascending `sort_order`.

#### Scenario: Published modalities follow CMS order
- **GIVEN** published and draft wedding modalities with different sort orders
- **WHEN** a visitor loads the home or services page
- **THEN** only published modalities appear in ascending `sort_order`

#### Scenario: Official initial modalities are available
- **WHEN** the content seeder runs
- **THEN** Essenza, Conduzione and Grand Jour are created as the official initial modalities with stable unique slugs

### Requirement: Wedding modality CTA has a contextual channel and conversion fallback
The system SHALL build a WhatsApp deeplink containing the selected modality when `whatsapp_number` is valid. When it is missing or invalid, the CTA SHALL point to `/briefing` with the modality prefilled as `servico_interesse`. The same rule MUST apply on modality cards and on the modality detail page final CTA.

#### Scenario: Valid WhatsApp setting creates contextual link
- **GIVEN** a valid official WhatsApp number
- **WHEN** a visitor activates a wedding modality CTA on a card or detail page
- **THEN** the link targets `wa.me` with a URL-encoded message naming that modality

#### Scenario: Missing WhatsApp setting preserves briefing conversion
- **GIVEN** no valid official WhatsApp number
- **WHEN** a visitor activates a wedding modality CTA on a card or detail page
- **THEN** the visitor reaches `/briefing` with `servico_interesse` prefilled

### Requirement: Wedding modality detail content is CMS-managed
The system SHALL store per-modality detail fields: eyebrow, bipartite title (`title_line`, `title_emphasis`), hero lead, optional hero image with alt, ordered benefits (`icon_key`, label), ordered included items (`icon_key`, title, description), audience heading/intro/points and optional audience image with alt, final CTA heading/body, and optional `meta_title` / `meta_description`. Icon keys MUST come from a closed catalog enforced in admin validation. `summary` and `scope_items` MUST remain available for card surfaces.

#### Scenario: Admin can edit detail sections
- **WHEN** an admin opens a WeddingPackage in Filament
- **THEN** the form MUST expose detail sections for hero, benefits, included items, audience, final CTA and SEO
- **AND** icon fields MUST offer only catalog keys

#### Scenario: Seeder fills detail for official modalities
- **WHEN** the content seeder runs
- **THEN** each official modality MUST have slug and non-empty hero lead plus at least one benefit and one included item suitable for public render

### Requirement: Published modality detail page is publicly reachable by slug
The system SHALL expose `packages.show` at `/pacotes/{slug}` without authentication. Only modalities with non-null `published_at` in the past or present MUST resolve. Draft or unknown slugs MUST return HTTP 404 without exposing internal fields.

#### Scenario: Published modality detail returns 200
- **GIVEN** a published wedding modality with slug `essenza`
- **WHEN** a visitor requests `/pacotes/essenza`
- **THEN** the response status MUST be 200
- **AND** the page MUST render hero title parts, benefits, included items, audience block and final CTA using CMS values

#### Scenario: Draft modality detail returns 404
- **GIVEN** a wedding modality saved as draft
- **WHEN** a visitor requests `/pacotes/{slug}` for that modality
- **THEN** the response status MUST be 404

#### Scenario: Cards link to the detail page
- **GIVEN** a published modality with a slug
- **WHEN** a visitor views the home or services wedding cards
- **THEN** a navigation control MUST link to `/pacotes/{slug}`
- **AND** the primary conversion CTA MUST remain the WhatsApp or briefing channel