feat: recreate public frontend with Heritage Editorial identity (#5)

* feat: recreate public frontend with Heritage Editorial identity

Replace placeholder visual system with EB Garamond/olive tokens, brand assets, editorial home narrative, São Paulo settings, real testimonials, and regenerated visual baselines.

Co-authored-by: Cursor <cursoragent@cursor.com>

* docs: archive recreate-public-frontend and sync Heritage Editorial specs

Merge delta requirements into main OpenSpec capabilities and move the completed change into the dated archive.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
2026-08-01 23:39:00 -03:00
committed by GitHub
parent 637be0664a
commit cf1589c916
75 changed files with 2078 additions and 364 deletions

View File

@@ -5,16 +5,24 @@ TBD - created by archiving change setup-foundation. Update Purpose after archive
## Requirements
### Requirement: Design tokens are centralized for the public site
The system SHALL define minimum design tokens in a single source consumed by the public site layout and components. Tokens MUST cover typography families, font scale, spacing, border radius, container width, background/text/border/accent/state colors, shadows, and transition duration/easing.
The system SHALL define design tokens in a single source consumed by the public site layout and components. Tokens MUST implement the Heritage Editorial system from `DESIGN.md`: typography family EB Garamond (self-hosted), font scale (display/headline/title/body/label), spacing on an 8px rhythm, border radius `0` for interactive and content surfaces, container max width `1120px`, paper/olive/sage/ink color roles, transition duration/easing, and MUST NOT rely on card shadows as a hierarchy mechanism for regular content.
#### Scenario: Public layout uses shared tokens
#### Scenario: Public layout uses shared Heritage Editorial tokens
- **WHEN** a public page is rendered
- **THEN** visual properties MUST be derived from the centralized token definitions rather than arbitrary inline values
- **AND** the primary typeface MUST be EB Garamond (or the declared serif fallback stack)
- **AND** public content surfaces MUST use `0` border radius from tokens
#### Scenario: Palette commits paper and olive regions
- **WHEN** the public site is rendered
- **THEN** background regions MUST use paper ivory / paper deep / olive deep tokens rather than pure white card stacks on a white page
- **AND** primary interactive emphasis MUST use olive heritage (`#556B2F`) / olive deep (`#3E5219`) tokens
### Requirement: Public site respects reduced motion preference
The system SHALL honor `prefers-reduced-motion` by disabling or minimizing non-essential animations and transitions on the public site.
The system SHALL honor `prefers-reduced-motion` by disabling or minimizing non-essential animations and transitions on the public site, including image hover scales and menu transitions.
#### Scenario: User prefers reduced motion
@@ -23,10 +31,25 @@ The system SHALL honor `prefers-reduced-motion` by disabling or minimizing non-e
### Requirement: Public site meets baseline accessibility contrast
The system SHALL use color combinations on the public site that meet WCAG AA contrast requirements for text and interactive elements defined in the token palette.
The system SHALL use Heritage Editorial color combinations that meet WCAG AA contrast requirements for text and interactive elements. Long-form text MUST use ink on paper; sage MUST NOT replace reading color when contrast would fall below AA.
#### Scenario: Primary text is readable
- **WHEN** primary body text is rendered on its background color
- **THEN** the contrast ratio MUST meet WCAG AA minimums
#### Scenario: Olive on paper interactive text is readable
- **WHEN** primary buttons or links use olive tokens on paper backgrounds (or paper text on olive)
- **THEN** the contrast ratio MUST meet WCAG AA minimums
### Requirement: Elevation comes from tonal fields not card shadows
The public site SHALL express hierarchy through tonal paper fields, 1px botanical rules, and editorial overlap. Regular content components MUST NOT use short grey SaaS card shadows.
#### Scenario: Content cards omit drop shadows
- **WHEN** home services, testimonials, or portfolio items are rendered
- **THEN** they MUST NOT depend on `--amare-shadow-*` card elevation for hierarchy
- **AND** separation MUST come from borders, tonal backgrounds, or whitespace