AI Travel Scout — known issues and manual setup

Things that need manual attention

Gmail API must stay enabled in Google Cloud project [google-cloud-project-id]. It was disabled and is now enabled. If the demo is rebuilt on a fresh OAuth client, enable Gmail API first.
Schedule Trigger is every minute and both workflows are left inactive after the test. For a live demo, activate AI Travel Scout — Monitor Ranking Gmail only while showing it, then deactivate, otherwise it re-sends every minute to whatever rows are due.
Form trigger field names: when testing via n8n MCP n8n_test_workflow, pass field-0 (email), field-1 (travel_description), field-2 (monitor_frequency). A human submitting the real hosted form uses the labels directly.

Design notes / limitations (acceptable for a training demo)

Test date fallback: when the user gives no concrete dates, Set: Prepare query params uses next Friday + parsed/default trip duration and flags it via query_fallback_note. These are clearly test dates, not asserted as user facts.
Single recipient guard: Gmail sends to user_email from the row. For the demo the only seeded row is the test address. There is no hard allowlist node; do not seed rows with non-test recipients before activating the monitor.
Monitor processes all due rows: Code: Add should_monitor_now returns rows where status=new (or interval elapsed). The preflight row (status=preflight_updated) is explicitly skipped. Add rows carefully.
OpenAI credential test in n8n UI was reported broken on an earlier version; the key works in execution (3 AI calls succeeded). Not a blocker.
No retry/backoff on SerpApi or Gmail beyond n8n defaults. Fine for demo, not production.
gpt-4.1-mini used for all three AI calls to keep cost low. Ranking/advisor quality is good enough for the demo.

Cost notes

Each full monitor run = 1 SerpApi call + 3 OpenAI calls (ranking, guide, advisor). Keep the monitor inactive except during a live demo to avoid per-minute spend.