@llblab/pi-telegram 0.25.6 → 0.26.0

package/AGENTS.md

@@ -89,7 +89,7 @@ The core product loop is mobile continuation: start or supervise work in the ter
 - Instance thread names are provisioner-authored identity metadata, not model-authored output. Fresh Threaded Mode threads select one of five curated compact 4-6 letter Latin names for the assigned slot letter using provisioning timestamp entropy, then create the Telegram thread with that thread name immediately. The title is the thread name itself, not `{slot} {threadName}` or `{slot} — {threadName}`. Do not register or reintroduce an agent-facing thread rename tool; removing the extra rename prompt/tool turn is an intentional simplicity constraint. Thread names must mirror into terminal status, live diagnostics, and `[telegram|thread:name]` through one target-aware current-instance identity resolver. Registered follower/leader metadata takes precedence over a stale shared record for the same target, with the record used only as fallback; do not hide a valid baked/custom thread name behind old slot-prefix validation. A follower that later becomes leader keeps its existing name; leadership changes are transport role changes, not identity resets.
 - Telegram private-chat Threaded Mode treats `All` as an aggregate/control surface, not a durable `General` thread or process launcher, and leader activation proactively creates or reuses its private-DM thread. When the owner writes in an unknown thread, the leader reclaims and routes the first one only if it lacks an active binding; later unknown threads remain intact and receive an in-thread chooser to reroute the captured prompt or restore a stale binding. Destructive cleanup requires explicit confirmation through `thread-reconciler`; another Pi instance still requires a manually started process followed by `/telegram-connect`. Without Threaded Mode, process the message through classic routing.
 - Telegram extension work should not hold Pi's core agent lifecycle hostage once Pi has produced the semantic result. For Telegram-originated turns, final Telegram delivery, attachment upload, and transport cleanup are extension-owned side effects; schedule them off the critical `agent_end` path when ordering can still be preserved, record failures as runtime events, and keep dispatch of the next Telegram turn behind the delivery task when needed to avoid interleaving previews/finals. Treat a low-level error `agent_end` as retryable while its Telegram turn remains active; only a later successful `agent_end` or Pi's `agent_settled` boundary may finalize and release that turn. Public activity handlers run through isolated asynchronous per-handler queues; lifecycle hooks enqueue normalized events and never await consumer work. Proactive push defaults enabled and requires explicit `assistant.proactivePush: false` to opt out. While enabled, core delivery projects each completed Pi-visible assistant text block from local/autonomous work once and in order; bind admitted blocks to the exact target, profile/token transport stamp, direct leader epoch or follower registration generation, and session generation. Token deltas, hidden reasoning, tool traffic, stale authority, and Telegram-owned turns never enter that projection.
-- Core thinking/tool visibility is controlled by `assistant.activity: "quiet" | "thinking" | "tools" | "verbose"`. It remains separate from proactive public prose and assistant Markdown: provider-exposed thinking and completed executed tools use durable ordinary HTML messages with standard expandable blockquotes and never use Rich Messages. Thinking uses the `🧠` header with the current Pi thinking level instead of a generic lifecycle status and renders inline Markdown as Telegram HTML inside its expandable blockquote; tools use `🛠`, `verbose` enables both, and every activity send/edit disables Telegram link previews while technical evidence also neutralizes HTTP(S) auto-link detection as a client-safe fallback. Keep it quiet by default, exact-target/transport-generation fenced, start-order preserving, boundary-aware, memory/transport bounded, and non-blocking; final delivery waits for admitted technical activity only inside the extension-owned background task, and session replacement abandons queued old-generation work without waiting on old transport. Read legacy `assistant.activityVerbosity` only when `assistant.activity` is absent and remove it on the next Settings write. Never invent unavailable provider-private thinking or replay a possibly committed technical message.
+- Core thinking/tool visibility is controlled by file-backed `assistant.activity: "quiet" | "thinking" | "tools" | "verbose"`; every Pi instance reloads the shared config at `agent-start` before admitting activity so process-local cache cannot broaden the selected class. It defaults to `verbose` when absent and remains separate from proactive public prose and assistant Markdown: provider-exposed thinking uses durable ordinary HTML with a standard expandable blockquote, while completed executed tools use native Rich Messages with separate closed details and JSON pre blocks for arguments, retained updates, and result/error evidence. Thinking uses the sentence-case `🧠  Thinking: <level>` header with the current Pi thinking level instead of a generic lifecycle status and renders inline Markdown as Telegram HTML inside its expandable blockquote; tools use sentence-case `🛠  <Tool>: <status>` headers, `verbose` enables both, and every activity send/edit disables Telegram link previews while technical evidence also neutralizes HTTP(S) auto-link detection as a client-safe fallback. Keep it quiet by default, exact-target/transport-generation fenced, start-order preserving, boundary-aware, memory/transport bounded, and non-blocking; final delivery waits for admitted technical activity only inside the extension-owned background task, and session replacement abandons queued old-generation work without waiting on old transport. Read legacy `assistant.activityVerbosity` only when `assistant.activity` is absent and remove it on the next Settings write. Never invent unavailable provider-private thinking or replay a possibly committed technical message.
 - Telegram runtime state should be treated as event-driven reconciliation of extension assumptions against observable Telegram signals, not as a full Telegram bot read-model and not as a reason to query Telegram on every action. Keep a local assumption model for bot identity/capabilities, pairing assumptions, thread support, known thread lifecycle, bound instance targets, reservations, and transport health. Invalidate and reconcile the relevant slice on meaningful events: startup/reload, lifecycle service messages, stale-send/API errors, setup/pairing changes, follower register/prune, explicit status/debug requests, and bounded low-frequency leader health ticks. `lib/sync.ts` owns sync slices, observation intake, invalidation triggers, status/debug freshness, and reconciliation scheduling; it must not promise complete bot-state mirroring because Bot API lacks a complete topic listing surface. `lib/thread-reconciler.ts` owns pure Threaded Mode lifecycle planning and should become the only policy authority for destructive thread cleanup decisions. `threads` owns current Telegram UI thread/tab binding primitives and thread-name helpers mapped to Bot API topic transport, `status` renders projections, and `index.ts` only wires ports. `tmp/telegram/logs.jsonl` is a session-local redacted runtime evidence stream for race debugging and resets on extension start / runtime scope changes; it is diagnostics only, not routing/provisioning authority. `state.json` should be an observable/debug snapshot aligned with `/telegram-status` (extension runtime, bot capabilities including `bot.lastSlot`, runtime role, live roster projection, reservations, diagnostics), not routing/provisioning authority. Because every process on one Telegram profile shares this file, only the active transport lock owner may persist it; followers read current state and gain write authority only after promotion. Status-only writes must refresh disk-backed bindings before serialization so a stale loaded snapshot cannot erase newer leader state. Live bus/runtime state is authoritative; file reservations and fresh capability observations may be startup hints/collision guards only; stale snapshots must re-probe before suppressing bus/topic behavior. Do not persist stale/offline/failed thread target history as source of truth.
 - Thread bindings are bidirectional. From the Pi-instance side, an instance knows and preserves its target, slot, thread name, lifecycle state, and direct-delivery defaults. From the Telegram-client/bot side, the bridge observes thread creation/close/reopen/stale-send signals and reconciles them into instance binding state. Lifecycle transitions that affect operator understanding should be Telegram-visible when a live transport remains: every successful follower registration/re-registration gets a compact connected notice in the assigned thread, while heartbeat pruning stays silent because it is only liveness suspicion. These notices should use the instance thread name when known and fall back to the slot letter only while the thread is still unnamed. New unknown or command-created temporary threads receive the complete forward plus replace/restore control set and remain preserved until the user chooses one. Successful forward deletes the chooser and temporary thread; successful replace/restore always deletes the chooser, rebinds the temporary thread, and deletes only the replaced old thread. Any destructive cleanup must go through `thread-reconciler`. Unknown `forum_topic_created` service events are observations, not destructive cleanup proof.
 - The multi-instance bus uses private bot DMs with Telegram private-chat Threaded Mode enabled for the bot. No supergroup, group, or forum configuration is needed; the thread chat is always the private chat with the paired owner. Threaded capability checks must use bot/private-chat evidence such as `getMe.has_topics_enabled`, incoming `message_thread_id`, and topic operation success/failure; do not use group chat metadata as the control-plane truth for Telegram private-chat Threaded Mode.
