Cloud Jet Travel Landing

Supply brand, home base, audience and short hero promise; destinations with coordinates and specific travel content; aircraft/vehicle categories with range, cruise speed, seats and hourly rates; advisor/contact details and approved photographs. Add confirmed dates, policies and operating-partner information where relevant. List missing prices, claims, people, reply times and business facts as drafts for approval.

Choose output within the project’s conventions. The default for no project is a self-contained HTML file. For an existing/requested framework, port the template to real routes/components and typed collections while keeping unrelated work. The guide defaults an unspecified framework request to Next.js App Router with TypeScript. React/Next generic controls use separately installed ReUI primitives; non-React projects need suitable local equivalents rather than a forced stack change.

Map the business to the page family and keep each detail useful. Destinations need their own arrangements, first days and travel facts; fleet pages need actual category specifications and operator caveats. A charter advisor can describe categories it arranges and name operating partners. Helicopter, yacht and rail adaptations need mode-appropriate route/time/pricing logic: the supplied aircraft formula is not a verified sea or rail journey planner.

Preserve the visual hierarchy: a framed high-key jet hero with eyebrow, two-tone headline, one short line, one pale action, sign-off and round arrow; place all trip controls below it. Keep the 84px desktop headline ceiling, 52px phone treatment, faded giant-type bands and tall destination cards. Use graphite for controls and light lilac-grey grounds, deliberate media crops and short optional motion.

Replace collection data and related static references together. The guide supports at least two destinations, three to eight experience themes, one to four fleet categories and two to six guest quotes. Match fleet/about/office grids to their counts, update numbered headings and ensure every route, navigation link, detail ID and destination/experience relationship remains valid. The first hub is the default home base; change it deliberately.

Understand the estimate before displaying it. It uses great-circle distance, flight hours of distance divided by cruise speed plus 0.4 hours per leg, seat capacity and an 8% range margin. Return adds the homeward leg; multi-leg may add a second destination and return; one-way applies a 1.5 repositioning multiplier. Price is hours times the selected category rate, displayed rounded to hundreds of euros. Dates do not change the rate, and accommodation is quoted separately.

Order fleet categories intentionally: automatic selection takes the first compatible entry, not an independently sorted cheapest/smallest aircraft. A preferred incompatible category or fallback can still produce a number alongside a warning. Verify no-match, excess-party, out-of-range, same-destination and multi-leg cases before relying on the interface. Confirm actual route, operator, aircraft and price separately; the formula does not model weather, airspace, stops, airport charges or market availability.

Plan one photographic direction and a unique portrait image per real destination. The eight supplied destination scenes depict invented places and must be replaced. Jet/fleet/cabin/terminal/desk pictures can be disclosed aviation stand-ins only where relevant; the advisor is a generated stand-in, not your team member. For another travel mode replace aviation imagery as well. Use owned/approved photos or an available image tool, whose new generation may incur charges; check subject fidelity, wings, faces, registrations, crops and alternative text.

Test the estimator, its continuation link and booking summary together: departure hub, destination(s), trip type, dates, party, category and extras should agree after navigation. Exercise date constraints and keyboard calendar dismissal, shortlist add/remove/count, filter/search/sort/reset, fleet/departure tabs, carousel keys/swipes and FAQ no-results states. Forms should show inline errors, loading and explicit “nothing sent/booked” preview feedback until a real backend confirms otherwise.

Replace sample metadata, wordmarks, hero/contact/about copy, advisor names, office details, newsletter, legal text, footer and script-built response promises. Retain the local-preview disclosure until integration. Do not inherit sample certified-operator or carbon-removal language without evidence. A generated destination scene or plausible testimonial is not proof of a real service, property or customer.

Build the standalone file with Node.js 18+ and initial internet access to download/embed Inter Tight and Geist Mono alongside local images. Target no more than 5 MB and stay below the 8 MB strict limit. Check helper exit status because an output can be written before missing assets cause failure. Run the supplied validator on the built file; files mode allows local assets but does not verify their existence. Framework output needs type/lint/build checks.

Review home and every route at 1440, 1024, 768 and 390px, extending overflow checks to 360–1920px. Inspect image subjects, text fit, booking calculations and warnings, mobile layouts, focus/Escape, back/forward, reduced motion and the standalone scripts-only iframe. Static checks validate structural/data markers, not actual operational assumptions or browser interaction. Deliver the output path, checks actually performed and all placeholder facts/images, then ask for page or estimate changes in ordinary language.