@llblab/pi-kit 0.34.3 → 0.35.1

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

@@ -1267,14 +1267,31 @@ export function createTelegramBridgeApiRuntime(deps) {
             const sent = await callRecorded("answerGuestQuery", buildTelegramAnswerGuestQueryBody(guestQueryId, text, options));
             return sent?.inline_message_id;
         },
-        editGuestInlineMessage: async (inlineMessageId, content) => {
+        editGuestInlineMessage: async (inlineMessageId, content, options) => {
+            if (content.media) {
+                try {
+                    const result = await callRecorded("editMessageMedia", {
+                        inline_message_id: inlineMessageId,
+                        media: content.media,
+                    }, { ...options, maxAttempts: 1, retryRateLimit: false });
+                    if (result !== true)
+                        throw new Error("Missing inline edit acknowledgement.");
+                }
+                catch (error) {
+                    // Only a parsed rejection permits replacing this attempt with a failure notice.
+                    if (isTelegramApiRequestRejected(error, "editMessageMedia"))
+                        throw error;
+                    throw new TelegramApiCommitUnknownError("editMessageMedia", error);
+                }
+                return;
+            }
             await callRecorded("editMessageText", {
                 inline_message_id: inlineMessageId,
                 ...(content.richMessage
                     ? { rich_message: content.richMessage }
                     : { text: content.text }),
                 ...(content.parseMode ? { parse_mode: content.parseMode } : {}),
-            });
+            }, options);
         },
         prepareTempDir: () => prepareTelegramTempDir(deps.tempDir, deps.tempFileMaxAgeMs),
         deleteMessage: (chatId, messageId) => callRecorded("deleteMessage", {

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

@@ -561,6 +561,8 @@ export interface TelegramTopicTargetStore {
         existingBindingOnly?: boolean;
         sessionId?: string;
         provisionProfileKey?: string;
+        /** Explicit same-process session handoff from `previousInstanceId`; never inferred. */
+        sessionHandoff?: boolean;
         onCapacityUnavailable?: () => void;
     }) => TelegramWorkspaceBindingIdentity | undefined;
     releaseWorkspaceClaim: (instanceId: string) => boolean;

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

@@ -1307,8 +1307,14 @@ function liveRebindOldTargetUnknown(value) {
 function retainLiveRebind(value) {
     return liveRebindActive(value) || liveRebindOldTargetUnknown(value) || value.oldTargetProtected === true;
 }
+function provisioningProtectionIntents(snapshot) {
+    return [...snapshot.operations, ...(snapshot.liveRebindings ?? []).filter(retainLiveRebind)];
+}
+function protectedLiveRebindOldTargetIntents(snapshot) {
+    return (snapshot?.liveRebindings ?? []).filter(value => value.oldTargetProtected === true || liveRebindOldTargetUnknown(value) || value.inputRelease !== undefined && value.cleanup === "issued");
+}
 function protectedLiveRebindOldTargets(snapshot) {
-    return (snapshot?.liveRebindings ?? []).filter(value => value.oldTargetProtected === true || liveRebindOldTargetUnknown(value) || value.inputRelease !== undefined && value.cleanup === "issued").map(value => ({ ...value.request.binding.target }));
+    return protectedLiveRebindOldTargetIntents(snapshot).map(value => ({ ...value.request.binding.target }));
 }
 function pendingWorkspaceRelocationRequests(snapshot) {
     return [
@@ -1362,10 +1368,11 @@ function assertWorkspaceRestoreBindingProtection(file) {
             throw new Error("Protected Workspace Restore owner target changed.");
         }
     }
-    for (const old of protectedLiveRebindOldTargets(file.workspaceRestore)) {
+    for (const { request } of protectedLiveRebindOldTargetIntents(file.workspaceRestore)) {
+        const old = request.binding.target;
         if (file.workspaceBindings?.some(value => targetMatches(value.target, old)) ||
             file.threads?.some(value => targetMatches(value.target, old) && ["active", "starting", "pending", "probe-required"].includes(value.status)) ||
-            file.pendingProvisions?.some(value => !value.target || targetMatches(value.target, old)) ||
+            file.pendingProvisions?.some(value => conflictsWithWorkspaceRestoreProvision(request, value)) ||
             file.reservations?.some(value => targetMatches(value.target, old)))
             throw new Error("Unknown live cleanup target remains protected.");
     }
@@ -2942,7 +2949,7 @@ export function createTelegramTopicTargetStore(options) {
                 !isDeepStrictEqual(file.workspaceRestore?.liveRebindings?.find((intent) => intent.request.operationId === expected.request.operationId), expected))
                 throw new Error("Workspace live-rebind observation changed.");
             assertWorkspaceRestoreBindingProtection(file);
-            assertRestoreRecoveryProtection(path, file.workspaceRestore.operations, file.pendingProvisions ?? []);
+            assertRestoreRecoveryProtection(path, provisioningProtectionIntents(file.workspaceRestore), file.pendingProvisions ?? []);
             observe({
                 threads: file.threads,
                 workspaceBindings: file.workspaceBindings,
@@ -2976,7 +2983,7 @@ export function createTelegramTopicTargetStore(options) {
                     !isDeepStrictEqual(file.workspaceRestore?.liveRebindings?.find((intent) => intent.request.operationId === request.operationId), expected))
                     return true;
                 assertWorkspaceRestoreBindingProtection(file);
-                assertRestoreRecoveryProtection(path, file.workspaceRestore.operations, file.pendingProvisions ?? []);
+                assertRestoreRecoveryProtection(path, provisioningProtectionIntents(file.workspaceRestore), file.pendingProvisions ?? []);
                 const canonical = file.workspaceBindings ?? [], warm = Array.from(workspaceBindings.values());
                 const matchesRecipient = (bindings, rows) => {
                     const bindingsForKey = bindings.filter((binding) => binding.bindingKey === request.binding.bindingKey);
@@ -3008,7 +3015,9 @@ export function createTelegramTopicTargetStore(options) {
                 const protectedTarget = (bindings, rows, reserved, provisions, cleanups) => bindings.some((binding) => targetMatches(binding.target, old)) ||
                     rows.some((row) => currentRow(row) && targetMatches(row.target, old)) ||
                     reserved.some((value) => targetMatches(value.target, old)) ||
-                    provisions.some((value) => !value.target || targetMatches(value.target, old)) ||
+                    // Use the same binding/slot/owner/target conflicts as rebind admission. An unrelated unlocated
+                    // create must not globally veto cleanup of this exact former binding (nor its issued marker).
+                    provisions.some((value) => conflictsWithWorkspaceRestoreProvision(request, value)) ||
                     cleanups.some((value) => targetMatches(value.target, old));
                 if (protectedTarget(canonical, file.threads, file.reservations ?? [], file.pendingProvisions ?? [], file.pendingCleanups ?? []) ||
                     protectedTarget(warm, Array.from(records.values()), reservations, pendingProvisions, pendingCleanups) ||
@@ -3153,7 +3162,10 @@ export function createTelegramTopicTargetStore(options) {
                 if (bindings.length > 1 ||
                     file.threads.some((value) => targetMatches(value.target, target)) ||
                     file.reservations?.some((value) => targetMatches(value.target, target)) ||
-                    file.pendingProvisions?.some((value) => !value.target || targetMatches(value.target, target)) ||
+                    // This exact created frame already proves a separately created routing tab (API ACK or authenticated
+                    // implicit creation). An unlocated Workspace create is not its owner; keep that intent unresolved,
+                    // but veto a concrete target collision. Generic unknown-target/Restore cleanup keeps its own guards.
+                    file.pendingProvisions?.some((value) => !!value.target && targetMatches(value.target, target)) ||
                     file.pendingCleanups?.some((value) => targetMatches(value.target, target)) ||
                     file.workspaceRetirements?.some((value) => targetMatches(value.binding.target, target)) ||
                     before.state.operations.some((value) => targetMatches(value.request.target, target)))
@@ -3274,7 +3286,7 @@ export function createTelegramTopicTargetStore(options) {
                         }
                         assertWorkspaceRestoreBindingProtection(before.file);
                         const provisions = parseTopicTargetFile(before.file).pendingProvisions ?? [];
-                        assertRestoreRecoveryProtection(path, before.state.operations, provisions);
+                        assertRestoreRecoveryProtection(path, provisioningProtectionIntents(before.state), provisions);
                         const after = { ...before.file, workspaceRestore: next };
                         // New temporary targets must be checked against the file they will be published into.
                         assertWorkspaceRestoreBindingProtection(parseTopicTargetFile(after));
@@ -3284,7 +3296,7 @@ export function createTelegramTopicTargetStore(options) {
                         if (workspaceIO) {
                             if (!workspaceFrame || !currentScope() || !isCurrent())
                                 return false;
-                            assertRestoreRecoveryProtection(path, [...before.state.operations, ...next.operations], provisions);
+                            assertRestoreRecoveryProtection(path, [...provisioningProtectionIntents(before.state), ...provisioningProtectionIntents(next)], provisions);
                             committedBefore = before;
                             committedAfter = JSON.parse(content);
                             workspaceFrame.value = committedAfter;
@@ -3304,7 +3316,7 @@ export function createTelegramTopicTargetStore(options) {
                                     return;
                                 if (!isDeepStrictEqual(read().file, before.file))
                                     throw new Error("Workspace Restore evidence changed before publication.");
-                                assertRestoreRecoveryProtection(path, [...before.state.operations, ...next.operations], provisions);
+                                assertRestoreRecoveryProtection(path, [...provisioningProtectionIntents(before.state), ...provisioningProtectionIntents(next)], provisions);
                                 if (!currentScope() || !isCurrent())
                                     return;
                                 replaceTelegramWorkspaceFile(temporary, path);
@@ -4175,7 +4187,7 @@ export function createTelegramTopicTargetStore(options) {
         upsertPendingProvision(provision) {
             if (pendingWorkspaceRelocationRequests(workspaceRestore).some((request) => conflictsWithWorkspaceRestoreProvision(request, provision)) ||
                 conflictsWithTemporaryThread(workspaceRestore, provision.target) ||
-                protectedLiveRebindOldTargets(workspaceRestore).some(old => !provision.target || targetMatches(old, provision.target))) {
+                protectedLiveRebindOldTargetIntents(workspaceRestore).some(({ request }) => conflictsWithWorkspaceRestoreProvision(request, provision))) {
                 throw new Error("Protected Workspace Restore provisioning conflict.");
             }
             const next = {
@@ -4892,10 +4904,25 @@ export function createTelegramTopicTargetStore(options) {
                 if (ownedProvisions.length > 1)
                     return undefined;
                 const ownProvision = ownedProvisions[0];
-                const retainedTarget = ownProvision?.target ?? binding?.target ?? legacyRecord?.target;
-                const retainedSlot = ownProvision?.slot ?? binding?.slot ?? legacyRecord?.slot;
+                // A same-cwd session handoff keeps its predecessor's Thread slot; the Workspace commit re-keys that binding.
+                const handoffBindings = binding ||
+                    ownProvision ||
+                    !options?.sessionHandoff ||
+                    !previousInstanceId ||
+                    !isSameTelegramProcessInstance(previousInstanceId, instanceId)
+                    ? []
+                    : Array.from(workspaceBindings.values()).filter((candidate) => candidate.cwd === identity.cwd &&
+                        candidate.sessionId !== identity.sessionId &&
+                        Array.from(records.values()).some((record) => record.instanceId === previousInstanceId &&
+                            record.status === "active" &&
+                            targetMatches(record.target, candidate.target)));
+                const handoffBinding = handoffBindings.length === 1 ? handoffBindings[0] : undefined;
+                const retainedTarget = ownProvision?.target ?? binding?.target ?? handoffBinding?.target ?? legacyRecord?.target;
+                const retainedSlot = ownProvision?.slot ?? binding?.slot ?? handoffBinding?.slot ?? legacyRecord?.slot;
                 const otherBindings = Array.from(workspaceBindings.values())
-                    .filter((other) => other.bindingKey !== identity.bindingKey && other.slot)
+                    .filter((other) => other.bindingKey !== identity.bindingKey &&
+                    other.bindingKey !== handoffBinding?.bindingKey &&
+                    other.slot)
                     .map((other) => ({
                     bindingKey: other.bindingKey,
                     slot: other.slot.toLowerCase(),

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

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

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

@@ -485,6 +485,10 @@ This multi-input lifecycle is implemented in the local candidate, not authority
 
 Temporary Reroute publishes the prompt in its selected destination before local queue/command admission or follower IPC. The existing exact whole-group `forwardedInputs` grant precedes this one unretried Bot API request as well as native dispatch; complete distinct positive returned IDs provide display/reply anchors, never source acceptance or settlement. `forwardMessages` preserves albums and requires ascending source IDs, so the warm map correlates each destination ID with its immutable original source update ID rather than a routed zero ID or array position. Acknowledged routing copies are preferred; a proven still-retained All original or real native-Thread original may supply the source instead. Before issuance and after awaits, guards recheck source/executor/operator/context/generation/profile, exact issued group, live recipient record and Workspace session binding; followers also retain their exact registration/protocol ownership. API and IPC callbacks stay local. Reroute passes recipient/session authority plus each original execution fence to the existing socket connect/write/ACK checks, with one guarded transport attempt; a stale post-write ACK cannot settle donor custody or undo accepted recipient work. The input's warm projection uses the confirmed copy ID and clears former-tab reply suppression before carrying the original execution fence; donor journal originals remain untouched. A partial/malformed/lost API reply or revoked authority keeps the issued group nonterminal with no output or native retry, even after restart. A lost native IPC ACK similarly retains donor authority and cannot replay an already accepted recipient input or its display copies. Local receipt disposal and exact whole-group foreign source-removal ACKs still own temporary cleanup; neither a visible copy nor model completion grants deletion. A follower donor ACK may precede recipient receipt disposal, so a fully resolved but protected, unissued tab retains one metadata-only one-second recheck and accepts existing session-delivery drain wakes. Every attempt reacquires profile admission and fresh namespace/binding/source/authority proof; time is not a deletion grant. A fresh runtime drain can reobserve retained completed membership without replaying its input. Issued or unknown deletion never repeats. Restore's held-input sequencing and cleanup schedules are unchanged.
 
+A canonical temporary frame in phase `created` identifies its own independently created tab: either the exact one-shot `createForumTopic` response was acknowledged, or an owner-authenticated fresh implicit creation was admitted. An unrelated Workspace creation intent without a target therefore does not turn this positively identified tab into an unknown target. That uncertain intent is retained unchanged; this is neither age-based expiry nor permission to discard its recovery evidence. Any concrete provision targeting this tab, binding, owner, reservation, Restore operation, unresolved source or uncertain issued deletion retains its existing veto. `creating` frames never acquire this exemption, and generic unknown-target cleanup keeps its separate conservative rules. Restore old-target protection uses its exact binding/slot/owner/target conflict contract, including late recovered target evidence, rather than treating every unrelated targetless creation as a global veto; see the [Live-Rebind Channel](./multi-instance-bus.md#live-rebind-channel).
+
+Fresh local menu Reroute (`/start`, `/help`, `/status`, `/model`, `/thinking`, `/queue`, `/settings`) uses the existing selected-command owner with a release barrier captured during preparation. After acknowledged destination publication, exact worker completion readiness and paired-recipient validation permit one acceptance report, not immediate menu effects. The routing operation finalizes its chooser and releases profile admission while retaining its exact source references. A bounded subscription then requires the worker's exact removal ACK; absence, a thrown removal after commit, timeout or ended source authority is not completion. Cleanup acquires a new profile admission, behind source-completion bookkeeping, and rechecks every ordinary temporary-tab protection. Only then are the accepted menu effects released under the captured recipient/session/target guard. Siblings, live queue custody, unconfirmed deletion and other protection may retain the tab without cancelling the independently accepted menu. An issued deletion never repeats. Lost recipient authority or an unconfirmed source ACK suppresses effects without replay. Sources lacking fresh exact completion readiness, other command kinds, follower delivery and Restore retain their existing paths; neither queue-producing commands nor cold inputs are pre-completed to manufacture cleanup authority. Ordinary follower ACK proves durable custody but does not hold the recipient worker before execution. Restore's held-command RPCs additionally bind relocation, saved input and canonical release authority; they are not a negotiated Reroute release protocol. Mutating local commands complete after their semantic action, and queue-producing commands retain their separately acknowledged receipts. Startup/historical inputs are excluded by the worker's fresh-source readiness predicate. Those contracts cannot borrow the menu-only barrier by changing command classification or weakening source protection.
+
 - `Membership`: A positively source-linked disposable temporary Thread owns no Pi binding or A–Z slot and may contain multiple independent unassigned inputs, each with its own routing controls. Track exact journal source/group membership, including additional inputs, rather than treating the first chooser or a process-local count as the whole Thread. Serialize admission, selection, cancellation, Restore and cleanup through the existing Workspace admission and mutation owners; unreadable, incomplete, selected, accepted, running or unknown-issued evidence blocks deletion.
 - `Per-input Cancel`: Privately retain the exact original and positively commit source-only cancellation before acknowledging `Routing cancelled` and deleting its one-shot chooser message. Other unassigned inputs retain their choosers and custody; cancelling one input neither delivers nor cancels siblings. No separate Cancel-and-delete action or extra confirmation dialog is required, but the chooser must disclose the conditional whole-tab deletion consequence.
 - `Last-resolution cleanup`: Only an explicit Cancel or positive completion of an explicitly issued Forward that resolves the final known group may schedule deletion of the entire still-temporary Telegram tab, including all its messages. The operator-approved grace is now zero, superseding the earlier 1-second and 2–3-second designs: deletion is attempted right after the chooser is deleted. For Last Cancel, scheduling follows positively recorded whole-group cancellation and successful retirement of the final chooser, not the initial button tap. The timer establishes earliest eligibility for one proof-gated cleanup attempt, not an exact deletion time: Workspace admission, fresh protection checks and Bot API latency may delay or refuse it. Actual client timing was accepted in the operator's 0.52.0 live smoke. Mirrored native witnesses use shortened injected delays, not a production-default or Telegram-client timing measurement. This grace is presentation timing, not proof of emptiness or non-delivery. New input or a changed binding/authority cancels the scheduled cleanup. Immediately before issuance, reacquire current Workspace admission, recheck exact operator/profile/session/leader/source/target authority, positive disposable-tab provenance, complete source dispositions and all Thread protection, then publish the canonical one-shot temporary cleanup grant. A restored/bound Thread or any unresolved/unverifiable work remains protected. TTL, startup, silence and a zero chooser count do not manufacture this last-Cancel grant. Failed/unknown deletion cannot undo cancellation or cause automatic repeat issuance.
@@ -694,7 +698,7 @@ Assistant delivery guarantees:
 - Prompt context blocks use compact metadata (`[tag|key:value]`) as the stable inbound contract. `[telegram...]` names the current surface only: owner/current turns use `[telegram]` or `[telegram|thread:<name>]`; guest-mode turns use `[telegram|guest:<group-title-or-peer-username-or-id>]`. In a private Guest Mode turn the paired owner's `from` identity is never the guest: the remote private-chat identity wins, then non-owner caller metadata, with a non-bot replied peer available only as a final identity fallback when stronger conversation evidence is absent; username falls back to the remote display name and numeric id. Reply attribution still belongs independently in `[reply|from:...]`, and a replied bot can never define or replace the current `[telegram|guest:...]` location identity. Source authors for quoted/forwarded material and their files are carried by `[reply|from:<username-or-id>]`, `[forward|from:<username-or-id>]`, and `[attachments|from:<username-or-id>]`, while plain `[attachments]` remains current-turn attachments and is ordered before reply/forward/source context. Media embedded in inbound Telegram `rich_message` blocks is downloaded like ordinary message media and stays attached to its forward-source block instead of being mislabeled as current-user material. Guest-mode turns append a `[guest]` block to their turn text stating the one-reply/limited-window constraint and instructing a fast, concise, self-contained answer; the note travels with the turn text rather than the system prompt.
 - Quoted rich replies use Telegram `rich_message` blocks as the prompt-context source when available, so `[reply]` context receives rendered plain text instead of raw `InputRichMessage.markdown` fallback text. Replied media runs through the same inbound handlers and voice transcription providers as current-message media, with provenance-scoped `[outputs|from:…]` appended inside the reply block.
 - Long native Markdown replies are split only at Telegram Rich Message transport limits; oversized fenced code, display-math, and fully wrapped inline-formatting blocks are rewrapped per chunk so persisted Rich Markdown chunks remain structurally valid.
-- When Draft previews are enabled, streaming previews pass structurally closed assistant Markdown prefixes through to `sendRichMessageDraft` with ownership checks, voice and guest-turn suppression, and serialized flushes. Telegram Guest Mode allows exactly one answer that cannot be patched afterward, so guest turns never start preview state even while `assistant.draftPreviews` is enabled. Unclosed inline spans, links, fenced code, comments, and display-math blocks are held back until a safe boundary exists. Draft failures are recorded and the failing frame is skipped instead of degrading to raw plain-message previews, because partial Markdown can be invalid while the final message remains valid.
+- When Draft previews are enabled, streaming previews pass structurally closed assistant Markdown prefixes through to `sendRichMessageDraft` with ownership checks, voice and guest-turn suppression, and serialized flushes. Telegram Guest Mode uses one guest answer, normally an early inline placeholder edited at completion, so guest turns never start ordinary preview state even while `assistant.draftPreviews` is enabled. Queued attachments replace the acknowledged placeholder through cached-media edits rather than a second guest answer; supported types, error handling and staging authority follow the [Guest Mode media boundary](./outbound.md#guest-mode-media-boundary). Unclosed inline spans, links, fenced code, comments, and display-math blocks are held back until a safe boundary exists. Draft failures are recorded and the failing frame is skipped instead of degrading to raw plain-message previews, because partial Markdown can be invalid while the final message remains valid.
 - Preview flushes are single-flight within their generation. Publication and final delivery capture only preceding draft/publication dependencies, never later drafts blocked by that publication, and final delivery performs no post-final draft-clear call. Reset/invalidation detaches old-generation dependencies; previously issued transport requests may still settle, but stale draft, timer and publication results cannot clear or mutate replacement work. Successful final text delivery clears local preview state only while its captured segment, session and transport remain active.
 
 UI/compat rendering guarantees:

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

@@ -216,7 +216,7 @@ Production retirement requires a durable profile-scoped reader/writer ledger own
 - Retirement intent preparation/adoption/execution owns its exact gate-and-ledger protocol. The allocation wrapper invokes it outside ordinary registration/provisioning admission, after a typed capacity failure or to reconcile a retained retirement. Status projection and polling/routing bot-mode writes change only diagnostic or capability metadata; they neither create nor remove Thread/Workspace authority and serialize through the store's local persistence queue.
 - Production callers of reservation, provision/cleanup intent, target-record, Workspace-binding, and display mutators are contained by the owners above. The generic store remains policy-free for isolated tests and domain composition; calling a primitive directly is not production retirement authority.
 - Workspace identity remains the selected bot profile plus normalized exact full `cwd`; directory basenames are presentation, never routing keys. Each concurrent binding receives one profile-wide unique lowercase slot from `a` through `z`, persisted on the wire/store as its uppercase equivalent, independent of directory and leader/follower role. This replaces the two competing displayed allocation identities; immutable legacy `instanceSlot` and `bindingKey` remain recovery keys, not another displayed pool.
-- Automatic display mode is a bot-profile setting shared by Telegram Thread titles and Pi TUI status. The selector offers `letters`, `names`, `directory-snake`, then `directory-title`; absent or invalid values resolve to `letters`. Letters show `A`, `B`, `C`; Names shows the generated dictionary name for the slot, such as `Anchor` for `A`. The retired `directories` value is unsupported: it resolves to `letters`, is omitted from Settings, and is not rewritten automatically. A durable per-Workspace `manualThreadName`, set through Telegram `/name`, overrides any automatic projection until explicitly reset. Bare `/name` immediately enters exact-target rename input: cancel is always available, while reset is shown only when a manual override exists; no intermediate action-selection step exists. Store the automatic preference at `profiles.<name>.threadDisplayMode`, not as a process-local choice or a setting shared by unrelated bots.
+- Automatic display mode is one shared setting used by Telegram Thread titles and Pi TUI status across every bot profile. The selector offers `letters`, `names`, `directory-snake`, then `directory-title`; absent or invalid values resolve to `letters`. Letters show `A`, `B`, `C`; Names shows the generated dictionary name for the slot, such as `Anchor` for `A`. The retired `directories` value is unsupported: it resolves to `letters`, is omitted from Settings, and is not rewritten automatically. A durable per-Workspace `manualThreadName`, set through Telegram `/name`, overrides any automatic projection until explicitly reset. Bare `/name` immediately enters exact-target rename input: cancel is always available, while reset is shown only when a manual override exists; no intermediate action-selection step exists. Store the automatic preference at top-level `threads.displayMode`, never as a process-local choice or inside `profiles.<name>`; the retired profile key is ignored.
 - Directory formatting operates on the shortest path-segment suffix that distinguishes the normalized exact cwd from every other displayed cwd, while routing and identity continue to use the unmodified full cwd. Each segment is tokenized deterministically at runs of non-letter/non-number characters, lowercase-or-number to uppercase transitions, and the acronym boundary before an uppercase-plus-lowercase word (`apiPRDServer` becomes `api`, `PRD`, `Server`). Empty tokens are discarded. `directory-snake` lowercases tokens and joins them with `_`; segment qualifiers also join with `_`, so `/work/API tools` previews as `api_tools`. `directory-title` joins words with spaces and qualified segments with ` / `; an all-uppercase token containing a letter is preserved (`PRD` remains `PRD`), while every other token is lowercased and capitalized (`api_tools` becomes `Api Tools`). Unicode letters and numbers participate in tokenization and locale-independent Unicode case conversion; punctuation is only a separator. Root and token-empty segments retain the existing safe fallback instead of fabricating an empty title. On Linux/macOS, a binding whose normalized cwd exactly equals the current OS user's normalized home directory uses the display segment `home`: `home` in Snake and `Home` in Title. This is display-only, not a change to cwd, binding or routing identity. Child paths, another user's home and Windows use ordinary formatting; Letters, Names, legacy presentation and manual overrides are unchanged. The synthetic segment participates in qualification, so an unrelated `/work/home` remains `work_home` or `Work / Home` rather than colliding; ordinary live-owner suffix rules still produce `home_a` or `Home A`.
 - Settings previews are computed by the same pure projector used for initial creation and reconciliation, against the current binding set rather than illustrative hard-coded text. Slot suffixes are applied after base formatting (`api_tools_a` and `Api Tools A`) and remain outside abbreviation/case normalization; title-case suffixes use one plain space and never a middle-dot separator. Manual names are never normalized. Case-insensitive or 128-character-bounded collisions remain fail-closed under the existing ambiguity contract. New persisted modes and follower requests require a new negotiated display-format capability; an older peer may continue operating only while the effective profile mode remains Letters or Names, and cannot silently reinterpret either new value.
 - The unreachable legacy `directories` projector remains only for decoding old internal snapshots; effective configuration falls back to Letters. The `directory-snake` and `directory-title` modes derive suffix visibility exclusively from the leader's current authenticated live-owner snapshot: one live binding for a normalized exact cwd has no suffix; two or more live bindings for that cwd all expose their globally assigned slots; dormant retained bindings never affect the count. `showSlotSuffix` remains readable for legacy presentation but is ignored by both new projectors and is never written merely because live concurrency changed. The leader captures exact profile, epoch, binding target, and follower registration generation before projection; a provisioning candidate counts only after its authenticated exact owner is admitted to the same serialized Workspace mutation, while an owner losing authority is excluded before reconciliation. Registration/provision completion, authenticated disconnect or confirmed-dead prune, target replacement, and promotion schedule one serialized reconciliation of every affected live same-cwd binding. A failed or partial Telegram rename retains acknowledged per-binding progress and retries only under a fresh live snapshot; dormant tabs are not renamed until they regain authenticated ownership. Leader startup treats its authenticated follower roster as unsettled for one follower-staleness window: automatic display reconciliations requested by election or incremental re-registration are deferred and coalesced until that boundary. A same-cwd follower returning within the window therefore preserves the already acknowledged suffix without an `unsuffixed → suffixed` Telegram rename; if it stays absent, the settled reconcile removes the suffix once. Explicit mode changes remain immediate, and leader stop/restart invalidates the pending timer. Equal basenames from different paths still require deterministic parent-path qualification independently from same-cwd suffixing. Preserve the existing `threadName` as generated/recovery identity while automatic modes are selected. New manual names live only in `manualThreadName`; do not guess manual provenance from a legacy name or palette membership. Telegram `/name Name` changes the manual override and displayed title only for its exact originating target. Leader and follower requests carry that target through final generation/binding checks, so replacement cannot redirect a stale dialog mutation. Reset uses the same negotiated `workspace-thread-rename-v1` capability and exact follower generation; the leader computes the current automatic projection from the latest live snapshot, edits the exact target, clears only `manualThreadName`, and persists before acknowledging. Follower metadata refresh preserves an acknowledged display title only while target and registration generation stay unchanged. Named-profile setup preserves the latest saved automatic preference even if another instance changes it while the token form is open.
@@ -311,6 +311,8 @@ Every participating peer must negotiate the required capabilities and retain cur
 
 Semantic reports, queued receipts, completion observation and delivery remain separate. Native exact ACK and donor CAS still own source disposition; lost or mismatched evidence retains uncertainty without handler replay, another queue or fallback admission. This section owns the unified command-channel policy; [architecture](./architecture.md#live-rebind-module-map) owns the module map. Existing Workspace Restore receivers/readers and queue-handoff retain their custody contracts; the new loaded root prefers live rebinding rather than using legacy Restore as an uncertain-input fallback. Source-enabled bounded cleanup is not proof of an actual deletion or client acceptance. Supported leader/follower prompts, commands and templates use `saved → binding applied → cleanup decision → input issuance → native admission/execution`. The chooser holds its existing profile admission through the unchanged whole first delay and one fresh cleanup attempt, without nested leader admission or another queue. A negotiated follower reports work through `observe-held` before release; binding readiness is not execution permission. `inputRelease: held/issued/accepted` is independent of cleanup: an issued input is never replayed after a lost admission reply, and a finished cleanup with held input remains active binding/source protection. Confirmed, failed or unknown terminal deletion permits the one native input attempt only on the confirmed binding. Issued and unknown old-target evidence remains canonically protected against reuse and generic cleanup, including response/publication interruption; unknown evidence survives input acceptance and is never capacity-evicted or reissued. If earlier work prevents issuance, input proceeds on the confirmed new target and the existing paced scheduler owns deferred cleanup; no old-target clearance is invented. Detached command producers accept their one input grant independently from exact source ACKs and reply publication; menu/reply authority tolerates only that issued-to-accepted progress, never changed binding, cleanup, recipient or generation. Expanded templates retain their captured content/default lane and Continue its control lane. A session-replacing `/new` producer with earlier protected work records positively unissued cleanup plus durable `oldTargetProtected`; it cannot erase that old-target protection or transfer a delete grant into the successor. Actual replacement still uses the existing post-removal Pi gateway and confirmation, not Restore readiness. Follower command/control completion retains the exact prepared-source/native ACK before donor CAS; queued admission is not completion and cannot dispose the donor. Unsupported producers do not gain arbitrary follower execution. Older peers keep the preceding supported channel. In deferred cleanup, old-tab cleanup waits for the recipient session to be idle, which the moved input itself may keep busy; its paced retries keep a whole first delay so a detached command reply still sees the released, cleanup-free row, but after that a leader's `agent_settled` or drained output barrier wakes a waiting retry at once. Publication/command-work, Activity handlers, per-target companion queues and target/chat API counters capture lifetime-fenced notifications when work starts and emit only after their pending observation clears. The session adapter defers the hint without awaiting cleanup and rechecks its captured context generation, transport/profile and leader epoch/operator authority. Streaming technical events can drain the publication queue without ending the agent run. A delivery hint while SDK idle is false, unavailable or throwing is retained in the existing chain but does not clear its timer or acquire Workspace admission. `agent_settled` remains an unconditional recheck hint; after settlement, actual remaining delivery drains can wake the retry. A running attempt retains one coalesced hint without a concurrent check, then re-enters the same idle filter after releasing its admission. A fresh timer/settlement attempt consumes the previously deferred hint; signals arriving during that await are not lost. Timer retries, including busy-session samples, are unchanged. Terminal outcomes discard hints, including unknown issued deletion. The initial one-second delay, retry/window fallback, follower pacing and negotiated IPC contracts remain unchanged. Each chain also retains its original generation/profile-store/epoch/operator lifetime rather than rebasing to a reused context. The wake only re-samples every gate through fresh admission; it never grants cleanup, clears unconfirmed work, occupies the publication tail or holds Pi settlement for deletion. Windows runs the same strict paths, exercised by the CI matrix; actual Pi/client acceptance and release are not inferred from supplied IPC fixtures.
 
+Live-rebind old-target cleanup and retained issued/unknown deletion markers use the same provisioning-conflict identity as rebind admission: binding key, slot, legacy owner identity and concrete old/new target. An unrelated intent without a target is retained, but is not a global veto on this exact former binding. The inverse provisioning write checks use the same rule. Fresh provisioning-recovery evidence participates in cleanup observation, publication and captured-recipient API-boundary checks, including after issuance; an exact late target collision or malformed matching recovery still refuses without erasing the intent or retrying a deletion. The ordering remains held input → confirmed new binding → old-tab cleanup decision → input release, not destructive deletion before a replacement binding is established. Native All `/start` regressions cover the successful old-tab deletion/new-tab preservation sequence, an unrelated ambiguous intent, protected busy work and a lost deletion reply. The paired Reroute regression deletes only the exhausted temporary tab and preserves the selected instance's binding. Post-reload operator checks confirmed both idle leader flows: Reroute removes its exhausted temporary tab, while Restore preserves the new tab and removes the old one. This acceptance does not imply every busy-session or follower scenario was exercised.
+
 ### Local IPC endpoint with bounded native paths
 
 Leader opens a local Node `net` endpoint only for the start that still owns its lifecycle: a stop that lands while startup is still replaying cleanup or binding the endpoint makes that start release whatever it brought up and never begin polling, and the startup display-stabilization timer arms only for the start that began it. The endpoint is a Unix-domain socket under the agent temp directory on Unix-like platforms, or a deterministic Windows named pipe (`\\.\pipe\pi-telegram-...`) on native Windows. A filesystem-style endpoint supplied by legacy state or a transport harness normalizes deterministically to the same Windows pipe boundary before listen/connect. On Unix, an endpoint that would exceed conservative domain-socket pathname limits maps to a private user-scoped, hash-derived path under the OS temp directory; ordinary agent paths remain under `tmp/pi-telegram`. On Unix, each server listens on a private generation socket and atomically publishes the stable profile path as a relative symlink; delayed shutdown closes only its private path and cannot remove a replacement generation's link. Followers register, heartbeat, and exchange routed events. The transport boundary owns endpoint derivation, socket-vs-pipe detection, bounded operation-aware retry policy, timeout/transient IPC error classification, endpoint reachability probes, and request-scoped transport events. Follower registration uses a longer registration-specific response timeout than ordinary heartbeat/forwarding calls because the leader may need to provision a Telegram thread before it can return the assigned target; timing out that handshake leaves a visible tab with no follower heartbeat. Keep this handshake to the true critical path: create/reuse the target, persist the live binding, and return it. Connected notices and replaced-thread reconciliation cleanup are non-critical and should run after registration so a follower becomes routable before Telegram client/server UI convergence work finishes.
@@ -561,7 +563,7 @@ All files containing routing, chat ids, thread ids, or process details use priva
 - Each unfinished preservation retains one admission operation ID across sequential attempts, so a lost acquisition acknowledgement reuses and releases the exact lease instead of leaking another. A rejected pre-rename write leaves the owner intact; a committed write with lost acknowledgement is recognized without rewriting first inactivity. A liveness interruption is retryable, not successful settlement. Every attempt reacquires profile admission and the shared mutation gate, rechecks authority at rename, and preserves accepted work. Cancellation or scope loss never guesses away an unresolved admission lease; existing exact lease/dead-owner recovery remains authoritative.
 - Followers treat rejected/missing heartbeat acknowledgements as registration loss: retain the last known target locally, clear registered truth, show `reconnecting` instead of a healthy `follower` status, try to re-register with the current leader, wait a short leader-reload grace window, and retry. They promote only after the exact leader lease becomes stale or inactive; a live owner with an unreachable endpoint leaves the follower disconnected/retrying rather than creating a competing poller.
 - Persisted current manual-follower bindings survive abrupt process absence as restoration hints when Thread cleanup is disabled. When enabled, graceful Pi quit requests exact-generation teardown before lifecycle suspension; if that envelope is missed, stale pruning may delete only after the leader's OS confirms the exact registered PID has exited.
-- Fresh registration sends one compact connected notice in the assigned thread. Reusing a retained exact-session target resolves its acknowledged Workspace display title, even if the provisional claim uses another instance slot; a generated dictionary name is only fallback when no acknowledged title exists. Cross-process/session restoration, including an exact immediate handoff, uses that connected message as its visibility probe before publishing registration. Typing is not proof that a retained tab accepts messages. A proven stale target enters existing replacement provisioning; an ambiguous send refuses registration without inventing deletion or retry authority.
+- Fresh registration sends one compact connected notice in the assigned thread. Reusing a retained exact-session target resolves its acknowledged Workspace display title, even if the provisional claim uses another instance slot; a generated dictionary name is only fallback when no acknowledged title exists. Cross-process/session restoration, including an exact cross-process handoff, uses that connected message as its visibility probe before publishing registration. A same-process session replacement (`/new`, `/fork`) that carries the exact active predecessor record is silent: it transfers that record, keeps the Thread, letter slot and acknowledged title, and re-keys the Workspace binding to the new session without sending a notice or allocating another slot. Typing is not proof that a retained tab accepts messages. A proven stale target enters existing replacement provisioning; an ambiguous send refuses registration without inventing deletion or retry authority.
 - Registration requires a present generation, and explicit disconnect requires that same exact live generation. Leader-side registration and disconnect mutations serialize per durable follower profile across old and replacement runtime instance IDs, so a replacement registration cannot overtake awaited destructive cleanup and an old disconnect cannot remove its successor's routing authority.
 - Successful forwarded updates and follower-originated API calls refresh liveness, so active followers are not pruned only because the interval heartbeat tick lagged. Each follower lifecycle owns at most one in-flight heartbeat for its exact registration generation; stop/replacement makes late settlement inert, and recovery or diagnostic failure cannot escape as an unhandled interval Promise.
 - Destructive follower thread teardown belongs to confirmed `/telegram-disconnect`, graceful Pi quit, or confirmed reconciliation actions, not generic heartbeat pruning. Manual disconnect retains its destructive confirmation and clears restart ownership; quit deletes the tab without prompting when Thread cleanup is enabled (default) but preserves the owner slot independently so a same-directory restart can reclaim leadership. Confirmed leader/follower teardown first persists an exact target/runtime-generation cleanup intent. The active leader attempts deletion under its current epoch; interruption preserves the intent so that leader or a successor can replay it under current authority, and confirmed deletion removes the binding plus intent in the same persisted state transition. If the graceful request is missed, stale heartbeat plus OS-confirmed absence of the exact registered PID may authorize the same cleanup while enabled; this action serializes ahead of replacement registration. Disabled cleanup, silence, heartbeat expiry alone, IPC/auth failure, and live or unknown process liveness remain non-destructive. Incomplete cleanup preserves durable intent for retry. A promoted leader uses its current owned leader epoch even when the inherited record still carries a historical `manual-follower` owner label.
@@ -587,7 +589,7 @@ For repeated unselected All-tab `/start`, a newer durable source supersedes olde
 
 The bounded pending reroute owns its original source target and the returned chooser message ID independently from remaining messages. Authenticated callbacks must match the stored chat/chooser and any supplied thread field. `InaccessibleMessage` may omit the thread field; a missing callback message, unknown chooser, conflicting identity, threadless source, or already-owned Restore source fails closed rather than forwarding to the old target. Restart or expiry without that pending identity does not authorize reconstruction from callback data alone. When the original input itself has no thread ID (including an All-tab `/start`), the chooser offers routing only, not Restore; old Restore callbacks explain that a plain message must first be sent in the destination thread. Client tab selection is not inferred from recent topic creation or from the chosen Pi instance.
 
-After dispatch, cleanup retries retain source identity but never redispatch accepted messages. Confirmed typed HTTP 400 `message to delete not found` completes message deletion idempotently; permission and transient failures remain errors. Reroute cleanup rechecks current bindings, live targets, reservations, and pending provisions before close, before delete, and on retry. Other destructive cleanup origins use the shared synchronous target-protection policy: explicit retirement permits only its unchanged departing binding, persisted shutdown intent permits only its original pre-intent binding, and reservation/provision cleanup permits only the corresponding unchanged claim. Protection checks also guard post-API local invalidation, reservation, and disconnect completion. A newly protected target cancels remaining cleanup. Already-issued remote operations cannot be undone by a later local ownership change; checks prevent subsequent effects, not retroactive cancellation.
+After dispatch, cleanup retries retain source identity but never redispatch accepted messages. For a fully resolved, positively unbound temporary tab, explicit cleanup may recover historical v1 queued receipts owned by confirmed-dead processes under profile admission and cross-family journal serialization. Strict complete namespace and exact-reference inspection precede whole unoffered receipt CAS recovery; alive/unverifiable owners, offered receipts, malformed sources and unsupported custody remain protective. Protection reads themselves never recover or repair files, and successful recovery is followed by a fresh ordinary protection check before one deletion grant. Confirmed typed HTTP 400 `message to delete not found` completes message deletion idempotently; permission and transient failures remain errors. Reroute cleanup rechecks current bindings, live targets, reservations, and pending provisions before close, before delete, and on retry. Other destructive cleanup origins use the shared synchronous target-protection policy: explicit retirement permits only its unchanged departing binding, persisted shutdown intent permits only its original pre-intent binding, and reservation/provision cleanup permits only the corresponding unchanged claim. Protection checks also guard post-API local invalidation, reservation, and disconnect completion. A newly protected target cancels remaining cleanup. Already-issued remote operations cannot be undone by a later local ownership change; checks prevent subsequent effects, not retroactive cancellation.
 
 Follower Restore uses only the source-bound `leader.workspaceRestore` protocol described under [protocol identity and compatibility](#protocol-identity-and-compatibility). The follower validates the retained operation and exact registration/session authority under read-only canonical snapshot protection; it never persists leader-owned state. Lost apply replies require inspection, not target replacement or another apply grant. Legacy target-replacement requests are rejected before recipient effects.
 

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

@@ -80,9 +80,11 @@ Core assistant output accepts only the Markdown or HTML `InputRichMessage` forms
 
 ### Guest Mode media boundary
 
-A Guest Mode reply is one `answerGuestQuery` call carrying exactly one `InlineQueryResult`; it is not a normal chat target and cannot receive `sendDocument`/`sendVoice` multipart uploads through sentinel `chatId: 0`. `telegram_attach` therefore admits at most one file during a guest turn and rejects additional files before queue mutation.
+A Guest Mode reply starts with one `answerGuestQuery` call carrying exactly one `InlineQueryResult`; it is not a normal chat target and cannot receive `sendDocument`/`sendVoice` multipart uploads through sentinel `chatId: 0`. The direct owner normally answers immediately with a placeholder and retains its `inline_message_id` for the final edit. `telegram_attach` admits at most one file during a guest turn and rejects additional files before queue mutation.
 
-Telegram accepts public URLs or existing Telegram `file_id` values for inline media results, but pi-telegram does not publish local artifacts to external hosting. A local guest document, photo, MP3 audio, or OGG/OPUS voice therefore uses a temporary upload to the paired owner's bot chat, extraction of the returned `file_id`, one cached-media guest answer, and best-effort deletion of the staging message. That message can briefly appear or notify the owner. One guest query can carry only one media item, and its answer text must fit the media caption limit rather than a separate full Rich Markdown message.
+Local guest documents, PNG/JPEG photos and MP3 audio use a temporary upload to the paired owner's bot chat, extraction of the returned `file_id`, and best-effort deletion of the staging message. With an acknowledged placeholder, the final result replaces that exact inline message through `editMessageMedia`; it never calls `answerGuestQuery` again. Without a placeholder, delivery retains the single cached-media guest-answer path, including OGG/OPUS voice support. The staging message can briefly appear or notify the owner. One reply carries one media item, with final text truncated to the 1024-character caption limit. No external file hosting or upload to `chatId: 0` is used.
+
+OGG/OPUS voice attachments cannot replace the acknowledged inline placeholder and are rejected before queue mutation; voice markup produces an explicit explanation instead of silently disappearing. Use MP3 audio or a normal bot chat. Upload failures and confirmed media-edit rejections replace the placeholder with a delivery-error notice where possible. An uncertain media-edit outcome is recorded without retrying or overwriting the possibly delivered media. Session/transport authority is checked after placeholder stop and upload, and at final edit issuance; retired work cannot edit, send fallback text or delete staging messages under successor authority. Actual guest-media rendering remains a live-client acceptance check.
 
 Configured text handlers provide `template`. A string is one command; an array is ordered composition. Top-level `args` and `defaults` apply to all composed steps unless a step defines private values. The command-template default timeout applies automatically. Use `template: [...]` for composition; the old local `pipe` alias is removed in 0.13.0. A falsy root `when` skips that handler: inbound and voice selection continue with the next matching handler, while a text transform passes its input through unchanged. A falsy `when` on a composed step, or on any enclosing composition node, skips that step and passes the previous output on. `recover` runs only between failed `retry` attempts of the node that declares it; its output is ignored and a recovery failure stops further retries. `parallel` and `delay` are not executed by these handlers.
 

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

@@ -93,7 +93,6 @@ interface TelegramBotProfile {
   botUsername?: string; // runtime-managed
   botId?: number; // runtime-managed
   allowedUserId?: number;
-  threadDisplayMode?: "letters" | "names" | "directory-snake" | "directory-title";
 }
 
 interface TelegramConfig {
@@ -115,15 +114,16 @@ interface TelegramConfig {
   };
   threads?: {
     automaticCleanup?: boolean;
+    displayMode?: "letters" | "names" | "directory-snake" | "directory-title";
   };
 }
 ```
 
-Bot/session identity always persists under `profiles.<name>`. The ordinary setup path uses `profiles.default`; `/telegram-setup default` and `/telegram-connect default` are exact aliases for the bare commands. Named profiles use the same shape. Shared handlers plus `assistant`, `voice`, `time`, and `threads` remain top-level. On the first `0.24.0` load, unambiguous legacy root identity moves atomically into `profiles.default`; identical duplicates collapse, complementary fields merge, and conflicting values fail closed without modifying the file.
+Bot/session identity always persists under `profiles.<name>`. The ordinary setup path uses `profiles.default`; `/telegram-setup default` and `/telegram-connect default` are exact aliases for the bare commands. Named profiles use the same shape. A profile holds only bot identity and its paired owner; shared handlers plus every Settings-menu preference (`assistant`, `voice`, `time`, and `threads`) remain top-level and apply to all profiles. On the first `0.24.0` load, unambiguous legacy root identity moves atomically into `profiles.default`; identical duplicates collapse, complementary fields merge, and conflicting values fail closed without modifying the file.
 
 The file is global across Pi instances and contains configuration only. The per-profile polling/admission cursor is `acceptedThroughUpdateId` in that profile's private durable update journal; it is not a config key. On first connection after this cut, a legacy config cursor is transferred directly into the journal before polling and then removed from config. Journal publication failure preserves the legacy source; config publication failure leaves the journal authoritative so retry is idempotent. Cooperating instances serialize recursive config delta merges through `telegram.json.transaction` and preserve unrelated global/profile changes from newer disk snapshots. A semantically unchanged merge adopts the latest disk state in memory without replacing the file; later commits win when two deltas intentionally change the same leaf. Same-parent temp-file replacement retries bounded transient `EPERM`, `EACCES`, and `EBUSY` destination contention without deleting the live config or leaving transaction serialization. For manual edits, stop or idle the connected instances, publish a complete valid file atomically, and let them reload. A non-transactional editor racing Pi persistence has no same-leaf conflict guarantee.
 
-Threaded Mode Settings exposes **Thread display** as Letters (default), Names, `directory-snake`, or `directory-title`; retained `directories` is unsupported, resolves to Letters, and is never rewritten automatically. `profiles.<name>.threadDisplayMode` is profile-scoped; absent and invalid values resolve to `letters`. Settings previews the current binding set through the same projector used for fresh titles and reconciliation. A manual `/name` override appears as `custom`; choosing any automatic Thread display option clears that override for the current Thread and immediately reapplies the selected projection. Names projects the generated dictionary name for the slot; the two directory modes tokenize Unicode path segments deterministically and render snake case or humanized title case, with `_a` or ` A` slot suffixes when required. The leader serializes preference persistence and title reconciliation, while a follower sends an authenticated `follower.setThreadDisplayMode` request gated by `thread-display-mode-v1`, the additional `directory-display-format-v1` capability for either new directory mode, and its exact registration generation. Config writes check the originating authority inside the config transaction; mode changes preserve target IDs, slots, generated recovery names, manual overrides, and queue ownership. `/name` mutations carry their originating target through final binding validation. The caller confirms only after application succeeds. A partial failure may leave the preference saved and some titles updated; Settings reports that state and permits retry. Acknowledged follower titles arrive through heartbeat rather than a new read loop.
+Threaded Mode Settings exposes **Thread display** as Letters (default), Names, `directory-snake`, or `directory-title`; retained `directories` is unsupported, resolves to Letters, and is never rewritten automatically. `threads.displayMode` is shared by every profile; absent and invalid values resolve to `letters`. The retired `profiles.<name>.threadDisplayMode` key is ignored, not migrated. Another profile's already-running leader applies a shared change at its next startup or display reconciliation. Settings previews the current binding set through the same projector used for fresh titles and reconciliation. A manual `/name` override appears as `custom`; choosing any automatic Thread display option clears that override for the current Thread and immediately reapplies the selected projection. Names projects the generated dictionary name for the slot; the two directory modes tokenize Unicode path segments deterministically and render snake case or humanized title case, with `_a` or ` A` slot suffixes when required. The leader serializes preference persistence and title reconciliation, while a follower sends an authenticated `follower.setThreadDisplayMode` request gated by `thread-display-mode-v1`, the additional `directory-display-format-v1` capability for either new directory mode, and its exact registration generation. Config writes check the originating authority inside the config transaction; mode changes preserve target IDs, slots, generated recovery names, manual overrides, and queue ownership. `/name` mutations carry their originating target through final binding validation. The caller confirms only after application succeeds. A partial failure may leave the preference saved and some titles updated; Settings reports that state and permits retry. Acknowledged follower titles arrive through heartbeat rather than a new read loop.
 
 Hidden/default semantics are represented by absence:
 

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

@@ -1043,12 +1043,7 @@ export function registerTelegramCommandsAndTools({
               );
             }
             await configStore.load();
-            const latestProfile =
-              configStore.getStoredConfig().profiles?.[profileName];
-            configStore.setProfile(profileName, {
-              ...profile,
-              threadDisplayMode: latestProfile?.threadDisplayMode,
-            });
+            configStore.setProfile(profileName, profile);
             configStore.activateProfile(profileName);
             await onTransportChanged?.();
             await persistConfig(configStore.get());
@@ -1176,7 +1171,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"]
   >;
@@ -1203,6 +1198,7 @@ interface TelegramLifecycleBindingDeps {
     ctx: Pi.ExtensionContext,
   ) => void;
   answerGuestQuery: TelegramApi.TelegramBridgeApiRuntime["answerGuestQuery"];
+  editGuestInlineMessage?: TelegramApi.TelegramBridgeApiRuntime["editGuestInlineMessage"];
   deleteMessage: TelegramApi.TelegramBridgeApiRuntime["deleteMessage"];
   sendGuestReply: NonNullable<
     Queue.TelegramAgentEndHookRuntimeDeps<
@@ -1281,6 +1277,7 @@ export function registerTelegramLifecycleRuntimeHooks({
   onSteerTurnEnd,
   onPromptHandedOff,
   answerGuestQuery,
+  editGuestInlineMessage,
   deleteMessage,
   sendGuestReply,
   editGuestReply,
@@ -1323,6 +1320,7 @@ export function registerTelegramLifecycleRuntimeHooks({
     turn: Queue.PendingTelegramTurn,
     attachment: Queue.QueuedAttachment,
     caption?: string,
+    options?: { isDeliveryActive?: () => boolean },
   ): Promise<void> => {
     const stagingTarget = proactivePushTargetGetter();
     const stagingChatId = stagingTarget?.chatId;
@@ -1333,11 +1331,19 @@ export function registerTelegramLifecycleRuntimeHooks({
     }
     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) =>

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

@@ -536,9 +536,10 @@ export function createTelegramBusAwareApiRuntime(
     editGuestInlineMessage(
       inlineMessageId: string,
       content: TelegramEditGuestInlineMessageContent,
+      options?: Pick<TelegramApiCallOptions, "assertAuthority">,
     ): Promise<void> {
       return deps.ownsDirect()
-        ? deps.directRuntime.editGuestInlineMessage(inlineMessageId, content)
+        ? deps.directRuntime.editGuestInlineMessage(inlineMessageId, content, options)
         : rejectTelegramDirectOwnership("editGuestInlineMessage");
     },
     async deleteMessage(chatId: number, messageId: number): Promise<void> {

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

@@ -1591,6 +1591,7 @@ export function createTelegramBusFollowerTargetProvisioner(
           {
             existingBindingOnly: options?.existingWorkspaceBindingOnly === true,
             sessionId: registration.sessionId,
+            sessionHandoff: registration.previousInstanceId !== undefined,
             provisionProfileKey: registration.profileKey ?? `manual:${registration.instanceId}`,
             onCapacityUnavailable() {
               capacityUnavailable = true;
@@ -1854,11 +1855,52 @@ export function createTelegramBusFollowerTargetProvisioner(
         };
       }
       const probeRequiredRecord = reconnectRecord?.status === "probe-required";
+      // Pi /new or /fork inside one live process keeps its Thread; that process already proves the tab.
+      const sameProcessSessionHandoff =
+        crossSessionReuse &&
+        reconnectRecord?.status === "active" &&
+        registration.previousInstanceId === reconnectRecord.instanceId &&
+        recoverableTarget === undefined &&
+        Threads.isSameTelegramProcessInstance(
+          reconnectRecord.instanceId,
+          registration.instanceId,
+        );
       const requiresVisibilityProbe =
-        crossSessionReuse ||
+        (crossSessionReuse && !sameProcessSessionHandoff) ||
         probeRequiredRecord ||
         recoverableTarget !== undefined;
-      const retainedDisplayBinding = deps.topicTargetStore.getWorkspaceBindingByTarget(result.target, registration.sessionId);
+      const transferSessionHandoffRecord = async (): Promise<void> => {
+        const nowMs = getNowMs();
+        const transferredRecord = deps.topicTargetStore.upsert({
+          ...result.record,
+          profileKey: followerProfileKey,
+          owner:
+            followerOwner.kind === "manual-follower"
+              ? followerOwner
+              : {
+                  kind: "manual-follower",
+                  instanceId: registration.instanceId,
+                },
+          instanceId: registration.instanceId,
+          updatedAtMs: nowMs,
+          lastSyncObservedAtMs: nowMs,
+          lastReconcileAction: "follower-session-handoff",
+        });
+        await deps.topicTargetStore.persist();
+        result = {
+          target: transferredRecord.target,
+          reused: true,
+          record: transferredRecord,
+        };
+      };
+      if (sameProcessSessionHandoff) {
+        assertRestoreRegistration();
+        await transferSessionHandoffRecord();
+      }
+      // A session handoff still owns the predecessor session's binding until the Workspace commit re-keys it.
+      const retainedDisplayBinding =
+        deps.topicTargetStore.getWorkspaceBindingByTarget(result.target, registration.sessionId) ??
+        deps.topicTargetStore.getWorkspaceBindingByTarget(result.target);
       let connectedAnnouncement =
         !result.reused || requiresVisibilityProbe
           ? createTelegramBusInstanceLifecycleAnnouncement({
@@ -1913,28 +1955,7 @@ export function createTelegramBusFollowerTargetProvisioner(
               record: activatedRecord,
             };
           } else if (crossSessionReuse && reconnectRecord) {
-            const nowMs = getNowMs();
-            const transferredRecord = deps.topicTargetStore.upsert({
-              ...result.record,
-              profileKey: followerProfileKey,
-              owner:
-                followerOwner.kind === "manual-follower"
-                  ? followerOwner
-                  : {
-                      kind: "manual-follower",
-                      instanceId: registration.instanceId,
-                    },
-              instanceId: registration.instanceId,
-              updatedAtMs: nowMs,
-              lastSyncObservedAtMs: nowMs,
-              lastReconcileAction: "follower-session-handoff",
-            });
-            await deps.topicTargetStore.persist();
-            result = {
-              target: transferredRecord.target,
-              reused: true,
-              record: transferredRecord,
-            };
+            await transferSessionHandoffRecord();
           }
           connectedAnnouncement = undefined;
         } catch (error) {