@@ -121,7 +121,7 @@ The core product loop is mobile continuation: start or supervise work in the ter
 - Forward-annotation grouping distinguishes two semantic layers: the forward owns its source text/caption/media, while an optional separate owner-authored annotation normally arrives immediately before it. Use a bounded one-second candidate window in both transport orders: ordinary short human text may wait for an adjacent same-sender/chat/thread forward, and a forwarded message—including a media-only forward with no source caption—may wait for one adjacent owner annotation. A matching opposite-kind message flushes immediately; same-kind messages, commands, bots, ordinary non-forward captions, media groups, target/sender mismatches, reversed ids, and distant ids stay separate. Preserve the candidate across session replacement and follower forwarding without weakening exact routing-generation authority.
 - `telegram_voice` and `telegram_button` are not Pi tools; keep prompts/docs explicit that agents should author markup while voice synthesis provider extensions own TTS/OGG conversion, and pi-telegram owns button routing plus Telegram delivery
 - Voice reply policy and prompt context are owned by pi-telegram's `telegram.json` `voice.replyMode`: missing, invalid, `hidden`, and legacy `manual` config resolve to `hidden` and add no `[voice]` context; `mirror` adds `[voice] delivery: automatic voice` only for voice/audio input, while `always` adds that same single factual line to every Telegram turn. Place voice context after `[outputs]` when handler output exists, otherwise after `[attachments]`; provider prompt contributions are optional provider-specific additions, not the default policy or delivery-composition channel.
-- Optional Telegram wall-clock context may add `[time] YYYY-MM-DD HH:mm:ss <timezone>` to Telegram-originated prompts. It is hidden by default, uses `assistant.timeInjection` values `hidden|always|interval`, stores the interval duration separately as `time.interval` in milliseconds, uses the system timezone, and should render last after `[attachments]`, `[outputs]`, and `[voice]` sections. The Settings row `🕒 Time injection: hidden|always|interval` controls only `assistant.timeInjection`; the old `time.injectionMode` key is ignored and is not migrated.
+- Optional Telegram wall-clock context may add `[time] YYYY-MM-DD HH:mm:ss <timezone>` to Telegram-originated prompts. It defaults to `interval` without migrating explicit settings, uses `assistant.timeInjection` values `hidden|always|interval`, stores the interval duration separately as `time.interval` in milliseconds, uses the system timezone, and should render last after `[attachments]`, `[outputs]`, and `[voice]` sections. The Settings row `🕒 Time injection: hidden|always|interval` controls only `assistant.timeInjection`; the old `time.injectionMode` key is ignored and is not migrated.
 - Agent activity status is native-only for the release path: Telegram uses `sendChatAction(typing)` and renders its native `…typing` indicator as the automatic work signal. When a connected instance starts any real agent run, send that indicator to the instance's own thread (and aggregate `All` surface), including Telegram turns, local/TUI prompts, and autonomous continuations such as Grow Loop; stop it at agent/session completion. Keep at most one chat action in flight per loop, coalesce identical leader-side actions across follower traffic, and treat Telegram 429 `retry_after` as a shared suppression window rather than a delayed retry or persistent terminal error. This signal is independent from terminal `Active`, which remains scoped to Telegram-owned turns. Confirmed manual `/compact` and automatic compaction tied to an active Telegram turn also use native activity. Do not send activity merely for startup/connect/reload/recovery or add extra in-chat work surfaces without a new explicit design decision.
 - Voice reply mode Settings UI standard: the top-level Settings row is `👄 Voice reply: hidden|mirror|always`; `hidden` is the true default, persists no `voice.replyMode`, adds no voice context, and still allows explicit agent-authored `telegram_voice`; `mirror` activates automatic voice context only for voice/audio input, and `always` activates it for every Telegram turn. The submenu title is `👄 Voice reply mode:`; choice buttons use lowercase labels with a model-style active dot (`🟢 hidden`, `🟢 mirror`) rather than per-mode emoji; the explanatory submenu body uses compact HTML-code bullets such as `<code>-</code> <code>hidden</code> (default): ...`. Preserve this wording/icons unless the operator explicitly asks to redesign it
 - Outbound voice delivery is one fallback pipeline: configured `outboundHandlers` with `type: "voice"` run first in `telegram.json` order, then programmatic voice handlers, then registered voice synthesis providers as zero-config progressive fallbacks; provider extensions must not override operator-configured handlers

package/BACKLOG.md

@@ -2,9 +2,24 @@
 
 _This backlog tracks only open release-relevant work: hotfixes, bounded maintenance, live runtime verification, evidence-gated Telegram client follow-ups, and upstream Pi API blockers. Completed outcomes and validation evidence belong in `CHANGELOG.md`, not in this queue._
 
+## P0 — Rich Tool Activity And Discoverable Defaults Release
+
+Context: Thinking keeps its current persistent HTML expandable quote. Tool activity moves to native Rich Messages so arguments, retained updates, and result/error evidence become separate collapsed details containing compact JSON code blocks. New installations should discover context and activity features through `assistant.timeInjection: "interval"` and `assistant.activity: "verbose"` defaults without migrating explicit existing settings.
+
+Open work:
+
+- [x] Render completed tool batches through `sendRichMessage` / `editMessageText.rich_message` with one sentence-case tool header followed by separate closed `Arguments`, `Update N`, and `Result`/`Error` details containing `json` pre blocks.
+- [x] Preserve tool ordering, coalescing, redaction, truncation, dropped-update evidence, transport/authority fencing, message bounds, final-answer ordering, and commit-unknown no-replay behavior; use the existing HTML representation only for a known-safe Rich capability rejection.
+- [x] Change absent Activity mode to `verbose` and absent time injection mode to `interval` with the existing one-hour interval fallback; preserve every explicit stored value without migration.
+- [x] Update tests, README, technical docs, durable project rules, changelog, and package metadata for the final behavior.
+- [ ] Publish and verify GitHub/npm release evidence for `0.26.0`.
+- [ ] Live-smoke Rich tool details on Telegram mobile and Desktop in classic and Threaded Mode, including multi-tool batches, updates, truncation, failures, follower transport, and final-answer ordering.
+
+Done when: native Rich tool activity is compact and logically segmented, explicit settings remain authoritative, new defaults are discoverable, automated validation passes, live clients confirm the rendering/routing contract, and the release is published through the repository release flow.
+
 ## P1 — Configurable Activity Live Smoke
 
