12 Commits

Author	SHA1	Message	Date
Maurice	89bae414ff	fix(offline): a missing driving-settings row no longer discards the trip bundle ... syncTrip read the roadtrip preferences before writing anything and rethrew everything but a 404. That read has an offline fallback which throws a bare Error when there is no cached row, which is the state a first sync is in and the state a logout leaves behind, so the whole downloaded bundle for that trip was dropped while the run still counted it. Settings reported "N trips stored" over an empty database, and the trips were gone the moment the connection was. The read moved to the end and is never fatal now: it belongs to an optional addon and the addon answers 404 when it is off. Two things that fed it, from the same trace. A sync run started on navigator.onLine alone, so work-offline downloaded over the real connection while every repo read answered from cache. And work-offline itself survived a logout, in localStorage, while step six of the same logout deleted the database it reads from, so the next account came up believing it was offline with nothing to be offline with. Also in this pass: deleting a hotel booking released its day stop after deleting the booking row, which now clears the stop's pointer by trigger. The release goes first, or the stop stands with nothing left to reach it.	2026-09-13 23:48:59 +02:00
Maurice	54e5525568	fix(accommodations): a booking that moves carries its stop instead of rebuilding it ... Correcting a booking's date deleted the day stop it had mirrored and inserted a fresh one. A day stop is not just a day and a place: its participants and any road-trip day boundary hang off its id by ON DELETE CASCADE, and its note, its hour and its end-of-day flag live in its own columns. All of it went, silently, for an edit that only meant to move the night one day on. The row is carried across now, seated by its check-in the same way an insert would be, and the delete-and-insert is kept only for the case where the target day already holds that place under a stop of the traveller's own. Three more holes in the same mirror, found alongside it: Dropping a night while keeping the place cleared accommodation_id server side and told nobody. Days hides a stop that carries a booking id, so on every other screen the place stayed invisible on a day it was standing on. A night is seated by its check-in, which renumbers the stops around it, and nothing said so. The day that changed now sends its order along. Deleting a place cancelled the nights booked there, which takes each night's partner booking and that booking's expense with it, and announced neither. The Bookings list kept the reservation and the Costs total kept the money until a reload, and an expense linked by reservation_id is not one the place-linked sweep finds. Also: day_assignments.accommodation_id went in as a bare INTEGER, so shortening a trip past a booking's last night cascaded the booking away and left the stop pointing at nothing, hidden from Days for good while the route still drove to it. Migration 234 clears the ones already out there and adds a trigger, which SQLite fires even when the booking went down with a cascade. And a duplicated trip now carries the stop's booking id, the booking's check-in window and a place's fill_percent, none of which the copy took along.	2026-09-13 23:48:59 +02:00
Maurice	c351a0471c	fix(accommodations): a check-in decides where in the day the night sits ... The stop went to the end of the day, always, on the reasoning that a night ends the day. It usually does — but a check-in at eleven says the traveller is at the desk before whatever they pinned to the afternoon, and putting the stop behind it built a drive that reaches the hotel at seventeen past five after a sixteen hundred it was booked around. The order looked like the traveller's and was not; it was this code's default. A booking with a check-in now takes the place its hour asks for: ahead of the first stop pinned later, and still last when nothing is. Editing the check-in re-seats it, in both directions, read off the chain rather than recomputed — the index a fresh insert would get is not the index a row already holds. Stops without an hour of their own are passed over in either direction. Their place in the chain came from the traveller, not from a clock, and a night has no business pushing past one.	2026-09-13 16:06:11 +02:00
Maurice	3f6d1e8ed7	fix(accommodations): re-export the module, not the provider inside it ... The container refused to boot: Nest will not export a provider that belongs to an imported module, and the service moved into the domain module in the commit before. Re-exporting that module gives every importer the same service it always got, and the wiring test now asserts the shape that actually boots rather than the one that only typechecks. Neither tsc nor the unit tests could see this — the module metadata is only read when a container is built. The e2e harness does build one, and that is what catches it.	2026-09-13 15:50:58 +02:00
Maurice	77a16d6f26	fix(places): deleting a place cancels the nights booked at it ... A stay whose place was deleted kept its row with place_id NULL: still drawn in the day header, still naming a hotel through its partner booking, and pointing nowhere. Nothing could reach it any more and nothing cleaned it up. It goes with the place now, through the accommodations domain rather than a DELETE in the places path, because a stay takes its partner booking, that booking's expense and the day stop it wrote with it — none of which is the places domain's business to know. Both delete paths, single and bulk. The service moves into an AccommodationsDomainModule, the assignments-domain precedent: the service never touches PlacesService, only the MCP tool that writes a place and a stay together does, so it can sit in a module PlacesModule is free to import without closing a loop. AccommodationsModule keeps exporting it, so every existing consumer is unchanged.	2026-09-13 15:36:02 +02:00
Maurice	d0d3f455a8	fix(planner): let the day list see which stop a booking wrote ... The row shapers name every column they pass on, and accommodation_id was in none of them. So the field the day list hides on never reached the client, and the booked night was listed as an ordinary place next to the overnight block that already named it. The stop was correct in the table the whole time; the three read paths just dropped it on the way out. The stamp on the freshly written stop had the same hole from the other side: the INSERT went in without the booking id and an UPDATE added it afterwards, so the row handed back in the answer, the one the client that booked the night puts straight into its store, carried none. It goes in with the INSERT now. The shared link gains the same filter. It has no road trip view to need the stop and already shows the booking as its own chip on the day, so the row was only ever the same hotel twice.	2026-09-13 12:59:19 +02:00
Maurice	eff4605ef3	test(accommodations): cover the paths the day stop added, and the ratchet fell on ... Six lines and four functions the mirror brought in were never entered by a test, which is what took the domain under its coverage floor. The keepStop branch of a delete, the plugin surface's own update, and the transaction that has to roll a place and its stay back together. Plus every sender a surface hands announceMirror: REST and the three plugin methods build one each, and a fixture that swallowed the call let all four go unexercised -- the one link between a stay write and the sockets everyone else is watching.	2026-09-13 12:12:38 +02:00
Maurice	edf0538260	fix(roadtrip): keep a booked night out of the day list, and off the traveller's stops ... Three things the first pass got wrong. A stop a booking puts on the day is for road trip mode, which needs the hotel in the driving chain. The day planner already shows that booking as its own overnight block, so the row there would be the same hotel twice. It is hidden in Days whatever the service-stop switch says, and the switch goes back to meaning what it says: the petrol stations the traveller added. Cancelling a night from the road trip popup took the stop with it. That control means "this is a pause now, not a night", and the stop sits mid-drive where re-adding it would land it at the end of the day. The booking now hands the stop over instead of deleting it. Moving a booking whose stop belongs to the traveller put a second one on the new day and left the first behind, which is the duplicate this change exists to remove. Only a booking's own stop moves now. Stays booked before this shipped get theirs from the migration, not from the next edit they happen to receive.	2026-09-13 01:42:52 +02:00
Maurice	f0e1da2d81	feat(accommodations): put a booked night on its check-in day ... A road-trip stop is a day assignment: the rail, the server-side plan and the map all build their stops from day_assignments and only look the stay up afterwards, to hang check-in and check-out on one. A stay written without an assignment was therefore invisible to every routing surface, so a hotel entered in the day planner never reached the road-trip view and had to be entered a second time as an ordinary place. The road-trip side has always written both halves in one go; this is the day planner catching up, in the domain that writes the stay. Booking a night now also assigns its place to the check-in day, inside the transaction that already writes the stay and its partner hotel reservation, and types the place as a hotel stop when it carries no type of its own, so it reads exactly like a night booked in the road trip. Only the check-in day gets a stop; the later nights ride on the stay row. A place already planned for that day gets no second stop and the booking claims none, so cancelling it cannot delete a stop somebody placed by hand. Moving the booking moves its own stop, deleting it takes its own stop back, and a trip re-date carries it along with the stay. All four write surfaces (REST, plugin RPC and both MCP tools) run the same write and announce the same events; the answers carry the stop too, because the broadcast skips the socket that sent the request. New nullable day_assignments.accommodation_id marks a stop as a booking's own. It stays NULL for every existing row on purpose: everything planned before this was planned by hand, and no backfill rewrites a finished trip. A stay booked earlier picks up its stop the next time somebody saves it. The booking form keeps writing stays on its own: that surface is gated on reservation_edit and the day stop is day_edit work.	2026-09-13 01:13:25 +02:00
Maurice	9dd0a851ca	fix: eleven reported bugs across atlas, budget, collections, journey, vacay and the LLM settings (#1923) ... * fix(mcp): accept per-leg times on create_transport and update_transport metadata was pinned to Record<string, string>, so a legs array could not get through and a multi-leg flight built over MCP lost every intermediate time. The booking ended up with correct endpoints and no legs, which every reader then treats as a single segment. legs is now a real, typed parameter with its contract in @trek/shared, shaped exactly the way the planner form and the importers write metadata.legs. The folding checks what the readers depend on: one leg fewer than endpoints (the AirTrail dedupe builds its signatures on that), day ids that belong to the trip, airport codes that agree with their endpoint, and the times, where a stopover endpoint carries the departure and the last one the arrival. metadata keeps its type and its replace semantics. Segments smuggled through metadata.legs as a JSON string used to be stored and then ignored by everything that read them; they are refused now and point at the legs parameter instead. Closes #1914 * fix(atlas): refuse a bucket list entry that is already on the list Nothing gave a bucket entry an identity, so the same country could be added as often as it was clicked. A wish is now identified by name, country, target date and, where it has them, coordinates. A different target date is a different wish and still lands, which is what the report asked for; two real places sharing a name stay separate because their coordinates differ. Empty string and NULL are normalised on both sides of the comparison, otherwise the dateless case, which is the one that was reported, would slip through. Deliberately no unique index and no migration. better-sqlite3 is synchronous and the server is a single process, so the race an index would guard against cannot happen here, and an index would have needed a destructive dedupe of existing rows first. create_bucket_list_item had no target_date parameter at all, so over MCP the allowed "same place, other date" case was unreachable. It takes one now. The plugin RPC reports the duplicate as bad params instead of letting it surface as an internal error. Closes #1898 * fix(settings): keep a free-form LLM endpoint in admin hands Any account could name the address the server calls, and the guard in front of it deliberately allows loopback and LAN so a self-hosted Ollama works. That is a reasonable trade for whoever runs the instance, because the network is theirs. It is not one for an arbitrary account, which could aim a request from inside that network at a target only it chose and read how the target answered. A free base URL, and the local provider that is one by another name, now come only from an admin controlled source: the addon config, the instance-wide defaults, or an admin's own settings. OpenAI and Anthropic stay available to everyone, because they go to a fixed address with the user's own key. The resolver is where this is enforced, since it is the single point both the booking import and the plugin host pass through, and the only one that also covers values already sitting in the database. The write path refuses as well, so nothing is stored that would never be read. The hint text promised something users no longer have, so it changed with it. Closes #1772 * fix(calendar): span a date-only booking to its end date A DATE event without DTEND is exactly one day per RFC 5545, so a multi-day booking that carries an end date still collapsed onto its first day. It gets an exclusive DTEND now, built the same way the stay branch already builds one. A booking without an end date serialises byte for byte as before. While in here: the stays query joins reservations on the accommodation, and two bookings pointed at the same stay fanned it out into two events sharing one UID. Duplicate UIDs in a feed are undefined behaviour and calendar clients pick one at random. The same "at most one booking per stay" assumption sat in the accommodations service, where it was worse than cosmetic: accommodation_id carries no foreign key, so deleting a stay took only the first booking and left the second pointing at something that no longer existed. Both the sync and the delete walk all of them now. The callers keep reading linkedReservationId; the list is additional. Refs #1869 * fix(vacay): say that the region is required, because it is The placeholder called the region optional while the add button stayed disabled until one was picked. The wording predates multiple calendars per plan, which is what introduced the gate. Only the value of the existing key changed, in all locales, so the key set stays identical. Two things the same screen got wrong were in the way of a clean answer: The button was clickable while the region list was still loading, which put the user in exactly the state the wording describes, and it is the state the report was filed from. It waits for the list now. Changing the country on an existing calendar kept the previous country's regions on screen, so a German region could be picked for the Netherlands. The list is cleared with the country, which only works in combination with the loading gate: without it, the empty list would happen to enable the button instead. Closes #1813 * fix(collections): let a saved place's address be corrected The edit form offered name, category and labels, and the address only on the way in. The cause was not the form: the update contract never declared address, so the validation pipe stripped it and the UPDATE had no column for it. Coordinates were pulled through for #1435 and the address was missed. It travels the whole chain now, contract to service to both forms. No migration, the column has always been there. The mobile add sheet had no address input at all, showing whatever the search result carried as read-only, so editing would have worked while creating still would not. It has one. The MCP tool description had drifted further than the address, never having mentioned the coordinates either. Both are in it now. Closes #1870 * fix(collections): keep the place search usable after the first save The add dialog stays open on purpose so several places can be added in a row, but after a save it gave no way back into the search. A search with no results was silent, with no empty state and no toast, so typing another name and pressing enter looked like nothing happened. The reporter described both halves and it is the silent search that matches "nothing happens" most closely. There is an empty state now, using a key that already existed in every locale and was unused. The search row is sticky inside the dialog body, so it stays reachable after the save instead of sitting above the scroll position. Also fixed while in here: refreshing the collection after each add reset the select mode, the selection and the label filter. In the very flow this dialog is built for, the user quietly lost all three. Closes #1921 * fix(vacay): make the phone year grid and the dock button do what they look like Two separate faults met on this screen. Tapping a day in the year grid did nothing unless the edit mode was already on, and the only way into it was a floating button that looks exactly like the one the dock draws in the same spot. A tap now opens that month in the editor, where the cells are big enough to hit. At 390px the grid cells are around 21px, which is too small to be mutating data with in the first place. The dock's plus was not wired for this route, so it fell through to creating a trip on the dashboard. Two different actions were stacked in one place, and the wrong one was on top whenever the screen had not painted yet, which includes the time its chunk is still loading. The dock leaves the slot to the screen now, and holds the geometry so the tab groups stay symmetric. Closes #1811 * fix(budget): settle in whole cents so balances stop drifting The report is a balance that moves on its own, with nothing added, edited or removed, on a trip where everything is in euro. Two mechanisms were behind it and both are real. The display currency is a fourth value, a per-user setting, so "everything is in euro" never covered it. Each balance was converted and rounded on its own, and the set no longer summed to zero: at 0.855 and 0.9312 it came out one cent over, at 0.94 it came out even. That cent appears and disappears with the six hour rate cache alone, which is exactly the symptom. The flows were rounded separately from the balances, so the two never had to agree. And a receipt line nobody was ticked for counted toward the total, and therefore toward the payer's credit, while landing in no share. That difference is permanent, and the client sent it that way. The settlement converts once, at the edge, and does integer arithmetic after that. Equal splits distribute the credited cents by largest remainder rather than the entered total, so credits and debits of one expense cancel exactly even in a foreign currency. Display conversion goes through the same largest-remainder allocation, so the sum survives it. With that, the 0.01 epsilon can go. It could never create a cent, but it stranded them: a one cent balance was filtered out of the flows while staying visible in the list, which is the "settle up offers nothing" half of the report. Closes #1382 * fix(journey): reach the book export and the suggestion toggle on a phone Below 1024px the hero card is dropped, and it held the only way to either action. The floating bar that replaces it was never given them. It has them now, and the hero is unmounted rather than hidden, so there is no second invisible copy of the same controls in the document. The bar's own buttons moved onto the appearance tokens while they were being touched. The phone screen never had either action at all and now carries both. The book itself was hardwired to English, cover and dates included, while the keys for it had been sitting in every locale unused. It takes the page's translator and locale, sets the document language, and prints mood and weather, which were on screen but never in the book. Closes #1848 * fix(journey): offer the connected photo providers in the phone entry editor The desktop editor grew an external photo source in #1632; the phone editor that came out of the mobile rewrite never did, so editing an entry on a phone had no way to Immich or Synology. It mirrors the desktop mechanics, including the part that is easy to miss: a save that creates the entry and then fails on the photos keeps the sheet open, and without remembering what was just created the retry creates a second entry. The sheet no longer kicks off its own addon load. The list is loaded once on boot and this only reacts to it; a second load races the other consumers and overwrites the store when it lands. Closes #1808 * fix(mobile): let the document scroll so Safari can collapse its URL bar iOS Safari only shrinks its address bar when the document scrolls, and TREK's never did: the root was locked and the mobile shell put a scroll container inside it. On the bottom tab layout that costs about a sixth of the viewport, permanently. Below 768px the document is the scroller again and the full-bleed screens measure their own height instead of leaning on the shell. That makes the body scroll locks real for the first time on a phone, and they were not ready for it. Three of them reset the overflow unconditionally, one of those on every run of its effect rather than on unmount, so a system notice could hand the page back while a sheet was still open. They all go through one reference counted lock now, which is the part that had to land first. Worth knowing for the issue: this reaches the flow screens. The trip planner, the journal, the atlas and the vacay screen keep their own full-height scrollers and still will not collapse the bar. Closes #1809 * fix(mobile): keep the screen gradient visible behind the translucent cards The gradient layer introduced with the scroll change sat at z-index -10. A negative layer paints above the canvas but below the backgrounds of ordinary blocks, and body carries an opaque one, so the gradient was hidden behind it. The mobile cards are translucent and take their depth from what is behind them, so every surface ended up compositing against a single flat colour and the whole phone UI read as one tone. The layer is positioned at z-index 0 now and the content above it at 10, which puts both over body's background. Same visual as before the scroll change, and the shell still owns no scroll container. * test(reservations): teach the accommodation delete stub about the id lists The RPC walks every linked booking since the delete stopped stopping at the first one. The stub still answered with the two singular fields, so the loop had nothing to iterate and the cascade events never fired. * fix(settings): move the free-form LLM endpoint out of user settings entirely Hiding it from non-admins closed the hole, but it left the option sitting in the admin's own personal settings, which is not what was asked for and not where it belongs: an instance has exactly one address it calls out to, and there was a second, invisible place to set it. The provider list is now the two hosted ones for everybody, the endpoint field is gone, and the resolver takes the address from the admin-controlled instance defaults for every caller including an admin. It no longer reads the users table at all. The write path refuses the keys for everyone, so nothing can be stored that would never be read. The endpoint is configured on the addon in the admin settings, which already carries provider, model, base URL and key, plus the Ollama model list. Nothing is lost, it just has one home now. Behaviour change worth a release note: an admin who set a personal Ollama endpoint has to move it to the addon config. A non-admin was already in that position after the previous commit. Refs #1772 * fix(journey): make the book preview usable on a phone The preview document carried no viewport, so a phone laid it out at its default 980px while the page is A4 landscape and about 1123px wide. It spilled out of the frame, which reads as being zoomed far in. Declaring the real width lets the browser scale the page to fit. Printing is unaffected, it goes by @page. The preview chrome had the same problem in miniature: a title and two labels on one row, sized inline, which does not fit a phone and fits translated labels even less. It moved to a stylesheet, and below 640px the card goes full-bleed, the decorative title steps aside and the two actions share the width. Refs #1848 * fix(mobile): stop the shell trapping the screens' own overlays Lifting the background layer into the positioned range meant the content wrapper had to be positioned too, and a positioned wrapper with a z-index is a stacking context. Every fixed overlay a screen renders inside it got clamped to that level: the vacay view/edit FAB sits at z-50 precisely so it beats the dock at z-40, and it disappeared behind it. The layer goes back to a negative z-index and the wrapper back to no positioning at all. What it needed in the first place was for body to stop painting over it, which is one line in the phone media block rather than a new stacking context. * fix(mobile): let the phone background override actually win A media query adds no specificity, so the themed body rule further down the file kept winning on source order and painted over the shell's background layer. The override is on html body now. The gradient was back to being invisible, which is the flat single-tone phone UI again. * fix(vacay): draw today's ring around the day instead of replacing it On the phone, today short-circuited the day-cell matrix and returned a ring on an empty cell. A vacation day or a company holiday logged for today was stored and counted in the totals, but the cell showed nothing, so it read as if the tap had not taken. Today is an annotation now, layered like the school band and the shared-calendar rings, which is how the desktop month card has always treated it. The strong ink stays only where the cell has no fill of its own, since --m-ink is light in dark mode and would disappear on a pastel. * fix(map): stop serving a stale GL style document from the service worker The Workbox rule for Mapbox matched every URL under api.mapbox.com, and the style document lives there too. Under StaleWhileRevalidate the map was built from the previous revision on every load, with the refresh landing one load too late, so a style republished in Studio with different label languages kept rendering the old ones. The network tab showed a 200 throughout, because the service worker's own answer is a real 200, which is why this looked like the app rewriting text-field at runtime. The style now has its own rule ahead of the tile rules, on NetworkFirst so it is current whenever the network is, and still cached so the map opens offline. Its own small cache too: sharing an LRU with three thousand tiles made the staleness come and go at random. OpenFreeMap styles had the same problem and are covered by the same rule. Closes #1924	2026-08-13 14:06:35 +02:00
Maurice	11afd3648e	Put the coverage back where the code went ... Every split on this branch dropped the giving domain's ratchet without a line being tested any worse: coverage follows the source file, so when well-covered code leaves, the weaker branches that stay behind become the whole denominator. days fell from 82 to 77.5 percent branches that way, feeds to 76.7, trip-read-model to 62.5. The rule in vitest.config.ts is that the only way past a number is to raise it, so these are tests, not edits to the thresholds. days is back at 92.1, calendar at 96.2, trip-read-model at 100. feeds and trip-members and trip-read-model had no unit test at all - feeds' whole threshold rested on one e2e, which is exactly the file whose contract this branch rewrote. They have one now, and the read-model test pins the thing in that file that would leak data if it regressed: getTripSummary and bundle both thread the viewer id into packing.listItems so another member's private items stay hidden, and nothing asserted that before. The five thresholds this branch introduced move up to what they now measure, with a few points of slack. The pre-existing entries are left alone on purpose: they were generated from a Linux run, CI measures there, and a handful of branches are platform-specific - raising them from a Windows measurement is how you get a failure that reproduces nowhere local.	2026-08-10 13:38:26 +02:00
Maurice	3d522be0e5	Give accommodations one home instead of two halves ... The routes lived in reservations/ while the SQL lived on DaysService, so the controller delegated every call across a domain boundary to reach its own data, and neither module owned the thing outright. The seven statements move into AccommodationsService unchanged and the domain gets its own directory, module, DTO, RPC and MCP surface. What stays in days/ is the reorder side: assertNoInvertedAccommodation and resyncAccommodationDays are about re-dating day rows, and the stay is the thing being carried, not the thing doing the carrying. Two edges fall out of this. AccommodationsService drops its DaysService dependency, and DaysMcp drops DatabaseService and PlacesService, because create_place_accommodation was their only user - which lets DaysModule stop importing PlacesModule and closes one leg of the latent Days -> Places -> Assignments -> Days cycle. DAY-SVC-016..026, 029 and 035 move to accommodations.service.test.ts with their case ids intact. The reservations e2e container assembles both modules now: it builds a single domain module on purpose, which is exactly what catches a move like this, and it caught it.	2026-08-10 13:38:26 +02:00