@llblab/pi-kit 0.35.0 → 0.35.2

package/BACKLOG.md

@@ -4,6 +4,8 @@ Package pins, resource order and bundled runtime ownership remain authoritative
 
 ## Carried checks
 
+- **Installed 0.35.2 Telegram smoke (operator-owned):** After separately authorized kit installation/reload, connect a new Thread with every letter slot occupied and confirm it appears in seconds without the leader stalling or its followers going stale. Repeat the operator's earlier checks for leader failover after `/telegram-disconnect`, follower takeover, and collapsed repeated log records. Packed validation does not certify installed clients.
+- **Installed 0.35.1 Telegram smoke (operator-owned):** After separately authorized kit installation/reload, verify Reroute removes an exhausted temporary tab and Restore keeps the new tab while deleting its unprotected predecessor. Confirm protected work survives. Guest PNG/JPEG, document and MP3 replacement plus staging cleanup remain explicitly deferred upstream live checks; verify unsupported OGG/Opus feedback separately. Upstream idle-leader acceptance and kit packaging checks do not certify this installation.
 - **Installed 0.35.0 Telegram smoke (operator-owned):** After separately authorized installation/reload of both peers, verify same-process follower session replacement keeps the Thread, letter slot and title without a second connected notice. Check shared `threads.displayMode` through Settings across profiles and confirm the retired profile key is ignored without migration. Package validation does not certify installed clients.
 - **Installed 0.34.3 typing smoke (operator-owned):** After separately authorized installation/reload of both peers, verify native typing during streaming, UI prompts and compaction without recurring local authorization churn. Check actual client versions, including iOS; successful HTTP issuance and synthetic tests do not prove client visibility. Use disposable sessions and preserve accepted work.
 - **Installed 0.34.2 smoke (operator-owned):** After separately authorized installation/reload, verify Pi 1.2 custom-message completions no longer raise the Telegram prompt-hook error, adjacent button matrices retain their rows and callbacks, and native Windows Codex CLI fallback works on an actual Windows host. Use disposable settings; package validation and synthetic SDK probes do not certify installed clients or authorize live fault injection.

package/CHANGELOG.md

@@ -2,6 +2,17 @@
 
 All notable changes to `@llblab/pi-kit` are documented here.
 
+## 0.35.2: Telegram Connect Latency and Session Identity
+
+- `Telegram connect`: Advances only the exact Telegram pin to `0.57.2`. A new Thread now connects in seconds instead of roughly 20 seconds when every letter slot is occupied: rotation no longer re-reads the shared journal namespace once per binding inside one synchronous pass, while post-fence protection checks still read fresh evidence. Other pins, package membership and resource order are unchanged.
+- `Session identity`: A follower connected with `/telegram-connect` becomes leader when the old leader stops answering, instead of retrying a dead socket indefinitely, because authority now follows the session rather than the exact Pi context object. A promoted follower keeps its Thread, slot and name and still defers to a live lower-slot follower.
+- `Log noise`: Expected-and-recovered failures no longer fill the log. Private-chat graceful cleanup deletes the Thread directly, the restore probe records one lifecycle event instead of an API error, bus attempts record only the first and final failure plus recovery, and repeated heartbeat, capability-probe and typing-presence failures collapse into one record per run with a recovery record. Status diagnostics print the paths of the agent directory in use.
+
+## 0.35.1: Telegram Guest Media and Routing Cleanup
+
+- `Telegram cleanup`: Advances only the exact Telegram pin to `0.57.1`. Exhausted Reroute tabs and Restore's old tab are no longer blocked by unrelated targetless creation attempts, while accepted work and uncertain deletion stay protected. Fresh local menu Reroute and supported Restore hold command effects through their cleanup decision. Other pins, package membership and resource order are unchanged.
+- `Guest media`: Queued photos, documents and MP3 now replace an acknowledged Guest Mode placeholder instead of being silently skipped. Confirmed failures report errors, uncertain edits are not replayed, and unsupported OGG/Opus replacement is rejected explicitly. Guest media client acceptance remains a deferred upstream follow-up, not proof supplied by kit validation.
+
 ## 0.35.0: Telegram Thread Continuity and Shared Settings
 
 - `Telegram continuity`: Advances only the exact Telegram pin to `0.57.0`. Same-process follower session replacement preserves the Thread, letter slot and acknowledged title without a second connected notice; cross-process handoff notices use the acknowledged title. Other pins, package membership and resource order are unchanged.

package/README.md

