@llblab/pi-telegram 0.25.0 → 0.25.2

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.
-- The only core reasoning/tool visibility path is the operator-enabled `assistant.activity: "verbose"` projection. It remains separate from proactive public prose and assistant Markdown: provider-exposed reasoning uses draft-only Rich `Thinking`, while completed executed tools use durable ordinary HTML messages with standard expandable blockquotes and never use Rich Messages. 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 persist reasoning, invent unavailable provider-private reasoning, or replay a possibly committed technical message.
+- 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, tools use `🛠`, `verbose` enables both, and every activity send/edit disables Telegram link previews. 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.json` `time` may add `[time] YYYY-MM-DD HH:mm:ss <timezone>` to Telegram-originated prompts for wall-clock context. It is hidden by default, uses `time.injectionMode` values `hidden|always|interval`, stores `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 `time.injectionMode` only.
+- 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.
 - 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,24 +2,15 @@
 
 _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._
 
-## P1 — 0.25.0 Configurable Activity Verbosity
+## P1 — Configurable Activity Live Smoke
 
-Context: Start the next minor release with an operator-controlled Telegram activity surface. Current behavior remains the quiet default: users receive assistant previews, intermediate public prose, and final answers without model reasoning or tool traffic. A new verbose mode should add compact technical reasoning and tool activity without turning bridge-owned UI into Markdown or mixing it into the semantic answer stream.
-
-Bot API evidence: Bot API 10.2 exposes explicit outgoing Rich Message blocks. `InputRichBlockThinking` is draft-only and disappears when the draft lifecycle ends; `InputRichBlockDetails` provides a collapsed disclosure container, and `InputRichBlockPreformatted` provides nested `<pre><code>` content. Exact mobile/Desktop rendering, edit behavior, and practical limits remain live-verification gates.
+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.
 
 Open work:
 
-- [x] Add a persisted `Activity` Settings option backed by `assistant.activity`, with exactly two initial values: `quiet` (default/current behavior) and `verbose` (reasoning plus tool activity). Omitted or invalid configuration must resolve to `quiet`; legacy `assistant.activityVerbosity` is read only when the canonical key is absent and removed on the next write. Settings must follow the existing nested list-option UI and callback/persistence concurrency contracts.
-- [x] In `verbose`, stream reasoning content exposed by supported Pi lifecycle events through a short-lived Telegram Rich Draft `Thinking` block bound to the exact chat/thread, profile, session generation, and direct-owner or follower authority. Finalization, cancellation, failure, replacement, and disconnect must clear local draft ownership without creating a persisted reasoning message or projecting unavailable provider-private chain-of-thought.
-- [x] Persist completed tool activity as bridge-owned compact ordinary HTML messages rather than assistant Markdown or Rich Messages. Render each tool call under one registered semantic icon and tool name with bounded, escaped arguments, updates, result, and error evidence inside a standard expandable blockquote.
-- [x] Coalesce consecutive tool calls from one ordered run into the same editable ordinary message while it remains within Telegram HTML message limits, with one independent expandable blockquote per call. Start a new message when the current message cannot safely accept another block; never reorder tools across assistant prose, reasoning boundaries, targets, runs, or lifecycle generations.
-- [x] Define bounded output, redaction, truncation, retry, edit-ambiguity, and transport-failure behavior so verbose mode cannot leak known secrets, flood the target, replay a possibly committed message, block Pi lifecycle completion, or disturb quiet-mode preview/final ordering. Record failures through existing diagnostics.
-- [x] Reconcile the current no-hidden-reasoning invariant and Rich rendering boundary in `AGENTS.md`, then update README, Settings/configuration docs, architecture/outbound docs, public activity guidance, UI emoji registry, and focused config/menu/activity/delivery/rendering/integration regressions.
-- [x] Order first-level `Settings` by operator meaning while keeping `⬆️ Main menu` first: message presentation (`Draft previews`, `Rendering`, `Voice reply`), technical/public activity (`Activity`, `Proactive push`), prompt context (`Time injection`), then lifecycle (`Thread cleanup`). Append extension-provided rows using their explicit `settings.order` and stable section-id tie-break, preserve each detail submenu's semantic option order, and add focused menu/section regressions.
-- [ ] Live-smoke both modes in classic and Threaded Mode on Telegram mobile and Desktop, including multiple sequential tools, oversized output rollover, cancellation during reasoning, tool failure, session replacement, follower transport, and final-answer ordering.
+- [ ] Live-smoke all four modes in classic and Threaded Mode on Telegram mobile and Desktop, including progressive thinking edits, multiple sequential tools, oversized output rollover, cancellation during thinking, tool failure, session replacement, follower transport, and final-answer ordering.
 
