4 Commits

Author	SHA1	Message	Date
Maurice	554d6f1b9f	feat(tours): a city walk prepared from a briefing over MCP, and the station fields an assistant reads spelled out (CW-10, CW-11) ... An assistant connected over MCP can now prepare a city walk from what the traveller tells it. propose_city_walk takes a start (and an end), a time frame on a day of the trip, the themes of CW-05, the stations the traveller wishes for, the places of the trip it may use and fixed appointments with their times, and saves nothing. Places for the themes come from the search along a tour, at most eight, each with the theme, category and source that brought it; nothing is made up. The stations are ordered on estimates over the straight distance, and a place of a theme or of the trip goes in only where it is open on arrival, keeps the frame and the appointments, and leaves every station already on the walk open when the walk gets there. The walk in that order is then planned on foot by the router the road trip uses (the traveller's own routing server where they set one), and its legs give the walking distance and time from one station to the next. Where the router cannot be reached, or a station lies more than 300 m off every way (the planner's limit, now shared with the server), the times are estimates over the straight distance with an allowance for streets at 4.5 km/h, and the answer says so and why. The answer gives the arrival and leave times, the stay where the traveller gave it and unknown otherwise, which makes every later arrival the earliest one, and the opening hours checked against the arrival on that day with the helpers the planner uses. Walking and stays are counted apart, the total is complete only when every stay is known, and the minutes the frame leaves for the unknown stays are named. Free time before an appointment or at the end, wishes and appointments that cannot be kept as asked, and places left out with their reason are listed; a tour of the trip offered as a station is named as a tour. A wish or an appointment is never dropped; an appointment is a must and protected. A place's default duration is not read as a stay: every place carries one, so it says nothing. Once the traveller confirms, create_city_walk saves the walk through the same creation the planner's save uses: one write, a key for every station, the links to the trip's places checked, the trip told, with place editing permission on the trip. Its way on foot is planned by the same router and saved with the walk, together with its distance and walking time. Where the router gives no way, the walk is saved with its stations only and the answer says why: no line, no distance and no walking time. The tours list says so (route_pending), the tour detail says in one line that the way is planned in the planner, and opening the walk in the planner plans its way at once and offers to save it, with a note once it is planned that it was just planned. Such a walk can be saved as a new tour and taken over into another trip, starting at its first stop, and is never offered as a place to stay. A tour without a line needs two points of its own. get_tour_plan now spells out every field of a city walk's stations: key, name, stay (null when not known), importance (null for normal), protection (false when not set) and opening hours (null when none are known); list_tours names the station count and whether a walk waits for its way, get_city_walk_progress gives each station's key and opening hours, and take_over_tour says a walk keeps its stations with their protection. No tool changes a walk's stations; deleting a walk's place takes its stations along, protected ones included, and both delete tools now ask the assistant to name those and ask the traveller first. REST answers the stations as before. A tour create refused for a type that is switched off, a description that is too long or planned times out of range is a domain refusal now, so an assistant gets the same text REST sends; REST still answers it as an error at 400.	2026-10-20 07:09:57 +00:00
Maurice	188953158a	fix(tours): a city walk's walking time, stays and total read apart and alike everywhere, and a stay plans no route again (CW-02) ... A stay, a name, an importance or a protection set in a stop's dialog no longer plans a city walk's route again: the walk stays ready to save, its time overview follows at once, and one undo takes the change back without routing either. A stop moved or added plans the route again as before. A walk saves no breaks, so a cafe never counts as a stay and as a break at once, and a break left from another type neither counts nor holds its save up. The planner and the tour detail show a walk's walking time, its stays and their total apart and in the same words: 45 minutes of walking, a museum of 90 minutes and a cafe of 30 minutes make 2 h 45 min. A stay not entered yet makes the stays and the total at least what is known, stays nobody entered read not known yet, and stays entered as 0 read 0 min. A total entered by hand keeps its own label, and the computed total shows beside it. The head of the tour detail, the day row on the desktop and the phone, the tour summary and the library of other trips show that same total, with a ≥ where a stay is missing. Their time on the move is called walking, and the summary says a walk is planned with its stays rather than breaks. The tour list and the library carry the minutes a walk's stops are entered with and how many have no stay yet, counted from the walk's points, so the way back of a loop is no stop and its start's stay counts once. A loop run the other way keeps its start as the stop there, with its key, name and stay. The planner's waypoint list keeps the rows of a leg in a file of their own, and the tour detail its name heading in a part of its own, so both stay within their size limits.	2026-10-20 07:09:57 +00:00
Maurice	20f8266439	fix(tours): keep a city walk's visits through a save from the planner, and count a loop's start once (CW-02, CW-03, CW-09) ... A walk saved from the planner kept its stops without the keys the server gave them, so the next save from the same open planner handed every stop a new key and dropped the visits checked off in the day plan meanwhile. The planner now takes over the keys a save answers, point by point, without planning the route again, so a stop keeps its key and its visits from one save to the next. The edits of a stop's dialog now reach the planner: a changed name, stay, importance or protection counted as no change and was dropped. It is a step of its own that can be undone, Save stays available, and the route is not planned again for it. A save that takes stops out of a walk, or makes it another type, tells every client of the trip which visits are left on each day the walk is on, the client that saved included, so the progress in the day row no longer counts a stop the walk has lost. The way back of a loop is the start again and no stop of its own. Closing a loop gives it only the start's spot and the place it stands for, and the planner's stays, the stops of the tour detail, the stop count of the tour list, the visits and the progress an assistant reads leave it out, so a loop through three stops counts three, the start's stay counts once and the way back cannot be checked off on its own. A loop saved before keeps working. The rule lives in one helper the server and the client share, and the tour list takes its stop count from the walk's points through it. The tests that seed a walk for the assistant's progress go through the ORM factories.	2026-10-20 07:09:57 +00:00
Maurice	e5f01e570a	fix(tours): check a city walk's stops off and save a stop from its dialog, with the walk under test (CW-01 to CW-05, CW-09) ... Marking a stop of a city walk visited or skipped answered with a server error every time: the write that keeps a changed status stamped its time as a function call, which neither SQLite nor Postgres takes. It now uses the clock the database itself spells, so a stop checked off, skipped or taken back stays that way and the day plan of everyone on the trip follows. The Save button of a stop's dialog in the planner did nothing, because it sat outside the dialog's form. It saves the name, stay, importance and protection again. A walk saved with two points that carry one key, as a loop back to the start does, keeps that key on the first point and gives the other one of its own, so checking one off never marks both. A walk put on one day twice is read for an assistant from its first assignment. The server tests cover the visits from the repository to the routes: per day, through a moved and a removed assignment, a copy of the walk and a copied trip without visits, a removed stop taking its visits along, and the refusals for another trip, a stop the walk does not have, a member who may not edit days and an unknown key or body. The MCP progress of a walk, the station fields and counts of the tour list, and the contracts in shared are tested too; the existing tests expect the keys every saved point now carries, the station count of a list row and the new entity. The client tests cover the stop dialog and its pills, the walk themes and categories of the search along a tour, the stop menu of the waypoint list, the walk's timing, routing and type choice, and answer the trip planner's read of the visits in the tests instead of leaving it unanswered.	2026-10-20 07:09:56 +00:00