@llblab/pi-kit 0.10.7 → 0.10.8

package/CHANGELOG.md

@@ -2,6 +2,10 @@
 
 All notable changes to `@llblab/pi-kit` are documented here.
 
+## 0.10.8 - 2026-09-13
+
+- `Follower Forwarding`: Advances the exact Telegram pin to `0.45.8`, so cached-ownership forwarding uses current registration protocol evidence for voice/message and edit retries, message-only callbacks, and reactions. Exact generation, binding, protocol, and durable-receipt checks remain enforced. The package set, resource inventory, and load order remain unchanged.
+
 ## 0.10.7 - 2026-09-12
 
 - `Queue Enqueue`: Advances the exact Telegram pin to `0.45.7`, preventing asynchronous voice/file preparation from restoring consumed prompts or overwriting newer queue changes. Surviving history and receipts follow current queue state; an already-wedged in-memory queue still requires separately authorized recovery. The package set, resource inventory, and load order remain unchanged.

package/README.md

@@ -15,7 +15,7 @@ Package links lead to the owning repositories for usage, documentation, issues,
 | [`@llblab/pi-codex-usage`](https://github.com/llblab/pi-codex-usage) | `0.9.4` | Compact Codex/Spark subscription-limit status |
 | [`@llblab/pi-grow-loop`](https://github.com/llblab/pi-grow-loop) | `0.8.1` | Visible continuation scheduling and bounded worker Skills |
 | [`@llblab/pi-state-flow`](https://github.com/llblab/pi-state-flow) | `0.9.6` | Atomic scoped state cohorts with final-eligibility resolution |
-| [`@llblab/pi-telegram`](https://github.com/llblab/pi-telegram) | `0.45.7` | Telegram companion, queues, files, voice, controls, and Generative Apps guidance |
+| [`@llblab/pi-telegram`](https://github.com/llblab/pi-telegram) | `0.45.8` | Telegram companion, queues, files, voice, controls, and Generative Apps guidance |
 | [`@llblab/skills`](https://github.com/llblab/skills) | `1.15.0` | Portable workflows for engineering, review, design, context maintenance, and other focused tasks |
 
 Versions are exact by design. An upstream release does not change an installed kit until this repository explicitly advances the dependency and publishes a new kit version. Runtime defects and package-specific feature requests belong in the linked repository; package selection and kit installation issues belong here.

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

@@ -4,6 +4,10 @@
 
 ## Unreleased
 
+## 0.45.8: Follower Forwarding Hotfix
+
+- `Follower Forwarding`: Message-ownership lookups now project the matching live registration's protocol identity before forwarding. Voice/message and edit retries, message-only callbacks, and reactions no longer stall on an incomplete cached owner after a rejection or re-registration. Exact generation, binding, protocol, and durable-receipt checks remain enforced.
+
 ## 0.45.7: Queue Enqueue Race Hotfix
 
 - `Queue Enqueue`: Asynchronous voice/file preparation no longer restores consumed prompts or overwrites newer queue changes, preventing a settled phantom head from blocking accepted work. Final assembly uses current queue state and allocates order at commit; abort-history folding retains only surviving intended prompts and receipts while preserving a handed-off head until `agent_start`.

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

@@ -429,7 +429,7 @@ The initial `offset: -1` cursor bootstrap is allowed only when both cursor and j
 
 Threaded Mode forwarding is a two-journal handoff. Only peers that mutually advertise protocol v1 and `durable-follower-admission-v1` may route or become election-eligible. The follower validates its exact binding and registration generation, durably appends the source-bound delivery, and only then returns the exact receipt. The leader classifies each attempt as `accepted`, `retryable`, or `terminal-rejected` with its delivery identity and failure class; only `accepted` with the expected `deliveryId` and `sourceUpdateId` may complete leader journal authority. Missing, negative, stale-generation, or mismatched-receipt acknowledgements remain durable, and a callback error answer is only an operator-facing side effect.
 
-Delivery ids derive only from envelope kind, source `update_id`, and stable recipient binding. Live registration generation remains a separate attempt fence, while callback/reaction message ownership carries that stable binding and rebinds to its current authenticated follower registration after replacement. Lost acknowledgements therefore replay idempotently into the same follower journal identity without changing the delivery id. Package build skew is allowed only while protocol version and capabilities remain compatible.
+Delivery ids derive only from envelope kind, source `update_id`, and stable recipient binding. Live registration generation remains a separate attempt fence. Message ownership carries the stable binding and rebinds to its current authenticated follower registration after replacement. `ownership.getForwardOwnership()` projects the protocol identity from the exact matching live instance, registration generation, and binding on every lookup; protocol is not cached with message history. The same port serves messages, edits, callbacks, and reactions, including callbacks without a Thread ID. If a cache lookup returns a foreign record but no matching durable-capable protocol can be projected, that record remains foreign and fails forwarding validation rather than falling through to local execution. The final bus validator independently rechecks generation, binding, and complete protocol identity before transport. Lost acknowledgements therefore retain the same delivery identity; only the exact durable receipt completes the source. Package build skew is allowed only while protocol version and capabilities remain compatible.
 
 Worker execution ownership is per `update_id` across same-runtime generations. Aborting a generation ends its authority but does not prove its handler settled; replacement replay remains blocked on that exact settlement. Late success and failure are both diagnostic events. Public and built-in handlers receive the same optional execution fence (`signal`, generation/update identity, and pre-effect assertion); the runtime binds it non-enumerably to every internal update carrier and checks it before routing-plan effects. Prompt construction rechecks after downloads and inbound handlers before queue mutation, pairing rechecks around persistence, command/menu and extension-command delegation retain the source fence across detached effects, lifecycle sync rechecks after store load before reconciliation, and reroute clones carry the source fence through forwarding, thread replacement, cleanup, persistence, and Bot API rename boundaries. Legacy handlers remain source-compatible but must not commit unfenced late effects.
 

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

@@ -934,7 +934,7 @@ export default function (pi: Pi.ExtensionAPI) {
     },
     getAdmissionScope: getTelegramUpdateAdmissionScope,
     getAdmissionJournalBinding: getTelegramQueueJournalBinding,
-    getMessageOwnership: messageOwnershipRuntime.store.get,
+    getMessageOwnership: messageOwnershipRuntime.getForwardOwnership,
     recordMessageOwnership: messageOwnershipRuntime.recordRouted,
     ...inboundBusProjectionRuntime,
     getDisplayTitle: getThreadDisplayTitle,

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

@@ -1,9 +1,14 @@
 /**
  * Telegram message ownership helpers
  * Zones: telegram routing, multi-instance bus, in-memory coordination
- * Owns live message-id ownership lookup so callbacks/reactions can resolve a Telegram UI surface back to the instance/target that produced it
+ * Owns message-id ownership and live forwarding projections so inbound updates resolve back to the instance/target that owns them
  */
 
+import {
+  TELEGRAM_BUS_CAPABILITY_DURABLE_FOLLOWER_ADMISSION,
+  type TelegramBusFollowerView,
+  type TelegramBusForwardOwnership,
+} from "./bus.ts";
 import { getTelegramTargetKey, type TelegramTarget } from "./target.ts";
 
 export interface TelegramMessageOwnershipRecord {
@@ -44,15 +49,17 @@ export interface TelegramMessageOwnershipStore {
   clear: () => void;
 }
 
-export interface TelegramFollowerOwnershipView {
-  instanceId: string;
-  connectedAtMs: number;
-  profileKey?: string;
-  registrationGeneration?: string;
-}
+export type TelegramFollowerOwnershipView = Pick<
+  TelegramBusFollowerView,
+  "instanceId" | "connectedAtMs" | "profileKey" | "registrationGeneration" | "protocol"
+>;
 
 export interface TelegramBusMessageOwnershipRuntime {
   store: TelegramMessageOwnershipStore;
+  getForwardOwnership(
+    chatId: number,
+    messageId: number,
+  ): TelegramBusForwardOwnership | undefined;
   recordLocal(input: {
     chatId: number;
     messageId: number;
@@ -137,6 +144,20 @@ export function createTelegramBusMessageOwnershipRuntime(deps: {
   };
   return {
     store,
+    getForwardOwnership(chatId, messageId) {
+      const record = store.get(chatId, messageId);
+      if (!record?.ownerGeneration || !record.recipientBindingKey) return record;
+      const follower = deps.listFollowers().find((candidate) =>
+        candidate.instanceId === record.instanceId &&
+        candidate.registrationGeneration === record.ownerGeneration &&
+        candidate.profileKey === record.recipientBindingKey,
+      );
+      // Protocol is live registration authority, not message-cache history.
+      // Keep an incomplete known owner foreign so the forwarder fails closed.
+      return follower?.protocol?.capabilities.includes(
+        TELEGRAM_BUS_CAPABILITY_DURABLE_FOLLOWER_ADMISSION,
+      ) ? { ...record, protocolIdentity: follower.protocol } : record;
+    },
     recordLocal(input) {
       return store.record({ ...input, instanceId: deps.instanceId });
     },

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

@@ -14,6 +14,7 @@ import {
 import type {
   TelegramBusEnvelope,
   TelegramBusFollowerView,
+  TelegramBusForwardOwnership,
   TelegramBusForeignUpdateSettlement,
   TelegramProcessLiveness,
 } from "./bus.ts";
@@ -345,22 +346,14 @@ export function getAuthorizedTelegramGuestMessage(
 
 // --- Flow ---
 
-export interface TelegramMessageOwnershipView {
-  instanceId: string;
-  ownerGeneration?: string;
-  recipientBindingKey?: string;
-}
+export type TelegramMessageOwnershipView = TelegramBusForwardOwnership;
 
 export type TelegramMessageOwnershipLookup = (
   chatId: number,
   messageId: number,
 ) => TelegramMessageOwnershipView | undefined;
 
-export interface TelegramTargetOwnershipView {
-  instanceId: string;
-  ownerGeneration?: string;
-  recipientBindingKey?: string;
-}
+export type TelegramTargetOwnershipView = TelegramBusForwardOwnership;
 
 export type TelegramTargetOwnershipLookup = (
   target: TelegramTarget,

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

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@llblab/pi-kit",
-  "version": "0.10.7",
+  "version": "0.10.8",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -45,7 +45,7 @@
     "@llblab/pi-codex-usage": "0.9.4",
     "@llblab/pi-grow-loop": "0.8.1",
     "@llblab/pi-state-flow": "0.9.6",
-    "@llblab/pi-telegram": "0.45.7",
+    "@llblab/pi-telegram": "0.45.8",
     "@llblab/skills": "1.15.0"
   },
   "bundledDependencies": [