mirror of
https://github.com/Tria-plc/edr-platform.git
synced 2026-09-01 08:53:27 +00:00
One conflict, in booking-notifier.service.ts's scheduleLabel(). Both branches had independently gone after the same thing — customers know a departure by its operating number, not the S-… schedule reference — so the resolution takes dev's version wholesale rather than splicing. Ours was a one-line flip, `s.trainNumber ?? s.reference`. Dev reaches the same result via `const number = s.trainNumber ?? s.reference` and goes further: it keeps the reference as a secondary detail beside the route, suppresses that detail when the number IS the reference so it cannot print twice, and gives the departure a time of day and an EAT suffix instead of a bare date. Nothing in ours is absent from theirs. This branch's own additions to the file — trainNumber(), trainTag() and the scheduleId threading — are untouched by the conflict and survive intact. Renumbered the two DJF migrations, which the merge put on top of dev's: 3790000000000 → 3840000000000 (DjfCurrencySupport) 3800000000000 → 3850000000000 (PerCurrencyExchangeSettings) Dev landed its own migrations at 3790 and 3800, so both of mine collided; the new prefixes are unused and above dev's highest (3830000000000), per the rule in CLAUDE.md. Fixed a real defect the renumber exposed. PerCurrencyExchangeSettings read `djf_enabled` unconditionally to carry the operator's DJF choice forward — but it DROPS that column at the end of its own up(), so it could only ever run once. Re-running it, or running it against a database repaired by hand, died on 42703 "column djf_enabled does not exist". The read is now guarded on information_schema, defaulting to false when the column has gone, and the insert's ON CONFLICT DO NOTHING leaves an existing DJF row's choice alone. Verified: migrations run clean to "no pending freight migrations" (both recorded, ids 379/380); exchange_settings holds ETB/USD/DJF with the unique index and djf_enabled dropped; DJF stayed enabled, so the operator's toggle carried across. Type-check passes on freight-api, payment-api, payment-providers, ui-common and portal. Freight suite: 10 suites / 28 tests failing against a pre-merge baseline of 9 / 27 — the one addition is dev's own freight-permissions.registry.spec, whose registry and spec are byte-identical to dev's here and which this branch never touched. No currency, exchange, pricing, billing or overview spec fails.