mulmoclaude 1.23.0 → 1.25.0

package/README.md

@@ -122,6 +122,8 @@ npx @mulmobridge/email@latest        # Email (IMAP + SMTP)
 
 Full bridge list and platform-specific setup: <https://github.com/receptron/mulmoclaude/blob/main/docs/mulmobridge-guide.md>
 
+**Long turns.** A bridge turn gets 5 minutes by default; after that the server replies with what it has so far. Set the limit on the bridge in milliseconds — `BRIDGE_REPLY_TIMEOUT_MS` for every bridge, `<TRANSPORT>_BRIDGE_REPLY_TIMEOUT_MS` for one (e.g. `DISCORD_BRIDGE_REPLY_TIMEOUT_MS=1800000`). It reaches the server in the handshake, so both sides use the same value; needs `@mulmobridge/client@1.4.0` or later.
+
 ### Auth token persistence across server restarts
 
 The server regenerates a fresh bearer token on every startup and writes it to `<workspace>/.session-token` (`$MULMOCLAUDE_WORKSPACE_PATH`, or `~/mulmoclaude` when unset), alongside the port it bound in `.server-port`.
@@ -158,7 +160,7 @@ Recommended: ≥ 32 characters of random data (shorter values trigger a startup
 - **Auto memory** — the agent maintains a typed memory layout (`conversations/memory/<type>/<topic>.md`) and reads it ambient-style.
 - **Web Push on task finish** — enable in Settings → Notifications to get a push on your phone when the answer to a question you asked is ready, even with the browser closed. Requires the RemoteHost connection + a registered device (see [`docs/remote-host.md`](https://github.com/receptron/mulmoclaude/blob/main/docs/remote-host.md#web-push-on-task-finish-2086)).
 - **Google (Calendar / Tasks / Drive)** — link your Google account in Settings → Plugins → Google and consent in the browser; no Google Cloud setup needed. The agent then gets a `google` tool covering the full round trip — list, create, edit and delete calendar events and tasks (including putting a completed task back on the list), plus the Drive files it creates — and the phone remote can trigger the same commands. Events can be timed or **all-day**: ask for a whole day and you get one, rather than a midnight appointment.
-- **Google Calendar ↔ collection sync** — a collection can mirror one of your calendars and keep itself current: the first sync starts as soon as you ask for the collection, an hourly pass follows, and a Sync button forces one. It calls the Calendar API directly rather than routing the events through the agent, so keeping it fresh costs no tokens. A **Push to Google** button beside it sends the other way, creating events for records you added and updating ones you edited — it skips anything edited on both sides rather than picking a winner. It does not delete unless you ask it to: a collection can opt in so that removing a record removes the event, and even then it refuses any event with attendees rather than withdrawing it from their calendars. Ask for **two-way sync** and the collection pushes on the same schedule it pulls on, as one cycle, so there is no button to forget; a record the push could not send is then left alone by the pull instead of being overwritten. Without it the pull is automatic and the push is a button, so push before you sync — a pull overwrites a locally edited record as soon as Google reports a change to that event. Event **notes and location** travel in both directions alongside the title, times and colour, and the mirror can also carry read-only details — your own RSVP, the meeting link, and which recurring series an occurrence came from. **The refresh token stays on your machine** (`~/.config/mulmo/`) — the sign-in service applies the OAuth client secret Google requires and keeps nothing. Prefer your own OAuth client? Drop a *desktop-app* client JSON in `~/.secrets/` and the whole flow stays local (see [`docs/remote-host.md`](https://github.com/receptron/mulmoclaude/blob/main/docs/remote-host.md)).
+- **Google Calendar ↔ collection sync** — a collection can mirror one of your calendars and keep itself current: the first sync starts as soon as you ask for the collection, an hourly pass follows, and a Sync button forces one. It calls the Calendar API directly rather than routing the events through the agent, so keeping it fresh costs no tokens. A **Push to Google** button beside it sends the other way, creating events for records you added and updating ones you edited — it skips anything edited on both sides rather than picking a winner. It does not delete unless you ask it to: a collection can opt in so that removing a record removes the event, and even then it refuses any event with attendees rather than withdrawing it from their calendars. Ask for **two-way sync** and the collection pushes on the same schedule it pulls on, as one cycle, so there is no button to forget; a record the push could not send is then left alone by the pull instead of being overwritten. Without it the pull is automatic and the push is a button, so push before you sync — a pull overwrites a locally edited record as soon as Google reports a change to that event. A record you add can be an **all-day** event: write just the date (`2026-09-28`) in its start and end. Event **notes and location** travel in both directions alongside the title, times and colour, and the mirror can also carry read-only details — your own RSVP, the meeting link, and which recurring series an occurrence came from. **The refresh token stays on your machine** (`~/.config/mulmo/`) — the sign-in service applies the OAuth client secret Google requires and keeps nothing. Prefer your own OAuth client? Drop a *desktop-app* client JSON in `~/.secrets/` and the whole flow stays local (see [`docs/remote-host.md`](https://github.com/receptron/mulmoclaude/blob/main/docs/remote-host.md)).
 
 ## Plugin authoring (`--dev-plugin`)