The last change marked the drive into the next day and kept it off a phone stage, but it only caught the connection `connectDays` builds through `inboundAt`. A trip with a day window set never takes that path: the window switches `inboundAt` off and builds the days itself, so day 2 opens on an automatic night standing where day 1 stopped and its first leg is the drive on from there. That leg is the same connection, it just arrives as one of day 2's own legs under day 2's number, and the stage drew the whole way back to yesterday's last stop on today's map. The setting is not even involved: with a window it happens either way. So the leg out of an opening night is marked as a join as well, and the phone drops it with the rest. One exception, because the filter must not empty the screen: a day that is nothing but driving, night to night with no stop of its own, has only the connection to show, and there the line IS the day. When dropping the joins would leave a stage with no line at all, it keeps them.
@trek/shared
Single source of truth for TREK's API contracts, expressed as Zod schemas and consumed by both the server (request validation + inferred DTO types) and the client (typed requests/responses).
This package is part of the incremental NestJS + React 19 migration (see the "Brownfield Rewrite" board). It is intentionally dormant until modules start importing it — adding it changes nothing for users.
Rules
- One folder per domain:
src/<domain>/<domain>.schema.ts(+.spec.ts). - Domain-agnostic building blocks live in
src/common/. - A route is only considered migrated once its contract lives here.
- Schemas are the source of truth; server DTOs and client types are inferred from them
(
z.infer<typeof schema>), never hand-duplicated.
Consumption (dev)
Both apps resolve @trek/shared to this package's TypeScript source:
- Server (
tsx): viapathsinserver/tsconfig.json. - Client (
vite): viaresolve.aliasinclient/vite.config.ts(+pathsfor the type-checker).
Production packaging (Docker / workspace wiring) is introduced in card F2, when the server first depends on this package at runtime. Until then prod builds are untouched.
Not yet here
The canonical error envelope is finalised in card F5 (it must match TREK's current Express error responses byte-for-byte), so it is deliberately not invented in F1.