A suite under tests/integration/broadcast-parity boots the app once per
group, runs a write tool through a real MCP session the way the
assistant attaches the registry, runs its REST twin on a twin scene, and
records every broadcast. Per case it checks the exact events in order and
count, that no MCP broadcast skips a socket (the asking tab hears its own
change), that nothing is sent inside a transaction, that every payload
parses with its registered schema, that REST sends the same sequence to
the same room and recipients, and that MCP's keys cover REST's.
A registry test lists the write tools as an MCP client sees them and
fails on a tool without a row, a stale row, or an exemption without a
reason; exemptions run too and must send nothing, and the tools still
waiting for a case are frozen in a list that may only shrink.
The new events the next changes send are registered now (member:updated,
todo:reordered, trips:changed, settings:updated, tags:changed,
notification:read-all, journey:updated, journey:deleted, atlas:changed);
the client keeps them apart as awaiting a sender, and the journey page
already leaves a journey that journey:deleted says is gone.
The server sends accommodation:created and accommodation:updated to the
whole trip, the assistant's writes included, but the client listed both
as ignored and reloaded stays only after a delete. A stay the assistant,
a fellow traveller, a plugin or a booking import added therefore showed
in the sidebar, on the map and in the day panel only after a reload.
Both events now refresh the stays like the deletes do, in the planner
(desktop and phone, which share its hook) and in the day panel. The
refresh is bundled per burst, since one assistant step can apply many
changes, a newer answer always wins over an older one, and a stay being
edited in the day panel that was deleted or moved elsewhere closes its
editor instead of letting the form overwrite another stay.
A browser test books a stay from a second context and sees it appear in
the open planner, on the desktop and on the phone.
- list_budget_items lists a trip's expenses with their ids, payers and
splits, page by page so no page is cut down on its way to a model;
get_budget_per_person answers who paid and owes what. Both in a new
budget-items.mcp.ts, checked like their REST twins.
- get_wind_forecast reads the hourly wind, gusts and direction of a day.
- get_journey_tracks lists a journey's GPX tracks; the line for drawing
rides under a key the provider never receives.
- The Dawarich wishlist scan and the countries the recordings suggest
become tools, with their confirming writes, in DawarichAtlasMcp in the
Atlas group; the shared time window check refuses alike on REST and
MCP, and the model never sees when the user was last seen in a city.
- The journal's map, tracks and recorded days load with the journey
group instead of riding in the core of every step.
- The prompt points at list_budget_items for expense ids (the trip
summary never carried them) and names the shares and the wind tools;
each new read has its own live step.
The hiking costing moves to shared, so the planner and the server ask the
router the same way. The road trip router learns to plan a hike on foot
with that costing (Valhalla only: OSRM knows no trail difficulty), to read
heights along a line in chunks and to read the OSM ways a line follows,
all through its one paced queue. A hike router builds on it: the way, its
heights, distance, climb and DIN walking time, and the SAC grades of its
stretches from the trail grade service, each part best effort.
New MCP tools in HikePlanMcp, in the assistant's tours group:
- propose_hike plans a hike without saving it.
- create_hike saves a confirmed hike through the planner's own creation;
a router that does not answer leaves it pending for the planner, a way
that cannot be planned is refused and nothing is saved.
- update_tour changes a saved hike against its revision, keeping linked
stations and refusing what would silently drop drawn legs or stages.
- import_tour_gpx takes a GPX file's text in as tours, like the import.
Same permission checks as REST, broadcasts from the services.
In the assistant a new hike or city walk is an "Add tour" card with its
route and difficulty, undone through delete_place while the tour is
untouched, and a hike being planned shows as a live step.
'br' is TREK's code for Brazilian Portuguese, but the assistant's strings
and the admin's AI settings added on this branch were written in Breton.
All of them now read in Brazilian Portuguese, in the words the other
Portuguese screens use for trips, days, places, bookings and expenses.
The faint line under a change's name showed its facts as loose icon and
text pairs. They are now the planner sidebar's SoftPill badges, icon and
value in a small round pill, a changed value struck and followed by the
new one inside the same badge. The action stays plain faint text in
front of them, and the line wraps instead of cutting a badge off in a
narrow chat window.
- Tests that still knew the ChatGPT sign-in as personal only follow the
admin's shared plan: the service takes the caller with their role, the
admin tiles show ChatGPT, the controller tests cover the admin routes.
- The table refused an instance ChatGPT connection with a CHECK, so
sharing the plan failed. A new migration rebuilds ai_connections
without that check; the shipped migration stays as it was.
- useChatgptConnect grew past the function size limit: reading the
clipboard and noticing the return to the tab are helpers of their own.
- The file link factory hands its overrides over apart from the row,
like every other factory, which ends the deep type instantiation.
- Knip: exports only their own file used are private again, and the
booking cap reads MAX_WRITES_PER_STEP instead of an alias.
- lint:i18n-keys reaches the tools' own action names through a key
builder and the connection hints through literal keys.
- MMehrSheet stays in the assistant hints pair only.
The Anthropic request marked only the instructions and the trip card for
the prompt cache, so every step of a turn paid the whole history again.
It now also marks the end of the history, which the next step starts
from, and the end of what came before the user's question, which every
step of the turn sends unchanged, within the four marks a request takes.
Every provider now reports how much of the input it read from its cache
(Anthropic cache_read_input_tokens, OpenAI cached_tokens), the turn adds
it up, and the usage log line says it, so the saving can be measured.
The connection for everyone can now also be the admin's own ChatGPT sign-in.
Whether a plan may be shared that way is the self-hoster's call under their
plan and OpenAI's terms; the form says what it means before the sign-in.
The sign-in starts on the admin route and finishes on the shared one, which
refuses a sign-in for everyone to anyone who is not an admin. The ChatGPT
return reads the clipboard only once the paste handler exists.
- The sign-in opens in a small window over TREK instead of a new tab.
- Step 2 shows the address the window ends on, so the error page there is
expected rather than alarming.
- Back in TREK the copied address is read off the clipboard where the browser
allows it and the sign-in finishes; else the field has the cursor.
- The token and OAuth client factories hand their columns over apart from
the row, as the others do (TS2589).
OpenAI offers a fixed web redirect for Sign in with ChatGPT only to selected
commercial partners; open-source apps sign in through the 127.0.0.1 loopback
callback. The relay could never be switched on, so it goes again.
Once the TREK project has a client id registered with OpenAI, the sign-in
goes out with the relay page as its redirect address and the install's own
settings in its state; the relay sends the browser back there and the
settings finish the sign-in, nothing to paste. The relay sees the code but
cannot redeem it without the install's PKCE verifier. Without the project's
client id, or for an install without an https address, the loopback page
and the pasted address stay as they are.
relay/chatgpt-callback/index.html is the page to publish.
A waiting change is one row as in the day list: a round choice in front,
what it touches in bold, a faint line with what happens and when. No switch,
nothing to fold open, no day band: the planner's day list already shows the
suggestion among the day's stops. Whether the days still fit is one pill in
the card's head, with what to look at on hover.
Also mends the comment the rebase onto dev split in json-columns.ts.
- A card for a tool without one of its own names what it works on: the place
of an assignment, the day, the note, the booking; its arguments sit under
the labels the other cards use, a new order reads as the names in order.
28 frequent tools carry their own action name in every language.
- The server's own steps without a card still refuse, as before.
- Tests: the rate limit is asked one request after another, the mention list
closes on the caret move a browser reports, the place factory hands its
category over as a plain id, eleven files formatted.
The assistant offered 25 hand-picked tools. It now offers every tool the MCP
registry holds, but a short denylist with a reason per tool (deleting the
trip, share, invite and feed links, membership changes, fetching an address
the model picks, documents to the provider, instance-wide categories and
holidays). The scopes widen to every addon but trips:delete, the share
scopes, file contents and plugins.
- A tool annotated read-only runs at once, every other one waits as a change
card; reads that fetch a planted address wait too.
- A turn starts with the trip's core tools; use_addon_tools loads tours, road
trip, journey, vacay, atlas, collections, trip chat, files, account or
plugin tools for the rest of the turn.
- A writing tool without a card of its own gets one from its arguments:
add, change or remove, the part of TREK it works in, the trip's days,
places and people named.
- The boot check fails on a tool that shares, invites or publishes and is
neither denied nor known to only take back.
The assistant tables gave Users three more relations, and a spread of
overrides checked against RequiredEntityData now ran tsc past its
instantiation depth (TS2589). Every factory passes its overrides as
createRow's own argument, the way rows.ts documents it.
An answer that searched several times showed only its last search, about
ten places. The strip now holds the places of all its searches, each once
(the same Google or OSM id, or the same name at the same spot), and shows
up to 60.
Maurice