telegram: сервис поднимается без бота и работает одним входом

- Клиент бота собирается один раз и достаётся отправителю и транспорту;
  разрез прошёл по «ответил ли Telegram»: ответ «такого бота нет» роняет
  старт, недоступность даёт подъём без Telegram (ADR-2026-08-13). Ожидание
  при сборке ограничено сроком — иначе молчащий Telegram вешал подъём.
- Недоставленный ответ не роняет шаг: пишется с job_id и считается метрикой,
  уровень по причине — WARN для неподнятого входа, ERROR для неназванного
  адресата. Заведены transcriber_intake_up и transcriber_undelivered_reply_count.
- Закрыта утечка токена в журнал: отказ разбора адреса рождается раньше
  обращения к клиенту, то есть мимо чистки на его границе.

openspec/specs/intake/spec.md

@@ -4,12 +4,15 @@
 
 Приём записи и опрос готовности задачи расшифровки: что считается принятой
 записью, что уезжает в ответ и что происходит, когда запись не удалось
-прочитать.
+прочитать. Плюс наличие входов: с каким из них сервис вправе подняться.
+
+Приём по существу описан пока **только для HTTP** — того, что нормируют
+проверки. Про вход Telegram нормировано одно: настроен он или нет и что из этого
+следует для подъёма. Кто допущен к боту и как забирается присланная им запись,
+требованиями по-прежнему не описано — требование, написанное без проверки, это
+предположение, а не норма. Первая задача, которая трогает поведение приёма из
+Telegram, дописывает его сюда.
 
-Описан пока **только приём по HTTP** — тот, что нормируют проверки. Приём из
-Telegram делит с ним общий шаг заведения задачи, но требований на него нет:
-требование, написанное без проверки, — предположение, а не норма. Первая задача,
-которая трогает поведение приёма из Telegram, дописывает его сюда.
 ## Requirements
 ### Requirement: Приём записи по HTTP
 
@@ -256,3 +259,78 @@ Telegram делит с ним общий шаг заведения задачи,
 - **WHEN** программа спрашивает состояние по неизвестному идентификатору
 - **THEN** ответ имеет код `404` и сообщение о ненайденной задаче
 
+### Requirement: Недоступный или незаданный вход Telegram не мешает подъёму
+
+Сервис SHALL подниматься, когда вход Telegram поднять не удалось, и MUST
+продолжать работу оставшимся входом: приём по HTTP, опрос готовности и конвейер
+расшифровки работают в полном объёме. Неподнятый вход MUST быть назван в журнале
+**ровно одной** записью уровня `WARN` при старте — с причиной и без значения
+токена.
+
+Исключение одно, и оно проходит по тому, **ответил ли Telegram**. Ответ «такого
+бота нет» — ошибка настройки: бот по этому токену не появится ни от ожидания, ни
+от повтора, и старт MUST кончаться отказом. Сервис, молча потерявший бота после
+опечатки в токене, перестаёт отвечать своим отправителям, и узнать об этом было
+бы неоткуда.
+
+Всё прочее — недоступность: сеть, DNS, авария Bot API, истёкший срок ожидания.
+Она MUST не влиять на подъём. Основной вход сервиса — не Telegram, и ронять его
+целиком из-за чужой аварии нельзя: перезапуск в такую минуту оставил бы без
+работы и приём по HTTP, и панель, и конвейер, которому Telegram не нужен вовсе.
+
+Ожидание при сборке MUST быть ограничено сроком. Без него недоступность
+неотличима от подъёма: обращение к Telegram стоит на пути старта, и молчащий
+собеседник останавливал бы его бессрочно — без записи, без порта и без пробы
+здоровья.
+
+Требование нормирует **наличие входа**, а не приём из него.
+
+#### Scenario: Токен не задан
+
+- **GIVEN** в настройках сервиса токен бота пуст
+- **WHEN** сервис запускается
+- **THEN** он поднимается и принимает записи по HTTP
+- **AND** конвейер расшифровки работает
+- **AND** бот не заведён, а в журнале ровно одна запись уровня `WARN` о том, что
+  он не поднят и почему
+
+#### Scenario: Токен задан и годен
+
+- **GIVEN** в настройках сервиса стоит токен, по которому Telegram признаёт бота
+- **WHEN** сервис запускается
+- **THEN** он поднимается и работает обоими входами
+
+#### Scenario: Telegram не отвечает
+
+- **GIVEN** в настройках сервиса стоит непустой токен
+- **AND** Telegram недоступен либо не отвечает дольше отведённого срока
+- **WHEN** сервис запускается
+- **THEN** он поднимается и принимает записи по HTTP
+- **AND** бот не заведён, а в журнале запись уровня `WARN` с причиной
+- **AND** запись не несёт значения токена
+
+#### Scenario: Telegram ответил, что такого бота нет
+
+- **GIVEN** в настройках сервиса стоит непустой токен
+- **AND** Telegram отвечает отказом на этот токен
+- **WHEN** сервис запускается
+- **THEN** старт кончается отказом
+- **AND** ни журнал, ни текст отказа не несут значения токена
+
+### Requirement: Поднятые входы видны наблюдателю
+
+Сервис SHALL отдавать признак поднятости по каждому входу приёма отдельной
+метрикой. Признак MUST выставляться при сборке входа и MUST различать поднятый
+вход и неподнятый.
+
+Требование стоит на том, что иначе потерянный вход не виден ничем: проба
+здоровья отвечает «сервис работает» и при неподнятом боте, а запись журнала
+живёт до ротации и вопрос «работает ли вход сейчас» не отвечает. Метрика —
+единственный канал наблюдения, который у владельца автоматизирован.
+
+#### Scenario: Вход Telegram не поднят
+
+- **GIVEN** сервис поднялся без Telegram
+- **WHEN** наблюдатель читает метрики
+- **THEN** признак поднятости входа Telegram равен нулю
+- **AND** признак поднятости входа HTTP равен единице

