generate the DTC brief
Let me grab the product data structures so the DTC brief carries accurate catalog info for the Magento connection.
The /docs/ folder isn't on this branch yet. Let me read the live catalog structures to make the brief accurate.
I have the catalog structure (cabinets with series/finishes, hoods with 10 collections/40 SKUs, LVP flooring). Here is the paste-ready seed prompt for your Direct-to-Consumer project. Copy everything in the block below and paste it as the first message in that new v0 project.
# PROJECT: Kitchens & Flooring Direct (Glide-Lock DTC Site)
Build a Next.js (App Router) direct-to-consumer e-commerce storefront for "Kitchens & Flooring Direct," a consumer-facing brand selling the same products as glidelock.com. This is a SEPARATE site with its OWN look and feel, but the SAME product foundation (catalog, SKUs, pricing structure) so it stays in sync with the main site's Magento backend.
## Relationship to the main site
- Same products, same Magento backend, same SKUs/pricing structure as glidelock.com.
- Different audience: everyday consumers/homeowners (NOT trade/B2B).
- Different visual identity: warmer, friendlier, more retail/shopping-oriented than the main pro-focused site.
- Own domain (consumer brand name "Kitchens & Flooring Direct").
## IMPORTANT — backend / shared core note for my dev team
Do NOT hardcode product data permanently. Build a typed product data layer (TypeScript interfaces below) and a fetch module with a clean interface (e.g. getProducts(), getProductBySku(), getProductsByCategory()). For now, stub it with static sample data matching the structure below. My dev team will connect this to the SAME Magento backend that powers glidelock.com — so keep the data-fetching layer isolated and swappable (one module, not scattered fetch calls). Treat this as the future "@glidelock/core" consumer.
## Product catalog structure (MUST MATCH main site so Magento maps cleanly)
Three top-level categories:
1. CABINETS — organized by Series (e.g. Nantucket, St Charles, Norway, Manhattan, Midwest). Each series has multiple finishes (e.g. "Nantucket White", "Nantucket Grey"), each finish has its own slug + Magento URL + color swatch.
2. RANGE HOODS — 10 collections / ~40 SKUs, grouped into 3 categories: 'shells', 'ventilator', 'premium'. Each collection has multiple SKUs with dimensions + price.
3. LVP FLOORING — luxury vinyl plank collections, each with colors/specs.
### TypeScript interfaces to use for the product layer
interface ProductSku {
sku: string
dimensions?: string
price: number
}
interface HoodCollection {
id: string
name: string
tagline: string
category: 'shells' | 'ventilator' | 'premium'
image?: string
skus: ProductSku[]
}
interface CabinetFinish {
displayName: string // e.g. "Nantucket White"
slug: string // maps to Magento URL — never change casually
image: string
magentoUrl: string
color: string // hex swatch
}
interface CabinetSeries {
id: string
name: string
finishes: CabinetFinish[]
}
interface FlooringCollection {
id: string
name: string
colors: { name: string; image: string; swatch: string }[]
specs: Record<string, string>
}
Use a handful of realistic sample entries per category (use /placeholder.svg images). Keep SKUs/prices realistic but clearly sample.
## Pages to build
- Home: consumer-friendly hero, featured categories (Cabinets / Range Hoods / Flooring), value props (free shipping/financing/easy ordering — placeholder), social proof, email signup.
- Category pages: /cabinets, /range-hoods, /flooring — grid of products/collections with filters (by series/category/price).
- Product detail page: image gallery, SKU/size/finish selector, price, "Add to Cart" + "Request a Quote", specs, related products.
- Cart page (client-side cart state with a context/provider — no payment integration yet; stub checkout).
- About + Contact pages.
## DTC design direction — DIFFERENT from the main site
- This is a CONSUMER shopping experience: warm, approachable, trust-building, conversion-focused. Think modern retail (clean product cards, prominent pricing, clear CTAs, reviews/ratings placeholders, financing badges).
- Do NOT copy the main site's pro/B2B layout. Create a fresh design system.
- Pick a cohesive 3–5 color palette (1 brand color + neutrals + 1 accent). Warm and inviting (avoid the corporate blue/red of the main site unless you want subtle brand continuity). No purple. No gradients unless subtle.
- Choose 2 fonts max (one display for headings, one clean sans for body).
- Mobile-first, accessible (semantic HTML, ARIA, alt text), components split into files.
## Technical notes
- App Router, SWR for any client data fetching/cart sync (no fetch in useEffect).
- Build a CartContext/provider for client-side cart.
- Isolated product data layer (see backend note) — stubbed now, Magento-ready later.
- Per-page SEO metadata.
- This is a separate project from the main site and the landing pages; it shares the product DATA STRUCTURE and brand lineage, but has its own independent design.
## First step when you build this
Start by scaffolding the product data layer + types and the category/home pages with sample data, then the product detail + cart. Generate a design brief first so the consumer aesthetic is intentional and distinct from glidelock.com.Two notes for you:
- The brief tells that project's v0 to generate its own design inspiration first so the DTC look comes out intentionally different from the pro site — that's by design per your "very different look and feel" requirement.
- The shared-core / Magento decision is baked in as instructions to keep the data layer isolated and swappable. When you talk to your dev team, the one question to settle is whether they want a real shared
@glidelock/corepackage or per-site Magento wiring — either way, this brief keeps the DTC data layer clean enough to plug into both.
Want me to also produce a small shared Brand Kit doc (logo usage, the exact tokens, voice/tone) that you can drop into all three projects for family consistency, or are the per-project brief tokens enough for now?
Some of our pages have the eyebrow or preheadline cut off (see screenshot) at the top of the hero.
I need you to check all pages for this.
We have had this problem multiple times and need it fixed throughout
The screenshot shows the LVP Flooring page hero: the fixed Glide-Lock logo header overlaps the blue "COMMERCIAL-GRADE QUALITY" eyebrow text, clipping its top edge. The eyebrow sits too high/too close under the fixed header, so the hero's top padding isn't accounting for the header height. This is a recurring layout issue to fix site-wide.
Let me investigate how heroes handle top spacing relative to the fixed header.
There's a prior fix doc for this exact issue. Let me read it, the header, and the LVP page to understand the pattern.
The header is fixed top-0 with a real height of: utility bar (h-10 sm:h-12 = 40/48px) + main nav (h-16 sm:h-20 lg:h-[100px] = 64/80/100px). So total header height is 104px mobile / 128px sm / 148px lg. Any hero needs to clear that. Let me see how the layout and pages currently handle this offset.
The layout renders {children} with NO global header — so each page renders its own <Header /> and sets its own top padding. That's exactly why this bug keeps recurring: there's no single source of truth for the header offset. Let me find the LVP hero section and see how it's structured, plus how the header is included on pages.
The root cause is clear and confirmed. The header's actual total height is:
- mobile: 40 + 64 = 104px
- sm: 48 + 80 = 128px
- lg: 48 + 100 = 148px
But the LVP hero uses pt-28 (112px) / lg:pt-32 (128px) — which is less than the header height at sm and lg, so the eyebrow clips. Since there's no global header in the layout (each page renders its own <Header/> + own padding), this bug recurs page-by-page.
The right systemic fix is a single reusable spacing token that always matches the header height. Let me check how many pages render <Header /> and what padding patterns exist across the site.
I now fully understand the recurring root cause. The header is rendered per-page (not in the global layout), and its real total height is 104px (mobile) / 128px (sm) / 148px (lg) — utility bar + main nav. The reported LVP page uses pt-28 lg:pt-32 (112/128px), which is shorter than the header at sm and lg, so the eyebrow clips. Several product detail pages also use lg:pt-36 (144px) which is under the 148px lg header. The accepted site standard that works is pt-32 … lg:pt-40.
To stop this whack-a-mole permanently, I'll establish a single source of truth: a pt-hero-safe utility in globals.css sized to always clear the header, then apply it to the offending heroes. Let me read the exact spots.
I have the complete picture. The fix: create ONE reusable utility sized to always clear the header (whose real height is 104/128/148px), then apply it to the clipping heroes. This replaces the per-page guesswork that keeps causing regressions. Let me find where to add the utility in globals.css.
I'll establish a single source of truth. The header's real height is 104px (mobile) / 128px (sm) / 148px (lg), so I'll create a .pt-hero-safe utility with guaranteed clearance plus breathing room, then apply it to the clipping heroes.
The utility is the single source of truth. Now I'll apply it to the pages that are actually clipping — those whose top padding is less than the header height. Starting with the reported LVP page (pt-28 lg:pt-32 = 112/128px, under the 128/148px header):
Now the product detail pages. Many use pt-32 pb-4 lg:pt-36 — and lg:pt-36 (144px) is under the 148px lg header, clipping the breadcrumb by a few px on desktop. And the accessories hero uses pt-24 (96px), under even the mobile header. Let me fix all of these to use the safe utility.
Now I'll apply the fix to the remaining files I've now read. Let me read the others quickly and edit them.
All confirmed. Applying the fix to the remaining five files:
Now I need to check pages that use pt-32 (128px) with no larger lg: value — those clip on desktop because the lg header is 148px. From the earlier search: territory-partner-application, resources, privacy-policy, premier-elite-dealer-program, and dealer-program/territory-partner all use pt-32 without a sufficient lg override. Let me verify each line.
These pt-32-only heroes (128px) sit under the 148px desktop header, so they clip on large screens. The ones already using lg:pt-40 are fine. Let me fix the clipping ones.
A few remaining pt-32-only wrappers (projects, not-found) also fall short of the 148px desktop header. Let me fix those for consistency.
The [id]/page.tsx has two pt-32 pb-24 occurrences (loading + content). Let me fix both, plus not-found.
Now let me verify no clipping patterns remain. I'll re-scan for heroes that still fall short of the 148px desktop header (i.e. pt-32 with no lg:pt-40+ override, or pt-24/pt-28).
Let me re-scan with a simpler pattern to catch any remaining short top-padding heroes, including the hood component.
The grep returned nothing, which is suspicious since I know the hood component used pt-32. Let me check that file directly.
The hood pages use pt-32 sm:pt-36 lg:pt-40 (128/144/160px) — these technically clear the header but with tight margins. For true consistency and to prevent future regressions, I'll convert them to the same pt-hero-safe token.
The hood pages clear the header but I'll standardize them to the token too, so all heroes share one source of truth. Both left columns (163, 299) and both right columns (202, 338) are identical pairs.
Now let me verify the build compiles and then visually confirm the fix in the browser on the reported LVP page plus a couple of others.
The app compiles cleanly (the image-quality warnings are pre-existing and unrelated). Now let me visually verify the fix on the reported LVP page and a couple others using the browser.
I'll screenshot the LVP page at desktop width (where the clip was reported) and verify the eyebrow is fully visible below the header.
The header now clears the hero area — good. But the hero text appears blank, likely because framer-motion's useInView entrance animation hasn't triggered yet. Let me scroll slightly to trigger it and re-capture.
The LVP hero now renders fully below the fixed two-tier header — the "COMMERCIAL-GRADE QUALITY" eyebrow and the "Luxury Vinyl Plank Flooring" headline are completely visible with comfortable clearance, no longer clipped behind the navigation. The fix works.
I resolved the header-overlap/clipping across all affected pages by replacing the inconsistent hard-coded top-padding values (pt-32, lg:pt-36, etc.) with a single shared pt-hero-safe utility token, so every hero now clears the fixed two-tier header (utility bar + main nav) with consistent spacing. I updated the product detail/listing pages (LVP, cabinets, series, finishes, types), the marketing/legal pages (dealer programs, applications, resources, privacy), the projects and 404 pages, and the hood series component, then verified the previously-reported LVP page renders correctly at desktop width. Using one token also prevents this drift from recurring, since future header height changes only need to be adjusted in one place.