# Plan Gacha

A local-first travel plan-pool tool for preparing main, backup, rainy-day and cross-city plans, then switching by weather, closures, bookings and energy during the trip.

## Metadata

- HTML: https://glenzli.com/en/projects/plan-gacha/
- Markdown: https://glenzli.com/en/projects/plan-gacha.md
- Collection: Projects
- Language: en
- Published: 2026-07-04
- Status: active
- Tags: travel, planner, weather, checklist, local-first

## Content

Plan Gacha is a lightweight tool for switching travel plans dynamically during a trip. It is designed for trips where you prepare `n + m` candidate plans in advance, then decide each day based on weather, closures, reservations, energy level, and last-minute changes.

Instead of locking the trip into one timeline, it lets main plans, backups, rainy-day options, and cross-city routes live in the same plan pool. During the trip, you choose the better-fit plan for the current day. Data is stored in browser `localStorage` by default, and the current version is a frontend-only app with no backend dependency; a deployment host may optionally inject a remote-storage adapter.

## Project Entry

  ![Plan Gacha project banner](/images/projects/plan-gacha-banner.png)

Open the deployed app here: [/apps/plan-gacha/](/apps/plan-gacha/?lang=en).

## What It Solves

    **Build a plan pool before departure**
    Main plans, backups, rainy-day options, and cross-city routes can live together without being locked into one timeline.

    **Switch by day during the trip**
    After checking weather, bookings, and energy level, pick the better-fit plan for the next day.

    **Avoid broken itineraries**
    Before switching, the app warns about date limits, bad weather, unscheduled must-go plans, and incomplete bookings.

    **Give AI an executable format**
    Let AI generate, supplement, or replan the itinerary, then paste JSON back into the app.

## Core Features

      **Multi-trip management**
      Create, delete, archive, restore, import, and download JSON exports, or load an example to explore the full feature set.

    Archived trips remain viewable from the editor but stay out of the top trip switcher, which makes them useful for keeping travel history.

      **Daily itinerary view**
      Mobile has compact date navigation; desktop has a left date list and central detail view.

    During the trip, the main loop is daily: update weather, inspect candidates, select a plan, and handle impacted later dates when needed.

      **Trip lifecycle and closing archive**
      The app prioritizes an ongoing, upcoming, or recently completed trip, then prompts for archiving after its end date.

    Archiving can optionally capture currency, categorized expenses, and a short reflection. Archived views show the total, breakdown, and trip note. When no trip is relevant to the current period, the app presents a clear empty state instead of reopening an old itinerary.

      **Candidate plan pool**
      Each plan can include multiple places, timed stops, cross-city routes, reminders, tips, reservations, and tickets.

    Plans can declare allowed dates, unavailable dates, weather blocks, preferred weather, must-go flags, and assigned dates.

      **Trip outcomes and historical boundaries**
      Record a whole day or one stop as skipped for this trip, or exclude a place from future planning.

    The original plan remains available in exports and read-only archives. Completed past plans no longer reappear on later dates, while historical corrections can still replan forward from the selected date.

      **Daily trip reviews**
      Completed days can record satisfaction, pacing and energy tags, plus a short note.

    Each review stays tied to its date and the plan used at the time. Replanning that day later does not overwrite the original feedback, so the trip can be reviewed against what actually happened.

      **Weather linkage and constraint checks**
      The app checks Open-Meteo weather by city, district, or coordinates, then evaluates plan suitability.

    Before selecting a plan, the app checks whether it affects later days and leaves impacted dates for the user to replan.

      **Bookings and trip checklist**
      Booking and ticket status remain manual; the checklist is maintained as standalone long-term data.

    The checklist starts empty, can be edited manually, filled from an example or imported from JSON, and supports done/skipped state plus one-click status reset.

## How To Use

1. Create a trip and set the start date and number of days.
2. Build the candidate pool from `AI Generate Plan Pool`, imported JSON, or the full example.
3. Before departure, add must-go plans, backups, rainy-day options, cross-city routes, bookings, reminders, and tips.
4. During the trip, open the current day and choose a plan based on weather, date limits, and assigned status.
5. If a choice moves or clears existing assignments, the app shows an impact preview before applying it.
6. After the trip, archive it and optionally record categorized expenses and a short reflection.

Candidates are grouped into three sections:

