# Вход Telegram убран целиком, а не выключен признаком

- **Дата:** 2026-08-15
- **Источник:** openspec/changes/archive/2026-08-15-remove-telegram-intake/design.md,
  разделы «Context» и «Формы решения, между которыми выбирали»

## Решение

Вход Telegram убран из сервиса целиком: клиент, транспорт обновлений, отправитель
сообщений, сборка входа при старте, список допущенных людей, секция настроек и
зависимость. Убран **временно** — возврат заводится новым изменением вместе со
связью чата с учётной записью.

Хранилище при этом не тронуто: колонки `tg_chat_id`, `tg_reply_message_id` и
значение `telegram` перечня источников остаются в схеме вместе с записями,
которые их заполнили.

## Почему

Цитата источника:

> Сервис принимает записи двумя входами, и входы расходятся в главном: у записи,
> пришедшей из приложения, есть владелец, а у записи, пришедшей от бота, владельца
> нет и быть не может — связи чата с учётной записью сервис не ведёт. Пока такие
> записи заводятся, правило «каждая запись принадлежит человеку» действует
> наполовину.

Отвергнуты две формы решения, обе с названной ценой:

> **Выключить вход признаком, код оставить.** Признак `telegram.enabled` заведён
> 2026-08-13 и обязателен, а приём по HTTP владельца уже требует: одна правка
> ключа в боевом файле даёт «новых записей без владельца не заводится» ценой ноля
> строк кода и мгновенным возвратом. Отвергнуто по причине из раздела «Why»:
> двойная модель остаётся в коде, и оговорку про бота продолжает платить каждая
> следующая задача.
>
> **Сузить бота до исходящего канала.** Приём убрать, отправку оставить с одним
> адресатом — чатом владельца строкой настроек. Отвергнуто потому, что заводит
> понятие «канал уведомления владельца», которое тут же переделает задача
> `ntfy-delivery`.

Решениями, которые это изменение отменяет, были
[ADR-2026-08-13-telegram-intent-declared-not-inferred](ADR-2026-08-13-telegram-intent-declared-not-inferred.md)
и
[ADR-2026-08-13-telegram-outage-does-not-block-startup](ADR-2026-08-13-telegram-outage-does-not-block-startup.md):
оба нормировали подъём входа, которого больше нет. Доводы их при этом устояли и
понадобятся возврату — оба продолжают отвечать на вопрос «что делать с входом,
чей внешний собеседник недоступен».

## Последствия

- `+` модель одна: оговорка про запись без владельца ушла из спек приёма,
  доступа, конвейера и хранилища.
- `+` зависимость `go-telegram-bot-api` ушла из манифеста вместе с двумя путями
  утечки токена, которые проект закрывал двумя задачами.
- `−` у сервиса не осталось входа, которым человек может воспользоваться:
  приложения нет, личных ключей для программ нет, и до этих задач запись кладут
  собранным руками запросом с сессией из браузера. Владелец окно принял.
- `−` записи, застрявшие в конвейере на минуту выкладки, доходят до текста, и
  ответа в чат по ним не уходит. Смягчения нет: чат и есть убираемый вход.
- `−` бот у Telegram остаётся зарегистрированным и на вид живым, а ключ доступа —
  в настройках выкладки под возврат входа (решение владельца от 2026-08-14).
  Отправитель голосового не получит ни ответа, ни отказа.
