md / archive / recap / 20260421_trips-spec-next-steps-audit.md
Molino⺢Pro

20260421_trips-spec-next-steps-audit

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
H1Trips Spec Audit

Status: reconciliation note for current Trips state

Scope:

  • current trip spec
  • planner canonical notes
  • trips module plan
  • execution layer assumptions
  • no destructive edits to existing notes
H2Canonical stance

The Trips Area plan remains the canonical top-level truth.

This note does not replace it. It reconciles later concerns into the correct layer, feature set, subchapter, or execution overlay.

The rule is:

  • keep the Trips module plan as the semantic and structural baseline
  • place newer operational concerns under the right subordinate layer
  • preserve one source of truth per layer
  • avoid creating parallel canonical models for the same thing
H2What is still true

The following remain canonical and consistent across the current Trips notes:

  • Trip is the planning and semantic authority
  • Experience is the reusable commercial unit
  • GroupSession is the dated operational occurrence
  • Trip does not define session existence
  • Experience does not define dates
  • GroupSession does not define bundles
  • Planning, pricing, and execution are separate layers
  • Server actions own persistence
  • UI owns intent only
  • Projection is not truth
H2What now looks stable enough to rely on
  • TripPlannerContext plus normalizeStops() as the route normalization spine
  • form.stops[] as the canonical route source of truth
  • Derived roles for arrival, departure, core, and extension
  • Planner autosave and edit flow
  • Assistant-assisted form generation
  • Trip sidebar as a usable planning surface
  • Document-to-trip orchestration as a working bridge
H2What is an emerging need

These are no longer speculative, but they should be treated as pending operational layers:

H31. Execution split

The current trip model needs a clearer handoff from planning to fulfillment.

Recommended additions:

  • BookingBundle
  • status: draft | pending | partial | confirmed
  • Request Booking action
H32. Hotel policy

Hotel behavior should remain derived, not user-promised.

Current direction:

  • daysUntilStart > 40 can use managed / blocked inventory logic
  • daysUntilStart <= 40 should degrade to services-only and external booking links

This is still a trip policy concern, but operationally it behaves like an execution rule.

H33. Apps Script highway

Export endpoints are now required for practical operations:

  • PDF
  • email
  • calendar
  • booking document

These should remain projection-only and never own business truth.

H34. FareHarbor posture

FareHarbor should remain:

  • inventory bridge
  • manual fallback
  • later validation layer

It should not become the backbone of the planner or the truth source for trip structure.

H2Canonical resolution map

Use this mapping to place concerns into the correct layer.

H31. Trip identity and structure

Keep in:

  • Trips area plan
  • Trips module plan
  • master skill links

This covers:

  • Trip as commercial surface
  • experience city links
  • group session versus trip separation
  • landing and discovery structure
H32. Planner mechanics

Keep in:

  • 20260420_trip-planner.current-pattern.md
  • 20260420_trip-planner.refactor-target.md
  • planner sections in the master note

This covers:

  • route normalization
  • arrival/departure role handling
  • city reorder edge cases
  • edit mode and autosave
H33. Execution concerns

Keep in:

  • 20260421_trip-execution-bundle.md
  • 20260421_trips-next-steps.locked.md

This covers:

  • booking bundle
  • hotel policy
  • execution mode
  • manual FareHarbor fallback
H34. Projection and office automation

Keep in:

  • SKILL_projection-appscript.md
  • appscript/appscript.apis.md
  • appscript-office-server-firstLoop.md

This covers:

  • PDF
  • email
  • calendar
  • booking docs
  • return metadata and traceability
H35. Cognitive and narrative layer

Keep in:

  • 20260420_trips-guidebook-plan.md
  • 20260220_trips-sessions-MLV.md
  • document / concept / guidebook chapters

This covers:

  • narrative framing
  • concept cards
  • guidebook text
  • semantic explanation
H2What needs softer logic

The current planner spec is right in principle, but the operational edge cases need gentler handling:

  • city reordering
  • arrival and departure preservation
  • duplicate city prevention
  • hotel mode derivation
  • stop role recalculation after edits
  • preserving human-intent edits while still normalizing the route
H2Current layered model
H3Cognitive layer

Use for:

  • concept cards
  • trip narrative
  • guidebook and planning language
  • assistant explanation
H3Operative layer

Use for:

  • trip route
  • services
  • hotel policy
  • booking intent
  • booking bundle
H3Projection layer

Use for:

  • PDF
  • document output
  • email
  • calendar
  • manual or external booking workflows
H2Risks to keep visible
  • recomputing pricing downstream
  • mixing experience and session truth
  • letting projection become truth
  • overloading the planner with execution concerns
  • making FareHarbor a hard dependency too early
  • treating sidebar UX as the domain model
H2Current conclusion

The current Trips spec is still true and is the canonical base. The newer notes do not contradict it; they refine the boundary between planning, execution, and projection.

The next safe step is to keep the planner canonical, keep execution as a separate bundle, and treat hotel and FareHarbor logic as operational overlays rather than core planning truth.

H2Related reading