md / archive / recap
Molino⺢Pro

20260421_trips-next-step-recap

Master Codebase Guidebook
Markdown + HTML Dev-Docs Renderer - Frontend Client Module

Default Index
Open README.md
Root: README.mdrecap
Milestones
⬆ Parent folder📝 20260421_trips-next-step-recap📝 20260421_trips-spec-next-steps-audit📝 20260422_module-status-audit📝 20260422_recursive-audit-round2📝 20260422_schema-gap-audit📝 micro-goals.next-steps-specs📝 README📝 recursive-audit-playbook
H2Priority order for the next 1 to 2 weeks
H31. Tighten trip planner rules

Goal:

  • remove edge-case ambiguity when changing city order
  • keep arrival and departure roles stable
  • make normalization predictable after edits

Focus:

  • city reordering
  • first and last stop rules
  • derived roles only
  • consistent form constraints
H32. Lock hotel policy

Goal:

  • derive hotel behavior from trip start date
  • stop promising hotel handling too late in the cycle

Working rule:

  • if daysUntilStart > 40, hotel handling may use blocked inventory
  • if daysUntilStart <= 40, fall back to services-only plus external hotel links
  • treat hotel mode as derived, not user-promised
H33. Separate execution from planning

Goal:

  • keep Trip planning clean
  • move fulfillment into a booking bundle

Deliverable:

  • BookingBundle
  • status: draft | pending | confirmed
  • Request Booking action
H34. Ship the Apps Script highway

Goal:

  • make office outputs reliable and repeatable

Endpoints to prioritize:

  • PDF export
  • email export
  • calendar export
  • booking document export
H35. Keep FareHarbor manual by default

Goal:

  • launch without widget dependency
  • use FareHarbor as an execution tool, not system backbone

Working flow:

  • create booking intent in app
  • operator confirms in FareHarbor dashboard
  • app status is updated afterward
H36. Add FareHarbor validation later

Goal:

  • check availability before commitment
  • keep booking automation for later
H1✅What is effectively already done
  • ✅ The app can already act as a document-centric control surface
  • The assistant can already populate documents and trip-related content
  • The Trips area already has enough structure to support planning-first work
  • The current risk is not missing architecture, but unfinished boundaries between planning, execution, and fulfillment
H1Trips Next Step Recap

Status: working recap based on current development state

Scope:

  • Trips only
  • no changes to existing files
  • derived from the current master spec, trips plan, and your working status notes
H2Assumptions from current status

These items are treated as already working or effectively proven:

  • Document interface is working
  • Sidebar assistant is generating and populating a new document
  • Assistant modes exist and are usable, even if not fully finished across every tool
  • Trip sidebar is working
  • AI LLM can auto-fill a trip form from chat
  • Current trip planning forms and route logic are mostly stable
  • Normalization and city order handling already exist as the base path
  • Modals and scaffolding are in place for future expansion

These items are treated as partial or proof-of-concept only:

  • Some assistant modes are not fully finished for all tools
  • Some modals are scaffolding rather than production-complete
  • Trip planner edge cases still need softening around city order, arrival, and departure
  • Hotel handling is not yet fully canonical
  • Booking execution is not yet fully split from planning
  • FareHarbor integration is not yet system backbone quality
H2Completed stages, by assumption
H3Completed enough to build on
  1. Document control surface
  2. Assistant-generated document population
  3. Trip sidebar flow
  4. Chat-driven trip form generation
  5. Base planner normalization logic
  6. Existing module scaffolding and modal surface
H3Partially complete
  1. Trip builder UX
  2. Trip planner rules
  3. Assistant modes across all tools
  4. Document-to-trip orchestration
  5. One-click operational flows beyond the document layer
H3Still pending
  1. Inline TripDetail editor
  2. Canonical hotel policy
  3. BookingBundle execution layer
  4. Apps Script highway endpoints
  5. Manual FareHarbor execution workflow
  6. FareHarbor calendar validation
  7. Cleanup of sidebar fragmentation
H2What to avoid for now
  • full FareHarbor API booking automation
  • widget debugging as a launch blocker
  • payment unification too early
  • over-modeling trips versus sessions
  • adding new flow fragmentation before the current planner is stable
H2Short conclusion

Current status is strong enough to treat the document layer, assistant layer, and trip sidebar as established. The next work should harden trip rules, derive hotel policy, then split execution into BookingBundle and office automation before touching deeper FareHarbor automation.

H2Related reading