GLOBAL STYLE SYSTEM - MANDATORY
==================================================

STAGE OWNERSHIP

- Planner owns page recipes, section roles, component families and variants.
- Content owns declared text variables and factual consistency.
- Media owns declared local asset variables and truthful provenance.
- Global tokens own typography, colour, spacing, radius and restrained motion.
- Package compiler owns Elementor IDs, component markers and file structure.
- Repair owns evidenced variable, media or token corrections before any structural exception.

Do not solve a token problem with per-widget overrides. Do not solve missing copy with a new section. Do not solve an image problem by changing the component. Do not solve a responsive defect by hiding meaningful content.

Global colors and fonts are mandatory, not optional.
Do not leave Elementor global colors/fonts as defaults.
Do not only hardcode styles widget-by-widget.

The imported site is the styling authority. Do not accept a standalone preview that looks correct while the clean Kit Factory import falls back to white/default Elementor styling.
Store all reference-specific styling in native Elementor container, widget, responsive and Site Settings controls. Project CSS, custom CSS and page/section classes are forbidden.

project.json must include inline site_settings with a complete design-token system.

Define at minimum:

Colors:
- Primary color
- Secondary color
- Accent color
- Dark text
- Muted text
- Light background
- Section background
- Card background
- Border color
- Button background
- Button text
- Button hover background
- Button hover text

Typography:
- Heading font
- Body font
- Button font/typography
- H1 size/weight/line-height
- H2 size/weight/line-height
- H3 size/weight/line-height
- Body size/weight/line-height
- Small text size
- Button text size/weight

Layout tokens:
- Container width
- Section padding desktop
- Section padding tablet
- Section padding mobile
- Container gap
- Card padding


- Card gap
- Button padding

Style tokens:
- Button radius
- Card radius
- Image radius
- Input radius
- Card shadow
- Header shadow
- Border style

Widgets must reference global style tokens where Elementor supports it:
- Headings should use global heading font/color
- Body text should use global body font/text colors
- Buttons should use global button colors/typography/radius
- Cards should use global card background/radius/shadow
- Sections should use global background and spacing tokens
- Forms should use global typography, borders, radius and button style

The final site must be adjustable from Elementor Site Settings without needing to manually
fix every widget.

==================================================
COLOR CONTRAST / READABILITY - MANDATORY
==================================================

All text must be readable against its background.

Follow WCAG AA contrast guidance:
- Normal text must have at least 4.5:1 contrast
- Large text/headings should have at least 3:1 contrast
- Buttons, icons and important UI elements should have at least 3:1 contrast against
surrounding colors

Do not place dark text on dark backgrounds.
Do not place muted gray text on dark sections if it becomes unreadable.
Do not place white/gold text on bright images without sufficient overlay.
Do not use low-opacity text where readability suffers.

For dark websites:
- Body text should use light/off-white colors
- Muted text should still be readable
- Accent/gold text should only be used where it has enough contrast
- Cards should have enough contrast against the section background
- Buttons must have clear text contrast
- Image backgrounds must use overlays when text is placed on top


Every section must define safe text color pairs:
- Dark section background + light text
- Light section background + dark text
- Accent button background + readable button text
- Card background + readable heading/body text

Post-build QA:
- Hero text is readable
- Card text is readable
- Footer text is readable
- CTA text is readable
- Buttons are readable in normal and hover states
- Text remains readable on mobile

==================================================
LAYOUT RULE - NO FLEX WRAP
==================================================

Do not use flexbox Wrap in Elementor container layouts.

Use normal flex layouts without wrap for general structure.
Use CSS/Grid-based container layouts where it makes sense.

Flexbox is acceptable for:
- Header logo/menu/CTA rows
- Simple two-column layouts
- Button rows
- Icon/text rows
- Small inline elements
- Normal parent/child structure where no wrapping is needed

Do not use flex-wrap for repeated card/info sections.

For repeated card/info sections with 6 items:
- Use grid layout
- 3 columns on desktop
- 2 rows on desktop
- Responsive tablet/mobile fallback
- Do not use flex-wrap

For repeated card/info sections with 3 items:
- Use grid or clean horizontal container structure
- 3 columns desktop
- 1-2 columns on tablet/mobile depending on design

