switchroom 0.18.32 → 0.19.0

package/telegram-plugin/gateway/checklist-message-handler.ts

@@ -0,0 +1,107 @@
+/**
+ * `checklist_tasks_done` / `checklist_tasks_added` service-message forwarding
+ * (switchroom#2996 P6 cluster F).
+ *
+ * Telegram emits these service messages when users tick or add tasks in a
+ * native checklist. They arrive as part of the `message` update type (no extra
+ * `allowed_updates` config needed). We route them to the agent as a new channel
+ * event with kind="checklist_task_changed" so the agent can react to user
+ * actions on a checklist it sent.
+ *
+ * Extracted verbatim from gateway.ts (Amendment 9 — no module-global reads).
+ * The two `bot.on('message:checklist_tasks_*')` registration lines stay in
+ * gateway.ts (order is a load-bearing invariant) and delegate here.
+ */
+
+import type { Context } from 'grammy'
+import type { InboundMessage } from './ipc-protocol.js'
+
+type ChecklistTaskUpdate = {
+  message_checklist?: {
+    title?: string
+    tasks?: Array<{ id?: number; text?: string; is_completed?: boolean }>
+  }
+  checklist_tasks_done?: Array<{ id?: number; user?: { id?: number; username?: string }; done?: boolean }>
+  checklist_tasks_added?: Array<{ id?: number; text?: string; user?: { id?: number; username?: string } }>
+}
+
+export interface ChecklistHandlerDeps {
+  /** Access config — only `allowFrom` is consulted (same gate as inbound). */
+  loadAccess: () => { allowFrom: string[] }
+  /** Broadcast a channel event to connected bridges. */
+  broadcast: (msg: InboundMessage) => void
+  /** stderr log sink. */
+  log: (line: string) => void
+}
+
+export function handleChecklistUpdate(
+  ctx: Context,
+  kind: 'checklist_tasks_done' | 'checklist_tasks_added',
+  deps: ChecklistHandlerDeps,
+): void {
+  try {
+    const msg = ctx.message as (typeof ctx.message & ChecklistTaskUpdate) | undefined
+    if (!msg) return
+
+    const chat = ctx.chat
+    if (!chat) return
+
+    const chat_id = String(chat.id)
+    const access = deps.loadAccess()
+
+    // Only notify if this chat is allowlisted — same guard as inbound user messages.
+    // Closes #472 finding #13. Pre-fix the `&& access.allowFrom.length > 0`
+    // tail made this fail-OPEN when the allowlist was empty: every chat's
+    // checklist tasks would forward to the agent. Sibling guards (the
+    // inbound-message gate at line ~588 and the operator-event broadcast
+    // at line ~1221) are both fail-closed for empty allowlists. The
+    // empty-allowlist case is the most likely state for a misconfiguration
+    // (e.g. /unpair just ran), so fail-OPEN is the worst default.
+    if (!access.allowFrom.includes(chat_id)) return
+
+    const message_id = String(msg.message_id)
+    const ts = msg.date ?? Math.floor(Date.now() / 1000)
+
+    // Extract task updates depending on service message type
+    const tasksDone = msg.checklist_tasks_done ?? []
+    const tasksAdded = msg.checklist_tasks_added ?? []
+    const allTasks = kind === 'checklist_tasks_done' ? tasksDone : tasksAdded
+
+    // Build per-task channel events and broadcast each to connected bridges.
+    for (const task of allTasks) {
+      const taskId = task.id != null ? String(task.id) : '?'
+      const user = (task.user as { username?: string; id?: number } | undefined)
+      const userName = user?.username ?? (user?.id != null ? String(user.id) : 'unknown')
+      const state = kind === 'checklist_tasks_done'
+        ? ((task as { done?: boolean }).done === false ? 'undone' : 'done')
+        : 'added'
+
+      const inboundMsg: InboundMessage = {
+        type: 'inbound',
+        chatId: chat_id,
+        messageId: Number(message_id),
+        user: userName,
+        userId: user?.id ?? 0,
+        ts,
+        text: `(checklist task ${state}: id=${taskId})`,
+        meta: {
+          chat_id,
+          message_id,
+          kind: 'checklist_task_changed',
+          task_id: taskId,
+          state,
+          user: userName,
+          user_id: user?.id != null ? String(user.id) : '0',
+          ts: new Date(ts * 1000).toISOString(),
+        },
+      }
+      // allow-broadcast: informational checklist task notification, not turn-driving
+      deps.broadcast(inboundMsg)
+      deps.log(
+        `telegram gateway: checklist ${kind}: chat_id=${chat_id} message_id=${message_id} task_id=${taskId} state=${state} user=${userName}\n`,
+      )
+    }
+  } catch (err) {
+    deps.log(`telegram gateway: checklist handler error (${kind}): ${err}\n`)
+  }
+}

