NAVIGATION SECTION RULES:
- Use a fixed/sticky top navigation bar with class "site-nav" or "main-nav"
- The nav MUST be the very first element inside <body> — nothing may appear above it in the DOM. No div, section, button, banner, or any other element may be placed before the nav opening tag.
- Nav height: 80px desktop, 64px mobile. NEVER add a spacer div or padding element above the nav.
- Include: logo, nav links, and a CTA button. Their positioning is your call per page — a common, safe layout is logo on the left with nav links and CTA grouped toward the right, but you may center the links or choose another balanced arrangement that fits the design. You are responsible for writing the CSS that achieves whatever alignment you choose (see NAV-INNER WRAPPER below).
- NAV-INNER WRAPPER — REQUIRED, EXACT CLASS NAME: Wrap the logo, nav links, CTA button, and hamburger toggle together inside a single `<nav class="nav-inner">` (or `<div class="nav-inner">`) element, directly inside `.site-nav`/`.main-nav`. The platform's landing-base.css gives `.nav-inner` ONLY a structural floor — `display:flex; align-items:center` — so the items lay out as a horizontal row rather than a stacked vertical block. It deliberately does NOT set `justify-content`, gap, max-width, or padding: the nav's ALIGNMENT and SPACING are your design decision. YOU MUST write your own `.nav-inner` rule (or rules on its children) to position the items — e.g. `justify-content: space-between` to spread logo-left / CTA-right, or `margin-left:auto` on the links/CTA group, plus whatever gap, max-width, and horizontal padding suits the design. If you write no positioning, all items will bunch together on the left. Decide the best layout for this specific page. Use this exact wrapper class name, not a synonym like "nav-container" or "nav-row".
- NAV CTA WRAPPER CLASS — REQUIRED: The CTA button described under NAV CTA BUTTON below must also carry the class "nav-cta" in addition to its "btn btn--primary" classes (e.g. `<a href="#offer" class="btn btn--primary nav-cta">Get Started</a>`). The platform's mobile CSS targets `.nav-inner > .nav-cta` specifically to keep it correctly ordered alongside the hamburger on mobile — omitting this class is a confirmed way for the CTA to end up out of position on small screens even though the button itself still renders.

LOGO:
- MUST use the real panel logo URLs provided. NEVER use a text-based logo, <span>, <div>, or heading for the logo. ALWAYS use an <img> tag with the provided logo URL.
- Logo max-width: 180px. Never set width:100% on the logo — it will distort the aspect ratio.
- MOBILE NAV LOGO — ABSOLUTE: The logo must ALWAYS remain visible on mobile inside the nav bar. It must NEVER be hidden, pushed off-screen, or removed at any breakpoint. The logo and hamburger button must coexist on the same row at all times on mobile.
- SCOPE REMINDER: The logo URL is only valid in the navigation/header, hero section, and footer. Do not reuse it as a placeholder image anywhere else on the page (see LOGO PLACEMENT RESTRICTION in non-negotiable rules).