-Done when: `quiet` remains behaviorally unchanged, `verbose` shows ephemeral reasoning plus durable collapsed tool-call evidence with exact routing and bounded safe output, first-level Settings entries follow the documented semantic groups with deterministic extension ordering, Settings survives reload and concurrent persistence, all automated validation passes, and live clients confirm the intended draft/disclosure UX.
+Done when: live mobile and Desktop clients confirm the intended mode isolation, persistent disclosures, routing, rollover, cancellation, failure, and final-answer ordering behavior in classic and Threaded Mode.
 
 ## P1 — Native Windows Runtime Smoke
 

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## 0.25.2: Persistent Thinking Activity Hotfix
+
+- `Activity Modes`: Expanded `assistant.activity` to `quiet`, `thinking`, `tools`, and `verbose`; thinking now uses persistent ordinary HTML messages with a `🧠` header and collapsed bounded disclosure instead of ephemeral Rich drafts, while tools retain `🛠` disclosures. Every activity send/edit disables Telegram link previews. Impact: operators can inspect thinking-only, tools-only, or combined technical history without Telegram removing thinking when the final answer arrives or URL-like evidence expanding into distracting previews.
+
+## 0.25.1: Config And Activity Presentation
+
+- `Time Injection Config`: Moved the Settings-owned mode to `assistant.timeInjection`, while retaining `time.interval` as the independent interval duration. The old `time.injectionMode` key is ignored without fallback, migration, or automatic rewriting. Impact: assistant presentation controls share one config domain without silently mutating historical user data.
+- `Verbose Tool Evidence`: Quoted argument, update, result, and error labels as JSON-style properties and compacted arrays of object entries to `[{ ... }, { ... }]` while retaining readable fields, evidence order, redaction, truncation, and delivery bounds. Impact: multi-entry tool updates consume less vertical space without losing technical evidence.
+
 ## 0.25.0: Configurable Activity
 
 - `Activity`: Added a persisted quiet-by-default `assistant.activity` Settings control. Verbose mode streams only provider-exposed reasoning through ephemeral target-fenced Rich Thinking drafts, projects inline Markdown bold/code markers to native Rich Text, and records completed executed tools through memory/transport-bounded ordinary HTML messages with standard expandable blockquotes; tool activity never uses Rich Messages. Tool headers use `🛠  <tool>: <status>` with a monospace `running`, `done`, or `failed` status, while argument, update, result, and error labels sit directly before their serialized values (`arguments: {`, `result: {`) for compact scanning. Settings refreshes always read the live value; legacy `assistant.activityVerbosity` is accepted only when the canonical key is absent and removed on the next write. Consecutive ordered tools coalesce without crossing assistant/reasoning, target, activity, or transport-generation boundaries. Final delivery waits behind admitted technical activity inside the background delivery task, while replacement sessions abandon queued old-generation work immediately. Impact: operators can inspect compact redacted technical activity without stale menu state, mixing it into assistant answers, exposing it by default, replaying ambiguous sends, reordering the final answer, or delaying Pi lifecycle completion.

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, reasoning, tool traffic, token deltas, Telegram-owned turns, or stale-generation work. The separate quiet-by-default `Activity` setting can add ephemeral provider-exposed reasoning and bounded collapsed tool evidence. 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 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).
 
 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.
 
@@ -98,12 +98,12 @@ The first Telegram user to message the bot becomes the allowed owner. Other user
 | Queue control | Inspect waiting turns, delete stale work, promote important prompts, continue, abort, stop, or force the next queued item. | Long Pi tasks keep running while new mobile prompts stay visible and controllable instead of interrupting or disappearing. |
 | Operator menu | Use `/start` for status, prompt templates, model, thinking, settings, queue, extension sections, and diagnostics. | The bot is an operator panel, not a command cheat sheet. |
 | Prompt templates | Run Pi prompt templates as Telegram-safe commands such as `/fix_tests`. | Reusable local workflows become phone-accessible without exposing arbitrary terminal commands. |
-| Model and thinking | Switch model or reasoning level from Telegram through safe continuation flows. | Mobile control can adjust execution strategy without tearing down the current session. |
+| 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, or select `verbose` for short-lived reasoning drafts and durable collapsed tool disclosures. | Technical activity stays bounded, redacted, target-fenced, and visually separate from semantic assistant answers. |
+| Activity | Keep the default `quiet` answer-only surface, show only `thinking`, show only `tools`, or select `verbose` for both. | Persistent collapsed technical activity stays bounded, redacted, target-fenced, 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 verbose reasoning through a draft-only Rich Thinking block, tool activity through ordinary expandable HTML messages, 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 and tool activity through ordinary expandable HTML messages, 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. |
 | 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. In `verbose` activity mode, bridge-owned reasoning uses an ephemeral Rich `Thinking` draft while completed tools use ordinary HTML messages with standard expandable blockquotes and never Rich Messages; 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 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).
 
 ### Files And Artifacts
 
@@ -225,7 +225,7 @@ Companion extensions can integrate with Telegram without owning polling or trans
 - Add menu sections and settings surfaces.
 - Add compact status rows.
 - Deliver target-aware operational views and chat actions from companion code.
-- Observe normalized assistant, reasoning, tool, compaction, and settlement activity without blocking Pi.
+- Observe normalized assistant, thinking, tool, compaction, and settlement activity without blocking Pi.
 - Handle update/callback namespaces.
 - Provide inbound preprocessing handlers.
 - Provide outbound voice synthesis.

package/docs/activity.md

@@ -291,7 +291,7 @@ The implementation must cover:
 
 ## Core Verbosity And Consumer Policy
 
-The bridge now owns the minimal global `quiet`/`verbose` policy. Quiet is the default. Verbose streams available reasoning through an ephemeral Rich Thinking draft and emits bounded tool evidence through ordinary HTML expandable blockquotes without changing public assistant-segment projection or final replies.
+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 registration and delivery examples above remain the public building blocks for companion-specific policy:
 

package/docs/architecture.md