For repeated card/info sections with 4 items:
- Use grid where appropriate
- 4 columns or 2x2 layout on desktop depending on design


- Responsive tablet/mobile fallback

General structure:
- Use Elementor containers
- Use boxed containers by default
- Use full-width sections only when the design clearly calls for it
- Use padding and container gap for spacing
- Avoid negative margins unless absolutely necessary
- Avoid unusual layout hacks
- Avoid horizontal overflow
- Keep mobile layouts clean and stacked

==================================================
INFO BOX / CARD GRID RULE - MANDATORY
==================================================

Repeated info boxes, service cards, benefit cards, review cards, price cards and feature
cards must use explicit grid layout.

Do not build repeated card sections as vertical 1-column stacks unless the reference design
clearly shows a vertical list.

Use grid for:
- Info boxes
- Service cards
- Benefits
- Features
- Reviews/testimonials
- Price/package cards
- Contact/info cards
- Icon boxes
- Gallery-style cards

Desktop layout requirements:
- 3 cards: 3 columns
- 4 cards: 2x2 or 4 columns depending on the reference
- 5 cards: 5 columns only if space allows, otherwise 3+2 balanced grid
- 6 cards: 3 columns x 2 rows
- 8 cards: 4 columns x 2 rows or 2x4 depending on the reference

Tablet:
- Usually 2 columns

Mobile:
- 1 column unless the design clearly supports 2 compact columns

Grid must be explicit:
- Use Elementor grid container settings where supported, or


- Use a reliable CSS grid helper that is confirmed to load on the frontend

Do not use flex-wrap for repeated card layouts.
Do not use a single vertical parent container for card sections unless intentionally creating a
list layout.

Post-build QA:
- Info boxes must not stack 1x1 on desktop
- 6-card sections must appear as 3 columns x 2 rows on desktop
- Card spacing must be even
- Cards must align visually
- No horizontal overflow

==================================================
PLUGIN ADAPTER LAYER - MANDATORY
==================================================

The package must include a plugin adapter layer prepared for the Admatic plugin stack.
The package should not only build the design.
It must prepare the site for the real Admatic environment.

Include adapter files under:
/plugin-adapters/

Include:
- adapter-manifest.json
- sticky-header-effects.json
- elementor-pro-forms.json
- yoast-seo.json
- tracking-placeholders.json
- performance-images.json
- menu-header-footer.json
- mobile-cta.json

The adapter layer must be referenced from project.json.

Adapter registry should include support for:
- Sticky Header Effects for Elementor
- Elementor Pro Forms
- Yoast SEO
- PixelYourSite / GTM placeholders
- WP Rocket notes
- Imagify notes
- Menu/header/footer adapter
- Mobile CTA adapter

Each adapter should include:
- Required plugin slug


- Status check expectations: active / inactive / missing
- Fields it can apply automatically
- Missing-plugin behavior; Elementor Pro must use block_build, while genuinely optional adapters may define a safe fallback
- Notes shown in README/build report

Sticky Header Effects for Elementor:
- Prepare the global header for Sticky Header Effects for Elementor
- Keep Elementor Advanced > Position at Default. Never set the header container to Fixed or Absolute.
- Use Header V2 native row alignment with align_items center and nested brand:auto, navigation:1fr and action:auto zones inside the measured content width.
- Add sticky-ready settings directly into the header template/container data where possible
- Preserve only the exact semantic global/header markers required by the production standard; do not target them for design
- Recommended behavior:
  Sticky on desktop/tablet/mobile
  Soft background after scroll
  Subtle shadow after scroll
  Optional shrink behavior only when it fits the design
- Header must still work normally if the plugin is inactive
- Include fallback notes in README-HANDOFF.txt

Elementor Pro Forms:
- Use Elementor Pro Forms for contact/lead forms
- Do not use Fluent Forms, Contact Form 7 or other form plugins unless specifically
requested
- Forms must be populated, not empty
- Recommended fields:
  Navn
  Telefon
  E-mail
  Ønsket ydelse/behandling
  Besked
- Do not add form or submit-button classes; the site owner may add optional tracking hooks later
- Include success message in Danish

Elementor Pro is mandatory for every production-standard project:
- Build real Elementor forms
- Set email action
- Set success message
- Apply form styling


