Maurice
63a7a4d397
An assistant can now take back a change it saved with save_tour_change, the way the change was saved: listed, shown, then taken back only after the traveller said yes. Until now a saved step could be followed but not undone; the traveller had to rebuild the walk by hand in the planner. - list_tour_change_steps lists the steps of a tour, the latest first, with the changes as confirmed and where each stands: latest, undone, later change on top or no readable earlier state. Planner saves are no steps. - prepare_tour_undo shows what taking a step back does without writing anything: the tour now, with the stations visited or skipped, set against the tour exactly as the step kept it, the stations kept, coming back and removed, and the distance and walking time stored then. - undo_tour_change restores that tour whole or not at all, through the write the planner's save uses: line, stations with their keys and the measures stored then, in one transaction with the mark on the step, and the trip is told after the commit. It needs place editing on the trip and checks everything again inside the write. - Only the tour's latest change goes back. A step something was saved on top of since, in the planner or by another step, is a conflict on the tour's one revision (no second one), so no later edit is lost unseen; a preview read at another revision is a conflict too. Taking back a step that would remove a station visited or skipped since, or bring back a station whose place of the trip is gone, is refused with every reason, and so is a step without a readable earlier state. Every refusal and failure leaves the tour as it is. - A step is taken back once: tour_change_steps records the revision that raised the tour to, who confirmed it and when, and nothing else is kept. - None of it touches a planner draft: the planner's own undo stays in the browser, and discarding a draft never changes a saved tour. The tool descriptions and the wiki say so. The write of a tour's line and points and the tour as the answer gives it now come from one place for the save and the undo.
@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.