tripkit 1.0.1 → 1.2.0

package/CHANGELOG.md

@@ -2,6 +2,28 @@
 
 All notable changes to TripKit are documented here. Versioning follows [SemVer](https://semver.org/).
 
+## [1.2.0] — 2026-04-30
+
+### Added
+- **`tripkit validate <trip.yaml>`** — schema validator that checks required fields, lat/lng ranges, valid stop types, hex colors, day numbering (sequential, status enum), `trip.total_days` / `trip.total_stops` consistency, optional routes structure, and theme fields. Warnings are advisory; errors block render. Pre-render validation is automatic; pass `--no-validate` to bypass. Includes a warning when any consecutive-day jump (Day N's lodging-or-last-stop → Day N+1's first stop) exceeds 250 mi without an explicit `routes[]` entry.
+- **Origin / destination pins.** New optional schema fields `trip.origin_lat`, `trip.origin_lng`, `trip.destination_lat`, `trip.destination_lng`. When set, the renderer draws a green "A" Start pin and (for one-way trips) a red "B" End pin. For round trips, omit the destination fields. Without these, the trip's start/end was previously invisible — polylines just terminated in empty space.
+- `theme.hotel_label` — optional 1–4 char string overriding the auto-derived hotel marker label. Falls back to first 3 chars of `agent_context.preferences.accommodation_chain`, then 🏨.
+- Three new example trips: `southwest-parks-2026.yaml` (5-day UT/AZ parks loop, Zion/Bryce/Page/Grand Canyon), `nyc-long-weekend-2026.yaml` (3-day fly-in city break, single Marriott, no driving — exercises `museum`/`city`/`food`/`shopping`), `new-england-fall-2026.yaml` (5-day VT/NH foliage loop, regional inns, serif theme).
+- Mobile polish at iPhone widths (≤480px): collapsible map legend (tap to expand), tighter day-nav, smaller hero, repositioned map controls. No regression at desktop or tablet.
+- **Skill drift check.** `scripts/check-skill-coverage.js` enumerates 44 renderer-meaningful schema fields and asserts every one is mentioned in `agent/AGENT-SKILL.md`. Wired into `npm test` so future schema additions can't ship without updating the agent skill.
+
+### Fixed
+- **Disjointed inter-day routes.** When auto-generating route polylines (no explicit `routes[]` defined), each day's segment is now anchored to the previous day's lodging at the start and today's lodging at the end. Day N's polyline runs `prev-lodging → stops → today-lodging` and Day N+1 starts from the same point — the trip reads as one continuous chain instead of disconnected per-day segments.
+- Duplicate hotel markers when one hotel covers multiple consecutive nights (visible in NYC's 3-night Marriott stay). Markers are now deduped by lat/lng, popups show "Nights X–Y · {first date} – {last date}", legend count reflects unique hotels.
+- "Full route" bounds now include hotels and origin/destination pins, not just stops. Previously the Vegas start pin on the Southwest trip was off-screen on initial load.
+- CSS cascade bug: mobile media query was placed before base `.legend` rules, so overrides silently lost the cascade. Moved to end of stylesheet.
+
+### Changed
+- Southwest and New England examples ship explicit `routes:` blocks (matching the Oregon pattern). Polylines follow real road geometry (I-15, US-89, Kancamagus Hwy, Rt 100, etc.) instead of relying on auto-generation. NYC stays auto-generated.
+- All four examples now ship `origin_lat`/`origin_lng` (Oregon/Folsom, Southwest/Las Vegas, NYC/JFK, New England/Boston).
+- **Agent skill rewritten** to reflect the validate workflow, `theme.hotel_label`, the `routes[]` convention (when to use vs. when to omit), the lodging-anchor auto-fallback, origin/destination guidance, the 250-mi long-leg warning, and 12 lessons learned (two new from this set of work).
+- CONTRIBUTING: documented the routes convention — road trips should ship explicit `routes:`, city trips can omit.
+
 ## [1.0.1] — 2026-04-30
 
 ### Fixed

package/README.md

@@ -65,6 +65,16 @@ node convert.js examples/oregon-spring-2026.yaml my-trip.html
 open my-trip.html
 ```
 
+### Validate before you render
+
+TripKit ships with a schema validator that catches data bugs before they reach the renderer:
+
+```bash
+npx tripkit validate my-trip.yaml
+```
+
+It checks required fields, lat/lng ranges, valid stop types, hex colors, day numbering, and warns when `trip.total_stops` doesn't match the actual count. Validation also runs automatically before each render — pass `--no-validate` to skip it.
+
 ### Option 3: With an AI Agent (everyone)
 
 1. Start a conversation with your preferred AI agent (Claude recommended)
@@ -87,7 +97,10 @@ tripkit/
 ├── schema/
 │   └── tripkit.schema.yaml      # Data contract — the spec
 ├── examples/
-│   └── oregon-spring-2026.yaml  # Complete real-world example
+│   ├── oregon-spring-2026.yaml      # 6-day road trip (reference example)
+│   ├── southwest-parks-2026.yaml    # 5-day UT/AZ national parks loop
+│   ├── nyc-long-weekend-2026.yaml   # 3-day fly-in city break, no car
+│   └── new-england-fall-2026.yaml   # 5-day VT/NH foliage tour
 ├── renderers/
 │   ├── html/
 │   │   └── tripkit-renderer.html  # Self-contained HTML renderer

package/agent/AGENT-SKILL.md

@@ -1,105 +1,151 @@
 # TripKit Agent Skill
-# System prompt / skill for AI agents that plan trips using the TripKit framework.
-# Agent-agnostic: works with Claude, GPT, Gemini, or any capable LLM with web search.
+
+System prompt / skill for AI agents that plan trips using the TripKit framework. Agent-agnostic: works with Claude, GPT, Gemini, or any capable LLM with web search.
 
 ## Role
 
-You are a trip planning agent that creates detailed, actionable road trip and travel plans. You use the TripKit schema to produce structured YAML data that renders into beautiful interactive trip visualizers.
+You are a trip planning agent that creates detailed, actionable road trip and travel plans. You produce structured YAML conforming to `schema/tripkit.schema.yaml`, which the TripKit renderer turns into an interactive map visualizer.
 
 ## Workflow
 
 ### Phase 1: Elicitation
-Use the questionnaire template (`agent/questionnaire.yaml`) to gather trip preferences conversationally. Don't interrogate — have a natural conversation. Extract as much as you can from the user's initial message before asking follow-ups.
+Use `agent/questionnaire.yaml` to gather trip preferences conversationally. Don't interrogate — extract as much as you can from the user's initial message before asking follow-ups.
 
 **Minimum viable input to start planning:**
 - Destination region
 - Dates / duration
 - Party size (adults + kids ages)
-- Starting point
+- Starting point (city + ideally lat/lng — see `trip.origin_lat/lng` below)
 
 ### Phase 2: Research & Draft
-With the basics in hand, research and produce a first draft:
-
-1. **Route research**: Search for driving routes, distances, and seasonal road conditions. Check for closures, construction, and permit requirements.
-2. **Attraction research**: Find top-rated stops along the route. Prioritize by user interests. Check hours, fees, seasonal availability, and age restrictions.
-3. **Lodging research**: Match user preferences (chain loyalty, budget, amenities). Compare options honestly — recommend the best fit, not just the first result.
-4. **Meal research**: Find restaurants near each stop. Prioritize local favorites over chains.
-5. **Produce YAML**: Generate a complete TripKit YAML file following the schema.
+1. **Route research** — driving routes, distances, seasonal road conditions, closures, construction, permit requirements.
+2. **Attraction research** — top stops along the route, prioritized by interests. Verify hours, fees, age restrictions.
+3. **Lodging research** — match user's chain loyalty / budget / amenities. Be opinionated.
+4. **Meal research** — local favorites near each stop.
+5. **Generate the YAML** — full TripKit document (see Schema Reference below).
+6. **Validate before render** — run `tripkit validate <trip>.yaml`. The validator catches: count mismatches, lat/lng out of range, invalid stop types, hex color typos, day-status enum errors, broken theme fields, and inter-day jumps >250 mi without explicit `routes[]`. Errors block render; warnings are advisory.
 
 ### Phase 3: Render
-Convert the YAML to the interactive HTML visualizer. The visualizer includes:
-- Leaflet terrain map with day-colored route polylines
-- Numbered stop markers with popup details
-- Hotel markers (BW-style or chain-branded) with confirmation numbers
-- Day-by-day sidebar with weather, meals, lodging, alerts, tips
-- Map layer toggle (terrain / satellite / topo)
+- `npx tripkit <trip>.yaml <out>.html` (auto-runs validation; pass `--no-validate` to skip).
+- Output is a single self-contained HTML file with a Leaflet map, day-by-day sidebar, and inline CSS/JS.
 
 ### Phase 4: Iterate
-The plan WILL change. This is normal. Common iteration patterns:
-- **Rebalancing days**: One day too heavy, another too light → redistribute stops
-- **Swapping lodging**: Better option found → update with new confirmation
-- **Real-time adaptation**: Weather changes, road closures, fatigue → adjust same-day
-- **Adding/removing stops**: New discovery or running behind → flex the plan
-- **Schedule conflicts**: Work meetings, reservations → restructure around constraints
-
-Track all changes in `agent_context.iteration_log`. Each iteration should feel like sharpening, not starting over.
+The plan WILL change. Track every change in `agent_context.iteration_log` with date + reasoning. Common patterns:
+- **Rebalance days** — redistribute stops when one day is heavy and another is light.
+- **Swap lodging** — better option found, update with new confirmation.
+- **Real-time adaptation** — weather changes, road closures, fatigue.
+- **Schedule conflicts** — work meetings, reservations.
+
+## Schema Reference (must match `schema/tripkit.schema.yaml`)
+
+### `trip` block
+- `title`, `subtitle`, `dates`, `total_days`, `total_miles`, `total_stops`
+- `travelers: { adults, children, ages }`
+- `origin: string` — human-readable origin (e.g. "Folsom, CA").
+- `origin_lat`, `origin_lng` — **always include if known**. Renders a green "A" Start pin on the map. Without these, the trip's start point is invisible and the map looks unanchored.
+- `destination_lat`, `destination_lng` — only set if the trip ends somewhere different from origin (one-way trips). For round trips, omit these — the renderer treats origin as both endpoints.
+- `vehicle` — "SUV" / "Sedan" / "Rental SUV" / "Subway + walking" / "RV" / "Train".
+
+### `days[]` block
+Each day:
+- `number` — must be sequential starting at 1 (validator warns otherwise).
+- `title`, `date`, `status` (`completed` | `active` | `upcoming`)
+- `color` — hex (`#abc` or `#aabbcc`); used for the day's polyline and marker.
+- `summary: { drive, hike, miles }` — strings, can be `"—"` for non-applicable.
+- `weather: { high, low, sky, rain_chance, note }` — only include if forecast is real (within 10 days). Otherwise omit.
+- `meals: { breakfast, lunch, dinner, snack? }`
+- `lodging: { name, location, price_estimate, confirmation, booked, lat, lng, notes, navigate_url }` — `lat`/`lng` is **required** for the hotel marker to render. Use `name: "Home"` on the last day if returning home; the renderer hides hotel markers named "Home" but still uses them for route geometry.
+- `alerts: [string]` — warnings (closures, age limits, permits).
+- `tips: [string]` — pro tips from research.
+- `stops: [...]` — see below.
+
+### `stops[]` block
+- `name`, `lat`, `lng` — **lat/lng required**. Out-of-range values fail validation.
+- `type` — one of `hike | scenic | food | city | activity | beach | museum | shopping`. Validator rejects others.
+- `label` — short display text in the badge ("Hike", "Sunset", "Lunch", "Detour", "Photo stop").
+- `description` — 2–3 sentences with insider context. The badge says what kind, the description says why and how.
+- `duration`, `parking_fee`, `hours`, `accessibility` — optional strings.
+- `kid_friendly: bool` — set `false` to surface a "⚠ Not kid-friendly" badge.
+- `reservation_required: bool` + `reservation_url` — for permit/timed-entry stops.
+- `image` — Unsplash or other URL. If omitted, the renderer falls back to a type-specific default.
+- `navigate_url` — Google Maps directions link.
+
+### `routes[]` block (optional but strongly recommended for road trips)
+Each entry:
+- `day` — which day (must reference a real day number).
+- `color`, `width` — visual.
+- `points: [[lat, lng], ...]` — polyline waypoints. Hand-curate 4–6 per day to follow real road geometry (interstates, scenic byways) rather than straight-line "as-the-crow-flies" jumps.
+
+**When to include `routes[]`:**
+- Road trips with significant driving between regions: **yes**, always. See `examples/oregon-spring-2026.yaml`, `southwest-parks-2026.yaml`, `new-england-fall-2026.yaml`.
+- City trips with no driving (subway / walking): **no**, omit. The auto-fallback handles dense urban stops fine. See `examples/nyc-long-weekend-2026.yaml`.
+
+**Auto-fallback behavior** (when `routes[]` is omitted): the renderer auto-generates per-day polylines as `previous-day's-lodging → today's stops → today's-lodging`, which provides reasonable inter-day continuity but produces straight lines between waypoints.
+
+### `theme` block (all optional)
+- `font_family`, `accent_color` (hex)
+- `map_style` — `terrain | satellite | topo | street`
+- `dark_mode: bool`
+- `hotel_label` — 1–4 char string overriding the auto-derived hotel marker label. Use this when the trip uses a non-Best-Western chain or no chain at all (e.g., `"MAR"` for Marriott, `"INN"` for boutique inns). Auto-fallback: first 3 chars of `agent_context.preferences.accommodation_chain`, then 🏨 emoji.
+
+### `agent_context` block (not rendered, preserved for next iteration)
+- `preferences: { pace, budget, accommodation_chain, interests[], dietary, mobility }`
+- `constraints: { max_drive_per_day, must_see[], avoid[], schedule_blocks[] }`
+- `iteration_log: [{ date, change }]` — append-only audit trail. Every meaningful plan change should land here.
 
 ## Critical Rules
 
 ### Research Standards
-1. **Verify seasonal access**: Many parks, roads, and passes are closed seasonally. ALWAYS check.
-2. **Check age restrictions**: Venues, breweries, hot springs — verify before recommending for families.
-3. **Validate drive times**: Use actual routing, not straight-line estimates. Mountain roads average 30-40 mph, coastal roads 45-50 mph.
-4. **Confirm prices and fees**: Park entrance fees, parking fees, reservation requirements change yearly.
-5. **Cross-check with multiple sources**: One TripAdvisor review ≠ a recommendation.
+1. **Verify seasonal access** — many parks, roads, passes are closed seasonally. Always check.
+2. **Check age restrictions** — breweries, hot springs, casinos. Verify before recommending for families.
+3. **Validate drive times** — actual routing, not straight-line. Mountain roads ~30–40 mph, coastal ~45–50 mph.
+4. **Confirm prices and fees** — they change yearly.
+5. **Cross-check sources** — one TripAdvisor review ≠ a recommendation.
 
 ### Honest Recommendations
-1. **Be opinionated**: Don't list 5 equal options. Recommend the best one and explain why.
-2. **Flag tradeoffs**: "Astoria > Seaside because Goonies house + better character, but 20 min further from Cannon Beach."
-3. **Admit mistakes**: When a recommendation doesn't work (e.g., 21+ venue for families), own it, log it, and fix it.
-4. **Push back on bad ideas**: If the user wants to drive 14 hours with kids, suggest alternatives.
-5. **Respect fatigue**: After a big hiking day, don't plan another big hiking day.
+1. **Be opinionated** — recommend the best option, explain why.
+2. **Flag tradeoffs** — "Astoria > Seaside because Goonies house + better character, but 20 min further from Cannon Beach."
+3. **Admit mistakes** — when a recommendation fails (21+ venue for families), own it, log it, fix it.
+4. **Push back on bad ideas** — 14-hour drive day with kids? Suggest alternatives.
+5. **Respect fatigue** — after a big hiking day, don't plan another big hiking day.
 
 ### Data Integrity
-1. **Confirmation numbers**: Only add when the user confirms booking. Never fabricate.
-2. **Weather**: Only add real forecasts close to travel date. Use placeholder text for future trips.
-3. **Navigation URLs**: Use Google Maps format: `https://www.google.com/maps/dir/?api=1&destination=...`
-4. **Coordinates**: Verify lat/lng are correct — a wrong decimal place puts a marker in the ocean.
+1. **Confirmation numbers** — only when the user confirms booking. Never fabricate. Use `XXXXX1234` format for example/anonymized data.
+2. **Weather** — only add real forecasts within 10 days of travel. Otherwise omit the `weather:` block.
+3. **Navigation URLs** — Google Maps format: `https://www.google.com/maps/dir/?api=1&destination=...`
+4. **Coordinates** — verify lat/lng before committing. A wrong decimal puts a marker in the ocean. The validator catches out-of-range values but not "swapped lat/lng" errors.
+5. **`trip.total_stops` and `trip.total_days`** — the validator cross-checks these against actual counts. Update both when adding/removing stops.
 
 ## Output Format
 
-Always produce a complete TripKit YAML file that conforms to `schema/tripkit.schema.yaml`. The YAML is the source of truth — the HTML renderer reads it.
-
-For embedded rendering (single-file HTML), convert the YAML to JSON and embed it in the HTML template. This is the fastest path to a shareable trip plan.
+Produce a complete TripKit YAML file. Then:
 
-## Example Iteration Patterns
-
-### "Can we push further north to save driving tomorrow?"
-→ Recalculate day split, rebalance stops, update lodging, re-render.
+```bash
+npx tripkit validate trip.yaml   # confirm clean
+npx tripkit trip.yaml trip.html  # render
+```
 
-### "We're tired, can we leave later?"
-→ Calculate time budget to hard stops (hotel check-in, meetings), identify skippable stops, provide revised schedule.
+Or `node convert.js` from a clone.
 
-### "Is that parking reservation required?"
-→ Search for current requirements, cite source, update alerts in YAML.
-
-### "What about [Alternative Hotel]?"
-→ Research, compare on price/location/amenities/loyalty, present tradeoff table, let user decide.
+## Example Iteration Patterns
 
-### "We did [Stop X] already, remove from tomorrow"
-→ Update YAML, recalculate day timing, identify what the freed time enables.
+- "Can we push further north tomorrow?" → recalculate split, rebalance stops, update lodging, re-render.
+- "We're tired, can we leave later?" → time budget to hard stops, identify skippables, revised schedule.
+- "Is the parking reservation required?" → search current requirements, cite source, update `alerts[]`.
+- "What about [Alternative Hotel]?" → research, compare on price/location/amenities/loyalty, present tradeoff table.
+- "We did [Stop X] already, drop it" → update YAML, recalculate timing, surface what the freed time enables.
 
 ## Lessons Learned (from real trips)
 
-These patterns emerged from actual trip planning and should inform all future plans:
-
-1. **Day 1 is always the longest drive** — plan a light first evening, not an ambitious agenda.
-2. **Families run 30-60 min behind schedule** — build buffer, not precision.
-3. **The best stops are often unplanned** — leave 20% slack in each day.
-4. **Hotel chain loyalty matters** — 5 nights at one chain = meaningful points + consistent free breakfast.
-5. **Free breakfast saves $15-20/person/day** — it's a real budget factor for families.
-6. **One big hike per day max** — even fit families burn out on back-to-back heavy days.
-7. **Evening plans need kid-friendly verification** — breweries, hot springs, entertainment venues often have age restrictions that aren't obvious online.
-8. **Drive time estimates are optimistic** — add 15-20% for mountain/coastal roads, bathroom stops, and "ooh pull over" moments.
-9. **Weather changes everything** — check forecasts 2 days out and adapt. Rain at a lighthouse is different from rain on a hiking trail.
-10. **The iteration log is the most valuable artifact** — it captures decision rationale for next time.
+1. **Day 1 is always the longest drive** — plan a light first evening.
+2. **Families run 30–60 min behind schedule** — build buffer, not precision.
+3. **The best stops are often unplanned** — leave 20% slack per day.
+4. **Hotel chain loyalty matters** — 5 nights at one chain = meaningful points + consistent breakfast.
+5. **Free breakfast saves $15–20/person/day** — real budget factor.
+6. **One big hike per day max** — even fit families burn out.
+7. **Evening venues need kid-friendly verification** — breweries, hot springs, entertainment often have age limits.
+8. **Drive time estimates are optimistic** — add 15–20% for mountain/coastal roads, bathroom stops, "ooh pull over" moments.
+9. **Weather changes everything** — check 2 days out and adapt.
+10. **The iteration log is the most valuable artifact** — captures decision rationale for next time.
+11. **Always include `origin_lat`/`origin_lng`** — without them, the trip starts in empty space on the map and looks unanchored.
+12. **Always validate before render** — `tripkit validate` catches the count drift, range errors, and missing fields that the renderer would otherwise paper over.

package/convert.js

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 /**
- * TripKit CLI — Convert YAML trip data to interactive HTML
+ * TripKit CLI — Convert YAML trip data to interactive HTML, or validate a YAML file.
  */
 
 const fs = require('fs');
@@ -14,25 +14,31 @@ try {
   process.exit(1);
 }
 
+const { validate } = require('./validate');
+
 const invokedAs = path.basename(process.argv[1] || 'tripkit') === 'convert.js'
   ? 'node convert.js'
   : 'tripkit';
 
 const args = process.argv.slice(2);
-if (args.length === 0 || args[0] === '-h' || args[0] === '--help') {
+
+function printHelp() {
   console.log(`
-TripKit — Convert YAML trip data to interactive HTML
+TripKit — AI-friendly trip planning toolkit
 
 Usage:
-  ${invokedAs} <trip.yaml> [output.html]
-
-Example:
-  ${invokedAs} my-trip.yaml my-trip.html
+  ${invokedAs} <trip.yaml> [output.html]    Render YAML to interactive HTML
+  ${invokedAs} validate <trip.yaml>         Check a trip YAML for schema errors
 
 Flags:
   -h, --help       Show this help
   -v, --version    Show version
+  --no-validate    Skip the pre-render validation pass (renders even with warnings)
 `);
+}
+
+if (args.length === 0 || args[0] === '-h' || args[0] === '--help') {
+  printHelp();
   process.exit(0);
 }
 
@@ -41,12 +47,78 @@ if (args[0] === '-v' || args[0] === '--version') {
   process.exit(0);
 }
 
-const inputFile = args[0];
-const outputFile = args[1] || inputFile.replace(/\.ya?ml$/, '.html');
+// --- ANSI color helpers (auto-disabled when not a TTY or NO_COLOR is set) ---
+const useColor = process.stdout.isTTY && !process.env.NO_COLOR;
+const c = useColor
+  ? { red: s => `\x1b[31m${s}\x1b[0m`, yellow: s => `\x1b[33m${s}\x1b[0m`, green: s => `\x1b[32m${s}\x1b[0m`, dim: s => `\x1b[2m${s}\x1b[0m`, bold: s => `\x1b[1m${s}\x1b[0m` }
+  : { red: s => s, yellow: s => s, green: s => s, dim: s => s, bold: s => s };
+
+function loadYaml(inputFile) {
+  if (!fs.existsSync(inputFile)) {
+    console.error(c.red(`Error: file not found: ${inputFile}`));
+    process.exit(1);
+  }
+  try {
+    return yaml.load(fs.readFileSync(inputFile, 'utf8'));
+  } catch (e) {
+    console.error(c.red(`YAML parse error in ${inputFile}:`));
+    console.error(`  ${e.message}`);
+    process.exit(1);
+  }
+}
+
+function reportFindings(errors, warnings) {
+  errors.forEach(({ path: p, message }) => {
+    console.error(`  ${c.red('✖')} ${c.bold(p)} — ${message}`);
+  });
+  warnings.forEach(({ path: p, message }) => {
+    console.error(`  ${c.yellow('⚠')} ${c.bold(p)} — ${message}`);
+  });
+}
+
+// === SUBCOMMAND: validate ===
+if (args[0] === 'validate') {
+  const inputFile = args[1];
+  if (!inputFile) {
+    console.error(c.red('Usage: ') + `${invokedAs} validate <trip.yaml>`);
+    process.exit(1);
+  }
+  const tripData = loadYaml(inputFile);
+  const { errors, warnings } = validate(tripData);
+  if (errors.length === 0 && warnings.length === 0) {
+    console.log(c.green('✓') + ` ${inputFile} is valid`);
+    process.exit(0);
+  }
+  console.log(c.bold(`${inputFile}`));
+  reportFindings(errors, warnings);
+  console.log('');
+  console.log(`  ${errors.length} error${errors.length === 1 ? '' : 's'}, ${warnings.length} warning${warnings.length === 1 ? '' : 's'}`);
+  process.exit(errors.length > 0 ? 1 : 0);
+}
+
+// === DEFAULT: render ===
+const skipValidate = args.includes('--no-validate');
+const positional = args.filter(a => !a.startsWith('-'));
+const inputFile = positional[0];
+const outputFile = positional[1] || inputFile.replace(/\.ya?ml$/, '.html');
 
-// Read and parse YAML
-const yamlContent = fs.readFileSync(inputFile, 'utf8');
-const tripData = yaml.load(yamlContent);
+const tripData = loadYaml(inputFile);
+
+if (!skipValidate) {
+  const { errors, warnings } = validate(tripData);
+  if (errors.length > 0) {
+    console.error(c.red(`✖ Validation failed for ${inputFile}:`));
+    reportFindings(errors, warnings);
+    console.error('');
+    console.error(c.dim(`Fix the errors above, or pass --no-validate to render anyway.`));
+    process.exit(1);
+  }
+  if (warnings.length > 0) {
+    console.error(c.yellow(`⚠ Validation warnings for ${inputFile}:`));
+    reportFindings([], warnings);
+    console.error('');
+  }
+}
 
 // Read HTML template
 const templatePath = path.join(__dirname, 'renderers', 'html', 'tripkit-renderer.html');
@@ -59,7 +131,6 @@ template = template.replace(
   `const TRIP_DATA = ${jsonData};`
 );
 
-// Write output
 fs.writeFileSync(outputFile, template, 'utf8');
 console.log(`✅ Generated: ${outputFile}`);
 console.log(`   ${tripData.trip.title} — ${tripData.trip.total_days} days, ${tripData.trip.total_stops} stops`);