Plan Gacha is a component for travel planning and records, operated by an AI assistant. Users express travel intent, supply conditions, and report changes in conversation. The assistant reads the journey, researches information, proposes adjustments, and explains results; the component provides journey state, rule checks, change previews, persistence, and history recovery.
On October 8, 2026, the project changed from a standalone travel app to a journey component operated through AI. Development continues. The old standalone web deployment on this site has been taken down, and its complete source is archived at legacy-web-final.

Journey operations in conversation
The AI host interprets intent, researches opening hours and reservation requirements, selects operations, and explains tradeoffs. It uses its existing tools to access private data, external services, and storage. The component does not embed a general AI model. Its core runs offline; map, weather, account, and order queries depend on the host’s tools and permissions.
An adjustment starts by reading the latest version of the same authoritative journey. The assistant turns intent into an explicit operation, checks affected activities, reservations, lodging, and constraints, then presents a change preview. Within the user’s authorization, the component saves local journey files with version checks. For external storage such as Library, the host replaces the same file with a native version check and verifies the result by reading it back. A candidate from stage does not itself establish successful external persistence.
Component capabilities
- Journeys and constraints: retain the original plan, current schedule, and user-reported actual events separately; insert, remove, move, reorder, and edit activities. Date, closure, conflict, weather, and candidate rules assess adjustments while protecting booked, locked, confirmed, or completed arrangements.
- Sourced records: keep facts, preferences, commitments, evidence, decisions, change reasons, and open issues in the same journey. Forecasts, final information, and actual reports remain distinct. Reservations and planned events do not establish completion.
- History and recovery: changes carry versions, preview tokens, idempotent receipts, and reasons. The component supports undo of the latest change, storage migration, and explicit adoption of recoverable history checkpoints. Older full states may require a prior version.
- Experience review: link firsthand observations, adjustment reasons, outcomes, and evaluations to the original journey and history; search explicitly supplied journeys and produce guide drafts for review.
- Read-only views: derive daily content, current and historical routes, night-dated lodging, and trip summaries from the authoritative journey for host pages or reports. The host handles view refresh and authoritative persistence separately.
Rule analysis identifies known conflicts and unknowns; it cannot prove that a real journey is feasible. Decision deadlines and reminder reconciliation produce advice or action descriptions. The host must separately execute and verify notifications, ticket purchases, bookings, cancellations, and refunds.
Current integration options
| Entry point | Use |
|---|---|
tripctl CLI | The full journey interface for an AI operator: schema discovery, reading, analysis, preview, persistence, and recovery. |
tripctl-lib.mjs / TypeScript library | Direct access to the same core, schemas, file store, and presentation interfaces. |
| Operator skill | Intent handling, proactive research, sources, uncertainty, authorized persistence, and readback workflow. |
| stdio MCP | Four stateless snapshot tools: get_context, evaluate_plan, rank_candidates, and preview_changes. The caller supplies data; tools return analysis or candidates without saving a journey. |
Source usage requires Node.js >=22.13. npm run build produces the portable CLI/library. dist/tripctl includes runtime files, the operator skill, contract documents, and synthetic examples; it runs without installing dependencies. See the README and CLI documentation for setup and operations.
Legacy web app and data handoff
This site no longer serves the React web app, its browser sync, or its PWA entry point. The annotated legacy-web-final tag preserves the web source, JSON import and export, browser storage, and sync adapter. The archive is also available on GitLab. To inspect or run it, check out the tag in a separate directory and follow its instructions.
Legacy data normally lives in the original browser and origin’s localStorage. CLI/MCP tools do not read it automatically, and taking down the deployment does not migrate personal data. Export explicitly from the original environment and retain the original backup, then prepare input against the actual schema, preview it, and review the save. Trip exports exclude standalone checklists and weather caches; a complete workspace backup includes all trips and checklists. A fresh checkout of the archived web app also cannot automatically read the original browser and origin’s data.
The component still provides read-only presentation interfaces for hosts. The old web app’s driveStorage adapter is a historical sync implementation. The current operator workflow requires the host to perform version-checked external persistence and readback; this project page does not store journeys.