@llblab/pi-kit 0.36.3 → 0.37.0

package/CHANGELOG.md

@@ -2,6 +2,11 @@
 
 All notable changes to `@llblab/pi-kit` are documented here.
 
+## 0.37.0: Bundled Package Updates (2026-10-25)
+
+- `Exact pins`: `@llblab/pi-telegram` 0.57.11 → 0.58.1.
+- `Packaging`: Synchronizes the lockfile, bundle aliases and README inventory. Package membership and resource order remain unchanged; packed validation does not certify extension safety or installed-client behavior.
+
 ## 0.36.3: Bundled Package Updates (2026-10-24)
 
 - `Exact pins`: `@llblab/pi-telegram` 0.57.7 → 0.57.11.

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.2` | 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.5` | 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.11` | 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.58.1` | 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.
@@ -27,7 +27,7 @@ Versions are exact by design. An upstream release does not change an installed k
 
 Requires **Pi 1.0.0+** and **Node.js 22.19.0+**. State Flow requires its canonical checkpoint/tail storage format and does not convert unsupported stores in place. Preserve existing stores and consult the [owning package's storage guidance](https://github.com/llblab/pi-state-flow/blob/v0.26.5/docs/usage.md#moving-a-store-and-supported-formats) before changing installations.
 
-From npm:
+From NPM:
 
 ```bash
 pi install npm:@llblab/pi-kit

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

@@ -109,7 +109,7 @@ Use the relevant local skill before non-trivial work in its domain. Keep skill o
 - In Threaded Mode, All is service/input-only. New output, previews, typing and routing UI require a concrete Thread; neither implicit fallback nor explicit aggregate delivery may write to All. Unavailable routing authority retains input without an All notice or silent settlement. Classic DM and explicit channel/business destinations remain separate; historical All output is not auto-cleaned.
 - Complete assistant/guest model answers use Telegram-native Rich Markdown. Harness-owned menus, status, diagnostics, thinking, and tool evidence remain explicit HTML/plain or their documented native surface. Before Telegram preview or final delivery, strip every assistant-authored HTML comment regardless of Markdown position while keeping action activation top-level-only; a comment-only result sends no text message. Preserve literal code outside comments and structurally safe chunking; never split invalid markup.
 - `preview` owns streaming lifecycle only, not assistant rendering. Finalization waits for the captured generation's preceding preview work, never later drafts blocked by that publication, and must not issue pre/post-final draft-clear calls that create transient Telegram draft UI. Reset/invalidation detaches predecessor dependencies; late settlements cannot mutate replacement state. Turns that already answer as one atomic reply (voice replies, Guest Mode queries) never stream previews.
-- Native `sendChatAction(typing)` is the automatic activity signal for unsettled agent and compaction work while Telegram transport is authorized. Extension-owned blocking UI prompts pause it and completion resumes it while either work owner remains active. Compaction may stop only a typing loop it actually started; it must preserve a pre-existing agent-owned loop. Refresh only the assigned Thread on a conservative three-second cadence; do not mirror typing to aggregate `All` and multiply shared-chat flood pressure. Typing is best-effort presence only, never a Thread-existence or message-delivery probe: a failed exact-target action remains a structured diagnostic and must not replace a healthy connected/leader/follower status with `error`. Do not invent extra in-chat work indicators or emit activity for startup/connect/reload/recovery alone.
+- Native `sendChatAction(typing)` is the automatic activity signal for unsettled agent and compaction work while Telegram transport is authorized. Extension-owned blocking UI prompts pause it and completion resumes it while either work owner remains active. Compaction may stop only a typing loop it actually started; it must preserve a pre-existing agent-owned loop. Refresh only the assigned Thread on a conservative three-second cadence; do not mirror typing to aggregate `All` and multiply shared-chat flood pressure. One Thread's pending action must not suppress another Thread's activity. Typing is best-effort presence only, never a Thread-existence or message-delivery probe: a failed exact-target action remains a structured diagnostic and must not replace a healthy connected/leader/follower status with `error`. Do not invent extra in-chat work indicators or emit activity for startup/connect/reload/recovery alone.
 - Public activity handlers and connected companion delivery are asynchronous, target-bound, generation-fenced surfaces. Connected companion projection has no independent opt-out: disconnect or authority loss is its boundary. Token deltas, hidden reasoning, unknown sources, and stale authority never enter public projection.
 - Profiles hold only bot identity and the paired owner; Settings-menu preferences live in shared top-level config. Thread display (`threads.displayMode`) defaults to the Letters strategy, with Names, Directory Snake, and Directory Title as the other automatic choices; Names projects the generated dictionary name for the slot. Unsupported retained display keys resolve to Letters without rewriting persisted configuration. A durable manual Thread display name retained on its Workspace binding overrides any automatic projection until exact reset; keep generated/recovery identity separate from manual and acknowledged display fields. After leader startup, automatic display contraction waits one follower-staleness window so election and follower re-registration cannot briefly remove and restore an acknowledged same-cwd suffix; stop/start generation cancels stale reconciliation. UI labels, emoji semantics, navigation, settings controls, callback namespaces, voice behavior, command templates, and assistant markup follow the linked `/docs` contracts. Generated human-readable action labels use `emoji + space + text`; emoji-free action text is only a reasoned no-semantic-marker fallback. State/value controls follow the [button control hierarchy](./docs/ui-style.md#button-control-hierarchy), not the action-label grammar. Non-spatial generated controls default to top-level vertical cells, with nested rows reserved for unmistakably compact peers. Do not restate other evolving UI details here.
 
@@ -134,7 +134,7 @@ The detailed map is canonical in [`docs/architecture.md`](./docs/architecture.md
 - Command templates remain compact and shell-free. Use string leaves or ordered `template` arrays; shell operators are not an execution contract. Examples use portable executable placeholders, never machine-local paths.
 - `telegram_attach` is the canonical file path and `telegram_message` the direct Markdown text/buttons path. Both require current direct or registered-follower authority and must not replace the normal active-turn reply.
 - Inbound handlers transform text/media before queueing; outbound handlers precede programmatic/provider fallbacks. Public contracts and ordering live in `docs/inbound.md`, `docs/outbound.md`, and `docs/public-api.md`.
-- Pi integration uses public hooks and APIs. Telegram `/new` is scheduled against the exact durable update, dispatched only after that update is removed from the journal, and then routed through the single `/telegram-internal` Pi gateway via `pi.sendUserMessage(..., { expandPromptTemplates: true })`; only a runtime-armed typed action may execute, manual invocation reports that the command cannot be run manually, and the handler receives the real `ExtensionCommandContext` before calling `ctx.newSession()`. Before replacement, CAS-publish one exact expiring handoff in the profile target snapshot. `workspace-thread` successors re-key the matching Workspace binding; `classic-chat` successors preserve Profile/CWD/session/chat continuity without creating a binding or invoking topic APIs. Both atomically claim the intent before one terminal result, and the old `withSession` path never publishes the same success. A registered follower cannot persist leader-owned state: its Workspace Thread intent is published and claimed by the leader over capability-gated exact-generation bus RPC after leader-side binding validation, and records its source runtime instance so only that follower lineage may re-key or claim it. Never replace the session while inbound authority is unsettled, store stale command contexts, accept an expired or mismatched handoff, inject terminal input, spawn a shadow Pi process, or mutate session files.
+- Pi integration uses public hooks and APIs. Telegram `/new` is scheduled against the exact durable update, dispatched only after that update is removed from the journal, and then routed through the `/telegram-connect --internal new <token>` Pi gateway via `pi.sendUserMessage(..., { expandPromptTemplates: true })`; the internal branch never enters profile activation or connection/recovery, only a runtime-armed one-use typed action may execute, manual invocation reports that the action cannot be run manually, and the handler receives the real `ExtensionCommandContext` before calling `ctx.newSession()`. Before replacement, CAS-publish one exact expiring handoff in the profile target snapshot. `workspace-thread` successors re-key the matching Workspace binding; `classic-chat` successors preserve Profile/CWD/session/chat continuity without creating a binding or invoking topic APIs. Both atomically claim the intent before one terminal result, and the old `withSession` path never publishes the same success. A registered follower cannot persist leader-owned state: its Workspace Thread intent is published and claimed by the leader over capability-gated exact-generation bus RPC after leader-side binding validation, and records its source runtime instance so only that follower lineage may re-key or claim it. Never replace the session while inbound authority is unsettled, store stale command contexts, accept an expired or mismatched handoff, inject terminal input, spawn a shadow Pi process, or mutate session files.
 
 ## 7. Engineering Conventions
 
@@ -145,7 +145,7 @@ The detailed map is canonical in [`docs/architecture.md`](./docs/architecture.md
 - Treat every meaningful `lib/extension.ts` edit as a composition-pressure check, but keep one-off live adapter wiring there when extraction would only hide cross-domain state.
 - Follow [`docs/ui-style.md`](./docs/ui-style.md) for interface copy, emoji, buttons, menus, and dialogs. Update the registry before assigning a new UI emoji meaning. Standalone notices use one fully bold emoji-led sentence with a terminal period; menu or chooser headings use the same hierarchy with a terminal colon. Material names may add nested italic emphasis without breaking the outer bold span. Callback toasts are fleeting plain text with no emoji and no terminal sentence period (question/exclamation marks and ellipses remain), written in that final form at their call site; no delivery boundary rewrites punctuation, and navigation taps answer silently. In-chat notices and explicit raw API payloads keep their punctuation.
 - Markdown lists never contain blank lines between adjacent items; list items are not paragraphs. Use blank lines only between paragraphs or independently separated blocks. Markdown tables use compact source formatting with `---` separator cells and one surrounding space per cell. Preserve vendored references unchanged.
-- Treat Windows filesystem, named-pipe, lock, heartbeat, and atomic-rename reports as high-signal evidence; reduce them to regressions or explicit platform caveats.
+- Treat Windows filesystem, named-pipe, lock, heartbeat, and atomic-rename reports as high-signal evidence; reduce them to regressions or explicit platform caveats. Process fixtures must distinguish bounded startup from post-readiness natural exit: arm the exit guard only after the declared checkpoint, retain a separate total cap, and ensure extra startup allowance cannot hide retained post-readiness handles.
 - Route significant runtime failures through the redacted recent-event recorder. Keep the compact TUI status at generic `error`; details belong in diagnostics.
 
 ## 8. Work Protocol

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

@@ -2,10 +2,10 @@
 
 _This file owns unresolved project work only. Completed behavior belongs in `CHANGELOG.md`; durable contracts belong in `AGENTS.md` and `/docs`._
 
-## 0.57.11 publication checkpoint
+## 0.58.1 publication checkpoint
 
-- [ ] Validate and publish only the pre-publication follower reply-target fix through the protected dev-to-main release path. Require fresh Ubuntu, Windows and both macOS shard checks before merge, exact candidate/merged-tree equality, one immutable version tag and the repository-owned release workflow.
-- [ ] Confirm the published GitHub Release and public npm version, tag/gitHead identity, release notes and packed runtime/skills before closing this checkpoint. Keep post-refusal recovery and disposable-tab live acceptance open; do not reload the running session.
+- [ ] Publish the independent Thread chat-action fix through the protected dev-to-main path, requiring fresh Ubuntu, Windows and both macOS shard checks at the exact candidate head and candidate/merged-tree equality. Keep the immutable Connect-only minor unchanged and verify its publication before issuing the hotfix tag.
+- [ ] Verify the hotfix GitHub Release and public npm latest, exact tag/gitHead identity, canonical notes, packed runtime/skills and provenance before closing this checkpoint. No live session reload or Telegram probes; controlled transport tests do not prove live client presence.
 
 ## Disposable Thread live acceptance
 
@@ -38,10 +38,10 @@ A target-scoped reply refusal cannot prove that a command made no prior effects.
 - [ ] Route an input that arrives in a tab bound to nothing through a fresh temporary routing tab (the All flow) instead of publishing the chooser in the orphan, deleting the orphan with it once nothing unspent remains. Needs its own durable-metadata design.
 - [ ] Live acceptance on disposable tabs only: Cancel on an orphan tab deletes it; a second unspent input keeps it until the last Cancel; a plain `std::map` option button is delivered as an ordinary prompt.
 
-## macOS process-exit test flake
+## Passive-child cold-import follow-up
 
-The 0.57.8 tag validation failed `Child process sharing the agent dir does not poll while parent owns Telegram lock` even when that file ran alone: `Child process did not exit. stdout= stderr=` at its existing child deadline. The other seven process tests and the identical pre-merge tree passed. That historical failure has no child-stage trace, so cold import, startup and a retained runtime handle remain competing explanations. Bounded diagnostic sampling is exhausted; passing traces showed imports up to 4.37 seconds against the five-second non-Windows child budget and natural exit within 8–14 ms after the event-loop checkpoint. These traces do not identify the original cause.
-- [ ] Retain bounded child-stage/resource diagnostics for the next genuinely failing passive-child trace; the original timeout is still unexplained. Do not spend more unchanged-head diagnostic samples. The parent records explicit shutdown separately; do not add a shutdown call to the passive child to make it pass. Correct a fixture/runtime cause only when the failing stage evidence supports it, and require fresh platform CI before resuming release recovery. Do not widen deadlines or describe the runner as the proven cause without measurement.
+The 0.57.8 tag validation failed `Child process sharing the agent dir does not poll while parent owns Telegram lock` even when that file ran alone: `Child process did not exit. stdout= stderr=` at its existing child deadline. The other seven process tests and the identical pre-merge tree passed. That historical failure has no child-stage trace, so cold import, startup and a retained runtime handle remain competing explanations. Bounded diagnostic sampling is exhausted; passing traces showed imports up to 4.37 seconds against the five-second non-Windows child budget and natural exit within 8–14 ms after the event-loop checkpoint. These traces do not identify the original cause. A later main-validation recurrence stopped after `eval` and `import-start`, with parent-clock `elapsedMs=5009` and no import-complete checkpoint. That trace locates this recurrence before import completion, not in natural exit or a retained post-checkpoint handle; the slow dependency/startup cause remains unknown. The independent tag-owned Release validation passed the same committed tree, which does not erase the failed main check. The initial hotfix candidate then showed the same pre-import-completion state on Ubuntu at `elapsedMs=5026`; the recurrence is not macOS-only. Slow dependency/startup cost remains unexplained, separate from the fixture's corrected startup/exit observation contract.
+- [ ] Validate the corrected phase-owned passive-child fixture in fresh complete platform CI before publication: bounded total startup, a strict post-readiness exit guard, unchanged no-poll/natural-exit assertions and no forced shutdown or retry. Controlled delayed-start/retained-work regressions and local native passes are not platform proof. For any genuine recurrence, preserve deadline and stage evidence before correcting runtime imports or budgets. Do not spend unchanged-head diagnostic samples or claim runner contention or the historical cause is proven.
 
 ## Windows Workspace-gate fixture timeout
 

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

@@ -4,6 +4,15 @@
 
 ## Unreleased
 
+## 0.58.1: Independent Thread Typing
+
+- `Typing`: A pending activity request in one Thread no longer silently suppresses another Thread's typing. Exact chat/Thread/action calls still coalesce with their own minimum interval, while real Telegram 429 cooldowns remain shared across the chat, including late failures after a faster peer completes. Authority checks, one-attempt typing and bounded gate storage remain intact.
+- `Process validation`: Passive-child checks distinguish cold startup from natural exit: a 15-second total cap retains the existing Windows bound, while a separate five-second guard starts after the event-loop checkpoint on every platform. Regressions reject both a missing checkpoint and retained post-checkpoint work; no polling assertions, natural-exit requirement or job budgets are weakened.
+
+## 0.58.0: Unified Connect Gateway
+
+- `Pi commands`: Removes the standalone `/telegram-internal` gateway. Runtime-armed session replacement now dispatches `/telegram-connect --internal new <token>` after exact durable update completion. Internal calls bypass profile activation and connection/recovery; malformed, unarmed and replayed calls fail closed. `internal` remains a valid profile name.
+
 ## 0.57.11: Follower Reply Target
 
 - `Follower command replies`: Status/model/settings and text replies from an admitted follower command select its acknowledged Thread before publication, not the old input Thread. A changed Thread drops the reply anchor; delivery, menu state and ownership use one destination. The journaled original and explicit selected-menu grants stay intact; no refused-send recovery, handler replay or proxy widening is added.

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

@@ -201,6 +201,7 @@ export declare function createTelegramLiveTargetWorkObserver<TContext>(deps: {
 }, ctx: TContext) => TelegramBusLiveRebindWorkState;
 interface TelegramCommandsAndToolsBindingDeps {
     pi: Pi.ExtensionAPI;
+    handleInternalAction: Commands.TelegramSessionActionRuntime["handleInternalAction"];
     agentDir: string;
     configStore: Config.TelegramConfigStore;
     persistConfig: (config?: Config.TelegramConfig) => Promise<void>;
@@ -241,7 +242,7 @@ interface TelegramCommandsAndToolsBindingDeps {
     connectionIntent: NonNullable<Commands.TelegramBridgeCommandRegistrationDeps["connectionIntent"]>;
     recordRuntimeEvent: TelegramRuntimeEventRecorder;
 }
-export declare function registerTelegramCommandsAndTools({ pi, agentDir, configStore, persistConfig, setup, activeTurnRuntime, lockedPollingRuntime, stopPolling, getDisconnectThreadName, onTransportChanged, getStatusLines, buttonActionStore, sendMarkdownReply, sendChannelMarkdownMessage, sendChannelMediaMessage, listChannelPosts, mutateChannelPost, callMultipart, getDefaultChatId, getDefaultTarget, resolveAgentTarget, routeAgentMessage, canSendDirect, setGenerativeAppLiveSurfaceRuntime, recordRuntimeEvent, updateStatus, isContextCurrent, getSessionGeneration, connectionIntent, }: TelegramCommandsAndToolsBindingDeps): void;
+export declare function registerTelegramCommandsAndTools({ pi, handleInternalAction, agentDir, configStore, persistConfig, setup, activeTurnRuntime, lockedPollingRuntime, stopPolling, getDisconnectThreadName, onTransportChanged, getStatusLines, buttonActionStore, sendMarkdownReply, sendChannelMarkdownMessage, sendChannelMediaMessage, listChannelPosts, mutateChannelPost, callMultipart, getDefaultChatId, getDefaultTarget, resolveAgentTarget, routeAgentMessage, canSendDirect, setGenerativeAppLiveSurfaceRuntime, recordRuntimeEvent, updateStatus, isContextCurrent, getSessionGeneration, connectionIntent, }: TelegramCommandsAndToolsBindingDeps): void;
 interface TelegramLifecycleBindingDeps {
     pi: Pi.ExtensionAPI;
     publicationRuntime: TelegramBridgePublicationRuntime;

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

@@ -497,7 +497,7 @@ export function createTelegramLiveTargetWorkObserver(deps) {
         };
     };
 }
-export function registerTelegramCommandsAndTools({ pi, agentDir, configStore, persistConfig, setup, activeTurnRuntime, lockedPollingRuntime, stopPolling, getDisconnectThreadName, onTransportChanged, getStatusLines, buttonActionStore, sendMarkdownReply, sendChannelMarkdownMessage, sendChannelMediaMessage, listChannelPosts, mutateChannelPost, callMultipart, getDefaultChatId, getDefaultTarget, resolveAgentTarget, routeAgentMessage, canSendDirect, setGenerativeAppLiveSurfaceRuntime, recordRuntimeEvent, updateStatus, isContextCurrent, getSessionGeneration, connectionIntent, }) {
+export function registerTelegramCommandsAndTools({ pi, handleInternalAction, agentDir, configStore, persistConfig, setup, activeTurnRuntime, lockedPollingRuntime, stopPolling, getDisconnectThreadName, onTransportChanged, getStatusLines, buttonActionStore, sendMarkdownReply, sendChannelMarkdownMessage, sendChannelMediaMessage, listChannelPosts, mutateChannelPost, callMultipart, getDefaultChatId, getDefaultTarget, resolveAgentTarget, routeAgentMessage, canSendDirect, setGenerativeAppLiveSurfaceRuntime, recordRuntimeEvent, updateStatus, isContextCurrent, getSessionGeneration, connectionIntent, }) {
     GenerativeApps.registerTelegramBindTool(pi, {
         agentDir,
         getActiveProfileName: configStore.getActiveProfileName,
@@ -551,6 +551,7 @@ export function registerTelegramCommandsAndTools({ pi, agentDir, configStore, pe
         }, { deliverAs: "nextTurn" });
     };
     Commands.registerTelegramBridgeCommands(pi, {
+        handleInternalAction,
         promptForConfig: async (ctx, profileName) => {
             const nextProfileName = profileName ?? undefined;
             if (profileName && !Config.isValidTelegramProfileName(profileName)) {

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

@@ -166,6 +166,7 @@ export interface TelegramBridgeCommandStartPollingResult {
     owner?: string;
 }
 export interface TelegramBridgeCommandRegistrationDeps {
+    handleInternalAction?: TelegramSessionActionRuntime["handleInternalAction"];
     promptForConfig: (ctx: ExtensionCommandContext, profileName?: string) => Promise<void>;
     getStatusLines: (options?: TelegramBridgeStatusLineOptions) => string[];
     reloadConfig: () => Promise<void>;
@@ -661,11 +662,10 @@ export declare function createTelegramCommandHandler<TMessage extends TelegramCo
     prepareSelectedMenuCommand(command: ParsedTelegramCommand, messages: readonly TMessage[], ctx: TContext, admission: TelegramSelectedCommandAdmission): (() => Promise<boolean>) | undefined;
 };
 export declare function createTelegramCommandOrPromptDispatcher<TMessage, TContext>(deps: TelegramCommandOrPromptDispatcherDeps<TMessage, TContext>): (messages: TMessage[], ctx: TContext) => Promise<void>;
-export declare const TELEGRAM_INTERNAL_COMMAND_NAME = "telegram-internal";
-export declare const TELEGRAM_INTERNAL_COMMAND_DESCRIPTION = "Internal Telegram command cannot be run manually";
-export declare const TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE = "This internal Telegram command cannot be run manually.";
+export declare const TELEGRAM_CONNECT_COMMAND_NAME = "telegram-connect";
+export declare const TELEGRAM_INTERNAL_COMMAND_FLAG = "--internal";
+export declare const TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE = "This internal Telegram action cannot be run manually.";
 export interface TelegramSessionActionRuntimeDeps {
-    registerCommand: Pi.ExtensionAPI["registerCommand"];
     sendUserMessage: Pi.ExtensionAPI["sendUserMessage"];
     notifyResult: (target: {
         chatId: number;
@@ -697,7 +697,6 @@ export interface TelegramSessionReplacementSettlementDeps {
 }
 export declare function settleTelegramSessionReplacement(deps: TelegramSessionReplacementSettlementDeps): Promise<"none" | "settled" | "expired" | "failed" | "stale">;
 export interface TelegramSessionActionAssemblyDeps {
-    registerCommand: Pi.ExtensionAPI["registerCommand"];
     sendUserMessage: Pi.ExtensionAPI["sendUserMessage"];
     store: {
         load: () => Promise<void>;
@@ -753,7 +752,7 @@ export declare function createTelegramSessionActionAssembly(deps: TelegramSessio
     };
 };
 export interface TelegramSessionActionRuntime {
-    register: () => void;
+    handleInternalAction: (args: string, ctx: Pi.ExtensionCommandContext) => Promise<void>;
     scheduleAfterUpdate: (updateId: number, target: {
         chatId: number;
         threadId?: number;

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

@@ -405,6 +405,7 @@ function formatTelegramTakeoverPrompt(ctx, owner) {
     return `${action}\n\n${from} ${source}\n${to} ${ctx.cwd}`;
 }
 export function registerTelegramBridgeCommands(pi, deps) {
+    const handleInternalAction = deps.handleInternalAction;
     pi.registerCommand("telegram-setup", {
         description: "<profile> — Configure Telegram bot token",
         handler: async (args, ctx) => {
@@ -418,9 +419,19 @@ export function registerTelegramBridgeCommands(pi, deps) {
             ctx.ui.notify(deps.getStatusLines({ verbose }).join("\n"), "info");
         },
     });
-    pi.registerCommand("telegram-connect", {
+    pi.registerCommand(TELEGRAM_CONNECT_COMMAND_NAME, {
         description: "<profile> — Start Telegram bridge",
         handler: async (args, ctx) => {
+            const words = args.trim().split(/\s+/);
+            // Service dispatch never inherits profile activation or explicit-connect recovery authority.
+            if (words.some(word => word.toLowerCase().startsWith(TELEGRAM_INTERNAL_COMMAND_FLAG))) {
+                if (words[0] !== TELEGRAM_INTERNAL_COMMAND_FLAG || !handleInternalAction) {
+                    ctx.ui.notify(TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE, "warning");
+                    return;
+                }
+                await handleInternalAction(words.slice(1).join(" "), ctx);
+                return;
+            }
             const sessionGeneration = deps.getSessionGeneration?.();
             let intentId;
             // Pi context getters throw after replacement; check plain intent/generation first.
@@ -2415,9 +2426,9 @@ async function handleTelegramCommandRuntime(commandName, message, ctx, deps, com
         },
     }, commandArgs);
 }
-export const TELEGRAM_INTERNAL_COMMAND_NAME = "telegram-internal";
-export const TELEGRAM_INTERNAL_COMMAND_DESCRIPTION = "Internal Telegram command cannot be run manually";
-export const TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE = "This internal Telegram command cannot be run manually.";
+export const TELEGRAM_CONNECT_COMMAND_NAME = "telegram-connect";
+export const TELEGRAM_INTERNAL_COMMAND_FLAG = "--internal";
+export const TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE = "This internal Telegram action cannot be run manually.";
 function delayTelegramSessionAction(delayMs) {
     return new Promise((resolve) => setTimeout(resolve, delayMs));
 }
@@ -2487,7 +2498,6 @@ export function createTelegramSessionActionAssembly(deps) {
         report(new Error("Telegram new-session result delivery failed."));
     };
     const action = createTelegramSessionActionRuntime({
-        registerCommand: deps.registerCommand,
         sendUserMessage: deps.sendUserMessage,
         notifyResult(target, result) {
             return sendTerminalResult(target, result);
@@ -2585,7 +2595,6 @@ export function createTelegramSessionActionRuntime(deps) {
     let pendingUpdateId;
     let pendingTarget;
     let pendingAction;
-    let registered = false;
     const reportFailure = (error) => {
         try {
             deps.recordRuntimeEvent?.("new-session", error);
@@ -2595,35 +2604,29 @@ export function createTelegramSessionActionRuntime(deps) {
         }
     };
     return {
-        register() {
-            if (registered)
+        async handleInternalAction(args, ctx) {
+            const action = pendingAction;
+            const [operation, token, ...extra] = args.trim().split(/\s+/);
+            if (!action || operation !== "new" ||
+                token !== action.token || extra.length !== 0) {
+                ctx.ui.notify(TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE, "warning");
                 return;
-            registered = true;
-            deps.registerCommand(TELEGRAM_INTERNAL_COMMAND_NAME, {
-                description: TELEGRAM_INTERNAL_COMMAND_DESCRIPTION,
-                handler: async (args, ctx) => {
-                    const action = pendingAction;
-                    if (!action || args.trim() !== action.token) {
-                        ctx.ui.notify(TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE, "warning");
-                        return;
+            }
+            pendingAction = undefined;
+            switch (action.kind) {
+                case "replace-session":
+                    try {
+                        await deps.prepareReplacement?.(ctx, action.updateId, action.target);
+                        const result = await ctx.newSession();
+                        if (result.cancelled)
+                            await deps.notifyResult(action.target, "cancelled");
                     }
-                    pendingAction = undefined;
-                    switch (action.kind) {
-                        case "replace-session":
-                            try {
-                                await deps.prepareReplacement?.(ctx, action.updateId, action.target);
-                                const result = await ctx.newSession();
-                                if (result.cancelled)
-                                    await deps.notifyResult(action.target, "cancelled");
-                            }
-                            catch (error) {
-                                reportFailure(error);
-                                await deps.notifyResult(action.target, "failure");
-                            }
-                            return;
+                    catch (error) {
+                        reportFailure(error);
+                        await deps.notifyResult(action.target, "failure");
                     }
-                },
-            });
+                    return;
+            }
         },
         scheduleAfterUpdate(updateId, target) {
             if (pendingUpdateId !== undefined || pendingAction !== undefined)
@@ -2643,9 +2646,7 @@ export function createTelegramSessionActionRuntime(deps) {
             const token = randomUUID();
             pendingAction = { kind: "replace-session", token, updateId, target };
             void Promise.resolve()
-                .then(() => deps.sendUserMessage(`/${TELEGRAM_INTERNAL_COMMAND_NAME} ${token}`, {
-                expandPromptTemplates: true,
-            }))
+                .then(() => deps.sendUserMessage(`/${TELEGRAM_CONNECT_COMMAND_NAME} ${TELEGRAM_INTERNAL_COMMAND_FLAG} new ${token}`, { expandPromptTemplates: true }))
                 .catch((error) => {
                 pendingAction = undefined;
                 reportFailure(error);

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

@@ -80,7 +80,7 @@ const telegramBusProtocolIdentity = Bus.createTelegramCurrentBusProtocolIdentity
 export default function (pi) {
     Skills.registerTelegramSkillDiscovery(pi);
     const piRuntime = Pi.createExtensionApiRuntimePorts(pi);
-    const { getActiveTools, getCommands, getThinkingLevel, sendUserMessage, registerCommand, setActiveTools, setModel, setThinkingLevel, } = piRuntime;
+    const { getActiveTools, getCommands, getThinkingLevel, sendUserMessage, setActiveTools, setModel, setThinkingLevel, } = piRuntime;
     const bridgeRuntime = Runtime.createTelegramBridgeRuntime();
     const runtimeDiagnostics = Logging.createTelegramRuntimeDiagnosticsRuntime({
         sharedFile: true,
@@ -242,7 +242,6 @@ export default function (pi) {
         captureAuthority: captureTelegramStateAuthority,
     });
     const sessionActionAssembly = Commands.createTelegramSessionActionAssembly({
-        registerCommand,
         sendUserMessage,
         store: threadStore,
         getProfileName: configStore.getActiveProfileName,
@@ -2293,9 +2292,9 @@ export default function (pi) {
             }
         },
     }.reset);
-    sessionActionsRuntime.register();
     Bindings.registerTelegramCommandsAndTools({
         pi,
+        handleInternalAction: sessionActionsRuntime.handleInternalAction,
         agentDir: Paths.resolveAgentDir(),
         configStore,
         persistConfig: persistTelegramConfigWithSync,

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

@@ -1039,6 +1039,7 @@ export function createTelegramBridgeApiRuntime(deps) {
     const chatActionMinIntervalMs = Math.max(0, deps.chatActionMinIntervalMs ?? 2_000);
     const chatActionMaxGates = Math.max(1, deps.chatActionMaxGates ?? 256);
     const chatActionGates = new Map();
+    // Pin shared cooldowns until every concurrent Thread settles; this state never owns their sends.
     const chatActionChatGates = new Map();
     const getChatActionKeys = (method, body) => {
         if (method !== "sendChatAction")
@@ -1069,7 +1070,7 @@ export function createTelegramBridgeApiRuntime(deps) {
                 }
             }
             for (const [key, candidate] of chatActionChatGates) {
-                if (!candidate.inFlight && nowMs >= candidate.notBeforeMs) {
+                if (candidate.pendingRequests === 0 && nowMs >= candidate.notBeforeMs) {
                     chatActionChatGates.delete(key);
                 }
             }
@@ -1085,13 +1086,11 @@ export function createTelegramBridgeApiRuntime(deps) {
                 if (chatActionChatGates.size >= chatActionMaxGates) {
                     return true;
                 }
-                chatGate = { notBeforeMs: 0 };
+                chatGate = { pendingRequests: 0, notBeforeMs: 0 };
                 chatActionChatGates.set(chatActionKeys.chat, chatGate);
             }
             if (gate.inFlight)
                 return (await gate.inFlight);
-            if (chatGate.inFlight)
-                return true;
             if (nowMs < gate.notBeforeMs || nowMs < chatGate.notBeforeMs) {
                 return true;
             }
@@ -1127,11 +1126,10 @@ export function createTelegramBridgeApiRuntime(deps) {
                 .finally(() => {
                 if (gate.inFlight === request)
                     gate.inFlight = undefined;
-                if (chatGate.inFlight === request)
-                    chatGate.inFlight = undefined;
+                chatGate.pendingRequests--;
             });
             gate.inFlight = request;
-            chatGate.inFlight = request;
+            chatGate.pendingRequests++;
             return request;
         }
         try {

package/node_modules/@llblab/pi-telegram/dist/package.json

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

package/node_modules/@llblab/pi-telegram/docs/architecture.md

@@ -42,7 +42,7 @@ Keep this boundary explicit:
 
 ### Instance, Session, And Context Cost
 
-Live Telegram routing belongs to the active authenticated Pi instance, while a durable Workspace Thread belongs to the exact profile/CWD/session identity. Ordinary Telegram prompts enter the session currently bound to that target. Local `/resume` replaces session-scoped runtime state and selects the destination session's binding; it never inherits the source Thread merely because the process is unchanged. Telegram exposes compaction and new-session replacement for the active session: `/new` first completes and removes its exact durable update, then dispatches an internal registered Pi command through `pi.sendUserMessage(..., { expandPromptTemplates: true })` so the handler runs with a real `ExtensionCommandContext` and calls the same `AgentSessionRuntime.newSession()` path as the terminal. Before invoking that path, the current transport owner CAS-publishes one expiring replacement intent inside the existing profile target snapshot. The intent discriminates `workspace-thread` from `classic-chat`. A same- or cross-process successor may consume either only for the exact profile, CWD, source session, target, and fresh lifetime: Threaded continuity re-keys the retained Workspace binding and preserves Thread, slot, and display identity, while Classic continuity preserves the exact chat target without creating a Workspace binding or entering topic lifecycle APIs. A confirmed callback is acknowledged and its dialog is deleted before session replacement begins. Once the successor has delivery authority, it atomically claims the intent by CAS-clearing it and then sends one separate terminal success result with bounded in-process transport retry. The old `withSession` path never publishes success, and an unclaimed intent never sends, preventing duplicate terminal notices across same-process startup and cleanup-ack ambiguity. Mismatch or expiry never authorizes binding takeover. Resume, fork, tree navigation, session switching, and full reload remain outside the stable Telegram API until Pi exposes safe public extension hooks for them.
+Live Telegram routing belongs to the active authenticated Pi instance, while a durable Workspace Thread belongs to the exact profile/CWD/session identity. Ordinary Telegram prompts enter the session currently bound to that target. Local `/resume` replaces session-scoped runtime state and selects the destination session's binding; it never inherits the source Thread merely because the process is unchanged. Telegram exposes compaction and new-session replacement for the active session: `/new` first completes and removes its exact durable update, then dispatches the runtime-armed `/telegram-connect --internal new <token>` branch through `pi.sendUserMessage(..., { expandPromptTemplates: true })`, without entering ordinary Connect profile or transport startup, so the handler runs with a real `ExtensionCommandContext` and calls the same `AgentSessionRuntime.newSession()` path as the terminal. Before invoking that path, the current transport owner CAS-publishes one expiring replacement intent inside the existing profile target snapshot. The intent discriminates `workspace-thread` from `classic-chat`. A same- or cross-process successor may consume either only for the exact profile, CWD, source session, target, and fresh lifetime: Threaded continuity re-keys the retained Workspace binding and preserves Thread, slot, and display identity, while Classic continuity preserves the exact chat target without creating a Workspace binding or entering topic lifecycle APIs. A confirmed callback is acknowledged and its dialog is deleted before session replacement begins. Once the successor has delivery authority, it atomically claims the intent by CAS-clearing it and then sends one separate terminal success result with bounded in-process transport retry. The old `withSession` path never publishes success, and an unclaimed intent never sends, preventing duplicate terminal notices across same-process startup and cleanup-ack ambiguity. Mismatch or expiry never authorizes binding takeover. Resume, fork, tree navigation, session switching, and full reload remain outside the stable Telegram API until Pi exposes safe public extension hooks for them.
 
 `/telegram-connect` never launches a hidden or headless Pi process. A long-lived background Pi process can own Telegram only when something else explicitly launched that process and it satisfies the normal lock/runtime rules. Pi `print` and `json` modes stay passive and exit rather than becoming hidden polling owners.
 
@@ -685,7 +685,7 @@ Native typing during compaction follows connected-instance activity rather than
 - Thread-targeted typing is sent only to the concrete thread. Aggregate `All` mirroring is intentionally omitted because duplicating every keepalive multiplies shared-chat flood pressure. Compaction completion, failure, or timeout stops only a loop actually started by the compaction observer; a pre-existing agent-owned loop remains active. Ownership is sticky across a repeated compaction start, whose shared-loop start reports `false` for the observer's own running loop. Authority loss and shutdown still stop the keyed loop.
 - Pi `ui_prompt_start` pauses typing while an extension-owned local prompt waits for the operator; `ui_prompt_end` emits the matching Activity boundary and resumes typing whenever agent or compaction work remains unsettled.
 
-At every connected instance `agent_start`, the lifecycle binding starts Telegram's native `…typing` indicator in that instance's assigned target, whether the run came from Telegram, the local TUI, or an autonomous continuation such as Grow Loop. Terminal `Active` remains Telegram-turn-specific; the native indicator answers the separate question of whether the instance is doing agent work. Streaming keepalives reuse a valid typing owner with the same session generation, transport and target rather than revoking its pending HTTP/IPC action. Fresh context wrappers may reuse that owner within a proven generation; without generation evidence, context identity must match. Explicit queue dispatch and Telegram prompt handoff still replace the owner. Queue dispatch carries the queued turn's exact target into typing before `agent_start`, rather than reducing it to a chat ID. In Threaded Mode, missing or invalid Thread targets are refused before starting a loop or invoking the API; mode changes also invalidate a captured Classic chat-only loop. A rejected start never replaces an existing valid Thread loop. The starter also requires the captured Pi context and session generation to remain current at start, queued send, tick and late failure boundaries, even if the transport epoch is unchanged; replacing a context object in place cannot revive old activity. Message activity hooks capture generation across awaited preview work, and agent-start bindings recheck it before post-await activity/typing, so an obsolete finally or continuation cannot acquire replacement ownership. The typing sender carries its captured loop/context/generation/transport assertion as process-local call authority: direct API issuance rechecks it after queued work, and the follower caller rechecks it after registration waits and immediately before socket issuance without putting callbacks in IPC data. Automatic typing uses one HTTP attempt with no transport-family fallback or delayed replay, including forwarded calls; a future keepalive is a fresh owner-checked attempt. An already issued HTTP/RPC cannot be retroactively unsent. Each loop refreshes its exact target every three seconds and keeps one action in flight. The leader API runtime coalesces identical chat/thread/action calls for two seconds, permits at most one concurrent chat action per chat, and shares a Telegram 429 `retry_after` fence across every Thread key in that chat; expired gates prune opportunistically and each gate family retains at most 256 active keys. Suppression never schedules a delayed retry. A failed typing action remains a structured diagnostic but cannot project `error` onto an otherwise healthy connected/leader/follower status. Assistant message start/update hooks still re-arm typing during Telegram-owned turns so transient provider/model errors do not leave a continuing run without activity feedback, and agent/session completion stops it.
+At every connected instance `agent_start`, the lifecycle binding starts Telegram's native `…typing` indicator in that instance's assigned target, whether the run came from Telegram, the local TUI, or an autonomous continuation such as Grow Loop. Terminal `Active` remains Telegram-turn-specific; the native indicator answers the separate question of whether the instance is doing agent work. Streaming keepalives reuse a valid typing owner with the same session generation, transport and target rather than revoking its pending HTTP/IPC action. Fresh context wrappers may reuse that owner within a proven generation; without generation evidence, context identity must match. Explicit queue dispatch and Telegram prompt handoff still replace the owner. Queue dispatch carries the queued turn's exact target into typing before `agent_start`, rather than reducing it to a chat ID. In Threaded Mode, missing or invalid Thread targets are refused before starting a loop or invoking the API; mode changes also invalidate a captured Classic chat-only loop. A rejected start never replaces an existing valid Thread loop. The starter also requires the captured Pi context and session generation to remain current at start, queued send, tick and late failure boundaries, even if the transport epoch is unchanged; replacing a context object in place cannot revive old activity. Message activity hooks capture generation across awaited preview work, and agent-start bindings recheck it before post-await activity/typing, so an obsolete finally or continuation cannot acquire replacement ownership. The typing sender carries its captured loop/context/generation/transport assertion as process-local call authority: direct API issuance rechecks it after queued work, and the follower caller rechecks it after registration waits and immediately before socket issuance without putting callbacks in IPC data. Automatic typing uses one HTTP attempt with no transport-family fallback or delayed replay, including forwarded calls; a future keepalive is a fresh owner-checked attempt. An already issued HTTP/RPC cannot be retroactively unsent. Each loop refreshes its exact target every three seconds and keeps one action in flight. The leader API runtime coalesces identical chat/thread/action calls for two seconds, admits different Threads independently, and shares a real Telegram 429 `retry_after` fence across every Thread key in that chat. A pending-request count retains that shared state until every concurrent action settles, so completion of a faster peer cannot orphan a late 429; expired gates prune opportunistically and each gate family retains at most 256 active keys. Suppression never schedules a delayed retry. A failed typing action remains a structured diagnostic but cannot project `error` onto an otherwise healthy connected/leader/follower status. Assistant message start/update hooks still re-arm typing during Telegram-owned turns so transient provider/model errors do not leave a continuing run without activity feedback, and agent/session completion stops it.
 
 ### Rendering And Delivery
 

package/node_modules/@llblab/pi-telegram/docs/multi-instance-bus.md

@@ -485,7 +485,7 @@ Threaded Mode should make follower threads behave like normal Telegram instance
 | Replies/finals                   | Final replies land in the same thread                                                                                                                                                                                                                 | Follower finals go through leader transport into follower thread                                                                                                                                                                                                | Outbound calls carry target and inject `message_thread_id`                                                                                                                                                                                          | Reply delivery and bus API tests                                                                                          |
 | Previews/Rich Drafts             | Draft previews use the active thread target                                                                                                                                                                                                           | Follower previews use the same native draft lifecycle through the leader                                                                                                                                                                                        | Preview transport preserves target and draft id                                                                                                                                                                                                     | Preview thread-target tests                                                                                               |
 | Attachments/voice                | Files and voice upload in the instance thread                                                                                                                                                                                                         | Follower uploads route through leader multipart transport                                                                                                                                                                                                       | Multipart calls are target-scoped and follower-authorized                                                                                                                                                                                           | Bus allowlist and outbound delivery tests                                                                                 |
-| Native activity status           | `sendChatAction(typing)` refreshes Telegram's native `…typing` indicator only in the assigned Thread for every agent run, including local and autonomous work; aggregate `All` is not mirrored, terminal identity remains `connected`, and active work stays included in the green Queue count | Followers route the exact Thread action through leader transport while retaining their stable terminal `follower` identity and green activity count; the leader admits one concurrent action per chat and shares Telegram 429 cooldown across that chat's Thread keys                                                                                       | Agent lifecycle targets the active Telegram turn when present and otherwise the instance binding; one keyed loop avoids duplicate aggregate sends/rate-limit pressure                                                                               | Agent-start binding, typing-loop, target-routing, and terminal-status regressions                                         |
+| Native activity status           | `sendChatAction(typing)` refreshes Telegram's native `…typing` indicator only in the assigned Thread for every agent run, including local and autonomous work; aggregate `All` is not mirrored, terminal identity remains `connected`, and active work stays included in the green Queue count | Followers route the exact Thread action through leader transport while retaining their stable terminal `follower` identity and green activity count; the leader admits different Threads independently, coalesces exact chat/Thread/action calls and shares real Telegram 429 cooldown across that chat's Thread keys                                                                                       | Agent lifecycle targets the active Telegram turn when present and otherwise the instance binding; one keyed loop avoids duplicate aggregate sends/rate-limit pressure                                                                               | Agent-start binding, typing-loop, target-routing, and terminal-status regressions                                         |
 | Leader election / promotion      | Current leader keeps its thread across reload                                                                                                                                                                                                         | A promoted follower keeps its existing thread, slot, and name when elected and after later reload                                                                                                                                                               | Promotion converts the current follower binding into the leader profile before forced lock acquisition, so leader startup reuses it instead of provisioning a new thread                                                                            | Follower heartbeat recovery passes binding snapshot into promotion; own-topic provisioner reuses promoted bindings        |
 | `/start` command/menu bootstrap  | Registers visible bot commands and opens the menu                                                                                                                                                                                                     | Follower `/start` can refresh the bot command menu through the leader and open its local menu without warnings                                                                                                                                                  | Bot command registration is a validated global Bot API call allowed through trusted follower bus transport                                                                                                                                          | Bus allowlist regression for `setMyCommands`                                                                              |
 | Follower reconnect               | Existing leader binding is reused only when still usable                                                                                                                                                                                              | Same-process `/new` or `/reload` suspends the old follower socket/context and automatically re-registers the new session to the exact prior target; explicit reconnect to a genuinely closed/stale Telegram tab still recreates a visible thread before success | A short-lived handoff carries the assigned target across session replacement, and the leader transfers that binding to the new runtime instance id by stable manual-follower identity; stale Bot API errors remain the proof for fresh provisioning | Session handoff/refresh, leader binding-transfer, persisted leader-reload reuse, and stale-target replacement regressions |

package/node_modules/@llblab/pi-telegram/docs/public-api.md

@@ -44,6 +44,8 @@ Stable commands inside Pi:
 - `/telegram-disconnect` — after destructive confirmation, stop polling and release ownership without deleting or silencing accepted local queue state. A successful command queues the corresponding hidden, non-triggering disconnected context note; cancelled or failed disconnects do not publish a false state transition. In Threaded Mode it deletes this instance's current Telegram thread; a follower waits for its active leader to confirm generation-fenced cleanup before stopping. Graceful Pi `quit` performs the same teardown without prompting, while session replacement suspends transport without disconnect teardown. Local `/resume` carries connection intent rather than the source Thread; other supported replacements retain their existing continuity rules.
 - `/telegram-status` — show connection, polling, execution, queue, and recent event diagnostics; debug output separates poller and worker progress, durable automatic-retry state, exact foreign queued-owner identity, and negotiated protocol/build/capabilities.
 
+The `/telegram-connect --internal new <token>` form is a runtime-only dispatch, not a profile connection or a manual new-session shortcut. It requires the exact prepared one-use action and bypasses profile activation, connection intents and startup/recovery. Missing, forged, replayed, unsupported or malformed internal calls fail closed; invalid calls do not consume a valid pending action. The flag is reserved, but `internal` without the leading dashes remains a valid profile name. The standalone `/telegram-internal` command is no longer registered.
+
 ### Telegram commands
 
 - `/name Name` — set the durable manual display name of the current Thread. The routed leader or follower uses the authenticated target-fenced mutation and edits the visible title over the active automatic projection. Bare `/name` immediately opens expiring exact-target input; the next valid name is consumed before agent dispatch. Cancel is always available; **Reset to automatic** appears only when a manual name exists. Entering a bare uppercase slot letter such as `A` is also treated as an explicit reset to the current automatic display projection rather than as a manual name.
@@ -51,7 +53,7 @@ Stable commands inside Pi:
 Stable commands inside the paired Telegram DM:
 
 - `/start` — pair when needed and open the main application menu.
-- `/new` — after idle and empty-queue checks, request a new Pi session in the current classic chat or Thread. The bridge acknowledges the callback, deletes its confirmation, completes and removes the exact durable update, then dispatches one runtime-armed typed action through the internal `/telegram-internal` Pi gateway using `pi.sendUserMessage(..., { expandPromptTemplates: true })`. Manual invocation reports that the gateway cannot be run manually; the armed handler receives a real `ExtensionCommandContext` and calls `ctx.newSession()`; one discriminated durable intent preserves either exact classic Profile/CWD/session/chat continuity or the Thread binding with slot/name re-key. The successor CAS-claims that intent before sending one terminal result. In a follower Thread the leader publishes and claims the intent on the follower's behalf over capability-gated, exact-generation local bus requests; followers never persist leader-owned state. Busy, identity-mismatch, stale-registration, incompatible-leader, and unavailable-host paths fail closed.
+- `/new` — after idle and empty-queue checks, request a new Pi session in the current classic chat or Thread. The bridge acknowledges the callback, deletes its confirmation, completes and removes the exact durable update, then dispatches one runtime-armed typed action through the internal `/telegram-connect --internal new <token>` Pi gateway using `pi.sendUserMessage(..., { expandPromptTemplates: true })`. Manual invocation reports that the gateway cannot be run manually; the armed handler receives a real `ExtensionCommandContext` and calls `ctx.newSession()`; one discriminated durable intent preserves either exact classic Profile/CWD/session/chat continuity or the Thread binding with slot/name re-key. The successor CAS-claims that intent before sending one terminal result. In a follower Thread the leader publishes and claims the intent on the follower's behalf over capability-gated, exact-generation local bus requests; followers never persist leader-owned state. Busy, identity-mismatch, stale-registration, incompatible-leader, and unavailable-host paths fail closed.
 - `/compact` — open confirmation and compact when idle.
 - `/next` — abort active work first when needed, attempt the interrupted prompt's abort notice, then reply `Dispatching next queued turn.` to the exact queued prompt selected for the next model turn. That dispatch notice owns the turn's one reply header; later answer messages do not reply to the same prompt again. Abort-notice failure is diagnostic and cannot block dispatch. A later `/abort` or `/stop` cancels both pending transition notices before taking ownership. The `/next` command itself is never the lifecycle-notice reply target, and aborted pending assistant text is suppressed.
 - `/continue` — enqueue a priority `continue` prompt.

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

@@ -869,6 +869,8 @@ export function createTelegramLiveTargetWorkObserver<TContext>(deps: {
 
 interface TelegramCommandsAndToolsBindingDeps {
   pi: Pi.ExtensionAPI;
+  handleInternalAction:
+    Commands.TelegramSessionActionRuntime["handleInternalAction"];
   agentDir: string;
   configStore: Config.TelegramConfigStore;
   persistConfig: (config?: Config.TelegramConfig) => Promise<void>;
@@ -926,6 +928,7 @@ interface TelegramCommandsAndToolsBindingDeps {
 
 export function registerTelegramCommandsAndTools({
   pi,
+  handleInternalAction,
   agentDir,
   configStore,
   persistConfig,
@@ -1023,6 +1026,7 @@ export function registerTelegramCommandsAndTools({
     );
   };
   Commands.registerTelegramBridgeCommands(pi, {
+    handleInternalAction,
     promptForConfig: async (ctx, profileName) => {
       const nextProfileName = profileName ?? undefined;
       if (profileName && !Config.isValidTelegramProfileName(profileName)) {

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

@@ -625,6 +625,7 @@ export interface TelegramBridgeCommandStartPollingResult {
 }
 
 export interface TelegramBridgeCommandRegistrationDeps {
+  handleInternalAction?: TelegramSessionActionRuntime["handleInternalAction"];
   promptForConfig: (
     ctx: ExtensionCommandContext,
     profileName?: string,
@@ -790,6 +791,7 @@ export function registerTelegramBridgeCommands(
   pi: ExtensionAPI,
   deps: TelegramBridgeCommandRegistrationDeps,
 ): void {
+  const handleInternalAction = deps.handleInternalAction;
   pi.registerCommand("telegram-setup", {
     description: "<profile> — Configure Telegram bot token",
     handler: async (args, ctx) => {
@@ -805,9 +807,21 @@ export function registerTelegramBridgeCommands(
       ctx.ui.notify(deps.getStatusLines({ verbose }).join("\n"), "info");
     },
   });
-  pi.registerCommand("telegram-connect", {
+  pi.registerCommand(TELEGRAM_CONNECT_COMMAND_NAME, {
     description: "<profile> — Start Telegram bridge",
     handler: async (args, ctx) => {
+      const words = args.trim().split(/\s+/);
+      // Service dispatch never inherits profile activation or explicit-connect recovery authority.
+      if (words.some(word =>
+        word.toLowerCase().startsWith(TELEGRAM_INTERNAL_COMMAND_FLAG),
+      )) {
+        if (words[0] !== TELEGRAM_INTERNAL_COMMAND_FLAG || !handleInternalAction) {
+          ctx.ui.notify(TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE, "warning");
+          return;
+        }
+        await handleInternalAction(words.slice(1).join(" "), ctx);
+        return;
+      }
       const sessionGeneration = deps.getSessionGeneration?.();
       let intentId: string | undefined;
       // Pi context getters throw after replacement; check plain intent/generation first.
@@ -4183,18 +4197,16 @@ async function handleTelegramCommandRuntime<
   );
 }
 
-export const TELEGRAM_INTERNAL_COMMAND_NAME = "telegram-internal";
-export const TELEGRAM_INTERNAL_COMMAND_DESCRIPTION =
-  "Internal Telegram command cannot be run manually";
+export const TELEGRAM_CONNECT_COMMAND_NAME = "telegram-connect";
+export const TELEGRAM_INTERNAL_COMMAND_FLAG = "--internal";
 export const TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE =
-  "This internal Telegram command cannot be run manually.";
+  "This internal Telegram action cannot be run manually.";
 
 function delayTelegramSessionAction(delayMs: number): Promise<void> {
   return new Promise<void>((resolve) => setTimeout(resolve, delayMs));
 }
 
 export interface TelegramSessionActionRuntimeDeps {
-  registerCommand: Pi.ExtensionAPI["registerCommand"];
   sendUserMessage: Pi.ExtensionAPI["sendUserMessage"];
   notifyResult: (
     target: { chatId: number; threadId?: number; messageId: number },
@@ -4277,7 +4289,6 @@ function createTelegramSessionReplacementSettlementRuntime<TContext>(deps: {
 }
 
 export interface TelegramSessionActionAssemblyDeps {
-  registerCommand: Pi.ExtensionAPI["registerCommand"];
   sendUserMessage: Pi.ExtensionAPI["sendUserMessage"];
   store: {
     load: () => Promise<void>;
@@ -4359,7 +4370,6 @@ export function createTelegramSessionActionAssembly(
     report(new Error("Telegram new-session result delivery failed."));
   };
   const action = createTelegramSessionActionRuntime({
-    registerCommand: deps.registerCommand,
     sendUserMessage: deps.sendUserMessage,
     notifyResult(target, result) {
       return sendTerminalResult(target, result);
@@ -4491,7 +4501,10 @@ type TelegramPendingInternalAction = {
 };
 
 export interface TelegramSessionActionRuntime {
-  register: () => void;
+  handleInternalAction: (
+    args: string,
+    ctx: Pi.ExtensionCommandContext,
+  ) => Promise<void>;
   scheduleAfterUpdate: (
     updateId: number,
     target: { chatId: number; threadId?: number; messageId: number },
@@ -4512,7 +4525,6 @@ export function createTelegramSessionActionRuntime(
       }
     | undefined;
   let pendingAction: TelegramPendingInternalAction | undefined;
-  let registered = false;
 
   const reportFailure = (error: unknown): void => {
     try {
@@ -4523,37 +4535,34 @@ export function createTelegramSessionActionRuntime(
   };
 
   return {
-    register() {
-      if (registered) return;
-      registered = true;
-      deps.registerCommand(TELEGRAM_INTERNAL_COMMAND_NAME, {
-        description: TELEGRAM_INTERNAL_COMMAND_DESCRIPTION,
-        handler: async (args, ctx) => {
-          const action = pendingAction;
-          if (!action || args.trim() !== action.token) {
-            ctx.ui.notify(TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE, "warning");
-            return;
-          }
-          pendingAction = undefined;
-          switch (action.kind) {
-            case "replace-session":
-              try {
-                await deps.prepareReplacement?.(
-                  ctx,
-                  action.updateId,
-                  action.target,
-                );
-                const result = await ctx.newSession();
-                if (result.cancelled)
-                  await deps.notifyResult(action.target, "cancelled");
-              } catch (error) {
-                reportFailure(error);
-                await deps.notifyResult(action.target, "failure");
-              }
-              return;
+    async handleInternalAction(args, ctx) {
+      const action = pendingAction;
+      const [operation, token, ...extra] = args.trim().split(/\s+/);
+      if (
+        !action || operation !== "new" ||
+        token !== action.token || extra.length !== 0
+      ) {
+        ctx.ui.notify(TELEGRAM_INTERNAL_MANUAL_USE_MESSAGE, "warning");
+        return;
+      }
+      pendingAction = undefined;
+      switch (action.kind) {
+        case "replace-session":
+          try {
+            await deps.prepareReplacement?.(
+              ctx,
+              action.updateId,
+              action.target,
+            );
+            const result = await ctx.newSession();
+            if (result.cancelled)
+              await deps.notifyResult(action.target, "cancelled");
+          } catch (error) {
+            reportFailure(error);
+            await deps.notifyResult(action.target, "failure");
           }
-        },
-      });
+          return;
+      }
     },
     scheduleAfterUpdate(updateId, target) {
       if (pendingUpdateId !== undefined || pendingAction !== undefined)
@@ -4572,9 +4581,10 @@ export function createTelegramSessionActionRuntime(
       pendingAction = { kind: "replace-session", token, updateId, target };
       void Promise.resolve()
         .then(() =>
-          deps.sendUserMessage(`/${TELEGRAM_INTERNAL_COMMAND_NAME} ${token}`, {
-            expandPromptTemplates: true,
-          }),
+          deps.sendUserMessage(
+            `/${TELEGRAM_CONNECT_COMMAND_NAME} ${TELEGRAM_INTERNAL_COMMAND_FLAG} new ${token}`,
+            { expandPromptTemplates: true },
+          ),
         )
         .catch((error) => {
           pendingAction = undefined;

package/node_modules/@llblab/pi-telegram/lib/extension.ts

@@ -92,7 +92,6 @@ export default function (pi: Pi.ExtensionAPI) {
     getCommands,
     getThinkingLevel,
     sendUserMessage,
-    registerCommand,
     setActiveTools,
     setModel,
     setThinkingLevel,
@@ -310,7 +309,6 @@ export default function (pi: Pi.ExtensionAPI) {
     captureAuthority: captureTelegramStateAuthority,
   });
   const sessionActionAssembly = Commands.createTelegramSessionActionAssembly({
-    registerCommand,
     sendUserMessage,
     store: threadStore,
     getProfileName: configStore.getActiveProfileName,
@@ -2833,9 +2831,9 @@ export default function (pi: Pi.ExtensionAPI) {
       },
     }.reset,
   );
-  sessionActionsRuntime.register();
   Bindings.registerTelegramCommandsAndTools({
     pi,
+    handleInternalAction: sessionActionsRuntime.handleInternalAction,
     agentDir: Paths.resolveAgentDir(),
     configStore,
     persistConfig: persistTelegramConfigWithSync,

package/node_modules/@llblab/pi-telegram/lib/telegram-api.ts

@@ -2090,7 +2090,8 @@ export function createTelegramBridgeApiRuntime(
     notBeforeMs: number;
   };
   const chatActionGates = new Map<string, ChatActionGate>();
-  const chatActionChatGates = new Map<string, ChatActionGate>();
+  // Pin shared cooldowns until every concurrent Thread settles; this state never owns their sends.
+  const chatActionChatGates = new Map<string, { pendingRequests: number; notBeforeMs: number }>();
   const getChatActionKeys = (
     method: string,
     body: Record<string, unknown>,
@@ -2130,7 +2131,7 @@ export function createTelegramBridgeApiRuntime(
         }
       }
       for (const [key, candidate] of chatActionChatGates) {
-        if (!candidate.inFlight && nowMs >= candidate.notBeforeMs) {
+        if (candidate.pendingRequests === 0 && nowMs >= candidate.notBeforeMs) {
           chatActionChatGates.delete(key);
         }
       }
@@ -2146,11 +2147,10 @@ export function createTelegramBridgeApiRuntime(
         if (chatActionChatGates.size >= chatActionMaxGates) {
           return true as TResponse;
         }
-        chatGate = { notBeforeMs: 0 };
+        chatGate = { pendingRequests: 0, notBeforeMs: 0 };
         chatActionChatGates.set(chatActionKeys.chat, chatGate);
       }
       if (gate.inFlight) return (await gate.inFlight) as TResponse;
-      if (chatGate.inFlight) return true as TResponse;
       if (nowMs < gate.notBeforeMs || nowMs < chatGate.notBeforeMs) {
         return true as TResponse;
       }
@@ -2198,10 +2198,10 @@ export function createTelegramBridgeApiRuntime(
         })
         .finally(() => {
           if (gate.inFlight === request) gate.inFlight = undefined;
-          if (chatGate.inFlight === request) chatGate.inFlight = undefined;
+          chatGate.pendingRequests--;
         });
       gate.inFlight = request;
-      chatGate.inFlight = request;
+      chatGate.pendingRequests++;
       return request;
     }
     try {

package/node_modules/@llblab/pi-telegram/package.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@llblab/pi-kit",
-  "version": "0.36.3",
+  "version": "0.37.0",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -50,7 +50,7 @@
     "@llblab/pi-codex-usage": "0.13.2",
     "@llblab/pi-grow-loop": "0.9.0",
     "@llblab/pi-state-flow": "0.26.5",
-    "@llblab/pi-telegram": "0.57.11",
+    "@llblab/pi-telegram": "0.58.1",
     "@llblab/skills": "1.15.0"
   },
   "bundledDependencies": [