# Upgrade Guide — vNEXT

<!-- assembled-by: assemble-next-md -->
<!-- bump: patch -->

## What Changed

**A moved conversation's reply no longer gets stuck behind a redundant safety
check.** When a conversation is moved to another machine, that machine relays its
replies through the machine that holds the Telegram connection. The reply was
being tone-gated twice — once on the relaying machine and again on the machine
that actually delivers it. The first gate was not just redundant: its quality
check makes an AI call that, under rate-limit protection, is allowed to wait up
to two minutes before proceeding — so on a busy system the relaying machine could
stall a reply for that long before it even handed it off (a relayed reply was
observed hanging over 50 seconds for exactly this reason).

Now the relaying machine skips its own tone gate; the machine that actually
delivers the reply still runs it. One gate, in the right place — the reply is
just as safe, the redundant stall is gone. Machines that send directly (and
single-machine setups) are unaffected.

## What to Tell Your User

Nothing to configure. If you run across more than one machine and move a
conversation between them, replies relay faster and no longer stall behind a
duplicated quality check — while still being checked once, on the machine that
delivers them.

## Summary of New Capabilities

- `TelegramAdapter.willRelay()` — true when a send will relay through the lease
  holder (tokenless standby). `/telegram/reply` uses it to skip its local tone
  gate for a relayed reply (the holder gates it). Direct sends gate locally,
  unchanged.

## Evidence

- Code-grounded diagnosis (2026-06-01): `/telegram/reply` runs
  `checkOutboundMessage` → `MessagingToneGate.review` (a `claude -p` LLM call
  carrying `rateLimitWaitMs: 120000`) BEFORE `sendToTopic`/relay. On a standby,
  that gate runs, then the relay hands the same reply to the holder, which gates
  it again. Under a rate-limited circuit the standby's gate can wait up to 120s
  pre-relay — matching the observed >50s hang of a standby reply.
- Tests: `tests/unit/telegram-tokenless-relay.test.ts` (+4) — `willRelay()` is
  true for a tokenless standby ({secret:true} placeholder, or null token) with a
  relay wired, false for a real string token, false for tokenless with no relay
  wired. Regression: 57/57 across the TelegramAdapter, MessagingToneGate, and
  relay-timeout suites. `tsc` clean.