- Optionally set hidden fields such as page URL/source

If Elementor Pro is inactive or incompatible:
- Block the production-standard build before any site mutation.
- Show a failed dependency row with the detected versions.
- Do not replace Theme Builder, Nav Menu or Form widgets with HTML fallbacks.

Yoast SEO basics:
- Include SEO title, meta description and focus keyword recommendations for each page
- Use proper heading hierarchy
- One H1 per page
- Use local SEO terms naturally where relevant
- Include contact details and address visibly on the site
- Add Yoast notes in README-HANDOFF.txt in case post meta must be confirmed manually
after build

Pixel / Analytics / GTM placeholders:
Do not inject tracking classes into Elementor content. Record optional analytics recommendations in the adapter or README so the site owner can add hooks manually later.

Cookie/tracking-ready setup:
- Phone links must use tel:
- Email links must use mailto:
- Booking/contact links must use consistent destinations and accessible labels
- Do not configure cookie consent unless specifically requested, but prepare the site so
consent-based tracking is easy to implement


==================================================
STICKY HEADER EFFECTS ACTIVATION - MANDATORY
==================================================

If Sticky Header Effects for Elementor is part of the expected plugin stack, the header must
not only be sticky-ready.
The actual Sticky Header Effects controls must be enabled on the global header
container/template.

The package/plugin adapter must apply the real Sticky Header Effects Elementor settings
used by the installed plugin version.

Required behavior:
- Sticky Header Effects panel must show Enable = On after build
- Elementor Advanced > Position must remain Default, with no direct Fixed or Absolute setting
- Logo, navigation and CTA must share one vertically centered row; navigation is centered and CTA is right-aligned
- Header must be sticky on desktop/tablet/mobile
- Header must get a solid/soft background after scroll
- Header must get a subtle shadow after scroll
- Header text/menu/button colors must remain readable before and after scroll
- Header must still work as a normal styled header if the plugin is inactive

Implementation requirement:
- Do not only add CSS classes like admatic-sticky-header
- Do not implement sticky behavior with Advanced > Position: Fixed
- Do not only use Elementor Pro sticky settings if Sticky Header Effects is specifically
requested
- The package must include the actual Sticky Header Effects settings in the header
Elementor data, or the Kit Factory adapter must apply them post-build

Adapter QA:
- Open the header template after build
- Confirm Sticky Header Effects > Enable is ON
- Confirm sticky behavior works on frontend
- Confirm no manual toggle is needed after build

If the exact Sticky Header Effects setting keys are uncertain:
- Create/export a test header where Sticky Header Effects has been manually enabled
- Compare the exported Elementor JSON/settings
- Reuse those exact settings in the Kit Factory adapter
- Do not guess unsupported setting keys

==================================================
MENU BUILDER - MANDATORY
==================================================

The package must define menus as first-class data.

Use this structure where relevant:
"menus": [


    {
        "name": "Primary Menu",
        "location": "primary",
        "items": [
          { "title": "Forside", "url": "/" },
          { "title": "Om os", "url": "/om-os/" },
          { "title": "Ydelser", "url": "/ydelser/" },
          { "title": "Kontakt", "url": "/kontakt/" }
        ]
    }
]

Kit Factory must create/update the WordPress menu and assign it to the correct theme
location.

Header and footer navigation must use Elementor Pro Nav Menu widgets.
Do not use raw HTML navigation in a production-standard package.

Header navigation must include an Elementor Pro Nav Menu widget connected to the primary menu.
Footer navigation must include an Elementor Pro Nav Menu widget connected to the footer menu.

The header must not omit the navigation area.
Kit Factory v2.13.1+ can auto-insert/connect a Nav Menu widget, but the package
should still include an intentional header navigation area.

Menu requirements:
- Main navigation must match the required pages
- Header must include the primary menu
- Footer should include relevant navigation links
- Mobile menu must work
- On mobile, the closed header must be exactly one non-wrapping row with the logo/brand and burger toggle aligned together; do not stack either item.
- Hide desktop header CTA buttons on mobile. Do not place a third CTA item in the compact row; the opened navigation panel may expand below it.
- Menu links must point to the correct page slugs
- Do not rely only on static HTML navigation
- Do not add tracking or project-specific classes to CTA buttons or menu links
- Use location: "primary" for the main menu
- Use location: "footer" for footer menus where included
- Package should not trigger Kit Factory menu-location or missing Nav Menu widget
warnings after build