@@ -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 reasoning or tool traffic. `verbose` uses bounded ephemeral Rich Thinking drafts for provider-exposed reasoning and ordinary HTML messages with standard expandable blockquotes for completed executed tools; tool output never uses Rich Messages. It captures the exact target and transport stamp at activity admission, serializes updates, preserves tool-start order, closes coalescing across assistant/reasoning boundaries, redacts and truncates evidence, bounds retained reasoning/update memory plus draft frames and message/tool size, 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 local ownership without persisting reasoning.
+`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 and bounded redacted latest-text window; 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, 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

@@ -12,26 +12,26 @@ Proactive projection defaults on. With `assistant.proactivePush` omitted or set
 
 Proactive blocks use `assistant.rendering` independently of voice policy. Rich mode sends native Rich Markdown and HTML mode keeps the established HTML renderer; proactive projection does not synthesize voice or attach queued files merely because Rich rendering is active. The queue revalidates exact target, profile/token transport generation, leader epoch or follower registration generation, and session generation before each send. Telegram-owned turns remain on their ordinary reply path, and `commit-unknown` never permits proactive replay.
 
-## Verbose Technical Activity
+## Technical Activity
 
-`assistant.activity` defaults to `quiet`. In `verbose`, the bridge consumes the same normalized Activity stream without mixing technical UI into assistant Markdown:
+`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.
 
-- Provider-exposed reasoning deltas update a bounded ephemeral `sendRichMessageDraft` containing one `Thinking` block. Inline Markdown bold and code markers are projected to native Rich Text so their delimiters do not appear literally; unmatched streaming delimiters remain plain text until a later complete draft. The draft is fenced to its captured chat/thread and transport generation; settlement, cancellation, replacement, disconnect, or authority loss drops local ownership. It is never converted into a persisted reasoning message, and providers that expose no reasoning 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. Labels share a line with their serialized value opening, for example `arguments: {`, `update 1: {`, and `result: {` or `error: {`.
-- Consecutive tools coalesce by editing one message only while target, activity, generation, ordering boundary, tool count, and serialized-size bounds still match. Assistant or reasoning 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: running|done` header sits above a standard Telegram `<blockquote expandable>` containing a bounded redacted latest-text window. The bridge sends the message once, edits it as thinking grows, and leaves the completed disclosure in chat; it never uses Rich drafts or 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`, so URL-like evidence never expands into a web preview. 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.
 
-Reasoning 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 verbose activity queue inside the extension-owned background delivery task, so completed tool evidence cannot be overtaken by the semantic answer and Pi lifecycle completion remains non-blocking.
+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.
 
-Verbose activity is operational evidence, not part of the semantic answer stream. Final-answer rendering, voice policy, artifacts, and quiet behavior remain unchanged.
+Technical activity is operational evidence, not part of the semantic answer stream. Final-answer rendering, voice policy, artifacts, and quiet behavior remain unchanged.
 
 ### Live Activity Smoke
 
 Exercise one classic chat and one Threaded Mode follower target on both Telegram mobile and Desktop:
 
-1. Leave `Activity` on `quiet`; run a reasoning-capable request with two tools and confirm only normal preview/public/final output appears in established order.
-2. Switch to `verbose`; confirm reasoning appears only as a temporary Thinking draft, two sequential tools become two independently collapsed disclosures in one message, and the final answer follows the completed tool UI.
+1. Leave `Activity` on `quiet`; run a thinking-capable request with two tools and confirm only normal preview/public/final output appears in established order.
+2. Exercise `thinking`, `tools`, and `verbose`; confirm persistent collapsed thinking appears only in the modes that include it, two sequential tools become two independently collapsed disclosures in one message only in the modes that include tools, and the final answer follows admitted technical UI.
 3. Produce oversized arguments, multiple updates, and oversized result/error output; confirm redaction/truncation markers, latest-update retention, and safe rollover to another message without flood or reordering.
-4. Cancel during reasoning, fail a tool, replace the Pi session, and disconnect/reconnect transport; confirm reasoning never persists, stale activity does not cross generations, failure remains collapsed technical evidence, and subsequent work uses only the current target/authority.
+4. Cancel during thinking, fail a tool, replace the Pi session, and disconnect/reconnect transport; confirm already-sent thinking remains in chat, stale activity does not cross generations, failure remains collapsed technical evidence, and subsequent work uses only the current target/authority.
 5. Repeat through a registered follower and confirm every draft/send/edit stays in its assigned thread. Capture client/version, mode, target role, observed block behavior, and any Bot API/runtime diagnostic for each result.
 
 ## Standard
@@ -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. `InputRichBlockThinking` is reserved for ephemeral verbose reasoning drafts; durable tool evidence uses ordinary HTML messages and never Rich Message blocks. Reasoning drafts consume only lifecycle content actually exposed by the active provider and never synthesize unavailable private reasoning.
+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.
 
 ### Guest Mode media boundary
 

package/docs/public-api.md