package/telegram-plugin/gateway/delivery-confirm-wiring.ts

@@ -0,0 +1,133 @@
+/**
+ * delivery-confirm-wiring.ts — the deliver-until-acked SWEEP wiring
+ * (#2996 P8 PR-C1).
+ *
+ * Extracted VERBATIM from gateway.ts: the 5 s confirm-sweep tick body
+ * (`runDeliveryConfirmSweep`), the strand re-delivery (`redeliverStrandedInbound`)
+ * and the #2787 Mechanism A card-suspension scoper (`sweepSuspendedTargets`).
+ * The gateway keeps thin same-name wrappers and OWNS the `setInterval`
+ * (the P0c rule — a test import must stay side-effect-free).
+ *
+ * DI contract: state stays in gateway.ts (`deliveryQueue`, the pending-card
+ * maps, `pendingInboundBuffer`); volatile handles cross as getters. The idle
+ * gate deliberately reads `getCurrentTurnNull()` — the turn ATOM, not the
+ * machine's eager in-turn state (the documented trap: `turnInFlightForGate`
+ * stays set through a strand until the TTL tick, so it is NOT a usable idle
+ * signal here). Design §3 PR-C1 risk row; harness case 4 pins mid-turn
+ * suppression.
+ *
+ * `trackDelivery` enrolment callsites stay in gateway.ts unchanged — the two
+ * twin-body sites live inside the P7-owned handleInbound window and are P7's
+ * to delete (design §2 PR-C1 note).
+ */
+import type { InboundMessage } from './ipc-protocol.js'
+import type { DeliveryConfirmWiringDeps } from './gateway.js'
+import {
+  trackDelivery,
+  sweep as sweepDeliveryQueue,
+  forgetDelivery,
+  isRedeliverySuspended,
+  type PendingDelivery,
+} from './inbound-delivery-confirm.js'
+import { chatKey } from './chat-key.js'
+
+export function createDeliveryConfirmWiring(deps: DeliveryConfirmWiringDeps) {
+  const {
+    DELIVERY_CONFIRM_ENABLED,
+    DELIVERY_CONFIRM_TIMEOUT_MS,
+    getCurrentTurnNull,
+    sendToAgent,
+    deliveryQueue,
+    pendingInboundBuffer,
+    pendingPermissions,
+    pendingAskUser,
+  } = deps
+
+// Re-deliver stranded inbounds until claude acks (the marko drop-wedge).
+// Every few seconds, re-send any inbound that was handed to claude but never
+// acked by an `enqueue` — it stranded unsubmitted in the composer. Re-clear
+// the composer so the re-sent notification lands on a clean line, then
+// re-send. Reuses the same delivery primitives; the message is never dropped.
+// (Refs ipcServer / pendingInboundBuffer declared below — resolved at fire
+// time, after module init.) unref so the interval never holds the process.
+async function redeliverStrandedInbound(p: PendingDelivery<InboundMessage>): Promise<void> {
+  const selfAgent = process.env.SWITCHROOM_AGENT_NAME ?? ''
+  process.stderr.write(
+    `telegram gateway: inbound strand (no enqueue ack) key=${p.key} — re-clearing composer + re-delivering\n`,
+  )
+  try {
+    const { clearAgentComposer } = await import('../../src/agents/tmux.js')
+    if (selfAgent) clearAgentComposer({ agentName: selfAgent })
+  } catch { /* best-effort; re-deliver regardless */ }
+  const ok = sendToAgent(selfAgent, p.inbound)
+  if (ok) {
+    // Survive an ack that raced the `await import` above: only `enqueue`
+    // clears tracking, so if a concurrent ack removed the entry, re-affirm
+    // it — never drop. Idempotent.
+    if (!deliveryQueue.pending.has(p.key)) {
+      trackDelivery(deliveryQueue, p.key, p.inbound, Date.now(), p.messageId)
+    }
+  } else {
+    // Bridge offline between attempts — hand off to the offline buffer
+    // (bridgeUp drains it) and stop tracking here; the spool owns it now.
+    pendingInboundBuffer.push(selfAgent, p.inbound)
+    forgetDelivery(deliveryQueue, p.key)
+  }
+}
+// #2787 Mechanism A — which chats/topics currently hold a live permission or
+// ask_user card. A pending card is a live interaction for ITS OWN chat, so the
+// confirm sweep must not re-clear the composer + re-send there. But the OLD guard
+// (`pendingPermissions.size > 0 || pendingAskUser.size > 0 → return`) suspended
+// the sweep GLOBALLY: one card parked in a single topic (or in the operator DM,
+// a different chatId entirely) froze re-delivery of every stranded inbound across
+// EVERY topic until that one card resolved. This scopes the suspension to the
+// card's own target. Returns per-topic chatKeys where the topic is known and bare
+// chatIds where it isn't (a card fanned to operator DMs records chatId only, and
+// a whole-chat suspension is the safe conservative fallback there); the callsite
+// tests a delivery entry against both renderings.
+function sweepSuspendedTargets(): { keys: Set<string>; chats: Set<string> } {
+  const keys = new Set<string>()
+  const chats = new Set<string>()
+  for (const p of pendingPermissions.values()) {
+    for (const c of p.cards) {
+      if (c.threadId != null) keys.add(chatKey(c.chatId, c.threadId))
+      else chats.add(c.chatId)
+    }
+    // A permission whose card send hasn't resolved yet (cards still empty) has
+    // no recorded target — suspend nothing for it; the next sweep sees it once
+    // the send resolves, and the currentTurn guard already covers the in-turn
+    // window a fresh permission request lives in.
+  }
+  for (const a of pendingAskUser.values()) {
+    if (a.threadId != null) keys.add(chatKey(a.chatId, a.threadId))
+    else chats.add(a.chatId)
+  }
+  return { keys, chats }
+}
+
+// #2996 P0c/P8 PR-C1: the sweep TICK body (named in PR-A so the harness can
+// drive it) — the GATEWAY still owns the `setInterval` (the P0c gate rule:
+// modules export the tick body; the gateway registers the timer).
+function runDeliveryConfirmSweep(): void {
+  if (!DELIVERY_CONFIRM_ENABLED) return
+  // Re-deliver ONLY when claude is genuinely idle. `currentTurn` is set solely
+  // by the enqueue session-event and nulled at turn-end, so `currentTurn != null`
+  // means a real turn is in flight — re-clearing the composer + re-sending now
+  // would clobber it (the exact mid-turn wedge this queue exists to prevent).
+  // NB: the machine's in-turn state (turnInFlightForGate) is advanced EAGERLY
+  // at delivery and stays set through a strand until the TTL tick, so it is
+  // NOT a usable "idle" signal here.
+  if (!getCurrentTurnNull()) return
+  // #2787 Mechanism A: a pending permission / ask_user card suspends re-delivery
+  // ONLY for its own chat/topic — never globally. Skip just the stranded entries
+  // whose target holds a live card; sweep the rest so unrelated topics keep
+  // getting re-delivered.
+  const suspended = sweepSuspendedTargets()
+  for (const p of sweepDeliveryQueue(deliveryQueue, Date.now(), DELIVERY_CONFIRM_TIMEOUT_MS)) {
+    if (isRedeliverySuspended(p.key, suspended)) continue
+    void redeliverStrandedInbound(p)
+  }
+}
+
+  return { runDeliveryConfirmSweep, redeliverStrandedInbound, sweepSuspendedTargets }
+}