Umami in Claude Design

gistfile1.txt

Build a production-quality public frontend called “Umami Next” — a modern, world-class reimagining of Drupal’s Umami demo for the Drupal CMS / Canvas era.

This is NOT a Drupal implementation.
Do NOT build Drupal backend code, admin UI, entity forms, login flows, config screens, or a fake CMS/page-builder interface.
Build only the public-facing frontend/theme prototype and the code architecture that will make a later migration into Drupal CMS straightforward.

This should feel like:
- a premium editorial food publication
- clearly descended from Umami’s food-magazine DNA
- modern enough that it could credibly become a Drupal CMS site template or a future successor to Umami
- structured enough that a Drupal architect would say: “yes, this will migrate cleanly into Canvas + Views + SDC”

Priority order:
1. World-class design quality
2. Drupal-friendly content architecture
3. Reusable component system
4. Clear migration path to Canvas / Views / SDC
5. Minimal, portable frontend complexity

Preserve this Umami DNA:
- food magazine/editorial tone
- recipes as the flagship structured content type
- editorial stories/articles
- taxonomy-driven discovery
- card-based browsing
- rich imagery and useful metadata
- warm, appetizing, approachable feel

But do NOT recreate old Umami 1:1.
Reimagine it at 2026 design quality.

Non-negotiable boundaries:
- No generic startup landing page
- No generic food blog
- No admin/CMS interface
- No fake page builder
- No documentation-heavy output
- Do not spend time generating CONTENT_MODEL.md, COMPONENT_MAP.md, DRUPAL_MIGRATION_NOTES.md, etc.
- Put the intelligence into the codebase itself: folder structure, data models, query helpers, component props, route composition, naming, and clean architecture
- Use original sample copy and placeholder/open imagery inspired by the Umami content universe; do not copy old Umami text verbatim

Design direction:
Create a visually exceptional editorial system with:
- one elegant editorial serif for display/headlines
- one clean, highly readable sans-serif for body/UI
- generous whitespace and strong spacing rhythm
- disciplined grid systems
- photography-led layouts
- warm natural palette inspired by ingredients, herbs, spices, ceramics, and kitchen materials
- compact but elegant metadata
- subtle tactile details, not gimmicks
- restrained motion only where it adds polish

The tone should feel closer to a premium food journal or modern culinary magazine than a tech template.
Typography should feel editorial, not app-like.
Layouts should feel art-directed, but still systematic and reusable.

Avoid:
- glassmorphism
- neon gradients
- dark SaaS/dashboard aesthetics
- “AI template” vibes
- giant rounded blob compositions
- excessive motion
- messy utility-class soup in page templates
- overdecorated cards
- food imagery that looks fake or overly stylized

Very important:
The site should make Drupal look impressive by showing off what Drupal is actually good at:
- structured recipes
- rich metadata
- taxonomy browsing
- reusable cards/teasers
- related content
- views-style listings
- editorial landing pages
- shared global content areas
- content that obviously wants to be queryable, filterable, reusable, and translatable

Build it as if it will later map to:
- Canvas pages for unique one-offs like homepage and 404
- node content templates for Recipe, Article, Collection, and Basic Page
- Views pages/blocks for archives, related content, filters, and search
- global config/content for nav, footer, newsletter CTA, promos, and social links

Use a code architecture that makes that migration path obvious.

Required public routes:
1. Homepage
2. Recipes archive
3. Recipe detail
4. Stories / Articles archive
5. Article detail
6. Topic or Tag archive
7. Collection / Seasonal Guide page
8. Basic page (About)
9. Contact / Newsletter page
10. Search results page
11. 404 page

Homepage must include:
- a large editorial hero
- featured recipes section
- latest or featured stories section
- a browse-by-topic / taxonomy section
- a seasonal collection or guide spotlight
- at least one mixed-layout editorial section (for example media + text, split feature, or curated picks)
- newsletter/signup CTA
- strong footer