@@ -95,14 +95,14 @@ interface TelegramConfig {
     draftPreviews?: boolean;
     rendering?: "rich" | "html";
     proactivePush?: boolean;
-    activity?: "quiet" | "verbose";
+    activity?: "quiet" | "thinking" | "tools" | "verbose";
+    timeInjection?: "hidden" | "always" | "interval";
   };
   voice?: {
     replyMode?: "hidden" | "mirror" | "always";
     sendTranscript?: boolean;
   };
   time?: {
-    injectionMode?: "hidden" | "always" | "interval";
     interval?: number;
   };
   threads?: {
@@ -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. 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"` or `"verbose"` and resolves omitted or invalid values to `"quiet"`. Quiet preserves the answer-only behavior. Verbose adds provider-exposed reasoning as an ephemeral target-bound Rich `Thinking` draft. Completed tool activity uses ordinary HTML `sendMessage`/`editMessageText`, with each tool represented by a standard expandable blockquote containing bounded redacted arguments, retained updates, results, and errors; tool output never uses Rich Messages. 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"` 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 and bounded redacted text, while each tool contains bounded redacted arguments, retained updates, results, and errors. Activity output never uses Rich Messages and disables link previews on every send/edit. 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.
-- Time Injection `hidden`: no `time.injectionMode` key is persisted; if `time` becomes empty, the whole `time` object may be omitted.
+- `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.
 
 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

@@ -33,8 +33,9 @@ Use emoji as stable semantic markers, not decoration. Emoji carry transportable
 | `👄` | Voice reply policy | Voice reply settings row and detail card | Not a generic audio attachment marker. |
 | `🕒` | Time injection / wall-clock context | Time injection settings row and detail card | Clock-face marker with hands; not a generic duration/progress marker. |
 | `📌` | 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 versus verbose bridge activity; not a generic diagnostics marker. |
-| `🛠` | Executed tool activity | Collapsed verbose tool disclosure summaries | One marker per tool summary; tool result state remains text (`done`/`failed`). |
+| `🔬` | 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; completion state remains text (`running`/`done`). |
+| `🛠` | Executed tool activity | Collapsed tool disclosure summaries | One marker per tool summary; 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

@@ -506,9 +506,7 @@ export default function (pi: Pi.ExtensionAPI) {
   const assistantOutputRuntime = assistantOutputBindingRuntime.runtime;
   activityVerbosityRuntime =
     ActivityVerbosity.createTelegramActivityVerbosityRuntime({
-      isVerbose() {
-        return configControls.getActivityVerbosity() === "verbose";
-      },
+      getActivityMode: configControls.getActivityVerbosity,
       resolveTarget(event) {
         return event.target ?? proactivePushTargetGetter();
       },
@@ -516,7 +514,6 @@ export default function (pi: Pi.ExtensionAPI) {
       isAuthorityActive:
         assistantOutputBindingRuntime.authority.isAuthorityActive,
       sendMessage,
-      sendRichMessageDraft,
       editMessageText: editTelegramMessageText,
       recordFailure(operation, event, error) {
         recordRuntimeEvent("activity", error, {

package/lib/activity-verbosity.ts

@@ -1,25 +1,24 @@
 /**
  * Bridge-owned Telegram activity verbosity projection
  * Zones: telegram activity, rich rendering, operational delivery
- * Owns ephemeral reasoning drafts and bounded durable tool disclosures; excludes activity normalization, assistant answer rendering, and transport authority policy
+ * Owns persistent bounded thinking and tool disclosures; excludes activity normalization, assistant answer rendering, and transport authority policy
  */
 
 import type { TelegramActivityEvent } from "./activity.ts";
 import { escapeHtml } from "./rendering.ts";
 import type {
   TelegramEditMessageTextBody,
-  TelegramRichText,
   TelegramSendMessageBody,
-  TelegramSendRichMessageDraftBody,
   TelegramSentMessage,
 } from "./telegram-api.ts";
 import type { TelegramTarget } from "./target.ts";
 
 export const TELEGRAM_TOOL_ACTIVITY_ICON = "🛠";
+export const TELEGRAM_THINKING_ACTIVITY_ICON = "🧠";
 export const TELEGRAM_ACTIVITY_DETAIL_MAX_CHARS = 1_200;
 export const TELEGRAM_ACTIVITY_MESSAGE_MAX_CHARS = 3_900;
 export const TELEGRAM_ACTIVITY_MESSAGE_MAX_TOOLS = 6;
-export const TELEGRAM_REASONING_DRAFT_MAX_FRAMES = 24;
+export const TELEGRAM_REASONING_MESSAGE_MAX_FRAMES = 24;
 export const TELEGRAM_REASONING_BUFFER_MAX_CHARS = 1_200;
 export const TELEGRAM_TOOL_UPDATE_MAX_ENTRIES = 4;
 
@@ -40,6 +39,11 @@ interface ToolMessage {
   target: TelegramTarget;
 }
 
+interface ReasoningMessage {
+  messageId: number;
+  target: TelegramTarget;
+}
+
 function targetEquals(left: TelegramTarget, right: TelegramTarget): boolean {
   return left.chatId === right.chatId && left.threadId === right.threadId;
 }
@@ -57,40 +61,71 @@ function redactActivityText(text: string): string {
     );
 }
 
-function renderReasoningRichText(text: string): TelegramRichText {
-  const parts: TelegramRichText[] = [];
-  let cursor = 0;
-  while (cursor < text.length) {
-    const codeStart = text.indexOf("`", cursor);
-    const boldStart = text.indexOf("**", cursor);
-    const starts = [codeStart, boldStart].filter((index) => index >= 0);
-    if (starts.length === 0) {
-      parts.push(text.slice(cursor));
-      break;
-    }
-    const start = Math.min(...starts);
-    if (start > cursor) parts.push(text.slice(cursor, start));
-    const marker = start === codeStart ? "`" : "**";
-    const end = text.indexOf(marker, start + marker.length);
-    if (end < 0) {
-      parts.push(text.slice(start));
-      break;
+function formatActivityJson(value: unknown, depth = 0): string[] {
+  const indent = "  ".repeat(depth);
+  if (Array.isArray(value)) {
+    if (value.length === 0) return [`${indent}[]`];
+    if (
+      value.every(
+        (entry) =>
+          entry !== null && typeof entry === "object" && !Array.isArray(entry),
+      )
+    ) {
+      const lines = [`${indent}[{`];
+      value.forEach((entry, index) => {
+        const fields = Object.entries(entry as Record<string, unknown>);
+        fields.forEach(([key, nested], fieldIndex) => {
+          const nestedLines = formatActivityJson(nested, depth + 1);
+          const nestedIndent = "  ".repeat(depth + 1);
+          lines.push(
+            `${nestedIndent}${JSON.stringify(key)}: ${nestedLines[0]!.slice(nestedIndent.length)}`,
+            ...nestedLines.slice(1),
+          );
+          if (fieldIndex < fields.length - 1) {
+            lines[lines.length - 1] += ",";
+          }
+        });
+        lines.push(
+          index < value.length - 1 ? `${indent}}, {` : `${indent}}]`,
+        );
+      });
+      return lines;
     }
-    parts.push({
-      type: marker === "`" ? "code" : "bold",
-      text: text.slice(start + marker.length, end),
+    const lines = [`${indent}[`];
+    value.forEach((entry, index) => {
+      const nestedLines = formatActivityJson(entry, depth + 1);
+      if (index < value.length - 1) {
+        nestedLines[nestedLines.length - 1] += ",";
+      }
+      lines.push(...nestedLines);
     });
-    cursor = end + marker.length;
+    lines.push(`${indent}]`);
+    return lines;
   }
-  if (parts.length === 0) return "";
-  return parts.length === 1 ? parts[0]! : parts;
+  if (value !== null && typeof value === "object") {
+    const entries = Object.entries(value as Record<string, unknown>);
+    if (entries.length === 0) return [`${indent}{}`];
+    const lines = [`${indent}{`];
+    entries.forEach(([key, nested], index) => {
+      const nestedLines = formatActivityJson(nested, depth + 1);
+      const nestedIndent = "  ".repeat(depth + 1);
+      lines.push(
+        `${nestedIndent}${JSON.stringify(key)}: ${nestedLines[0]!.slice(nestedIndent.length)}`,
+        ...nestedLines.slice(1),
+      );
+      if (index < entries.length - 1) lines[lines.length - 1] += ",";
+    });
+    lines.push(`${indent}}`);
+    return lines;
+  }
+  return [`${indent}${JSON.stringify(value)}`];
 }
 
 function serializeActivityValue(value: unknown): string {
   const seen = new WeakSet<object>();
   let text: string;
   try {
-    text =
+    const normalized =
       JSON.stringify(
         value,
         (_key, nested) => {
@@ -101,8 +136,8 @@ function serializeActivityValue(value: unknown): string {
           }
           return nested;
         },
-        2,
       ) ?? JSON.stringify(String(value));
+    text = formatActivityJson(JSON.parse(normalized)).join("\n");
   } catch {
     text = JSON.stringify(String(value));
   }
@@ -113,17 +148,17 @@ function serializeActivityValue(value: unknown): string {
 }
 
 function renderToolActivityHtml(tool: ToolActivity): string {
-  const evidence = [`arguments: ${tool.args}`];
+  const evidence = [`"arguments": ${tool.args}`];
   if (tool.droppedUpdates > 0) {
     evidence.push(`… [${tool.droppedUpdates} earlier updates omitted]`);
   }
   tool.updates.forEach((update, index) => {
     evidence.push(
-      `update ${tool.droppedUpdates + index + 1}: ${update}`,
+      `"update ${tool.droppedUpdates + index + 1}": ${update}`,
     );
   });
   if (tool.complete && tool.result !== undefined) {
-    evidence.push(`${tool.isError ? "error" : "result"}: ${tool.result}`);
+    evidence.push(`"${tool.isError ? "error" : "result"}": ${tool.result}`);
   }
   const status = tool.complete
     ? tool.isError
@@ -146,13 +181,14 @@ function toolMessageSize(tools: readonly ToolActivity[]): number {
   return renderTelegramToolActivityHtml(tools).length;
 }
 
-function draftIdForActivity(activityId: string): number {
-  let hash = 2166136261;
-  for (const character of activityId) {
-    hash ^= character.charCodeAt(0);
-    hash = Math.imul(hash, 16777619);
-  }
-  return (hash >>> 0) || 1;
+export function renderTelegramThinkingActivityHtml(
+  text: string,
+  complete: boolean,
+): string {
+  return [
+    `<b>${TELEGRAM_THINKING_ACTIVITY_ICON}&#160; thinking:</b> <code>${complete ? "done" : "running"}</code>`,
+    `<blockquote expandable>${escapeHtml(text)}</blockquote>`,
+  ].join("\n");
 }
 
 export interface TelegramActivityVerbosityRuntime {
@@ -163,19 +199,16 @@ export interface TelegramActivityVerbosityRuntime {
 }
 
 export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
-  isVerbose: () => boolean;
+  getActivityMode: () => "quiet" | "thinking" | "tools" | "verbose";
   resolveTarget: (event: TelegramActivityEvent) => TelegramTarget | undefined;
   captureAuthority: () => TAuthority;
   isAuthorityActive: (authority: TAuthority) => boolean;
   sendMessage: (body: TelegramSendMessageBody) => Promise<TelegramSentMessage>;
-  sendRichMessageDraft: (
-    body: TelegramSendRichMessageDraftBody,
-  ) => Promise<boolean>;
   editMessageText: (
     body: TelegramEditMessageTextBody,
   ) => Promise<"edited" | "unchanged">;
   recordFailure?: (
-    operation: "reasoning-draft" | "tool-send" | "tool-edit",
+    operation: "reasoning-send" | "reasoning-edit" | "tool-send" | "tool-edit",
     event: TelegramActivityEvent,
     error: unknown,
   ) => void;
@@ -188,8 +221,10 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
   let target: TelegramTarget | undefined;
   let reasoningBuffer = "";
   let reasoningChars = 0;
-  let reasoningDraftFrames = 0;
-  let lastReasoningDraftChars = 0;
+  let reasoningMessageFrames = 0;
+  let lastReasoningMessageChars = 0;
+  let reasoningMessage: ReasoningMessage | undefined;
+  let reasoningBlocked = false;
   let toolMessage: ToolMessage | undefined;
   const tools = new Map<string, ToolActivity>();
   const toolOrder: string[] = [];
@@ -200,8 +235,10 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
     target = undefined;
     reasoningBuffer = "";
     reasoningChars = 0;
-    reasoningDraftFrames = 0;
-    lastReasoningDraftChars = 0;
+    reasoningMessageFrames = 0;
+    lastReasoningMessageChars = 0;
+    reasoningMessage = undefined;
+    reasoningBlocked = false;
     toolMessage = undefined;
     tools.clear();
     toolOrder.length = 0;
@@ -209,7 +246,7 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
   const hasAuthority = (): boolean =>
     authority !== undefined && deps.isAuthorityActive(authority);
   const ensureActivity = (event: TelegramActivityEvent): boolean => {
-    if (!deps.isVerbose()) return false;
+    if (deps.getActivityMode() === "quiet") return false;
     if (activityId === event.activityId) return hasAuthority();
     clearActivity();
     const resolvedTarget = deps.resolveTarget(event);
@@ -222,44 +259,68 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
   const closeToolBatch = () => {
     toolMessage = undefined;
   };
-  const sendReasoningDraft = async (
+  const publishReasoning = async (
     event: TelegramActivityEvent,
     acceptedGeneration: number,
+    complete: boolean,
   ) => {
     if (
       generation !== acceptedGeneration ||
       !target ||
-      !hasAuthority()
+      !hasAuthority() ||
+      reasoningBlocked
     ) {
       return;
     }
-    const omitted = reasoningChars - reasoningBuffer.length;
-    const text =
-      omitted > 0
-        ? `… [${omitted} earlier chars omitted]\n${reasoningBuffer}`
-        : reasoningBuffer;
+    let retained = reasoningBuffer;
+    let body = "";
+    do {
+      const omitted = reasoningChars - retained.length;
+      const text = redactActivityText(
+        omitted > 0
+          ? `… [${omitted} earlier chars omitted]\n${retained}`
+          : retained,
+      );
+      body = renderTelegramThinkingActivityHtml(text, complete);
+      if (body.length <= TELEGRAM_ACTIVITY_MESSAGE_MAX_CHARS) break;
+      retained = retained.slice(-Math.max(1, Math.floor(retained.length * 0.75)));
+    } while (retained.length > 1);
+    const canEdit =
+      reasoningMessage && targetEquals(reasoningMessage.target, target);
     try {
-      await deps.sendRichMessageDraft({
-        chat_id: target.chatId,
-        ...(target.threadId === undefined
-          ? {}
-          : { message_thread_id: target.threadId }),
-        draft_id: draftIdForActivity(event.activityId),
-        rich_message: {
-          blocks: [
-            {
-              type: "thinking",
-              text: renderReasoningRichText(redactActivityText(text)),
-            },
-          ],
-          skip_entity_detection: true,
-        },
-      });
+      if (canEdit && reasoningMessage) {
+        await deps.editMessageText({
+          chat_id: target.chatId,
+          message_id: reasoningMessage.messageId,
+          text: body,
+          parse_mode: "HTML",
+          link_preview_options: { is_disabled: true },
+        });
+      } else {
+        const sent = await deps.sendMessage({
+          chat_id: target.chatId,
+          ...(target.threadId === undefined
+            ? {}
+            : { message_thread_id: target.threadId }),
+          text: body,
+          parse_mode: "HTML",
+          link_preview_options: { is_disabled: true },
+        });
+        reasoningMessage = {
+          messageId: sent.message_id,
+          target: { ...target },
+        };
+      }
       if (generation !== acceptedGeneration) return;
-      reasoningDraftFrames += 1;
-      lastReasoningDraftChars = reasoningChars;
+      reasoningMessageFrames += 1;
+      lastReasoningMessageChars = reasoningChars;
     } catch (error) {
-      deps.recordFailure?.("reasoning-draft", event, error);
+      deps.recordFailure?.(
+        canEdit ? "reasoning-edit" : "reasoning-send",
+        event,
+        error,
+      );
+      reasoningBlocked = true;
     }
   };
   const publishTool = async (
@@ -288,6 +349,7 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
           message_id: toolMessage.messageId,
           text: renderTelegramToolActivityHtml(nextTools),
           parse_mode: "HTML",
+          link_preview_options: { is_disabled: true },
         });
         if (generation !== acceptedGeneration) return;
         toolMessage.tools = nextTools;
@@ -300,6 +362,7 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
           : { message_thread_id: target.threadId }),
         text: renderTelegramToolActivityHtml([tool]),
         parse_mode: "HTML",
+        link_preview_options: { is_disabled: true },
       });
       if (generation !== acceptedGeneration) return;
       toolMessage = {
@@ -317,9 +380,17 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
     acceptedGeneration: number,
   ) => {
     if (!ensureActivity(event)) {
-      if (activityId === event.activityId && !deps.isVerbose()) clearActivity();
+      if (
+        activityId === event.activityId &&
+        deps.getActivityMode() === "quiet"
+      ) {
+        clearActivity();
+      }
       return;
     }
+    const mode = deps.getActivityMode();
+    const showThinking = mode === "thinking" || mode === "verbose";
+    const showTools = mode === "tools" || mode === "verbose";
     if (
       event.type === "assistant-text-delta" ||
       event.type === "assistant-segment" ||
@@ -329,31 +400,41 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
       closeToolBatch();
     }
     if (event.type === "reasoning-delta") {
+      if (!showThinking) return;
       reasoningChars += event.delta.length;
       reasoningBuffer = `${reasoningBuffer}${event.delta}`.slice(
         -TELEGRAM_REASONING_BUFFER_MAX_CHARS,
       );
       if (
-        reasoningDraftFrames < TELEGRAM_REASONING_DRAFT_MAX_FRAMES &&
-        (reasoningDraftFrames === 0 ||
-          reasoningChars - lastReasoningDraftChars >= 160)
+        reasoningMessageFrames < TELEGRAM_REASONING_MESSAGE_MAX_FRAMES &&
+        (reasoningMessageFrames === 0 ||
+          reasoningChars - lastReasoningMessageChars >= 160)
       ) {
-        await sendReasoningDraft(event, acceptedGeneration);
+        await publishReasoning(event, acceptedGeneration, false);
       }
       return;
     }
     if (event.type === "reasoning-end") {
-      if (
-        reasoningChars > lastReasoningDraftChars &&
-        reasoningDraftFrames < TELEGRAM_REASONING_DRAFT_MAX_FRAMES
-      ) {
-        await sendReasoningDraft(event, acceptedGeneration);
+      if (!showThinking) return;
+      if (reasoningChars === 0 && event.text) {
+        reasoningChars = event.text.length;
+        reasoningBuffer = event.text.slice(
+          -TELEGRAM_REASONING_BUFFER_MAX_CHARS,
+        );
+      }
+      if (reasoningChars > 0 && !reasoningBlocked) {
+        await publishReasoning(event, acceptedGeneration, true);
       }
       reasoningBuffer = "";
       reasoningChars = 0;
+      reasoningMessageFrames = 0;
+      lastReasoningMessageChars = 0;
+      reasoningMessage = undefined;
+      reasoningBlocked = false;
       return;
     }
     if (event.type === "tool-start") {
+      if (!showTools) return;
       tools.set(event.toolCallId, {
         id: event.toolCallId,
         name: event.toolName,
@@ -366,6 +447,7 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
       return;
     }
     if (event.type === "tool-update") {
+      if (!showTools) return;
       const tool = tools.get(event.toolCallId);
       if (!tool) return;
       tool.updates.push(serializeActivityValue(event.update));
@@ -376,6 +458,7 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
       return;
     }
     if (event.type === "tool-end") {
+      if (!showTools) return;
       const tool = tools.get(event.toolCallId) ?? {
         id: event.toolCallId,
         name: event.toolName,
@@ -400,6 +483,9 @@ export function createTelegramActivityVerbosityRuntime<TAuthority>(deps: {
       return;
     }
     if (event.type === "agent-end" || event.type === "agent-settled") {
+      if (reasoningMessage && reasoningChars > 0 && !reasoningBlocked) {
+        await publishReasoning(event, acceptedGeneration, true);
+      }
       clearActivity();
     }
   };

package/lib/config.ts

@@ -44,7 +44,6 @@ export interface TelegramOutboundHandlerConfig extends CommandTemplateObjectConf
 export type TelegramTimeMode = "hidden" | "always" | "interval";
 
 export interface TelegramTimeConfig {
-  injectionMode?: TelegramTimeMode;
   interval?: number;
 }
 
@@ -55,7 +54,11 @@ export interface ResolvedTelegramTimeConfig {
 }
 
 export type TelegramAssistantRenderingMode = "rich" | "html";
-export type TelegramActivityVerbosity = "quiet" | "verbose";
+export type TelegramActivityVerbosity =
+  | "quiet"
+  | "thinking"
+  | "tools"
+  | "verbose";
 
 export interface TelegramConfig {
   /** @deprecated persisted identity belongs in profiles.default; retained for effective/legacy views */
@@ -76,6 +79,7 @@ export interface TelegramConfig {
     rendering?: TelegramAssistantRenderingMode;
     proactivePush?: boolean;
     activity?: TelegramActivityVerbosity;
+    timeInjection?: TelegramTimeMode;
     /** @deprecated use activity */
     activityVerbosity?: TelegramActivityVerbosity;
   };
@@ -756,7 +760,14 @@ export function createTelegramActivityVerbosityGetter(
   return () => {
     const assistant = configStore.get().assistant;
     if (assistant?.activity !== undefined) {
-      return assistant.activity === "verbose" ? "verbose" : "quiet";
+      if (
+        assistant.activity === "thinking" ||
+        assistant.activity === "tools" ||
+        assistant.activity === "verbose"
+      ) {
+        return assistant.activity;
+      }
+      return "quiet";
     }
     return assistant?.activityVerbosity === "verbose" ? "verbose" : "quiet";
   };
@@ -834,10 +845,11 @@ function getSystemTimezone(): string {
 
 export function resolveTelegramTimeConfig(
   raw: TelegramTimeConfig | undefined,
+  timeInjection: TelegramTimeMode | undefined = undefined,
 ): ResolvedTelegramTimeConfig {
   const injectionMode: TelegramTimeMode =
-    raw?.injectionMode === "always" || raw?.injectionMode === "interval"
-      ? raw.injectionMode
+    timeInjection === "always" || timeInjection === "interval"
+      ? timeInjection
       : "hidden";
   const interval =
     typeof raw?.interval === "number" && raw.interval > 0
@@ -850,13 +862,25 @@ export function resolveTelegramTimeConfig(
 export function createTelegramTimeConfigGetter(
   configStore: Pick<TelegramConfigStore, "get">,
 ): () => ResolvedTelegramTimeConfig {
-  return () => resolveTelegramTimeConfig(configStore.get().time);
+  return () => {
+    const config = configStore.get();
+    return resolveTelegramTimeConfig(
+      config.time,
+      config.assistant?.timeInjection,
+    );
+  };
 }
 
 export function createTelegramTimeInjectionModeGetter(
   configStore: Pick<TelegramConfigStore, "get">,
 ): () => TelegramTimeMode {
-  return () => resolveTelegramTimeConfig(configStore.get().time).injectionMode;
+  return () => {
+    const config = configStore.get();
+    return resolveTelegramTimeConfig(
+      config.time,
+      config.assistant?.timeInjection,
+    ).injectionMode;
+  };
 }
 
 export function createTelegramTimeInjectionModeSetter(
@@ -865,19 +889,12 @@ export function createTelegramTimeInjectionModeSetter(
   return async (injectionMode) => {
     await loadLatestTelegramConfig(configStore);
     const current = configStore.get();
-    if (injectionMode === "hidden") {
-      const { injectionMode: _injectionMode, ...remainingTime } =
-        current.time ?? {};
-      const next = { ...current };
-      if (Object.keys(remainingTime).length > 0) next.time = remainingTime;
-      else delete next.time;
-      configStore.set(next);
-      await configStore.persist(next);
-      return;
-    }
     const next = {
       ...current,
-      time: { ...(current.time ?? {}), injectionMode },
+      assistant: {
+        ...(current.assistant ?? {}),
+        timeInjection: injectionMode,
+      },
     };
     configStore.set(next);
     await configStore.persist(next);

package/lib/menu-settings.ts

@@ -228,8 +228,10 @@ export function buildActivityVerbositySettingsText(
     "",
     "Choose how much technical model activity Telegram shows.",
     "",
-    "<code>-</code> <code>quiet</code> (default): show public assistant output without reasoning or tool traffic.",
-    "<code>-</code> <code>verbose</code>: add ephemeral available reasoning and durable collapsed tool details.",
+    "<code>-</code> <code>quiet</code> (default): 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.",
   ].join("\n");
 }
 
@@ -459,7 +461,12 @@ export function buildAssistantRenderingSettingsReplyMarkup(
 export function buildActivityVerbositySettingsReplyMarkup(
   verbosity: TelegramActivityVerbosity,
 ): TelegramSettingsMenuReplyMarkup {
-  const values: TelegramActivityVerbosity[] = ["quiet", "verbose"];
+  const values: TelegramActivityVerbosity[] = [
+    "quiet",
+    "thinking",
+    "tools",
+    "verbose",
+  ];
   return {
     inline_keyboard: [
       [{ text: "⬆️ Back", callback_data: "settings:list" }],
@@ -712,7 +719,12 @@ export async function handleTelegramSettingsMenuCallbackAction(
   }
   if (data.startsWith("settings:set:activity-verbosity:")) {
     const verbosity = data.slice("settings:set:activity-verbosity:".length);
-    if (verbosity === "quiet" || verbosity === "verbose") {
+    if (
+      verbosity === "quiet" ||
+      verbosity === "thinking" ||
+      verbosity === "tools" ||
+      verbosity === "verbose"
+    ) {
       await deps.setActivityVerbosity(verbosity);
       await updateActivityVerbositySettingsMessage(deps);
       await deps.answerCallbackQuery(

package/lib/telegram-api.ts

@@ -204,10 +204,15 @@ export interface TelegramReplyParameters {
   message_thread_id?: number;
 }
 
+export interface TelegramLinkPreviewOptions {
+  is_disabled?: boolean;
+}
+
 export type TelegramSendMessageBody = Record<string, unknown> & {
   chat_id: number;
   text: string;
   parse_mode?: "HTML";
+  link_preview_options?: TelegramLinkPreviewOptions;
   reply_markup?: unknown;
   reply_parameters?: TelegramReplyParameters;
 };
@@ -327,6 +332,7 @@ export type TelegramEditMessageTextBody = Record<string, unknown> & {
   text?: string;
   rich_message?: TelegramInputRichMessage;
   parse_mode?: "HTML";
+  link_preview_options?: TelegramLinkPreviewOptions;
   reply_markup?: unknown;
 };
 

package/package.json

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