Files
transcriber/openspec/changes/archive/2026-08-15-remove-telegram-intake/proposal.md
T
av 8f7c3a057a удалён вход Telegram, владелец записи стал обязателен в схеме
- убраны клиент бота, транспорт обновлений, отправитель сообщений, сборка
  входа при старте, секция настроек и зависимость go-telegram-bot-api; из
  конвейера ушла доставка ответа отправителю — исход виден опросом готовности.
  Колонки адресата и значение источника остались в схеме: применённые шаги не
  переписываются
- шаг 202608140003 запрещает пустого владельца у аудиозаписи и у файла;
  существующие строки он не проверяет, и это принято сознательно — искать их
  надо запросом до выкладки
- ревью нашло два пред-существующих дефекта, оба закрыты: пустой второй ответ
  распознавателя стирал сохранённую расшифровку, а пустая расшифровка перестала
  быть заметной вместе с убранной доставкой. Попутно поднят golang.org/x/image
  до v0.45.0 — красный шаг vulns, воспроизводился и на чистом master
2026-08-15 07:24:35 +03:00

7.5 KiB

Why

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

Основной вход сегодня — приложение, и работа идёт над ним. Второй вход при этом стоит денег на каждой задаче: его нельзя не учитывать в приёме, в доставке ответа, в отборе записей и в настройках. Убираем его, чтобы модель стала одной, и убираем временно: бот вернётся, когда появится связь чата с учётной записью.

What Changes

  • BREAKING: вход Telegram убирается целиком. Бот не поднимается, записи от него не принимаются, ответ в чат не уходит.
  • BREAKING по смыслу, а не по разбору: настройки входа Telegram и список допущенных к боту людей уходят из конфигурации. Файл, где их забыли, сервис примет молча — незнакомые ключи разбор настроек не судит, — но значить они перестают что бы то ни было. Секцию убирает человек при выкладке.
  • У записи появляется владелец на правах обязательного, и держит это хранилище: колонка владельца у записи и у файла перестаёт принимать пустое значение. Завести ничью запись нельзя ничем — ни приёмом, ни конвейером, ни рукой в панели.
  • Из конвейера уходит доставка ответа отправителю: единственный оставшийся вход узнаёт исход опросом готовности и из панели владельца. Вместе с доставкой уходят правило про недоставленный ответ и обязанность остановки сообщать отправителю.
  • Наблюдатель видит один поднятый вход вместо двух.
  • Записи с источником Telegram, если они есть, остаются нетронутыми: колонки чата и ответного сообщения из схемы не убираются, и ни одна запись не удаляется. Записей без владельца в базе при этом нет — так ответил владелец сервиса, и на этом стоит обязательность колонки; прогон нового шага схемы на копии боевой базы проверяет это до выкладки.

Capabilities

New Capabilities

Новых нет: изменение убирает поведение, а не заводит.

Modified Capabilities

  • intake: уходит требование о признаке включения входа Telegram; требование о видимых наблюдателю входах говорит об одном входе.
  • pipeline: уходят требования о недоставленном ответе и об обязанности всякой остановки сообщать отправителю — адресата у сообщения не осталось. Взамен появляется требование, что конвейер наружу не обращается вовсе. Из выборки воркера и из требования о держателе захвата уходят оговорки про записи без владельца и про ответ отправителю.
  • access: запись без владельца перестаёт быть возможной. Правило «чужую запись не отдают» не меняется; остаётся и правило «пустой владелец не совпадает ни с одной записью» — оно запрещает спрашивать ничьим именем, а не заводить ничью запись.
  • storage: колонка владельца у аудиозаписи и у файла перестаёт принимать пустое значение — это новый шаг схемы. Приведённая копия файла получает владельца своей записи. Из требований о подъёме на чистом каталоге и о пароле владельца уходит «обоими входами».

Impact

  • Код: удаляются клиент бота, отправитель сообщений, разбиение длинного текста, заглушка отправителя, транспорт бота, сборка входа при старте и договор об отправителе сообщений. Из службы расшифровки уходят приём записи от бота и отправка текста в чат.
  • Настройки: секция [telegram] целиком и ключ server.users_while_list (имя ключа в коде написано с опечаткой, и она здесь воспроизведена намеренно — искать в боевом файле надо именно его).
  • Зависимости: go-telegram-bot-api/telegram-bot-api/v5 уходит из манифеста.
  • Хранилище: один новый шаг схемы, и он делает колонку владельца обязательной у аудиозаписи и у файла. Применённые шаги не переписываются, колонки чата и ответного сообщения остаются на месте вместе с записями, которые их заполнили.
  • Наблюдение: метка telegram у признака поднятого входа больше не выставляется.
  • Документы: паспорт теряет потребителя и два типовых сценария; инвариант о белом списке бота уходит из памятки; модель угроз теряет вход.
  • Задачи беклога: telegram-account-link и bot-api-only-through-bot-client теряют предмет до возвращения бота. Судьбу их решает владелец — это изменение их не закрывает.