Content direction:
Use the same editorial universe as Umami:
- recipes
- cooking stories
- seasonal produce
- ingredient-led features
- weeknight cooking
- special-occasion dishes
- global cuisines
- dietary-friendly options
- cooking techniques and food culture

The content should feel like one coherent publication, not random lorem ipsum.

Build output requirements:
- Build the site pages and components, not docs
- Create realistic structured mock data files
- Create a reusable query layer that mimics future Drupal Views/Search behavior
- Create a design-token system using CSS variables or similarly portable tokens
- Use semantic HTML and accessible interactions
- Keep JavaScript light and progressive-enhancement-friendly
- Keep the public site mostly driven by data + pure components, not client-only app logic

Codebase structure:
Use a clean structure similar to this, adapted to the framework you choose:

src/
  content/
    recipes.*
    articles.*
    collections.*
    authors.*
    taxonomies.*
    site.*
  queries/
    getRecipes.*
    getArticles.*
    getCollections.*
    getRelatedContent.*
    searchContent.*
  components/
    [single-directory component folders]
  routes/ or app/
    homepage
    recipes archive
    recipe detail
    stories archive
    article detail
    topic archive
    collection
    about
    contact
    search
    404
  styles/
    tokens.*
    globals.*

Single-directory component rule:
Each reusable component should live in its own folder with:
- component file
- prop/types file
- local styles file if needed
- optional helper file if needed

Make the component architecture feel close to future Drupal SDC thinking.

Data placement rules:
These are mandatory:
- All canonical content lives in src/content or equivalent data-only modules
- All archive/detail/search pages consume data through query helpers in src/queries
- Page files should compose sections/components and call query helpers
- Do not hardcode content arrays directly inside page templates
- Do not embed layout HTML inside long rich-text blobs
- If a value should be filterable, searchable, reusable, or shown in more than one place, it must exist as structured data
- Keep content separate from presentation

Minimum content volume:
Create enough realistic data for the site to feel editorially alive:
- 18+ recipes
- 8+ articles/stories
- 4+ collections/seasonal guides
- 4+ authors
- multiple recipe categories
- multiple topics/tags
- dietary filters
- cuisine filters
- a meaningful set of global nav/footer items

Content model to encode in the data layer:

Recipe
- id
- slug
- title
- summary/deck
- hero image
- optional gallery
- author reference
- published date
- recipe category (single)
- topics/tags (multi)
- dietary tags (multi, optional)
- cuisine (single, optional)
- difficulty
- prep minutes
- cook minutes
- total minutes
- servings
- ingredients as structured repeatable items, not one blob
- method/instructions as structured repeatable steps, not one blob
- optional notes/callout
- optional related content references
- optional media credit

Article
- id
- slug
- title
- summary/deck
- featured image
- author reference
- published date
- topics/tags (multi)
- body rich text
- optional pull quote
- optional related recipe/content references
- optional read time
- optional media credit

Collection
- id
- slug
- title
- summary
- hero image
- intro/body
- featured content references
- secondary content references or listing criteria
- topics/tags
- CTA link object(s)

Basic Page
- id
- slug
- title
- intro
- body
- optional hero image
- optional sidebar CTA

Taxonomy / controlled vocabularies
- recipe categories
- topics/tags
- dietary preferences
- cuisines

Global content/config
- main navigation
- footer navigation groups
- social links
- newsletter CTA content
- promo/announcement content

Data modeling rules:
- Use link objects with label + href
- Use image objects with src + alt + width + height and optional caption/credit
- Use enums or controlled values where appropriate
- Keep field names and object shapes stable and obvious
- Add short comments only where useful to indicate likely Drupal mapping
- Favor canonical content fields over presentation-only overrides

Query layer requirements:
Create query helpers that mimic future Drupal Views / Search API patterns, such as:
- getRecipes({ category, topic, dietary, cuisine, difficulty, search, sort, page, pageSize })
- getArticles({ topic, author, search, sort, page, pageSize })
- getCollection(slug)
- getRelatedContent({ type, id, limit })
- searchContent({ q, type, topic, page, pageSize })

