ROOM FOR A CHANGE OF PLANS
How this works.
Pick what you enjoy. Get two days in Lisbon. See how a failed reservation changes the route, the schedule and the money.
- Review a plan and approve its quote.
- Authorize test money with a sandbox card or PayPal wallet.
- Hold bookings with the Simulated supplier.
- Make the hotel unavailable. Compare checked replacements and their schedule changes.
- Accept a repair. Void the old hold and approve a new one.
- Confirm the bookings, then capture the payment.
- A supplier cancels an activity. The slot is replanned and the price difference is refunded.
Who it is for.
A small tour operator sells a Lisbon weekend as one package, paid with one PayPal payment: a hotel, two airport cars, a tile painting class and a fado dinner. Two days before the trip, the hotel cancels. The cars were timed to that hotel and the class was picked because it was a short walk away.
RoamReprise is a prototype of the tool that operator would use. It compares the replacement hotels, recomputes the times that move, asks the traveler to approve the new price, and keeps the one package payment in step: the old hold is released without a charge, the new total is held, the money is captured only when every booking is confirmed, and a cancelled activity after payment becomes a partial refund.
What it covers today: one Lisbon weekend, simulated inventory, estimated travel times, and one demonstrated activity cancellation. Real supplier connections are future work. It does not import or repair bookings already bought from other sellers.
Real places. Simulated bookings.
Hotels, meals, activities and cars use local fixtures labelled “Simulated supplier.” No real travel is purchased. A confirmed booking here is a simulation.
Sandbox payments.
The live app sends authorization, void, capture and refund requests to PayPal sandbox. All money is test money. The server sets amounts from the approved quote. A changed plan needs new approval.
A lost response means “Checking payment.” Further payment writes wait while the server reads PayPal's state. A refund stays pending until PayPal reports completion.
The URL option ?mock=1 uses browser data and makes no PayPal or AI calls. Mock ids start with MOCK-. Recorded runs show saved evidence with a capture date and send no PayPal requests.
AI within a daily cap.
Workers AI can pick offers, a checked repair and changes you request before or during a hold, before capture. Code checks prices, times, availability and travel buffers. AI never sets payment fields.
At most 4 AI calls run per trip: one plan, one repair and up to two changes you ask for. Each reserves 15 neurons before it starts. This app's cap is 900 neurons per UTC day, allowing at most 60 such reservations. A shared account guard stops reservations at 9,500 neurons. The budget ledger must approve every call.
If the cap is used up, the ledger is unavailable, or the model gives invalid ids, the app uses a rule choice or a recorded answer for the default trip. The notebook labels each step as AI picked · code checked, AI pick (cached today, no new call), Recorded AI answer or Rule pick. Cached answers last 24 hours. Changes you request use a live answer or the rules, with no cached answer.
Tools behind the trip.
Plain JavaScript modules run the app. Three.js draws the dotted globe. Natural Earth land polygons are public domain. An original canvas sketch draws Lisbon routes.
The route sketch is drawn by the app; no map tiles are used.
Bryntum Scheduler shows two days, travel buffers and dependencies. Its trial watermark stays visible. A basic timeline works if the Scheduler cannot load. Cloudflare Workers, Durable Objects and D1 handle the server, trip state and shared usage ledger. PayPal sandbox handles test payments.