Building a Restaurant Site

Build around the decisions guests need to make: why visit, what to order, what the experience feels like, and how to get there. Use one evidence-grounded JTBD model across the site, with richer reviews and photos than the initial place response alone provides.

Inputs and Boundaries

• Require restaurant name and city, region, or city/country. Ask for missing values before fetching data or creating site files. A Google/Dineway placeId is optional.
• Keep the existing $dineway-enrich-places lookup and official-website extraction. Supplement Google Maps through normal browser interaction; do not add enrichment APIs, hidden Maps endpoints, external model calls, or batch generation services. The current Agent performs all new analysis and synthesis.
• Require distinct crawlable pages at /, /menu, /reviews, /gallery, and /visit. Reviews and Gallery cannot be replaced by homepage sections. Experience and Journal are evidence-dependent additions.
• Menu, Reviews, and Gallery must query real published Dineway content. Reusable Advantages, special touches, experiences, and tips also belong in CMS when used. Astro owns layout and one-off promotional copy.
• Do not inspect, copy, or adapt Dineway templates/ or demos/ unless the user explicitly requests that exact source. Existing demo-like target files are replaceable implementation files, not a design reference.

Required Workflow

1. Establish the evidence and planning workspace

• Use $dineway-enrich-places with name, city, and the optional authoritative place id. Inspect its returned placeDetailsPath, including reviews, menu data, UGC, posts, videos, service flags, and media. Preserve the original JSON.
• Maintain .plan/<restaurant-slug>/task_plan.md, findings.md, and progress.md for the complete run, including source gaps and validation results.
• Read data-mapping.md for field coverage. The optional summarize helper supplies factual planning inputs; it does not decide the site structure or perform JTBD enrichment.