-Context: configurable activity now offers quiet, thinking-only, tools-only, and verbose modes. Thinking and tools use persistent collapsed ordinary HTML messages instead of draft-only Rich Thinking blocks.
+Context: configurable activity offers quiet, thinking-only, tools-only, and verbose modes. Thinking uses persistent collapsed ordinary HTML instead of draft-only Rich Thinking blocks; completed tools use native Rich details with JSON code blocks.
 
 Open work:
 

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## 0.26.0: Rich Tool Activity
+
+- `Tool Presentation`: Moved completed tool batches from one ordinary HTML expandable quote to native Rich Messages. Each sentence-case tool header now precedes separate closed `Arguments`, retained `Update N`, and `Result`/`Error` details containing compact JSON code blocks; dropped-update counts remain visible in the first retained update summary. Thinking keeps its distinct persistent HTML expandable quote. Impact: technical history becomes easier to scan, tool phases no longer compete inside one large JSON disclosure, and thinking remains optimized for prose.
+- `Activity Safety`: Preserved tool-start ordering, batch coalescing, redaction, per-field truncation, target and generation fencing, final-answer ordering, and no replay after ambiguous sends. Rich activity disables entity detection; a known-safe Rich HTTP 400 rejection falls back once to the previous HTML representation. Impact: the richer UI retains the existing bounded privacy and transport guarantees without duplicate technical messages.
+- `Discoverable Defaults`: Changed absent `assistant.activity` to `verbose` and absent `assistant.timeInjection` to `interval` with the existing one-hour interval fallback. Explicit stored settings remain authoritative and receive no migration. Impact: new installations discover technical activity and periodic wall-clock context immediately, while existing operator choices remain unchanged.
+
+## 0.25.7: Multi-Instance Activity Isolation Hotfix
+
+- `Activity Config`: Reloaded the shared file-backed `assistant.activity` setting in every Pi process at `agent-start` before activity admission, failing closed for that run if refresh fails. Impact: selecting `thinking` emits only thinking, selecting `tools` emits only tools, `verbose` emits both, and `quiet` emits neither across all live instances instead of stale process-local config behaving like an older broader mode.
+- `Activity Labels`: Capitalized human-facing technical headers as `🧠  Thinking: <level>` and `🛠  <Tool>: <status>`. Impact: persistent activity messages follow the same sentence-case UI convention as menus and settings.
+
 ## 0.25.6: Same-Profile Thread Reuse Hotfix
 
 - `Leader Restart`: Deferred a pending leader cleanup when its target still belongs to the replacement's active stable profile, restored that existing binding first, and then cancelled the superseded cleanup intent. Unrelated cleanup intents still execute before provisioning. Impact: an interrupted graceful shutdown no longer causes the next launch of the same Pi instance to delete and recreate its reusable Telegram thread.

package/README.md

@@ -8,7 +8,7 @@
 
 It is a **runtime adapter**, not a remote terminal. Start or supervise work in the Pi TUI, then continue from Telegram while away from the keyboard. Each Telegram destination follows a running Pi instance and sends prompts into that instance's currently active session; it is not permanently bound to one session file or session identity. The bridge preserves Pi session semantics instead of pretending Telegram is a PTY, shell, process launcher, or session browser. That boundary is the product: Telegram gets safe runtime handles, not raw terminal power.
 
