image-to-code — implement the reference boards faithfully (Phase 3)

The boards are the specification. The #1 failure mode of image-grounded builds is design drift: strong references, generic code. This file is the discipline that prevents it.

Deep board analysis (per section, BEFORE coding it)

Read the board image again at build time — do not code from memory. Extract, per board:

Anti-drift rules (during implementation)

Ambiguity resolution (in order)

  1. Preserve the visible design language.
  2. Preserve layout + spacing logic.
  3. Preserve the component family.
  4. Preserve mood/polish level.
  5. Generate an extra detail image of the unclear region.
  6. Regenerate that section's board fresh.
  7. Only then pick the most implementation-friendly faithful reading.

Never fill ambiguity with a generic default first.

Bespoke chrome (hard rule, gate-checked)

Page chrome inside a section board is non-normative. Board generators often render a nav bar, footer, or sibling-section fragments inside a single section's mockup. Only the section's OWN content is binding; do not copy board-invented nav items, footer chrome, or adjacent-section slivers into a section that doesn't own them.

Board-drawn eyebrows beyond the budget are also non-normative. Boards love uppercase kickers and will draw one on nearly every section; the page's eyebrow ceiling (ceil(sections/3)) wins. Keep the budgeted ones where the board placed them; drop the rest without treating it as drift.

The generated icon set is exempt from the "don't add micro-UI" rule when it annotates real content (spec rows, facts tables, feature labels) — the icons come from the asset plan, not board improvisation. Don't scatter them decoratively where nothing needs annotating.

Board vs. brief precedence for CTAs: the board wins for composition and placement; the brief's CTA inventory wins for the CTA's garment and interaction identity (boards often render generic default buttons — that part of the board is not authoritative). Distinct intents (e.g. "book" vs. "walk in") may carry distinct labels; the one-label rule collapses only same-intent duplicates.

Garment catalog — stop reinventing the same three buttons. Recent builds converged on the same trio (drawing underline, hover flood-fill, framed block). Those three are now RATIONED: at most ONE of them per page, and zero overlap with the previous build's garment set (anti-convergence ledger, wow-catalog.md). Pick or derive the rest from garments like these — always re-expressed through the brief's material world, not copied literally:

The test: cover the label — could you still tell which site this button belongs to? If it could live on any site, it's not done.

No shared button/CTA style stamped across the page. Each CTA is designed in the component that owns it, with its own interaction identity — examples:

Same voice, different garments. Also: no site-wide .btn-primary-style utility classes in the global CSS; style CTAs where they live. Two builds (or two sections) sharing the same nav/CTA shape is a failure even if the palette differs.

Structural hygiene