# Implement the planned pages Read the selected direction, storyboard, edited copy, and media inventory. At representative: build the homepage and representative interior. At pages: implement remaining routes and repair reviewer findings. Adapt local components to compositions; don't choose the narrative from a starter stack. Use layout.md for the concrete hierarchy, grouping and spacing review before composing sections. Carry those relationships through interior routes and exposed interaction states; changing only fonts and colors does not establish the intended page structure. For an opted-in reference release, preserve the accepted relationships in direction identity invariants and storyboard: introduction, proof format, density changes, interior development, mobile order and action placement. Inspect the relevant pinned original previews or live dossier evidence before adapting an unfamiliar relationship. Later routes should develop the same organizing idea for their own tasks. If implementation constraints erase it, record the concrete constraint and revise the plan explicitly. Do not solve that mismatch by importing teaching claims/media or replacing the accepted direction with a familiar default. Build site-owned treatments for the selected theme and content. If renaming a component, update its class selectors and variants consistently. Keep ordinary controls accessible, semantic markup, keyboard navigation, image dimensions/alt, and functioning actions. For the representative homepage and interior, follow the active authoring mode in `components.md`. Implement the planned content relationships with site-owned elements. In `composition-v1`, record consequential decisions and bind stable planned element IDs in markup. Check full-page rhythm after compilation; a good isolated element can still be wrong next to its neighbors. Inspect the live local render before accepting the choice. Place media with attention to intrinsic content and crop. Keep text-bearing graphics legible. Retain supported business meaning when adjusting copy to fit. A themed restyle may change component CSS and composition while preserving facts and integrations. Do not edit raw harvest, business facts, or approved copy to disguise a visual failure. For an upstream factual defect, record the required correction instead. Run build and inspect actual output. The next browser and critic nodes provide independent acceptance. # Contact behavior If a page offers a lead form, mark the form `data-lead-form` so the compiler binds its action to the harness lead endpoint. Give every field a native label and meaningful validation. The browser review submits synthetic values against a mocked local response and must see the success state. A form that simply reloads the same page is an essential-functionality defect. A direct phone or email route is also valid when it matches the business's actual contact process. For scroll motion, use the stage-scoped `motion.md` contract. Choose business-specific scenes and quiet intervals; preserve operator policies. Carry motionPlan v2 for every new/reauthored route (historical v1 remains compatible) from direction/storyboard to unique native/component target IDs, then inspect before/during/after normal and reduced scrolling. Temporal claims require live observations or recordings; agent review is not human preference. Whole-page motion responsibility: for new/reauthored routes use motionPlan v2 and read `motion-page`. Cover every authored route, including expansion/contact; locate opening, development, connected quiet intervals and closing in actual IDs. Keep essential content/actions static and readable. Representative runtime success or two colocated effects is insufficient. Inspect normal desktop/mobile full journeys and reduced/static views; critique distribution, continuity, inert stretches, competition and meaningful differences among routes with located evidence. Return actionable repairs, preserving operator off and historical records. Human preference stays unset. For new-build icons, read `icons.md`, search by meaning with `vitris-icons search QUERY`, inspect availability and family-specific sizes with `vitris-icons inspect NAME --json`, and author paired `` tags. Use original SVG masters instead of Unicode/emoji pictograms, icon fonts or client catalogs. Keep a coherent supported family, visible service labels, and accessible control names. The curated industry studio selection supports eight symbols at 24–32px or larger; use core masters for compact controls. Each route receives only its used SVG geometry. For sites with typography version 1, load `typography.md`. Establish concrete shared roles before authoring, reuse sizes and weights across routes, retain the 12px rendered floor, and repair browser typography findings before acceptance. Template identity does not waive this policy. For requested appointment booking, load `scheduling.md`; use the standard component and verify the compatible admin connection. Do not enable it on sites that did not request scheduling. ## Carry the craft through interior pages Treat the representative interior as a real destination with its own visitor task, evidence, content depth and next action. Expand the accepted visual system through every route: shared type roles, navigation, spacing relationships, image treatment, captions, form controls and footer. An interior can use a quieter opening while retaining the site's identity. Reusing the homepage hero and a generic card grid does not establish a complete service or project page. Use the approved material to explain scope, process, relevant constraints and the decision the visitor is making. Keep real project context and detail imagery accessible on the pages where they support the story. Preserve individual services and qualifications from the source ledger. If evidence or photography is missing, keep the gap explicit rather than inventing projects, testimonials, prices or credentials. Review long and sparse routes at both widths, including the ending and the transition into contact or booking. ## Polish the full form and booking interaction Review the resting, focused, invalid, submitting, accepted and failed states as part of the page design. Use the site's type, color, border, radius and spacing tokens consistently. Reserve a clear place for progress and feedback so labels, buttons and nearby content do not jump or overlap when messages appear. Keep field labels visible, errors actionable, entered values intact after a recoverable failure, keyboard focus usable and the resulting status available to assistive technology. Match the wording to the actual result: an enquiry saved, a notification submitted to a provider, a booking awaiting approval and a confirmed appointment are different outcomes. Show a verified contact alternative when a service cannot complete. Avoid decorative success claims or promises of response times without business evidence. Exercise long messages and labels on mobile; optional analytics refusal must not disable essential contact or booking. For the standard booking component, preserve its internal interaction contract and shared type roles; compose the surrounding page and service links. Inspect empty services/times, current price/policy changes, conflicts, uncertain retries, confirmation/pending approval, and private cancellation/rescheduling. Use the existing request identity for an uncertain retry and retain the original reservation when a replacement fails. Follow scheduling.md for privacy and capability-link handling. Browser fixtures establish local behavior; they do not prove live delivery or activate live booking.