Travel Scheduler

Mobile-first trip platform with three screens under one App Bar — /discover (browse), /planner (map + drag-and-drop daily timeline), /scrapbook (saved trips) — plus a / home dashboard that fans out into all three.

Stack

• Next.js (App Router) + TailwindCSS
• Zustand — itinerary state (src/store/itineraryStore.ts)
• React Query — trending-places & shared-itinerary polling (src/lib/api.ts)
• @react-google-maps/api — /planner's live map (src/app/(app)/planner/MapProvider.tsx)
• shadcn/ui (hand-authored, see below) + framer-motion for the /discover//scrapbook/home screens

Getting started

npm install
npm run dev

Open http://localhost:3000 — this is now the home dashboard, linking out to /discover, /planner, and /scrapbook. Without NEXT_PUBLIC_GOOGLE_MAPS_API_KEY set, /planner's map area shows a clean "Failed to load Google Maps" state, but every other interaction (scheduling, search, trend sheet, budget, route optimization) still works end to end. Copy .env.example to .env.local and set the relevant keys:

• NEXT_PUBLIC_GOOGLE_MAPS_API_KEY → real Google Maps in /planner
• GOOGLE_PLACES_API_KEY → real results for the legacy /api/trends + /api/places/search pipeline endpoints (see below) instead of offline fixtures — no current screen calls these directly, /planner's own search/trend sheet use separate, screen-local implementations instead (see the Phase 4 section further down)

Google API 사용처(프로젝트 ↔ API ↔ 환경 변수 ↔ 호출 지점 ↔ 월 무료 한도 가드)는 docs/GOOGLE_APIS.md 에 있다 — Google API 호출을 추가·변경하는 PR 은 이 문서도 같이 고친다.

Interactions (/planner)

• Tap a pin → time/date picker modal → Register Schedule.
• Press and hold a pin (~0.5s) → the pin lifts → drag it onto an hour slot in the timeline to schedule it there.
• ✨ Trending spots button opens a bottom sheet with curated spots plus a search box; tapping a result opens the same time-picker modal.

Trend data pipeline

This was the international trend source for the very first version of this app (a single / page, since replaced by the /discover+/planner+ /scrapbook platform below — see the "Drawer-based routing split" and "design merge" sections for how that happened). The pipeline itself, and the /api/trends + /api/places/search routes it backs, are kept as-is: still fully runnable, just not currently called by any screen's UI.

src/server/pipeline/ implements the zero-cost trend data flow described in the spec: mock SNS scrape → regex ad-filter (drops 협찬/소정의 원고료/ 디너의여왕, keeps 내돈내산/영수증 리뷰) → LLM authenticity check → Google Places (New) searchText resolution with a minimal field mask → JSON DB write. Run it with:

npm run pipeline

This writes data/trending-places.json, which src/lib/server/getTrendingPlaces.ts serves via /api/trends, so the app never calls a paid Places API on a user request — only the offline pipeline run does. Without GOOGLE_PLACES_API_KEY / LLM_API_KEY set, the pipeline resolves against small offline fixtures so it's fully testable here; in production point it at real credentials and run it on a schedule (cron / GitHub Actions / Vercel Cron).

Swapping the JSON file for Postgres/Supabase only touches two files: src/server/pipeline/db.ts (write) and src/lib/server/getTrendingPlaces.ts (read). The domestic list is a Phase-4 mockup per spec (더미 데이터); wire it to a real Naver blog/Place pipeline the same way when needed.

Data model

itineraryState (Zustand) holds one flat array of:

{ id, placeId, name, date, time, coordinates: { lat, lng } }

Auth & saved itineraries (Phase 1.5)

Browsing the trend list and drag-and-drop planning both work fully signed-out — the login modal only appears at the moment you tap 저장 (save) or 공유 (share), per spec.

• Auth: Auth.js v5 (next-auth@beta) with Google/Kakao/Apple providers. A provider is only registered once its AUTH_<PROVIDER>_ID env var is set (src/auth.ts), so a partially-configured setup doesn't break.
• DB: PostgreSQL via the pure-JS pg driver + @auth/pg-adapter, not Prisma — retried three times now, same result every time: this sandbox's network policy lets pg/npm traffic through a proxy, but Prisma's engine postinstall downloader dials binaries.prisma.sh directly (confirmed via NODE_DEBUG=https) and gets reset by the sandbox firewall every time, even though the exact same file downloads fine over the proxy with curl. pg has no native-binary install step, so it was used instead. Schema (src/server/db/schema.sql) is the standard Auth.js Postgres adapter tables (users, accounts, sessions, verification_token) plus one app table, itineraries (userId, title, region, placesData JSONB — holds the frontend's schedule array as-is). Run npm run db:migrate against DATABASE_URL to apply it. If your deployment environment can reach Prisma's binary CDN, swapping back to Prisma is a straightforward, isolated change — only src/lib/server/db.ts, src/auth.ts's adapter line, and the two pool.query call sites (src/app/api/itineraries/route.ts, src/app/share/[id]/page.tsx) touch the DB layer.
• Save: 저장 POSTs the current region + itinerary items to /api/itineraries, which upserts one row per user.
• Share: 공유 saves, then copies /share/{id} to the clipboard — a public, read-only page listing the trip's stops by date (src/app/share/[id]/page.tsx).

This is the beginning of the README. Read the rest at the original. Read the full README ↗