v3.4.0 (#1540)

* 3.3.0 (#1472)

* feat(plugins): grow the frame bridge — fill pages, confirm, openExternal, live context

- page/trip-page hosts pass fill: the frame pins to 100% height and ignores
  trek:resize, so a kit plugin's auto height report no longer collapses a full
  page into a floating island with dead space below (widgets keep self-sizing)
- trek:confirm renders the native ConfirmDialog host-side (the sandbox has no
  allow-modals) and answers trek:confirm:result; one at a time
- trek:openExternal opens validated http(s) URLs in a noopener tab — the
  sandbox has no allow-popups, so plugins simply couldn't link out before
- trek:notify accepts an optional duration, clamped to 1.5-15s
- context gains dir (rtl/ltr) and is re-pushed when locale or format settings
  change, not just on appearance mutations
- core events for the trip in view are forwarded as trek:event — names only,
  never payloads, mirroring the server-side events surface

* fix(plugins): move trip warnings out of the content area

The warning pills overlaid the top of every planner tab at full width, sitting
on the map and its toolbar. Now a warning from a plugin that owns a trip-page
tab renders as a compact chip in the navbar centre (click jumps to the tab; the
navbar centre is free on trip pages), and everything else floats above the
content at the bottom instead. Mobile keeps all warnings in the bottom overlay
since the desktop navbar isn't there. The trip tab's frame also opts into the
new fill mode.

* feat(plugin-sdk): 1.4.0 — motion library + new bridge helpers in the kit

Mirrors the host's animation vocabulary 1:1 into TREK_UI_CSS (menu/popover/
modal/backdrop/toast enters, drawer variant under 640px, page-enter, stagger,
skeleton shimmer, chart reveals) including the reduced-motion degrade to a
gentle fade. window.trek grows confirm(), openExternal(), onEvent() and a
notify duration, and applyContext now stamps lang/dir on the document so RTL
hosts get RTL plugin UIs.

* feat(plugins): surface registry download counts in browse

The registry now aggregates GitHub release download counts per plugin
(TREK-Plugins#18) as an entry-level downloadCount. Project it through
browse/detail and show it as a compact stat on the browse cards and in the
detail meta grid. Counts are raw asset downloads (updates and CI included),
so the UI says downloads, not installs.

* docs(plugins): document the grown bridge surface and motion classes

* fix(plugins): harden the new bridge paths

Review pass over the bridge additions:

- keep the unstable useToast() object out of the effect deps (ref instead) —
  it re-created the effect on every parent render, and with the new live
  repost that meant a trek:context flood into the frame
- reset loads/height/confirm state and key the iframe when a host swaps
  pluginId in place (tab bar, /plugins/:id) — the new plugin's document was
  refused as a 'navigated' frame and every kit promise hung
- confirm dialogs always lead with the host-controlled plugin name so a
  plugin can't dress its dialog up as a TREK system prompt; answer/refuse
  moved out of setState updaters (StrictMode ran them twice)
- Number.isFinite on the notify duration (NaN parked a sticky toast)
- don't forward other plugins' namespaced broadcasts as trek:event; a
  plugin's own plugin:{id}:* broadcasts now reach its frame though
- teach the SDK dev preview the confirm/openExternal contract so
  trek.confirm() resolves in /preview
- 999,950 downloads formats as 1M, not 1000k

* fix(planner): let plugin warning chips grow wider before truncating

The nav-centre chip capped at 340px, so a longer warning (e.g. the TREK x
Japan weather prompt) was ellipsised almost immediately. Scale it with the
viewport up to 520px so most messages read in full while still yielding on
narrow desktops.

* feat(plugins): sort the plugin browser by download count

Discover now honours the sort dropdown (it was always alphabetical) and adds
a 'Most downloads' option that ranks the registry by downloadCount. The sort
keys are scoped per tab — updates-first stays with Installed, most-downloads
with Discover — and snap back to name when the tab can't offer them.

* feat(plugin-sdk): auto-upgrade native <select> to a host-styled dropdown

A sandboxed plugin can't reach the host's components, and a native <select>
draws its popup from the OS — so plugin dropdowns never matched TREK. The design
kit now enhances every <select> into a keyboard-accessible listbox that uses the
kit tokens, keeping the real element as the value/form source (it still fires
change). Authors write a plain <select> and get the host look for free; opt a
field out with data-trek-native. validate warns when a plugin ships a <select>
without inlining the kit.

* feat(plugins): add issue url link

* feat(plugins): reservations write + cross-trip reads

- db:write:reservations -> reservations.create/update/delete, gated exactly like
  the REST/MCP path (reservation_edit + trip membership, acting user host-bound,
  no impersonation) and delegating to ReservationsService so the accommodation,
  budget-sync, booking-notification and reservation:* broadcasts match the web
  app 1:1 — a booking/flight/import plugin can finally write a reservation
- trips.listMine / reservations.listMine: enumerate every trip and booking the
  acting user can access (membership baked into listTrips, never a raw
  cross-tenant SELECT) — dashboards/aggregates were impossible before
- audit: derive auditability from METHOD_PERMISSION so a new capability method
  can't be added un-audited by omission
- typed ctx.reservations.* / ctx.trips.listMine, perm label (en/de), wiki

* feat(plugins): read scopes for journal, atlas, vacay and day notes

- db:read:journal / db:read:atlas / db:read:vacay expose the acting user's OWN
  journals / visited countries+regions / vacation plan across all their trips
  (user-scoped like costs.listMine, each gated on its addon being enabled),
  reusing the addon's existing readers
- db:read:daynotes -> daynotes.list(tripId, dayId), trip-scoped and
  membership-checked like the other trip reads
- typed ctx.journal / atlas / vacay / daynotes, perm labels (en/de), wiki,
  audit resource labels, tests

* feat(plugins): day notes write scope

- db:write:daynotes -> daynotes.create/update/delete, gated under the app's
  'day_edit' permission (like days) with the day verified to belong to the trip;
  reuses dayNoteService and broadcasts the same dayNote:* events so open
  sessions update live
- typed ctx.daynotes.create/update/delete, perm label (en/de), wiki, tests

* feat(plugins): run declared background jobs on a schedule

- plugins already declared jobs {id, schedule} but the cron was never wired. The
  host now schedules them: host-entry reports each job's schedule, the supervisor
  starts the jobs (node-cron) when the plugin goes active and stops them on
  kill/deactivate so nothing leaks
- opt-in via a new jobs:run permission — scheduled work runs with NO acting user
  (its trip reads stay refused; it can only use ctx.db and declared egress), so
  background execution is a distinct, admin-granted capability. Invalid crons are
  skipped and a throwing job can't break the host
- extracted a small, unit-tested scheduler (plugin-jobs.ts); perm label (en/de),
  wiki, tests

* feat(plugins): read scope for saved-place collections

- db:read:collections -> collections.listMine() / collections.get(id): the acting
  user's own collections (user-scoped, gated on the Collections addon), reusing
  collectionsService
- typed ctx.collections, perm label (en/de), wiki, audit resource labels, tests

* fix(plugins): translate new permission labels to all locales + cover the new wiring

- add the 8 new admin.plugins.perm.* labels (reservations/day-notes writes, the
  journal/atlas/vacay/day-notes/collections reads and jobs:run) to the remaining
  20 locales so the strict i18n key-parity test passes again
- cover the create-rpc-host reservation / day-note / cross-trip / addon-read deps
  (the real side-effect wiring the mocked rpc-host tests don't exercise) so the
  src/nest 80% branch-coverage gate holds

* feat(plugins): dev-link — hot-reload a local plugin against real data

Answers a plugin developer's ask: today you either get `trek-plugin-sdk dev`
(fast hot-reload but MOCK/fixture data) or the full build->pack->upload->activate
cycle (real data, no watcher). Neither gives "local dir + hot-reload + real data".

- POST /admin/plugins/link registers a plugin from a LOCAL built directory by
  symlinking it into the plugins volume — the loader already forks the resolved
  real path, so ZERO loader change — and registering it INACTIVE as `local:link`.
  Validates the manifest + refuses native binaries exactly like a sideload.
- POST /admin/plugins/:id/reload re-forks a linked plugin via the existing
  deactivate->activate primitive (same grants, no re-consent unless the manifest
  widened perms). A best-effort fs.watch auto-reloads on rebuild.
- It runs through the UNCHANGED capability RPC host: real, membership-gated data,
  acting user host-bound, no impersonation — code origin never touches the gate.
- Gated behind TREK_PLUGINS_DEV_LINK on top of admin + kill-switch, because a
  linked plugin bypasses the install-time signature model and, under `npm run
  dev`, the OS jail is off. Off by default; never reachable in production.
- discovery follows a symlinked <root>/<id>; uninstall/link never delete the
  author's source (link-safe removal for POSIX symlinks and Windows junctions).

* docs(plugins): document the dev-link real-data hot-reload workflow

Adds a "Test against a real instance's data (dev-link)" subsection next to the
mock-data SDK preview: TREK_PLUGINS_DEV_LINK, POST /link with a local built dir,
activate + consent, hot-reload via the file-watch / POST /:id/reload / Restart,
and the dev-only security caveats.

* feat(plugins): dev-link admin UI

- surface devLink (TREK_PLUGINS_DEV_LINK) in GET /admin/plugins so the panel shows
  the link form only where dev-link is enabled
- AdminPluginsPanel: a "Link a local plugin" form (path -> POST /link), a Dev-Link
  badge for source_repo=local:link, and adminApi.pluginLink/pluginReload
- fix: the plugin menu treated any non-local:upload source_repo as a GitHub repo,
  so a dev-linked plugin rendered github.com/local:link links — exclude local:link
- labels for the 6 new dev-link UI strings across all 22 locales

* docs(plugins): document the dev-link admin UI

The dev-link section showed only the curl call — surface the Admin → Plugins
"Link a local plugin" field (the primary path) and the Dev-link badge, with curl
kept as the scripting alternative.

* feat(plugins): enrich core events with { entity, entityId }

Subscribed plugins now learn WHICH entity changed, not just the event name — a
reservation/place/day/... id derived host-side from an explicit per-family
whitelist. Threaded through the six event hops WITHOUT touching actingUserId: the
handler still runs with no user, so the id is not dereferenceable (a trip read is
still refused; the id says what to react to, not what it contains). A non-entity id
can never surface — budget:member-paid-updated yields the itemId, never the userId
— and bulk/reorder/sub-entity payloads carry no id. The mapper is pure, synchronous
and never throws into the core broadcast. No new permission (reuses
events:subscribe); backend-only.

* feat(plugins): packing write scope with #858 privacy-scoped broadcasts

- db:write:packing -> packing.create/update/delete, gated under the app's
  'packing_edit' permission (like the REST path) with the host-bound acting user
  as owner; reuses packingService
- replicates the packing privacy model 1:1 (the controller/service helpers aren't
  exported): create/delete fan out to the item's viewers only (owner + recipients,
  or the whole room for a Common item); update runs the four public<->private
  transitions, dropping a freshly-privatized item from the room BEFORE re-adding it
  owner-only so it never leaks. A stale write is BAD_PARAMS with no broadcast
- typed ctx.packing.create/update/delete, perm label (22 locales), wiki, tests
  (rpc-host gating + the four transitions + owner-scoped delete)

* feat(plugins): tableContributor hook — host-rendered view columns/actions (backend)

The registry backend for plugin-contributed columns/actions in the native planner
views (the tabular-reservations use case), mirroring placeDetailProvider:
- hook:table-contributor + the tableContributor hook (getContributions(view,
  tripId, ctx) -> TableContribution[]), double-gated (implement + grant) like the
  other provider hooks
- GET /api/view-contributions/:view/:tripId — view whitelist + membership gate +
  per-provider timeout/fail-safe, plus the hardening the older provider hooks lack:
  every field is String-coerced + length-capped, kind/tone/target enum-whitelisted,
  per-provider counts capped (<=20 columns / <=10 actions), and a column url must be
  http/https/mailto (a javascript:/data: url is click-XSS into the native DOM)
- typed pluginsApi.viewContributions + the ViewContribution union, perm label
  (22 locales), wiki, hardening tests

* feat(plugins): render tableContributor columns/actions in the reservations view

The frontend for the tableContributor hook: a reusable PluginContributions layer
(usePluginViewContributions + PluginColumns/PluginActions) that renders the
host-normalized column/action leaves NATIVELY — a column is text/badge/link, an
action is a button that calls the plugin route or opens its sandboxed frame in a
modal (plugin markup only ever runs inside the opaque-origin iframe). Wired into the
reservations cards (both ReservationCard and TransitJourneyCard) as a strictly-
additive footer keyed by reservation id: zero change to a card when no plugin
contributes. Fetched once per view, fail-safe.

* docs(plugins): bring the permissions wikis current with this cycle

Plugin-Permissions.md was missing every permission added this cycle — add rows for
the read scopes (journal/atlas/vacay/daynotes/collections), the write scopes
(reservations/daynotes/packing, packing noting the #858 owner-scoping), jobs:run
and hook:table-contributor, and correct the events:subscribe row for the new
{ entity, entityId } hint. Add the jobs:run row to Plugin-Development.md too.

* fix(maps): stop quick one-finger pans zooming the map on mobile (#1440)

The global drag-drop-touch polyfill installs document-level touch listeners
on phones. On every single-finger touchend it records a timestamp, and if the
next touch starts within 500ms it synthesises a dblclick on the target, which
the map's default double-click-zoom turns into a zoom-in. Two quick one-finger
pans therefore zoomed instead of panning.

The polyfill only bridges HTML5 drag-and-drop to touch for planner reordering,
which is already disabled on mobile (#1432), so gate its import to viewports
>=1024px (the lg breakpoint useIsMobile uses). Removes the phantom-dblclick
source on phones while keeping touch DnD on large viewports; fixes both the
Leaflet and GL renderers.

* fix(feeds): emit TZID + VTIMEZONE so subscribed calendars respect time zones (#1453)

exportICS emitted timed DTSTART/DTEND as bare floating times (no Z, no TZID),
which iOS/Google Calendar render in the subscriber's local zone instead of the
zone TREK shows. Resolve an IANA zone per timed event — transport endpoints use
their stored timezone (departure drives DTSTART, arrival drives DTEND), while
assignments and hotel/restaurant reservations derive it from place coordinates
via tz-lookup — and attach TZID backed by a VTIMEZONE component. The all-trips
feed now carries deduped VTIMEZONE blocks so TZID references still resolve.

* feat(plugins): render tableContributor contributions in the places + day views

Extends the tableContributor frontend to all three planner views: hoist the shared
PluginCardFooter into PluginContributions, wire the places sidebar (keyed by place
id, rendered as a sibling after each row so the drag/scroll row stays untouched)
and the day panel (keyed by day id, guarded for a null day). Strictly additive +
fail-safe like the reservations view — nothing renders when no plugin contributes.

* fix(vacay): source holiday subdivisions from ISO 3166-2 so all states show

The state/region picker for public-holiday calendars was built from the
union of each holiday's counties for the current year, so a subdivision
only appeared if some holiday that year was tagged with it. States with
no state-specific holiday (e.g. US-WA, and AR/FL/NV/WY in 2026) silently
vanished, blocking calendar creation (#1456).

Source the full, correctly-named subdivision list per country from
ISO 3166-2 instead, merged with any nager county code ISO lacks. Only
region-partitioned countries get a picker, so nationwide-only countries
keep allowing a country-level calendar. No server change needed —
selecting a state already yields federal holidays via applyHolidayCalendars.

* fix(costs): settlements honor custom per-member splits (#1458)

calculateSettlement read each member's custom split amount but its query
never selected budget_item_members.amount, so hasCustomSplit was always
false and every settlement fell back to the equal split. Select bm.amount
so custom amounts drive the balances.

Also blank the Overview 'Per Person' / 'Per Person·Day' columns and CSV
for custom-split items, where a single averaged figure is meaningless.

* feat(plugins): read-convenience + todos + packing bags + tags + roster

A wave of small, high-value capabilities:
- weather:read (ctx.weather.get) — the host's cached forecast, tenant-free
- db:read:categories (ctx.categories.list) — the global place-category list
- db:read:tags / db:write:tags (ctx.tags) — the acting user's own tags, ownership
  re-checked before each write
- trips.members (ctx.trips.members) — the trip roster (id + display fields),
  membership-checked
- db:read:todos / db:write:todos (ctx.todos) — a trip's to-dos, gated by the app's
  packing_edit like the REST path, broadcasts todo:*
- packing bags on ctx.packing (listBags/createBag/updateBag/deleteBag/setBagMembers)
  under db:write:packing — no privacy, plain room broadcasts
perm labels (22 locales), both wikis, rpc-host gating + create-rpc-host wiring tests

* fix(dashboard): render next-trip boarding pass stats on Safari (#1459)

The boarding-pass bar carved its ticket-stub notches with a two-layer
radial-gradient mask composited via mask-composite: intersect (and legacy
-webkit-mask-composite: source-in). Safari mis-composites that multi-layer
path to fully transparent, hiding the entire stats bar while Chrome renders
it fine.

Split .hero-pass into an outer wrapper (left notch) and a .hero-pass-inner
glass panel (right notch), each carrying a single-layer mask so the
mask-composite path is never exercised. Renders identically across engines
and degrades safely where mask-image is unsupported.

* feat(plugins): write scopes for atlas, vacay, journal and collections

The write half of the user-scoped addon reads:
- db:write:atlas -> ctx.atlas.markCountry/unmarkCountry/markRegion/unmarkRegion +
  bucket-list create/delete. Every row is the acting user's own (visited_countries/
  visited_regions/bucket) — no trip scoping, no cross-tenant surface. Unblocks
  AirTrail-style two-way sync (#214)
- db:write:vacay -> ctx.vacay.toggleEntry/toggleCompanyHoliday. The plan is
  resolved HOST-SIDE from the acting user's active plan — a plugin can never name
  another plan, and toggleEntry only toggles the acting user's own PTO day
- db:write:journal -> ctx.journal.createEntry/updateEntry/deleteEntry, self-gated
  by journeyService.canEdit (owner/contributor) against the acting user
- db:write:collections -> ctx.collections.create/update/savePlace/copyToTrip/
  deletePlace, schema-validated; the service's per-collection role checks
  (assertAccess 404 / assertCanEdit 403) map onto RESOURCE_FORBIDDEN
All addon-gated, userless contexts refused, audited. Perm labels (22 locales),
both wikis, gating + wiring tests.

* fix(admin): name the Costs add-on consistently in the catalog

The budget add-on catalog entry still resolved to 'Budget' while the
feature is labeled 'Costs' everywhere else (trip tab, navbar). Align
admin.addons.catalog.budget.name with each locale's trip.tabs.budget
label. Closes #1464

* feat(plugins): file attach, collab content and gated member-add

- db:write:files -> ctx.files.create/createLink/update/softDelete under the app's
  separate file_upload/file_edit/file_delete rights. Content arrives as bounded
  base64 (10MB decoded cap, well under the app's 50MB), the extension is validated
  against the central blocklist BEFORE anything touches disk, and link targets
  must live on the same trip (findForeignLinkTarget). Broadcasts file:*
- db:write:collab -> ctx.collab.createNote/createPoll/votePoll/createMessage
  under collab_edit + the Collab addon, emitting the same collab:* events as the
  app; service-reported errors surface as BAD_PARAMS
- db:write:members -> ctx.trips.addMember. Adding a member GRANTS TRIP ACCESS, so
  it is deliberately its own permission behind the app's member_manage right
  (default: trip owner only) and never bundled with a lower-risk write; the acting
  user is recorded as the inviter, target must exist, owner/duplicate adds no-op
Perm labels (22 locales), both wikis, gating + wiring tests.

* fix(maps): honor check-in/out times for hotel bookend legs (#1465)

The day route drew the accommodation as the day's start/end whenever the
edge stop was a place, ignoring the morningIsSleptHere/eveningIsOvernight
provenance already computed by getDayBookendHotels. On a check-in day an
airport placed before check-in got a spurious hotel -> airport leg, and on
a check-out day a later "home" stop still got a home -> hotel return leg.

Add time-aware shouldDrawMorningLeg/shouldDrawEveningLeg helpers: the
morning leg is the home-base default on a check-in day but is dropped when
the first place is timed before check-in; the evening return leg is off on
a check-out day unless the last place is timed at/before check-out. Wire
them into the map polyline, the sidebar hotel connectors, and the Google
Maps export so all three stay consistent.

* feat(plugins): host-mediated notifications and LLM access

Two host-owned integration primitives — the plugin supplies intent, the host
owns the sensitive part:

- notify:send -> ctx.notify.send({title, body, link?, scope, targetId}). Delegates
  to notificationService.send with a new plugin_notification event (raw title/body
  carried as passthrough params), so recipient resolution, channel fan-out
  (bell inbox + email/ntfy/webhook) and per-user preferences all match core 1:1.
  Recipients are FORCED to the acting user (scope 'user', targetId === uid) or a
  trip they belong to (scope 'trip'); scope 'admin' refused; the in-app link must
  be a relative /path (open-redirect-safe). No arbitrary recipient, no impersonation.
  Users can mute plugin notifications like any other event.
- ai:invoke -> ctx.ai.complete(prompt) / ctx.ai.extract(text, jsonSchema). Runs the
  admin/user-configured provider via resolveLlmConfig + the existing extraction
  client under the acting user; the host holds the (encrypted) key, the plugin
  never sees it. Refused when no provider is configured; 20k-char caps. Output is
  DATA (complete -> {text}, extract -> {results}) and never auto-written, so
  prompt-injection can't reach a write without the plugin's own gated call.

plugin_notification wired through the shared NotificationEventKey + all 22 locales
(inbox passthrough + external channels). Perm labels (22 locales), both wikis,
gating + wiring tests.

* fix(budget): offer every Frankfurter-supported currency (#1470)

The cost currency picker was gated by a hardcoded 47-code list, so
currencies the app can actually convert (OMR, CRC, UGX, MKD, ALL, and
~115 more) couldn't be selected. Replace CURRENCIES/SYMBOLS with the full
set the Frankfurter v2 FX API supports (archived BGN/HRK dropped), unify
the dashboard offline fallback onto it, and teach currencyDecimals about
the newly reachable zero- and three-decimal currencies. A currenciesWith
helper keeps a previously saved (now-archived) selection selectable so it
isn't silently wiped.

* feat(plugins): tableContributor into the costs, packing and files views

Extends the shipped tableContributor hook to three more native views — no new
permission, no new attack surface: the same host-normalized, length-capped,
url-allowlisted (http/https/mailto), enum-bounded, fail-safe pipeline, just more
render sites.

- server: add costs/packing/files to the view-contributions whitelist
- client: widen the ViewName union + the api view type; render PluginCardFooter
  keyed by entityId in the budget category table (a colSpan footer row per item),
  the packing category group (footer after each item row, drag untouched) and the
  files list (footer after each row)

A currency plugin can now drop a converted-amount column onto a cost row, a
receipts plugin a 'view receipt' action onto a file, etc. Controller test asserts
the three new views are accepted; both wikis updated.

* fix(pdf): repeat day header on overflowing itinerary export pages (#1471)

* feat(plugins): map-marker provider hook — plugins can overlay trip-map markers

New declarative provider hook `mapMarkerProvider` (#587 "show bookings on map",
the single most-requested contribution class, with zero contribution point until
now):

- hook:map-marker-provider permission + MapMarkerProvider/MapMarkerContribution SDK
  types + HOOK_PERMISSION wiring
- GET /api/map-markers/:tripId (MapMarkersController) mirrors the view-contributions
  hardening: membership-gated, providers invoked host->plugin on a 5s timeout,
  fail-safe. Every field normalized server-side — coordinates range-checked
  (-90..90 / -180..180), strings String-coerced + length-capped, icon/tone enum-
  whitelisted, popup url http/https/mailto only (a javascript:/data: url would be
  click-XSS), marker count capped at 200 per plugin
- client: PluginMapMarkers layer renders the markers as plain Leaflet Marker+Popup
  inside the trip map; plugin JS NEVER runs on the map canvas, every value is
  host-vetted data. Threaded tripId through MapView; fail-safe fetch

Declarative-only by design, mirroring placeDetailProvider/tableContributor. Perm
label (22 locales), controller hardening test, both wikis.

* feat(plugins): show page plugins in the mobile bottom nav

Page plugins were reachable from the desktop nav pill (Navbar) but not the mobile
tab bar — you had to type /plugins/:id. BottomNav now reads page plugins from the
plugin store and appends them the same way global addons are, mirroring Navbar.
One-file client nav wiring; no new capability surface.

* feat(plugins): per-user plugin settings form + ctx.settings runtime read

Users can now enter their own per-plugin config (an API key, a preference) —
the prerequisite for almost every real integration, previously unreachable
(scope:'user' settings were only listed read-only in the admin panel).

- migration: plugin_user_config (plugin_id, user_id, config JSON) — each user's
  own values, separate from the admin-owned instance plugins.config
- PluginsService.getUserConfig / updateUserConfig / getUserConfigDecrypted +
  readUserSettingDecrypted: secrets encrypted at rest (apiKeyCrypto), masked to
  the client, an unchanged secret (the mask) keeps its stored ciphertext, and only
  DECLARED scope:'user' keys are ever stored
- GET/POST /api/plugin-settings/:id (PluginUserSettingsController) — its own
  user-gated path (not the admin surface, not the /:id/* proxy), JwtAuthGuard only,
  scoped to the acting user
- runtime: ctx.settings.get(key) -> the acting user's decrypted value (unconditional
  RPC, not sensitive cross-tenant; userless job/onLoad gets undefined)
- client: a Plugins tab in Settings host-renders each active plugin's scope:'user'
  fields as an editable form (secrets write-only), reusing the declarative field
  shape — no plugin markup executes

i18n (22 locales), wiki, rpc-host + service + masking/encryption tests.

* fix(journey): keep skeleton suggestions in sync with linked trip places (#1473)

Journey skeleton suggestions mirror a linked trip's day-assigned places, but
sync relied on scattered per-event hooks that several assignment mutation paths
never called: unassign, move and time-change fired nothing, no remove-on-unassign
capability existed, and every MCP assignment tool synced nothing. Skeletons drifted
from the trip.

Add an idempotent reconcileTripSkeletons(tripId) that re-mirrors the trip's
day-assigned places onto every linked journey (add missing skeletons, refresh
date/time/location on move, remove skeletons for unassigned places; filled entries
are detached + noted, never destroyed). Call it from every REST assignment handler
and MCP assignment tool, and fire onPlaceDeleted on single MCP delete_place for
parity. Extract a shared insertSkeletonEntry helper.

* fix(memories): drop hidden Immich assets so Live Photo motion parts don't show a broken thumbnail (#1474)

* fix(transit): anchor arrive-by search time to the destination timezone (#1479)

* feat(plugins): host-brokered OAuth client + trustworthy inbound webhooks

Two integration primitives where the host owns the sensitive part.

Trustworthy webhooks:
- auth:false routes now receive req.headers, but ONLY an explicit, credential-free
  allowlist (the common provider signature/event headers — stripe-signature,
  x-hub-signature-256, svix-*, x-gitlab-event, …). Cookie/Authorization/X-Socket-Id
  and every session/forwarded-auth header are stripped; authenticated routes get {}.
  A plugin can finally verify a provider signature without any way to leak a session.

Host-brokered outbound OAuth (oauth:client):
- the HOST runs the whole flow — authorize -> callback -> token exchange -> refresh —
  with PKCE + single-use, user-bound, TTL'd state, and HOLDS the tokens. The client
  secret + refresh token never leave the host; the plugin only triggers connect and
  reads a short-lived access token via ctx.oauth.getAccessToken() for the acting user.
- provider config (authorize/token url + scopes + client id/secret) is the plugin's
  admin-owned instance settings; endpoints must be https (SSRF backstop, private/local
  hosts refused). Tokens per-user + encrypted at rest (apiKeyCrypto).
- GET/POST /api/plugin-oauth/:id/{status,connect,callback,disconnect} — JwtAuth-gated,
  the callback always redirects to an in-app /settings path (never leaks an error).
- Settings -> Plugins gains a Connect/Disconnect control per configured plugin.

migration: plugin_oauth_tokens + plugin_oauth_state. Perm labels + form strings
(22 locales), both wikis, service (PKCE/state/exchange/refresh/encrypt) + controller
+ proxy header-allowlist + rpc-host gating + create-rpc-host wiring tests.

* fix(navbar): re-measure sliding tab pill after font load and resize (#1481)

The active tab pill was measured once in a layout effect keyed only on activeTab, so on a hard reload it captured the active (bold) label's width against fallback-font metrics and never re-ran when the web font swapped in, leaving the pill slightly offset.

Re-measure after document.fonts.ready resolves and on ResizeObserver changes (container + active button), with an idempotent state update to avoid redundant renders.

* fix(collections): keep the Add-place button reachable after the first save

On a wide/desktop layout the collection toolbar (which hosts the Add
button) was gated on !mapOverlay, so it unmounted as soon as the list
gained its first place with coordinates — leaving only an easy-to-miss
"+" in the map overlay. Keep the toolbar rendered whenever the user can
add a place, and drop the now-redundant map-overlay Add button so there
is a single, predictable Add affordance in every state.

Fixes #1485

* feat(plugins): days + accommodations reads/writes, endpoints on the reservation write path

Community feedback on the 3.2.1 plugin surface: a plugin could write days but
never list them (no way to learn day ids), day_accommodations had no surface at
all, and trips.getReservations was the one reservation read that dropped the
endpoints/day_positions hydration.

- trips.getDays / trips.getAccommodations under db:read:trips (tripRead gate),
  wired to the same dayService lists the REST GETs use
- trips.getReservations now returns the hydrated REST-parity list (endpoints,
  day_positions, joins, normalized accommodation_id) - strict superset
- new db:write:accommodations scope: ctx.accommodations create/update/delete
  gated by day_edit like the accommodations REST path, with the partner-hotel
  reservation + delete cascade and broadcasts intact
- reservation create/update pin the endpoints shape up front (BadParams instead
  of a mid-transaction NOT-NULL or a silently dropped row)
- perm label in all 22 locales, consent PERM_KEYS, wiki tables

* feat(plugins): day-detail widget slot in the day panel

Widgets can now mount inside the trip planner's day panel
(capabilities.widget.slot: 'day-detail'), scoped to the open day via a dayId in
trek:context - the same pattern as the place-detail slot. Covers the requested
per-day plugin content (logistics, outfit planning, live flight status) without
a new plugin type. Day-detail widgets stay off the dashboard, the consent panel
labels the slot in all 22 locales.

* feat(plugins): let the frame CSP serve a plugin's own static assets

The sandboxed frame runs at an opaque origin, so script-src 'self' never
matched and a plugin's own <script src>/<link> files were blocked - authors had
to inline entire React builds into index.html. Add a scheme-less host-source
pinned to the plugin's own /plugin-frame/<id>/ path (charset-checked Host +
plugin id so a stray token can't widen the policy; malformed Host falls back to
inline-only). Multi-file client builds now load as-is; remote hosts stay
blocked, so script URLs remain useless as an egress channel.

* fix(plugin-sdk): catch the package up to the server capability surface

The npm SDK's validator still knew only the 3.2.1 permission set, so
'trek-plugin-sdk validate' (and pack/publish, which run it) hard-rejected any
manifest using the newer scopes - db:write:reservations, notify:send,
hook:map-marker-provider and 25 more. Sync KNOWN_PERMISSIONS with the server
envelope (48 entries), mirror the full PluginContext (reservations,
accommodations, notify/ai/oauth/settings, packing writes + bags, file writes,
collab, tags/todos/daynotes/collections/atlas/vacay/journal, weather,
categories), type the tableContributor/mapMarkerProvider hooks + the
entity/entityId event hint, accept the day-detail widget slot, and extend
createMockHost so plugin unit tests can exercise all of it.

* feat(plugins): grant-scoped entity snapshots on core events

An events:subscribe handler so far learned only WHICH entity changed - useful
for cache busting, useless for reacting to content, and the userless handler
can't refetch. Now the broadcast tap derives a whitelisted field snapshot of
the changed entity and the supervisor attaches it per plugin, only where the
granted set holds the family's matching db:read:* permission (trips family ->
db:read:trips, budget -> db:read:costs, packing -> db:read:packing, dayNote ->
db:read:daynotes, file -> db:read:files). No acting user is ever synthesized.

The whitelists are explicit per family, so user ids (owner/paid_by/uploaded_by/
participants/members), trips.feed_token and future migration columns never
travel; a private packing item (#858) yields no snapshot at all because its
core broadcast is owner-scoped; deletes/reorders/bulk ops carry none.

* feat(plugins): pdf-section, atlas-layer and journal-entry provider hooks

Three more declarative provider surfaces in the map-marker mould - plugins
return data specs, the host normalizes, caps and renders; a slow or failing
provider contributes nothing:

- hook:pdf-section-provider: sections (title + paragraphs + a simple table)
  appended to the trip PDF export, escaped into the same HTML/print pipeline
  as the core content
- hook:atlas-layer-provider: per-user country tint layers on the Atlas map
  (ISO 3166-1 alpha-2 codes only, tone-whitelisted, non-interactive pane so
  mark/unmark clicks keep working)
- hook:journal-entry-provider: extra rows on a journal entry card, gated by
  the same journey access check as the journal routes + the Journey addon

Permission labels in all 22 locales, consent PERM_KEYS, SDK types + manifest
validator in both SDK copies, wiki tables, per-controller hardening tests.

* feat(plugins): trip-page plugins can replace core planner tabs and pick their spot

A trip-page plugin that takes over a core surface (a transit planner
superseding Transports, a costs plugin superseding the budget tab) had to sit
awkwardly next to the tab it replaces. capabilities.tripPage now names the
core tabs to hide while the plugin is active - whitelisted (transports,
buchungen, listen, finanzplan, dateien, collab), 'plan' deliberately not
replaceable, and the tabs return the moment the plugin is deactivated - plus
an optional 0-based position for the plugin's own tab. The feed re-validates
the values out of the DB blob so a hand-edited row can't hide anything else,
the admin list chips a replacing plugin (all 22 locales), and a saved session
tab that got replaced falls back to the plan view.

Also fixes the plugins feed dropping the day-detail widget slot to 'sidebar',
which would have mounted a day-panel widget on the dashboard.

* fix(plugins): audit follow-ups — normalization, secret cleanup, cron leak, slot filter

Adversarial audit of the whole plugin PR surfaced 12 confirmed issues; this
addresses them:

- place-details provider was the ONE hook controller with no normalization: a
  plugin's href/label/value went to the client raw and unbounded. Now normalized
  like journal-entry-rows (safeUrl http/https/mailto, length + count caps).
- trip-warnings capped message length + per-provider count (was unbounded).
- uninstall(deleteData) now also purges plugin_user_config, plugin_oauth_tokens,
  plugin_oauth_state, plugin_meta_migrations and the capability audit — encrypted
  per-user API keys + OAuth refresh tokens no longer survive a 'delete all data'
  and get silently re-adopted on a same-id reinstall.
- supervisor: a crash-restart cycle leaked the dead child's node-cron tasks and
  re-scheduled fresh ones, so a job fired N+1 times per tick after N crashes.
  onExit now stops them, mirroring kill().
- dashboard sidebar no longer mounts place-detail/day-detail widgets (they belong
  in the planner panels).
- reservation endpoint validation relaxed to match the 3.2.1 service: a coord-less
  endpoint is accepted and dropped downstream instead of BadParams (no breaking
  change), while a bad role/non-string still rejects up front.
- a replaced core tab reached by programmatic nav now falls back to the plan view.
- trips.update caps title/description like the places path; plugin-db guard bans
  load_extension as defense-in-depth.
- wiki: event snapshots, string-typed context ids, dayId in the payload, the live
  provider hooks and the costs update/delete grant are now documented correctly.

* feat(plugins): phase-0 lifecycle hardening + per-plugin RPC rate limit

Operational-readiness fixes from the completeness audit:

- Re-activation after a failure worked again: a plugin left in 'error' state by
  a load-failure or crash-auto-disable stayed in the running map, so the admin's
  'enable' button was a silent no-op. activate() now replaces a dead entry.
- Per-plugin RPC rate limit at the dispatch boundary: every ctx.* call runs
  synchronously on the host thread, so a plugin in a tight loop could freeze the
  whole instance (and the reap sweep). A token bucket (generous burst) + an
  in-flight cap now throttle a runaway plugin with a retryable HOST_ERROR; a
  legitimate plugin never notices.
- plugin_error_log retention (500 rows/plugin) so a crash-looper can't grow
  trek.db without bound; the crash-timestamp array is trimmed to its window too.
- TREK_PLUGIN_PERMISSIONS=off now logs a loud one-time warning that the OS
  permission jail is disabled.

* feat(plugins): read symmetry + broker — collab/journal/atlas reads, file content, trip create, rates

The plugin API leaned write-heavy: collab and journal could be written but not
read, files listed but not read, and there was no way to create a trip or see
exchange rates. This closes those gaps in the established RPC+gate pattern (zero
architecture risk), and it's what unlocks the importer + finance plugin classes:

- collab reads: ctx.collab.listNotes/listPolls/listMessages under a new
  db:read:collab (membership + Collab addon, like the REST GETs)
- ctx.journal.getEntries(journeyId): a journey's entries, journey-access-checked,
  under the existing db:read:journal
- ctx.atlas.bucketList(): the acting user's bucket list, under db:read:atlas
- ctx.files.getContent(tripId, fileId): a file's bytes as base64 under a NEW
  db:read:files:content grant (reading a passport scan is more sensitive than its
  filename), size-capped at 10MB before it crosses the IPC pipe, trashed files
  refused
- ctx.trips.create(input): a new trip owned by the acting user, gated by the app's
  trip_create right + a bound user — the capability importers need
- ctx.rates.get(base): cached currency exchange rates, tenant-free like weather

Also caps trips.update title/description like the places path, and the plugin-db
guard now bans load_extension (defense-in-depth). SDK, mock-host, i18n (22
locales), consent labels and the wikis are all in lockstep.

* feat(plugins): deeper integration + user-facing activity transparency

Wave 2 of the completeness work — richer extension points, deeper metadata, and
the transparency that makes the broad read grants accountable:

- db:meta now attaches to reservations + accommodations too (not just
  trip/place/day), gated by reservation_edit / day_edit respectively — the
  natural home for an external-id mapping (AirTrail/calendar/booking-import sync)
  without forking the core schema.
- reservation-detail widget slot: a widget can mount on a booking card, scoped to
  the open reservation via reservationId in trek:context (the place-detail /
  day-detail pattern, third instance).
- tableContributor gains the transports + todos views, so a plugin can add
  host-rendered columns/actions there too.
- User activity log: GET /api/plugin-activity + a Settings → Plugins panel showing
  every host-mediated action a plugin took bound to the signed-in user, across all
  plugins, newest first — the user-facing half of the hash-chained audit. This is
  what legitimizes the deliberately broad read grants: not just the admin, the
  person whose data is read can see what was done in their name.
- DX: the local dev server now binds a default acting user, so the canonical
  ctx.trips.getPlaces(tripId) call works locally instead of failing RESOURCE_
  FORBIDDEN; the create scaffold drops the dead manifest routes[] / capabilities.nav
  fields the host ignores.

SDK, i18n (22 locales), consent labels and the wikis are all in lockstep.

* fix(memories): load Immich album photos on Immich v3

Immich v3 removed the `assets` property from AlbumResponseDto, so
`GET /api/albums/:id` no longer carries album contents. TREK read album
photos from that property, which now parses as undefined and degrades to
an empty array — hence "No photos yet" in the Journey gallery picker even
though the album header shows the right count (that count comes from
`GET /api/albums` -> assetCount, which v3 still returns).

Two call sites read the removed property. Besides getAlbumPhotos (the
reported bug), syncAlbumAssets failed silently on v3: it reported
`success: true, added: 0` while syncing nothing.

Fetch album contents via an `albumIds`-filtered `POST /api/search/metadata`
when `assets` is absent, and feature-detect rather than probe a version.
The two paths are not interchangeable: on v2, searchMetadata
unconditionally scopes results to `[self, ...partners]`
(`asset.ownerId = ANY(userIds)`), so an albumIds search against an album
shared by a non-partner returns nothing. v3 added an albumIds branch that
checks AlbumRead and skips that owner filter. v2 also hard-defaults
`visibility` to `timeline`, dropping archived assets. So v2 must keep
reading the album detail body, which this preserves exactly.

`withExif: true` is required on the search path: it has no default and
gates an inner join, so without it Immich omits `exifInfo` entirely and
every photo's city/country goes null.

The existing test mock returned an album detail body *with* `assets` — it
encoded the v2 assumption, which is why this shipped green. It now models
v3 by default, with explicit v2 coverage asserting no search call is made.

Fixes #1492

* feat(plugins): daily AI/notify budgets, runtime scheduler & reliable event redelivery

Per-plugin daily caps on ai.complete/ai.extract and notify.send (defaults
200 / 100, overridable via TREK_PLUGIN_AI_PER_DAY / TREK_PLUGIN_NOTIFY_PER_DAY),
seeded from the capability audit so a mid-day restart resumes the count instead
of resetting it. Surfaced at GET /plugins/:id/budget.

ctx.scheduler (at / in / every / cancel): persistent, userless timers that
survive restarts and fire a scheduled() handler, riding the existing jobs:run
grant so no new consent or admin setup is needed. Backed by
plugin_scheduled_tasks, swept every 30s, capped at 100 tasks/plugin with an 8 KB
payload and a 60s recurring floor; rows are removed on uninstall.

Core events that fire while a subscriber is mid-restart are now held in a
bounded in-memory buffer (200/plugin, 15 min TTL) and replayed once it goes
active again, with the events:subscribe grant and snapshot gating re-evaluated
at replay time so nothing leaks if a grant was revoked while the plugin was down.

* feat(plugins): GDPR data-subject rights — durable per-plugin erasure + export

New hook:user-data grant with two userless lifecycle handlers a plugin can put
on its definition: deleteUserData and exportUserData. Neither carries an acting
user — the plugin only learns the userId and touches its own db — so the grant
reads nothing from core data; it exists purely so a plugin can honour a GDPR
erasure or data-access request.

When a TREK account is deleted (admin or self-service), every installed plugin
holding the grant gets a row in a new durable erasure queue and its
deleteUserData runs on the next sweep, retried until it ACKs — so erasure
survives the plugin being offline or the server restarting. The core deletion
path notifies the runtime through a dependency-free relay (like the event sink),
keeping the auth/admin services decoupled from the plugins layer, and a plugin
bookkeeping error can never fail the account deletion.

Portability is served by GET /api/admin/plugins/user-data/:userId/export, which
fans exportUserData out to the active granted plugins and aggregates what each
holds about the user. Queue rows are purged on uninstall; the grant is labelled
in all 22 locales.

* feat(plugins): atomic ctx.db.tx for consistent multi-write on a plugin's own db

Plugins could already query/exec/migrate their own SQLite file, but a multi-step
write (move an item between tables, decrement one row and increment another) had
no way to be atomic. db.tx([{sql, args?}, …]) runs up to 100 statements in a
single transaction — all commit or all roll back — and reads within the batch see
its own earlier writes, so read-modify-write is safe. Each op is one statement:
a read returns { rows }, a write { changes }. The same guard (no ATTACH/PRAGMA/
RECURSIVE, size + row caps) applies to every statement in the batch.

* fix(memories): filter hidden Immich assets at the source, not just the picker

#1474 has the same root cause as #1492: the Immich v3 migration. On v2,
searchAssetBuilder hard-defaulted metadata search to `timeline` visibility
(`visibility = options.visibility ?? Timeline`), so hidden Live Photo
motion parts could never come back from a search. v3 defaults to any
visibility except `locked`, so they do — which is why the reporter is on
Immich 3.0.1 and why the bug never appeared before.

Ask for `visibility: 'timeline'` explicitly on the search path. That
restores v2 semantics on both versions and stops hidden assets crossing
the wire, which also fixes a pagination wart: a full page half-made of
motion parts previously rendered as a half-empty page, because hasMore
counts the raw page length while the filter shrinks the rendered set.

The client-side filter was display-only, applied in searchPhotos and
getAlbumPhotos — both picker-listing paths. Nothing guarded persistence
or rendering: getOrCreateTrekPhoto stores any id it is handed, pipeAsset
forwards Immich's 400/404 verbatim, and the photo grid is a plain <img>
with no onError. So syncAlbumAssets, which filtered `type === 'IMAGE'`
only, could persist a hidden IMAGE as a permanently broken tile. It now
applies the same guard, extracted as isVisibleAsset().

Albums keep their filter rather than requesting `timeline` visibility:
albums legitimately contain archived assets, and both the v2 album body
and the v3 album search return them.

Does not address tiles already persisted before this — those still render
broken and need a separate fix.

Refs #1474

* docs(memories): correct Immich version boundaries in the hidden-asset comments

Verified against the v1.120.0 → v3.0.0 OpenAPI specs and server source. The
previous comments said "Immich v2 hard-defaulted metadata search to timeline
visibility". That is true only for 1.133–1.144.

- `visibility` was added in 1.133.0. Before that, searchAssetBuilder applied
  `.$if(options.isVisible !== undefined, ...)` with no default, so pre-1.133
  servers returned hidden assets too. #1474 was therefore not purely a v3
  regression.
- Those servers strip the `visibility: 'timeline'` filter rather than
  rejecting it: Immich validates with `whitelist: true` and no
  `forbidNonWhitelisted`. So the request stays valid, the filter is a no-op,
  and isVisibleAsset() is the ONLY guard there. Say so, so it does not get
  removed later as redundant.
- `albumIds` only exists from 1.135.0. Because unknown properties are stripped,
  an albumIds search against an older server would silently drop the album
  filter and return the entire library as the album's contents. Feature
  detection on `assets` (present through 1.144.1, absent on v3) makes that
  unreachable; a version probe with a wrong boundary would not.

Also cite Immich's own enum, which documents AssetVisibility.Hidden as
"Video part of the LivePhotos and MotionPhotos".

Comments only — no behavior change.

* feat(plugins): dashboard trip-card badges + a mock-host driver for plugin tests

Two additions that round out the plugin platform's breadth and its authoring DX.

tripCardProvider hook (hook:trip-card-provider): a plugin returns small declarative
badges for the dashboard trip cards. The dashboard fetches all visible cards in one
call; the host access-checks every tripId for the acting user, bounds each field
(label/value length, enum tone, http/https/mailto-only url), caps the count and drops
any badge for a card that wasn't requested — plugin JS never runs on the dashboard.
Rendered as text chips under the card meta; labelled + gated in all 22 locales.

createMockHost now exposes run(def) — the other half of a plugin unit test. Where the
ctx recorders capture what a plugin read, run() fires its own entry points (route, job,
scheduled, event, plugin-event, deleteUserData, exportUserData, provider hooks) against
the same mock ctx, and host.scheduled surfaces the timers it armed. A handler the plugin
didn't declare throws a clear error instead of a silent no-op.

* feat(plugins): include plugin data + code in backups, applied on restart

A TREK backup archived travel.db + uploads + the encryption key, but each plugin's
own SQLite file — the ONLY copy of the user data it holds — and its installed code
lived in separate trees that were never captured, so a restore left the plugins rows
with no data or code behind them.

createBackup now adds plugins-data/ (each plugin's db + WAL sidecars, so SQLite
recovers a consistent snapshot) and plugins-code/ (skipping dev-links by realpath, so
an author's linked source is never bundled). Restore can't swap those live — the
runtime holds each plugin db open — so it STAGES the extracted trees beside the live
ones and the runtime swaps them in at the next boot, before it opens anything. Same
"applies on restart" model the bundled encryption key already uses: no plugin quiesce,
no swap under open handles, no new admin setup. Older archives without the trees restore
exactly as before.

* fix(plugins): audit — runtime robustness, security & data-lifecycle fixes

Fixes from an adversarial audit of the plugin system, host/runtime side:

Robustness:
- getPluginDataDb recreated a handle a terminal-failure dispose had closed but
  left cached, so a re-enabled plugin's db:own threw on every call — recreate
  when the cached handle is shut.
- ctx.ws.broadcast* now carry _inv, so the host can bind the acting user (the
  capability was silently refused, i.e. dead, without it).
- ctx.events.emit swallows a rejected emit instead of crashing the child into a
  terminal 'error'; an uncaught throw AFTER activation is treated as a crash
  (restart with backoff), not a load failure.
- A crash-respawned child gets the same activation deadline as a first activation
  and the buffered-event queue is cleared on the timeout path, so a hung onLoad
  after a crash can't peg a core and orphan events forever.
- Expired buffered events are pruned by the reaper, not only at flush; the
  scheduler + erasure sweeps scope their LIMIT window to ACTIVE plugins so a
  backlog for inactive plugins can't starve deliverable work.

Security / integrity:
- Unix-domain-socket / named-pipe connects are refused by default in the egress
  guard (a host-local pivot to docker.sock / DB sockets), under the same policy
  as private IPs.
- db.tx refuses transaction-control statements (a raw COMMIT would break its
  atomicity) and caps rows across the WHOLE batch, not per statement.
- plugin_capability_audit is retention-capped per plugin (chain-safe: retained
  rows stay self-verifying), so it can't grow unbounded in the shared db.
- A cap of 0 in TREK_PLUGIN_AI_PER_DAY / _NOTIFY_PER_DAY now disables the broker
  instead of falling back to the default.

GDPR data lifecycle:
- Account deletion now erases host-side per-user plugin tables (config, OAuth
  tokens/state) and enqueues the own-db erasure from the CORE path, so it works
  even when the runtime is disabled or pre-boot; guest deletion does the same.
- uninstall keeps a pending erasure when data is retained (deleteData=false);
  erasure delivery is no longer grant-re-checked (a queued erasure is a duty);
  export flags installed-but-inactive plugins as pending instead of omitting them.

Backup/restore:
- Plugin DBs are WAL-checkpointed before archiving (no torn/stale snapshots).
- Restore applies the staged trees immediately by quiescing the plugins (no
  unbounded gap where a later unrelated restart would revert diverged data);
  the swap is content-level (safe on a volume-mounted root) and preserves
  dev-links; the decompressed-size cap is operator-raisable.

* fix(plugins): audit — hook-output hardening, dashboard slot & mock-host parity

- Map-marker and atlas-layer tones were validated on String(tone) but emitted
  raw, so a non-string tone (an object with a matching toString) slipped through
  and crashed the client that renders it — check the raw value against the enum.
- View-contribution column/action caps are now PER ENTITY, not per view, so a
  plugin's columns no longer vanish from every table row past the first 20; the
  dashboard trip-card badge cap is per card (≥ one on every visible card).
- A reservation-detail widget no longer also renders as a context-free dashboard
  sidebar card (the inline filter was missing that slot).
- mock-host matches the real host: it ignores asUserId on trip reads (bind the
  acting user), throws on a wrong user-scope notify target instead of coercing,
  enforces the scheduler caps, and detects RETURNING as a read in db.tx — so a
  passing author test can't hide a production RESOURCE_FORBIDDEN.

* feat(plugins): full ctx parity in the dev server + fire jobs/events/hooks locally

The trek-plugin dev server injected only ~6 of the ~35 ctx areas, so any plugin
touching ctx.costs/packing/files/notify/ai/settings/scheduler/meta/oauth/db.tx/…
hit a TypeError in local dev while the same code passed mock-host tests and worked
installed. It also could only exercise routes.

Delegate every non-db-own capability to a grant-enforcing mock host (the same one
unit tests use) while keeping the real node:sqlite for db:own and dev-native ws
capture + logging — so the whole surface works in dev with the exact production
permission rules. dev-fixtures.json now takes the createMockHost options shape, so
you can seed the full surface. New GET /__dev/fire/<kind>[/<name>][/<fn>] fires a
job, scheduled timer, event subscription, GDPR handler or provider hook against the
dev ctx, closing the "can't test non-routes locally" gap.

* feat(plugins): wire the photoProvider + calendarSource hooks to real core consumers

Both hooks were declared, typed and documented but NO core code ever invoked them,
so an author could build, mock-test and install a photo or calendar plugin that
silently did nothing. Give each a real consumer that fans out to it, exactly like
the other eight provider hooks:

- GET /api/plugin-photos/search (+ /sources, /item) aggregates photoProvider results
  for the picker — {id, title?, thumbnailUrl, fullUrl, takenAt?}, thumbnail/full URLs
  http/https-only (they become <img src>), per-source count capped, failing source
  skipped.
- GET /api/plugin-calendar?start=&end= aggregates calendarSource events for the
  signed-in user — {id, title, start, end, allDay} ISO, count capped, failing source
  skipped, sensible default window.

Both run with the acting user bound. The SDK interfaces now pass ctx as the last arg
(so a source can reach ctx.settings/oauth/http for its backend), and the wiki marks
them live instead of "reserved — no core consumer".

* feat(plugins): close the create-heavy API asymmetries importers/sync hit

Core services implemented these but plugins had no path to them, so the flagship
importer/sync integrations hit real walls. Added, each reusing the EXISTING grant
(no new consent):

- ctx.trips.removeMember(tripId, userId) — reconcile DEPARTURES, not just additions
  (db:write:members + member_manage). Never removes the owner (that would orphan the
  trip); ownership transfer stays a separate deliberate action.
- ctx.journal.createJourney({title, subtitle?, trip_ids?}) / deleteJourney(journeyId)
  — an importer can now bootstrap the journal it fills with entries and clean it up
  (db:write:journal), instead of only appending to journals a human created first.

Wired end-to-end (envelope → rpc-host → create-rpc-host reusing tripService/
journeyService → both SDK copies → mock-host) and documented. (trips.delete needs its
own destructive permission + consent copy and collab edit/delete + collections.delete
remain — tracked as small follow-ups.)

* feat(plugins): strip emojis from plugin-rendered text so it matches TREK's lucide UI

Plugin authors (especially AI-generated ones) sprinkle emojis into the declarative
text TREK renders in its OWN chrome — hook contributions (badges, columns, warnings,
PDF sections, map-marker/atlas labels, journal rows, place details, trip-card badges,
calendar + photo titles) and notifications — which clashes with TREK's lucide-only icon
language.

A shared stripEmoji() removes emojis (incl. flag/ZWJ/variation-selector sequences) and
tidies the leftover whitespace, applied at the render boundary in every hook-contribution
normalizer and in notify.send — so no matter what a plugin returns, the text TREK draws
stays emoji-free. It does NOT touch a plugin's own sandboxed /ui frame (the author's to
design), and it leaves photo ids verbatim (they round-trip to getById). The validate CLI
warns when a manifest name/description contains emojis, nudging authors to the declarative
`icon` field (a lucide name) instead.

* fix(plugins): harden the restore-apply path — regressions from the backup/dev fix pass

A final audit of the fix pass caught three regressions clustered in the two newest
surfaces; the restore path could both crash the server and destroy data.

- CRITICAL: a restore quiesces plugins via supervisor.shutdownAll() AFTER closeDb(), but
  shutdownAll killed children without first marking them stopped, so each child 'exit'
  took the CRASH path and wrote crash-accounting rows into the now-closed core DB — the
  throw escaped an EventEmitter listener as an uncaughtException and killed the whole
  process mid-restore. shutdownAll now marks every entry stopped and drops it from
  `running` BEFORE the kills (so onExit early-returns), and the onStatus/onLog DB hooks
  are wrapped in try/catch (also covers the stderr→onLog path). This also stops a normal
  shutdown from logging phantom "crashed" rows.
- HIGH: swapContents cleared live entries then MOVED staged ones in, so a crash mid-move
  permanently deleted a plugin's only data copy (staging was already emptied, so a retry
  couldn't restore it). It now COPIES each staged entry over the live one and only deletes
  staging at the very end — `staged` stays the complete source of truth, making the whole
  operation crash-idempotent.
- HIGH: the dev server lost the actingUserId=1 default in the mock-host refactor, so a
  fresh scaffold refused every user-bound capability. Restored.

* fix(plugins): final-audit medium/low findings

- GDPR export flags an active plugin whose export errored/timed out as `pending`
  instead of silently omitting it (collectUserExport now returns a discriminated
  result), so a data-access export never reads complete while missing data.
- Account deletion also enqueues an erasure for plugins UNINSTALLED with retained
  data (an orphan data dir) — a same-id reinstall now honours the deletion instead
  of re-adopting the user's data forever.
- oauth.getToken returns null in a userless context (matching the SDK/mock contract)
  instead of throwing RESOURCE_FORBIDDEN a background caller can't handle.
- Crash-backoff restart is identity-guarded (+ the timer is tracked and cleared like
  the activation timer), so a disable + re-enable during the backoff window can no
  longer respawn a ghost child from the replaced entry.
- db.tx transaction-control guard strips leading comments first, so `/* */COMMIT`
  can't slip past the start-anchored check and break batch atomicity.
- createJournal inherits its cover only from a trip that was actually LINKED
  (access-checked), closing a cross-tenant cover-image read on plugin + REST paths.
- trip-warnings drops a null array element instead of losing ALL of that provider's
  warnings; plugin-activity floors a non-integer ?limit so it can't 500.
- The trek-plugin dev server binds loopback only and refuses cross-site requests to
  its side-effectful /__dev/fire endpoints (it serves real routes + no-auth dev
  actions).

* fix(plugins): clear no-misleading-character-class in the emoji stripper

The character class listed the ZWJ, variation selectors and combining keycap
marks as members, which eslint reads as an accidental combined grapheme and
rejected on CI. Pull the emoji glyphs out into Extended_Pictographic /
Regional_Indicator alternatives so only the joiner/selector code points stay in
the class, with a scoped disable where the rule still can't tell them apart.
While here, reset lastIndex before the /g regex is reused in hasEmoji() so a
second call can't resume mid-string and miss a leading emoji.

* fix(security): trip-scope note-file deletion and guard the LLM base URL

Two reported issues:

- deleteNoteFile only matched on the note id and file id, so a member of trip A
  could delete a file attached to a note in trip B by guessing its id. Thread the
  trip id through the service and controller and scope the delete to it, the way
  every other collab operation already does.

- The LLM extraction clients fetched the user-configured base URL directly, so a
  user could point it at the cloud-metadata endpoint (169.254.169.254) and read
  the echoed error body. Route both clients through a new safeFetchLlm() that
  blocks the link-local/metadata range while still allowing a local or LAN Ollama
  (loopback and private ranges stay reachable), pinned to the resolved IP so a
  hostname can't rebind to the metadata address after the check.

* fix(security): route every LLM client through the SSRF guard

The base-URL SSRF fix covered the openai-compatible and anthropic clients but
missed the native Ollama /api/chat client and the /api/tags + /api/pull model-
management calls, whic…

* fix(plugins): repair plain-HTTP egress and forward the private-egress opt-out

Two pre-existing bugs in the plugin egress guard, found by running a plugin
against a real service end to end.

1. Every plain-HTTP request a plugin made was refused, whatever host it had
   declared. Node pre-normalises `net.connect()` args into an [options, cb]
   array and passes THAT array as the single argument; undici's plain-HTTP
   connector takes this path, its TLS connector does not. classifyConnect read
   `host` off the array, got undefined, and fell back to 'localhost' — so a
   fetch to a declared, public host was rejected with the nonsense message
   "localhost is not in the plugin's declared hosts". It failed closed, so it
   was never a security hole, and it went unnoticed because the only shipped
   egress plugin uses HTTPS. unwrapConnectArgs() unwraps the normalised form
   before anything reads host/path.

2. TREK_PLUGIN_ALLOW_PRIVATE_EGRESS could never have any effect. The guard that
   reads it runs INSIDE the child, whose env is scrubbed to a four-entry
   whitelist that never included it — so a documented setting (wiki/
   Environment-Variables.md) was wired to nothing, and no plugin could reach a
   self-hoster's LAN service no matter what the operator set. Forwarded only
   when set, so the default stays the secure block-private policy.

Regression tests cover the normalised form in both directions: the real host is
now resolved, and an undeclared host, a private IP and a unix socket are all
still refused when passed that way.

* feat(notifications): let a plugin register a notification channel

TREK's four channels (in-app, email, webhook, ntfy) were a closed set:
notificationService.send() dispatched with four copy-pasted `if` blocks and no
provider abstraction, so a fifth channel meant editing eight files by hand. A
plugin could produce a notification via ctx.notify.send(), but never deliver
one.

A plugin now registers a channel with `hooks.notificationChannel` +
`hook:notification-channel` on a plain `type: 'integration'` — not a new manifest
type, so the TREK-Plugins registry schema and both its CI gates are untouched.

Core refactor
- New channel registry (services/notifications/): email/webhook/ntfy become
  ExternalChannel providers wrapping the EXISTING send functions — no delivery
  logic is rewritten, only relocated. In-app deliberately stays out: it writes
  typed rows with scope/target/callbacks, not a rendered title+body, the same
  line shared/ already draws with i18n/externalNotifications.
- The event text is now rendered once per recipient instead of once per channel.
- The channel set is open: NotifChannel becomes a string, the matrix is
  registry-derived, and the UI columns are server-driven. The DB column was
  already bare TEXT and the Zod contract already a string record — only the
  TypeScript and the two UIs were ever closed.

The hook runs USERLESS. Every other hook is user-initiated, so actingUserId falls
out of the request; a notification is host-initiated for an ARBITRARY recipient,
so ctx.settings.get() would return undefined. The host resolves the recipient's
decrypted scope:'user' settings itself and passes them as an argument. That is
what lets a channel plugin be handed someone's push token WITHOUT being handed
the right to read their trips as them.

Enabling the plugin is the opt-in: a plugin channel is not gated on the admin's
`notification_channels` list. A built-in always exists in code and needs an
explicit switch; a plugin channel only exists because an admin enabled that
plugin. (Nothing could write a `plugin:` id into that CSV anyway, and the admin
toggle rebuilt it from three booleans, silently dropping anything else — so
requiring a second opt-in meant the channel could never be turned on at all.)

Also fixed, found while building this:
- Plugin settings keys were unvalidated, so a field named `__proto__` or
  `constructor` resolved off Object.prototype: a REQUIRED field with such a name
  reported as configured for every user who had configured nothing — enough, for
  a channel, to be dispatched to everyone with no credentials. Keys are now
  constrained at install and the config blob is parsed null-prototype, so it is
  impossible even for an already-installed plugin.
- A `select` field's options were cast straight through, so the obvious
  `["1","5"]` form rendered every dropdown entry BLANK (the client reads
  value/label). Now coerced, and malformed options are rejected.

Also adds: operator-supplied egress hosts (a plugin talking to a self-hosted
service can't name the operator's host at publish time, so an admin adds it
post-install and the runtime re-spawns the child with the widened allow-list —
only for a plugin that DECLARED operatorEgress, and only an admin, never a user);
settings-page actions (a "Test connection" button, user-initiated so
ctx.settings.get() returns the clicking user's own value); and a Gotify-shaped
notification-channel template in the SDK.

Verified end to end against a real Gotify container, not just in tests.

* docs(wiki): document the plugin notification-channel surface

Covers the pieces added in the previous commits, in the pages a reader would
actually reach for:

- Plugins.md (the admin-facing page) had none of it: notification channels,
  settings actions, and a full "Allowed hosts" section — including what
  operator-supplied egress deliberately does NOT let anyone do.
- Plugin-Development.md: the notificationChannel hook (and why it is the one hook
  with no acting user), settings-page actions, operatorEgress, and the manifest
  reference rows.
- Plugin-Cookbook.md: a "become a notification channel" recipe and a
  "Test connection button" recipe.
- Plugin-Permissions.md: hook:notification-channel, operatorEgress under the
  outbound section, and settings actions under "not a permission".
- Notifications.md: plugin channels alongside the four built-ins.

* fix(sdk): allow empty egress if and only if operatorEgress is true

* ci: don't run repo-specific workflows on forks

Guard release, publish, wiki-deploy and issue/PR-triage workflows with a
`github.repository` check so they no-op in forks instead of failing or
acting on the fork's own issues, PRs, tags and registries.

Also skip the Docker Scout scan for pull requests from forks: Docker Hub
secrets are never exposed there, so the login step could not succeed.

Tests and lint stay ungated — they need no secrets and are the gate for
incoming fork PRs.

* feat(sdk): add missing methods in mock-host

* fix(airports): rebuild the json file

* fix(airports.json): add small airports too

* fix(public transit): only show public transit option when a trip has actual dates

* fix(plugins): reap a queued erasure only once the plugin's data is gone

The orphan reap deleted every queue row whose plugin had left the registry, but
uninstall(deleteData=false) removes the plugins row while deliberately keeping the
data dir AND the queued erasure so a same-id reinstall can still honour it. The reap
now deletes a row only when the plugin's data dir is actually gone; a deleteData=true
uninstall already clears the rows itself.

* fix(backup): snapshot the core DB and swap restores atomically

createBackup archived travel.db via the archiver's lazy live-file read, so a WAL
auto-checkpoint firing mid-stream could write a torn database into the zip. It now
VACUUM INTOs a point-in-time snapshot and archives that, the same guarantee plugin
DBs already get. restoreFromZip swapped the DB by unlink-then-copy, which on an
interrupted restore could leave no valid travel.db; it now copies to a temp file and
renames it into place (atomic), dropping the stale -wal/-shm sidecars first.

* fix(deploy): Recreate strategy for the SQLite volume, pin the root compose image

The Helm Deployment had no strategy, so the default RollingUpdate would start a second
pod holding the same ReadWriteOnce PVC before the old one exits — a Multi-Attach
deadlock or two writers on one SQLite file. Default to Recreate (overridable for
ReadWriteMany). The root docker-compose.yml pinned trek:dev, a tag no workflow builds,
so a clone-and-up at the release tag ran a stale image; pin it to :latest like the README.

* fix(security): re-validate LLM endpoint fetch redirects per hop (GHSA-fmq9)

safeFetchLlm left undici's default redirect:'follow', so a configured LLM
endpoint could 302 to http://169.254.169.254/ and reach cloud-metadata
credentials — the DNS pin does not cover an IP-literal redirect hop, since
net.connect skips the pinned lookup for a literal IP. Follow redirects
manually now, re-resolving/re-checking/re-pinning each hop (allowing LAN/
localhost as before). Also block the Alibaba metadata IPs directly.

* fix(plugins): throttle the plugin log channel to prevent host-thread DoS

The per-plugin RpcRateLimiter only guarded the ctx.* (req) channel; ctx.log.*,
stdout/stderr and unknown evt topics reached a synchronous INSERT+prune on the
host thread unthrottled, so a while(true) ctx.log.error(...) loop could freeze
the instance. Route every plugin-driven log path through a per-plugin log token
bucket; excess lines are dropped with a summary line on resume.

* fix(plugin-sdk): serve dev /ui frame at /ui/index.html so relative assets resolve (#1526)

The dev server embedded the plugin UI as <iframe src="/ui"> (no trailing
slash), so a multi-file build's relative asset URLs (./assets/x.js from Vite
base:'./') resolved against the origin root -> /assets/x.js -> 404, even though
the files are served at /ui/assets/*. The real host loads the frame at
/plugin-frame/<id>/index.html where the same relative URLs resolve correctly, so
dev now matches it by loading /ui/index.html (and also serves /ui/ as index.html).

* i18n: improve Russian translations (#1539)

* v3.4.0 (#1527)

* fix(plugins): unknown column

* fix(mcp): reuse MCP sessions instead of creating one per tool call

The /mcp CORS layer never set exposedHeaders, so Access-Control-Expose-Headers
was absent and browser-context MCP clients (Claude Desktop connectors,
Claude.ai, MCP Inspector) could not read Mcp-Session-Id off the initialize
response. Unable to echo it back, every request looked like a fresh initialize:
one McpServer and one session per tool call, until the per-user cap returned a
429 and the integration died until the container was restarted.

The idle sweep was not at fault — it expires on lastActivity with a 1h default,
so sessions born seconds apart are nowhere near expiry, hence 'cleaned 0'.

- expose Mcp-Session-Id, MCP-Protocol-Version and WWW-Authenticate
- evict a user's least-recently-active session at the cap rather than
  refusing the request, so a client that cannot persist its session id (or a
  proxy that strips the header) can never wedge the server
- close the McpServer/transport orphaned by every session-less non-initialize
  POST, which was leaked: never mapped, never swept, never closed
- return the cap error as JSON-RPC so clients surface the real reason
- warn on session-less POSTs to make a header-stripping proxy diagnosable

* chore(deps): declare @modelcontextprotocol/sdk ^1.29.0

Matches the version already resolved in the lockfile; no dependency-tree change.

* docs(mcp): add the reverse proxy specs for MCP

* fix(plugins): stop the row ⋯ menu being clipped by the sidebar

The menu was an in-flow `absolute` div, and its ancestor (PageSidebar) is
`overflow-hidden` — which clips absolutely-positioned descendants regardless
of z-index. With enough plugins installed a row sits low enough that its menu
runs past the sidebar's bottom edge and gets chopped, taking Delete with it,
so the plugin could no longer be uninstalled from the UI.

Portal the menu to <body> and position it `fixed` against the ⋯ button,
flipping upward when the bottom is tight and re-anchoring on scroll/resize.
A fixed child of <body> has no overflow ancestor, so nothing can clip it.

Closes #1523

* feat(plugins): surface author-signature status and add a scoped re-trust override

TREK has always verified an author's Ed25519 signature and TOFU-pinned the key on
first install, but none of it was ever shown: a successfully-installed UNSIGNED
plugin looked identical to a signed one, and a signature-refused update left the
plugin quietly pinned at its old version with the reason dying in a toast.

Give the four refusal conditions machine-readable codes (SIGNATURE_MISSING /
_INCOMPLETE / _KEY_CHANGED / _INVALID), persist a refusal on the plugin row so the
admin list keeps showing it, and badge Signed/Unsigned in the list and in Discover.

Only SIGNATURE_KEY_CHANGED is overridable — an author can legitimately rotate a key;
a signature that does not verify means the bytes are not what the author signed, and
there is no story where waving that through is right. The override re-pins and
updates in ONE call (POST :id/retrust): a re-pin that waited for a follow-up /update
would leave the plugin pinned to a key no install had ever been verified against if
that second call never came. The artifact must still verify under the new key, so a
re-trust moves the pin from one verified key to another.

assertRetrustable re-derives the condition server-side, so the UI hiding the button
is a convenience, not the control, and it echoes back the full key the admin was
shown so a re-key since the dialog rendered is refused. The rotation is written to
the admin audit log with both fingerprints — after an incident, "which key did we
move from, and to what?" is the question a single key cannot answer.

* fix(plugins): let a plugin's frame reach the hosts an admin added for it

The frame's connect-src was built from the manifest's http:outbound grants alone, but
the child's egress guard is the UNION of those and the hosts an admin added after
install for an operatorEgress plugin (a self-hosted Gotify, an ntfy — hosts the author
cannot know in advance). So such a plugin WITH A UI could call the operator's host from
its server and was CSP-blocked in its own iframe.

Match the frame to the child. The admin consented to these hosts at install and the
child already reaches them, so this widens no trust boundary that isn't already crossed.
Both sources stay validated on the way in, and the interpolation filter is unchanged.

* fix(plugins): report a rejected events.emit on the plugin's own log stream

The host can reject an emit (an undeclared event name, a rate limit). The rejection must
not escape — a detached rejection crashes the child and terminally disables the plugin
over one bad emit — but swallowing it silently left an author with no way to discover
that `emits` was missing from their manifest. Surface it as a warning instead.

* feat(plugin-sdk): expose the raw request body for webhook signature checks

A webhook author must run their HMAC over the exact bytes the sender signed. `body` is
the PARSED value, and re-serializing it will not reproduce those bytes — key order,
whitespace and unicode escaping all differ — so the signature never matches. Document
`rawBodyBase64`, which the host already sets on auth:false routes.

* fix(plugin-sdk): refuse to overwrite a released artifact, and keep the packed zip

A released artifact is IMMUTABLE: the registry pins its sha256, so overwriting the bytes
of a release already in the registry breaks the checksum for everyone who installed that
version — they can no longer install or update it. The old code blanket-caught every
`gh release create` failure (auth, network, a bad repo) and turned it into a --clobber
upload. Probe for the release explicitly and refuse unless --force.

Also stop deleting plugin.zip on the way out. It is the exact bytes the release and the
entry's sha256 pin were computed from; a re-pack on another machine or SDK version can
differ (CRLF, walk order), so anyone re-running `entry`/`sign` afterwards must hash THAT
file, not a rebuild.

* fix(plugin-sdk): don't fail submit when the fork already has an upstream remote

`gh repo clone` of a fork may already have wired `upstream`, in which case a bare
`remote add` exits non-zero and took the whole submit down. Set it either way.

* fix(plugin-sdk): make the dev server behave like the host

Three ways `dev` lied to an author about how their plugin would run in production:

- ctx.db: one try/catch wrapped both the node:sqlite probe AND opening the database, so
  an mkdir/permission failure silently degraded to the in-memory stub — which swallows
  every write while reporting success. A db:own plugin "worked" in dev and persisted
  nothing. Probe separately: fail loudly on a real error, degrade only on old Node, and
  say plainly that the stub discards writes.
- notificationChannel: the host fires it with no acting user and hands the recipient's
  decrypted settings in as a separate `config` argument — send(msg, config, ctx) /
  test(config, ctx). Firing it like an ordinary hook passed `ctx` where `config` belongs,
  so a channel plugin read its settings off ctx and was broken in production.
- /preview pinned tripId 42 while the scaffold seeds trip 1, so the widget's first
  trek:invoke hit assertMember(42) and 500'd. Preview against a trip that exists.

* fix(plugin-sdk): reject unknown flags, wire up create's new flags, and add --help

`parse()` accepts any --x, so a flag a command does not read was silently dropped:
`create --template notification-channel` cheerfully scaffolded a blank plugin. Silently
ignoring an author's explicit instruction is worse than refusing it, so unknown flags are
now an error, and create actually forwards --template/--egress/--required-addons.

A bare --permissions used to split the string "true" into a permission literally named
`true`; listFlag() now treats a valueless flag as absent.

Since an unknown flag is now fatal, `--help` has to exist: it is intercepted before the
flag check and prints usage on stdout with exit 0.

* chore(plugins): drop three unused eslint-disable directives

The no-console rule is not enabled for these files, so the directives were dead and
eslint reports them as unused.

* fix(plugin-sdk): bring preflight back in step with the registry's gates

preflight exists to tell an author what TREK-Plugins' CI will say before they open the
PR. The registry now verifies author signatures, and preflight didn't — so it drifted
into the one failure mode it must never have: a false green. An author trusts a green.

- Verify the signature against the artifact bytes. preflight already downloads them for
  the sha256 check, so this costs one call. Without it, signing with the wrong key (or
  re-packing after signing) sails through and is caught at review.
- Check the signature SHAPE (checkSignatureShape): a key with no signed version, a
  signature with no key, a malformed key or signature. TREK refuses to install a
  half-signed entry, so such an entry is dead on arrival.
- Default apiVersion to 1 before comparing. It is OPTIONAL in the manifest — install/
  manifest.ts and `entry` both default it — so a manifest that legally omits it was
  failing preflight with "manifest apiVersion undefined != entry 1" while the registry
  passed it. A false RED, which teaches authors to ignore the tool.
- Check requiredAddons/pluginDependencies parity, and operatorEgress without an
  http:outbound grant.

The verifier is a port of the host's install/verify-signature.ts (the registry has its
own port); sign.ts's verifyArtifact only understands the bare key/signature pair the SDK
itself emits and cannot judge a minisign key. A test pins all three to the same verdicts.

* feat(plugins): enforce compatibility range

* chore: bump sdk version

* test(e2e): repair the trip-creation specs

create-trip and trip-planner have been failing for a while — long enough for
three separate UI changes to drift past them, which nothing caught because CI
runs vitest only and never invokes Playwright.

Each failure was masking the next:

- The release-notice modal greets a freshly seeded user and its backdrop
  swallowed the click on .add-trip-card. Added a shared dismissSystemNotices()
  helper (the X only shows on the notice's last page, so it has to page through
  first).
- .modal-backdrop no longer exists — the class was namespaced to
  .trek-modal-backdrop so content blockers stop hiding it.
- input[type=text].first() is no longer the Title field: the cover-image search
  inputs now sit above it, so the specs were typing the trip name into the photo
  search box and creating an untitled trip that never matched getByText(title).

* fix(planner): gate drag & drop on pointer type, not viewport width (#1432)

The 3.2.1 fix disabled drag on "mobile", but nothing in the client has ever
detected touch — "mobile" was inferred from viewport width, at four independent
breakpoints. A tablet is a coarse-pointer device at a *desktop* width, so an
iPad (820-1366px) fell on the wrong side of all four, which is why iPhone was
fixed and iPad was not:

- useTripPlanner's isMobile (<768px) is what disarmed `draggable`, so on iPad
  rows stayed draggable and a scroll swipe became an HTML5 drag.
- TripPlannerPage hardcoded isMobile={false} on the desktop PlacesSidebar, so
  its drop handlers and the drop-to-import overlay could never be disabled —
  that overlay is the reported symptom.
- The arrow-button reorder fallback was revealed only below 767px, leaving iPad
  with no drag *and* no fallback.
- touchDragPolyfill loaded drag-drop-touch at >=1024px, synthesising drags from
  touchmove — on a landscape iPad that re-armed the very gesture hijack 3.2.1
  removed.

Adds useIsTouch() ((pointer: coarse)) as a signal separate from isMobile: layout
stays width-driven, so the iPad keeps the desktop two-pane planner, while every
drag affordance is gated on isMobile || isTouch. The reorder arrows now show on
coarse pointers, and the polyfill loads only on hybrid laptops
((pointer: fine) and (any-pointer: coarse)), which also removes the #1440
phantom-dblclick map zoom on tablets.

Guarded by unit tests plus an e2e spec on real WebKit in an iPad Pro 11 context
— the engine matters, since every browser on iPadOS is WebKit underneath, which
is why the reporter hit this in all three they tried.

* test(planner): guard the day-plan reorder arrows against phantom clicks

The hover rule that reveals the reorder arrows had been dead since the
TypeScript migration: it targeted `.place-row:hover .reorder-btns`, and neither
class exists — the component renders `.reorder-buttons` inside an unclassed row.
The buttons sat at opacity:0 on desktop with nothing to reveal them.

That was not merely invisible. opacity:0 still hit-tests, so every itinerary row
and day note carried an invisible, fully clickable target that silently
reordered the trip:

  opacity: "0", visibility: "visible", pointerEvents: "auto"
  elementFromPoint(centre) -> BUTTON, inside .reorder-buttons

The repair — pointer-events: none while hidden, plus a working
.dp-row:hover/:focus-within reveal (focus-within so the buttons are also
reachable by keyboard, which the file's JS-hover pattern cannot do) — lives in
index.css and DayPlanSidebar.tsx. Both files also carry the #1432 drag gating,
so they went with that commit rather than being split mid-file; this commit is
the regression guard for them.

E2E rather than unit, because jsdom does not evaluate :hover. Against the old
CSS it fails on exactly the right assertion: "hidden arrows must not swallow
clicks" — expected false, received true.

* fix(pdf): keep the header gap on day-header overflow pages (#1531)

The repeated <thead> day header (#1471) carried no gap before the first
card on overflow pages: the 12px sat in .day-body's block-start padding,
which a fragmented box only paints on its first fragment. Move it to the
thead cell so it repeats with the header; the day's first page renders
pixel-identically.

* fix(budget): keep "no one paid yet" when editing an expense (#1533)

The ExpenseModal payer initializer fell back to the current user whenever the
edited item had no payer, so reopening an expense saved with "no one paid yet"
silently reselected "You" — and re-saving then recorded the current user as the
payer, corrupting the balances. An absent payer on an existing expense is a
deliberate value, so only a brand-new expense defaults to me.

* feat(sdk): support for plugin icons

* fix(planner): keep the places filter applied and visible across tab switches

The category and all/unplanned/tracks filters lived twice: a local copy in
the sidebar driving the checkboxes and the list, and a page-level copy
driving the map markers, synced only when a checkbox was clicked. Switching
planner tabs unmounts the sidebar, so the local copy reset to "All
Categories" while the markers stayed filtered — and the only way out was
toggling any category on and off again (#1541).

The filter now lives once in the trip store, next to selectedDayId: it
survives the Plan tab unmounting (and the mobile places sheet closing),
keeps both sidebar instances in agreement, and resets when another trip
loads.

* feat(airtrail): import connecting flights as one multi-leg booking

AirTrail flights always imported as separate single-leg reservations, so a
layover could not be expressed and the connection country ended up counted
as visited in Atlas (#1535).

The import picker now detects connection chains among the listed flights —
each leg departing from the airport the previous one landed at, onward
within 24 hours, and never back to the origin (an out-and-back is a return,
not a connection) — and offers to import each chain as one flight with
layover stops, on by default. The joined booking keeps per-leg airline,
flight number, times and seat in metadata.legs, files every leg on its own
trip day, and mirrors the first/last leg flat, exactly like the manual
multi-leg form. With the connection stored as a stop endpoint, the existing
Atlas role filter excludes the layover country on its own.

AirTrail has no multi-leg flight a joined booking could round-trip to, so
it imports detached from live sync, with every source flight id recorded in
metadata.airtrail_ids — the picker and the server-side dedupe both treat
those legs as imported, per leg, even across trip members. The server
re-validates each requested chain and falls back to individual imports when
it does not actually connect.

* fix(airtrail): stop syncing a booking once it grows extra stops

A linked flight that becomes multi-leg locally no longer matches the single
AirTrail flight it was imported from: pushing would rewrite that flight to
span the whole route, and the next pull would flatten the layover chain
back to a plain from/to. Both sync directions now detach the link instead —
the same state a joined import starts in, surfaced by the existing "Not
synced" badge.

TransportModal also carries metadata.airtrail_ids through re-saves (like it
already does for transit itineraries and day positions), so editing a
joined booking cannot cost it its import dedupe and get its legs re-offered
in the picker.

* fix(planner): default a new accommodation to checking out the next day

The hotel picker pre-filled "Apply to days" with the same day for check-in
and check-out — a stay that ends the day it begins. New accommodations now
default to the following day for check-out; the last trip day keeps the
same-day range, and editing still seeds from the stored range.

* docs(wiki): document the AirTrail import and connection joining

* fix(plugins): fold resolvePluginIcon into PluginIcon

pluginIcon.ts and PluginIcon.tsx resolve to the same file on the
case-insensitive filesystems dev checkouts commonly sit on (Windows,
macOS) — tsc sees both casings of one module and fails with TS1149 in
every importer. Keep the resolver and the component in one module.

* feat(sdk): add update verification

* chore: remove test files

* fix(sdk) rework the sdk helpers and DX/UX

* fix(sdk) harden dev environment

* fix(budget): add back the multi payer selection

* fix(map): stop MapLibre mouse rotation from reversing near mid-screen

Since MapLibre 5's camera rewrite, the right-button rotate handler flips
its sign whenever the cursor sits above a mid-screen line it derives by
re-projecting the map center. That line drifts with the bearing by a
fraction of a pixel, so inside the 100px band around the screen center a
steady horizontal drag lands alternately above and below it — every
processed movement reverses the previous one and the camera ping-pongs in
place instead of rotating (#1545). A real hand crossing the line mid-drag
flips the rotation direction outright. maplibre-gl 4.x rotated from plain
horizontal movement and had none of this.

Passing aroundCenter: false opts the handler out of the around-center
mode and restores the 4.x/mapbox-gl behaviour: horizontal drag rotates,
vertical drag pitches, in one continuous motion. Applied to all three GL
map builds (planner, journey, settings preview); mapbox-gl keeps its
options untouched.

* fix(budget): settle in the trip's real currency, not always EUR

The settlement route read `currency` off the row returned by canAccessTrip,
whose SELECT never included the column. A cast hid the mistake, so trip.currency
was always undefined and the settlement was told every trip is in EUR.

Balances are netted in the trip currency and converted to the display currency
once. With the trip mislabelled EUR, expenses in the trip's own currency still
cancelled out, but an expense booked in a foreign currency was divided by its
frozen rate into trip-currency units, then converted again as if those were
euros — inflating balances by the EUR/trip rate (~27x for a RUB trip with a USD
expense, #1543). MCP was unaffected: it reads the currency with its own SELECT.

Select the currency in canAccessTrip so the read is real. The settlement maths
was correct all along; it was simply being lied to about the base currency.

Fixes #1543

* feat(trips): let users set the trip currency, and rebase the budget when it changes

The trip currency is the base every expense and settle-up is netted against, but
the only picker for it lived in the legacy Budget addon panel — so on the Costs
panel a trip was stuck with whatever it was created as. Add the field to the trip
form, on create and on edit, gated on trip_edit. The REST and MCP write paths
already accepted `currency`; only the form was missing.

Changing it is not a rename, though: an expense's frozen `exchange_rate` is
"units of its currency per 1 trip currency", and `currency = NULL` means "the
trip's own", so both are relative to the outgoing base. Swapping it out from
under them redenominates the implicit rows (9 000 RUB becoming 9 000 EUR) and
leaves the frozen rates pointing at a currency the trip no longer uses — the same
mismatch that inflated #1543.

So rebaseTripCurrency() runs first, while the old currency is still on the row:
it pins the implicit rows to the outgoing currency and re-freezes every rate
against the incoming one, for expenses and settle-up transfers alike. No stored
amount is rewritten — each keeps the figure the user typed, in the currency they
typed it in, and its real-world value survives the switch.

Also covers the #1543 data as a settlement regression test.

* feat(budget): give settle-up payments their own currency

A transfer settling a shared bill can be made in any currency — paying a rouble
debt in euros is normal — and the server has stored `currency` + a frozen
`exchange_rate` on every transfer since #1445, re-freezing it on edit. The UI
just never let anyone choose one, so a payment silently inherited whatever the
viewer's display currency happened to be.

Add the picker to the payment modal, mirroring the expense modal, and reopen an
existing payment in the currency it was actually recorded in. The ledger row now
shows a foreign payment as `$30.00 -> 27,00 EUR` like a foreign expense does,
instead of stamping the display currency's symbol onto the raw stored number.

The Settle buttons on the suggested flows keep sending the display currency:
those amounts are computed in it.

* feat(settings): make the display currency optional, falling back to the trip's

Costs already resolved `default_currency || trip.currency || 'EUR'`, but the
setting could never actually be empty: the store seeded 'USD', so a user who had
never touched it silently had every trip converted into dollars, and the picker
offered no way to unset it.

Seed it empty and lead the picker with a "Trip currency" option, so an unset
preference means "show each trip in its own currency" instead of forcing them all
through one code. An explicit empty value persists and beats the admin-set
instance default — it is a deliberate choice, not an absence.

This also brings the public share's fallback to life: the share payload has
resolved sharer's currency -> trip currency since #1361, but the trip-currency
branch was unreachable while every owner had a currency forced on them.

Plugins are handed `formats.currency` as a concrete code, so PluginFrame now
resolves the same chain rather than passing an empty string through the bridge.

* docs(wiki): explain the three currencies and how they relate

Trip currency, expense currency and display currency answer three different
questions, and nothing said so: the trip currency wasn't documented at all (it
had no picker until now), and Budget-Tracking conflated the other two while
still claiming 47 currencies and a display currency that always came from
Settings.

Add a Currencies page as the one place they're defined together — the trip
currency as the accounting base, the expense currency as the receipt with its
rate frozen at entry, the display currency as presentation-only — plus what
happens when a trip's currency changes, which currency a public share renders
in, and what belongs to the Costs addon versus the trip itself.

Rewrite Budget-Tracking's currency section against it, document the currency
field in Creating-a-Trip and the display currency in Display-Settings (which
never mentioned it), and note the sharer-or-trip fallback in Public-Share-Links.

* feat(help): serve the in-app wiki from disk instead of fetching GitHub

The /help pages fetched their markdown from raw.githubusercontent.com at
runtime, so a self-hosted install was served docs from main rather than the
version it was actually running, and help was unusable without network access.
The wiki/ directory was in the repo the whole time; the bundled-snapshot
fallback the code reached for was gitignored and never populated by any build
step, so it was dead code.

Read wiki/ straight from disk instead. server/{src,dist}/services both sit
three levels under the repo root, so a single __dirname anchor resolves in dev,
a built source install, vitest and Docker with no copy or build step. GitHub is
kept strictly as a fallback for when the directory cannot be resolved, decided
once at load by probing for _Sidebar.md: a page missing from a present wiki is
a genuine 404, since falling back per-file would reintroduce the version skew
this removes.

Ship wiki/ in the image: .dockerignore excluded it outright, so the COPY alone
would have produced an image with no wiki, and the GitHub fallback would have
masked that at runtime. Add a real path-containment check on assets now that
the path becomes a filesystem read rather than a URL, and document
TREK_WIKI_DIR as an off-by-default escape hatch across the deployment configs.

* fix(plugins): serve frame assets root-relative and cross-origin loadable

res.sendFile(absolutePath) resolves against the rewritten req.url under
the Nest ExpressAdapter and 404s spuriously (files-download already
works around the same trap), which broke every plugin frame document.
And helmet's CORP: same-origin made the browser drop the opaque-origin
frame's own script/style subresources, so a multi-file plugin client
could never boot. Serve root-relative and mark frame responses
cross-origin — sandbox + per-plugin CSP stay the isolation boundary.

* feat(plugins): let a plugin ship its own settings page

A plugin that declares capabilities.settingsUi: true gets its
client/settings.html framed as a card under Settings -> Plugins — same
opaque-origin sandbox and postMessage bridge as its widget, sized via
trek:resize. Hosts that predate the flag strip it at install, so old
instances keep working and simply don't show the card.

* feat(map): open maps framed on their places (builds on #1393) (#1556)

* fix(map): fit MapLibre routes reliably

* fix(map): default planner map to world view

* fix(map): only await route geometry when a route is actually pending

The fit armed a pending route-refit slot on every fitKey change, even with no
route drawn, and only ever cleared it when a route arrived. So a route toggled
on much later — after the user had panned elsewhere — was mistaken for the
awaited geometry and yanked the camera back, and only on the first toggle.

Arm the slot only when a route is already on screen: updateRouteForDay lays down
straight lines in the same batch as the fit and upgrades them to real geometry a
moment later, so an empty route at fit time means none is coming.

* fix(collections): open the empty collection map on the world view

A collection with no mappable places centred on Paris, the same hardcoded
default this branch removes everywhere else.

* feat(map): open the map framed on its places

A trip in Japan opened on the world view at 0,0 and only then animated a fitBounds
flight across the planet — the hardcoded default was the map's answer to a question
its own places already answer.

Each renderer now derives its opening camera from the places it receives, at
construction: MapView for Leaflet, MapViewGL for MapLibre and Mapbox (whose zoom
runs one level below Leaflet's, measuring against a 512px world tile rather than
256px). Doing it at construction is what confines it to load — the map is built
once, and by then the trip's places are in hand. Nothing recomputes it afterwards,
so the camera stays where the user leaves it, and the opening fit stands down
rather than overruling the gentler zoom a lone place opens at.

A trip with no coordinates still falls back to the world view. Collections and the
public shared-trip page frame themselves the same way.

* refactor(settings): drop the default map centre and zoom

Nothing reads them now that every map frames itself on its own places, and a
home-city default was the wrong answer for the next trip on the other side of the
world. The style preview keeps a fixed location of its own: it needs a city to show
label density and 3D buildings, which open ocean cannot.

* fix(map): frame the map the way each renderer can actually draw

Two defects the unit tests missed and running the app exposed.

MapLibre and Mapbox opened on Null Island at zoom 2 regardless of the places: the
effect that mirrors an external centre prop onto the camera also ran on mount, so
it jumped straight to the default nobody passed and threw away the camera the map
had just been built with. It now only responds to actual changes, which is what it
was for. Leaflet was unaffected — its controller already guarded on the centre
changing.

A trip spanning Sydney, Reykjavik and Santiago lost Sydney's marker entirely. The
narrowest arc containing all three crosses the antimeridian, and framing there is
only sound on a renderer that repeats the world: MapLibre and Mapbox draw a marker
on whichever copy is nearest the camera, Leaflet draws one world and puts the
marker at its absolute position — off-screen. Leaflet now spans the long way round,
as L.latLngBounds would. The test that should have caught this wrapped the x-offset
in its own projection helper, quietly assuming behaviour Leaflet does not have; it
now models each renderer's real wrapping.

---------

Co-authored-by: Azalea <noreply@aza.moe>

* feat(mcp): expose public transit planning tools (#1558)

* feat(mcp): add public transit planning tools

* refactor(transit): reuse local time conversion

* fix(mcp): harden transit journey validation

* refactor(transit): centralize itinerary processing

* fix(mcp): return the transit itineraries the provider actually offers

search_transit_routes validated each itinerary leg's mode against
SCHEDULED_TRANSIT_MODES, but that constant is the request-side filter
whitelist — the modes a caller may ask for — not the modes MOTIS can return.
Its default TRANSIT mode expands to TRAM,FERRY,AIRPLANE,BUS,COACH,RAIL,ODM,
RIDE_SHARING,FUNICULAR,AERIAL_LIFT,OTHER, and street legs can be BIKE/CAR/
RENTAL. Any itinerary carrying one of those failed the parse and was dropped
by the flatMap, so the tool reported fewer routes than exist — or none at all.
Against the live provider, Trondheim → Ålesund returns 5 itineraries and 3 of
them contain an AIRPLANE leg, so the tool silently discarded them; the web app
shows all 5, because it treats mode as a free string and renders anything
non-WALK as a transit leg.

Accept any mode token on a leg and keep the existing "at least one non-WALK
leg" rule as the real gate, which restores parity with the web app. Everything
downstream keeps its mode !== 'WALK' semantics, so a journey created over MCP
is identical to one created in the app.

Dropping an itinerary is still possible when provider data fails the remaining
consistency rules, but it is indistinguishable from "no routes exist" — so
search_transit_routes now reports a `dropped` count alongside the results.

---------

Co-authored-by: Uzini <43294422+Uziniii@users.noreply.github.com>

* fix: show map poi search controls on mobile (#1555)

* fix(pdf): use the trip's actual currency instead of hardcoded EUR (#1519)

* fix(pdf): use the trip's actual currency instead of hardcoded EUR

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(i18n): drop hardcoded currency text from pdf.costLabel across locales

Remove redundant EUR/currency references from pdf.costLabel translations
across 21 locales now that the PDF export correctly renders amounts
with their actual trip currency via formatMoney().

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(pdf): drop hardcoded euro-shaped icon from place price chip

svgEuro rendered a fixed € glyph next to the price chip regardless of
the trip's actual currency, undermining the currency fix. Swap for a
currency-neutral coin icon.

---------

Co-authored-by: Nguyen Trong Binh <nguytb15@VN1N07HO1CD1015.local>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

* fix(trips): pin place prices when the trip currency changes

A place price with no currency of its own means "the trip's own currency" —
that is how the PDF export and the place chips read it since #1519. But
rebaseTripCurrency() only pinned budget_items and budget_settlements, so
switching a trip's currency silently redenominated every implicit place
price: a €15 museum on a trip moved to JPY started reading as ¥15. Same
class of mismatch as #1543, on the places surface.

Pin priced, currency-less places to the outgoing currency inside the same
transaction. No amount is rewritten — the figure the user typed keeps its
real-world value, it just stops being ambiguous about which unit it is in.
Bump updated_at as well: it doubles as the optimistic-concurrency token
(#1135), so a client holding the pre-switch row can no longer write the
pin away.

Document place prices in the wiki's currency model, and drop the now-stale
"in EUR" from the PDF export's estimated-cost stat.

* fix(budget): re-split expenses when a member is removed

* fix(plugins): derive plugin req.user.isAdmin from role, not is_admin

* chore(test): make jsdom Storage work under Node's native Web Storage globals

* fix: recompute vacay calendar when week start changes (#1554)

* fix(websocket): handle socket 'error' events to prevent crash on malformed frames (#1584)

* fix(packing): apply templates into the active list tab (#1581)

* Fix packing list readability on mobile

* Localize packing quantity label in overflow menu

* fix(atlas): stream boundary GeoJSON instead of caching parsed bundles (#1585)

* fix(atlas): stream boundary GeoJSON instead of caching parsed bundles

* fix(atlas): scan admin1 features in one pass to avoid O(n^2) build

createFeatureSplitter re-scanned each partial Feature from the start on
every gunzip chunk, so a large feature (Canada ~5.5MB, ~340 chunks) made
the one-time admin1 store build O(n^2). That pushed the streaming build
(~4.2s) past the 15s test timeout under CI coverage/fork contention and
added the same latency to the first live region request.

Carry scan state (position, brace depth, string state) across chunks so
each character is examined once. Output is byte-identical (3228 features,
197 countries) and peak build memory is unchanged (~192MB RSS under a hard
512MB cap); build time drops to ~1.7s.

* fix(i18n): add packing.quantity to all locales

The packing.quantity key existed only in en (Qty) and de (Menge), so
i18n:parity:strict and the client parity test failed for the other 20
locales. Add the key everywhere; en/de are unchanged.

---------

Co-authored-by: jubnl <jgunther021@gmail.com>

* fix(trips): keep accommodations on their dates when the trip range shifts (#1288)

The v3.1.3 fix re-anchored dated bookings after a trip date change but
explicitly excluded hotels: day_accommodations has no absolute date columns,
so stays remained glued to positionally re-dated day rows and shifted with
the range. updateTrip now snapshots day dates before generateDays and a new
resyncAccommodationDays re-anchors each stay (and its linked hotel
reservation, restamping its stale reservation_time) to the days holding its
pre-change dates; out-of-range stays stay glued so whole-trip moves still
shift together. Unlinked dated hotels resync like any booking, and the
date-change block is wrapped in a transaction.

Changing the start date now also asks how plans should follow via a new
date_shift_mode field ('keep_bookings' default / 'shift_all', which reuses
the reorder/insert restamp path to glue everything), exposed in the trip
edit modal (all 22 locales), the shared contract, and the MCP update_trip
tool. Clients no longer show stale state: the initiator reloads
reservations + accommodations after saving, collaborators refetch on a
date-changing trip:updated, and reconnect hydration nudges the planner's
accommodations too.

* fix(extract): retry with json_object and surface AI import failures (#1546)

OpenAI-compatible providers that only support json_object (DeepSeek,
Mistral, some vLLM/llama.cpp) reject the json_schema response_format
with a 400, and the resulting error was swallowed silently: not logged
server-side and never rendered by the background-task widget, leaving
only a generic "no reservations" message.

- Retry the chat/completions request once with response_format
  json_object when the json_schema attempt returns 400 (non-NuExtract
  only); the system prompt already dictates the output shape
- Log swallowed llm-parse errors with an [llm-parse] tag so failures
  show up in server logs
- Render task warnings under the empty-preview note in the background
  tasks widget so the actual provider error reaches the user

* fix(costs): keep ticket item amounts visible on narrow screens (#1568)

* chore: update repo url

* chore: update repo url

* chore: update repo url

* chore: update repo url

* fix(security): block IPv6 transition addresses (NAT64/6to4/Teredo) in SSRF guard

An attacker-controlled DNS record pointing at a NAT64 (64:ff9b::/96),
6to4 (2002::/16), or Teredo (2001:0000::/32) address that embeds a
private IPv4 (e.g. 64:ff9b::a9fe:a9fe = 169.254.169.254) bypassed the
SSRF guard: none of the guard functions recognised these ranges, so on a
host that routes the transition prefix the connection reached the
embedded private target (cloud metadata / internal SSRF).

Add a shared embeddedTransitionIpv4() detector and re-apply each guard's
own blocklist to the extracted IPv4 in isAlwaysBlocked, isPrivateNetwork,
isLinkLocal (ssrfGuard.ts) and isBlockedIp (egress-policy.ts). A
transition address to a public IPv4 stays allowed so legitimate
IPv6-only egress is unaffected.

egress-policy.ts keeps the detector inline to preserve its dependency-free
contract for the isolated plugin subprocess.

* chore: Add star history

* Revert "chore: Add star history"

This reverts commit f9d5f75837.

* fix(map): draw transit routes even without other places on the day

The reservation overlays hide any transport whose from/to endpoints
project closer than a per-type pixel threshold (200px for transit) to
declutter tiny no-op straight connectors. A transit journey, though,
draws its real rail/bus alignment rather than a straight endpoint line,
so on a zoomed-out day — one with no other places to tighten the map
onto — its stations fall under the threshold and the whole route
vanishes.

Exempt a transit booking that carries real per-leg geometry from the
proximity gate in both renderers (Leaflet + MapLibre); a geometry-less
transit keeps the straight-arc declutter.

* fix(atlas): resolve region AND country by coordinates against the bundled polygons

Rebased onto dev's streaming atlas index (#1576): region resolution now
resolves a place's lat/lng directly against the same bundled admin1
polygons the client renders — offline, deterministic, and guaranteed to
match a bundle feature — rather than trusting Nominatim's address level,
which can name a subdivision the bundle doesn't carry (Barcelona's ES-B
province vs the bundle's ES-CT autonomous community) and never highlight.
Country resolution moves to the same coordinates-first order, so a place
stored "..., San Francisco, CA" no longer resolves to Canada.

admin1 is held as per-country GeoJSON text (never parsed whole, #1576),
so a country's regions are flattened to the compact Float64Array form and
cached on first use — only visited countries pay the parse. The stale GB
constituent-country rescue is removed, and a one-time migration clears the
re-derivable place_regions cache so every place re-resolves under the new
logic.

Closes #1547

* fix(client): convert mixed-currency day/trip cost totals instead of mislabeling raw sums (#1561)

Day headers, the plan sidebar footer and the PDF day/cover totals summed
raw place prices across currencies and labeled the result with a single
currency — a $2,730.27 hotel on a NOK trip read as "2730 NOK".

Totals now convert every amount into a base currency via the existing
frankfurter rates (sidebar: the user's display currency, falling back to
the trip's; PDF: the trip currency, resolved once before rendering so the
document is consistent), marked with "≈" when a conversion happened. When
a rate is unavailable (offline, blocked egress, unknown code) they fall
back to an honest per-currency breakdown ("2 500 kr + $2,730.27") instead
of folding foreign amounts into a mislabeled number. All-same-currency
trips make no FX request, so offline PDF export keeps working.

Also swaps the place inspector's hardcoded € chip icon for a neutral one
and formats the price via formatMoney in the place's own currency.

Note: day-header totals move from "50 EUR" to Intl formatting ("50 €").

* feat(atlas): let a visited region be hidden, cascading to the country when none remain (server)

Countries already have a hide/tombstone mechanism (hidden_countries, #1490):
a zero-count derived country can be dismissed and stays gone across reloads.
Regions had no equivalent — unmarkRegionVisited only ever deleted a
manually-marked visited_regions row, a no-op for the common case of a region
derived fresh from place_regions on every request, so there was no way to
dismiss one at all (place-derived or otherwise).

Adds the region-level counterpart:
- New hidden_regions table (user_id, region_code, country_code), mirroring
  hidden_countries.
- getVisitedRegions() filters its result through it, the same way getStats()
  already filters through getHiddenCountries().
- unmarkRegionVisited() now tombstones unconditionally (not just for a
  manually-marked region — a region with a real place attached, e.g. one
  misassigned by a border-simplification gap, is exactly the case this
  exists for) and derives the country code from the region code's
  "<country>-<rest>" prefix when there's no visited_regions row to read it
  from.
- Cascade: after hiding a region, if the country has no other visible region
  left (checked against place_regions + visited_regions, minus hidden_regions),
  the country is hidden too via the existing unmarkCountryVisited.
- markRegionVisited() clears both tombstones on re-mark, so a region (and its
  cascade-hidden country) can come back.

Note the cascade only has a visible effect on a country with no real place
attached to it — getStats' places-derived country entries are never
suppressed by hidden_countries (#1490's deliberate "reappears with a real
place" rule), so hiding every region of a country that DOES have real places
leaves the country visible, by the same existing design. Test coverage
reflects this.

Server-side only — client wiring (a way to trigger this from the map) is a
separate commit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(atlas): let a visited region be hidden, cascading to the country when none remain (client)

Client wiring for the server-side hide-region feature (previous commit).

Clicking a visited region on the map used to open the hide/unmark
confirmation only when it was manually marked (visitedRegions[...].manuallyMarked);
a region derived from real place data instead opened the country-detail
view, with no way to dismiss it at all. Now any visited region offers the
same "Remove this region from your visited list?" confirmation regardless of
how it was derived — country details remain reachable via the country
search/sidebar, which was never gated on this in the first place.

The confirm handler's optimistic country-removal check dropped its
`&& r.manuallyMarked` filter on the remaining-regions count, matching the
server's unconditional cascade — but keeps the existing "only when the
country has zero real places/trips" guard, since a country backed by real
data is never actually hidden server-side (#1490) and removing it from the
UI early would just flash and reappear on the next reload.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* fix(settings): make fresh-instance unit defaults internally consistent

A brand-new instance — no admin-set defaults, no saved value — rendered
temperatures in Fahrenheit and times on the 12-hour clock while distances
defaulted to metric, a mix that matches no locale. The store also seeded
'fahrenheit'/'12h' while DisplaySettingsTab's fallback said 'celsius', so the
two paths disagreed about the intended default in the first place.

Default to one system — celsius / metric / 24h — matching the already-metric
distance_unit. The unit defaults now live in a single exported DEFAULT_SETTINGS
that both the store and DisplaySettingsTab's fallback read, so they can't drift
apart again. Admin-set user defaults (getAdminUserDefaults) and any value a user
has already saved still take precedence; only the code-level default changed.

* feat(i18n): complete Catalan (ca) translation

Adds Catalan as a supported language — the full shared/src/i18n/ca locale
(all domain files plus the notification texts), registered in
SUPPORTED_LANGUAGES and the client locale loader. Rebuilt onto current dev so
the locale is at full key parity with en (i18n:parity:strict clean).

* fix(map): stop real road-route fetches from dying under StrictMode

useTransportRoutes cached its AbortController in a ref that was
created once and aborted on unmount. React StrictMode's dev-only
mount->cleanup->remount cycle ran that abort during the *simulated*
cleanup, permanently poisoning the controller before the real mount's
fetch ever started — every road-routed booking (car/bus/taxi/bicycle)
silently fell back to a straight line in local dev, while production
builds (no StrictMode double-invoke) worked fine.

Fix: create a fresh AbortController per effect run instead of a
ref-cached singleton, and synchronously un-mark a job as "attempted"
in that same run's cleanup if it didn't settle before the cleanup
fired — so a StrictMode remount (or any other pre-completion
cancellation) retries instead of being skipped forever. Verified
against the real OSRM endpoint in a running dev server: all four
road-routed legs on a live trip now resolve with real road geometry
instead of straight lines.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(map): add reservation route-visibility util

Extracts the route-visibility filter that was hand-copied, identically,
in both MapView.tsx and MapViewGL.tsx into one pure, unit-tested
function: a reservation's route shows on the map when it's a transit
booking with the day-route toggle on, or its id is in the caller's
visible-ids set. isRoutableReservation (>= 2 endpoints) is exported
separately since callers besides the map filter need the same check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(map): add per-trip connections-visibility resolution util

Pure storage/resolution logic for a trip's booking-route visibility
preference, keyed trek:visible-connections:<tripId>. Two modes:
'only' (nothing shown except the listed ids — today's existing
behavior; a legacy bare-array localStorage value parses as this mode
for backward compatibility) and 'all-except' (everything routable
shown except the listed ids). A trip with no stored preference falls
back to the account-wide default (all or nothing) without writing
anything, so flipping the account setting later never silently
overrides a trip with an explicit per-trip choice already recorded.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(settings): add always-show-booking-routes account setting

New map_always_show_routes account setting, defaulting to off, i18n'd
across all 22 supported locales. Lives in Display > Travel & map,
directly under Booking route labels — its closest sibling — using
that section's immediate-save On/Off pattern rather than a separate
toggle+Save flow, since it's a booking-display preference, not a map
render-config option.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* feat(map): per-trip booking-route visibility with account default and bulk toggle

Lets a user see a booking's route on the map without manually
toggling it per item, two ways:

- The account setting from the previous commit sets the default for
  any trip that's never had its routes touched before.
- A new bulk "show all / hide all" button in the day-plan toolbar
  flips a trip explicitly between the two connectionsVisibility modes,
  independent of the per-item toggle (which still edits whichever
  mode's id list is active, in both directions, including while the
  account default is on).

useTripPlanner.ts resolves a trip's effective visible-connection ids
from connectionsVisibility.ts + the account setting + the trip's
routable reservations, and exposes it through the same
visibleConnections/toggleConnection contract MapView, MapViewGL and
DayPlanSidebar already had, plus allConnectionsShown/
toggleAllConnections for the new bulk control. MapView/MapViewGL
consume it via the shared reservationRoutes util instead of each
carrying their own copy of the filter.

The bulk toggle's tooltip gets its own map.showAllConnections/
hideAllConnections i18n keys (all 22 locales) distinct from the
per-item toggle's text, and matches the per-item toggle's active
(solid blue) styling rather than the toolbar's generic hover tint.

Manually verified end-to-end in a running dev server: the account
default seeding an untouched trip, the bulk toggle flipping a trip
between all-shown/all-hidden, and a single per-leg override while the
trip is in all-shown mode.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Update documentation for booking visibility change

* fix(i18n): add Catalan keys for the booking-route toggle + fix the language-count test

#1483 added map.showAllConnections/hideAllConnections and
settings.alwaysShowRoutes/Hint to every locale that existed when it was
written; Catalan (#1418) landed just after and was missing them, which
broke i18n parity. Also bumps the SUPPORTED_LANGUAGES test to 23 entries
and asserts the Catalan one — the ca addition left that assertion stale.

* test(e2e): add a reproducible documentation screenshot run

The wiki screenshots had drifted three months and two releases behind the UI:
39 of 46 assets came from a single commit in April, and pages such as
Budget-Tracking carry a disclaimer that their own images are out of date.
Retaking them by hand is what created that drift in the first place.

This adds a `screenshots` Playwright project that captures them from a dev
build instead:

- seed.ts populates a demo trip over the REST API — deliberately in JPY, so the
  3.4.0 currency work (per-trip currency, frozen FX rates, foreign-currency
  settle-up) is actually visible rather than hidden behind EUR.
- shot.ts settles the page before capturing (fonts, images, transitions) so
  captures don't catch skeleton loaders, and rewrites /auth/app-config to clear
  dev_mode — the E2E backend runs NODE_ENV=development, which would otherwise
  put a "Dev: Notifications" tab no real deployment has into every admin shot.
- promote.mjs downscales 2880px captures to 1600px on the way into
  wiki/assets/, which is 70% smaller for detail the wiki never renders.

Tabs are located by their visible label, so a rename like Budget → Costs fails
the run loudly instead of quietly capturing the wrong panel.

npm run shots && npm run shots:promote

* docs(wiki): retake screenshots against 3.4.0

Regenerated with `npm run shots` from the dev build. Replaces 21 assets and
adds 13 surfaces that had no screenshot at all.

Notable corrections:

- Collections.md referenced assets/Collections.png, which was never committed —
  the only broken image in the wiki. It now exists.
- The Budget panel became Costs in 3.3.0 (#1464); every budget image still
  showed the old label.
- The trip-create dialog gained a Currency field in 3.4.0, absent from the old
  TripCreate.png.
- Settings grew a Plugins tab and the admin sidebar a Plugins entry; neither
  appeared in the old sidebar shots.
- Weather now renders in Celsius. A fresh instance defaults to Fahrenheit while
  distance defaults to metric, so the seed pins both units — the mismatched
  defaults are a separate bug, not fixed here.

Koffi is installed from the community registry rather than dev-linked, because
dev-link and sideload both stamp a badge on the plugin card that an ordinary
install never shows.

Total 3.6 MB for 34 images, against 26 MB for the 46 assets already in the
directory.

No wiki page text is touched here — pages still point at the old filenames
where those were kept, and the newly added images are not referenced yet.

* fix(help): make wiki links and anchors work in the in-app reader

The wiki pages are written in GitHub-wiki style, and 455 of their links across
81 pages use the bare relative form — `[Currencies](Currencies)` — against only
114 `[[..]]` links. processMarkdown only rewrote the latter, so in-app every one
of those 455 fell through to HelpPage's external-link branch, opened a new tab
and 404'd. Since 6c87bf2f serves the wiki from disk, that is the primary way
users read these docs.

Rewriting them in the renderer fixes every page at once and keeps the sources
GitHub-compatible, so contributors can keep writing either form and neither
target breaks. Rewriting the 81 files instead would have fixed today's pages and
left the trap open for tomorrow's.

Also:

- Code is protected from the rewrite. Plugin-Development.md documents
  `actions[key](ctx)`, which reads as a markdown link and would otherwise be
  corrupted into `actions[key](/help/ctx)` inside a verbatim snippet.
- `[[Page#anchor|Slug]]` no longer renders its anchor as visible link text.
- Headings carry GitHub-compatible ids, so the 22 in-page `](#anchor)` links
  scroll instead of doing nothing.

* docs(wiki): correct settings, map and addon docs against 3.4.0

The wiki described settings that no longer exist and pointed at UI labels that
had been renamed. Each correction below was checked against the code.

- The Settings tab is labelled **General**, not "Display"
  (shared/src/i18n/en/settings.ts:6). Every "Settings → Display" path was wrong.
  The *display currency* setting keeps its name — only the tab was renamed.
- Colour mode is on the **Appearance** tab, not Display.
- The "Route calculation" setting does not exist: no hits for route_calc /
  routeCalc / auto_route / calculateRoutes anywhere in client or server.
- Default map centre and zoom were removed in 3.4.0 (0f4766e1). Replaced with
  what actually happens now, written from client/src/utils/mapViewport.ts:
  every map frames itself on its own places, world view when a trip has no
  coordinates.
- A third map provider, MapLibre GL / OpenFreeMap, was undocumented. It needs no
  access token, which is the reason a reader would choose it over Mapbox.
- Budget-Tracking.md said the feature is called Costs everywhere and then told
  the reader to open the "Budget" tab. The screenshot disclaimer is gone too —
  the images now show Costs.
- The admin tab table was missing Plugins.
- The `packing` addon is seeded as "Lists", not "Packing list management".
- Install docs pinned `mauriceboe/TREK:3.0.15` as the exact-release example,
  four minor versions stale.

* docs(wiki): document passkeys, calendar feeds, appearance, plugins and help

Five shipped features had no user documentation at all:

- **Passkeys** — WebAuthn enrolment and sign-in, admin policy, RP ID/origins.
  Previously mentioned only in passing in Environment-Variables.
- **Calendar Feeds** — the subscribable per-trip and per-user ICS feeds. Note
  Day-Plans-and-Notes documents only the one-off .ics *export*; the two are
  cross-referenced so it is clear which is which.
- **Appearance Settings** — the whole tab, including the custom accent colour
  and its contrast check.
- **Admin: Plugins** — installing from the registry, the pre-install permission
  review, egress hosts, and what Reviewed/Signed/Unsigned actually guarantee.
- **In-App Help** — that the wiki ships in the image and is served from disk
  since 3.4.0, with the GitHub fallback and TREK_WIKI_DIR.

One deliberate deviation from the brief: the Appearance settings are documented
as account-level, not per-device. They persist to /api/settings on the user
account with nothing in localStorage, so the dashboard widget picker's
desktop/mobile split still changes both from either device.

All five are listed in _Sidebar.md.

* docs(wiki): add screenshots for the remaining surfaces

Second capture pass, bringing the run to 42 screenshots. Adds the surfaces that
need more than a navigation to reach: collection and journey detail, MCP access,
two-factor setup, the settle-up payment dialog, and the trip file manager.

Two fixes to the harness itself, both of which had produced misleading images:

- The admin captures showed a "Dev: Notifications" tab that only exists when the
  server runs NODE_ENV=development. The run now clears dev_mode in the
  /auth/app-config response; switching the server to production instead would
  have enabled HSTS and broken the run over http://localhost.
- The settle-up capture clicked "Settle up", which does not open a view — it
  records the transfers. It zeroed every balance and photographed "Everyone's
  square", and because the specs share one database it poisoned Costs.png in the
  same run. Screenshot specs must not mutate state; it now captures the
  "Add payment" dialog instead.

Koffi is installed from the community registry rather than dev-linked, since
dev-link and sideload both badge the plugin card in a way no ordinary install
does.

* test(e2e): capture the detail pages and dialogs

Adds the second wave of screenshot specs (collection/journey detail, MCP access,
2FA, settle-up dialog, files) and enables the mcp, documents and collab addons
in the seed so their surfaces render instead of 404ing.

* docs(wiki): point plugin authors at the agent skill and the registry

Plugin-Development jumped straight into scaffolding without saying that two
supporting resources exist. TREK-Plugins was referenced only in passing far down
the page, and Plugin-Skill — an agent skill that teaches Claude Code and other
SKILL.md-compatible agents to build and publish a plugin — was not mentioned
anywhere in the wiki.

Both are called out up front, with a note that neither is required: the registry
only matters once you want other instances to find your plugin.

* test(e2e): capture the four collab surfaces separately

One Collab.png illustrated chat, notes, polls and the What's Next widget, so at
most one of those four wiki pages showed the feature it described. Each now has
its own capture.

Two things the collab seed needed:

- The conversation is posted by three different people. Every collab write is
  attributed to the acting user, and a single-voice chat log would misrepresent
  the feature outright.
- Each member therefore gets its OWN request context, created with an explicit
  `storageState: undefined`. Without that, newContext inherits the project's
  storageState — the admin's trek_session cookie — and extractToken reads the
  cookie BEFORE the Authorization header (server/src/middleware/auth.ts:9). The
  posts still return 200; they are just all recorded as the admin. That is
  exactly what happened on the first attempt, and the DB was the only place it
  showed.

The collab view is not tabbed — CollabPanel renders all panels at once — so the
captures target cards by seeded content rather than clicking tabs or matching
headings, whose DOM text is 'Notes'/'Polls' while CSS renders them uppercase.

* docs(wiki): show every screenshot on the page it belongs to

Finishes the wiring the screenshot commits deliberately left out.

- Embeds the 14 images that were committed but displayed nowhere: the Costs
  panel and settle-up dialog, the trip planner, transports, documents,
  collection and journey detail, the notifications inbox, the Offline and
  Account settings tabs, appearance, admin user defaults, registration and
  password reset.
- Splits the four collab pages onto their own images. Chat, Notes, Polls and
  What's Next each showed the same Collab.png until now; the overview shot moves
  to Real-Time-Collaboration, which had no image at all.
- Day-Plans-and-Notes pointed at TripPlaner.png — one 'n'. It now uses the
  correctly spelled file, and the misspelled one is deleted since nothing else
  referenced it.
- Removes 45 dead '<!-- TODO: screenshot -->' markers whose screenshot had long
  since been added. 9 remain, each on a page that genuinely still lacks the
  image it asks for — so the marker means something again and the gap is
  greppable, which is how this drifted unnoticed for three months.

Every asset in wiki/assets/ is now referenced by a page, and every image
reference resolves to a file.

* docs(wiki): add the four collab screenshots

Chat now shows a real three-person conversation rather than one voice talking to
itself, and the poll shows three separate votes across two options.

44 images, 4.6 MB total.

* test(help): point the asset test at the correctly spelled screenshot

The integration test hard-coded assets/TripPlaner.png — one 'n' — so deleting
the misspelled file broke it. It was the only thing keeping that filename
alive.

* docs(wiki): regenerate the screenshots on top of the rebased dev

ba3733da changed the fresh-instance defaults to celsius/metric/24h. Every
capture showing a clock — chat timestamps, bookings, day plans — and the General
settings tab itself were still on the 12-hour clock, so 39 of 44 images needed a
new run. Regenerating them is one command, which is the point.

The seed keeps pinning the units explicitly: it now matches the new defaults, but
stating them keeps the captures reproducible if a default moves again.

* docs(wiki): regenerate screenshots after rebasing onto dev

dev added a Catalan translation, an always-show-booking-routes account setting
and a bulk route toggle in the day-plan toolbar since the last run — all visible
on captures we ship. 15 of 44 images changed.

Also resolves the Map-Features conflict from 41d12e89: upstream's new bulk-options
section is kept, with the two 'Settings → Display' paths corrected to 'General'.
The tab is labelled General (shared/src/i18n/en/settings.ts:6), and upstream's own
i18n key for that section is settings.general.travelMap.

* chore: only allow manual trigger for the build&push

---------

Co-authored-by: Maurice <61554723+mauriceboe@users.noreply.github.com>
Co-authored-by: Dieter Blomme <dieterblomme@gmail.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Co-authored-by: sld272 <zjrdmczh@outlook.com>
Co-authored-by: Nguyen Trong Binh <nguytb15@VN1N07HO1CD1015.local>
Co-authored-by: Maurice <mauriceboe@icloud.com>
Co-authored-by: Pavel Zolotarevskiy <code@fxgn.dev>
Co-authored-by: Azalea <noreply@aza.moe>
Co-authored-by: Uzini <43294422+Uziniii@users.noreply.github.com>
Co-authored-by: Daniel <drmoreno271@gmail.com>
Co-authored-by: trongbinhnguyen <43725147+trongbinh15@users.noreply.github.com>
Co-authored-by: Konstantinos Thermos <info@subdee.org>
Co-authored-by: Konstantinos Thermos <subdee@users.noreply.github.com>
Co-authored-by: Lucas Español <lucas.espanol@tutanota.com>
Co-authored-by: fbnlrz <frlrnzn@gmail.com>

wiki/Accommodations.md

@@ -2,8 +2,6 @@
 
 Link an accommodation to specific check-in and check-out days so it appears for every day you are staying there. Accommodations are a distinct record type backed by the `day_accommodations` table and are separate from regular reservations, though each accommodation automatically creates a linked **Hotel** reservation.
 
-<!-- TODO: screenshot: accommodation list showing check-in/check-out details -->
-
 ## Creating an accommodation
 
 There are two ways to create an accommodation:

wiki/Addons-Overview.md

@@ -15,8 +15,8 @@ The following addons are registered in the system (defined in `server/src/db/see
 | Addon ID | Type | Description |
 |---|---|---|
 | `mcp` | integration | Exposes TREK data and actions through the Model Context Protocol for AI assistant integrations. |
-| `packing` | trip | Packing list management — create templates and lists linked to trips. See [Packing-Lists](Packing-Lists). |
-| `budget` | trip | Trip budget tracking — log expenses, set budgets, and track spending per trip. See [Budget-Tracking](Budget-Tracking). |
+| `packing` | trip | **Lists** — packing lists and to-do tasks for your trips. See [Packing-Lists](Packing-Lists). |
+| `budget` | trip | **Costs** — track and split trip expenses. See [Budget-Tracking](Budget-Tracking). |
 | `documents` | trip | Document and file attachments for trips — store itineraries, visa copies, and other files. See [Documents-and-Files](Documents-and-Files). |
 | `vacay` | global | Personal vacation day planner with a year calendar, holiday packs, and collaborator fusion. See [Vacay](Vacay). |
 | `atlas` | global | Interactive world map showing countries and regions you have visited, plus a bucket list. See [Atlas](Atlas). |

wiki/Admin-Addons.md

@@ -2,8 +2,6 @@
 
 The **Addons** tab lets you enable or disable optional features for the entire TREK instance. Toggling an addon affects all users immediately — disabling one hides its UI elements and blocks its API routes instance-wide.
 
-<!-- TODO: screenshot: addon toggle switches in admin panel -->
-
 ![Addon overview](assets/Addons-Overview.png)
 
 ## What addons control
@@ -18,7 +16,7 @@ Addons are grouped into three categories, shown as labeled sections.
 
 Trip addons add per-trip feature panels. They appear in every trip where the addon is enabled.
 
-The default trip addons are: **Lists**, **Budget**, **Documents**, **Collab**, and **Naver List Import** (all enabled by default). The exact list is determined by what is registered in your TREK database.
+The default trip addons are: **Lists**, **Costs**, **Documents**, **Collab**, and **Naver List Import** (all enabled by default). The exact list is determined by what is registered in your TREK database.
 
 **Sub-toggles on trip addons:**
 

wiki/Admin-Categories.md

@@ -2,8 +2,6 @@
 
 The **Personalization** tab → **Categories** section lets you manage global place categories. Categories are shared across all trips and all users on the instance.
 
-<!-- TODO: screenshot: category list in admin panel -->
-
 ![Category Manager](assets/CategoryManager.png)
 
 ## What categories are

wiki/Admin-GitHub-Releases.md

@@ -2,8 +2,6 @@
 
 The **GitHub** tab shows the TREK release history fetched from GitHub and provides links to community resources and support options.
 
-<!-- TODO: screenshot: GitHub releases panel with release timeline -->
-
 ![GitHub tab](assets/GithubReleases.png)
 
 ## Support and resources
@@ -21,7 +19,7 @@ Six cards at the top of the tab link to external resources:
 
 ## Release timeline
 
-Below the support cards, a chronological timeline lists GitHub releases for the `mauriceboe/TREK` repository. Each entry shows:
+Below the support cards, a chronological timeline lists GitHub releases for the `liketrek/TREK` repository. Each entry shows:
 
 - **Version tag** (e.g., `v2.9.14`)
 - A **Latest** badge on the first (most recent) entry in the displayed list

wiki/Admin-MCP-Tokens.md

@@ -4,8 +4,6 @@ The **MCP Access** panel shows all active MCP OAuth sessions and API tokens acro
 
 This panel is only visible when the **MCP addon** is enabled in the [Admin-Addons](Admin-Addons) panel.
 
-<!-- TODO: screenshot: OAuth client and token list in MCP Access panel -->
-
 ![MCP Access](assets/MCPAccess.png)
 
 ## OAuth Sessions

wiki/Admin-Packing-Templates.md

@@ -2,8 +2,6 @@
 
 The **Personalization** tab → **Packing Templates** section lets you create reusable packing list templates that users can apply to any trip.
 
-<!-- TODO: screenshot: packing templates admin list with categories and items -->
-
 ![Packing Template Manager](assets/PackingTemplate.png)
 
 ## What templates are

wiki/Admin-Panel-Overview.md

@@ -6,8 +6,6 @@ The Admin Panel is the central control surface for TREK instance operators. It i
 
 Navigate to the **Admin** link in the top navbar. If you do not see it, your account does not have admin privileges.
 
-<!-- TODO: screenshot: admin panel main dashboard with tabs -->
-
 ![Admin Panel](assets/AdminPanel.png)
 
 ## Tabs
@@ -20,6 +18,7 @@ The Admin Panel is divided into tabs. Most tabs are always visible; a few appear
 | **Personalization** | Packing templates and place categories | No |
 | **User Defaults** | Default settings applied to new users | No |
 | **Addons** | Enable or disable optional features instance-wide | No |
+| **Plugins** | Install, update, and manage plugins; rescan the plugins folder; review each plugin's capability audit. See [Admin-Plugins](Admin-Plugins) | No |
 | **Settings** | Authentication methods, MFA, allowed file types, API keys, OIDC/SSO configuration, and JWT secret rotation | No |
 | **Notifications** | SMTP, webhook, ntfy, and push notification channel configuration; trip reminder toggle; admin notification preferences | No |
 | **Backup** | Manual and scheduled database backups | No |
@@ -28,6 +27,8 @@ The Admin Panel is divided into tabs. Most tabs are always visible; a few appear
 | **GitHub** | Release timeline and support links | No |
 | **Dev: Notifications** | Test notification dispatch | Only in development mode (`NODE_ENV=development`) |
 
+![Admin panel on the User Defaults tab, setting instance-wide defaults for colour mode, temperature unit, distance unit, time format, currency and blurred booking codes](assets/AdminUserDefaults.png)
+
 ## Plugin activity and audit
 
 Plugins that are granted data-access capabilities have every host-mediated action they take recorded in a tamper-evident, hash-chained log. This log is separate from the instance **Audit** tab described above.

wiki/Admin-Permissions.md

@@ -2,8 +2,6 @@
 
 The Permissions panel, located at the bottom of the **Users** tab, controls which role level is required to perform each action. Changes apply immediately across the entire instance.
 
-<!-- TODO: screenshot: permissions matrix with role dropdowns -->
-
 ![Permissions panel](assets/PermissionSettings.png)
 
 ## Role model

wiki/Admin-Plugins.md

@@ -0,0 +1,125 @@
+# Admin: Plugins
+
+Install, review, enable, update, and remove third-party plugins on your instance.
+
+![Admin Plugins](assets/AdminPlugins.png)
+
+## Where to find it
+
+Open the **Admin Panel** and select the **Plugins** tab. *Install and manage third-party plugins on your instance.*
+
+> **Admin:** This whole panel is admin-only. It also needs the plugin runtime turned on — otherwise you get *Plugins are disabled*: **The plugin runtime is turned off (`TREK_PLUGINS_ENABLED`). No plugin can run until an admin enables it in the server configuration.** When the runtime is on, a green **Runtime on** pill appears in the header.
+
+For what plugins are and how users interact with them, see [Plugins](Plugins).
+
+## The two views
+
+A segmented switch at the top toggles between:
+
+- **Installed** — what is on this instance, with a count.
+- **Discover** — the community registry, browsable as cards.
+
+Both views share a toolbar: a **Search plugins…** box, a **Type** filter (Widget / Page / Integration / Trip page), a **Sort** menu, an **Upload plugin** button, and a **Rescan** button. The **Installed** view adds a **Status** filter (Active / Off / Update available / Error).
+
+**Rescan** does two things: it rediscovers locally-installed plugins *and* force-pulls the registry, bypassing the 30-minute server cache and GitHub's CDN, so a just-published plugin shows up immediately instead of up to ~35 minutes later.
+
+## Installing from the registry
+
+1. Switch to **Discover**. Each card shows the icon, name, author, description, type, a **Reviewed** badge if applicable, the **Signed**/**Unsigned** badge, the latest version, and a download count.
+2. Click a card to open the **pre-install review dialog** (see below).
+3. Click **Install**.
+
+If the newest release requires a newer TREK than you are running, the button changes: when an older release still fits you get **Install {version}** for that one; when nothing fits, the button reads **Incompatible** and is disabled. Either way the dialog explains why in an amber note — it does not hide the reason behind a tooltip.
+
+A newly installed plugin is **off**. Nothing runs until you enable it.
+
+### The pre-install review dialog
+
+Before installing, read these sections:
+
+- **What it can access** — the plugin's requested permissions, rendered as plain-language lines ("Read the trips…", "Create and edit places…"). Unknown permission codes appear verbatim. If it asks for nothing, this reads *Needs no special access.*
+- **Connects to** — every host the manifest declares it may reach, as monospace chips.
+- **Setup** — settings the plugin will ask you (or each user) to fill in, tagged **Instance-wide** or **Per user**, and **Required** where applicable.
+- **Details** — version, size, the TREK version range it requires, when it was reviewed, and total downloads.
+
+A footer links to the **Source repository**, **Report an issue**, and the plugin's **Homepage**.
+
+### Operator egress hosts
+
+Some plugins talk to a service only *you* can name — a self-hosted Gotify, ntfy, or similar. Their manifest cannot list a host, so the review dialog adds a **+ hosts you add** chip and this note:
+
+> *This plugin talks to a service only you can name (a self-hosted server). After installing, add the hosts it may reach under ⋯ → Allowed hosts. It can reach no others.*
+
+After install, open the row's **⋯ → Allowed hosts** dialog and add hostnames one at a time. Until you add at least one, the plugin's row shows an amber **Add allowed host** chip, because it can reach nothing and would otherwise look silently broken. Once hosts exist the chip turns blue and counts them.
+
+Saving restarts the plugin so it picks up the new list — a running plugin's allow-list can never be widened in place.
+
+## Enabling, restarting, and disabling
+
+Each installed row has a toggle (**Enable plugin**) and shows **Active** or **Off**. A coloured dot on the icon tile reflects runtime health: active, starting, error, inactive, disabled, or incompatible.
+
+Enabling can be refused for good reasons, each of which opens the right remedy:
+
+- **A required addon is disabled** — a toast names the addon; turn it on in [Admin-Addons](Admin-Addons).
+- **A plugin dependency is missing or outdated** — a dialog lists each dependency with a one-click **Download** / **Update** that installs the newest compatible version and then retries.
+- **The update widened its permissions** — the consent dialog (below).
+
+Installed-but-disabled dependencies are enabled automatically as a cascade, and a toast tells you which.
+
+The row's **⋯** menu offers **Restart** (active plugins only), **View error log**, **Allowed hosts**, links to the **Source repository** and **Report an issue** for registry plugins, and **Delete**.
+
+## Updating
+
+When a newer version exists, the row grows an **Update → v{version}** button, and a bar above the list reads *{count} updates available for your plugins.* with an **Update all** button.
+
+If the new version requests rights you have not granted, TREK installs it but leaves it off and shows **This update needs new permissions**:
+
+> *{name} v{version} is asking for rights you haven't granted yet. The new version is installed but stays off until you approve it.*
+
+The dialog lists **Newly requested permissions** and **New outbound connections**. Choose **Approve & turn on** or **Keep off for now**. Updating several plugins at once queues these prompts, so none is skipped. If the version being approved is unsigned, the dialog adds a line saying nothing ties it to its author.
+
+### Blocked updates
+
+If an author's signing key no longer matches the one pinned at install, the update is refused and the row shows **Update blocked — {reason}** with a **Review** link. The dialog then shows the pinned key fingerprint next to the offered one:
+
+> *TREK cannot tell a legitimate key rotation apart from a takeover — both look identical from here. Confirm the new key with the author through a channel you already trust before you accept it.*
+
+Only a **changed key** can be overridden (**Trust the new key & update**). A signature that is invalid, missing, or half-declared gets an explanation and **no override button at all** — the server refuses those too.
+
+## Uninstalling
+
+**⋯ → Delete** asks **Uninstall plugin?** — *This stops the plugin, removes its code, and deletes all of its data. This cannot be undone.*
+
+## Badges: what they do and do not guarantee
+
+- **Reviewed** — *"Reviewed" means a TREK maintainer scanned this plugin for malware on each version — not for quality or whether it works. It is not a guarantee that a plugin is harmless.*
+- **Signed** — the files were verified against the author's signing key at install, and that key is pinned. A checksum already proves the files are what the *registry* vouches for; a signature proves they came from the *author*.
+- **Unsigned** — *The files match what the registry vouches for, but nothing ties them to the author. One guarantee fewer — not unsafe.* Most registry plugins are unsigned today, which is why this is an amber note rather than an alarm.
+
+Neither badge says anything about what the code *does*. A collapsible **How plugins are contained — and the limits** panel at the bottom of the tab spells out the isolation model, what permissions really constrain, what TREK cannot promise, and the worst case. Read it once.
+
+## Sideloading and dev-linking
+
+Two paths install a plugin that never went through the registry:
+
+- **Upload plugin** (toolbar button, or drag a `.zip` onto the panel) — installs the archive **inactive**; you still consent on activation. The row is marked **Sideloaded**: *Uploaded manually — not from the registry, unsigned and unreviewed.*
+- **Link a local plugin** — a path field that registers a plugin from a local build directory and hot-reloads it against real data. Dev only, and only shown when the server sets `TREK_PLUGINS_DEV_LINK=1`. The row is marked **Dev-Link**.
+
+Be honest with yourself about what these badges mean: both are only a *label on the card*. They record where the code came from — they do not check, sandbox differently, or restrict it. A sideloaded or dev-linked plugin runs with exactly the permissions it declares, same as a registry one, and it received no malware scan and carries no signature. The badge is there so you can tell at a glance that no one but you vouched for that code. (The source badge also replaces the Signed/Unsigned badge on those rows, since it already says something stronger.)
+
+## Permissions
+
+Every endpoint on this panel requires an admin account, on top of the `TREK_PLUGINS_ENABLED` runtime kill-switch. Dev-link additionally requires `TREK_PLUGINS_DEV_LINK`.
+
+The per-plugin permissions shown in the review and consent dialogs are documented in [Plugin-Permissions](Plugin-Permissions).
+
+## See also
+
+- [Plugins](Plugins)
+- [Plugin-Permissions](Plugin-Permissions)
+- [Plugin-Development](Plugin-Development)
+- [Plugin-Publishing](Plugin-Publishing)
+- [Admin-Addons](Admin-Addons)
+- [Admin-Panel-Overview](Admin-Panel-Overview)
+- [Environment-Variables](Environment-Variables)
+- [Security-Hardening](Security-Hardening)

wiki/Admin-Users-and-Invites.md

@@ -2,8 +2,6 @@
 
 The **Users** tab in the Admin Panel lets you view all registered users, manage their accounts, and create invite links so new people can register without open registration.
 
-<!-- TODO: screenshot: users table with invite form -->
-
 ![Users tab](assets/UsersAndInvites.png)
 
 ## User list

wiki/Appearance-Settings.md

@@ -0,0 +1,90 @@
+# Appearance Settings
+
+Tune how TREK looks — colour mode, accent scheme, readability, and which dashboard widgets you see.
+
+![Settings page on the Appearance tab showing the Light / Dark / Auto colour mode buttons, the eight colour scheme swatches, and the Readability section with transparency, reduce motion and density controls](assets/UsrSettingsAppearance.png)
+
+## Where to find it
+
+Open **Settings** and select the **Appearance** tab.
+
+Changes preview instantly and are saved to your account a moment later, so they follow you to every browser you sign in with. A **Reset to defaults** button at the bottom of the tab restores everything on this page in one click.
+
+> These are personal settings — no permission and no admin toggle gate them.
+
+## Theme
+
+### Color mode
+
+Three segmented buttons: **Light**, **Dark**, and **Auto**. **Auto** follows your operating system's light/dark preference.
+
+### Color scheme
+
+A grid of accent schemes, each with a colour dot that previews in your current mode:
+
+- **Default** — TREK's monochrome look.
+- **High contrast** — raises text and border contrast.
+- **Indigo**, **Teal**, **Rose**, **Amber**, **Violet** — coloured accents.
+- **Custom** — pick your own accent (below).
+
+### Custom accent
+
+Choosing **Custom** reveals a **Custom accent** picker:
+
+1. Click one of the ten preset swatches to set light and dark to the same colour, or
+2. Use the **Light** and **Dark** colour inputs to pick a different accent for each mode.
+
+Next to the pickers, a live contrast badge evaluates the accent you are currently seeing against white and shows the ratio:
+
+- **Good contrast (n.n:1)** — the ratio meets WCAG AA for normal text (4.5:1 or better).
+- **Low contrast (n.n:1)** — below 4.5:1; white text on that accent will be hard to read.
+
+The badge is advisory. TREK will still let you apply a low-contrast accent.
+
+## Readability
+
+This whole section carries an **Experimental** badge.
+
+- **Transparency** — *Glassy translucent surfaces. Turn off for solid, higher-contrast backgrounds.*
+- **Reduce motion** — *Minimize animations and transitions.*
+- **Density** — **Comfortable** or **Compact**. *Compact tightens spacing and padding for a denser layout that fits more on screen.*
+
+### Text size
+
+Text scaling works on four axes plus one master control. Every slider runs from **80%** to **160%** in 5% steps, and shows its current percentage on the right.
+
+- **Everything** — a global scale applied on top of the per-tier values.
+- **Large** — *Headings, big numbers*
+- **Medium** — *Sub-headings*
+- **Normal** — *Place names, descriptions*
+- **Small** — *Addresses, labels*
+
+Each of the four rows renders a live sample in that tier ("Large heading", "Medium subtitle", "Normal body text", "Small caption / address"), so you can see the effect while dragging.
+
+## Dashboard widgets
+
+*Show or hide dashboard widgets independently on desktop and mobile.* This does not detect your current device — it sets two independent layouts, and the dashboard picks the one matching the viewport it is rendered at. Both layouts are stored on your account, so a change made on your laptop also changes what your phone shows.
+
+### Desktop
+
+- **Below the hero** — **Atlas / countries**, **Trips total**, **Days traveled**, **Distance flown**.
+- **Right sidebar** — a master toggle (*The whole right column. Turn off and the dashboard centers.*) with four widgets nested under it: **Currency**, **Collections**, **Timezones**, **Upcoming reservations**. Turning the master off greys the nested toggles out; their individual states are remembered for when you turn it back on.
+
+### Mobile
+
+- **Below the hero** — **Trips total**, **Days traveled**.
+- **Bottom of page** — **Currency**, **Collections**, **Timezones**, **Upcoming reservations**.
+
+Hiding a widget here only affects your own dashboard. Widgets that depend on an addon (for example **Collections**) also need that addon enabled by an admin — see [Dashboard-Widgets](Dashboard-Widgets) and [Admin-Addons](Admin-Addons).
+
+## Permissions
+
+None. Every setting on this tab applies only to your own account.
+
+## See also
+
+- [Display-Settings](Display-Settings)
+- [User-Settings](User-Settings)
+- [Dashboard-Widgets](Dashboard-Widgets)
+- [My-Trips-Dashboard](My-Trips-Dashboard)
+- [Map-Settings](Map-Settings)

wiki/Atlas.md

@@ -4,8 +4,6 @@ Atlas is an interactive world map that shows countries and regions you have visi
 
 > **Admin:** enable Atlas in [Admin-Addons](Admin-Addons).
 
-<!-- TODO: screenshot: world map with visited countries highlighted -->
-
 ![Atlas](assets/Atlas.png)
 
 ## What Atlas is

wiki/Audit-Log.md

@@ -6,8 +6,6 @@ The audit log records significant actions taken on your TREK instance. Use it to
 
 **Admin Panel → Audit** tab.
 
-<!-- TODO: screenshot: audit log table with action entries -->
-
 ![Audit log](assets/Audit.png)
 
 ## What the log captures

wiki/Backups.md

@@ -6,8 +6,6 @@ TREK stores all data in a single SQLite database (`travel.db`) plus an `uploads/
 
 **Admin Panel → Backup** tab.
 
-<!-- TODO: screenshot: backup tab with backup list and auto-backup settings -->
-
 ![Backup tab](assets/Backup.png)
 
 ## What a backup contains

wiki/Budget-Tracking.md

@@ -1,26 +1,32 @@
-# Budget Tracking
+# Costs (Budget Tracking)
 
 Track trip expenses by category, split costs between members, and visualize spending.
 
-> **Renamed to Costs (v3.3.0, #1464):** This feature is now called **Costs** everywhere in the UI — the planner tab reads **Costs** and it is listed as **Costs** in Admin → Addons (its internal addon id stays `budget`). Screenshots and some labels on this page may still say "Budget".
+> **Renamed to Costs (v3.3.0, #1464):** This feature is now called **Costs** everywhere in the UI — the planner tab reads **Costs** and it is listed as **Costs** in Admin → Addons. Its internal addon id stays `budget`, which is why the permission is `budget_edit` and the MCP scopes are `budget:read` / `budget:write`.
 
-<!-- TODO: screenshot: budget summary and expense list -->
+![Costs tab of a trip showing the You owe / You're owed / Outstanding / Total trip spend cards above the dated expense list, with the settle-up transfers and per-member balances in the right-hand column](assets/Costs.png)
 
-![Budget panel](assets/Budget.png)
+![Costs panel](assets/Budget.png)
 
 ## Where to find it
 
-Open the **Budget** tab inside the trip planner. The tab is only visible when the Budget addon is enabled.
+Open the **Costs** tab inside the trip planner. The tab is only visible when the Costs addon is enabled.
 
-> **Admin:** Budget is an addon. Enable it in [Admin-Addons](Admin-Addons).
+> **Admin:** Costs is an addon. Enable it in [Admin-Addons](Admin-Addons).
 
 ![Create Budget](assets/BudgetCreateBudget.gif)
 
 ## Currency
 
-Costs is **multi-currency** (#551). Each expense (line item) is entered in **its own currency** — pick it from the currency picker in the expense modal — and everything is converted to a single **display currency** for totals, charts and settlement. The display currency is your own preferred currency (**Settings → default currency**), falling back to the trip's currency when you haven't set one. 47 currencies are supported.
+Costs is **multi-currency** (#551). Three settings are involved, and they do different jobs:
 
-When an item's currency differs from the display currency, the modal shows the converted amount alongside the rate (`1 {from} in {to}`). The exchange rate is **frozen at entry time**, so a settled position keeps the rate it was booked at and doesn't drift as live rates move.
+- The **trip currency** (Trip → Edit trip) is the trip's accounting base. Every balance and settle-up is calculated in it.
+- Each **expense** carries **its own currency** — pick it in the expense modal and enter what the receipt says (a $100 dinner on a rouble trip is `100 USD`). It is converted into the trip currency at a rate **frozen when you save it**, so a settled debt doesn't reopen when the market moves.
+- Your **display currency** (Settings → General) converts what you *read* — totals, chart, balances — into one currency. It changes nothing that is stored. Left on **Trip currency** (the default), each trip is shown in its own currency.
+
+165 currencies are supported, with rates from [Frankfurter](https://frankfurter.dev) (no API key needed). When an item's currency differs from the display currency, the modal shows the converted amount alongside the rate (`1 {from} in {to}`), and the ledger row shows both (`$100.00 → 7 668,71 ₽`).
+
+> **Read [Currencies](Currencies) for the full picture** — how the three interact, what happens when you change a trip's currency, and which currency a public share link is shown in.
 
 ## Categories
 
@@ -74,9 +80,15 @@ When multiple members are assigned to expenses and there are outstanding debts b
 - Transfer flows: who pays whom and how much.
 - Net balances: each member's overall surplus or deficit.
 
+Balances are always netted in the **trip currency** and converted to your display currency once, at the end — so they stay stable even when the trip mixes currencies.
+
+A recorded payment carries **its own currency** too: settling a rouble debt with a euro transfer is normal, so the payment modal has a currency picker, and its rate is frozen when you record it. A payment made in another currency shows both amounts in the ledger (`$30.00 → 27,00 €`).
+
+![Add payment dialog with From and To member pickers, an amount field and a currency selector](assets/CostsSettleUp.png)
+
 ![Final Settlement](assets/BudgetFinalSettlement.gif)
 
-## Budget summary
+## Costs summary
 
 The right-hand column contains two widgets:
 
@@ -89,10 +101,11 @@ Click **Export CSV** in the toolbar to download all expenses as a spreadsheet (r
 
 ## Permissions
 
-All write operations (adding/editing/deleting items and categories, changing currency) require the `budget_edit` permission.
+All write operations (adding/editing/deleting items and categories, and an expense's currency) require the `budget_edit` permission. The **trip** currency lives on the trip itself, so changing that requires `trip_edit` instead.
 
 ## See also
 
+- [Currencies](Currencies)
 - [Admin-Addons](Admin-Addons)
 - [Reservations-and-Bookings](Reservations-and-Bookings)
 - [Trip-Planner-Overview](Trip-Planner-Overview)

wiki/Calendar-Feeds.md

@@ -0,0 +1,78 @@
+# Calendar Feeds
+
+Subscribe your calendar app to a TREK trip so it stays in sync automatically, instead of importing a snapshot once.
+
+> **Not the same as the ICS export.** The **Download ICS** action described in [Day-Plans-and-Notes](Day-Plans-and-Notes) writes a one-off `.ics` file that never changes after you import it. A calendar *feed* is a live URL your calendar re-fetches on its own. Use the export for a frozen copy, a feed for something that keeps up with your edits.
+
+## Where to find it
+
+There are two feeds, reached from two places:
+
+- **Per-trip feed** — in the trip planner, hover the **ICS** button in the Day Plan sidebar toolbar and choose **Subscribe to calendar**. (The other entry in that menu, **Download ICS**, is the one-off export.)
+- **All-trips feed** — on the **My Trips** dashboard, click the calendar-plus button in the toolbar (**Subscribe to all trips**).
+
+Both open the same dialog.
+
+## Per-trip vs. all-trips
+
+|                     | Per-trip feed                     | All-trips feed                                              |
+|---------------------|-----------------------------------|-------------------------------------------------------------|
+| Covers              | One trip                          | Every trip you own **or** are a member of                    |
+| Calendar name       | The trip title                    | *{your username} – All Trips*                                |
+| Excludes            | —                                 | Archived trips, and trips that ended more than 90 days ago   |
+| URL                 | `/api/feed/trip/{token}.ics`      | `/api/feed/user/{token}.ics`                                 |
+| Token lives on      | The trip                          | Your user account                                            |
+
+The all-trips feed merges every qualifying trip into one calendar, sorted by start date, and de-duplicates the time-zone definitions so each event still resolves to the right local time.
+
+## Turning a feed on
+
+1. Open the **Subscribe to calendar** (or **Subscribe to all trips**) dialog. Opening it only reads the current state — it never mints a link behind your back.
+2. Click **Enable calendar subscription**. TREK generates a random token and shows the feed URL.
+3. Hand the URL to your calendar app with one of the buttons:
+   - **Add to Google Calendar** — opens Google's add-by-URL page with the feed pre-filled.
+   - **Add to Apple Calendar / Outlook** — a `webcal://` link that the OS hands to your default calendar app.
+   - **Or copy a link manually** — expand this to copy the raw `https://…` URL (for a *From URL* box) or the `webcal://` variant.
+
+The URL is built from `APP_URL` when it is set; otherwise TREK falls back to the host you are browsing from. Set `APP_URL` behind a reverse proxy so the link is the one your calendar app can actually reach — see [Environment-Variables](Environment-Variables) and [Reverse-Proxy](Reverse-Proxy).
+
+## The token, and who can read the feed
+
+The random token in the URL **is** the credential. The feed endpoint requires no login: anyone who has the link can read the whole trip — every event, note, address, and confirmation detail — without an account. The dialog says as much: *Creates a secret link anyone with it can read without logging in. You can turn it off anytime.*
+
+Treat the URL like a password. Don't post it in a shared document or a public issue.
+
+## Rotating and revoking
+
+Once a feed is enabled, two buttons appear beneath the subscribe links:
+
+- **Regenerate** — issues a new token. The old URL stops resolving immediately, so every calendar still subscribed to it goes dead and has to be re-added.
+- **Turn off** — clears the token entirely. The URL 404s and no feed exists until you enable one again.
+
+Use **Regenerate** if a link leaked; use **Turn off** if you no longer want a public feed at all.
+
+## What appears in the feed
+
+The feed carries the same events as the ICS export:
+
+- **The trip itself** — an all-day event spanning the trip's start and end dates, with the trip description.
+- **Timed day assignments** — one event per place that has a time, using the place name as the title, its address as the location, and its notes in the description. Times are anchored to the place's own time zone.
+- **A per-day summary event** — an all-day event for each day that has untimed places or notes, titled with the day title (or *Day N*), listing those places and notes in the description.
+- **Reservations** — hotels, restaurants, and transport. Flights and other transport take their start and end from the departure and arrival endpoints, each in its own time zone. Reservations with no placeable date are skipped.
+
+Feeds are served with cache headers that tell clients not to cache, plus an hourly refresh hint (`REFRESH-INTERVAL` / `X-PUBLISHED-TTL` of one hour). Most calendar apps treat that as a suggestion — Google in particular refreshes on its own schedule, often much slower — so an edit may take a while to show up.
+
+## Permissions
+
+No dedicated permission gates feeds. You can manage a per-trip token if you own the trip or are a member of it; anyone else gets a *Trip not found*. The all-trips feed is always scoped to your own account.
+
+Because the token grants unauthenticated read access, enabling a feed effectively shares that trip's contents with whoever holds the link, regardless of trip roles — see [Public-Share-Links](Public-Share-Links) for the equivalent trade-off on the sharing side.
+
+## See also
+
+- [Day-Plans-and-Notes](Day-Plans-and-Notes)
+- [Trip-Planner-Overview](Trip-Planner-Overview)
+- [Reservations-and-Bookings](Reservations-and-Bookings)
+- [Public-Share-Links](Public-Share-Links)
+- [My-Trips-Dashboard](My-Trips-Dashboard)
+- [Environment-Variables](Environment-Variables)

wiki/Collab-Chat.md

@@ -2,9 +2,7 @@
 
 Chat with your group in real time, without leaving the trip planner.
 
-<!-- TODO: screenshot: chat panel with messages and reactions -->
-
-![Collab Chat](assets/Collab.png)
+![The trip chat, with messages from three trip members](assets/CollabChat.png)
 
 ## Where to find it
 

wiki/Collab-Notes.md

@@ -2,9 +2,7 @@
 
 Share structured, richly formatted notes with your group. Notes are organized into color-coded categories and can be pinned, attached with files, and linked to external websites.
 
-<!-- TODO: screenshot: collab notes editor with categories -->
-
-![Collab Notes](assets/Collab.png)
+![Shared trip notes, grouped by category with colour coding](assets/CollabNotes.png)
 
 ## Where to find it
 

wiki/Collab-Polls.md

@@ -2,9 +2,7 @@
 
 Create group polls to make decisions collaboratively — where to eat, which hotel, what to do on a free day.
 
-<!-- TODO: screenshot: poll with options and vote counts -->
-
-![Collab Polls](assets/Collab.png)
+![A trip poll with three options and the current vote counts](assets/CollabPolls.png)
 
 ## Where to find it
 

wiki/Collections.md

@@ -4,8 +4,6 @@ Collections is a personal, server-wide library of saved places that lives outsid
 
 > **Admin:** enable Collections in [Admin-Addons](Admin-Addons).
 
-<!-- TODO: screenshot: the /collections page with the lists rail, a list hero and the places -->
-
 ![Collections](assets/Collections.png)
 
 ## What Collections is
@@ -24,6 +22,8 @@ The dashboard also gains a **Collections widget** that surfaces your lists as co
 - **Edit or delete a list** from the **Edit** button in the list's hero (owner only). Deleting a list removes its saved places.
 - **All saved** is a built-in view that unions the places from every list you own or co-own, so you can search and act across your whole library at once.
 
+![A single collection, "Kyoto shortlist", with its coloured hero, Edit and Share actions, the lists rail on the left and three saved places each marked Idea, next to the map](assets/CollectionDetail.png)
+
 ## Place status
 
 Every saved place carries a status you can cycle with one tap:

wiki/Creating-a-Trip.md

@@ -1,7 +1,5 @@
 # Creating a Trip
 
-<!-- TODO: screenshot: trip creation form with date and cover fields -->
-
 ![Trip creation dialog](assets/TripCreate.png)
 
 ## Opening the Dialog
@@ -28,6 +26,14 @@ If you leave **both** dates empty, a separate **Day count** field appears. Enter
 
 You cannot set only one date and leave the other blank via normal interaction — setting a start date auto-fills or adjusts the end date to preserve the previous duration.
 
+### Currency
+
+The trip's currency — its **accounting base**. Every expense in the Costs tab is converted into it, and every balance and settle-up suggestion is calculated in it. Defaults to **EUR**; 165 currencies are available.
+
+Pick the currency you will actually settle up in. It is not a cosmetic label, but it is not a one-way door either: you can change it later from the same dialog (with the `trip_edit` permission), and TREK re-bases the existing expenses so no money moves — see [Currencies → Changing the trip currency](Currencies#changing-the-trip-currency).
+
+> This is **not** the same as the display currency in Settings → General, which only changes what *you* read. See [Currencies](Currencies).
+
 ### Cover Image
 
 The cover image is displayed on the trip card and as the background of the Spotlight card. You can add one in three ways:

wiki/Currencies.md

@@ -0,0 +1,110 @@
+# Currencies
+
+TREK has **three** currency settings, and they answer three different questions. Most confusion about the Costs tab comes from mixing them up, so this page is the one place they are defined together.
+
+| Setting | Where | Question it answers | Affects |
+|---|---|---|---|
+| **Trip currency** | Trip → Edit trip | *What is this trip's money?* | Stored data — the base every balance is calculated in |
+| **Expense currency** | Costs → expense modal | *What currency did I actually pay in?* | Stored data — that one expense |
+| **Display currency** | Settings → General | *What currency do I want to read?* | Presentation only — never the stored data |
+
+The short version: **the trip currency is the accounting base, the expense currency is the receipt, and the display currency is your reading glasses.**
+
+## Trip currency
+
+Every trip has exactly one currency. It is set when you create the trip and can be changed later in the trip edit dialog (requires the `trip_edit` permission). It defaults to **EUR**.
+
+This is the trip's **accounting base**. It is not a cosmetic label:
+
+- Every balance, debt and settle-up suggestion is calculated in it.
+- Every expense in another currency is converted **into it** and stored with the rate it was converted at.
+- It is what the Costs tab falls back to when nobody has expressed a display preference.
+
+Pick the currency of the place you are travelling to (or the one you will actually settle up in), and you will rarely think about currencies again.
+
+### Changing the trip currency
+
+Changing it is **not** a relabelling — it is a re-basing, and TREK does the work for you so that no money moves:
+
+- Expenses that had no currency of their own (they simply inherited the trip's) are **pinned to the old currency** first. A 9 000 ₽ expense on a trip switching from RUB to EUR stays *9 000 ₽*; it does not silently become 9 000 €.
+- Every frozen exchange rate is **re-anchored** to the new base, because a frozen rate is stored relative to the trip currency (see below).
+- **Place prices** are pinned the same way. A place price also inherits the trip's currency unless you gave it one of its own, so a €15 museum on a trip switching to JPY is stamped EUR rather than starting to read as ¥15.
+
+The numbers you typed are never rewritten. Each expense keeps its original amount, in its original currency, and its real-world value survives the switch — only the base the balances are expressed in changes.
+
+## Expense currency
+
+Each expense in the Costs tab carries **its own currency**, chosen in the expense modal. Enter what the receipt says: a $100 dinner on a rouble trip is entered as **100 USD**, not as its rouble equivalent.
+
+When an expense's currency differs from the trip currency, TREK looks up the live rate **once, at the moment you save it**, and freezes it on the expense. That frozen rate is what converts the expense into the trip currency forever after.
+
+> **Why freeze it?** Because a debt settled today shouldn't reopen tomorrow. If balances were recomputed at live rates, a settled-up trip would drift back into a few cents of debt every time the FX market moved. The rate you booked at is the rate you owe at.
+
+Rates come from [Frankfurter](https://frankfurter.dev) (European Central Bank data, no API key needed). **165 currencies** are supported. If the rate lookup fails (the instance is offline, or the upstream is down), the expense is stored without a frozen rate and falls back to live conversion when it is next read — TREK never invents a rate.
+
+### Settle-up payments
+
+A payment recorded in **Settle Up** also carries its own currency, for the same reason: settling a rouble debt with a euro transfer is perfectly normal. Its rate is frozen at the moment you record it, exactly like an expense's, so the payment keeps cancelling the debt it was meant to cancel.
+
+## Display currency
+
+**Settings → General → Currency** is a **per-user, presentation-only** preference. It converts what you *read* in the Costs tab — totals, the category chart, balances, the settle-up amounts — into a single currency, so a trip with dollars, yen and roubles in it still adds up to one number you understand.
+
+It never changes what is stored. Two people looking at the same trip can read it in different currencies and both see correct, consistent balances.
+
+It has two modes:
+
+| Value | Behaviour |
+|---|---|
+| **Trip currency** (the default) | Each trip is shown in **its own** currency. A Tokyo trip reads in yen, a Moscow trip in roubles. |
+| A specific currency (e.g. `USD`) | **Every** trip is converted into that currency for you, whatever its own currency is. |
+
+Leave it on **Trip currency** unless you specifically want everything in your home currency regardless of where you are going. An administrator can set an instance-wide default for new users (Admin → Default User Settings); choosing **Trip currency** yourself overrides it, because it is a deliberate choice rather than an absence of one.
+
+> Display conversion uses **live** rates, not the frozen ones — it is a view, and a view should reflect today. This is why a converted total can shift slightly day to day while the underlying balances stay rock steady.
+
+## How they fit together
+
+An expense flows through all three:
+
+```
+    100 USD                  ≈ 7 668 ₽                    ≈ 87 €
+  ┌───────────┐   frozen   ┌───────────────┐    live    ┌───────────────┐
+  │  expense  │ ─────────► │     trip      │ ─────────► │    display    │
+  │ currency  │    rate    │   currency    │    rate    │   currency    │
+  └───────────┘  (at entry)└───────────────┘  (at read) └───────────────┘
+     what you              what the trip is             what you read,
+     actually paid         settled in  ← balances       if you asked for
+                                          live here     a display currency
+```
+
+Balances are always netted in the **trip currency** and converted to your display currency **once, at the end** — never per-expense. That ordering is deliberate: netting in a moving display currency would let rounding drift shuffle a settled trip into phantom one-cent debts.
+
+## The public share link
+
+A public share page has no logged-in viewer, so it cannot use "your" display currency. It uses **the sharer's display currency, falling back to the trip's own currency** — i.e. a guest sees the trip the way the person who shared it sees it. If the sharer left their display currency on **Trip currency**, guests read the trip in the trip's currency.
+
+## Relationship with the Costs addon
+
+The **trip currency lives on the trip itself**, not in the Costs addon — it is set in the trip dialog and remains set even if Costs is disabled. Expense currencies, frozen rates and settle-up all belong to **Costs** (addon id `budget`), which an admin can toggle in [Admin-Addons](Admin-Addons). Turning Costs off hides the money features; it does not clear the trip's currency.
+
+Changing the trip currency requires `trip_edit`. Adding or editing expenses (and their currencies) requires `budget_edit`. See [Admin-Permissions](Admin-Permissions).
+
+## Troubleshooting
+
+**"My balances are huge / nonsense on a trip with a foreign expense."**
+Fixed in v3.4.0 (#1543). The settlement was reading the trip currency incorrectly and treating every trip as EUR, which inflated balances on any non-EUR trip that had a foreign-currency expense. Upgrade; no data was damaged and nothing needs fixing by hand.
+
+**"The totals move slightly from day to day."**
+Expected, if your display currency differs from the trip currency: the *display* conversion uses live rates. The underlying balances and debts do not move.
+
+**"An expense shows an odd converted value."**
+Its rate was frozen when it was entered, and the market has moved since. That is by design — see the note above.
+
+## See also
+
+- [Budget-Tracking](Budget-Tracking) — the Costs tab
+- [Creating-a-Trip](Creating-a-Trip) — where the trip currency is set
+- [Display-Settings](Display-Settings) — where the display currency is set
+- [Public-Share-Links](Public-Share-Links)
+- [Admin-Addons](Admin-Addons)

wiki/Dashboard-Widgets.md

@@ -2,8 +2,6 @@
 
 The My Trips dashboard includes two utility widgets: a currency converter and a timezone clock.
 
-<!-- TODO: screenshot: widget gallery showing currency converter and timezone clock -->
-
 ![Dashboard Widgets](assets/DashboardWidgets.png)
 
 ## Where they appear

wiki/Day-Plans-and-Notes.md

@@ -2,9 +2,7 @@
 
 The Day Plan sidebar lets you organize places into days, add free-form notes, and manage the order of your itinerary.
 
-<!-- TODO: screenshot: itinerary view with assigned places and day notes -->
-
-![Day Plan](assets/TripPlaner.png)
+![Day Plan](assets/TripPlanner.png)
 
 ## The Day Plan sidebar
 
@@ -79,6 +77,6 @@ At the top of the Day Plan sidebar:
 - **Expand / Collapse all** — toggles all day sections open or closed at once.
 - **Undo** — reverses the last drag, reorder, or assign action.
 
-Route calculation controls (optimize order, open in Google Maps) appear inside each expanded day section after the place list.
+Route controls (optimize order, open in Google Maps) appear inside each expanded day section after the place list.
 
 **See also:** [Places-and-Search](Places-and-Search) · [Map-Features](Map-Features) · [Route-Optimization](Route-Optimization) · [Weather-Forecasts](Weather-Forecasts) · [Reservations-and-Bookings](Reservations-and-Bookings)

wiki/Development-environment.md

@@ -13,7 +13,7 @@
 
 ## 1. Fork & Clone the Repository
 
-Go to the [TREK repository](https://github.com/mauriceboe/TREK) and click **Fork** to create your own copy.
+Go to the [TREK repository](https://github.com/liketrek/TREK) and click **Fork** to create your own copy.
 
 Then clone your fork locally:
 
@@ -30,7 +30,7 @@ cd TREK
 Add the original repository as `upstream` so you can pull in future updates:
 
 ```bash
-git remote add upstream git@github.com:mauriceboe/TREK.git
+git remote add upstream git@github.com:liketrek/TREK.git
 ```
 
 You should now have two remotes:
@@ -38,7 +38,7 @@ You should now have two remotes:
 | Remote     | URL                                          | Purpose                        |
 |------------|----------------------------------------------|--------------------------------|
 | `origin`   | `git@github.com:your-username/TREK.git`      | Your fork — push changes here  |
-| `upstream` | `git@github.com:mauriceboe/TREK.git`         | Main repo — pull updates from here |
+| `upstream` | `git@github.com:liketrek/TREK.git`         | Main repo — pull updates from here |
 
 ---
 
@@ -192,7 +192,7 @@ git push origin fix/my-changes
 git push origin dev
 ```
 
-Then open a Pull Request from your fork to `mauriceboe/TREK` targeting the `dev` branch. If your PR only modifies files under `wiki/`, it is exempt from branch enforcement and may target any branch.
+Then open a Pull Request from your fork to `liketrek/TREK` targeting the `dev` branch. If your PR only modifies files under `wiki/`, it is exempt from branch enforcement and may target any branch.
 
 ---
 

wiki/Display-Settings.md

@@ -1,20 +1,31 @@
-# Display Settings
+# General Settings
 
-The Display tab (Settings → Display) controls the visual appearance and locale preferences of the app. All changes save immediately to your account and persist across devices.
+The General tab (Settings → General) controls your locale preferences and a few map-related display options. All changes save immediately to your account and persist across devices.
 
-<!-- TODO: screenshot: appearance settings panel -->
+![General Settings](assets/UsrSettings.png)
 
-![Display Settings](assets/UsrSettings.png)
+## Where to find it
 
-## Color mode
+Open the user menu in the top navigation bar, select **Settings**, and stay on the **General** tab — it is the tab the page opens on.
 
-Choose between three options:
+The tab is split into two sections: **Language & region** (currency, language, temperature, distance, time format) and **Travel & map** (booking route labels, POI pills, blur booking codes).
+
+> Color mode (Light / Dark / Auto) is **not** here — it lives on the **Appearance** tab. See [Appearance-Settings](Appearance-Settings).
+
+## Currency
+
+Your **display currency** — the currency you want to *read* amounts in on the Costs tab (totals, the category chart, balances, settle-up). It is presentation only: it never changes what is stored, and two members of the same trip can read it in different currencies and both see correct balances.
 
 | Option | Behaviour |
 |--------|-----------|
-| Light | Always uses the light theme |
-| Dark | Always uses the dark theme |
-| Auto | Follows your operating system / browser preference |
+| **Trip currency** (default) | Each trip is shown in **its own** currency — a Tokyo trip in yen, a Moscow trip in roubles. |
+| A specific currency (e.g. `USD`) | **Every** trip is converted into that currency for you, whatever its own currency is. |
+
+165 currencies are available. Conversion uses live rates, so a converted total can shift slightly from day to day while the trip's actual balances stay fixed.
+
+> This is **not** the trip's currency, which is set on the trip itself and is the base its balances are calculated in. The distinction matters — see [Currencies](Currencies).
+
+An administrator can set the instance-wide default for new users in Admin → Default User Settings. Choosing **Trip currency** yourself overrides it.
 
 ## Language
 
@@ -29,6 +40,13 @@ Affects the weather widget on trip days.
 | °C Celsius | Metric |
 | °F Fahrenheit | Imperial |
 
+## Distance unit
+
+| Option | Display |
+|--------|---------|
+| km Metric | Kilometres |
+| mi Imperial | Miles |
+
 ## Time format
 
 Affects all time displays throughout the app.
@@ -38,13 +56,19 @@ Affects all time displays throughout the app.
 | 24h | 14:30 |
 | 12h | 2:30 PM |
 
-## Route calculation
-
-Toggles automatic route calculation between places on the trip map. Set to **On** or **Off**.
-
 ## Booking route labels
 
-Shows or hides labels on booking-related route segments on the map. Set to **On** or **Off**.
+Shows or hides station / airport names on the endpoint markers of booking routes on the map. When off, only the icon is shown. Set to **On** or **Off**.
+
+## Explore places on the map
+
+Shows a category pill on the trip map for finding nearby restaurants, hotels and more from OpenStreetMap. Set to **On** or **Off**.
+
+## Always show booking routes
+
+When **On**, every booking that has a route (flight, train, car leg, etc.) shows its route line on the map automatically, on every trip, without needing the per-booking toggle. Set to **On** or **Off** — off by default.
+
+This only sets the *default* for a trip you haven't touched before. If you've already used the per-booking toggle or the trip's "show all / hide all" button (in the day-plan toolbar) on a given trip, that choice is remembered for that trip and isn't overridden by changing this setting afterwards.
 
 ## Blur booking codes
 
@@ -52,5 +76,7 @@ When enabled, confirmation codes and reference numbers are blurred until you hov
 
 ## See also
 
+- [Currencies](Currencies)
 - [Languages](Languages)
+- [Appearance-Settings](Appearance-Settings)
 - [User-Settings](User-Settings)

wiki/Documents-and-Files.md

@@ -2,8 +2,6 @@
 
 Attach and manage documents, tickets, and other files for your trip.
 
-<!-- TODO: screenshot: file attachment list with filter tabs -->
-
 ![Files](assets/Files.png)
 
 ## Where to find it
@@ -14,6 +12,8 @@ Open the **Files** tab inside the trip planner, or navigate directly to `/trips/
 
 ## Uploading
 
+![Files & Documents page with the All / PDFs / Images / Documents filter tabs, a Trash button, and the empty drag-and-drop upload area listing the allowed file types and 50 MB limit](assets/Documents.png)
+
 Drag and drop files onto the upload area, click it to open the file picker, or paste an image directly into the Files panel.
 
 - **Maximum file size:** 50 MB per file.

wiki/Environment-Variables.md

@@ -28,6 +28,7 @@ Complete reference for all environment variables TREK reads.
 | `ALLOWED_ORIGINS`           | Comma-separated origins for CORS and email notification links                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | same-origin                     |
 | `ALLOW_INTERNAL_NETWORK`    | Allow outbound requests to private/RFC-1918 IPs. Set `true` if Immich or other integrated services are on your local network. Loopback (`127.x`) and link-local (`169.254.x`) addresses remain blocked regardless.                                                                                                                                                                                                                                                                                                                | `false`                         |
 | `APP_URL`                   | Public base URL (e.g. `https://trek.example.com`). Required when OIDC is enabled — must match the redirect URI registered with your IdP. Also used as the base URL for email notification links and subscribable calendar feed URLs (the `webcal://`/`https://` links the Subscribe dialog hands to Google/Apple/Outlook).                                                                                                                                                                                                          | —                               |
+| `TREK_WIKI_DIR`             | Where the in-app Help pages (`/help`) read their content from. TREK ships this wiki and serves it from disk, so the docs always match the version you are running. You should not need to set this — it is an escape hatch for unusual layouts. If the directory cannot be found, Help falls back to fetching the public GitHub wiki (which tracks the latest release and needs outbound network access).                                                                                                                            | the bundled `wiki/` directory   |
 
 ### `HOST` — Source and Proxmox installs only
 
@@ -184,7 +185,7 @@ For setup instructions, see [MCP-Overview](MCP-Overview).
 | Variable                   | Description                                                                                             | Default |
 |----------------------------|---------------------------------------------------------------------------------------------------------|---------|
 | `MCP_RATE_LIMIT`           | Max MCP API requests per user per minute                                                                 | `300`   |
-| `MCP_MAX_SESSION_PER_USER` | Max concurrent MCP sessions per user                                                                     | `20`    |
+| `MCP_MAX_SESSION_PER_USER` | Max concurrent MCP sessions per user. At the cap the user's least-recently-active session is closed to make room — requests are not rejected. | `20`    |
 | `MCP_SESSION_TTL`          | Session idle timeout in seconds (max 86400)                                                              | `3600`  |
 | `MCP_SSE_KEEPALIVE`        | SSE keep-alive ping interval in seconds — keeps the stream alive through reverse proxies. `0` disables the pings; an open stream still refreshes the session's idle timeout. | `25`    |
 
@@ -234,7 +235,7 @@ When left at the default, using the transit feature makes the TREK **server** se
 
 TREK can search [Unsplash](https://unsplash.com/) for **trip cover images** and **place images**. By default the server queries Unsplash's public web endpoint **without an API key**, so no configuration is needed on most installs.
 
-Some hosting environments — commonly VPS and datacenter IP ranges (and many Kubernetes clusters) — are **blocked or rate-limited** by that unauthenticated endpoint, which surfaces in the UI as **"Unsplash search unavailable"**. Configuring a free Unsplash Access Key switches the server to Unsplash's official, authenticated API (`api.unsplash.com`), which is not subject to that block. See [issue #1449](https://github.com/mauriceboe/TREK/issues/1449).
+Some hosting environments — commonly VPS and datacenter IP ranges (and many Kubernetes clusters) — are **blocked or rate-limited** by that unauthenticated endpoint, which surfaces in the UI as **"Unsplash search unavailable"**. Configuring a free Unsplash Access Key switches the server to Unsplash's official, authenticated API (`api.unsplash.com`), which is not subject to that block. See [issue #1449](https://github.com/liketrek/TREK/issues/1449).
 
 | Variable              | Description                                                                                                                                                                                                                                                                                                                                                                    | Default                       |
 |-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------|
@@ -293,7 +294,7 @@ The plugin system is **on by default**. The runtime and the Admin → Plugins pa
 | `TREK_PLUGINS_ENABLED`            | Master switch for the plugin system. Enabled unless set to `false` (also accepts `0`, `off`, `no`, case-insensitive). Turning it off is a kill switch — installed plugins stay on disk but nothing runs.               | enabled                                                                             |
 | `TREK_PLUGINS_DIR`                | Directory where installed plugin **code** is stored. Persist it as a volume if you use plugins.                                                                                                                       | `<data>/plugins`                                                                    |
 | `TREK_PLUGINS_DATA_DIR`           | Directory for each plugin's own **data** (its private SQLite file). Kept separate from the code tree; persist it as a volume too.                                                                                     | `<data>/plugins-data`                                                               |
-| `TREK_PLUGIN_REGISTRY_URL`        | Override the plugin registry index the *Discover* tab browses. Point it at your own fork or mirror of the registry.                                                                                                  | `https://raw.githubusercontent.com/mauriceboe/TREK-Plugins/main/dist/index.json` |
+| `TREK_PLUGIN_REGISTRY_URL`        | Override the plugin registry index the *Discover* tab browses. Point it at your own fork or mirror of the registry.                                                                                                  | `https://raw.githubusercontent.com/liketrek/TREK-Plugins/main/dist/index.json` |
 | `TREK_PLUGIN_MAX_RSS_MB`          | Per-plugin memory ceiling in MB. A plugin process that exceeds it is stopped.                                                                                                                                         | `300`                                                                               |
 | `TREK_PLUGIN_PERMISSIONS`         | Set to `off` to opt **out** of the Node.js OS-level permission sandbox for plugin child processes (not recommended). Any other value keeps the sandbox on.                                                            | `on`                                                                                |
 | `TREK_PLUGIN_ALLOW_PRIVATE_EGRESS`| Set to `on` to let a plugin's declared outbound hosts resolve to private/internal addresses (e.g. a service on your LAN). By default connections to private, loopback, link-local and metadata addresses are refused. | off (private egress blocked)                                                        |

wiki/Home.md

@@ -16,7 +16,7 @@ TREK is a self-hosted, real-time collaborative travel planner licensed under AGP
 
 ### Travel Management
 - **Reservations & Bookings** — track flights, accommodations, restaurants with confirmation numbers and file attachments
-- **Budget Tracking** — category-based expenses with pie chart, per-person/per-day splitting, multi-currency support
+- **Budget Tracking** — category-based expenses with pie chart, per-person/per-day splitting, multi-currency support (see [Currencies](Currencies))
 - **Packing Lists** — category-based checklists with user assignment, templates, and progress tracking
 - **Document Manager** — attach documents, tickets, and PDFs to trips, places, or reservations (up to 50 MB per file)
 - **PDF Export** — export complete trip plans as PDF with cover page, images, and notes

wiki/In-App-Help.md

@@ -0,0 +1,66 @@
+# In-App Help
+
+Read the whole TREK wiki from inside TREK, without leaving the app or opening GitHub.
+
+![In-App Help](assets/HelpInApp.png)
+
+## Where to find it
+
+Click your avatar in the top-right navbar and choose **Help**, or go to `/help` directly. Individual pages live at `/help/{slug}` — for example `/help/Packing-Lists`.
+
+The page is titled **Help & Docs**. You must be signed in to reach the route.
+
+## The docs ship with your install
+
+Since **v3.4.0** the wiki is bundled into the TREK image and served from disk (commit `6c87bf2f`). That means:
+
+- The help you read always matches the version you are running. A v3.4 install shows v3.4 docs, not whatever `main` says.
+- Help works with no outbound network access at all.
+- Screenshots and other images are served by TREK, not fetched from GitHub — your browser never talks to github.com for help content.
+
+### The GitHub fallback
+
+If the bundled `wiki/` directory cannot be found — an unusual layout, or an image built without it — TREK logs a warning and falls back to fetching the public GitHub wiki over the network instead, caching each page and image for an hour and serving a stale copy rather than failing outright. Help degrades instead of disappearing, but the content then tracks the latest release rather than your version.
+
+TREK probes for `_Sidebar.md` specifically, not just the directory, so a half-copied `wiki/` folder falls back rather than serving an empty table of contents.
+
+### `TREK_WIKI_DIR`
+
+The bundled directory is found automatically. `TREK_WIKI_DIR` overrides where TREK looks — an escape hatch for unusual layouts, not something a normal install needs to set. See [Environment-Variables](Environment-Variables).
+
+## The sidebar
+
+The left sidebar mirrors this wiki's own table of contents, parsed straight out of `_Sidebar.md`: the same sections, in the same order, with the same page titles. On screens narrower than desktop the sidebar collapses behind a **Contents** button that opens it as a drawer.
+
+The page you are reading is highlighted with a chevron.
+
+## Search
+
+The **Search docs…** box at the top of the sidebar filters the navigation as you type. It matches **page titles only** — it does not search inside page text. Sections with no matching page disappear; when nothing matches you get **No matching pages.**
+
+To search page contents, use the wiki on GitHub or your browser's in-page find.
+
+## Rendering
+
+Pages render with TREK's own styling: headings, tables, code blocks, blockquotes, and images. A few things are handled specially so the same Markdown works both here and on GitHub:
+
+- Wiki links in either GitHub spelling — `[[Title|Slug]]` and the bare relative `[Currencies](Currencies)` — become in-app links that navigate without a page reload.
+- Relative image paths are rewritten to TREK's own asset endpoint.
+- Heading anchors use GitHub's slug scheme, so a `](#some-heading)` link inside a page lands in the right place.
+- HTML comments (such as `<!-- TODO: screenshot -->` placeholders) are stripped rather than shown.
+
+External links open in a new tab.
+
+If a page cannot be loaded you get **Couldn't load this page** — *The help content is fetched from the TREK wiki. Check your connection and try again.*
+
+## Permissions
+
+No permission gates the help browser; any signed-in user sees the same pages. The underlying `/api/help` endpoints are unauthenticated, because the content is public documentation — that is also what lets image tags load without sending credentials.
+
+## See also
+
+- [FAQ](FAQ)
+- [Troubleshooting](Troubleshooting)
+- [Environment-Variables](Environment-Variables)
+- [Updating](Updating)
+- [Contributing](Contributing)

wiki/Install-Docker-Compose.md

@@ -4,7 +4,7 @@ Production-ready setup using Docker Compose with security hardening enabled.
 
 ## Compose File
 
-See https://github.com/mauriceboe/TREK/blob/main/docker-compose.yml
+See https://github.com/liketrek/TREK/blob/main/docker-compose.yml
 
 ## Security Hardening Explained
 
@@ -64,17 +64,17 @@ Uncomment and fill in the OIDC, initial setup, or MCP variables as needed. For a
 
 Three tag strategies are available:
 
-| Tag | Example | Behavior |
-|---|---|---|
-| `latest` | `mauriceboe/trek:latest` | Always the newest release across all major versions |
-| Major version | `mauriceboe/trek:3` | Latest release pinned to that major version |
-| Full version | `mauriceboe/trek:3.0.15` | Exact release; never changes |
+| Tag | Example                  | Behavior |
+|---|--------------------------|---|
+| `latest` | `mauriceboe/TREK:latest` | Always the newest release across all major versions |
+| Major version | `mauriceboe/TREK:3`        | Latest release pinned to that major version |
+| Full version | `mauriceboe/TREK:3.4.0`   | Exact release; never changes |
 
 The compose file above uses `latest`. To pin, change the `image:` line:
 
 ```yaml
-image: mauriceboe/trek:3        # track major version 3
-image: mauriceboe/trek:3.0.15   # pin to exact release
+image: mauriceboe/TREK:3        # track major version 3
+image: mauriceboe/TREK:3.4.0   # pin to exact release
 ```
 
 ## Start TREK

wiki/Install-Docker.md

@@ -12,7 +12,7 @@ docker run -d \
   -v ./uploads:/app/uploads \
   -e ENCRYPTION_KEY=<your-32-byte-hex-key> \
   --restart unless-stopped \
-  mauriceboe/trek:latest
+  mauriceboe/TREK:latest
 ```
 
 `ENCRYPTION_KEY` is strongly recommended but not strictly required. If omitted, a key is auto-generated on first start and persisted to `data/.encryption_key`. Setting it explicitly means you can recreate the container from scratch (e.g. on a new host) without losing access to stored encrypted data (API keys, SMTP credentials, OIDC secrets, MFA secrets).
@@ -38,11 +38,11 @@ See [Environment-Variables](Environment-Variables) for the full list.
 
 | Tag | Example | Behavior |
 |---|---|---|
-| `latest` | `mauriceboe/trek:latest` | Always the newest release across all major versions |
-| Major version | `mauriceboe/trek:3` | Latest release pinned to that major version |
-| Full version | `mauriceboe/trek:3.0.15` | Exact release; never changes |
+| `latest` | `mauriceboe/TREK:latest` | Always the newest release across all major versions |
+| Major version | `mauriceboe/TREK:3` | Latest release pinned to that major version |
+| Full version | `mauriceboe/TREK:3.4.0` | Exact release; never changes |
 
-Replace `mauriceboe/trek:latest` in the run command with your chosen tag to pin to a major version or exact release.
+Replace `mauriceboe/TREK:latest` in the run command with your chosen tag to pin to a major version or exact release.
 
 ## Volume Reference
 
@@ -65,7 +65,7 @@ docker run -d \
   -v trek_uploads:/app/uploads \
   -e ENCRYPTION_KEY=<your-32-byte-hex-key> \
   --restart unless-stopped \
-  mauriceboe/trek:latest
+  mauriceboe/TREK:latest
 ```
 
 Docker creates `trek_data` and `trek_uploads` automatically on first run. Named volumes are easier to manage with `docker volume` commands and work better in some NAS or container-management environments.

wiki/Install-Helm.md

@@ -72,7 +72,7 @@ helm install trek trek/trek \
 
 ```yaml
 image:
-  repository: mauriceboe/trek
+  repository: liketrek/TREK
   # tag: latest        # defaults to the chart's appVersion
   pullPolicy: IfNotPresent
 
@@ -97,6 +97,7 @@ env:
   PORT: 3000
   # TZ: "Europe/Berlin"          # timezone for logs, reminders, cron jobs
   # LOG_LEVEL: "info"            # "info" = concise, "debug" = verbose
+  # TREK_WIKI_DIR: "/app/wiki"   # where /help reads its docs from; leave unset (the image ships them)
   # DEFAULT_LANGUAGE: "en"       # fallback language on login page; supported: de, en, es, fr, hu, nl, br, cs, pl, ru, zh, zh-TW, it, tr, ar, id, ja, ko, uk, gr
   # ALLOWED_ORIGINS: "https://trek.example.com"
   # APP_URL: "https://trek.example.com"
@@ -187,7 +188,7 @@ helm upgrade trek trek/trek
 
 ## Full Values Reference
 
-See the [`charts/README.md`](https://github.com/mauriceboe/TREK/blob/main/charts/README.md) for all available values.
+See the [`charts/README.md`](https://github.com/liketrek/TREK/blob/main/charts/README.md) for all available values.
 
 ## Next Steps
 

wiki/Install-Portainer.md

@@ -12,7 +12,7 @@ Portainer must be installed and connected to your Docker environment. Use **Stac
 
 1. In Portainer, go to **Stacks → Add stack**.
 2. Give the stack a name (e.g. `trek`).
-3. Select **Web editor** and paste the compose file from [docker-compose.yml](https://github.com/mauriceboe/TREK/blob/main/docker-compose.yml).
+3. Select **Web editor** and paste the compose file from [docker-compose.yml](https://github.com/liketrek/TREK/blob/main/docker-compose.yml).
 
 ![Web editor with the docker-compose content pasted in](assets/portainer-stack-save.png)
 
@@ -26,7 +26,7 @@ Portainer must be installed and connected to your Docker environment. Use **Stac
 
 ## Compose Content
 
-See https://github.com/mauriceboe/TREK/blob/main/docker-compose.yml
+See https://github.com/liketrek/TREK/blob/main/docker-compose.yml
 
 Set at minimum `ENCRYPTION_KEY`, `TZ`, and `APP_URL` in the **Environment variables** section of the stack editor. Generate an encryption key with:
 
@@ -40,11 +40,11 @@ Three tag strategies are available:
 
 | Tag | Example | Behavior |
 |---|---|---|
-| `latest` | `mauriceboe/trek:latest` | Always the newest release across all major versions |
-| Major version | `mauriceboe/trek:3` | Latest release pinned to that major version |
-| Full version | `mauriceboe/trek:3.0.15` | Exact release; never changes |
+| `latest` | `mauriceboe/TREK:latest` | Always the newest release across all major versions |
+| Major version | `mauriceboe/TREK:3` | Latest release pinned to that major version |
+| Full version | `mauriceboe/TREK:3.4.0` | Exact release; never changes |
 
-Use `latest` or a major-version tag (e.g. `3`) if you want automatic updates on redeploy. Use a full version tag (e.g. `3.0.15`) if you want explicit control over which release runs.
+Use `latest` or a major-version tag (e.g. `3`) if you want automatic updates on redeploy. Use a full version tag (e.g. `3.4.0`) if you want explicit control over which release runs.
 
 ## Updating
 
@@ -54,7 +54,7 @@ How you update depends on the tag you chose:
 
 ![Re-pull image and redeploy switch ticked, with arrows pointing to the switch and the Update button](assets/portainer-force-pull.png)
 
-**Pinned full-version tag** — Edit the stack, change the tag in the `image:` line (e.g. `3.0.15` → `3.0.16`), then click **Update the stack**. No need to toggle the re-pull switch — a tag change forces a fresh pull.
+**Pinned full-version tag** — Edit the stack, change the tag in the `image:` line (e.g. `3.4.0` → `3.4.1`), then click **Update the stack**. No need to toggle the re-pull switch — a tag change forces a fresh pull.
 
 ![Edit stack page with an arrow pointing to the image tag in the compose editor](assets/portainer-update-version.png)
 

wiki/Install-Unraid.md

@@ -17,7 +17,7 @@ Docker must be enabled in Unraid (**Settings → Docker → Enable Docker: Yes**
 If the app does not appear, you can install directly from the template URL. In **Docker → Add Container**, paste the template URL:
 
 ```
-https://raw.githubusercontent.com/mauriceboe/TREK/main/unraid-template.xml
+https://raw.githubusercontent.com/liketrek/TREK/main/unraid-template.xml
 ```
 
 ## Template Fields
@@ -45,7 +45,7 @@ The Unraid template exposes the following fields in the container UI:
 
 ### Advanced Variables
 
-Additional variables (`PORT`, `NODE_ENV`, `LOG_LEVEL`, `DEFAULT_LANGUAGE`, `FORCE_HTTPS`, `TRUST_PROXY`, `COOKIE_SECURE`, `ALLOW_INTERNAL_NETWORK`, `SESSION_DURATION`, `SESSION_DURATION_REMEMBER`, all OIDC variables, `MCP_RATE_LIMIT`, `MCP_MAX_SESSION_PER_USER`, `DEMO_MODE`) are available under **Advanced View** in the template editor.
+Additional variables (`PORT`, `NODE_ENV`, `LOG_LEVEL`, `TREK_WIKI_DIR`, `DEFAULT_LANGUAGE`, `FORCE_HTTPS`, `TRUST_PROXY`, `COOKIE_SECURE`, `ALLOW_INTERNAL_NETWORK`, `SESSION_DURATION`, `SESSION_DURATION_REMEMBER`, all OIDC variables, `MCP_RATE_LIMIT`, `MCP_MAX_SESSION_PER_USER`, `DEMO_MODE`) are available under **Advanced View** in the template editor.
 
 ## Setting the Encryption Key
 

wiki/Invite-Links.md

@@ -2,8 +2,6 @@
 
 Invite new users to register on your TREK instance, even when open registration is disabled. Invite links work by embedding a short-lived token in the registration URL.
 
-<!-- TODO: screenshot: invite link management form -->
-
 ![Invite Links](assets/UsersAndInvites.png)
 
 ## What invite links do

wiki/Journey-Journal.md

@@ -4,8 +4,6 @@ Journey is a photo-first travel journal. Each journey is linked to one or more o
 
 > **Admin:** enable Journey in [Admin-Addons](Admin-Addons).
 
-<!-- TODO: screenshot: journal entries view with photos and mood indicators -->
-
 ![Journey screenshot](assets/Journey.png)
 
 ## What Journey is
@@ -51,6 +49,8 @@ On mobile, entries are displayed in a horizontal scrolling timeline of card thum
 
 The journey detail page includes a map on the right (desktop) or an integrated map-timeline (mobile) showing all entry locations alongside the places from linked trips.
 
+![Journey detail page for "Autumn in Japan" with its cover header and day/place/entry/photo counts, the day-by-day timeline with Add Entry actions on the left, and the entry map on the right](assets/JourneyDetail.png)
+
 ## Plugin entry rows
 
 Installed plugins can add extra rows to a journal entry card via the `journalEntryProvider` hook. A plugin returns rows (`label`, optional `value`, optional `url`) and TREK renders them natively under the entry — no iframe. Rows are additive and fail-safe: they require the Journey addon, the entry's journey is access-checked the same way as reading it, only http/https/mailto links are allowed, and a provider that errors or is slow is simply skipped.

wiki/Languages.md

@@ -35,7 +35,7 @@ Arabic (`ar`) uses a right-to-left layout. All other languages use left-to-right
 
 TREK resolves the display language in this order:
 
-1. **User preference** — the language saved to your account (set in Settings → Display).
+1. **User preference** — the language saved to your account (set in Settings → General).
 2. **Browser language** — `navigator.languages` (and `navigator.language`) reported by your browser.
 3. **Server default** — the `DEFAULT_LANGUAGE` environment variable set by the admin.
 4. **Fallback** — English (`en`).
@@ -43,7 +43,7 @@ TREK resolves the display language in this order:
 ## Where the language picker appears
 
 - **Login / Register page** — before you are signed in.
-- **Settings → Display** — after you are signed in. See [Display-Settings](Display-Settings).
+- **Settings → General** — after you are signed in. See [Display-Settings](Display-Settings).
 - **Public share pages** — trip share links.
 - **Public journey pages** — public-facing journey views.
 

wiki/Login-and-Registration.md

@@ -1,6 +1,6 @@
 # Login and Registration
 
-<!-- TODO: screenshot: login form with email and password fields -->
+![TREK login page: the product splash panel on the left and the Sign In card on the right with email and password fields, a Remember me switch, a Forgot password? link and a Register link](assets/Registration.png)
 
 ## Signing in
 

wiki/MCP-Overview.md

@@ -44,6 +44,10 @@ See [MCP-Setup](MCP-Setup) for step-by-step instructions for each method.
 
 Rate limits are tracked per user–client pair, so each OAuth client has its own independent window. Sessions expire after 1 hour of inactivity by default (`MCP_SESSION_TTL`); an open SSE stream counts as activity. The server also sends an SSE comment ping every 25 seconds so reverse proxies with idle timeouts (e.g. nginx's default 60s) don't kill the stream between tool calls.
 
+Reaching `MCP_MAX_SESSION_PER_USER` does not refuse the request: the server closes that user's least-recently-active session to make room for the new one. This keeps a client that cannot hold onto its session id from locking itself out of the server.
+
+> **Reverse proxy:** MCP sessions depend on the `Mcp-Session-Id` header travelling in both directions. A proxy that strips it makes every tool call open a new session instead of reusing one. Nginx and Caddy pass it through by default — see [Reverse-Proxy](Reverse-Proxy) if you have customised header handling.
+
 > **Kubernetes / multi-replica:** MCP sessions are held in memory per instance. With more than one replica you need sticky sessions (or a single replica), or clients will intermittently see `404 Session not found`.
 
 ## Endpoint

wiki/MCP-Scopes.md

@@ -32,7 +32,7 @@ TREK defines 27 scopes across 13 groups.
 | | `notifications:write` | Mark notifications as read or unread (individually or all at once) |
 | **Vacation** | `vacay:read` | Read vacation planning data, entries, and stats |
 | | `vacay:write` | Create and manage vacation entries, holidays, and team plans |
-| **Geo** | `geo:read` | Search locations, resolve map URLs, and reverse-geocode coordinates |
+| **Geo** | `geo:read` | Search locations and public transit routes, resolve map URLs, and reverse-geocode coordinates |
 | **Weather** | `weather:read` | Fetch weather forecasts for trip locations and dates |
 | **Journey** | `journey:read` | Read journeys, entries, and contributor list |
 | | `journey:write` | Create, update, and delete journeys and their entries |

wiki/MCP-Setup.md

@@ -2,8 +2,6 @@
 
 This page explains how to connect an AI assistant to your TREK instance. TREK supports three authentication methods: OAuth 2.1 with browser consent (recommended for interactive clients), machine clients with no browser login (recommended for AI agents and scripts), and static API tokens (deprecated).
 
-<!-- TODO: screenshot: OAuth client registration form -->
-
 ![MCP Setup](assets/MCPConfig.png)
 
 > **Cloudflare users:** If your TREK instance is proxied through Cloudflare, Bot Fight Mode and Super Bot Fight Mode will block MCP requests from ChatGPT. Claude.ai is not affected. See [Troubleshooting → MCP requests blocked by Cloudflare WAF](#mcp-requests-blocked-by-cloudflare-waf-bot-fight-mode) for the fix.
@@ -154,3 +152,5 @@ Each user can create up to **10 static tokens**.
 - [MCP-Scopes](MCP-Scopes)
 - [Admin-MCP-Tokens](Admin-MCP-Tokens)
 - [Environment-Variables](Environment-Variables)
+- [Reverse-Proxy](Reverse-Proxy) — the proxy must pass `Mcp-Session-Id` through, or every tool call opens a new session
+- [Troubleshooting](Troubleshooting) — OAuth flow not starting, sessions piling up, Cloudflare WAF blocks

wiki/MCP-Tools-and-Resources.md

@@ -106,6 +106,16 @@ Requires `reservations:write` scope.
 | `update_transport` | Update an existing transport booking. Pass `endpoints[]` to replace all stops. |
 | `delete_transport` | Delete a transport booking from a trip. |
 
+### Automated public transit
+
+Transit search is powered by Transitous and uses the existing `geo:read` and `reservations:write` scopes.
+
+| Tool | Scope required | Description |
+|---|---|---|
+| `search_transit_stops` | `geo:read` | Search real public-transit stops and stations, optionally biased around coordinates. |
+| `search_transit_routes` | `geo:read` | Search scheduled routes between two coordinates with time, mode, and transfer filters. Also returns `dropped`, the number of provider itineraries that failed validation and are absent from the results. |
+| `create_transit_journey` | `reservations:write` | Save a selected route as a first-class automated transit journey on a trip day. |
+
 ### Reservations
 
 Requires `reservations:read` or `reservations:write` scope.

wiki/Map-Features.md

@@ -2,8 +2,6 @@
 
 The trip planner map shows your places, route lines, transport overlays, and your current location in real time.
 
-<!-- TODO: screenshot: trip map with place markers and route lines -->
-
 ![Trip Planner Map](assets/TripPlannerWithPlane.png)
 
 ## Map renderer
@@ -36,21 +34,24 @@ When you have a day selected, a dark dashed line connects consecutive places in
 
 At zoom level 12 or higher, small pill-shaped labels appear between consecutive places and show the estimated **walking time** and **driving time** for each segment. Below zoom 12 they are hidden to keep the map clean.
 
-> **Requires:** Settings → Display → **Route calculation** must be ON. When this setting is OFF, TREK never queries the routing service, so no pills are calculated or drawn at any zoom level.
-
 ## Reservation and transport overlay
 
-Flights, trains, cars, and cruises can be drawn as overlays between their endpoint places. Overlays are **off by default** — activate each reservation individually by clicking the small **Route** icon next to the booking row in the day sidebar. The selection is remembered per trip in your browser. Click the icon again to hide it.
+Flights, trains, cars, and cruises can be drawn as overlays between their endpoint places. Overlays are **off by default** — activate each reservation individually by clicking the small **Route** icon next to the booking row in the day sidebar, or use one of the bulk options below. The selection is remembered per trip in your browser. Click the icon again to hide it.
 
 - **Flights and cruises** — geodesic great-circle arcs
 - **Cars, buses, taxis and bicycles** — real routed lines that follow actual roads, fetched on demand from a public OSRM router (driving for car/bus/taxi, cycling for bicycle). A straight line is shown while the route loads and kept if routing fails or the trip is very long (~2000 km+)
 - **Trains** — a straight line between the endpoints; a multi-leg train draws its whole station chain (from → stop → to)
 - **Antimeridian crossings** — routes that cross the date line now draw as one continuous arc instead of splitting into disconnected segments at the map edges
 - **Endpoint markers** — pill-shaped labels with the transport icon and the endpoint code (e.g. IATA airport code) or location name
-- **Flight stats** — a floating label on the arc shows departure code → arrival code and, when times are available, the duration and great-circle distance. Stats labels are only rendered for flights and require Settings → Display → **Route calculation** to be ON.
+- **Flight stats** — a floating label on the arc shows departure code → arrival code and, when times are available, the duration and great-circle distance. Stats labels are only rendered for flights.
 - **Confirmed reservations** — solid line; **Pending** — dashed line
 
-> **Admin:** Whether endpoint text labels appear on the endpoint markers is controlled by the **Booking route labels** setting in Settings → Display (`map_booking_labels`).
+**Bulk options**, alongside the per-booking toggle:
+
+- **Show all / hide all** — a route icon button in the day-plan toolbar (next to Undo/Reorder) flips every routable booking on the trip on or off at once, without affecting bookings you've toggled individually.
+- **Always show booking routes** (Settings → General → Travel & map) — an account-wide default that shows every booking's route automatically on any trip you haven't touched before. It sets the *default* only — a trip where you've already used the per-booking toggle or the bulk button keeps its own choice even if you change this setting afterwards.
+
+> **Admin:** Whether endpoint text labels appear on the endpoint markers is controlled by the **Booking route labels** setting in Settings → General (`map_booking_labels`).
 
 ## Plugin map markers
 

wiki/Map-Settings.md

@@ -1,21 +1,26 @@
 # Map Settings
 
-The Map tab (Settings → Map) controls which map engine and tile source TREK uses in the Trip Planner and Journey maps. Changes take effect after clicking **Save map settings**.
+The Map tab controls which map engine and tile source TREK uses in the Trip Planner and Journey maps.
 
 > **Note:** The Atlas view always uses Leaflet regardless of this setting.
 
-<!-- TODO: screenshot: map settings panel with provider selection -->
-
 ![Map Settings](assets/UsrSettingsMap.png)
 
+## Where to find it
+
+Open the user menu in the top navigation bar, select **Settings**, then the **Map** tab. Unlike the General tab, changes here are not saved as you make them — click **Save Map** when you are done.
+
 ## Map provider
 
 Choose the rendering engine:
 
 | Provider | Description |
 |----------|-------------|
-| **Leaflet** | Classic 2D renderer. Works with any raster tile URL. |
-| **Mapbox GL** *(Experimental)* | Vector tiles with 3D buildings and terrain support. Requires a Mapbox access token. |
+| **Leaflet** | Classic 2D renderer. Works with any raster tile URL. No token. |
+| **Mapbox GL** *(Experimental)* | Vector tiles with 3D buildings and terrain support. **Requires a Mapbox access token.** |
+| **MapLibre GL** | Vector tiles from **OpenFreeMap**. **No access token required** — this is the reason to pick it over Mapbox GL. |
+
+Each GL provider stores its style in its own slot (`mapbox_style` for Mapbox GL, `maplibre_style` for MapLibre GL), so switching providers never clobbers the other one's style.
 
 ## Leaflet — tile source
 
@@ -73,9 +78,35 @@ Enables pitch and building extrusions on all styles. Terrain elevation (DEM-base
 
 Enables antialiasing and globe projection for sharper edges. May impact performance on lower-end devices.
 
-## Default map center
+## MapLibre GL — style
 
-Set the default latitude, longitude, and zoom level for the map. You can also click on the map preview to move the center pin.
+MapLibre GL renders OpenFreeMap vector tiles and needs **no token at all**, so there is no token field on this provider — just a style.
+
+**Built-in style presets:**
+
+| Style | URL |
+|-------|-----|
+| OpenFreeMap Liberty *(default)* | `https://tiles.openfreemap.org/styles/liberty` |
+| OpenFreeMap Bright | `https://tiles.openfreemap.org/styles/bright` |
+| OpenFreeMap Positron | `https://tiles.openfreemap.org/styles/positron` |
+
+You can also type any `https://tiles.openfreemap.org/…` style URL. A style that is not an OpenFreeMap URL is rejected and replaced with Liberty when you save.
+
+The **3D Buildings & Terrain** and **High Quality Mode** toggles are Mapbox-only and are not shown for MapLibre GL.
+
+## Where a map opens
+
+There is **no** default map center or zoom setting — it was removed in v3.4.0. Instead, every map works out its own opening camera from the places it is about to draw, so a trip in Japan opens on Japan instead of starting on the world view and then flying across the planet.
+
+For each map, TREK takes the coordinates it is given and computes the center and zoom that frame them all:
+
+- **Several places** — the camera fits their bounding box. The zoom is capped (16 on Leaflet, 15 on the GL renderers) so a tight cluster does not open absurdly far in, and the center is taken in projected (Mercator) space rather than as an average of the latitudes, so the northernmost place does not fall out of frame.
+- **A single place** (or several stacked on the same spot) — there is no extent to fit, so it opens at city level: zoom 12 on Leaflet, 11 on the GL renderers.
+- **Places spanning the date line** — MapLibre GL and Mapbox GL wrap the world, so a trip covering Fiji and Samoa is framed as the 10°-wide arc it really is. Leaflet does not wrap, so it takes the plain west-to-east span instead.
+- **Side panels** — chrome overlaying the map shifts the center, so the places stay inside the part of the map you can actually see.
+- **No usable coordinates** — a brand-new trip with nothing placed yet has nothing to frame, so the map falls back to a world view (center `0, 0` at zoom 2).
+
+The small map preview on this settings page is the one exception: it stays on a fixed city (Paris, zoom 16) so you can judge label density, 3D buildings and satellite texture. It is not a setting and no real map opens there.
 
 ## See also
 

wiki/My-Trips-Dashboard.md

@@ -2,8 +2,6 @@
 
 The dashboard at `/dashboard` is your home base — it lists all your trips, lets you create new ones, and surfaces quick-access widgets.
 
-<!-- TODO: screenshot: trips grid with spotlight card -->
-
 ![My Trips Dashboard](assets/DashboardWidgets.png)
 
 ## View Modes

wiki/Notifications.md

@@ -2,8 +2,6 @@
 
 The Notifications tab (Settings → Notifications) lets you choose which events notify you and through which channels. Each toggle saves immediately.
 
-<!-- TODO: screenshot: notifications panel or bell dropdown -->
-
 ![Notifications tab](assets/NotifSettings.png)
 
 ## Notification channels
@@ -89,6 +87,8 @@ Enter your ntfy **topic** and optionally a custom **server URL** (defaults to th
 
 ## In-app notification center
 
+![Full-page Notifications inbox with All and Unread filter pills and an empty "No notifications — you're all caught up!" state](assets/NotificationsInbox.png)
+
 The bell icon in the navigation bar shows your unread notification count. Click it to open the notification panel where you can:
 
 - Mark individual items read or unread.

wiki/Offline-Mode-and-PWA.md

@@ -50,7 +50,7 @@ On login, after each trip-list refresh, and on WebSocket reconnect, TREK runs a
 
 The **Offline** tab gives you control over what is stored on this device and lets you go offline deliberately.
 
-<!-- TODO: screenshot: Offline tab -->
+![Settings → Offline tab with the Force offline mode switch, the Download for offline use and Re-sync now buttons, per-trip offline storage toggles and the offline cache counters](assets/SettingsOffline.png)
 
 ### Offline mode
 

wiki/PDF-Export.md

@@ -2,8 +2,6 @@
 
 TREK can generate two kinds of PDFs from your trip data: a structured **Trip Plan PDF** and a photo-book-style **Journey Book PDF**. Both render as HTML in a sandboxed iframe and open the browser's native print/save dialog — no server-side processing is involved.
 
-<!-- TODO: screenshot: export options dialog or PDF preview modal -->
-
 ![PDF Export](assets/PDFTrip.png)
 
 ---
@@ -23,7 +21,7 @@ Open the Day Plan sidebar in the trip planner. Click the **PDF** button in the t
   - **Days** — total number of days in the trip
   - **Places** — total places in your trip's place list
   - **Planned** — number of unique places assigned to at least one day
-  - **Estimated cost** — sum of all assigned place prices in EUR (hidden if zero)
+  - **Estimated cost** — sum of all assigned place prices, shown in the trip's currency (hidden if zero)
 
 ### Per-day pages
 

wiki/Packing-Lists.md

@@ -2,8 +2,6 @@
 
 Create categorized packing checklists with member assignments and optional bag tracking.
 
-<!-- TODO: screenshot: packing list with checked items and categories -->
-
 ![Packing Lists](assets/PackingList.png)
 
 ## Where to find it

wiki/Packing-Templates.md

@@ -2,8 +2,6 @@
 
 Reuse packing lists across trips using pre-built templates.
 
-<!-- TODO: screenshot: packing template list with categories and items -->
-
 ![Packing Templates](assets/PackingTemplate.png)
 
 ## Applying a template

wiki/Passkeys.md

@@ -0,0 +1,84 @@
+# Passkeys
+
+Sign in with a fingerprint, face, PIN, or hardware security key instead of typing a password.
+
+## Where to find it
+
+Open **Settings** and select the **Account** tab. The **Passkeys** section sits below the two-factor authentication block.
+
+> **Admin:** Passkey login is off by default. Turn on **Enable passkey login** in **Admin → Settings**, under the **Passkey login** card.
+
+The section is hidden entirely when the feature is off and you have no passkeys enrolled. If you already have passkeys, the list stays visible even after an admin turns the feature off, so you can always clean them up.
+
+## Enrolling a passkey
+
+1. Click **Add a passkey**.
+2. Enter your **current password** — TREK asks for it so a hijacked session cannot silently plant a passkey.
+3. Optionally give the passkey a name (the placeholder suggests something like `iPhone`). Leave it blank and TREK names it **Passkey (synced)** or **Passkey** depending on the authenticator.
+4. Click **Add a passkey** again and follow your device prompt (Touch ID, Windows Hello, Android screen lock, a YubiKey, and so on).
+
+Every passkey is registered with *user verification required*, so a biometric or PIN check always happens — a bare "tap the key" gesture is not enough. The same authenticator cannot be enrolled twice on one account, and enrolment expires if you take longer than five minutes.
+
+If you dismiss the browser dialog you get **Passkey setup cancelled** and nothing is stored.
+
+## Signing in with a passkey
+
+On the login page, a **Sign in with a passkey** button appears below the password form (separated by an **or** divider). Click it, pick your passkey in the browser prompt, and you are signed straight in — no username, no password, no second step.
+
+The button only shows when all of these hold:
+
+- An admin enabled passkey login.
+- A usable WebAuthn domain resolves for the deployment (see [Setup requirements](#setup-requirements)).
+- The instance is not in OIDC-only mode.
+- You are on the sign-in form (not registration, the 2FA step, or a forced password change).
+
+TREK never reveals which accounts have passkeys: the login ceremony uses discoverable credentials, every failure returns the same generic *Authentication failed*, and responses are padded to a fixed minimum latency so timing gives nothing away.
+
+## Managing your passkeys
+
+Each entry in the list shows its name, a **Synced** or **This device** badge, the date it was **Added**, and either **Last used** with a date or **Never used**.
+
+- **Rename** (pencil icon) — edit the name inline; press Enter to save, Escape to cancel. Names are capped at 60 characters.
+- **Delete** (trash icon) — confirms with *Remove this passkey? Confirm with your password.* and requires your current password.
+
+Removing every passkey can never lock you out — your password always remains as a fallback.
+
+> **Admin:** In **Admin → Users**, editing a user exposes a **Reset passkeys** action that removes all of that user's passkeys at once (for a lost device). The user can still sign in with their password.
+
+## Passkeys and two-factor authentication
+
+A user-verified passkey is already two factors — possession of the device plus a biometric or PIN — so it mints a session directly and does **not** prompt for a TOTP code afterwards.
+
+The same reasoning applies to the admin **Require two-factor authentication (2FA)** policy: owning at least one passkey satisfies that policy exactly like an enabled TOTP authenticator does. A brand-new user under the policy can enrol a passkey instead of setting up an authenticator app; the enrolment endpoints stay reachable while the rest of the API is blocked, so nobody gets stuck. See [Two-Factor-Authentication](Two-Factor-Authentication).
+
+## Setup requirements
+
+Passkeys are bound to a domain (the *Relying Party ID*). If no usable domain resolves, the feature stays hidden even with the toggle on, and the admin card shows a warning.
+
+> **Admin:** The **Passkey login** card also has **Relying Party ID (domain)** and **Allowed origins** fields. Leave them empty to derive both from `APP_URL`. Changing the RP ID later invalidates existing passkeys.
+
+Both values can be pinned with environment variables, which take priority over the Admin panel fields:
+
+- `WEBAUTHN_RP_ID` — the registrable domain, e.g. `trek.example.com`. Bare IP addresses are rejected.
+- `WEBAUTHN_ORIGINS` — comma-separated allowed origins, e.g. `https://trek.example.com`.
+
+See [Environment-Variables](Environment-Variables) for the full description of both.
+
+## Audit and rate limits
+
+Enrolment, deletion, and passkey logins are recorded in the [Audit-Log](Audit-Log) (`user.passkey_register`, `user.passkey_delete`, and `user.login` with `method: passkey`). If an authenticator ever replays a stale signature counter, TREK rejects that attempt and logs `user.passkey_clone_suspected` without disabling the credential.
+
+Login and enrolment attempts are rate limited per IP over a 15-minute window.
+
+## Permissions
+
+No TREK permission gates passkeys — any signed-in user can enrol and manage their own. Only the instance-wide toggle and the WebAuthn domain configuration are admin-controlled, and the **Reset passkeys** action is admin-only.
+
+## See also
+
+- [Login-and-Registration](Login-and-Registration)
+- [Two-Factor-Authentication](Two-Factor-Authentication)
+- [User-Settings](User-Settings)
+- [Environment-Variables](Environment-Variables)
+- [Security-Hardening](Security-Hardening)
+- [Audit-Log](Audit-Log)

wiki/Password-Reset.md

@@ -4,6 +4,8 @@
 
 TREK supports email-based self-service password reset. On the login page, click the **"Forgot password?"** link to go to `/forgot-password`. Enter your email address and submit — if the address matches a local account, a reset link is sent to that inbox. The page always shows the same confirmation message regardless of whether the email was found, to prevent account enumeration.
 
+![Reset your password card with a Back to sign in link, an email field and a Send reset link button, plus a warning that SMTP is unconfigured so the reset link is written to the server console](assets/PasswordReset.png)
+
 > **No SMTP configured?** When the server has no SMTP credentials set up, the reset link is not emailed. Instead, it is printed to the **server console** inside a clearly-fenced block so a self-hoster can copy and relay it manually. The forgot-password page also shows a visible hint that SMTP is unconfigured.
 
 ### Reset flow

wiki/Plugin-Cookbook.md

@@ -11,7 +11,7 @@ for the permission catalogue see [[Plugin Permissions|Plugin-Permissions]].
 > loudly; it never silently escalates.
 
 The complete, runnable version of these recipes is the
-[`trip-doctor`](https://github.com/mauriceboe/TREK/tree/main/plugin-sdk/examples/trip-doctor)
+[`trip-doctor`](https://github.com/liketrek/TREK/tree/main/plugin-sdk/examples/trip-doctor)
 example plugin.
 
 ---

wiki/Plugin-Development.md

@@ -6,6 +6,25 @@ plugins — a static client bundle. TREK runs your server code in an **isolated
 child process** and reaches it only over RPC; the browser part runs in a
 **sandboxed, opaque-origin iframe**. There is no other way in or out.
 
+## Before you start
+
+Two resources sit alongside this page:
+
+- **[Plugin-Skill](https://github.com/liketrek/Plugin-Skill)** — an agent skill
+  that teaches Claude Code and other SKILL.md-compatible coding agents how to
+  build, test and publish a TREK plugin. It covers the same ground as this page,
+  but the agent reads it instead of you. Add it to the repo you build your plugin
+  in and it loads automatically whenever the task touches TREK plugins.
+- **[TREK-Plugins](https://github.com/liketrek/TREK-Plugins)** — the community
+  registry. It is a static index with no server and no account: you list a plugin
+  by opening a pull request that adds one JSON file. Your plugin's code stays in
+  your own repository; the registry only points at it. See
+  [Plugin-Publishing](Plugin-Publishing) for the submission flow and the CI gates.
+
+Neither is required. You can build, install and run a plugin without touching
+either — the registry only matters when you want other people's TREK instances
+to find it.
+
 ## Scaffold
 
 ```bash
@@ -14,20 +33,31 @@ npx trek-plugin-sdk create my-plugin --type integration|page|widget|trip-page
 cd my-plugin
 ```
 
-The wizard (run `create` with no name) asks for the id, type, author and
-permissions; the direct form takes them as flags.
+The wizard (run `create` with no name) asks for the id, type, author, icon (checked
+against lucide — a typo there is invisible locally but rejected by the registry),
+permissions, egress hosts and required addons; the direct form takes them as flags.
 
 This emits:
 
 ```
 my-plugin/
-  trek-plugin.json      # manifest
+  trek-plugin.json      # manifest — including `icon`, and a widget's `slot`
   package.json          # CommonJS marker + the SDK as a devDependency
   server/index.js       # your plugin code (built, plain JS)
   client/index.html     # native UI via the design kit (page / widget / trip-page only)
-  README.md             # fill this in — the registry requires a screenshot
+  README.md             # fill this in — the registry requires four sections and a screenshot
+  docs/                 # where docs/screenshot.png goes; `trek-plugin shot` writes it
+  .gitattributes        # LF everywhere, so the packed artifact's sha256 is reproducible
 ```
 
+The scaffold declares `"trek": ">=3.4.0 <4.0.0"` — the `ctx` namespaces it is written
+against only exist from 3.4.0, and claiming an older floor would let the plugin install
+on a host where they are `undefined`.
+
+What you get **runs and packs immediately**, but it does **not** pass `validate` yet:
+the README is still a template and there is no screenshot. That is deliberate — those
+are yours to write — and `trek-plugin status` says exactly what is missing.
+
 ## Run it locally with hot reload
 
 ```bash
@@ -540,6 +570,18 @@ settings are per-user. `secret: true` fields are stored encrypted and delivered
 decrypted through `ctx.config` (server-side only) — never to the iframe. Resolved
 values arrive in `ctx.config`.
 
+### A custom settings page (`capabilities.settingsUi`)
+
+When declared fields aren't enough — a picker with previews, anything visual —
+set `"capabilities": { "settingsUi": true }` and ship a `client/settings.html`.
+TREK frames it as a card on the user's **Settings → Plugins** page, in the same
+opaque-origin sandbox and postMessage bridge as your widget: it can only reach
+your own declared routes (`trek:invoke`), receives `trek:context`, and should
+report its height via `trek:resize`. Persist whatever it edits through one of
+your own routes (e.g. into your `db:own` database keyed by `req.user.id`) — the
+settings page has no special storage powers. Hosts older than this capability
+simply ignore the flag, so declaring it never breaks an install.
+
 ## Host-brokered OAuth (`ctx.oauth`)
 
 A plugin can act as an OAuth *client* of a third-party service **without ever handling the secrets**. The **host** runs the entire flow — authorize → callback → token exchange → refresh — with PKCE (S256) and a `state` check, and holds the tokens. The plugin only triggers "connect" and reads a **short-lived access token** at runtime.
@@ -1027,7 +1069,12 @@ what your manifest declares.
   only). Vendor any *other* runtime deps: TREK never runs `npm install` on a plugin.
 - **Ship built JS** in `server/index.js` and pre-built static files in `client/`.
   `.ts` and `.map` files are stripped by `pack`.
-- Declare every outbound host in `egress[]` whenever you use `http:outbound`.
+- Declare every outbound host in `egress[]` whenever you use `http:outbound` — **and
+  grant each of them a matching `http:outbound:<host>` permission**. The runtime builds
+  the child process's network allow-list and the iframe's CSP from those *permissions*
+  only; it never reads `egress[]`, which exists for the admin's consent screen. A host
+  listed in `egress[]` with no matching permission installs, activates, consents — and
+  is then silently unreachable. `validate` errors on this.
 
 ## Manifest reference (`trek-plugin.json`)
 
@@ -1038,7 +1085,7 @@ what your manifest declares.
 | `version` | string, **required** | semver (`1.2.3`, optional pre-release). |
 | `apiVersion` | number | plugin API version (currently `1`; `PLUGIN_API_VERSION`). Defaults to `1`. |
 | `type` | string, **required** | `integration` \| `page` \| `widget` \| `trip-page`. |
-| `trek` | string | supported TREK range, e.g. `">=3.2.0 <4.0.0"`. Its lower bound becomes `minTrekVersion` in the registry entry. |
+| `trek` | string, **required** | the TREK versions this plugin supports, as a semver **range**: `">=3.4.0 <4.0.0"` (what the scaffold writes). Must be *satisfiable* (`">=4.0.0 <3.0.0"` parses but nothing can satisfy it — rejected). **Enforced at install and at activation** (see below); it is copied verbatim onto the registry entry, which is the entry's only compatibility field. Keep it **bounded** — an unbounded range claims support for TREK versions that do not exist yet. |
 | `author` | string | shown in the store. |
 | `description` | string | one-line summary for the store. |
 | `icon` | string | lucide-react icon name (default `Blocks`); used for the page nav entry. |
@@ -1058,6 +1105,33 @@ what your manifest declares.
 | `pluginDependencies` | `{ id, version }[]` | other plugins (semver range) that must be installed + version-satisfied to activate. |
 | `settings` | array | setting fields (below). |
 
+#### TREK version compatibility (`trek`)
+
+The `trek` range is a **hard contract**, enforced in both directions:
+
+- **Install** is refused when the running TREK falls outside it — on every path:
+  registry install, an explicitly pinned version, an update, a sideloaded archive,
+  and a dev-link. A manifest with no range (or an unsatisfiable one) cannot be
+  installed at all.
+- **Activation** re-checks it, which is the half install cannot cover: a plugin
+  legitimately installed on 3.3 is still on disk after an upgrade to 4.0, and if it
+  declared `<4.0.0` it now refuses to start. It stays installed and listed,
+  switched off, with the reason shown (`TREK_VERSION_INCOMPATIBLE`; a plugin that
+  declares no range at all reports `TREK_VERSION_UNKNOWN`).
+- **No admin override.** The range is the author's own statement that the plugin
+  does not work there — unlike a rotated signing key, there is nothing an operator
+  could verify out-of-band and wave through.
+
+Two behaviours follow. "Install latest" resolves to the newest version *this* TREK
+can run rather than the newest published, so shipping a 2.0.0 that needs TREK 4
+doesn't strand 3.x users. And an **update** that would move a working plugin out of
+compatibility is refused rather than performed.
+
+One gap, by design: a host whose `APP_VERSION` is not a semver version — the Docker
+build arg defaults to the literal `dev` — has nothing to compare a range against, so
+the check is skipped and an unversioned build installs anything. Plugins should still
+guard optional `ctx.*` namespaces.
+
 **Permissions** — the commonly-used core subset below; the **full list of ~50**
 (all read/write scopes, the notify/ai/oauth brokers, every provider hook) lives in
 **[[Plugin Permissions|Plugin-Permissions]]**. Unknown values are rejected at activation.
@@ -1112,47 +1186,84 @@ what your manifest declares.
 | `oauth` | `{ initPath, callbackPath }` for OAuth flows. |
 
 **Page nav:** the host builds a page plugin's nav entry from the top-level `name`
-and `icon`. `create-trek-plugin` also scaffolds a `capabilities.nav` block, but the
-installed-manifest parser only consumes `capabilities.widget` — set `name`/`icon`
-to control the nav entry.
+and `icon` — the installed-manifest parser only consumes `capabilities.widget`, so
+there is nothing else to set. `icon` must be a real lucide name: TREK resolves it at
+render time and silently falls back to `Blocks`, which makes a typo invisible locally,
+so `validate` rejects one.
 
 See [[Plugin Permissions|Plugin-Permissions]] for the full permission model.
 
 ## The `trek-plugin` CLI
 
 Run `npx trek-plugin-sdk` **with no command** in a terminal and you get an
-interactive menu (create / dev / validate / pack / publish, with signing and
-registry-entry commands under **Advanced…**); it just picks which command to run,
-then that command prompts for whatever it needs. Pass a command explicitly to skip
-the menu (and for scripts/CI).
+interactive menu — create / dev / status / shot / publish, with validate, pack,
+signing and the registry-entry commands under **Advanced…** It picks which command to
+run and asks which plugin directory to run it against; that command then prompts for
+whatever else it needs. Pass a command explicitly to skip the menu (and for scripts and
+CI). `trek-plugin help <command>` — or `trek-plugin <command> --help` — prints a full
+page for any command.
 
-Author commands (from `trek-plugin-sdk`):
+**The path is four commands**, and the other nine are steps one of them already does:
 
 ```bash
-# 1. Manifest + layout checks (a subset of the registry CI — CI additionally
-#    verifies the GitHub release exists, the artifact sha256, and the README
-#    over the network).
-trek-plugin validate [dir]
-
-# 2. Build plugin.zip in the installer's exact layout. Prints sha256 + byte size,
-#    refuses native binaries, enforces the same size limits (25MB/file, 50MB total).
-#    Ships trek-plugin.json, README.md, LICENSE(.md), package.json + server/ + client/.
-#    docs/ is intentionally NOT shipped — the store fetches docs/screenshot.png
-#    from your repo. --json prints a machine-readable result.
-trek-plugin pack [dir] [--out plugin.zip] [--json]
-
-# 3. Emit the ready-to-PR registry entry: commitSha (resolved from the git tag),
-#    downloadUrl, sha256, size and minTrekVersion (derived from the manifest
-#    'trek' range) all computed for you. --merge prepends a new version onto an
-#    existing entry (the update case, kept newest-first).
-trek-plugin entry --repo owner/name --tag vX.Y.Z [--zip plugin.zip] [--merge entry.json] [--out file]
-
-# 4. One shot: pack -> create the GitHub release (via gh) -> print the entry.
-trek-plugin release [dir] --repo owner/name --tag vX.Y.Z
+trek-plugin create [name] [--type integration|page|widget|trip-page]
+trek-plugin dev [dir] [--port 4317]
+trek-plugin status [dir]
+trek-plugin publish [dir] --repo owner/name --tag vX.Y.Z [--sign]
 ```
 
-To publish, open a PR that adds the emitted JSON as
-`registry/plugins/<id>.json` in the TREK-Plugins registry.
+`status` is the one to reach for when you are not sure what to do next. It runs every
+gate the TREK-Plugins registry enforces that can be answered **without a network** —
+which is nearly all of them — and prints the whole journey as a checklist grouped by
+stage (Manifest, Code, Docs, Release, Repo), with the one command to run next. It never
+exits non-zero: it is for orientation, not for gating.
+
+```bash
+# The gate. The SAME checks as `status`, but it exits 1. This is the form for CI.
+trek-plugin validate [dir]
+
+# Build plugin.zip in the installer's exact layout. Prints sha256 + byte size,
+# refuses native binaries, enforces the same size limits (25MB/file, 50MB total).
+# Ships trek-plugin.json, README.md, LICENSE(.md), package.json + server/ + client/.
+# docs/ is intentionally NOT shipped — the store fetches docs/screenshot.png from
+# your repo. It refuses a plugin that could not LOAD, but deliberately does not
+# enforce the publish gates (an unwritten README, a missing screenshot) — packing is
+# how you sideload a plugin to try it locally.
+trek-plugin pack [dir] [--out plugin.zip] [--json]
+
+# Boot the dev server, render the plugin in the themed /preview frame, and write a
+# 1600x900 docs/screenshot.png. Needs Playwright (not an SDK dependency — it ships a
+# browser): npm i -D playwright && npx playwright install chromium
+trek-plugin shot [dir] [--port 4317] [--out docs/screenshot.png] [--dark] [--no-serve]
+
+# Ed25519 signing. keygen once; `publish --sign` is the usual way to use the key.
+trek-plugin keygen [--key file]
+trek-plugin sign [zip] [--key file]
+
+# Emit the ready-to-PR registry entry: commitSha (resolved from the git tag),
+# downloadUrl, sha256, size, and the manifest's `trek` range verbatim — plus
+# requiredAddons and pluginDependencies, which the registry parity-checks against the
+# manifest. --merge prepends a new version onto an existing entry (the update case,
+# kept newest-first).
+trek-plugin entry --repo owner/name --tag vX.Y.Z [--zip plugin.zip] [--merge entry.json] [--out file]
+
+# The registry checks that genuinely need the network: the tag resolves to the commit
+# the entry pins, the released artifact downloads and hashes to the pinned sha256, the
+# id is not bound to another GitHub owner, and an update does not drop or rotate a
+# signing key you already published under. `publish` runs this for you.
+trek-plugin preflight [dir] --repo owner/name --tag vX.Y.Z [--entry file.json] [--all]
+
+# Pack -> cut the GitHub release -> print the entry, without opening the registry PR.
+trek-plugin release [dir] --repo owner/name --tag vX.Y.Z [--sign] [--merge entry.json]
+
+# Fork the registry, write registry/plugins/<id>.json, open the PR. Needs `gh`.
+trek-plugin submit [dir] --repo owner/name --tag vX.Y.Z [--registry o/n] [--draft]
+```
+
+`publish` chains those last steps in the order that matters: **check → pack → release →
+preflight → submit**. The local gates run *before* anything is tagged or released,
+because a GitHub release is effectively immutable — the registry pins its sha256. See
+[[Publishing a Plugin|Plugin-Publishing]].
 
 ## Registry & publishing
 

wiki/Plugin-Publishing.md

@@ -1,7 +1,7 @@
 # Publishing a Plugin
 
 Plugins are distributed from a static registry — the
-[TREK-Plugins](https://github.com/mauriceboe/TREK-Plugins) GitHub repo. There is
+[TREK-Plugins](https://github.com/liketrek/TREK-Plugins) GitHub repo. There is
 no upload server and no account: you host the code in your own public GitHub repo,
 attach a built `plugin.zip` to a release, and list it with a pull request.
 
@@ -10,16 +10,33 @@ the mechanical work — you rarely hand-type a hash, size, commit, or JSON field
 
 ## The short version — one command
 
-Commit and push your plugin to its public GitHub repo, then:
+Get the plugin green locally (`trek-plugin status` will tell you what is left), commit
+and push it to its public GitHub repo, then:
 
 ```bash
 npx trek-plugin-sdk publish --repo you/trek-plugin-flight-tracker --tag v1.0.0
 ```
 
-`publish` runs the whole release: **pack** → **tag + GitHub release** →
-**preflight** (the registry CI checks, locally) → **open the registry PR**. If
-preflight finds a problem it stops *before* submitting, so a broken entry never
-becomes a doomed PR. It prints the PR URL at the end. Sign it with `--sign`.
+`publish` runs the whole release, in five steps and in **this order**:
+
+1. **check** — every registry gate that can be checked locally
+2. **pack** — build `plugin.zip`
+3. **release** — git tag, push, and cut the GitHub release with the artifact attached
+4. **preflight** — the gates that need the tag and the release to exist
+5. **submit** — open the PR against the registry
+
+The order is the point. A GitHub release is effectively immutable: the registry pins
+its sha256, so overwriting the bytes breaks the checksum for everyone who already
+installed that version. So the local gates run **first** — if one fails, nothing is
+packed, tagged, pushed or released, and you can fix it and re-run against the same
+version. (Before this, the checks ran *after* the release was cut, and an author who
+failed them had burned their `v1.0.0` tag on an unwritten README.)
+
+It prints the PR URL at the end. In a terminal it **offers to sign** the release (and
+creates the key if you have none); scripts and CI are never prompted and pass `--sign`.
+`--no-checks` skips step 1 and
+`--no-preflight` skips step 4 — escape hatches for a re-run, never right on a first
+publish. It needs `git` and an authenticated `gh`.
 
 The individual steps below still exist for when you want one by hand — `release`
 (pack → GitHub release → entry), `preflight`, and `submit` (opens the PR) — or
@@ -44,19 +61,55 @@ A publishable plugin has, at the repo root:
 - `README.md` — filled in, with a real screenshot (the quality gate is strict — see below)
 - `docs/screenshot.png` — the store card image, committed to the repo
 
-## 2. Validate
+What `create` gives you runs and packs, but it does **not** pass `validate`: the README
+is a template and there is no screenshot. Those are the two things only you can write.
+
+## 2. Get it green locally
 
 ```bash
-npx trek-plugin-sdk validate .
+npx trek-plugin-sdk status         # where am I? what's left? — never fails
+npx trek-plugin-sdk validate .     # the same checks, but it exits non-zero
 ```
 
-`validate` runs the manifest checks plus a light layout/README sanity pass:
-it fails if `trek-plugin.json` is invalid or `server/index.js` is missing, and
-warns if the directory name doesn't match the plugin `id`, the README has no
-screenshot, or the README still contains scaffold placeholders. This is a
-**subset** of what CI runs — CI additionally verifies the release, the artifact's
-SHA-256, and the README over the network — so a clean local run predicts a clean
-CI run but doesn't replace it.
+`status` and `validate` run the **same registry gates** at two different depths.
+`status` prints them as a checklist grouped by stage (Manifest, Code, Docs, Release,
+Repo) and names the one command to run next; it is for orientation, so it never fails.
+`validate` is the gate — same checks, exit code — and is the form for scripts and CI.
+
+Between them they now catch, **offline**, nearly everything the registry rejects for:
+
+- an `icon` that isn't a real lucide name (TREK falls back to `Blocks` silently, so a
+  typo is invisible locally — but CI rejects it)
+- a README missing any of the four required sections, still carrying scaffold
+  placeholders, or under **400 characters** of real prose
+- a screenshot that doesn't resolve to a file on disk (not just a link in the README —
+  the file has to be there)
+- a permission your manifest declares but the README never explains
+- a `name`, `description` or `author` outside the registry's length limits, or a name
+  that mixes Latin with Cyrillic/Greek look-alikes (a homoglyph spoof)
+- an `egress[]` host with no matching `http:outbound:<host>` permission — TREK builds
+  the network allow-list and the iframe CSP from those permissions only and never reads
+  `egress[]`, so such a host is silently unreachable at runtime
+
+Only **four** gates genuinely need the network, and they all need the release to exist:
+that the tag resolves to the commit the entry pins, that the released artifact downloads
+and hashes to the pinned sha256 (and verifies against your key), that your plugin id
+isn't bound to another GitHub owner, and that an update doesn't drop or rotate a signing
+key you already published under. Those run in `preflight` — step 4 of `publish`.
+
+### Capture the screenshot
+
+```bash
+npm i -D playwright && npx playwright install chromium   # once — not an SDK dependency
+npx trek-plugin-sdk shot                                 # --dark for the dark theme
+```
+
+`shot` boots the dev server, renders your plugin in the same themed frame TREK uses,
+and writes a 1600×900 `docs/screenshot.png`. An `integration` plugin has no UI to
+render, so `shot` can't help — screenshot the TREK surface your plugin changes instead.
+
+Commit the screenshot. The registry resolves it **at the pinned commit**, so an image
+that exists only in your working tree fails CI even though `status` was green.
 
 ## 3. Pack
 
@@ -66,8 +119,13 @@ npx trek-plugin-sdk pack . --out dist.zip  # custom output path
 npx trek-plugin-sdk pack . --json          # machine-readable result
 ```
 
-`pack` validates first, then builds `plugin.zip` in the installer's exact layout
-and prints the **sha256** and **size** you'd otherwise compute by hand. It ships
+`pack` builds `plugin.zip` in the installer's exact layout and prints the **sha256**
+and **size** you'd otherwise compute by hand. It refuses to pack a plugin that could
+not *load* — a broken manifest, a missing `server/index.js`, a native binary — but it
+deliberately does **not** enforce the publish gates (an unwritten README, a missing
+screenshot), because packing is also how you sideload a plugin into a local TREK to try
+it, and the docs only have to be there when you ship. `validate` is what gates those.
+It ships
 only what the runtime needs — `trek-plugin.json`, `README.md`, `LICENSE`,
 `package.json`, and the `server/` and `client/` trees — and drops `node_modules`,
 `.git`, source maps and `.ts` sources. It **refuses native binaries**
@@ -108,8 +166,13 @@ npx trek-plugin-sdk entry \
 
 `entry` reads your manifest and `plugin.zip` and emits the complete entry —
 deriving `commitSha` (from `git rev-parse <tag>^{commit}`), `downloadUrl`,
-`sha256`, `size`, `apiVersion`, and `minTrekVersion` (the lower bound of the
-manifest's `trek` range, e.g. `">=3.2.0 <4.0.0"` → `3.2.0`). Flags: `--zip`
+`sha256`, `size`, `apiVersion`, and **`trek`** — your manifest's range, verbatim.
+That range is the entry's only compatibility field: it is what TREK gates installs
+and activation on. (The older `minTrekVersion`/`maxTrekVersion` are **deprecated**
+and no longer emitted — the first merely restated the range's lower bound, and the
+second is *inclusive*, so it cannot express `<4.0.0` at all. Entries published
+before `trek` existed may still carry them.) `entry` refuses to build an entry for a
+manifest with no usable `trek` range, because TREK would refuse to install it. Flags: `--zip`
 (default `plugin.zip`), `--commit <sha>` to override commit resolution, `--asset`
 to name a differently-named release asset, `--merge` for updates (below), and
 `--out` to write a file.
@@ -124,21 +187,27 @@ npx trek-plugin-sdk release . --repo you/trek-plugin-flight-tracker --tag v1.0.0
 entry to stdout. It accepts `--out`, `--notes`, `--commit`, and `--merge`. (It
 requires the `gh` CLI, authenticated.)
 
-## 6. Preflight — run the CI checks locally
+## 6. Preflight — the checks that need the release to exist
 
-Before you open the PR, run the exact registry CI checks against your pushed
+Before you open the PR, run the registry's remaining CI checks against your pushed
 release, so you catch what CI would reject without a review round-trip:
 
 ```bash
 npx trek-plugin-sdk preflight --repo you/trek-plugin-flight-tracker --tag v1.0.0
 ```
 
-`preflight` mirrors both CI scripts over the network: the tag resolves to the
-pinned `commitSha`, the manifest at that commit matches the entry, the released
-artifact's **sha256 + size** match and it carries **no native binaries**, and the
-README passes the quality gate (required sections, real prose, a resolving
-screenshot, permission parity). It also accepts `--entry <file.json>` to check a
-hand-written entry. A green preflight predicts a green CI.
+`preflight` runs everything `validate` runs, plus the four gates that genuinely need
+the network: the tag resolves to the pinned `commitSha`; the manifest **and the
+README** at that commit match the entry and pass the quality gate; the released
+artifact downloads, hashes to the pinned **sha256**, carries **no native binaries** and
+verifies against your key; your plugin id is not bound to a different GitHub owner; and
+an update does not drop or rotate a signing key you already published under.
+
+Re-grading the manifest and the README *at the commit* is not redundant with the local
+pass: an author who writes the README and forgets to commit it has a green tree and a
+red tag, and the tag is what CI grades. `--entry <file.json>` checks a hand-written
+entry, `--all` checks every version rather than just the newest. A green preflight
+predicts a green CI.
 
 ## 7. Open the registry PR
 
@@ -148,7 +217,7 @@ The fast path — `submit` does the whole fork/branch/commit/PR dance for you:
 npx trek-plugin-sdk submit --repo you/trek-plugin-flight-tracker --tag v1.0.0
 ```
 
-It forks [TREK-Plugins](https://github.com/mauriceboe/TREK-Plugins) (once),
+It forks [TREK-Plugins](https://github.com/liketrek/TREK-Plugins) (once),
 branches off the current `main`, writes (or, for an update, merges into)
 `registry/plugins/<id>.json`, pushes, and opens the PR — printing its URL. Add
 `--draft` for a draft PR, `--registry <owner/name>` for a mirror. (Requires `gh`,
@@ -158,17 +227,21 @@ authenticated.)
 `registry/plugins/<id>.json`, and open a PR back to `main`. Add **only** that
 file — `dist/` is generated on merge, and CI rejects manual edits to it.
 
-The entry follows [`schema/plugin-entry.schema.json`](https://github.com/mauriceboe/TREK-Plugins/blob/main/schema/plugin-entry.schema.json);
-[`schema/example-entry.json`](https://github.com/mauriceboe/TREK-Plugins/blob/main/schema/example-entry.json)
+The entry follows [`schema/plugin-entry.schema.json`](https://github.com/liketrek/TREK-Plugins/blob/main/schema/plugin-entry.schema.json);
+[`schema/example-entry.json`](https://github.com/liketrek/TREK-Plugins/blob/main/schema/example-entry.json)
 is the canonical shape. `size` is **required** (a common omission), as are
-`commitSha`, `downloadUrl`, `sha256`, `minTrekVersion`, `apiVersion`, and
+`commitSha`, `downloadUrl`, `sha256`, `trek`, `apiVersion`, and
 `nativeModules: false` on every version — all of which `trek-plugin entry` fills
-in for you.
+in for you. CI rejects an entry whose `trek` disagrees with the manifest at
+`commitSha` (and, on a legacy entry that still carries a `minTrekVersion`, one
+whose floor disagrees with that range).
 
 ## What CI enforces
 
 CI runs `scripts/validate-entry.mjs` and `scripts/check-readme.mjs` on every
-changed `registry/plugins/*.json`.
+changed `registry/plugins/*.json`. Nearly every rule below is a pure function of your
+`trek-plugin.json` and `README.md`, so `trek-plugin validate` checks it offline before
+you have tagged anything — you should never learn any of this from CI.
 
 **Entry** (`validate-entry.mjs`): valid schema · `id` matches the filename and
 the slug pattern `^[a-z][a-z0-9-]{2,39}$` · your `id` is bound to your GitHub
@@ -210,19 +283,21 @@ TREK verifies the signature offline (minisign / Ed25519, no external service) an
 pins your key on first install (trust-on-first-use): a later release signed with a
 different key is refused until an admin re-trusts it.
 
-**The easy way — let the SDK do it** (dependency-free Ed25519, no minisign needed):
+**The easy way — let the SDK do it** (dependency-free Ed25519, no minisign needed).
+In a terminal, `publish` **proposes signing**: it explains the tradeoff, offers to
+create the key if you have none, and signs. You never have to know `keygen` or
+`--sign` exist. Scripts and CI are never prompted — they pass `--sign`:
 
 ```bash
-npx trek-plugin-sdk keygen                                     # once: writes ~/.trek-plugin/signing.key
-npx trek-plugin-sdk release --repo you/repo --tag v1.2.0 --sign
-npx trek-plugin-sdk submit  --repo you/repo --tag v1.2.0 --sign
+npx trek-plugin-sdk publish --repo you/repo --tag v1.2.0 --sign
 ```
 
 `--sign` signs the exact artifact bytes and fills both `authorPublicKey` (entry)
-and `signature` (version) for you; `submit --sign` even refuses to publish an
-update signed with a *different* key than the one already listed, so you can't
-lock yourself out by accident. **Back up `~/.trek-plugin/signing.key`** — losing
-it means you can't ship signed updates.
+and `signature` (version) for you. If the plugin was already published signed,
+`publish` **refuses an unsigned release at step 1** — before anything is packed,
+tagged or released — because a GitHub release is immutable and learning this at
+step 4 would have burned the tag. **Back up `~/.trek-plugin/signing.key`** —
+losing it means you can't ship signed updates.
 
 **By hand with minisign**, if you prefer:
 
@@ -252,14 +327,21 @@ next to its `sha256`:
 }
 ```
 
-Signing is **opt-in**: an entry without `authorPublicKey`/`signature` installs on
-`sha256` alone. But once a plugin has shipped signed, an *unsigned* update is
-refused — don't drop the signature between versions.
+Signing is **opt-in**, and it is a one-way door you may walk through **late**. An
+entry without `authorPublicKey`/`signature` installs on `sha256` alone; **going
+unsigned → signed later breaks nobody**, because nothing is pinned until a signed
+version installs — adding a key at v1.4.0 is a real option, not a lost cause. What
+you can never do is go back: once a plugin has shipped signed, an *unsigned* update
+is refused (`SIGNATURE_MISSING`) on every instance that already has it, and a key
+*rotation* needs a registry maintainer override (`allow-key-change`) plus an admin
+re-trust on each instance. So sign whenever you like — but back the key up.
 
 ## Updating
 
-Bump `version` in the manifest, re-`pack`, cut a new `vX.Y.Z` release, then fold
-the new version onto your existing entry with `--merge`:
+Bump `version` in the manifest, commit, and run `publish` again with the new tag — it
+detects the existing entry and prepends the new version, newest-first. By hand: re-`pack`,
+cut a new `vX.Y.Z` release, then fold the new version onto your existing entry with
+`--merge`:
 
 ```bash
 npx trek-plugin-sdk entry --repo you/trek-plugin-flight-tracker --tag v1.1.0 \

wiki/Public-Share-Links.md

@@ -2,8 +2,6 @@
 
 Share a read-only view of your trip with people who do not have a TREK account. The viewer opens in a browser without logging in.
 
-<!-- TODO: screenshot: share link creation form with permission toggles -->
-
 ![Public share link](assets/Share.png)
 
 ## Creating a share link
@@ -34,6 +32,10 @@ When creating or updating a share link you choose what the recipient can see. Th
 
 Disabled toggles hide the corresponding tab from the public viewer entirely. Permission changes take effect immediately — you do not need to recreate the link.
 
+### Which currency guests see
+
+A public viewer has no account, so there is no "their" display currency to use. The Budget tab is rendered in **the sharer's display currency, falling back to the trip's own currency** — in other words, a guest sees the money the way the person who shared the trip sees it. If the sharer leaves their display currency on **Trip currency** (the default), guests read the trip in the trip's own currency. See [Currencies](Currencies).
+
 ## What the public viewer shows
 
 The shared trip page renders a branded read-only interface with a dark hero header showing the trip title, description, and date range. A tab bar at the top provides access to the sections you enabled. The viewer can switch the display language using a language picker in the top-right corner.
@@ -52,4 +54,4 @@ The Travel Journal (Journey addon) has a separate share mechanism with its own t
 
 ## Related pages
 
-[Trip-Members-and-Sharing](Trip-Members-and-Sharing) · [Journey-Journal](Journey-Journal) · [Real-Time-Collaboration](Real-Time-Collaboration)
+[Trip-Members-and-Sharing](Trip-Members-and-Sharing) · [Currencies](Currencies) · [Journey-Journal](Journey-Journal) · [Real-Time-Collaboration](Real-Time-Collaboration)

wiki/Quick-Start.md

@@ -21,7 +21,7 @@ ENCRYPTION_KEY=$(openssl rand -hex 32) docker run -d \
   -v ./data:/app/data \
   -v ./uploads:/app/uploads \
   --restart unless-stopped \
-  mauriceboe/trek:latest
+  mauriceboe/TREK:latest
 ```
 
 **Flag breakdown:**

wiki/Real-Time-Collaboration.md

@@ -2,7 +2,7 @@
 
 TREK keeps every trip in sync across all connected members without requiring a page refresh. A dedicated **Collab addon** adds a second layer on top of that sync: group chat, shared notes, polls, and a "What's Next" widget showing upcoming assigned places.
 
-<!-- TODO: screenshot: collaborative editing with presence indicators -->
+![The Collab tab: chat, shared notes, polls and the What's Next widget side by side](assets/Collab.png)
 
 ## Real-time sync
 

wiki/Reservations-and-Bookings.md

@@ -121,6 +121,16 @@ Items that the extractor could only partially parse are flagged **Needs review**
 
 KDE Itinerary only recognises structured tickets. For confirmations it can't read — plain-text emails, unusual PDF layouts, vendors it doesn't know — TREK can optionally hand the file to an AI model instead. The optional **AI Parsing** addon runs only for the files Itinerary returns nothing for, parses them in the background, and flags every result for review before you save it. It works with a self-hosted local model, so booking data need not leave your server. See **[AI-Booking-Import](AI-Booking-Import)**.
 
+## Import from AirTrail
+
+With the **AirTrail** integration addon enabled and your instance connected under **Settings → Integrations**, the reservations toolbar shows an **AirTrail** button. It lists the flights from your AirTrail account — flights inside the trip dates come pre-selected — and imports each one as a flight reservation that stays in sync with AirTrail both ways.
+
+### Connecting flights (layovers)
+
+When selected flights form a connection — each leg departs from the airport the previous one landed at, onward within 24 hours — the picker groups them and offers to **import them as one flight with a layover**. The offer is on by default; untick it to keep separate bookings. A joined booking keeps each leg's own airline, flight number, times and seat, the connection airport becomes a layover **stop** on the route, and each leg files into its own day in the planner. Since a stop is not a destination, the layover country no longer shows up as visited in Atlas.
+
+AirTrail itself has no multi-leg flights, so a joined booking is imported **without live sync** (it shows the *Not synced* badge). Its source flights stay recognised — the picker will not offer them for import again. The same applies when you add a stop to a synced single flight by hand: the booking detaches from AirTrail instead of syncing a shape AirTrail cannot represent.
+
 ## Editing and deleting
 
 Each card has a pencil icon to open the edit form and a trash icon to delete. Deleting requires confirmation in a dialog before the record is removed.

wiki/Reverse-Proxy.md

@@ -9,12 +9,13 @@ Putting TREK behind a TLS-terminating reverse proxy is strongly recommended for
 - **OIDC / SSO** — identity providers require the redirect URI to use HTTPS.
 - **MCP** — the MCP API requires HTTPS for OAuth 2.1 auth.
 
-## Two Hard Requirements
+## Three Hard Requirements
 
-Whatever proxy you use, it must satisfy two constraints:
+Whatever proxy you use, it must satisfy three constraints:
 
 1. **WebSocket upgrades on `/ws`** — TREK uses WebSockets for real-time sync. Set `proxy_read_timeout 86400` (Nginx) or rely on Caddy's automatic upgrade handling.
 2. **Body size ≥ 500 MB** — backup restore ZIPs can include the full uploads directory. Set `client_max_body_size 500m` (Nginx) or `request_body_max_size 500mb` (Caddy) if you restore large backups.
+3. **Pass the `Mcp-Session-Id` header through on `/mcp`** — if you use MCP. See below.
 
 ## Nginx
 
@@ -83,6 +84,44 @@ trek.yourdomain.com {
 }
 ```
 
+## MCP behind a proxy
+
+Skip this section if you don't use the MCP addon.
+
+MCP is session-based. On the first request the server replies with an `Mcp-Session-Id` response header, and the client sends that value back as a request header on every subsequent call. **Both directions must survive the proxy.** If the response header is stripped, the client never learns its session id, so every single tool call looks like a brand-new connection — the server opens a fresh session each time, sessions pile up, and once the user hits `MCP_MAX_SESSION_PER_USER` the oldest session is evicted to make room for each new one. The connection keeps working, but it is churning sessions instead of reusing one, and you will see this warning on every tool call:
+
+```
+[MCP] POST without mcp-session-id for user 1 — starting a new session. If this
+repeats on every tool call, the Mcp-Session-Id response header is not reaching
+the client (check that your reverse proxy forwards it).
+```
+
+Nginx and Caddy both forward custom headers in both directions by default, so **the standard configs above already work**. You only need to act if you have deliberately restricted headers:
+
+- Don't list `/mcp` under a `proxy_hide_header` directive, and don't run it through a response-header allowlist that omits `Mcp-Session-Id`.
+- If your proxy rewrites or lowercases headers, that's fine — HTTP header names are case-insensitive and both TREK and MCP clients treat them as such.
+- The browser-facing `Access-Control-Expose-Headers: Mcp-Session-Id` response header is what permits browser-based clients (Claude.ai, Claude Desktop connectors, MCP Inspector) to *read* the session id at all. TREK sends it automatically — don't strip or overwrite it in the proxy.
+
+TREK 3.3.0 and earlier did not send `Access-Control-Expose-Headers` at all, which caused exactly the symptom above regardless of proxy configuration. If you are on an older version and see a new session per tool call, upgrade — no proxy change will fix it.
+
+### Streaming responses
+
+The `/mcp` endpoint answers with Server-Sent Events. If your proxy buffers responses, tool results are delayed until the buffer flushes. Nginx buffers by default, so disable it for that path:
+
+```nginx
+location /mcp {
+    proxy_pass http://localhost:3000;
+    proxy_set_header Host $host;
+    proxy_set_header X-Real-IP $remote_addr;
+    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    proxy_set_header X-Forwarded-Proto $scheme;
+    proxy_buffering off;      # SSE — deliver tool results as they stream
+    proxy_read_timeout 3600s; # long-lived streams between tool calls
+}
+```
+
+TREK sends an SSE keep-alive comment every 25 seconds (`MCP_SSE_KEEPALIVE`) precisely so proxies with a short idle timeout — nginx defaults to 60 s — don't drop an idle stream between tool calls. Lower the interval if your proxy's timeout is tighter than that.
+
 ## HTTPS Environment Variables
 
 Four variables control how TREK behaves behind a proxy. They work as a group:

wiki/Route-Optimization.md

@@ -2,8 +2,6 @@
 
 TREK calculates walking and driving times between your places and can reorder them to minimize total travel distance.
 
-<!-- TODO: screenshot: optimized route displayed on map -->
-
 ![Route Optimization](assets/OptimizeRoute.png)
 
 ## Route calculation
@@ -28,14 +26,8 @@ Only unlocked places are reordered — locked places stay in their current posit
 
 The reorder can be undone immediately using the undo action that appears after it is applied.
 
-## Route calculation on/off
-
-Route calculation (segment time pills) can be toggled on or off per user in **Settings → Display**. When disabled, no OSRM requests are made and time pills are not shown.
-
 ## Export day to Google Maps
 
 The **Open in Google Maps** button (icon next to Optimize) generates a `https://www.google.com/maps/dir/lat,lng/lat,lng/…` URL containing all places in order and opens it in a new tab.
 
-> **Admin:** Route calculation can be disabled instance-wide via the admin settings.
-
 **See also:** [Day-Plans-and-Notes](Day-Plans-and-Notes) · [Map-Features](Map-Features) · [Display-Settings](Display-Settings)

wiki/Todos-and-Tasks.md

@@ -2,8 +2,6 @@
 
 Manage a to-do list for trip tasks and pre-departure preparation.
 
-<!-- TODO: screenshot: to-do list with checkboxes and priority badges -->
-
 ![Todos and Tasks](assets/Todos.png)
 
 ## Where to find it

wiki/Transport-Flights-Trains-Cars.md

@@ -2,6 +2,8 @@
 
 Log flights, trains, car rentals, and cruises with departure and arrival endpoints, times, and transit-specific details.
 
+![Transports tab listing a confirmed flight card with its day range, times, booking code, airport endpoints, airline and flight number](assets/Transports.png)
+
 ## Where to create
 
 Open the **Transports** tab in the trip planner and click **Add**, or open the planner from a day view and use the transport shortcut. Transport records appear in the [Reservations](Reservations-and-Bookings) panel alongside other bookings.

wiki/Trip-Members-and-Sharing.md

@@ -1,7 +1,5 @@
 # Trip Members and Sharing
 
-<!-- TODO: screenshot: trip members list with roles and share link form -->
-
 ![Trip Members](assets/Share.png)
 
 ## Opening the Members Panel

wiki/Trip-Planner-Overview.md

@@ -2,8 +2,6 @@
 
 The trip planner is the main workspace for building your itinerary. It opens automatically after you create a trip, or any time you click a trip card on the dashboard.
 
-<!-- TODO: screenshot: trip planner tab bar overview -->
-
 ![Trip Planner](assets/TripPlannerWithPlane.png)
 
 ## Layout
@@ -25,6 +23,8 @@ The planner uses a **three-pane resizable layout** on desktop:
 
 Each sidebar has a drag handle on its inner edge for resizing.
 
+![Planner in its three-pane layout: the day plan sidebar with days, places, notes and flight entries on the left, the map in the centre, and the places sidebar with search and category filter on the right](assets/TripPlanner.png)
+
 A **Day Detail overlay** slides in over the center pane when you open a specific day, showing weather, the day's notes, reservation summaries, and the accommodation block. It can be minimized without closing it.
 
 ## Tabs
@@ -37,11 +37,11 @@ The tab bar sits directly below the main navigation bar.
 | **Transports** | Flights, trains, cars, cruises, and buses. |
 | **Reservations** | Hotels, restaurants, events, tours, and other bookings. |
 | **Lists** | Packing list and to-do list. |
-| **Budget** | Budget tracking and expense logging. |
+| **Costs** | Expense tracking, splitting, and settlement. |
 | **Files** | Document manager for receipts, tickets, and other files. |
 | **Collab** | Real-time chat, shared notes, and polls. |
 
-> **Admin:** The **Lists**, **Budget**, **Files**, and **Collab** tabs only appear when the corresponding addon is enabled. See [Admin-Addons](Admin-Addons).
+> **Admin:** The **Lists**, **Costs**, **Files**, and **Collab** tabs only appear when the corresponding addon is enabled. See [Admin-Addons](Admin-Addons).
 
 The active tab is saved in `sessionStorage` per trip, so switching between trips preserves your last position.
 

wiki/Troubleshooting.md

@@ -349,9 +349,9 @@ Restart the container after adding the variable. Once set, clicking **Connect**
 
 ---
 
-## MCP integration: "Too many requests" or "Session limit reached"
+## MCP integration: "Too many requests"
 
-**Cause:** Each user is limited to 300 MCP requests per minute and 20 concurrent sessions by default. Exceeding either limit returns a `429` response.
+**Cause:** Each user is limited to 300 MCP requests per minute by default. Exceeding the limit returns a `429` response.
 
 **Fix:** Increase the limits via environment variables:
 
@@ -361,6 +361,48 @@ environment:
   - MCP_MAX_SESSION_PER_USER=50 # concurrent sessions per user (default: 20)
 ```
 
+The session limit no longer rejects requests: at the cap, the server closes the user's least-recently-active session to make room for the new one. If you are hitting the cap at all, see the next entry — the usual cause is sessions being created faster than they are reused, not genuinely parallel clients.
+
+---
+
+## MCP: a new session is created on every tool call / sessions pile up
+
+**Symptoms:** the server log shows a `Session <uuid> created` line for *every* tool call, with `Active sessions` climbing steadily. The idle sweep reports `cleaned 0` no matter how many sessions are open. On older versions the connection dies once the count reaches `MCP_MAX_SESSION_PER_USER` and only a restart brings it back.
+
+**Cause:** the client never receives — or cannot read — the `Mcp-Session-Id` response header, so it cannot send it back on the next call. Every request then looks like a brand-new connection and the server opens a fresh session for it. The `cleaned 0` sweep is a red herring: the sweep expires sessions after an hour of *inactivity* (`MCP_SESSION_TTL`), so sessions created seconds apart are nowhere near expiry.
+
+There are two reasons the header goes missing:
+
+1. **TREK 3.3.0 and earlier** did not send `Access-Control-Expose-Headers: Mcp-Session-Id`. Without it, browser-based clients — Claude.ai, Claude Desktop connectors, MCP Inspector — are forbidden by the browser from reading the session id, no matter how the proxy is configured. **Fix: upgrade** — no proxy change will help.
+2. **A reverse proxy stripping the header.** Nginx and Caddy forward it by default, so this only happens if you have a `proxy_hide_header` directive or a response-header allowlist in front of `/mcp`. See [Reverse-Proxy](Reverse-Proxy).
+
+**How to tell which:** from the machine running the proxy, ask for a session and look at the response headers.
+
+```bash
+curl -i -X POST https://trek.example.com/mcp \
+  -H "Authorization: Bearer <your-token>" \
+  -H "Accept: application/json, text/event-stream" \
+  -H "Content-Type: application/json" \
+  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'
+```
+
+A healthy response contains **both**:
+
+```
+mcp-session-id: 412d245d-1daa-4dfc-b453-eaf266673696
+access-control-expose-headers: Mcp-Session-Id,MCP-Protocol-Version,WWW-Authenticate
+```
+
+If `mcp-session-id` is missing, the proxy is stripping it. If `access-control-expose-headers` is missing, you are on an affected version — upgrade.
+
+On current versions the server also warns on every session-less request, which is the same signal:
+
+```
+[MCP] POST without mcp-session-id for user 1 — starting a new session. If this
+repeats on every tool call, the Mcp-Session-Id response header is not reaching
+the client (check that your reverse proxy forwards it).
+```
+
 ---
 
 ## MCP requests blocked by Cloudflare WAF (Bot Fight Mode)

wiki/Two-Factor-Authentication.md

@@ -1,7 +1,5 @@
 # Two-Factor Authentication
 
-<!-- TODO: screenshot: 2FA setup QR code screen -->
-
 ![2FA](assets/2FA.png)
 
 ## What it is

wiki/Updating.md

@@ -10,9 +10,9 @@ Back up your data first. Go to Admin Panel → Backups and create a manual backu
 
 | Tag | Example | Behavior |
 |---|---|---|
-| `latest` | `mauriceboe/trek:latest` | Always the newest release across all major versions |
-| Major version | `mauriceboe/trek:3` | Latest release pinned to that major version |
-| Full version | `mauriceboe/trek:3.0.15` | Exact release; never changes |
+| `latest` | `mauriceboe/TREK:latest` | Always the newest release across all major versions |
+| Major version | `mauriceboe/TREK:3` | Latest release pinned to that major version |
+| Full version | `mauriceboe/TREK:3.4.0` | Exact release; never changes |
 
 Use `latest` or a major-version tag if you want updates on each redeploy. Use a full version tag for explicit control — update by changing the tag, not by re-pulling.
 
@@ -28,7 +28,7 @@ This pulls the newest matching image and recreates the container with your exist
 
 **Pinned full-version tag:**
 
-Edit `docker-compose.yml`, update the tag in the `image:` line (e.g. `3.0.15` → `3.0.16`), then redeploy:
+Edit `docker-compose.yml`, update the tag in the `image:` line (e.g. `3.4.0` → `3.4.1`), then redeploy:
 
 ```bash
 docker compose up -d
@@ -39,14 +39,14 @@ docker compose up -d
 If you started TREK with `docker run`, pull the new image and replace the container:
 
 ```bash
-docker pull mauriceboe/trek
+docker pull mauriceboe/TREK
 docker rm -f trek
 docker run -d --name trek -p 3000:3000 \
   -v ./data:/app/data \
   -v ./uploads:/app/uploads \
   -e ENCRYPTION_KEY=<your-key> \
   --restart unless-stopped \
-  mauriceboe/trek
+  mauriceboe/TREK
 ```
 
 > **Tip:** Not sure which volume paths you used? Check before removing:
@@ -91,7 +91,7 @@ Open the **Stacks** list, click the TREK stack, then click **Redeploy**.
 
 ![Re-pull image and redeploy switch ticked, with arrows pointing to the switch and the Update button](assets/portainer-force-pull.png)
 
-**Pinned full-version tag** (e.g. `3.0.15`) — edit the stack, update the tag in the `image:` line, then click **Update the stack**. No re-pull switch needed; the tag change forces a fresh pull.
+**Pinned full-version tag** (e.g. `3.4.0`) — edit the stack, update the tag in the `image:` line, then click **Update the stack**. No re-pull switch needed; the tag change forces a fresh pull.
 
 ![Edit stack page with an arrow pointing to the image tag in the compose editor](assets/portainer-update-version.png)
 

wiki/User-Settings.md

@@ -2,11 +2,9 @@
 
 The Settings page lets you personalise every aspect of TREK — appearance, maps, notifications, offline behaviour, and your account.
 
-<!-- TODO: screenshot: user settings page tabs -->
-
 ## Navigating to Settings
 
-Open the user menu in the top navigation bar and select **Settings**. The page opens on the **Display** tab by default.
+Open the user menu in the top navigation bar and select **Settings**. The page opens on the **General** tab by default.
 
 If your account requires MFA setup, TREK redirects you directly to the **Account** tab (via `?mfa=required`).
 
@@ -14,25 +12,42 @@ If your account requires MFA setup, TREK redirects you directly to the **Account
 
 | Tab | Purpose | Shown when |
 |-----|---------|------------|
-| Display | Color mode, language, temperature unit, time format, route calculation, booking route labels, and blur booking codes | Always |
-| Map | Map provider (Leaflet or Mapbox GL), tile presets, Mapbox style and token, 3D buildings, high-quality mode, default map center and zoom | Always |
+| General | Currency, language, temperature unit, distance unit, time format, booking route labels, map POI pills, and blur booking codes | Always |
+| Appearance | Color mode, color scheme / accent, readability (transparency, reduce motion, density, text size), and which widgets appear on your dashboard | Always |
+| Map | Map provider (Leaflet, Mapbox GL, or MapLibre GL), tile presets, map style and Mapbox token, 3D buildings, high-quality mode | Always |
 | Notifications | Email, webhook, ntfy, and in-app notification preferences | Always |
 | Integrations | Photo providers (Immich, Synology, etc.) and MCP OAuth clients / API tokens | Only when the Memories or MCP addon is enabled |
+| Plugins | Per-user settings for installed plugins | Only when at least one plugin is installed |
 | Offline | Cached trips, pending changes, re-sync and clear cache | Always |
 | Account | Username, email, password, MFA (TOTP + backup codes), avatar, delete account | Always |
 | About | App version, links to Ko-fi / Buy Me a Coffee / Discord / GitHub (bug reports, feature requests) / Wiki | Only when version metadata is available |
 
-## Display tab
+## General tab
 
-The Display tab controls the following preferences, all saved immediately on change:
+The General tab controls the following preferences, all saved immediately on change. See [Display-Settings](Display-Settings) for the detail.
 
-- **Color mode** — Light, Dark, or Auto (follows the OS setting).
-- **Language** — Displayed as a button grid on desktop and a dropdown on mobile.
+**Language & region**
+
+- **Currency** — your display currency; **Trip currency** (the default) shows each trip in its own. See [Currencies](Currencies).
+- **Language** — displayed as a button grid on desktop and a dropdown on mobile.
 - **Temperature unit** — Celsius (°C) or Fahrenheit (°F).
+- **Distance unit** — Metric (km) or Imperial (mi).
 - **Time format** — 24h (14:30) or 12h (2:30 PM).
-- **Route calculation** — Enable or disable automatic route calculation between places.
-- **Booking route labels** — Show or hide labels on booking routes on the map.
-- **Blur booking codes** — Blur confirmation codes and reference numbers (useful when screen-sharing).
+
+**Travel & map**
+
+- **Booking route labels** — show or hide station / airport names on booking route endpoint markers.
+- **Explore places on the map** — show a POI category pill on the trip map for finding nearby places from OpenStreetMap.
+- **Blur booking codes** — blur confirmation codes and reference numbers (useful when screen-sharing).
+
+## Appearance tab
+
+- **Color mode** — Light, Dark, or Auto (follows your operating system / browser preference).
+- **Color scheme** — a preset accent, or **Custom** with your own light and dark accent colors.
+- **Readability** *(Experimental)* — transparency, reduce motion, density, and text size.
+- **Dashboard widgets** — which widgets appear on the dashboard, independently for desktop and mobile.
+
+See [Appearance-Settings](Appearance-Settings) for the detail.
 
 ## Map tab
 
@@ -44,13 +59,18 @@ The Map tab requires an explicit **Save** action after making changes.
 - **Mapbox GL** (Experimental) — Vector tiles with 3D buildings and terrain. Requires a public Mapbox access token (`pk.*`). Supports built-in style presets (Mapbox Standard, Standard Satellite, Streets, Outdoors, Light, Dark, Satellite, Satellite Streets, Navigation Day, Navigation Night) or a custom `mapbox://styles/USER/ID` URL. Additional options:
   - **3D Buildings & Terrain** — Pitch and real 3D building extrusions (works on every style including satellite).
   - **High Quality Mode** (Experimental) — Antialiasing + globe projection for sharper edges. May impact performance on lower-end devices.
+- **MapLibre GL** — Vector tiles from **OpenFreeMap**, and the reason to pick it over Mapbox GL: **it needs no access token**. Styles are OpenFreeMap Liberty, Bright, and Positron, or any `https://tiles.openfreemap.org/…` style URL. The 3D and high-quality toggles are Mapbox-only and are not shown here.
+
+Each GL provider keeps its own saved style, so switching between Mapbox GL and MapLibre GL never overwrites the other one's choice.
 
 > Atlas always uses Leaflet regardless of the provider setting.
 
-**Default map position** — Set the default latitude, longitude, and zoom level. You can also click directly on the map preview to set the center.
+**Opening view** — there is no default map center or zoom setting. Every map frames itself on the places it is showing. See [Map-Settings](Map-Settings).
 
 ## Account tab summary
 
+![Settings page on the Account tab, with the settings tab rail on the left and username, email, change-password fields and the two-factor authentication section on the right](assets/SettingsAccount.png)
+
 The Account tab lets you:
 
 - Edit your **username** and **email address**.
@@ -74,6 +94,7 @@ The Integrations tab is only visible when the **Memories** or **MCP** addon is e
 ## See also
 
 - [Display-Settings](Display-Settings)
+- [Appearance-Settings](Appearance-Settings)
 - [Map-Settings](Map-Settings)
 - [Notifications](Notifications)
 - [Offline-Mode-and-PWA](Offline-Mode-and-PWA)

wiki/Vacay.md

@@ -4,8 +4,6 @@ Vacay is a personal vacation day planner that lives separately from your trip pl
 
 > **Admin:** enable Vacay in [Admin-Addons](Admin-Addons).
 
-<!-- TODO: screenshot: vacation planner calendar view -->
-
 ![Vacay screenshot](assets/Vacay.png)
 
 ## What Vacay is

wiki/Weather-Forecasts.md

@@ -2,8 +2,6 @@
 
 TREK shows weather forecasts and historical climate estimates for each day in your trip, powered by Open-Meteo — no API key required.
 
-<!-- TODO: screenshot: weather forecast card on a trip day -->
-
 ![Weather forecasts](assets/Weather.png)
 
 ## Where forecasts appear

wiki/Whats-Next-Widget.md

@@ -2,9 +2,7 @@
 
 The What's Next widget shows the upcoming assigned places across all days of your trip at a glance — useful for quickly orienting the group before heading out.
 
-<!-- TODO: screenshot: What's Next widget showing upcoming events -->
-
-![What's Next widget](assets/Collab.png)
+![The What's Next widget listing the next scheduled activities per day](assets/WhatsNext.png)
 
 ## Where to find it
 

wiki/_Footer.md

@@ -1 +1 @@
-[AGPL-3.0 License](https://github.com/mauriceboe/TREK/blob/main/LICENSE) · [GitHub](https://github.com/mauriceboe/TREK) · [Discord](https://discord.gg/NhZBDSd4qW) · [Security Hardening](Security-Hardening)
+[AGPL-3.0 License](https://github.com/liketrek/TREK/blob/main/LICENSE) · [GitHub](https://github.com/liketrek/TREK) · [Discord](https://discord.gg/NhZBDSd4qW) · [Security Hardening](Security-Hardening)

wiki/_Sidebar.md

@@ -15,9 +15,11 @@
 - [[Login and Registration|Login-and-Registration]]
 - [[OIDC SSO|OIDC-SSO]]
 - [[Two-Factor Authentication|Two-Factor-Authentication]]
+- [[Passkeys]]
 - [[Password Reset|Password-Reset]]
 - [[User Settings|User-Settings]]
-- [[Display Settings|Display-Settings]]
+- [[General Settings|Display-Settings]]
+- [[Appearance Settings|Appearance-Settings]]
 - [[Map Settings|Map-Settings]]
 - [[Notifications]]
 - [[Offline Mode and PWA|Offline-Mode-and-PWA]]
@@ -39,12 +41,14 @@
 - [[AI Booking Import|AI-Booking-Import]]
 - [[Transport: Flights, Trains, Cars|Transport-Flights-Trains-Cars]]
 - [[Accommodations]]
-- [[Budget Tracking|Budget-Tracking]]
+- [[Costs|Budget-Tracking]]
+- [[Currencies]]
 - [[Packing Lists|Packing-Lists]]
 - [[Packing Templates|Packing-Templates]]
 - [[Todos and Tasks|Todos-and-Tasks]]
 - [[Documents and Files|Documents-and-Files]]
 - [[Tags and Categories|Tags-and-Categories]]
+- [[Calendar Feeds|Calendar-Feeds]]
 
 ## Photos & Media
 - [[Photo Providers|Photo-Providers]]
@@ -89,6 +93,7 @@
 - [[Admin: Categories|Admin-Categories]]
 - [[Admin: Packing Templates|Admin-Packing-Templates]]
 - [[Admin: Permissions|Admin-Permissions]]
+- [[Admin: Plugins|Admin-Plugins]]
 - [[Admin: MCP Tokens|Admin-MCP-Tokens]]
 - [[Admin: GitHub Releases|Admin-GitHub-Releases]]
 
@@ -101,6 +106,7 @@
 - [[Security Hardening|Security-Hardening]]
 
 ## Help
+- [[In-App Help|In-App-Help]]
 - [[FAQ]]
 - [[Troubleshooting]]