NAV LINKS:
- 4–6 items maximum, anchor links to page sections (e.g. #features, #pricing)
- NAV COLLAPSE BREAKPOINT — NON-NEGOTIABLE: The navigation must NEVER collapse to hamburger mode at tablet widths. Full desktop nav links must remain visible at all widths down to 768px. The hamburger ONLY activates at max-width:767px. Never write a media query that hides nav links or shows the hamburger at 1024px, 900px, or any breakpoint above 767px.
- HAMBURGER MODE TRIGGER: If all nav links plus the CTA button cannot comfortably fit on a single line at the available nav width, the nav MUST switch entirely to hamburger mode. Estimate the total width needed based on actual link text length, padding, gaps, and CTA button width. If they would crowd or wrap, collapse to hamburger instead of letting individual links wrap their own text.

NAV CTA BUTTON — NON-NEGOTIABLE:
- Far right: a CTA button ("Get Started" or "Join Now") in accent color, visually standing out.
- This button MUST be a plain <a href="#section-id"> with btn classes (e.g. <a href="#offer" class="btn btn--primary">Get Started</a>) — NEVER a <button>.
- It MUST be inside the <header> element.
- On tablet (max-width:1024px): reduce padding and font-size slightly (e.g. padding:0.6rem 1.25rem; font-size:var(--text-sm)) so it doesn't crowd the nav links.
- On mobile: the nav CTA button is hidden by the platform — it remains available inside the hamburger drawer instead. Do not add a separate mobile-only CTA.

MOBILE MENU MARKUP — EXACT CLASS NAMES REQUIRED, NO VARIATIONS:
The platform's mobile CSS and hamburger-toggle JS match these exact hyphenated class names. A different naming convention (BEM double-underscore, camelCase, or any other variant) will NOT be matched and the nav will silently break on mobile. You MUST use:
- .nav-links (the <ul> or <div> containing nav link items — hidden on mobile, shown in open drawer). The platform's landing-base.css now provides the DESKTOP horizontal layout for `.nav-links` automatically (display:flex, gap, list-style:none) as a soft default — so as long as you use this exact class on the links container, it will render as a proper horizontal row on desktop even if you write no `.nav-links` rule of your own. You may still write your own `.nav-links` rule to adjust the gap, font, or colors; just keep it a horizontal flex row. NEVER leave the links container without the `.nav-links` class assuming default styling — a plain `<ul>` with no class renders as a stacked vertical bullet list spilling down the page on desktop.
- .nav-toggle (the hamburger <button> — visible only on mobile)
- .nav-menu (optional wrapper for the full nav drawer area)
The hamburger button markup:
<button class="nav-toggle" aria-label="Toggle navigation" aria-expanded="false">
  <i class="fas fa-bars" aria-hidden="true"></i>
</button>

NAV-TOGGLE APPEARANCE IS YOURS TO STYLE — BUT NEVER SET `display` ON IT — NON-NEGOTIABLE: You ARE responsible for `.nav-toggle`'s visual appearance — background, border, color, font-size, cursor, padding, line-height — write that CSS yourself. But you must NEVER include a `display` property in that rule (or any other rule targeting `.nav-toggle`), at any breakpoint, with or without a media query. `display` for this class is 100% platform-owned (desktop: hidden; mobile: shown) — see BUILD AROUND THE PLATFORM BASELINE in non_negotiable_rules.md. A CONFIRMED REAL-WORLD FAILURE: the model wrote `.nav-toggle { background:none; border:none; ...; display:none; padding:0.5rem; }` — bundling `display:none` into the same rule as its legitimate appearance styling, out of habit, not realizing this specific property is platform-owned. Because this is an unconditional rule (no media query) with the same specificity as the platform's own `@media (max-width:767px) { .nav-toggle { display:flex; } }` mobile-show rule, the two rules tie on specificity and the winner is decided by pure source order — meaning the hamburger could silently stay hidden on an actual mobile visitor too, not just inside the GrapesJS editor, depending purely on which order the two rules happened to land in the output. Write every other appearance property you want on `.nav-toggle`, just never `display`.

CRITICAL — THIS MUST BE A CLASS, NEVER AN ID: The toggle script and CSS both query by CLASS (`.nav-menu`, `.nav-links`), never by ID. A confirmed real-world failure: the model wrote `<div id="nav-menu">` instead of `<div class="nav-menu">` for the mobile drawer wrapper. Because `document.querySelector('.nav-links, .nav-menu')` only matches the `class` attribute, an ID-only element is invisible to it — `navMenu` resolves to `null`, the click listener is never attached, and tapping the hamburger does nothing at all, with no console error to alert you. The CSS that shows the open drawer (`.nav-open .nav-links`, `[class*="nav-menu"]`, etc.) is equally blind to an ID. Giving an element both an id AND the class is fine and often useful for anchor links — but the class is the one that makes the hamburger and drawer actually function, and it must always be present.
WRONG: <div id="nav-menu"> ... </div>  ← hamburger will not open this; clicking does nothing
RIGHT: <div class="nav-menu"> ... </div>  ← or <div id="nav-menu" class="nav-menu"> if you also want an anchor id
Before finalizing your HTML, check every nav-related element you wrote (the toggle button, the links container, the drawer wrapper) and confirm each one carries its required class — not just an id with a similar-looking name.

MOBILE NAV HEIGHT — NON-NEGOTIABLE: On mobile (max-width:767px) the nav bar must remain a single compact row — logo on the left, hamburger on the right — with a fixed height of no more than 64px. The nav must NEVER grow vertically on mobile. All nav links are hidden in the collapsed drawer.

MOBILE PARITY — ABSOLUTE: NEVER add any element, button, banner, or content to the mobile view that does not also exist in the desktop view. Mobile is a responsive reflow of the exact same DOM. Do not inject mobile-only CTAs, banners, or bars.

STICKY BEHAVIOR:
- position: fixed; top: 0; left: 0; right: 0; width: 100%; z-index: 900; will-change: transform.
- The sticky CTA bar (if present) has z-index: 999, so nav must be z-index: 900 to sit below it.
- When nav is present, the hero section needs padding-top to clear the fixed nav — this is fully specified in hero.md's NAV/HEADER CLEARANCE and HORIZONTAL PADDING ON MOBILE rules. Do not write your own ad-hoc padding-top value here in addition to what hero.md specifies — there is only one place this value should come from, to avoid two different instructions producing two different (and potentially stacking) padding values.
- Nav background: semi-transparent with backdrop-filter: blur(10px), or solid dark/light.
- WHEN THE USER ENTERS COLORS — NAV BACKGROUND MUST BE THE DARKEST COLOR FROM THAT INPUT — NON-NEGOTIABLE: If explicit colors were entered for this request (see COLOR PALETTE in the prompt — entered via the brand colors field, not extracted from an image), the nav's background MUST be the darkest color derivable from that entered palette — a near-black or very dark shade of the entered hue(s), NOT an arbitrary dark gray, NOT a lighter tint of the brand color, and NOT a color unrelated to what was entered. This applies regardless of what the rest of the page's sections use for their own backgrounds (which may legitimately be lighter mid-tones of the palette) — the nav specifically must sit at the darkest end of that palette's range, the same way a real site's persistent header is almost always the darkest, most neutral anchor point on the page. If the entered colors are a hue family (e.g. "navy and gold"), derive a near-black/very-dark-navy shade for the nav background — never substitute an unrelated dark color just because "dark" was satisfied technically.
- THIS EXACT SAME DARKEST SHADE IS REUSED, NOT RE-DERIVED, ACROSS EVERY CONTAINER TYPE — NAV, FORM CARDS, GENERAL CARD CONTAINERS, FAQ BOXES, DARK PILLS/BADGES: This single darkest-palette value is the background for `.site-nav`/`.main-nav`, the form card/container (`.form-card`, `.capture-form-wrap`), general card containers (`.card`, feature/pricing/testimonial cards, any bordered content box), FAQ boxes (`.faq-item`), any pill or badge that uses a dark background, callout/urgency/guarantee boxes, and any other component you give a dark background to. Treat this darkest shade as ONE single value you compute FIRST, before any section-level color planning, and reuse verbatim everywhere a dark background is called for — never let the nav, the form card, a FAQ box, and a pill each independently land on a slightly different "dark enough" shade; they must be the exact same hex.
- PRIORITY ORDER — CONTAINERS ARE FIXED FIRST, SECTION BACKGROUNDS ARE PLANNED AROUND THEM: This darkest-palette container color is decided BEFORE you do the page's section-by-section COLOR PLANNING step (the MANDATORY FIRST STEP described in the prompt). Once it's fixed, plan every section's own background hex with that fixed value already in mind — section backgrounds are free to use other shades from the palette to build proper depth/variety, but you must check each section that will actually CONTAIN one of these darkest-shade containers (the hero with its form-card, a FAQ section, any section with cards) against this fixed value before finalizing that section's background.
- SAME-COLOR EXCEPTION — IF A SECTION'S BACKGROUND WOULD MATCH THE CONTAINER COLOR EXACTLY, SOMETHING MUST CHANGE: A container's dark background and the section it sits directly on top of must NEVER resolve to the exact same hex — if they match, the container becomes visually indistinguishable from its own section, with no visible card/box/nav edge at all (no contrast, no depth, no separation). If your section-planning would otherwise land a section on the exact darkest-palette hex, resolve the conflict — either give that specific section a different (typically lighter mid-tone) background instead, since section-level variety is the more flexible side of this equation, or, only if the section's background genuinely needs to stay at that exact value for other reasons (divider matching, page-wide consistency), give that one container instance a distinguishable alternate dark shade instead (still dark, just not identical to the section beneath it) — e.g. one step lighter or with a subtle hue shift. Either fix is acceptable; what's never acceptable is leaving the two identical. A CONFIRMED REAL-WORLD FAILURE: a hero section's background, the form-card sitting inside that hero, the nav above it, and the dark pill/badge components all resolved to the same (or nearly indistinguishable) dark navy — because the model derived every one of these independently from a narrow 2-color entered palette without checking them against each other, producing a flat, depthless page where nothing visually separated from anything else. This rule does not apply when no explicit colors were entered (image-only or no-color-input generations) — in that case each component still just needs a sensible dark value per its own section rules, with no specific darkest-of-palette/cross-component/section-conflict requirement.
- Sticky state CSS: background: rgba(13,13,13,0.85); backdrop-filter: blur(14px); box-shadow: var(--shadow-md).

NAV INLINE SCRIPT — ALWAYS REQUIRED, NO EXCEPTIONS:
Every single page, regardless of nav style, MUST include one inline <script> tag immediately after the nav's closing </header> tag (or </nav>, whichever is the actual closing tag used). This is non-negotiable and applies even if the page has no hamburger menu, no nav links, or only a logo and a CTA button — the scroll-hide behavior inside this script has nothing to do with whether a hamburger exists and must run unconditionally on every page with a nav. External script.js does not reliably execute inside the GrapesJS editor canvas, which is why this MUST be inline HTML, never placed in the separate javascript output field.

This single script always contains TWO independent behaviors:
1. Hamburger toggle (only does anything if .nav-toggle and .nav-links/.nav-menu exist on the page — safely does nothing otherwise, so it is harmless to always include even on a no-hamburger page).
2. Nav hide-on-scroll (always runs on every page that has a .site-nav or .main-nav element — completely independent of whether a hamburger menu exists).

Do NOT reason "this page has no hamburger, so I can skip the inline script" — that is incorrect. The hide-on-scroll behavior is the reason this script is required on EVERY page; the hamburger toggle is simply bundled into the same tag for GrapesJS-reliability reasons, not because the two behaviors depend on each other.

Use this exact script, unmodified, on every page:
<script>
(function() {
  var insideGrapesJs = window.location.search.includes('grapesjs') || document.body.classList.contains('gjs-no-pointer');

  // Hamburger toggle attaches REGARDLESS of GrapesJS context — there is no
  // reason a designer previewing/building inside the editor shouldn't be
  // able to click the hamburger and see the mobile drawer open. Only the
  // scroll-hide behavior below is skipped inside the editor (see that
  // section for why).
  var navToggle = document.querySelector('.nav-toggle');
  var navMenu = document.querySelector('.nav-links, .nav-menu, #nav-links, #nav-menu');
  if (navToggle && navMenu) {
    navToggle.addEventListener('click', function() {
      var isOpen = document.querySelector('.site-nav, .main-nav').classList.toggle('nav-open');
      navToggle.setAttribute('aria-expanded', isOpen ? 'true' : 'false');
    });
  }

  // Scroll-hide is skipped inside the GrapesJS editor canvas specifically —
  // a nav that slides away mid-scroll while someone is editing inside the
  // canvas is disorienting and can interfere with selecting/editing nav
  // content. This early return does NOT affect the hamburger above, which
  // has already been wired up by this point.
  if (insideGrapesJs) return;

  var lastScrollY = window.scrollY;
  var nav = document.querySelector('.site-nav, .main-nav');
  if (nav) {
    nav.style.transition = 'transform 0.3s ease';
    window.addEventListener('scroll', function() {
      if (window.scrollY > lastScrollY && window.scrollY > 100) {
        nav.style.transform = 'translateY(-100%)';
      } else {
        nav.style.transform = 'translateY(0)';
      }
      lastScrollY = window.scrollY;
    }, { passive: true });
  }
})();
</script>

This script works for both <button> and <button> hamburger elements — the click event listener is tag-agnostic. Do NOT split this into two separate <script> tags, do NOT place either behavior in the javascript output field, and do NOT omit this script on pages without a hamburger menu — both behaviors live in this single inline block on every page, always.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GRAPESJS MOBILE CHECKS — NAVIGATION
[GRAPESJS BUILDER ONLY — page generator: ignore this section]
Run these checks after adding or modifying navigation in GrapesJS.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. NAV-TOGGLE visible on mobile (display is platform-owned — NEVER write display: on .nav-toggle yourself; just verify it's showing):
   editor.Canvas.getDocument().querySelector('.nav-toggle') — should be visible at mobile width.
   If hidden incorrectly, check if YOUR CSS has 'display:none' on .nav-toggle and REMOVE it.

2. NAV-LINKS hidden on mobile (platform-owned, just verify):
   editor.Canvas.getDocument().querySelector('.nav-links') — should be display:none at max-width:767px.

3. LOGO always visible — never hidden on any breakpoint:
   editor.Canvas.getDocument().querySelector('.nav-inner img') — must be present and visible.

4. NAV HEIGHT stays compact on mobile (max 64px):
   editor.Css.setRule('.site-nav, .main-nav', {'height':'64px','min-height':'64px','max-height':'64px'}, {atRuleType:'media',atRuleParams:'(max-width:767px)'});

5. NAV full width — never constrained by a container:
   editor.Css.setRule('.site-nav, .main-nav', {'width':'100%','left':'0','right':'0'}, {atRuleType:'media',atRuleParams:'(max-width:767px)'});

6. NAV-INNER 10px horizontal padding on mobile:
   editor.Css.setRule('.nav-inner', {'padding-left':'10px','padding-right':'10px'}, {atRuleType:'media',atRuleParams:'(max-width:767px)'});

7. HAMBURGER tap target minimum 48px:
   editor.addStyle('@media (max-width:767px) { .nav-toggle { min-width: 48px; min-height: 48px; display: flex; align-items: center; justify-content: center; } }');
