1
Wybór recipe
Z canvasa i briefu agent inferuje hero, cards, story, faq, cta itd.
Section recipes
Recipes są główną warstwą, z którą agent powinien pracować przy zwykłych trasach.
To tutaj mieszczą się warianty, fallbacki i estetyczne defaulty. Nie w page.tsx, nie w kilku równoległych helperach.
Przykładowe recipes
Hero, cards, story, proof, timeline, faq, contact, cta.
Każda recipe ma sensowne defaulty, działa przy małej ilości danych i umie żyć bez obrazu albo aside.
Co agent ustawia
Dobór section recipe to prosty zestaw prymitywnych decyzji.
kind → variant → tone → density → surface → widthMode → heightMode → sloty.
2
Wybór wariantu
Split, centered, strip, stack, band, rail, grid.
3
Wypełnienie slotów
intro, items, actions, media, metrics, aside, body.
Variant defaults
Każda recipe umie estetycznie działać nawet przy małej ilości danych.
Poniższy przykład pricingu pokazuje fallback bez rozbudowanych porównań i bez custom layout engine.
Compact
Recipe fallback
Działa przy samym title, price i 2–3 bullets.
od 1 900 zł
brak tabeli porównawczejnadal estetyczny layoutten sam model danych
od 1 900 zł
Balanced
Route-friendly
Agent nie wymyśla JSX. Dobiera recipe i sloty.
od 3 500 zł
łatwa zamiana sekcjispójny surfacespójne CTA
od 3 500 zł
Airy
Premium intent
Różnica estetyczna wynika głównie z intentu, nie z osobnej architektury sekcji.
indywidualnie
tonedensityemphasis
indywidualnie
FAQ recipe
Wspólna semantyka upraszcza planowanie i walidację.
Validator nie musi zgadywać, czy to nowy custom widget, bo każda sekcja ma data-section-kind i deklaratywne route composition.
Czy każda sekcja ma inne propsy?
Nie. Celowo trzymamy wspólne sloty i wspólne intent controls.
Czy agent może usuwać i zamieniać sekcje?
Tak. Na poziomie listy sekcji w route modelu, bez rozbijania JSX page.tsx.
Czy canvas wpływa na wybór layoutu?
Tak. Geometryczne heurystyki mapują width/height semantics, recipe i variant.