A car dealer with its own workshop

update_document on inventory with merge {"status": "sold"}: the car leaves the search page, the JSON and the feed, and its page says Sold.

update_document on service_bookings with merge {"status": "ready", "status_note": "Ready from 15:00."}: the status page shows it straight away.

"Which electric cars under 35,000 euros does this dealer have?" An agent reads /llms.txt, then /api/inventory?fuel=electric&max_price=35000.

Build a website for a car dealer with its own workshop with Hypamoon and put it live. The customer comes first: the cars in stock, a test drive, a service or inspection booking, and where their car is right now, without calling. Use a fictional dealer and 8 fictional cars unless I gave you real ones; say once, calmly, in the footer that they are fictional. Don't ask me anything; make sensible choices.

1. Stock as data. create_collection inventory with a schema (id as a slug, make, model, variant, year, price_eur, mileage_km, fuel, transmission, body, colour, doors, seats, power_kw, range_km, status available, reserved or sold, features, description, image) and access {"assistant_read": true}, so the chat knows the stock. insert_document one document per car, including one reserved and one sold.

2. Bookings. create_collection test_drives (car_id, name, email, phone, preferred_date, preferred_time, trade_in, message) and service_bookings (reference, name, email, plate, car, mileage_km, service as maintenance, inspection, tyres, repair or air_conditioning, preferred_date, drop_off, message, plus status and status_note that the workshop sets), both with {"public_write": true}, triggers {"email_on_insert": true} and a JSON schema. get_form_snippet shows the form html; keep the bot check.

3. The site, with deploy_site. Home with search and four clear actions; /cars, a search page with filters for fuel, body and price and a sort; one page per car at /cars/<id> with price, specifications, features and a Book a test drive button to /test-drive?car=<id>; /test-drive with the car filled in from the link; /service, which makes a booking reference like FM-7K2Q9D in the page before sending (a hidden field) and shows it after; /status, where reference plus plate show the steps booked, confirmed, checked in, in the workshop (or waiting for parts), ready to collect; /privacy, linked under both forms. Structured data: AutoDealer with an AutoRepair department and opening hours on the home page, Car with an Offer (price, EUR, availability) on every car page, an ItemList on /cars. Machine readable: /llms.txt that says what agents can read and which links a person uses to book, /sitemap.xml and /robots.txt. Light and dark, perfect on a phone.

4. Live data for people, agents and classifieds sites, with deploy_app on the same site_id: one module that reads the collections through env.HYPAMOON_API, then update_collection with app_access read on inventory and service_bookings for that app. Routes: /api/inventory as JSON with url, image and test_drive_url per car; /api/inventory/<id>; /api/feed.xml and /api/feed.csv, a feed of the cars that are available now, for classifieds sites that fetch a feed URL; /api/service-status that answers only when reference and plate both match, and never returns a name, email or phone. Pages update their status badges from /api/inventory, so a sold car never looks available. Start from:

const plate = (s) => String(s || "").toUpperCase().replace(/[^A-Z0-9]/g, "");
async function documents(env, collection, filter) {
  const u = new URL(env.HYPAMOON_API + "/collections/" + collection + "/documents");
  u.searchParams.set("limit", "100");
  if (filter) u.searchParams.set("filter", JSON.stringify(filter));
  const r = await fetch(u.toString());
  if (!r.ok) throw new Error(collection + " answered " + r.status);
  return (await r.json()).data || [];
}
// GET /api/inventory (q, fuel, body, max_price, status), /api/inventory/<id>,
// /api/feed.xml and /api/feed.csv (only status available, same ids every time),
// /api/service-status?reference=&plate= (only when both match; never name, email or phone).

5. The chat. set_assistant in the visitor's language with instructions: answer only from the stock, never invent a price, discount or trade-in value, send people to the car page, /test-drive or /service, and for the status to /status, never asking for a plate in the chat. Then create_chat_widget with allowed_origins set to the site's origin, and put its embed_code on every page.

6. Confirmation by email. list_email_domains: with a verified sending domain, create_email_template for a test drive and for a workshop booking (the form fields are its variables, so the reference goes in the email) and create_email_automation on form.submitted, filter.collection test_drives and service_bookings, to contact. Without one, skip this step and tell me: the dealer still gets every booking by email, and the customer sees the confirmation and reference on screen.

7. Check: fetch_site_page on /, /cars, a car page, /llms.txt, /api/inventory and /api/feed.xml. insert_document one service booking with a fictional plate and status waiting_for_parts, and check /api/service-status with the right and a wrong plate. Give me the link and the reference and plate to try.

Optional, only when I ask:
- Classifieds sites: in the dealer account of a classifieds site, paste /api/feed.xml (or /api/feed.csv) as the feed URL and map the fields there; the feed follows the stock by itself. A site with an API instead of a feed URL gets its own adapter: the recipe build-an-adapter.
- Their own dealer management system: the recipe build-an-adapter connects it, then query_adapter reads the stock and update_document keeps inventory in step.
- Phone: search_numbers, order_number and set_call_plan, so the same assistant answers the phone when the team does not pick up. Never use a demo number that answers.
- A reservation deposit: a products collection (create_collection with role products) and get_checkout_snippet on the car page, a test payment while payments are in test mode.

Updating the status is one call for the workshop or its chat: update_document on service_bookings with merge {"status": "ready", "status_note": "..."}.

Done when

• The site is live, opens without an account, and has no horizontal scroll at 375 px, in light and in dark.
• Every car in inventory has its own page with schema.org Car data and an Offer; the home page has AutoDealer data.
• /cars filters by fuel, body and price; a sold car is not listed and its page says Sold.
• /api/inventory and /api/feed.xml answer from the collection; the feed has only the cars that are available.
• The test drive and workshop forms send to their collections; /service shows the booking reference after sending.
• /api/service-status shows the status for the right reference and plate, and 404 for a wrong plate, without personal details.
• /llms.txt names the live stock, the feed, the booking links and the status endpoint.
• The chat widget is on every page; customer confirmation emails are on, or the user was told they need a verified sending domain.