Build a lookbook-style, multi-page fashion or lifestyle site with image transitions between pages for
[brand name] on the
[server name] site on my Opus Growth hosting server. Brand:
[what it makes, where, for whom]. Season or collection name:
[name]. Products: [for each one name, category, colour, material, price and photo link]. Size chart:
[measurements, or "none"]. How people buy:
[workshop or shop address, WhatsApp number, store link if any]. Shipping and returns:
[if any]. Contact:
[email],
[phone],
[address]. Domain:
[domain]. Lookbook photos:
[links].
Pages: lookbook home (/), collection (/koleksiyon/), a separate page per product (/urun/
[product-name]/), workshop or about (/atolye/), contact (/iletisim/) and 404.html. Home sections: hero (h1, short brand intro, two buttons and a tall main photo), a three-photo lookbook below it where each photo links to a product, the material or making story, and FAQ. Collection page: category filters and the product grid. Product page: large image, name, price, a first paragraph saying what the product is, a material, colour, sizes and care list, a "How do I buy?" box, the size chart and two products from the same collection. No cart and no checkout; buying happens over WhatsApp, in the shop or at the workshop, and every product page says so plainly.
Style: editorial fashion, like a printed lookbook. A fabric-toned background, full-bleed photos with square corners, 1 pixel hairlines, small uppercase letter-spaced labels and plenty of white space. Typography: a high-contrast fashion serif from Fontshare (for example Melodrama 400 and 600) with a calm grotesk body (for example Archivo 400 and 500). One accent colour (for example clay) only for focus rings and hover. Lay the lookbook trio out at 5, 4 and 3 columns of a 12-column grid with a staggered vertical offset. There are two signature elements: the image transition between pages and the Flip quick view in the collection grid. Lenis, Swiper, ScrollTrigger and SplitText are not loaded.
Page transition and Flip rules (follow them exactly):
1. Cross-document View Transitions: write `@view-transition { navigation: auto; }` in `assets/app.css`. The image on the collection card and the main image on the product page carry the SAME view-transition-name; set it with a Tailwind arbitrary property class (`
[view-transition-name:u-product-name]`), not style="". Each name may appear only once per page, because the browser cancels the transition when two elements share a name; the "same collection" cards on a product page may carry their own products' names. Give the top menu `view-transition-name: site-header` so it holds still during the transition. Group duration 0.5 seconds, root cross-fade 0.3 seconds. Inside `@media (prefers-reduced-motion: reduce)` write `@view-transition { navigation: none; }`. Browsers without support simply navigate normally; do not write a JavaScript fallback.
2. Load GSAP and Flip on the collection page only; no other page has any script. Download the GSAP 3.13 core and the Flip plugin from jsdelivr into `assets/vendor/` with site_fetch and pin the version. A one-line script in `<head>` adds the `js` class to `<html>`, and the `anim` class unless prefers-reduced-motion is "reduce". A small loader at the end of the page waits for the load event, two requestAnimationFrame calls and requestIdleCallback, downloads nothing if `anim` is missing, and otherwise appends gsap.min.js, Flip.min.js and a tiny file containing `gsap.registerPlugin(Flip)` in order with async=false.
3. Separate the interaction from Flip: `assets/koleksiyon.js` (defer) runs the filter and quick view WITHOUT Flip as well. On every change, if Flip and `anim` are present, take `Flip.getState(cards)` first, change the DOM, then call `Flip.from(state, {duration: 0.6, ease: "power3.inOut", nested: true})`; otherwise apply the change instantly. That way a visitor who does not want motion can still use the filter and quick view.
4. Filter: the "All" and category buttons sit in a container with `role="group"` and an aria-label, each with `aria-pressed`. Cards that do not match get `hidden`; in Flip use `absolute: true`, onEnter for entering cards (opacity and scale from 0.92 to 1) and onLeave for leaving ones. An `aria-live="polite"` element announces the result, such as "3 products shown".
5. Quick view (the grid to detail image morph): every card has a "Quick look" button with `aria-expanded` and `aria-controls` and a `hidden` detail panel (description, styling tip, link to the product page). When opened, the card spans the full width with `grid-column: 1 / -1` and on desktop splits into two columns, image on the left and details on the right; Flip animates the image growing from the small tile to the large view. Update the opened image's `sizes` for the large view so a bigger file loads. Only one card is open at a time, the button text becomes "Close" and focus moves to the panel, which has tabindex="-1".
6. Without JavaScript the filter and quick view buttons are hidden (`.js-only` shows only under `.js`), and every card and product page link still works. The card's main link always goes to the product page; quick view is a separate button.
Setup and known traps (each one cost points or failed a gate in the demo measurement, do not skip):
1. If a site is already live on the server, tell me first, because setup overwrites index.html and the assets folder. Preview scaffold_site with confirm=false first, then call confirm=true once I approve. Then read site_design_guide and site_seo_guide. Before writing code, write the design direction (typography, colour, grid, signature element, motion language and the libraries that will NOT be loaded) into a short ART.md outside assets and show it to me.
2. Compile Tailwind, do not load it from the CDN. Install `npm i -D tailwindcss@3` with site_run_command and background=true, and follow it with site_command_status. The content paths in `tailwind.config.js` must cover every HTML file including subfolders, the `_src/*.tpl` templates and any JS file that writes classes. `_src/tw.css` holds the line `@import "../assets/app.css";` and the three `@tailwind` lines; compile it into one file with `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remove the cdn.tailwindcss.com script, the inline tailwind.config, chrome.js and motion.js from the pages and link only `/assets/site.css`. Recompile after every HTML change. Add `assets/koleksiyon.js` to the content list too, because it writes classes such as `is-open`.
3. Self-host the fonts. Read the Fontshare CSS with one request per family and weight (`https://api.fontshare.com/v2/css?f[]=family@weight`), download each woff2 file into `assets/fonts/` with site_fetch and write the @font-face rules with `font-display: swap` into `assets/app.css`; design-check looks for the custom font there. Preload EVERY weight used above the fold (heading, body and buttons) on every page with `<link rel="preload" as="font" type="font/woff2" crossorigin>` and put these lines before the stylesheet link. Most Fontshare fonts have no ₺ sign, so write prices with "TL".
4. Make the menu and footer static HTML. Write a small `chrome-stamp.mjs` that reads the nav list from site.config.js and stamps `_src/header.tpl` and `_src/footer.tpl` between the `<!-- nav:start --><!-- nav:end -->` and `<!-- footer:start --><!-- footer:end -->` markers on every page, adding aria-current="page" to the active link. Do not give the templates a .html extension and use placeholders like `
[[NAV]]` instead of `{{...}}`. Build the mobile menu with `<details>` and no JS. Keep the business name, address and phone in the footer as plain text, and make footer and breadcrumb links at least 44 pixels tall.
5. Convert images while downloading them with site_fetch: write the same photo to separate files with resize="480x", "800x" and "1120x" (or the widths the page needs), image_format="webp" and quality=65. Give every `<img>` srcset, sizes and a width and height that match the real ratio. The main above-the-fold image gets fetchpriority="high" and is not lazy; give fetchpriority only to the real LCP element, and loading="lazy" decoding="async" to the rest.
6. Write a small `favicon.svg` in the site root and add `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` to every page; if there is a PNG logo, make an apple-touch-icon with site_fetch, resize="180x180" and image_format="png". Without a favicon the browser logs a 404 for /favicon.ico and Best Practices drops to 96.
7. HTML validator rules: start every document with an uppercase `<!DOCTYPE html>`, quote attributes with double quotes, use ` ` for the spaces in the visible text of tel: links, never use a style="" attribute (if you need a CSS variable, use a Tailwind arbitrary property class such as `
[--r:-4deg]`), give every button type="button", do not put aria-label on role-less elements such as `<ul>` or `<div>`, and use `<section aria-label="...">` instead of role="region".
8. Download product images with site_fetch at a 4:5 portrait ratio with resize="400x", "640x" and "960x"; keep every product photo at the same ratio so the grid stays even and the Flip transition does not jump. The main image on a product page is that page's LCP element and gets fetchpriority="high".
9. Check the display font's digits: in the demo Melodrama's zero was slashed and "2026" in the h1 read like "2Ø26" from a distance. Keep numbers out of display-font headings, or set digits in the body font.
SEO, AEO and GEO:
1. Use directory-style URLs with a trailing slash (/koleksiyon/, /urun/
[product-name]/, /atolye/, /iletisim/ or their equivalents in your language). Fill in the seo block of site.config.js and run `node seo-stamp.mjs`. If there is a physical workshop or shop, set the most specific businessType in site.config.js (for example ClothingStore) and the address; add opening hours only if I give them. Page schemas: home WebPage and FAQPage; collection CollectionPage and an ItemList of every product url; every product page ItemPage and Product (name, description, image, sku, color, material, category, brand and an Offer with price, priceCurrency TRY, availability, itemCondition, url and seller @id); workshop AboutPage; contact ContactPage; BreadcrumbList on inner pages (Lookbook, Collection, product). Even without a checkout the Offer carries the correct price and stock status; if I give shipping and return terms, add shippingDetails and hasMerchantReturnPolicy to the Offer. Do not invent reviews or ratings (aggregateRating). Write every page-specific schema in its own `<script type="application/ld+json">` block and link it to the base graph with @id. Do not nest BreadcrumbList inside @graph; keep it in its own block, because that is the only way seo-check sees it.
2. Titles 48 to 60 characters (seo-check treats over 65 as an error), descriptions 145 to 158 characters, one h1 per page. The main content of every page is at least 150 words. In the demo the workshop and contact pages came in at 113 and 95 words on the first try and were completed with real information such as "what we do in the workshop" and "what to include when you write". On product pages, write shared sentences (care, fabric) as short list items and write the description separately for each product; seo-check warns about duplicate content when pages share more than 50 percent of their sentences.
3. The first paragraph of every page answers the page's question directly, and the h1 is phrased as that question. Write the page's own FAQ with `<details>` and mark it up as FAQPage. Show the publishing organisation and a "Last updated" date with `<time datetime>`.
4. In robots.txt, write your decision with the reason for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot and CCBot, and point to the sitemap. sitemap.xml has a real lastmod. llms.txt has an accurate two-sentence summary of the site and a list of the important pages.
5. No invention: do not write reviews, ratings, awards, customer counts, certificates, opening hours, coordinates, prices or product figures without asking me. Leave any field you do not know out of the schema entirely.
Gates (in order; do not say "done" until all pass):
1. With site_run_command, run in order `node chrome-stamp.mjs`, the Tailwind build, `node seo-stamp.mjs`, `node seo-check.mjs` (0 errors, 0 warnings), `node design-check.mjs` (0 errors; justify any remaining warning) and `npx html-validate "**/*.html"` (0 errors).
2. View every page with site_preview, view="mobile" and view="desktop". site_preview captures the page with motion turned off; if the content is not complete in that capture, the no-motion state is broken. Lazy images further down may be blank in a full-page capture; do not count that as an error, but check their paths.
3. Run core_web_vitals for every page with strategy="mobile" and strategy="desktop". Acceptance: on mobile Performance at least 95 and Accessibility, Best Practices and SEO at 100; on desktop all four at least 95, target 100. For a page that misses, find the slow file with resources=true, fix it and measure again. Then run seo_audit on the home page with strategy="mobile" and runs=2. The network request list must contain no address outside your own domain (store and WhatsApp links are links, not requests).
4. No horizontal scrolling at 360, 390, 768 and 1440 pixels wide, touch targets at least 44 pixels, no console errors.
Interaction check: since site_preview cannot show motion, tell me what to look for in my own browser: in Chrome or Edge, clicking a product in the collection makes the image grow from its card into its place on the product page while the menu stays put; in Firefox the page simply opens; pressing a filter slides the cards into a new order; "Quick look" opens the card inside the grid and the image grows; with reduce motion on the same actions happen instantly; with JavaScript off every product is visible. In a local check I also saw `document.documentElement.matches(':active-view-transition')` return true on the product page during the transition; you can run the same check.
After publishing: preview the rule `/assets/* Cache-Control: public, max-age=31536000, immutable` with site_headers and apply it once I approve; from then on, version the file name whenever CSS or JS changes (site-v2.css and so on). Submit sitemap.xml with gsc_submit_sitemap and check the home page with gsc_url_inspect. At the end give me: a per-page score table (page, four mobile scores, four desktop scores, LCP, CLS), the gate results and the list of fixes you applied.