@@ -18,7 +18,7 @@ Package links lead to the owning repositories for usage, documentation, issues,
 | [`@llblab/pi-codex-usage`](https://github.com/llblab/pi-codex-usage) | `0.13.1` | OpenAI/legacy Codex subscription quota and Business credit status, with persistent priority Fast toggle mirrored in Telegram |
 | [`@llblab/pi-grow-loop`](https://github.com/llblab/pi-grow-loop) | `0.9.0` | Visible continuation scheduling and bounded worker Skills through compiled, manifest-owned resources |
 | [`@llblab/pi-state-flow`](https://github.com/llblab/pi-state-flow) | `0.26.4` | Scoped context/memory compiler with step-independent current memory, stable Passive/Active modes and visible blocked-state status |
-| [`@llblab/pi-telegram`](https://github.com/llblab/pi-telegram) | `0.57.0` | Telegram companion with per-prompt Steer, queued controls, Reroute/Restore, recoverable connections, previews, follower Threads, files, and voice |
+| [`@llblab/pi-telegram`](https://github.com/llblab/pi-telegram) | `0.57.2` | Telegram companion with per-prompt Steer, queued controls, Reroute/Restore, recoverable connections, previews, follower Threads, files, and voice |
 | [`@llblab/skills`](https://github.com/llblab/skills) | `1.15.0` | Portable workflows for engineering, review, design, context maintenance, and other focused tasks |
 
 Versions are exact by design. An upstream release does not change an installed kit until this repository explicitly advances the dependency and publishes a new kit version. Runtime defects and package-specific feature requests belong in the linked repository; package selection and kit installation issues belong here.

package/node_modules/@llblab/pi-telegram/AGENTS.md

@@ -77,9 +77,10 @@ Use the relevant local skill before non-trivial work in its domain. Keep skill o
 - Runtime files live under `<agent-dir>/tmp/pi-telegram` (releases before 0.52.0 used `tmp/telegram`, which a new release never writes, migrates or deletes). The older `owners.json` is read-only evidence: a live fresh owner there blocks acquisition so two release generations never poll one bot, and only its identity is exposed, never its bus endpoint or secret. Only `state.json` and `logs.jsonl` are persistent root files: the per-profile `transport` section of `state.json` is the sole transport-owner authority, `workspace` owns canonical Workspace/Restore evidence and `admission` its leases; the `runtime` section and `logs.jsonl` never grant routing authority. Each section changes only through the shared transaction under its own domain authority (nonleader admission remains process/birth-owned, not transport-owned); Workspace/runtime publication captures exact session authority, and acquisition, refresh, release, takeover, and irreversible leader work fence the exact owner/epoch. Ordinary reads and section mutations still refuse a damaged shared envelope without repair. Explicit `/telegram-connect` additionally grants one profile-admitted reset of matching untargeted unfinished Thread-creation metadata before Workspace identity allocation; it may leave an unknown Telegram tab behind, but never deletes a known target, Workspace binding or journal receipt. Automatic startup/re-registration and Restore-only admission cannot grant that reset. Known pending targets retain their exact binding key and slot; fresh provisioning uses unique operation IDs so late recovery evidence cannot attach to a replacement attempt. Follower reset intent uses authenticated `explicit-connect-recovery-v1` registration. Only a non-election leader start (`/telegram-connect` or session auto-start) runs the operator-approved optimistic reset: under the shared transaction guard it replaces damaged envelope/transport/Workspace/admission evidence with an empty envelope, accepting loss of every profile's runtime continuity; filesystem access errors still refuse (see [Damaged-State Reset](./docs/architecture.md#damaged-state-reset-operator-approved)). Use the [session journal contract](./docs/multi-instance-bus.md#session-owned-journal-storage) for owners-named polling continuity and the explicitly approved optimistic session-family sweep; that sweep is not Thread deletion or receipt settlement.
 - Threaded Mode has exactly one live leader per bot profile. Followers are real operator-started Pi processes and must authenticate/register over local IPC; Telegram never spawns hidden Pi processes. A live but unreachable owner does not authorize split-brain polling.
 - Local IPC is a trust boundary, not merely a private socket. Unknown, stale, mismatched-generation, or unauthorized requests must not inject prompts, callbacks, API sends, artifacts, liveness, or bindings. Follower registration identity may prepare a binding, but inbound generation authority is published only after successful preparation for the same generation and current context; pending or failed startup cannot append into a retained old journal. Readiness also binds the active Pi context and supplied session generation. Same-session refresh awaits binding preparation without re-registering; a changed session ID cannot publish readiness until its exact leader registration is acknowledged. Reusing a context object cannot carry readiness across a session-generation or ID change. Registration requests capture session authority before asynchronous startup and fence every publication/finalization against the current attempt. Stop or supersession invalidates that attempt; obsolete cleanup cannot erase a newer registration or a refreshed context.
+- Session identity, not Pi context object identity, decides authority. Pi builds a fresh context object for every event, command, and tool call, so compare sessions through their stored generation and ID, never by object, and treat a fresh object of the same session as the same authority. How an instance came online — explicit `/telegram-connect`, session auto-restore, election promotion, or a same-process handoff — may decide only that it is online and which existing binding, slot, and target it takes; every post-online behavior, including election eligibility, promotion, routing, delivery, status, and Thread display, must read the same acknowledged registration state and must not branch on that mechanism. Only the documented connect-time gates (remembered-binding restore admission, restore/recovery envelope flags, capability negotiation, and predecessor handoff) may observe it. An in-flight registration survives a fresh same-session context and is dropped only by a replaced session generation or ID.
 - Protocol compatibility is independent from package version. Registration negotiates protocol version, runtime build, and canonical capabilities before target provisioning or live publication. `durable-follower-admission-v1` gates source forwarding; `queue-handoff-v1` independently gates semantic queue transfer for every participant and is advertised only with exact source/recipient journal-binding composition. `follower.register`, capability-gated restore-only `follower.restoreWorkspace` and side-effect-free liveness `bus.probe` are bootstrap requests; other requests require exact live-registry generation authority, and `bus.ack` is response-only. `thread-display-mode-v1` gates follower display-setting requests; the leader serializes the shared preference write and owns title application.
 - Long-lived timers, pollers, watchers, receivers, heartbeats, background delivery, and deferred dispatch are session-bound. Shutdown cancels/drains diagnostics publications and fences deferred status reads before they can acquire guards or repair files. Replacement stops stale activity and makes late work inert; teardown must recheck the captured session generation even when context identity is reused. Same-process handoff may preserve exact profile/target identity but never stale Pi context or cross-profile authority. Follower heartbeat and leader-to-follower Restore/live-rebind control reply deadlines align with the eight-second leader stale-liveness window rather than the generic one-second local-RPC default; an ordinary multi-second Pi/TUI event-loop stall or a slower Windows named pipe is not registration or recipient loss. Participating source observations must hold a reference for the actual read, including pending-mutation/count queries against a stopped worker's retained source; a scoped observation never restores receipt readiness or execution authority. A donor cancellation resumed after remote handoff awaits must also hold a source reference; only the existing exact journal CAS may cancel, never undo accepted recipient custody. Stable source keys do not certify captured callable lifetimes: snapshot prepared worker capabilities at construction and replace them on source-handle renewal without replaying unsettled input. Aborting a durable update generation does not release that `update_id`: replacement replay waits for its actual handler settlement, and effectful handlers use the shared execution fence immediately before commit and after awaited delegation. Admission also rechecks that fence after the default handler returns, before its outcome can settle custody; a stopped handler's ordinary return is not completion authority. Internal clones explicitly carry the hidden fence; reroute forwarding, thread-store mutation, cleanup, and Bot API boundaries retain the originating generation.
-- Runtime state is event-driven reconciliation of local assumptions against Telegram signals, not a complete bot read-model and not permission to query Telegram on every action. Destructive thread cleanup goes through `thread-reconciler` with current proof and leader fencing. Fresh Workspace Thread creation derives its initial Bot API title from the active display mode before issuance; the stable generated `threadName` remains separate from the acknowledged `displayTitle`.
+- Repeated identical diagnostics in one phase collapse into one run record plus one outcome record; the logging domain owns that recording policy, and other domains receive it as a structural port rather than growing a second owner. Runtime state is event-driven reconciliation of local assumptions against Telegram signals, not a complete bot read-model and not permission to query Telegram on every action. Destructive thread cleanup goes through `thread-reconciler` with current proof and leader fencing. Fresh Workspace Thread creation derives its initial Bot API title from the active display mode before issuance; the stable generated `threadName` remains separate from the acknowledged `displayTitle`.
 
 ### 4.3 Durable Admission And Settlement
 
@@ -90,7 +91,7 @@ Use the relevant local skill before non-trivial work in its domain. Keep skill o
 - Foreign forwarding settles as `accepted`, `retryable`, or `terminal-rejected`. Only an authenticated acknowledgement carrying the expected `deliveryId` and `sourceUpdateId` releases leader journal authority. Negative, missing, stale, mismatched, or capacity-failed settlement remains durable; callback error answers are side effects only. Exception: the operator-approved fixed chooser deadline may discard its exact unclaimed donor pending source without a body archive or delivery-success claim. Accepted recipient queue/work and bound Threads are untouched; old donor controls and late reports cannot replay it. The lifetime and temporary cleanup contract lives in `docs/architecture.md`.
 - A forwarding delivery id is stable across registration replacement and derives from envelope kind, source `update_id`, and stable recipient binding. Runtime instance and registration generation remain separate attempt fences. Persisted message ownership carries the stable binding so replay can rebind only to its current authenticated registration.
 - A queued receipt persists its acquiring runtime instance, OS pid/process-birth identity, session generation, acquisition id, and acquisition time. Only exact authority may settle or discard it. Cached presence is not current execution proof: prepared custody must revalidate the exact queued owner/group without recovery and refuse offers or uncertain reads. Completion requires an exact removal acknowledgement, never merely `!ready`; a retained acknowledgement permits local cleanup only, not replay. Same-process session replacement may reconstruct the claim and the original process may settle after transport ownership moves; a foreign process may neither replay nor settle it through generic removal or a copied acquisition id.
-- Startup and elapsed time are not owner-death proof; queued authority has no time lease. Dead-owner cleanup groups the complete receipt and transactionally rechecks pid liveness plus process-birth identity: only an absent PID or mismatched stable Linux/macOS/Windows birth proof discards all session-owned sources without replay; a matching proof is `alive`, while inaccessible birth metadata is `unverifiable`, and both non-dead outcomes keep authority queued. Under actual `A`–`Z` allocation pressure, retirement may invoke that journal-owned CAS only for a current inactive binding after complete strict source inspection, no local work/live owner/delivery authority, whole unoffered receipt groups, and a preflight proving every grouped owner dead. It must then recapture all protection before preparing deletion; partial progress never grants deletion authority. The live-transfer contract is authenticated offer → exact-generation bounded payload staging → recipient CAS acceptance → exact receipt-and-owner ACK → donor removal → recipient readiness. The offer freezes donor settlement/recovery; controls rebuild local closures; negative/mismatched pre-acceptance ACK cancels only an unaccepted offer and retains donor work; a lost post-acceptance ACK cannot cancel recipient authority and leaves donor memory frozen for explicit reconciliation.
+- Startup and elapsed time are not owner-death proof; queued authority has no time lease. Dead-owner cleanup groups the complete receipt and transactionally rechecks pid liveness plus process-birth identity: only an absent PID or mismatched stable Linux/macOS/Windows birth proof discards all session-owned sources without replay; a matching proof is `alive`, while inaccessible birth metadata is `unverifiable`, and both non-dead outcomes keep authority queued. Under actual `A`–`Z` allocation pressure, retirement may invoke that journal-owned CAS only for a current inactive binding after complete strict source inspection, no local work/live owner/delivery authority, whole unoffered receipt groups, and a preflight proving every grouped owner dead. It must then recapture all protection before preparing deletion; partial progress never grants deletion authority. Fully resolved, positively unbound temporary-tab cleanup may independently recover historical v1 queued receipts under its profile admission and journal source serialization: complete strict namespace/reference inspection, whole unoffered receipt groups, fresh process-death proof and the existing journal CAS are required. Alive/unverifiable owners and unsupported custody remain protected; this recovery never runs from read-only protection checks, and every ordinary target/source protection is recaptured before deletion. The live-transfer contract is authenticated offer → exact-generation bounded payload staging → recipient CAS acceptance → exact receipt-and-owner ACK → donor removal → recipient readiness. The offer freezes donor settlement/recovery; controls rebuild local closures; negative/mismatched pre-acceptance ACK cancels only an unaccepted offer and retains donor work; a lost post-acceptance ACK cannot cancel recipient authority and leaves donor memory frozen for explicit reconciliation.
 - Execution failures persist bounded diagnostics and attempt state as `retry-wait`, except that an exact Telegram HTTP 400 stale/deleted-thread API failure with a proven `{chatId, threadId}` terminally settles the currently executing source after best-effort shared binding invalidation. Automatic retry continues indefinitely with exponential `1s → 2s → 4s → 8s → 16s → 32s → 60s` delay capped at 60 seconds; later independent updates continue draining, durable authority is never silently discarded, and legacy `failed` entries resume automatically at startup. Snapshot-plus-segment journals compact only after 256 unapplied revisions or 4 MiB; snapshot-first cleanup tolerates redundant segments, and empty authority may atomically rebind bot/profile identity. Missing snapshots left by the retired broad temp cleanup rebuild only from a complete provably empty segment chain, while revisionless snapshots may recover from a validated later segment predecessor; otherwise the transaction-locked reset deletes damaged segments before publishing a fresh journal, with accepted input loss and informational evidence, not a quarantine copy. Unsupported versions remain untouched; strict protection reads never reset. Startup best-effort removes obsolete current-runtime root/session `recovery/` folders without touching pre-0.52.0 storage.
 - Business connection chats are a separate namespace even when their chat/message IDs match bot-chat IDs. Default DM routing must never infer private-queue deletion intent from `deleted_business_messages`; raw companion handlers remain separate owners.
 - Clock-bearing chooser sources survive cold spending until their fixed deadline. A restarted owner revives one in place only while its saved phase is still `waiting`, its recorded chooser location is known, its tab stays unbound and live threads exist; that waiting phase is the proof no selection or effect ran. Selected, expired or bound sources keep the protective hold, and new-world forgetting preserves their positively unbound temporary frame. Expiry is a donor discard, not recipient cancellation or source execution completion. Confirmed expiry releases worker custody before UI/cleanup awaits; metadata retries retain no prompt bodies and cannot repeat an issued delete.

package/node_modules/@llblab/pi-telegram/BACKLOG.md

@@ -2,9 +2,4 @@
 
 _This file owns unresolved project work only. Completed behavior belongs in `CHANGELOG.md`; durable contracts belong in `AGENTS.md` and `/docs`._
 
-- [ ] **Connection recovery live acceptance.** Verify operator-run leader/follower reconnect after interrupted creation on updated peers. Known target reuse and unknown-target abandonment have separate local regressions; do not infer live recovery from them. Also verify a long-deleted follower tab, follower `/start` Restore with negotiated menu-alias support, and leader Restore confirmation on the first click plus separately proven old-tab cleanup. Record leftover-tab behavior, exact peer capabilities and diagnostics; local regressions and release authorization do not replace this live evidence.
-- [ ] **Steer follow-up live acceptance.** Release authorization explicitly defers these checks beyond 0.56.0; do not treat automated coverage or the accepted busy-run smoke as live proof for unrun scenarios. Preserve the [queue and dispatch contract](./docs/architecture.md#queue-and-dispatch-safety).
-  - [ ] **Operator scenarios.** Verify final selector/counter rendering; idle packets, native pending input, compaction, model switching, abort/Continue, complete media groups, Reroute/Restore, negotiated leader/follower transfer, reply/preview ownership and session-generation replacement. Record actual Pi/OS/Telegram versions, peer capabilities and redacted outcomes. Reload and disposable live tests require operator intent; do not manipulate runtime files to obtain acceptance.
-  - [ ] **Restore recipient refusal after leadership change.** Diagnose a retained routing chooser refusing the selected current leader with unavailable recipient authority. Identify the exact context/session/Workspace mismatch before proposing recovery; do not treat an absent follower registry as the cause of a leader-target refusal, bypass fences or mutate live state.
-  - [ ] **Post-reload diagnostics.** Investigate recurring typing-authority refusals and Workspace publication retries observed alongside successful leader/follower reconnection. Establish whether they are expected fenced stale work or affect current-session delivery; successful registration alone does not establish error-free operation.
-  - [ ] **Native Windows scenarios.** Verify named-pipe custody/ACK, journal/atomic rename, reused-context lifecycle and the phone scenarios on an actual Windows host. Record skipped tests and missing platform evidence explicitly; a hosted CI result does not establish phone or full live-runtime acceptance.
+No open tasks.

package/node_modules/@llblab/pi-telegram/CHANGELOG.md

@@ -4,6 +4,24 @@
 
 ## Unreleased
 
+## 0.57.2: Connect Latency and Session Identity
+
+- `Connect latency`: A new Thread no longer waits about 20 seconds when all 26 letter slots are occupied. Slot rotation read the complete journal namespace and every shared journal once per binding inside one synchronous pass, freezing the leader's event loop and staling healthy follower heartbeats. One occupancy snapshot now reads that binding-independent evidence once, and every fresh snapshot still re-reads it so post-fence checks see newly arrived work.
+- `Session identity`: Follower promotion, Thread-name authority and in-flight registration now compare the session instead of the exact context object. A follower connected manually with `/telegram-connect` becomes leader when the old leader stops answering, instead of rescheduling promotion forever while registration retried a dead socket. Pi's fresh per-event context objects no longer change behavior; a follower with no live session still waits.
+- `Bus retries`: A leader reload no longer logs a line for every follower bus attempt, and an absent leader no longer repeats identical heartbeat, capability-probe or typing-presence failures every interval or tick. Each request records its first failure, one `client-recovered` event when a later attempt succeeds, and its final failure; a repeated failure records once per run plus a recovery record with the suppressed count. Detection and recovery observation are unchanged.
+- `Restore probe`: The follower restore probe now treats Telegram's `message thread not found` as its own expected answer instead of an API error. It still marks the target stale, re-creates the Thread and records one `topic-lifecycle` event with the old and new thread ids. Unexpected API failures keep their diagnostics.
+- `Graceful shutdown`: Graceful cleanup in a private chat now deletes the Thread directly instead of first calling `closeForumTopic`, which Telegram rejects outside forums. Rebind protection still runs immediately before deletion, so a Thread re-bound during cleanup remains protected; forum cleanups still close before deleting.
+- `Status diagnostics`: The connection status prints the state and log paths of the agent directory actually in use, so a second profile started with `PI_CODING_AGENT_DIR` no longer points at the default profile's files. Stored paths resolve through symlinked home directories before they are abbreviated. Fixes #349.
+- `Slow-call diagnostics`: Follower API calls slower than 1.5 seconds record one diagnostic with the method, the elapsed time and the split between waiting for registration and transport. A late reply can now be attributed to recovery waiting or to delivery instead of staying unexplained. This is observation only.
+- `Delivery coverage`: Automated checks now assert that commentary is delivered while its tool call is still running and that a final answer is delivered before automatic compaction completes, for every activity mode with draft previews on and off. Both paths already behaved this way; the coverage prevents regressions.
+
+
+## 0.57.1: Guest Media and Routing Cleanup
+
+- `Guest attachments`: Queued photos, documents and MP3 audio now replace the acknowledged Guest Mode placeholder instead of being silently skipped. Upload failures and confirmed edit rejections report errors; uncertain edits are not replayed or overwritten. OGG/Opus attachments are rejected before queueing on this path, and voice markup explains the limitation. Live-client media acceptance remains a deferred follow-up. Fixes #346.
+- `Routing cleanup`: Exhausted Reroute tabs and a restored instance's old tab are no longer blocked by unrelated creation attempts with unknown targets. Uncertain creation records stay intact; binding, slot, owner and concrete or recovered target conflicts still protect. Temporary cleanup can recover whole historical receipts from proven-dead owners; live/unverifiable owners, handoff offers and damaged sources remain protected. Idle leader Reroute and Restore passed operator live checks.
+- `Command ordering`: Fresh local menu Reroute waits for exact source removal and a temporary-tab cleanup attempt before rendering. Restore confirms the new binding, decides old-tab cleanup, then releases held input. Busy work retains protection, and uncertain deletion never repeats. Other Reroute commands, follower delivery and sources without fresh completion readiness retain their existing paths.
+
 ## 0.57.0: Thread Continuity and Shared Settings
 
 - `Config`: Thread display now lives in shared top-level `threads.displayMode`, beside the other Settings preferences; profiles hold only bot identity and the paired owner. The old `profiles.<name>.threadDisplayMode` key is not migrated and is ignored, so configs without the new key use the Letters default until Settings saves a choice.

package/node_modules/@llblab/pi-telegram/dist/lib/bindings.d.ts

@@ -269,7 +269,7 @@ interface TelegramLifecycleBindingDeps {
     shutdownGenerativeAppLiveSurfaces?: () => void;
     resolveAutomaticThreadCleanupEnabled?: () => boolean | Promise<boolean>;
     buttonActionStore: OutboundHandlers.TelegramButtonActionStore;
-    callMultipart: OutboundHandlers.TelegramVoiceReplySenderDeps["sendMultipart"];
+    callMultipart: (...args: Parameters<TelegramApi.TelegramBridgeApiRuntime["callMultipart"]>) => Promise<unknown>;
     sendChatAction: NonNullable<OutboundHandlers.TelegramVoiceReplySenderDeps["sendChatAction"]>;
     sendRecordVoiceAction: NonNullable<OutboundHandlers.TelegramVoiceReplySenderDeps["sendRecordVoiceAction"]>;
     sendMarkdownReply: Queue.TelegramAgentEndHookRuntimeDeps<Queue.PendingTelegramTurn, Pi.ExtensionContext, Pi.AgentEndEvent["messages"][number], Keyboard.TelegramInlineKeyboardMarkup>["sendMarkdownReply"];
@@ -278,6 +278,7 @@ interface TelegramLifecycleBindingDeps {
     onSteerTurnEnd?: TelegramQueueBindingRuntime<Pi.ExtensionContext>["onTurnEnd"];
     onPromptHandedOff?: (turn: Queue.PendingTelegramTurn, ctx: Pi.ExtensionContext) => void;
     answerGuestQuery: TelegramApi.TelegramBridgeApiRuntime["answerGuestQuery"];
+    editGuestInlineMessage?: TelegramApi.TelegramBridgeApiRuntime["editGuestInlineMessage"];
     deleteMessage: TelegramApi.TelegramBridgeApiRuntime["deleteMessage"];
     sendGuestReply: NonNullable<Queue.TelegramAgentEndHookRuntimeDeps<Queue.PendingTelegramTurn, Pi.ExtensionContext, Pi.AgentEndEvent["messages"][number], Keyboard.TelegramInlineKeyboardMarkup>["sendGuestReply"]>;
     editGuestReply?: Queue.TelegramAgentEndHookRuntimeDeps<Queue.PendingTelegramTurn, Pi.ExtensionContext, Pi.AgentEndEvent["messages"][number], Keyboard.TelegramInlineKeyboardMarkup>["editGuestReply"];
@@ -300,5 +301,5 @@ interface TelegramLifecycleBindingDeps {
     /** Settled-session hint for owners that wait on agent idleness, such as old-tab cleanup after a live rebind. */
     onSessionSettled?: (ctx: Pi.ExtensionContext) => void;
 }
-export declare function registerTelegramLifecycleRuntimeHooks({ pi, publicationRuntime, activityRuntime, activityVerbosityRuntime, diagnostics, assistantOutputRuntime, sessionLifecycleRuntime, configStore, abort, typing, lifecycle, activeTurnRuntime, telegramQueueStore, modelSwitchController, previewRuntime, promptDispatchRuntime, deferredQueueDispatchRuntime, modelContextAvailabilityRuntime, disconnectOnQuit, onSessionStarted, shutdownGenerativeAppLiveSurfaces, resolveAutomaticThreadCleanupEnabled, buttonActionStore, callMultipart, sendChatAction, sendRecordVoiceAction, sendMarkdownReply, sendTextReply, dispatchNextQueuedTelegramTurn, onSteerTurnEnd, onPromptHandedOff, answerGuestQuery, deleteMessage, sendGuestReply, editGuestReply, stopGuestPlaceholder, preparePreviewDelivery, finalizeMarkdownPreview, proactivePushTargetGetter, getAssistantRenderingMode, recordMessageOwnership, canSendAgentActivity, isSessionContextActive, getSessionGeneration, isTurnTransportActive, updateStatus, recordRuntimeEvent, onSessionSettled, }: TelegramLifecycleBindingDeps): void;
+export declare function registerTelegramLifecycleRuntimeHooks({ pi, publicationRuntime, activityRuntime, activityVerbosityRuntime, diagnostics, assistantOutputRuntime, sessionLifecycleRuntime, configStore, abort, typing, lifecycle, activeTurnRuntime, telegramQueueStore, modelSwitchController, previewRuntime, promptDispatchRuntime, deferredQueueDispatchRuntime, modelContextAvailabilityRuntime, disconnectOnQuit, onSessionStarted, shutdownGenerativeAppLiveSurfaces, resolveAutomaticThreadCleanupEnabled, buttonActionStore, callMultipart, sendChatAction, sendRecordVoiceAction, sendMarkdownReply, sendTextReply, dispatchNextQueuedTelegramTurn, onSteerTurnEnd, onPromptHandedOff, answerGuestQuery, editGuestInlineMessage, deleteMessage, sendGuestReply, editGuestReply, stopGuestPlaceholder, preparePreviewDelivery, finalizeMarkdownPreview, proactivePushTargetGetter, getAssistantRenderingMode, recordMessageOwnership, canSendAgentActivity, isSessionContextActive, getSessionGeneration, isTurnTransportActive, updateStatus, recordRuntimeEvent, onSessionSettled, }: TelegramLifecycleBindingDeps): void;
 export {};

package/node_modules/@llblab/pi-telegram/dist/lib/bindings.js

@@ -657,7 +657,7 @@ export function registerTelegramCommandsAndTools({ pi, agentDir, configStore, pe
         },
     });
 }
-export function registerTelegramLifecycleRuntimeHooks({ pi, publicationRuntime, activityRuntime, activityVerbosityRuntime, diagnostics, assistantOutputRuntime, sessionLifecycleRuntime, configStore, abort, typing, lifecycle, activeTurnRuntime, telegramQueueStore, modelSwitchController, previewRuntime, promptDispatchRuntime, deferredQueueDispatchRuntime, modelContextAvailabilityRuntime, disconnectOnQuit, onSessionStarted, shutdownGenerativeAppLiveSurfaces, resolveAutomaticThreadCleanupEnabled, buttonActionStore, callMultipart, sendChatAction, sendRecordVoiceAction, sendMarkdownReply, sendTextReply, dispatchNextQueuedTelegramTurn, onSteerTurnEnd, onPromptHandedOff, answerGuestQuery, deleteMessage, sendGuestReply, editGuestReply, stopGuestPlaceholder, preparePreviewDelivery, finalizeMarkdownPreview, proactivePushTargetGetter, getAssistantRenderingMode, recordMessageOwnership, canSendAgentActivity, isSessionContextActive = () => true, getSessionGeneration, isTurnTransportActive, updateStatus, recordRuntimeEvent, onSessionSettled, }) {
+export function registerTelegramLifecycleRuntimeHooks({ pi, publicationRuntime, activityRuntime, activityVerbosityRuntime, diagnostics, assistantOutputRuntime, sessionLifecycleRuntime, configStore, abort, typing, lifecycle, activeTurnRuntime, telegramQueueStore, modelSwitchController, previewRuntime, promptDispatchRuntime, deferredQueueDispatchRuntime, modelContextAvailabilityRuntime, disconnectOnQuit, onSessionStarted, shutdownGenerativeAppLiveSurfaces, resolveAutomaticThreadCleanupEnabled, buttonActionStore, callMultipart, sendChatAction, sendRecordVoiceAction, sendMarkdownReply, sendTextReply, dispatchNextQueuedTelegramTurn, onSteerTurnEnd, onPromptHandedOff, answerGuestQuery, editGuestInlineMessage, deleteMessage, sendGuestReply, editGuestReply, stopGuestPlaceholder, preparePreviewDelivery, finalizeMarkdownPreview, proactivePushTargetGetter, getAssistantRenderingMode, recordMessageOwnership, canSendAgentActivity, isSessionContextActive = () => true, getSessionGeneration, isTurnTransportActive, updateStatus, recordRuntimeEvent, onSessionSettled, }) {
     const agentEndResetter = Runtime.createTelegramAgentEndResetter({
         abort,
         typing,
@@ -677,7 +677,7 @@ export function registerTelegramLifecycleRuntimeHooks({ pi, publicationRuntime,
         recordOwnership: recordMessageOwnership,
         recordRuntimeEvent,
     });
-    const sendGuestAttachment = async (turn, attachment, caption) => {
+    const sendGuestAttachment = async (turn, attachment, caption, options) => {
         const stagingTarget = proactivePushTargetGetter();
         const stagingChatId = stagingTarget?.chatId;
         if (stagingChatId === undefined) {
@@ -685,11 +685,19 @@ export function registerTelegramLifecycleRuntimeHooks({ pi, publicationRuntime,
         }
         await OutboundAttachments.deliverTelegramGuestCachedAttachment({
             guestQueryId: turn.guestQueryId,
+            guestInlineMessageId: turn.guestInlineMessageId,
+            editGuestInlineMessage,
+            isDeliveryActive: options?.isDeliveryActive,
             stagingChatId,
             stagingTarget,
             attachment,
             caption,
-            sendMultipart: callMultipart,
+            sendMultipart: (method, fields, fileField, path, name) => callMultipart(method, fields, fileField, path, name, {
+                assertAuthority() {
+                    if (options?.isDeliveryActive?.() === false)
+                        throw new Error("Guest attachment upload lost authority.");
+                },
+            }),
             answerGuestQuery: (guestQueryId, result) => answerGuestQuery(guestQueryId, undefined, { result }),
             answerGuestText: (guestQueryId, text) => answerGuestQuery(guestQueryId, text),
             fallbackText: caption ||

package/node_modules/@llblab/pi-telegram/dist/lib/bus-api.js

@@ -339,9 +339,9 @@ export function createTelegramBusAwareApiRuntime(deps) {
                 ? deps.directRuntime.answerGuestQueryForInlineMessage(guestQueryId, text, options)
                 : rejectTelegramDirectOwnership("answerGuestQueryForInlineMessage");
         },
-        editGuestInlineMessage(inlineMessageId, content) {
+        editGuestInlineMessage(inlineMessageId, content, options) {
             return deps.ownsDirect()
-                ? deps.directRuntime.editGuestInlineMessage(inlineMessageId, content)
+                ? deps.directRuntime.editGuestInlineMessage(inlineMessageId, content, options)
                 : rejectTelegramDirectOwnership("editGuestInlineMessage");
         },
         async deleteMessage(chatId, messageId) {

package/node_modules/@llblab/pi-telegram/dist/lib/bus-follower.d.ts

@@ -131,6 +131,18 @@ export interface TelegramBusFollowerClientRuntimeDeps<TMessage = unknown> {
     recordRuntimeEvent?: (category: string, error: unknown, details?: Record<string, unknown>) => void;
     timeoutMs?: number;
 }
+/** Structural port for run-collapsing diagnostics, implemented by the logging domain. */
+export interface TelegramFailureRunLogPort {
+    record: (error: unknown, details?: Record<string, unknown>) => boolean;
+    settled: () => TelegramFailureRunSummaryPort | undefined;
+    reset: () => void;
+}
+export interface TelegramFailureRunSummaryPort {
+    signature: string;
+    failedAttempts: number;
+    suppressedFailures: number;
+    failedForMs: number;
+}
 export interface TelegramBusFollowerApiCallerDeps {
     socketPath: TelegramBusSocketPathSource;
     instanceId: string;
@@ -140,10 +152,18 @@ export interface TelegramBusFollowerApiCallerDeps {
     waitForRegistrationGeneration?: (timeoutMs?: number) => Promise<string | undefined>;
     getNowMs?: () => number;
     timeoutMs?: number;
+    /** Receives one diagnostic per call slower than `slowCallMs`; observation only. */
+    recordRuntimeEvent?: (category: string, error: unknown, details?: Record<string, unknown>) => void;
+    slowCallMs?: number;
 }
 export interface TelegramBusFollowerRegistrationRuntimeDeps<TContext extends {
     cwd?: string;
 }> {
+    /**
+     * Collapses one sustained heartbeat failure run. Optional at this unit boundary, where an absent port records
+     * every failure; the runtime assembly requires it so production always supplies the logging domain's owner.
+     */
+    failureLog?: TelegramFailureRunLogPort;
     instanceId: string;
     createRequestId: () => string;
     protocolIdentity: TelegramBusProtocolIdentity;
@@ -291,6 +311,8 @@ export interface TelegramBusFollowerRuntimeAssemblyPorts<TContext extends {
     cwd?: string;
 }> {
     instanceId: string;
+    /** Collapses one sustained heartbeat failure run; the composition root supplies the logging domain's owner. */
+    failureLog: TelegramFailureRunLogPort;
     registrationState: TelegramBusFollowerRegistrationState;
     recordRuntimeEvent: (category: string, error: unknown, details?: Record<string, unknown>) => void;
     receiver: Omit<TelegramBusForwardedUpdateReceiverRuntimeDeps<TContext>, "instanceId" | "recordRuntimeEvent" | "getRegistrationGeneration">;

package/node_modules/@llblab/pi-telegram/dist/lib/bus-follower.js

@@ -23,6 +23,7 @@ import * as WorkspaceIdentity from "./workspace-identity.js";
 const TELEGRAM_BUS_FOLLOWER_PROMOTION_GRACE_MS = 2_500;
 const TELEGRAM_FOLLOWER_SESSION_HANDOFF_TTL_MS = 30_000;
 const TELEGRAM_BUS_FOLLOWER_CLIENT_TIMEOUT_MS = 30_000;
+const TELEGRAM_BUS_FOLLOWER_API_SLOW_CALL_MS = 1_500;
 const TELEGRAM_BUS_FOLLOWER_REGISTRATION_WAIT_MS = 30_000;
 export const TELEGRAM_BUS_FOLLOWER_HEARTBEAT_TIMEOUT_MS = TELEGRAM_BUS_LEADER_STALE_HEARTBEAT_MS;
 const TELEGRAM_BUS_FOLLOWER_REGISTRATION_RETRY_ATTEMPTS = TELEGRAM_BUS_REGISTRATION_RETRY.attempts;
@@ -213,6 +214,7 @@ export function createTelegramBusFollowerRuntimeAssembly(ports) {
     });
     registration = createTelegramBusFollowerRegistrationRuntime({
         ...ports.registration,
+        failureLog: ports.failureLog,
         ...sharedRuntimeDeps,
         startReceiving: receiver.start,
         stopReceiving: receiver.stop,
@@ -677,6 +679,7 @@ export function createTelegramBusFollowerClientRuntime(deps) {
             instanceId: deps.instanceId,
             getAuthSecret: deps.getApiAuthSecret,
             getRegistrationGeneration: deps.getRegistrationGeneration,
+            recordRuntimeEvent: deps.recordRuntimeEvent,
         }),
         agentMessages: createTelegramBusAgentMessageClient({
             ...sharedClientDeps,
@@ -947,11 +950,13 @@ export function createTelegramBusFollowerSelectedMenuCaller(deps) {
 export function createTelegramBusFollowerApiCaller(deps) {
     const getNowMs = deps.getNowMs ?? Date.now;
     const timeoutMs = deps.timeoutMs ?? TELEGRAM_BUS_FOLLOWER_CLIENT_TIMEOUT_MS;
-    return async (method, args, localOptions) => {
+    const slowCallMs = deps.slowCallMs ?? TELEGRAM_BUS_FOLLOWER_API_SLOW_CALL_MS;
+    const caller = async (method, args, localOptions, timing) => {
         const assertion = localOptions?.assertAuthority;
         const assertCurrent = () => assertTelegramApiCallAuthority(assertion, false);
         assertCurrent();
         const registration = await resolveTelegramBusFollowerRegistration(deps, timeoutMs);
+        timing.registeredAtMs = getNowMs();
         assertCurrent();
         const socketPath = resolveTelegramBusSocketPath(deps.socketPath);
         let response;
@@ -999,6 +1004,42 @@ export function createTelegramBusFollowerApiCaller(deps) {
         }
         throw new Error(message ?? "Telegram bus API call failed.");
     };
+    return async (method, args, localOptions) => {
+        const startedAtMs = getNowMs();
+        const timing = {};
+        let outcome = "ok";
+        try {
+            return await caller(method, args, localOptions, timing);
+        }
+        catch (error) {
+            outcome = "error";
+            throw error;
+        }
+        finally {
+            const elapsedMs = getNowMs() - startedAtMs;
+            if (elapsedMs >= slowCallMs) {
+                const apiMethod = (method === "call" || method === "callMultipart") &&
+                    typeof args[0] === "string"
+                    ? args[0]
+                    : method;
+                try {
+                    deps.recordRuntimeEvent?.("bus", `Telegram bus follower API call was slow (${elapsedMs}ms).`, {
+                        phase: "follower-api-slow",
+                        method: apiMethod,
+                        elapsedMs,
+                        registrationWaitMs: (timing.registeredAtMs ?? getNowMs()) - startedAtMs,
+                        ...(timing.registeredAtMs === undefined
+                            ? {}
+                            : { transportMs: getNowMs() - timing.registeredAtMs }),
+                        outcome,
+                    });
+                }
+                catch {
+                    // Diagnostics cannot change the API call outcome.
+                }
+            }
+        }
+    };
 }
 async function resolveTelegramBusFollowerRegistration(deps, timeoutMs) {
     const current = deps.getRegistrationGeneration();
@@ -1447,10 +1488,16 @@ export function createTelegramBusFollowerHeartbeatRecoveryHandler(deps) {
         const promoteToLeader = async (reason, ctx, binding, election) => {
             if (!isCurrent())
                 return;
-            const activeCtx = deps.getActiveContext?.();
-            if (deps.getActiveContext && activeCtx !== ctx) {
-                scheduleRecovery(reason, ctx, binding);
-                return;
+            if (deps.getActiveContext) {
+                // Pi hands every event and command a fresh context object, so a manually connected follower never holds
+                // the stored session object. Promote through the live session context instead of rescheduling: heartbeat
+                // failures re-request recovery faster than the retry grace, so a reschedule-only path never fires.
+                const activeCtx = deps.getActiveContext();
+                if (!activeCtx) {
+                    scheduleRecovery(reason, ctx, binding);
+                    return;
+                }
+                ctx = activeCtx;
             }
             deps.setLifecyclePhase("electing");
             safeUpdateStatus(ctx);
@@ -1629,6 +1676,8 @@ export function createTelegramBusFollowerRegistrationRuntime(deps) {
         (!deps.registrationState ||
             deps.registrationState.getGeneration() === generation);
     const stopHeartbeat = () => {
+        // A stopped heartbeat ends the current failure run, so a later run logs its own first failure.
+        heartbeatFailureLog.reset();
         if (!heartbeatInterval)
             return;
         clearInterval(heartbeatInterval);
@@ -1659,6 +1708,22 @@ export function createTelegramBusFollowerRegistrationRuntime(deps) {
             }
         });
     };
+    /** A sustained leader outage repeats one identical failure every interval; the port collapses the run. */
+    const heartbeatFailureLog = deps.failureLog ?? {
+        record(error) {
+            try {
+                deps.recordRuntimeEvent?.("bus", error, {
+                    phase: "follower-heartbeat",
+                });
+            }
+            catch {
+                // Diagnostics cannot replace heartbeat recovery.
+            }
+            return true;
+        },
+        settled: () => undefined,
+        reset: () => undefined,
+    };
     const sendHeartbeat = async () => {
         const leaderSocketPath = activeLeaderSocketPath;
         const registrationGeneration = activeRegistrationGeneration;
@@ -1681,6 +1746,7 @@ export function createTelegramBusFollowerRegistrationRuntime(deps) {
             if (!isCurrentHeartbeat())
                 return;
             if (response?.kind === "bus.ack" && response.ok) {
+                heartbeatFailureLog.settled();
                 const heartbeatResult = isRecord(response.result)
                     ? response.result
                     : undefined;
@@ -1707,14 +1773,7 @@ export function createTelegramBusFollowerRegistrationRuntime(deps) {
         catch (error) {
             if (!isCurrentHeartbeat())
                 return;
-            try {
-                deps.recordRuntimeEvent?.("bus", error, {
-                    phase: "follower-heartbeat",
-                });
-            }
-            catch {
-                // Diagnostics cannot replace heartbeat recovery.
-            }
+            heartbeatFailureLog.record(error);
             if (!heartbeatContext)
                 return;
             try {
@@ -1956,10 +2015,10 @@ export function createTelegramBusFollowerRegistrationRuntime(deps) {
             return false;
         },
         setContext(ctx) {
+            // Pi hands every event a fresh context object. Only a replaced session drops an in-flight attempt.
             if (registrationAttempt &&
-                (registrationAttempt.ctx !== ctx ||
-                    registrationAttempt.sessionGeneration !==
-                        deps.getSessionGeneration?.() ||
+                (registrationAttempt.sessionGeneration !==
+                    deps.getSessionGeneration?.() ||
                     registrationAttempt.sessionId !== deps.getSessionId?.(ctx)))
                 registrationAttempt = undefined;
             activeContext = ctx;

package/node_modules/@llblab/pi-telegram/dist/lib/bus-leader.d.ts

@@ -66,7 +66,7 @@ export interface TelegramBusFollowerTargetProvisionerDeps {
     getLiveFollowers?: () => readonly TelegramBusFollowerView[];
     isFollowerProcessAlive?: (pid: number) => boolean;
     topicTargetStore: Threads.TelegramTopicTargetStore;
-    callApi: <TResponse>(method: string, body: Record<string, unknown>) => Promise<TResponse>;
+    callApi: <TResponse>(method: string, body: Record<string, unknown>, options?: TelegramApiCallOptions) => Promise<TResponse>;
     getCurrentLeaderEpoch?: () => number | string | undefined;
     getSyncState: () => Sync.TelegramSyncState;
     setSyncState: (state: Sync.TelegramSyncState) => void;

package/node_modules/@llblab/pi-telegram/dist/lib/bus-leader.js

@@ -1200,7 +1200,9 @@ export function createTelegramBusFollowerTargetProvisioner(deps) {
                         message_thread_id: connectedAnnouncement.target.threadId,
                         text: connectedAnnouncement.text,
                         parse_mode: connectedAnnouncement.parseMode,
-                    });
+                    }, 
+                    // A deleted Thread is this probe's expected answer; the recovery below records it.
+                    { isExpectedError: Threads.isTelegramTopicTargetStaleError });
                     assertRestoreRegistration();
                     if (recoverableTarget || probeRequiredRecord) {
                         const activatedRecord = deps.topicTargetStore.upsert({
@@ -1240,7 +1242,15 @@ export function createTelegramBusFollowerTargetProvisioner(deps) {
                     if (Threads.isTelegramTopicTargetStaleError(error)) {
                         deps.topicTargetStore.markStaleByTarget(result.target, "deleted", error instanceof Error ? error.message : String(error));
                         await deps.topicTargetStore.persist();
+                        const staleTarget = result.target;
                         result = await provisionTarget();
+                        deps.recordRuntimeEvent("telegram", "Telegram follower restore probe found its Thread deleted; re-created it.", {
+                            phase: "topic-lifecycle-restore-probe-recreated",
+                            instanceId: registration.instanceId,
+                            chatId: staleTarget.chatId,
+                            staleThreadId: staleTarget.threadId,
+                            threadId: result.target.threadId,
+                        });
                         connectedAnnouncement =
                             createTelegramBusInstanceLifecycleAnnouncement({
                                 target: result.target,

package/node_modules/@llblab/pi-telegram/dist/lib/bus.js

@@ -1960,32 +1960,43 @@ export async function sendTelegramBusLocalEnvelope(options) {
     };
     const attempts = Math.max(1, resolvedOptions.retry?.attempts ?? 1);
     const delayMs = Math.max(0, resolvedOptions.retry?.delayMs ?? 0);
+    // Log the first failure, then only the outcome: a reloading leader would otherwise log every attempt.
     for (let attempt = 1;; attempt += 1) {
         try {
-            return await sendTelegramBusLocalEnvelopeOnce(resolvedOptions);
+            const response = await sendTelegramBusLocalEnvelopeOnce(resolvedOptions);
+            if (attempt > 1)
+                resolvedOptions.recordTransportEvent?.("client-recovered", {
+                    ...getTelegramBusEndpointDiagnostics(resolvedOptions.socketPath),
+                    ...getTelegramBusEnvelopeDiagnostics(resolvedOptions.envelope),
+                    attempt,
+                    attempts,
+                });
+            return response;
         }
         catch (error) {
             const info = classifyTelegramBusTransportError(error);
-            resolvedOptions.recordTransportEvent?.("client-failed", {
-                ...getTelegramBusEndpointDiagnostics(resolvedOptions.socketPath),
-                ...getTelegramBusEnvelopeDiagnostics(resolvedOptions.envelope),
-                attempt,
-                attempts,
-                ...info,
-            });
-            if (error instanceof TelegramBusLocalAuthorityError ||
+            const final = error instanceof TelegramBusLocalAuthorityError ||
                 attempt >= attempts ||
-                !isRetryableTelegramBusTransportError(error)) {
+                !isRetryableTelegramBusTransportError(error);
+            if (attempt === 1 || final)
+                resolvedOptions.recordTransportEvent?.("client-failed", {
+                    ...getTelegramBusEndpointDiagnostics(resolvedOptions.socketPath),
+                    ...getTelegramBusEnvelopeDiagnostics(resolvedOptions.envelope),
+                    attempt,
+                    attempts,
+                    ...info,
+                });
+            if (final)
                 throw error;
-            }
-            resolvedOptions.recordTransportEvent?.("client-retry", {
-                ...getTelegramBusEndpointDiagnostics(resolvedOptions.socketPath),
-                ...getTelegramBusEnvelopeDiagnostics(resolvedOptions.envelope),
-                attempt,
-                attempts,
-                delayMs,
-                ...info,
-            });
+            if (attempt === 1)
+                resolvedOptions.recordTransportEvent?.("client-retry", {
+                    ...getTelegramBusEndpointDiagnostics(resolvedOptions.socketPath),
+                    ...getTelegramBusEnvelopeDiagnostics(resolvedOptions.envelope),
+                    attempt,
+                    attempts,
+                    delayMs,
+                    ...info,
+                });
             await delayTelegramBusTransportRetry(delayMs);
         }
     }

package/node_modules/@llblab/pi-telegram/dist/lib/commands.d.ts

@@ -627,6 +627,8 @@ export interface TelegramSelectedCommandAdmission {
     /** Independent exact recipient/target lifetime, including inside captured menu transport adapters. */
     assertRecipientCurrent(): void;
     reportCompleted(): boolean;
+    /** Optional recipient release barrier after acceptance; rejection suppresses effects without replay. */
+    beforeEffects?(): Promise<void>;
 }
 export declare function createTelegramCommandHandler<TMessage extends TelegramCommandRuntimeMessage, TContext>(deps: TelegramCommandRuntimeDeps<TMessage, TContext>): ((commandName: string | undefined, message: TMessage, ctx: TContext, commandArgs?: string) => Promise<boolean>) & {
     /** Command-only producer execution; Routing must supply the captured plan and released exact-source authority. */