3.9 KiB
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.mewith 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
/briefingwithservico_interesseprefilled
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