-Proactive push is enabled by default. `assistant.proactivePush` projects every completed public assistant text block from local or autonomous work—including visible checkpoints and the final answer—to the authorized Telegram target once and in order; set it explicitly to `false` to disable projection. Proactive push itself never mirrors local prompts, thinking, tool traffic, token deltas, Telegram-owned turns, or stale-generation work. The separate quiet-by-default `Activity` setting can persist collapsed provider-exposed thinking, tool evidence, or both. See [Outbound](docs/outbound.md#proactive-public-output) and the [configuration reference](docs/public-api.md#configuration-api).
+Proactive push is enabled by default. `assistant.proactivePush` projects every completed public assistant text block from local or autonomous work—including visible checkpoints and the final answer—to the authorized Telegram target once and in order; set it explicitly to `false` to disable projection. Proactive push itself never mirrors local prompts, thinking, tool traffic, token deltas, Telegram-owned turns, or stale-generation work. The separate `Activity` setting defaults to `verbose` so new installations discover collapsed provider-exposed thinking and tool evidence immediately; operators can narrow it to one class or choose `quiet`. See [Outbound](docs/outbound.md#proactive-public-output) and the [configuration reference](docs/public-api.md#configuration-api).
 
 This repository is an actively maintained fork of [`badlogic/pi-telegram`](https://github.com/badlogic/pi-telegram). It started from upstream commit [`cb34008`](https://github.com/badlogic/pi-telegram/commit/cb34008460b6c1ca036d92322f69d87f626be0fc) and has since diverged substantially.
 
@@ -101,9 +101,9 @@ The first Telegram user to message the bot becomes the allowed owner. Other user
 | Model and thinking | Switch model or thinking level from Telegram through safe continuation flows. | Mobile control can adjust execution strategy without tearing down the current session. |
 | Compaction | Confirm `/compact`, show native active status during compaction, and preserve Telegram-owned turn semantics. | Context maintenance is visible and safe from the phone. |
 | Draft previews | Show Telegram's native `…typing` indicator whenever the connected instance is doing agent work, or enable Rich Draft previews for streamed answer text. | Local prompts, Telegram turns, and autonomous continuations remain visibly active while draft visibility stays independent from final rendering. |
-| Activity | Keep the default `quiet` answer-only surface, show only `thinking`, show only `tools`, or select `verbose` for both. Thinking headers report the current Pi thinking level instead of a generic completion state. | Persistent collapsed technical activity stays bounded, redacted, target-fenced, density-aware, free of URL previews, and visually separate from semantic assistant answers. |
+| Activity | Keep the default `verbose` technical surface, show only `thinking`, show only `tools`, or select `quiet` for answer-only delivery. Every instance reloads this shared file-backed choice before a new agent run, and thinking headers report the current Pi thinking level instead of a generic completion state. | Persistent collapsed technical activity uses sentence-case headers and stays bounded, redacted, target-fenced, density-aware, free of URL previews, and visually separate from semantic assistant answers. |
 | Assistant rendering | Choose Native Rich Markdown or legacy Markdown-to-HTML for final assistant replies. | Renderer compatibility is explicit instead of being conflated with draft previews. |
-| Bridge UI rendering | Render thinking and tool activity through ordinary expandable HTML messages, including inline emphasis/code formatting for thinking evidence, and menus, queue controls, status, settings, diagnostics, and sections through Telegram HTML/plain UI. | Harness-owned surfaces remain operationally predictable and visually distinct from model-authored answers. |
+| Bridge UI rendering | Render thinking through ordinary expandable HTML with inline emphasis/code, render tools through native Rich details with JSON code blocks, and keep menus, queue controls, status, settings, diagnostics, and sections on Telegram HTML/plain UI. | Harness-owned surfaces remain operationally predictable and visually distinct from model-authored answers. |
 | Inbound files | Download inbound files to the Pi agent temp directory with size limits. | Screenshots, PDFs, datasets, and artifacts enter Pi as inspectable local files. |
 | Outbound artifacts | Return generated files through `telegram_attach` during active turns or explicit direct delivery. | Agents send real artifacts as files, not pasted blobs. |
 | Voice input | Route audio through configured command-template handlers, programmatic handlers, or STT providers. | Voice notes become usable prompt context. |
@@ -172,7 +172,7 @@ Messages sent while Pi is busy become queued turns. Priority lanes support contr
 
 ### Native Rich Markdown
 
-Rich Markdown is the default model-answer membrane. Complete assistant and guest model replies use Telegram's native Rich Message APIs. Activity thinking and completed tools use persistent ordinary HTML messages with standard expandable blockquotes and never Rich Messages; `thinking`, `tools`, and `verbose` select the visible classes, while menus, status rows, queue controls, settings, diagnostics, and other operational UI retain explicit Telegram HTML/plain rendering. Three Settings controls keep the layers separate: `Draft previews` toggles streamed answer drafts, `Activity` chooses `quiet` or `verbose` technical activity, and `Assistant rendering` chooses final-answer delivery (`rich` Native Rich Markdown or `html` legacy Markdown-to-HTML).
+Rich Markdown is the default model-answer membrane. Complete assistant and guest model replies use Telegram's native Rich Message APIs. Activity thinking uses persistent ordinary HTML with a standard expandable blockquote, while completed tools use native Rich details with JSON code blocks; `thinking`, `tools`, and `verbose` select the visible classes, while menus, status rows, queue controls, settings, diagnostics, and other operational UI retain explicit Telegram HTML/plain rendering. Three Settings controls keep the layers separate: `Draft previews` toggles streamed answer drafts, `Activity` chooses `quiet` or `verbose` technical activity, and `Assistant rendering` chooses final-answer delivery (`rich` Native Rich Markdown or `html` legacy Markdown-to-HTML).
 
 ### Files And Artifacts
 
@@ -215,7 +215,7 @@ Most controls live in Pi commands or the Telegram menu. Environment variables re
 | Inbound file limit | `PI_TELEGRAM_INBOUND_FILE_MAX_BYTES`, `TELEGRAM_MAX_FILE_SIZE_BYTES` |
 | Outbound attachment limit | `PI_TELEGRAM_OUTBOUND_ATTACHMENT_MAX_BYTES`, `TELEGRAM_MAX_ATTACHMENT_SIZE_BYTES` |
 
-Defaults are chosen for ordinary private-bot use: saved config in `~/.pi/agent`, inbound temp files in `~/.pi/agent/tmp/telegram`, `assistant: { rendering: "rich", draftPreviews: false, activity: "quiet" }` for assistant output and activity, and native Telegram active status for long-running turns.
+Defaults are chosen for ordinary private-bot use: saved config in `~/.pi/agent`, inbound temp files in `~/.pi/agent/tmp/telegram`, `assistant: { rendering: "rich", draftPreviews: false, activity: "verbose", timeInjection: "interval" }` for assistant output and activity, and native Telegram active status for long-running turns.
 
 ## Extension Platform
 

package/docs/activity.md

@@ -180,7 +180,7 @@ Pi provider events use `thinking_*`; the public product term is `reasoning`. The
 
 Tool activity uses Pi's executed-tool lifecycle (`tool_execution_start/update/end`), not provider `toolcall_*` payloads. Provider tool-call boundaries are used only to classify preceding assistant prose. This prevents duplicate tool rows and reports actual execution results.
 
-`args`, `update`, and `result` may contain paths, source text, command output, or other sensitive data. They are available to trusted local extension code but must not be rendered wholesale by default. Core `quiet` mode renders none of them. Explicit `verbose` mode redacts known secret shapes, truncates every evidence field, and places completed tool evidence in ordinary HTML messages with standard expandable blockquotes rather than Rich Messages.
+`args`, `update`, and `result` may contain paths, source text, command output, or other sensitive data. They are available to trusted local extension code but must not be rendered wholesale by default. Core `quiet` mode renders none of them. Visible tool modes redact known secret shapes, truncate every evidence field, and place completed tool evidence in native Rich Messages with separate closed Arguments/Update/Result/Error details containing JSON pre blocks.
 
 ## Delivery Context
 
@@ -291,7 +291,7 @@ The implementation must cover:
 
 ## Core Verbosity And Consumer Policy
 
-The bridge owns a global `quiet`/`thinking`/`tools`/`verbose` policy. Quiet is the default, `thinking` and `tools` select one technical class, and `verbose` enables both. Available thinking and bounded tool evidence use persistent ordinary HTML messages with expandable blockquotes without changing public assistant-segment projection or final replies.
+The bridge owns a global `quiet`/`thinking`/`tools`/`verbose` policy. `verbose` is the absent-config default, `thinking` and `tools` select one technical class, and `quiet` disables both. Available thinking uses persistent ordinary HTML with an expandable blockquote; bounded tool evidence uses native Rich details without changing public assistant-segment projection or final replies.
 
 The registration and delivery examples above remain the public building blocks for companion-specific policy:
 

package/docs/architecture.md

@@ -256,7 +256,7 @@ At every connected instance `agent_start`, the lifecycle binding starts Telegram
 
 ### Rendering And Delivery
 
-Rich Markdown is the default model-answer membrane. Complete assistant replies send final Markdown directly as `InputRichMessage.markdown` through `sendRichMessage` when `assistant.rendering` is `rich`, and through the legacy Markdown-to-HTML renderer when `assistant.rendering` is `html`; guest replies use native Rich Markdown through `InputRichMessageContent` in `answerGuestQuery` results. Tool-call rows, reasoning/thinking blocks, menus, status rows, queue controls, settings, diagnostics, and other harness-owned surfaces stay on explicit Telegram HTML/plain rendering. Streaming previews may use `sendRichMessageDraft` only when `assistant.draftPreviews` is enabled and draft delivery succeeds. The bridge still strips top-level assistant action comments before delivery and may split output only for Telegram transport limits.
+Rich Markdown is the default model-answer membrane. Complete assistant replies send final Markdown directly as `InputRichMessage.markdown` through `sendRichMessage` when `assistant.rendering` is `rich`, and through the legacy Markdown-to-HTML renderer when `assistant.rendering` is `html`; guest replies use native Rich Markdown through `InputRichMessageContent` in `answerGuestQuery` results. Reasoning/thinking blocks, menus, status rows, queue controls, settings, diagnostics, and other harness-owned surfaces stay on explicit Telegram HTML/plain rendering, while completed tool activity uses native Rich block objects for visually distinct structured disclosure. Streaming previews may use `sendRichMessageDraft` only when `assistant.draftPreviews` is enabled and draft delivery succeeds. The bridge still strips top-level assistant action comments before delivery and may split output only for Telegram transport limits.
 
 Assistant delivery guarantees:
 
@@ -315,7 +315,7 @@ Queue reactions are shortcut controls for waiting turns. Promotion reactions (`
 
 When `assistant.proactivePush` is enabled and this instance has exact direct or follower transport authority, completed public assistant text blocks from local/autonomous work are sent once and in source order to the instance's authorized target. Visible commentary/checkpoints and the final block use the configured Rich or HTML renderer. Proactive projection excludes reasoning, tool traffic, token deltas, local prompt text, Telegram-owned turns, and stale generations. Each admitted block remains fenced to its exact target, profile/token stamp, leader epoch or follower registration generation, and session generation; non-idempotent acknowledgement ambiguity never authorizes replay.
 
-`assistant.activity` is an independent bridge-owned projection over normalized Activity events. Omitted or invalid values resolve to `quiet`, which emits no thinking or tool traffic; `thinking` and `tools` select one technical class, while `verbose` enables both. Provider-exposed thinking and completed executed tools use persistent ordinary HTML messages with standard expandable blockquotes and never use Rich Messages. Thinking uses a `🧠` header carrying the current Pi thinking level and a bounded redacted latest-text window with inline Markdown rendered as Telegram HTML inside the expandable quote; tools use `🛠` headers and bounded redacted execution evidence. The projection captures the exact target and transport stamp at activity admission, serializes updates, preserves tool-start order, closes coalescing across assistant/thinking boundaries, bounds retained text/update memory plus edit frames and message/tool size, disables previews and HTTP(S) auto-link recognition inside technical evidence, and never replays a possibly committed send. Session generations own independent queues, so replacement drops queued old work without waiting on an old call. Both proactive prose and active-turn final delivery wait for the admitted activity queue inside their extension-owned delivery tasks, preserving technical-before-semantic ordering without delaying Pi lifecycle completion. Settlement, replacement, disconnect, failure, or stale authority clears only local ownership; already-sent activity messages remain in chat.
+`assistant.activity` is an independent bridge-owned projection over normalized Activity events. Each process reloads the shared file-backed setting at `agent-start` before activity admission, so multi-instance mode cannot continue projecting a stale broader process-local selection. Omitted values resolve to `verbose`, while invalid values fail closed to `quiet`; `thinking` and `tools` select one technical class, while `verbose` enables both. Provider-exposed thinking uses persistent ordinary HTML with a standard expandable blockquote. Completed executed tools use native Rich Messages: each sentence-case `🛠` header precedes separate closed `Arguments`, retained `Update N`, and `Result`/`Error` details containing JSON pre blocks, with known-safe Rich rejections falling back to the previous HTML disclosure. Thinking uses a `🧠` header carrying the current Pi thinking level and a bounded redacted latest-text window with inline Markdown rendered as Telegram HTML inside the expandable quote. The projection captures the exact target and transport stamp at activity admission, serializes updates, preserves tool-start order, closes coalescing across assistant/thinking boundaries, bounds retained text/update memory plus edit frames and message/tool size, disables previews and HTTP(S) auto-link recognition inside technical evidence, and never replays a possibly committed send. Session generations own independent queues, so replacement drops queued old work without waiting on an old call. Both proactive prose and active-turn final delivery wait for the admitted activity queue inside their extension-owned delivery tasks, preserving technical-before-semantic ordering without delaying Pi lifecycle completion. Settlement, replacement, disconnect, failure, or stale authority clears only local ownership; already-sent activity messages remain in chat.
 
 Telegram prompt guidance is context- and authority-aware. Only an exact direct owner or live registered follower exposes the three pi-telegram model tools, their active-tool metadata, and the compact local bridge suffix. Disconnect or authority loss removes those surfaces for subsequent requests without touching foreign tools; reconnect/recovery restores only the pi-telegram subset that was active before suspension, including across same-process reload. Telegram-originated turns receive a compact pointer to `telegram_help` plus dynamic prompt blocks such as `[voice] delivery: automatic voice`; full voice/button/direct-delivery/Threaded Mode syntax stays in the help tool rather than every system prompt.
 

package/docs/outbound.md

@@ -14,11 +14,11 @@ Proactive blocks use `assistant.rendering` independently of voice policy. Rich m
 
 ## Technical Activity
 
-`assistant.activity` defaults to `quiet` and accepts four modes: `quiet`, `thinking`, `tools`, and `verbose`. `thinking` shows only provider-exposed thinking, `tools` shows only completed executed tools, and `verbose` shows both without mixing technical UI into assistant Markdown.
+`assistant.activity` defaults to `verbose` when absent and accepts four modes: `quiet`, `thinking`, `tools`, and `verbose`. Explicit stored values remain unchanged; invalid values fail closed to `quiet`. Every Pi instance reloads this shared file-backed mode at `agent-start`, so a setting changed from one thread applies to subsequent runs in the other live instances without requiring process reload. `thinking` shows only provider-exposed thinking, `tools` shows only completed executed tools, and `verbose` shows both without mixing technical UI into assistant Markdown.
 
-- Provider-exposed thinking updates one persistent ordinary HTML message. Its `🧠  thinking: <level>` header reports the current Pi thinking level, such as `high`, above a standard Telegram `<blockquote expandable>` containing a bounded redacted latest-text window whose inline Markdown emphasis and code render as Telegram HTML instead of leaking raw markers. The bridge sends the message once, edits it only as thinking grows, and leaves the disclosure in chat; it never replaces useful density metadata with a generic completion state or uses Rich drafts/Rich Messages. Providers that expose no thinking produce none.
-- Completed executed tools use ordinary `sendMessage` HTML, never `sendRichMessage`. Each tool header renders as `🛠  <tool>: <status>`, with a stable two-space visual gap after the icon and the `running`, `done`, or `failed` status in monospace. One standard Telegram `<blockquote expandable>` then contains bounded redacted evidence in chronological order. JSON-style labels share a line with their serialized value opening, for example `"arguments": {`, `"update 1": {`, and `"result": {` or `"error": {`; arrays of object entries use the denser `[{ ... }, { ... }]` layout while retaining indented fields.
-- Every thinking/tool `sendMessage` and `editMessageText` sets `link_preview_options.is_disabled: true` and breaks auto-link recognition inside technical evidence with an invisible separator after HTTP(S) schemes, so URL-like arguments, updates, results, and reasoning cannot expand into a web preview even when a Telegram client ignores preview options inside expandable blockquotes. Consecutive tools coalesce by editing one message only while target, activity, generation, ordering boundary, tool count, and serialized-size bounds still match. Assistant or thinking content closes the batch. A non-idempotent send with unknown commit state is never replayed; failed or ambiguous edits start no fallback send.
+- Provider-exposed thinking updates one persistent ordinary HTML message. Its `🧠  Thinking: <level>` header reports the current Pi thinking level, such as `high`, above a standard Telegram `<blockquote expandable>` containing a bounded redacted latest-text window whose inline Markdown emphasis and code render as Telegram HTML instead of leaking raw markers. The bridge sends the message once, edits it only as thinking grows, and leaves the disclosure in chat; it never replaces useful density metadata with a generic completion state or uses Rich drafts/Rich Messages. Providers that expose no thinking produce none.
+- Completed executed tools use native `sendRichMessage` block objects. Each tool starts with the sentence-case `🛠  <Tool>: <status>` header, then separate closed `Arguments`, retained `Update N`, and `Result`/`Error` details; every detail contains one preformatted `json` block. Updates remain chronological, dropped-update counts appear in the first retained update summary, and arrays of object entries keep the denser `[{ ... }, { ... }]` layout. A known-safe Rich HTTP 400 rejection falls back once to the previous expandable HTML representation; ambiguous non-idempotent outcomes never replay.
+- Thinking `sendMessage`/`editMessageText` disables link previews and breaks HTTP(S) auto-link recognition inside evidence. Rich tool messages set `skip_entity_detection: true`, so URL-like arguments, updates, and results remain literal code. Consecutive tools coalesce by editing one message only while target, activity, generation, ordering boundary, tool count, and serialized-size bounds still match. Assistant or thinking content closes the batch. A non-idempotent send with unknown commit state is never replayed; failed or ambiguous edits start no fallback send.
 
 Thinking retains only a bounded latest-text window, tool updates retain only a bounded latest-entry window, and a session reset abandons queued old-generation work without making the replacement session wait for an old transport call. Final-answer delivery waits for the admitted activity queue inside the extension-owned background delivery task, so completed technical evidence cannot be overtaken by the semantic answer and Pi lifecycle completion remains non-blocking.
 
@@ -54,7 +54,7 @@ The optimization is deliberately narrow. HTML rendering, empty final text, multi
 
 This behavior does not generate media or alter voice policy. `telegram_attach` still represents an explicit assistant artifact decision, while `hidden`, `mirror`, and `always` continue to decide voice synthesis independently.
 
-Core assistant output accepts only the Markdown or HTML `InputRichMessage` forms. Activity thinking and tool evidence use persistent ordinary HTML messages with expandable blockquotes and never Rich Message blocks. Thinking consumes only lifecycle content actually exposed by the active provider and never synthesizes unavailable private thinking.
+Core assistant output accepts only the Markdown or HTML `InputRichMessage` forms. Activity thinking remains persistent ordinary HTML with an expandable blockquote, while completed tool evidence uses structured `InputRichMessage.blocks` with closed details and JSON pre blocks. Thinking consumes only lifecycle content actually exposed by the active provider and never synthesizes unavailable private thinking.
 
 ### Guest Mode media boundary
 

package/docs/public-api.md

@@ -119,10 +119,10 @@ Hidden/default semantics are represented by absence:
 
 - `threads.automaticCleanup` defaults to `true`; graceful Pi quit deletes the instance's bound Threaded Mode tab without prompting. Set it to `false`, or use `🧹 Thread cleanup` in Telegram Settings, to preserve the tab as a restart hint. Settings views and cleanup reload shared config before evaluating this switch, so another live Pi instance's update takes effect without restarting. Confirmed leader/follower teardown persists an exact target/runtime-generation cleanup intent before Telegram deletion; an interrupted attempt remains retryable by the current or successor leader under current authority and clears only after confirmed deletion. A same-profile replacement leader first adopts any still-active binding and cancels its superseded cleanup, so startup never deletes and recreates a reusable thread. If a follower's graceful envelope is missed, the leader may create the same fenced cleanup only after its heartbeat is stale, the OS confirms the exact registered PID no longer exists, cleanup remains enabled, and no replacement registration can overtake deletion. Heartbeat loss alone, live/unknown process liveness, IPC failure, and auth failure remain non-destructive. Invalid-config recovery makes the setting unresolved and therefore skips destructive cleanup. Manual `/telegram-disconnect` keeps its confirmation and teardown behavior regardless of this setting.
 - `assistant.proactivePush` defaults to `true`; omit it to keep projection enabled, or set it explicitly to `false` to disable it. When enabled, each completed public assistant text block from local or autonomous work is projected to the authorized Telegram target once and in source order. This includes visible intermediate commentary/checkpoints and the final block. It excludes token deltas, hidden reasoning, tool calls/arguments/results, Telegram-owned turns, empty blocks, and stale authority. Projection uses the configured Rich or HTML assistant renderer and binds admitted work to the exact target, profile/token transport generation, direct leader epoch or follower registration generation, and session generation. The old top-level `proactivePush` key is ignored; move the setting manually under `assistant`.
-- `assistant.activity` accepts exactly `"quiet"`, `"thinking"`, `"tools"`, or `"verbose"` and resolves omitted or invalid values to `"quiet"`. `thinking` shows only provider-exposed thinking, `tools` shows only completed tool activity, and `verbose` shows both. Thinking and tools use persistent ordinary HTML `sendMessage`/`editMessageText` disclosures with standard expandable blockquotes; thinking carries a `🧠` header with the current Pi thinking level and bounded redacted text whose inline Markdown renders as Telegram HTML inside the expandable quote, while each tool contains bounded redacted arguments, retained updates, results, and errors. Activity output never uses Rich Messages, disables link previews on every send/edit, and neutralizes HTTP(S) auto-link detection inside technical evidence as a client-safe fallback. Consecutive tools coalesce only inside the same ordered activity segment and bounded message. Legacy `assistant.activityVerbosity` is read only when `assistant.activity` is absent and is removed by the next Activity Settings write.
+- `assistant.activity` accepts exactly `"quiet"`, `"thinking"`, `"tools"`, or `"verbose"`; omitted values default to `"verbose"`, explicit values remain unchanged, and invalid values fail closed to `"quiet"`. Each Pi process reloads the shared file-backed value at `agent-start`, so multi-instance activity isolation never relies on a stale process-local config snapshot. `thinking` shows only provider-exposed thinking, `tools` shows only completed tool activity, and `verbose` shows both. Thinking uses persistent ordinary HTML `sendMessage`/`editMessageText` disclosure with a standard expandable blockquote, a `🧠` header carrying the current Pi thinking level, and bounded redacted text whose inline Markdown renders as Telegram HTML. Tools use native Rich Messages with one header followed by separate closed details and JSON pre blocks for bounded redacted arguments, retained updates, and results/errors. Thinking disables link previews on every HTML send/edit and neutralizes HTTP(S) auto-link detection; Rich tool output disables automatic entity detection, with the same protections retained by its HTML fallback. Consecutive tools coalesce only inside the same ordered activity segment and bounded message. Legacy `assistant.activityVerbosity` is read only when `assistant.activity` is absent and is removed by the next Activity Settings write.
 - Voice Reply `hidden`: no `voice.replyMode` key is persisted; legacy `manual` resolves to this silent default. `mirror` adds `[voice] delivery: automatic voice` only to voice/audio-input turns, while `always` adds the same effective line to every Telegram turn.
 - Agent activity status is not configurable in this release. Telegram uses native `sendChatAction(typing)` / product `...active` status as the only automatic in-chat work signal before the final reply.
-- `assistant.timeInjection` accepts `hidden`, `always`, or `interval` and defaults to `hidden`. Settings writes the selected value there, including `hidden`; the old `time.injectionMode` key is ignored and is not migrated. `time.interval` remains the optional interval duration in milliseconds.
+- `assistant.timeInjection` accepts `hidden`, `always`, or `interval` and defaults to `interval` when absent without migrating an explicit stored value. Settings writes the selected value there, including `hidden`; the old `time.injectionMode` key is ignored and is not migrated. `time.interval` remains the optional interval duration in milliseconds.
 
 With `assistant.rendering: "rich"` (the default), assistant Markdown delivery is native: final replies are sent as `InputRichMessage.markdown` via `sendRichMessage`, and draft previews use `sendRichMessageDraft` when a structurally closed preview frame is available. Draft-frame failures are recorded and skipped rather than converted into raw plain preview messages, because partial Markdown can be temporarily invalid while the final answer remains valid. Long native replies are split at Telegram Rich Message transport limits, with oversized fenced code, display-math, and fully wrapped inline-formatting blocks rewrapped per chunk so persisted chunks remain structurally valid. Guest replies use `InputRichMessageContent` in `answerGuestQuery` results. Bridge-owned UI surfaces such as menus, status, queue controls, commands, and sections keep explicit Telegram HTML/plain rendering by default because those texts are authored by the bridge or companion extensions for Telegram UI. Companion extension sections may explicitly request `"markdown"`, `"html"`, or `"plain"` per view. `assistant.rendering: "html"` keeps the compatibility path that converts assistant Markdown to Telegram HTML before ordinary message delivery. The bridge sets `skip_entity_detection: true` for assistant and guest Markdown so technical text such as `/commands`, hashtags, URLs, phone numbers, and card-like numbers does not gain unintended automatic entities; explicit Markdown links still belong in the Markdown source.
 

package/docs/ui-style.md

@@ -35,7 +35,7 @@ Use emoji as stable semantic markers, not decoration. Emoji carry transportable
 | `📌` | Proactive push / pinned behavior | Proactive push settings row and detail card | Not generic active/selected state. |
 | `🔬` | Activity / technical detail | Activity settings row and detail card | Chooses quiet, thinking, tools, or verbose bridge activity; not a generic diagnostics marker. |
 | `🧠` | Model thinking activity | Collapsed persistent thinking disclosure summaries | One marker per thinking message; header text reports the current thinking level such as `high`. |
-| `🛠` | Executed tool activity | Collapsed tool disclosure summaries | One marker per tool summary; tool result state remains text (`done`/`failed`). |
+| `🛠` | Executed tool activity | Native Rich tool headers above closed Arguments/Update/Result/Error details | One marker per tool header; tool result state remains text (`done`/`failed`). |
 | `📎` | Attachment | Attachment summaries, queue rows for attachment-only turns | Not for thread binding. |
 
 ### Command And Control Actions

package/index.ts

@@ -507,6 +507,7 @@ export default function (pi: Pi.ExtensionAPI) {
   activityVerbosityRuntime =
     ActivityVerbosity.createTelegramActivityVerbosityRuntime({
       getActivityMode: configControls.getActivityVerbosity,
+      refreshActivityMode: configControls.refreshActivityVerbosity,
       getThinkingLevel,
       resolveTarget(event) {
         return event.target ?? proactivePushTargetGetter();
@@ -515,6 +516,7 @@ export default function (pi: Pi.ExtensionAPI) {
       isAuthorityActive:
         assistantOutputBindingRuntime.authority.isAuthorityActive,
       sendMessage,
+      sendRichMessage,
       editMessageText: editTelegramMessageText,
       recordFailure(operation, event, error) {
         recordRuntimeEvent("activity", error, {

package/lib/activity-verbosity.ts

@@ -11,7 +11,10 @@ import {
 } from "./rendering.ts";
 import type {
   TelegramEditMessageTextBody,
+  TelegramInputRichBlock,
+  TelegramInputRichMessage,
   TelegramSendMessageBody,
+  TelegramSendRichMessageBody,
   TelegramSentMessage,
 } from "./telegram-api.ts";
 import type { TelegramTarget } from "./target.ts";
@@ -40,6 +43,7 @@ interface ToolMessage {
   messageId: number;
   tools: ToolActivity[];
   target: TelegramTarget;
+  format: "rich" | "html";
 }
 
 interface ReasoningMessage {
@@ -164,6 +168,10 @@ function renderThinkingActivityEvidenceHtml(text: string): string {
   });
 }
 
+function capitalizeActivityLabel(label: string): string {
+  return label.length > 0 ? `${label[0]!.toUpperCase()}${label.slice(1)}` : label;
+}
+
 function renderToolActivityHtml(tool: ToolActivity): string {
   const evidence = [`"arguments": ${tool.args}`];
   if (tool.droppedUpdates > 0) {
@@ -183,7 +191,7 @@ function renderToolActivityHtml(tool: ToolActivity): string {
       : "done"
     : "running";
   return [
-    `<b>${TELEGRAM_TOOL_ACTIVITY_ICON}&#160; ${escapeHtml(tool.name)}:</b> <code>${status}</code>`,
+    `<b>${TELEGRAM_TOOL_ACTIVITY_ICON}&#160; ${escapeHtml(capitalizeActivityLabel(tool.name))}:</b> <code>${status}</code>`,
     `<blockquote expandable>${escapeActivityEvidenceHtml(evidence.join("\n\n"))}</blockquote>`,
   ].join("\n");
 }
@@ -194,16 +202,76 @@ export function renderTelegramToolActivityHtml(
   return tools.map(renderToolActivityHtml).join("\n\n");
 }
 
+function createToolActivityDetail(
+  summary: string,
+  text: string,
+): TelegramInputRichBlock {
+  return {
+    type: "details",
+    summary: { type: "bold", text: summary },
+    blocks: [{ type: "pre", text, language: "json" }],
+  };
+}
+
+function renderToolActivityRichBlocks(tool: ToolActivity): TelegramInputRichBlock[] {
+  const status = tool.complete
+    ? tool.isError
+      ? "failed"
+      : "done"
+    : "running";
+  const blocks: TelegramInputRichBlock[] = [
+    {
+      type: "paragraph",
+      text: [
+        {
+          type: "bold",
+          text: `${TELEGRAM_TOOL_ACTIVITY_ICON}  ${capitalizeActivityLabel(tool.name)}:`,
+        },
+        " ",
+        { type: "code", text: status },
+      ],
+    },
+    createToolActivityDetail("Arguments", tool.args),
+  ];
+  tool.updates.forEach((update, index) => {
+    const number = tool.droppedUpdates + index + 1;
+    const omitted =
+      index === 0 && tool.droppedUpdates > 0
+        ? ` · ${tool.droppedUpdates} earlier omitted`
+        : "";
+    blocks.push(createToolActivityDetail(`Update ${number}${omitted}`, update));
+  });
+  if (tool.complete && tool.result !== undefined) {
+    blocks.push(
+      createToolActivityDetail(tool.isError ? "Error" : "Result", tool.result),
+    );
+  }
+  return blocks;
+}
+
+export function renderTelegramToolActivityRichMessage(
+  tools: readonly ToolActivity[],
+): TelegramInputRichMessage {
+  return {
+    blocks: tools.flatMap(renderToolActivityRichBlocks),
+    skip_entity_detection: true,
+  };
+}
+
 function toolMessageSize(tools: readonly ToolActivity[]): number {
   return renderTelegramToolActivityHtml(tools).length;
 }
 
+function isKnownSafeRichActivityRejection(error: unknown): boolean {
+  return error instanceof Error && /HTTP 400: Bad Request:/i.test(error.message);
+}
+
 export function renderTelegramThinkingActivityHtml(
   text: string,
   thinkingLevel: string,
 ): string {
   return [
-    `<b>${TELEGRAM_THINKING_ACTIVITY_ICON}&#160; thinking:</b> <code>${escapeHtml(thinkingLevel)}</code>`,
+    `<b>${TELEGRAM_THINKING_ACTIVITY_ICON}&#160; Thinking:</b> <code>${escapeHtml(thinkingLevel)}</code>`,
     `<blockquote expandable>${renderThinkingActivityEvidenceHtml(text)}</blockquote>`,
   ].join("\n");
 }
@@ -217,16 +285,25 @@ export interface TelegramActivityVerbosityRuntime {
 
 export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
   getActivityMode: () => "quiet" | "thinking" | "tools" | "verbose";
+  refreshActivityMode?: () => Promise<void>;
   getThinkingLevel: () => string;
   resolveTarget: (event: TelegramActivityEvent) => TelegramTarget | undefined;
   captureAuthority: () => TAuthority;
   isAuthorityActive: (authority: TAuthority) => boolean;
   sendMessage: (body: TelegramSendMessageBody) => Promise<TelegramSentMessage>;
+  sendRichMessage: (
+    body: TelegramSendRichMessageBody,
+  ) => Promise<TelegramSentMessage>;
   editMessageText: (
     body: TelegramEditMessageTextBody,
   ) => Promise<"edited" | "unchanged">;
   recordFailure?: (
-    operation: "reasoning-send" | "reasoning-edit" | "tool-send" | "tool-edit",
+    operation:
+      | "config-refresh"
+      | "reasoning-send"
+      | "reasoning-edit"
+      | "tool-send"
+      | "tool-edit",
     event: TelegramActivityEvent,
     error: unknown,
   ) => void;
@@ -361,31 +438,70 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
     try {
       if (canAppend && toolMessage) {
         const nextTools = [...toolMessage.tools, tool];
-        await deps.editMessageText({
-          chat_id: target.chatId,
-          message_id: toolMessage.messageId,
-          text: renderTelegramToolActivityHtml(nextTools),
-          parse_mode: "HTML",
-          link_preview_options: { is_disabled: true },
-        });
+        try {
+          await deps.editMessageText({
+            chat_id: target.chatId,
+            message_id: toolMessage.messageId,
+            ...(toolMessage.format === "rich"
+              ? {
+                  rich_message:
+                    renderTelegramToolActivityRichMessage(nextTools),
+                }
+              : {
+                  text: renderTelegramToolActivityHtml(nextTools),
+                  parse_mode: "HTML" as const,
+                  link_preview_options: { is_disabled: true },
+                }),
+          });
+        } catch (error) {
+          if (
+            toolMessage.format !== "rich" ||
+            !isKnownSafeRichActivityRejection(error)
+          ) {
+            throw error;
+          }
+          await deps.editMessageText({
+            chat_id: target.chatId,
+            message_id: toolMessage.messageId,
+            text: renderTelegramToolActivityHtml(nextTools),
+            parse_mode: "HTML",
+            link_preview_options: { is_disabled: true },
+          });
+          toolMessage.format = "html";
+        }
         if (generation !== acceptedGeneration) return;
         toolMessage.tools = nextTools;
         return;
       }
-      const sent = await deps.sendMessage({
+      const body = {
         chat_id: target.chatId,
         ...(target.threadId === undefined
           ? {}
           : { message_thread_id: target.threadId }),
-        text: renderTelegramToolActivityHtml([tool]),
-        parse_mode: "HTML",
-        link_preview_options: { is_disabled: true },
-      });
+      };
+      let sent: TelegramSentMessage;
+      let format: ToolMessage["format"] = "rich";
+      try {
+        sent = await deps.sendRichMessage({
+          ...body,
+          rich_message: renderTelegramToolActivityRichMessage([tool]),
+        });
+      } catch (error) {
+        if (!isKnownSafeRichActivityRejection(error)) throw error;
+        sent = await deps.sendMessage({
+          ...body,
+          text: renderTelegramToolActivityHtml([tool]),
+          parse_mode: "HTML",
+          link_preview_options: { is_disabled: true },
+        });
+        format = "html";
+      }
       if (generation !== acceptedGeneration) return;
       toolMessage = {
         messageId: sent.message_id,
         tools: [tool],
         target: { ...target },
+        format,
       };
     } catch (error) {
       deps.recordFailure?.(canAppend ? "tool-edit" : "tool-send", event, error);
@@ -396,6 +512,16 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
     event: TelegramActivityEvent,
     acceptedGeneration: number,
   ) => {
+    if (event.type === "agent-start" && deps.refreshActivityMode) {
+      try {
+        await deps.refreshActivityMode();
+      } catch (error) {
+        deps.recordFailure?.("config-refresh", event, error);
+        clearActivity();
+        activityId = event.activityId;
+        return;
+      }
+    }
     if (!ensureActivity(event)) {
       if (
         activityId === event.activityId &&

package/lib/config.ts

@@ -769,10 +769,19 @@ export function createTelegramActivityVerbosityGetter(
       }
       return "quiet";
     }
-    return assistant?.activityVerbosity === "verbose" ? "verbose" : "quiet";
+    if (assistant?.activityVerbosity !== undefined) {
+      return assistant.activityVerbosity === "verbose" ? "verbose" : "quiet";
+    }
+    return "verbose";
   };
 }
 
+export function createTelegramActivityVerbosityRefresher(
+  configStore: TelegramMutableConfigStore,
+): () => Promise<void> {
+  return () => loadLatestTelegramConfig(configStore);
+}
+
 export function createTelegramActivityVerbositySetter(
   configStore: TelegramMutableConfigStore,
 ): (verbosity: TelegramActivityVerbosity) => Promise<void> {
@@ -848,9 +857,11 @@ export function resolveTelegramTimeConfig(
   timeInjection: TelegramTimeMode | undefined = undefined,
 ): ResolvedTelegramTimeConfig {
   const injectionMode: TelegramTimeMode =
-    timeInjection === "always" || timeInjection === "interval"
-      ? timeInjection
-      : "hidden";
+    timeInjection === undefined
+      ? "interval"
+      : timeInjection === "always" || timeInjection === "interval"
+        ? timeInjection
+        : "hidden";
   const interval =
     typeof raw?.interval === "number" && raw.interval > 0
       ? raw.interval
@@ -976,6 +987,8 @@ export function createTelegramConfigControls(
       createTelegramAssistantRenderingModeSetter(configStore),
     getActivityVerbosity:
       createTelegramActivityVerbosityGetter(configStore),
+    refreshActivityVerbosity:
+      createTelegramActivityVerbosityRefresher(configStore),
     setActivityVerbosity:
       createTelegramActivityVerbositySetter(configStore),
     getVoiceReplyMode: createTelegramVoiceReplyModeGetter(configStore),

package/lib/menu-settings.ts

@@ -228,10 +228,10 @@ export function buildActivityVerbositySettingsText(
     "",
     "Choose how much technical model activity Telegram shows.",
     "",
-    "<code>-</code> <code>quiet</code> (default): show no thinking or tool traffic.",
+    "<code>-</code> <code>quiet</code>: show no thinking or tool traffic.",
     "<code>-</code> <code>thinking</code>: show persistent collapsed thinking.",
-    "<code>-</code> <code>tools</code>: show persistent collapsed tool details.",
-    "<code>-</code> <code>verbose</code>: show both thinking and tools.",
+    "<code>-</code> <code>tools</code>: show persistent Rich tool details.",
+    "<code>-</code> <code>verbose</code> (default): show both thinking and tools.",
   ].join("\n");
 }
 
@@ -260,9 +260,9 @@ export function buildTimeInjectionModeSettingsText(
     "",
     "Controls whether Telegram-originated prompts include a compact wall-clock [time] line.",
     "",
-    "<code>-</code> <code>hidden</code> (default): no time line is added to prompt context.",
+    "<code>-</code> <code>hidden</code>: no time line is added to prompt context.",
     "<code>-</code> <code>always</code>: add time to every Telegram turn.",
-    "<code>-</code> <code>interval</code>: add time at most once per chat interval (default: 1 hour).",
+    "<code>-</code> <code>interval</code> (default): add time at most once per chat interval (1 hour unless configured).",
   ].join("\n");
 }
 

package/lib/telegram-api.ts

@@ -285,6 +285,7 @@ export type TelegramRichText =
   | { type: "bold" | "code"; text: TelegramRichText };
 
 export type TelegramInputRichBlock =
+  | { type: "paragraph"; text: TelegramRichText }
   | { type: "pre"; text: TelegramRichText; language?: string }
   | {
       type: "details";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@llblab/pi-telegram",
-  "version": "0.25.6",
+  "version": "0.26.0",
   "private": false,
   "publishConfig": {
     "access": "public"