H1Trip Execution Bundle
Status: stage note for Trips execution
This note separates planning from fulfillment so booking does not get forced into the Trip Planner surface.
H2Locked model
Trip Planner stays planning-first.
It should produce:
- route
- services
- hotel policy outcome
- execution intent
It should not confirm live inventory inside the same flow.
H2Hotel rule
Hotel handling is derived, not promised.
- If
daysUntilStart > 40, hotel handling may use pre-blocked room inventory. - If
daysUntilStart <= 40, the trip becomes services-only and hotel section falls back to guidance plus external booking links. - Thirty days before trip start, release unsold blocked rooms from internal stock logic.
Derived field:
hotelPolicy =
| "managed_blocked_inventory"
| "estimate_only"
| "external_links_only"
H2Execution model
Recommended launch order:
- Manual operations
- Calendar-aware hybrid validation
- Full automation later
Core execution modes:
executionMode =
| "manual_ops"
| "calendar_checked_manual"
| "auto_booking_later"
H2BookingBundle
The execution layer should create a booking bundle separate from the planner.
BookingBundle {
tripId
status: "draft" | "pending" | "confirmed"
}
H2FareHarbor guidance
- Use links or manual dashboard operations first
- Use embedded widgets only where they are verified to work in the deployment environment
- Do not make widgets the backbone of the launch
- Treat FareHarbor API and embeds as validation and UX layers, not as the core system
H2Operational flow
Trip Builder -> Booking Request / Confirmation Doc -> Apps Script office workflow -> Manual FareHarbor confirmation -> Optional payment handling -> Customer confirmation email, PDF, and calendar invite