PROJECT WIZARD MEDIA LIBRARY INTAKE
- Uploaded references, logo and client photography are real WordPress Media Library attachments, not temporary form files.
- Preserve the originating staging attachmentId, public URL, mime type, dimensions and semantic role through configure-media and project materialization. Core should download from the URL unless it has independently resolved a Core-local attachment ID.
- logo_attachment_id/logo_asset_url identifies the active brand-logo and must never be replaced by a content photo, template-kit logo, screenshot crop or generated placeholder.
- reference_asset_urls are design evidence only and must never be inserted into page imagery.
- media_asset_urls are production-media candidates and require named section/control usage plus truthful provenance.
- A page refresh must not be part of the upload flow; the current prompt brief and asset list are persisted atomically by the REST upload endpoint.

==================================================
IMAGE / MEDIA RULES - LOCAL MEDIA FIRST
==================================================

Use client-provided images when available.

All images used on the website must be included as local package assets.

Required image structure:
- Put every image file inside the project ZIP under:
  /assets/images/
- Do not reference live remote image URLs directly inside Elementor widgets, background
  images, galleries, cards, templates or page content.
- Remote Unsplash/source URLs may only be used as source/credit metadata in the media
  manifest.
- Every stock image must identify provider, photographer/credit and source page.
- Every image must state generation_method: photography, client_asset or generated. Generated is forbidden unless media_source_policy explicitly allows it.
- Elementor content must reference importable local asset keys or local package paths that
  Kit Factory can rewrite after Media Library import.
- Do not leave empty image boxes.

Client images:
- Use client-provided images first.
- Include them under /assets/images/.
- Add descriptive filenames.
- Add alt text.
- Add them to the media manifest.
- Set generation_method to client_asset.
- Set provider to the client or business name and include an explicit ownership credit.
- Set source_url to client-provided:// followed by a stable original filename or asset identifier when no real public source exists.
- A real HTTPS source is allowed when it exists. Never fabricate an HTTPS URL for a private client file.

Placeholder images:
- When client images are missing, use real photographic placeholder images.
- Preferred source: Unsplash or another approved real-photo source.
- Download/place the placeholder images into /assets/images/ before creating the ZIP.
- Do not leave placeholders as remote-only URLs.
- Do not generate images when media_source_policy is licensed_stock_local, mixed_user_stock or user_assets_only.
- Do not create AI-style placeholder graphics.
- Do not create abstract decorative WebP/JPG/PNG placeholders.
- Do not create placeholder images inspired by, copied from, traced from, or visually derived
  from the uploaded design reference.
- Do not use screenshots, crops, blurred crops, redraws, vectorized versions, or generated
  versions of the reference images.
- Do not use generic abstract black/gold graphics, AI patterns, icon-like artwork, or
  generated background panels as image placeholders.
- If suitable real photos cannot be downloaded, stop and state that the package cannot pass
  media QA yet; do not replace this requirement with remote-only image URLs.

Every image must be listed in the media manifest/project.json with:
- id / asset key
- local file path
- filename
- alt text
- source URL or credit URL: HTTPS for external photography, or client-provided:// for client_asset provenance
- provider and photographer/credit
- generation_method
- original width/height or packaged dimensions
- usage location
- import_to_media_library: true
- rewrite_elementor_references: true
- expected Elementor rewrite target

Elementor image references:
- Image widgets must reference the local asset key/path.
- Background images must reference the local asset key/path.
- Gallery/card images must reference local asset keys/paths.
- No Elementor image field may depend on a remote URL being available in the browser.
- No image widget may be left with an empty ID and a remote-only URL.
- Remote URLs are allowed only as manifest source/credit metadata and must map to a local
  image that will be imported into the WordPress Media Library.

Image styling and positioning:
- Images must follow the reference radius, cropping and visual treatment.
- Use object-fit: cover where needed.
- Set object-position intentionally.
- Images inside rounded cards must inherit/receive the same border radius.
- Do not let square images break rounded design language.
- Do not stretch images unnaturally.
- Do not use overly dark image overlays that make the image unusable.
- Do not use overly light overlays that make text unreadable.
- Text over images must always have enough contrast.
- Hero/background images must include overlay settings where needed.