- `Ready to select`: available for the current date and not assigned elsewhere.
- `Scheduled elsewhere`: already assigned to another date, but can be moved here.
- `Unavailable`: blocked by hard limits such as date restrictions or closures.

Weather-unsuitable plans remain selectable. The button uses risk color so the user can make a local judgment; hard date limits and closures stay disabled.

## AI Workflow

The app does not directly call a general-purpose AI API. The reason is product quality: travel planning usually depends on the broader tool stack inside AI products, such as maps, search, and location understanding. Connecting only a bare model API can produce a weaker result, while rebuilding that surrounding system is unnecessary for a planning tool.

Current AI features use a copy-prompt, external-AI, paste-JSON workflow:

- `AI Generate Plan Pool`: create a full plan from an empty trip, or add candidates to an existing trip.
- `AI Edit Single Plan`: add or modify one concrete plan.
- `AI Replan`: rearrange the remaining trip based on remaining days, weather, and completed plans.

Prompts are scoped to the task. Initial or incremental planning includes the plan-pool JSON structure, existing plan IDs, and the user's extra request. Single-plan editing includes only the current plan or existing plan IDs. Replanning includes fixed dates, adjustable dates, remaining plans, weather, and warnings, then asks AI for an importable result.

Recorded daily reviews are passed into AI editing and replanning only as soft preferences for pacing, energy, transport, and weather. They never become place blacklists or other hard constraints automatically.

## Weather Data

Weather lookup uses the free [Open-Meteo](https://open-meteo.com/) API. The app caches weather locally by location and date range to avoid repeated short-interval requests for the same city or district.

For better lookup reliability, each plan should include a city, district, or coordinates. The UI can still display the specific place, while weather lookup uses the more stable location metadata.

Weather evaluation combines weather type, precipitation probability, and whether a plan is mainly indoor or outdoor:

- `31-50%` precipitation probability: outdoor plans are usually marked as weather-is-okay / not ideal.
- `51%+` precipitation probability: primarily outdoor plans are marked weather-unsuitable.
- `70%+` precipitation probability: rain risk is considered even when the weather code is ambiguous.
- Heavy rain or storms: outdoor plans are high risk; indoor plans are usually unaffected.

Weather lookup prioritizes `location.weather_location`, city, district, or coordinates. Scenic spot names can fail or be unstable.

## Data And Import/Export

- Data is stored in browser `localStorage`; there is no built-in account system or cloud service. A deployment host may provide the optional remote-sync adapter described below.
- `127.0.0.1:5173` and `localhost:5173` are different browser origins, so their local data is separate.
- Trip export downloads a JSON file containing dates, lodgings, the plan pool, schedule, place feedback, actual trip outcomes, daily reviews, and the archive summary. It excludes the checklist and weather cache; import supports pasted JSON or a local JSON file.
- Weather results are stored only as local browser cache. They are not written to trip export JSON or remote sync files.
- The checklist is global standalone data. It can be downloaded separately as JSON, then imported by pasting JSON or selecting a file, with replace and merge modes.
- During checklist merge, same category plus same text is treated as the same item. Same text in a different category migrates clear status matches and reports a conflict.
- Repeated same-text items or status disagreements do not overwrite the current checklist automatically; the app reports them for cleanup before re-importing.
- The current sync-file schema is `appSchemaVersion: "1.0"`; compatible field additions, UI changes and sync-strategy changes do not bump the schema. Only breaking data-shape changes should.

## Optional Remote Sync

Plan Gacha does not bind itself to a specific remote storage provider. A host page can inject a minimal `driveStorage` adapter to sync a complete workspace snapshot containing trips, schedules, review state, and the checklist. Weather cache data is never uploaded.

By default, the sync entry appears only when the URL includes `?sync=1`, or when the browser already remembers a synced file; the host must also provide the `driveStorage` API, otherwise the entry stays hidden. In this site, that capability is provided by the outer app page, while Plan Gacha remains a frontend-only application.

On first sync, the app locates `plan-gacha.state.json` by file name and application marker. Empty local state can pull remote directly; non-empty local state asks for confirmation; a new file is created only when no match exists. Conflicts can be resolved by taking remote, taking local, or attempting an automatic merge. Incompatible schemas, invalid remote JSON, and simultaneous edits to the same data are reported explicitly.