implementation-order

Implementation order: inner layers first

Build the cake from the inside out. A unit may be written only when everything it depends on already exists and is green. This keeps every layer testable without mocks and stops the classic hackathon failure where a beautiful screen sits on top of arithmetic nobody verified.

The order

L0. Pure domain core, src/composer/. No imports outside the file's own layer, no I/O, no clock, no network.

1. types.ts - TripRequest, TripResult, TripPackage, EventCard, Leg, HotelOffer, CheckoutLink, CoverageNote, SkippedNote. The file grows feature by feature; it is never published whole in the first commit.
2. dates.ts - check-in day, check-out day, night count.
3. selection.ts - candidate events, with the reference date passed in as an argument.
4. feasibility.ts - arrival buffer, departure after the event, unknown start time.
5. pricing.ts - total participation price and budget breakdown. It receives an already marked set of working days; reading isDayOff is L2, not L0.
6. hotels.ts - hotel ranking: by distance when the venue was geocoded precisely, otherwise by price and rating with the distance block suppressed.
7. packages.ts - the three selection rules and their collapse to fewer cards. It chooses among combinations that L3 already assembled; building the cartesian product is L3.
8. checkout-labels.ts - the pure kind to button-label table.

L1. Sources, src/sources/. Protocol and normalization, one module per concern.

1. types.ts - normalized shapes the rest of the code sees.
2. normalize.ts - raw payload (unknown) to domain types, plus forgiving input coercion.
3. cache.ts - keyed in-memory cache with per-source TTL, replay from fixtures/.
4. confcal.ts - session handling, one concurrent call, automatic re-initialize.
5. tutu.ts - sessionless client over the four tools actually used.

L2. Enrichment, src/enrich/. Each one a function with a timeout and a fallback, independent of the others.