openspec/specs/pipeline/spec.md

@@ -3,16 +3,19 @@
 ## Purpose
 
 Конвейер расшифровки: как задача движется по состояниям, что делает воркер,
-когда работы нет, и что считается отказом шага.
+когда работы нет, что считается отказом шага и что бывает с ответом отправителю,
+когда доставить его некуда.
 
 Описаны пустой прогон воркера, неделимость захвата и срок его протухания, число
-попыток и состояние «мертва», нарастающая пауза перед повтором и условие записи
-результата держателем захвата. Сознательно не описаны: цепочка переходов
-`created → converted → transcribe → done | failed`, отмена контекста посреди
-шага и освобождение ресурсов внешних клиентов. Это не значит, что такого
-поведения нет: оно живёт в коде, а требования на него не написаны, потому что
-требование без проверки — предположение, а не норма. Первая задача, которая
-трогает любое из перечисленного, дописывает его сюда.
+попыток и состояние «мертва», нарастающая пауза перед повтором, условие записи
+результата держателем захвата и недоставка ответа при неподнятом входе.
+Сознательно не описаны: цепочка переходов `created → converted → transcribe →
+done | failed`, отмена контекста посреди шага и освобождение ресурсов внешних
+клиентов. Это не значит, что такого поведения нет: оно живёт в коде, а
+требования на него не написаны, потому что требование без проверки —
+предположение, а не норма. Первая задача, которая трогает любое из
+перечисленного, дописывает его сюда.
+
 ## Requirements
 ### Requirement: Пустой прогон воркера — не отказ
 
@@ -260,3 +263,65 @@ MUST расти с числом её попыток до объявленног
 - **THEN** задержка до следующей проверки каждый раз одна и та же
 - **AND** число попыток задачи не растёт
 
+### Requirement: Недоставленный ответ не роняет шаг
+
+Шаг конвейера SHALL доводить задачу до достигнутого состояния, когда ответ
+отправителю доставить не удалось, и MUST не считать недоставку отказом шага.
+Недоставка MUST быть записана в журнал владельца, MUST нести идентификатор
+задачи, MUST называть причину и MUST считаться отдельной метрикой с причиной
+меткой.
+
+Причин у недоставки две, и исход у них общий: **вход отправителя не поднят** —
+задача заведена прошлым запуском, а сервис поднялся без этого входа; и **адресат
+у задачи не назван** — источником значится Telegram, а чата в задаче нет.
+
+Уровень записи MUST различать эти причины. Неподнятый вход — объявленный режим,
+и его уровень «может стать проблемой». Неназванный адресат — симптом порчи
+записи: у задачи из Telegram чат есть всегда, и пропасть он может только от
+дефекта, самый коварный источник которого назван инвариантом проекта про колонки
+очереди. Один уровень на обе причины утопил бы этот сигнал в потоке штатных
+записей о ненастроенном боте.
+
+Общий исход — не упрощение, а следствие момента: ответ уходит **после** того, как
+достигнутое состояние сохранено. Работа к этой минуте сделана, и объявленный
+отказ засчитался бы воркеру сбоем и лёг бы владельцу записью отказа — то есть
+соврал бы про исход дважды. Повтор делу не помогает: ни бот, ни адресат от
+ожидания не появятся. Поэтому задача остаётся в достигнутом состоянии, в повтор
+не уходит и в `failed` не переводится, а причина недоставки живёт в записи
+журнала, а не в состоянии задачи.
+
+Идентификатор задачи в записи обязателен: без него владелец видит, что ответ не
+ушёл, но не может найти, чей. Текст расшифровки и сообщение отправителя в эту
+запись MUST не попадать — приватность содержимого записи требование не
+ослабляет.
+
+Отложенной доставки это требование не заводит: ответ, не ушедший сегодня, не
+уходит и потом. Забрать расшифровку можно там же, где лежат остальные.
+
+#### Scenario: Вход отправителя не поднят
+
+- **GIVEN** задача принята входом Telegram прошлым запуском сервиса
+- **AND** сервис поднялся без этого входа
+- **WHEN** шаг конвейера доходит до ответа отправителю
+- **THEN** шаг завершается без отказа, и воркер не считает прогон сбоем
+- **AND** задача остаётся в достигнутом состоянии, в повтор не уходит и в
+  `failed` не переводится
+- **AND** в журнале есть запись уровня `WARN` о недоставке с идентификатором
+  задачи и причиной
+- **AND** счётчик недоставленных ответов вырос с этой причиной меткой
+- **AND** ни текста расшифровки, ни сообщения отправителя в этой записи нет
+
+#### Scenario: Адресат у задачи не назван
+
+- **GIVEN** у задачи источником значится Telegram, а чат не назван
+- **WHEN** шаг конвейера доходит до ответа отправителю
+- **THEN** шаг завершается без отказа, и воркер не считает прогон сбоем
+- **AND** задача остаётся в достигнутом состоянии
+- **AND** в журнале есть запись уровня `ERROR` о недоставке с идентификатором
+  задачи и причиной: неназванный адресат — симптом порчи записи
+
+#### Scenario: Отвечать некуда, потому что запись пришла не из Telegram
+
+- **GIVEN** задача принята по HTTP
+- **WHEN** шаг конвейера доходит до ответа отправителю
+- **THEN** шаг завершается без отказа и без записи о недоставке