These should power:
- recipe archive with exposed-filter-style UI
- article archive
- topic/tag archive
- related recipes/articles sections
- search results
- empty states
- paginated states

Component system:
Build a thoughtful, medium-sized component library.
Not dozens of one-offs.
Not one giant generic renderer.

Generic reusable components:
- site header
- navigation / mobile menu
- footer
- breadcrumbs
- hero
- section heading
- content grid
- recipe card
- article card
- collection card
- taxonomy pills / chips
- metadata row
- promo / CTA block
- rich text block
- media + text split
- pull quote
- filter bar
- pagination
- newsletter signup block
- search results list
- empty state
- form state messages
- 404 state

Content-template components:
- recipe header
- recipe meta panel
- ingredients list
- instruction steps
- recipe notes/callout
- article header
- article body layout
- related content rail
- collection hero
- curated collection sections

Card/view-mode variants:
At minimum support variants that feel like future Drupal view modes:
- featured
- standard teaser
- compact
- related

Component rules:
- Every component must have a clear prop contract
- Props should use portable primitives and structured objects that would translate cleanly into SDC / Canvas props later
- Support optional data gracefully
- Prefer composition over giant prop lists
- Keep components semantic and Twig-portable
- Do not make components depend on page path, page title, or hidden global state
- Do not create a separate bespoke card for every section if one variant can solve it

Required page behavior:
- Breadcrumbs on inner pages where appropriate
- Archive filtering UI that looks and behaves like future exposed filters
- Mobile-friendly filter behavior
- Search results that can mix content types cleanly
- Related content based on shared taxonomy and/or author through query helpers, not manually repeated hardcoded lists
- Contact/newsletter page with default, validation error, and success states
- 404 page that is on-brand and useful, with links back into content discovery

Framework / rendering rules:
- Use the framework Lovable is best at, but keep the rendering architecture portable
- Avoid heavy client-only state for core page rendering
- Do not fetch canonical content in useEffect for basic page output
- Do not rely on React context or app-wide stores for core content
- Keep page templates mostly pure and data-driven
- Avoid CSS-in-JS
- Prefer CSS modules, plain CSS, or similarly portable styling
- If using Tailwind, keep it disciplined and readable

Very important: make the Drupal migration path visible in the code
Do this with implementation, not extra docs:
- At the top of each route/template file, add a short comment such as:
  - Drupal target: Canvas page
  - Drupal target: node content template (Recipe)
  - Drupal target: Views page with exposed filters
- Keep section boundaries stable so major homepage/archive sections could later become Canvas components or Views blocks
- Keep detail-page structures stable so they could later become node content templates
- Keep listing logic isolated so it could later become Views

Disqualifying patterns:
Do NOT do any of these:
- a single generic page JSON blob powering the whole site
- hardcoded recipe/article arrays directly inside page files
- giant bodyHtml strings containing whole page layouts
- ingredients and steps stored as one unstructured HTML field
- one giant Page component with 40 props
- route/path/title-based conditional template logic instead of structured data
- separate CTA text fields when a link object can hold the label
- homepage sections manually wired to repeated dummy cards instead of query results
- flashy template aesthetics that overshadow content architecture

Quality bar:
This should feel like:
- a premium editorial food publication
- a modern successor to Umami
- a credible Drupal CMS site template concept
- something a Drupal architect would be happy to migrate
- something that makes Drupal’s structured-content strengths obvious at a glance

When finished:
- Return the working frontend implementation
- In your final response, give a concise build summary only:
  - routes built
  - where the data lives
  - main reusable components
  - main query helpers
  - 5–8 sentences on why this is migration-ready for Drupal Canvas / Views / SDC
Do not spend time generating separate architecture markdown docs unless absolutely necessary to make the code understandable.