Media handling requirements:
- Use optimized JPG/WebP placeholder images
- Avoid oversized images
- Avoid unnecessary background image stacking
- Use image widgets where possible
- Use background images only when the design requires it
- Use clean, descriptive filenames
- Add image alt text
- Support local ZIP assets as the default and required build path
- Keep remote Unsplash/source URLs only as source/credit metadata
- Detect duplicate images before importing
- Reuse existing imported images where possible
- Store imported media manifest per project
- Warn if image is too large
- Convert/rewrite image references reliably inside Elementor content
- Include image/performance notes in performance-images.json and README-HANDOFF.txt

Reject and rebuild the package before delivery if:
- images are only remote URLs
- files are missing from /assets/images/
- images are not listed in the media manifest
- Elementor image widgets/backgrounds do not reference importable local assets
- the ZIP depends on browser-loaded external image URLs
- images do not import to the WordPress Media Library after build
- frontend screenshots show broken image icons
- remote image URLs remain in Elementor content after import

==================================================
LEAD GENERATION STRUCTURE
==================================================

For lead-generation websites, include conversion-focused structure by default:
- Clear CTA in header
- Hero CTA
- Trust/reassurance section
- Services/ydelser cards
- Benefits section
- Contact form section
- Click-to-call button
- Email button
- Location/address block
- FAQ section
- Footer CTA
- Mobile-friendly CTA behavior
- No injected tracking classes; optional tracking hooks are documented for manual owner setup

Every important CTA must have a stable destination and readable label; tracking hooks remain a manual owner choice.

==================================================
BASELINE EDITOR BEHAVIOR
- Leave Elementor Advanced > Position at Default for every page, section, template, container and widget. Do not use Relative, Fixed, Absolute or responsive offset controls.
- Use an explicit native Elementor page background. CTA banners use internal padding and no external margin, so no theme canvas can appear above or below them.
- The header brand is an Image/Site Logo widget only when assetRole is brand-logo; otherwise it is a native Heading wordmark containing the business name. Placeholder logos and content photos in the brand zone are forbidden. Header V2 uses space-between with bounded logo dimensions, Nav Menu Full Width is Yes, and the CTA uses Elementor responsive hide_mobile.

CANONICAL GEOMETRY DEFAULTS
Use 1300px content width, 100/70/56 desktop/tablet/mobile section rhythm, a minimum 620px hero, three desktop card columns, and a four-column footer with at least ten widgets unless measured project evidence justifies a bounded change.


MODERN GOLDEN STANDARD V4 — CREATIVE EXPRESSION CONTRACT
- Visible reference evidence is authoritative. Reconstruct its section sequence, geometry, media rhythm, visual density, hierarchy, surface changes and conversion flow before selecting components.
- Do not default to repeated bare heading/text card grids. A standard homepage should normally contain 10–14 distinct visual regions; inner pages should normally contain 6–10.
- Approved components are optional candidates, not mandatory output. Use them only at measured structural match >= 0.96. Otherwise use expressive admatic.native-composition.v2 structures.
- Creative freedom is open inside native Elementor controls. Use Grid, nested containers, images, galleries, counters, icons, icon lists, testimonials, forms, accordions, tabs, carousels, dividers, backgrounds, overlays, borders, radii, soft shadows, typography and responsive controls.
- Hard restrictions only: direct Position remains Default; no custom CSS; no HTML widgets; no flex wrap; no arbitrary tracking/design classes. Multi-column layouts use native Elementor Grid with explicit desktop/tablet/mobile columns.
- Modern surface language: subtle 1px borders, 12–32px radii, soft low-opacity shadows, alternating dark/light or accent/quiet regions, deliberate image crops and clear content max-widths. Avoid every section looking like the same flat dark rectangle.
- Mobile must satisfy document.scrollWidth <= document.documentElement.clientWidth + 1 at 390px. Clear fixed/oversized widths, negative margins and multi-column mobile grids; mobile grids collapse to one column.
- Use at least four media-led regions on a standard homepage when enough media is available. Prefer editorial split layouts, image mosaics, location cards, quote/proof panels and richer CTA/footer transitions.
