transcriber/openspec/changes/archive/2026-08-15-remove-telegram-intake/design.md

## Context

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

Вход Telegram при этом несёт собственный вес: клиент, транспорт обновлений,
разбиение длинного текста на сообщения, заглушка отправителя, сборка входа при
старте с разбором «недоступность или ошибка настройки», список допущенных людей,
доставка ответа из конвейера и правило о недоставленном ответе.

Ограничение, которое правит решением: применённый шаг схемы не переписывается —
это инвариант проекта, и он **critical**. Колонки `tg_chat_id`,
`tg_reply_message_id` и значение `telegram` перечня `source` заведены шагами
`202608110001` и `202608140002`, оба применены. В боевой базе по этим колонкам
лежат записи живых людей.

## Goals / Non-Goals

**Goals:**

- Убрать вход Telegram из кода, настроек и зависимостей целиком.
- Сделать владельца записи безусловным: завести запись без владельца сервису
  нечем.
- Сделать владельца обязательным **в схеме**, а не только в приёме: ни одной
  записи не потерять и ни одного применённого шага схемы не переписать.
- Оставить возврат входа дешёвым: удалённое лежит в истории git одним изменением,
  и возвращается оно вместе со связью чата и учётной записи.

**Non-Goals:**

- Замена доставки ответа. Уведомлений взамен чата не заводим — на это стоит
  задача `ntfy-delivery`.
- Чистка хранилища от колонок и значений бота. Ни нового шага схемы, ни правки
  применённых.
- Переделка приёма по HTTP, конвейера, распознавания и панели.
- Связь чата Telegram с учётной записью. Она нужна возврату входа, и заводит её
  своя задача.

## Decisions

### Схема теряет только необязательность владельца

Колонки чата и ответного сообщения остаются, значение `telegram` в перечне
источников остаётся, применённые шаги не переписываются. Новый шаг схемы у
изменения один, и делает он ровно одно: колонка владельца у аудиозаписи и у файла
перестаёт принимать пустое значение.

Шаг безопасен потому, что записей без владельца в боевой базе нет — это сказал
владелец сервиса, отвечая на прямой вопрос, и на этом ответе решение и стоит.
Будь такие записи, шаг пришлось бы либо отменить, либо оплатить необратимой
правкой чужих данных: назначить им владельца выдумкой или удалить.

**Проверяется это запросом, а не прогоном шага**, и разница выяснилась ревью с
оракулом: хранилище держит обязательность связи проверкой записи при сохранении,
а не ограничением таблицы. Смена признака на базе с ничьей записью проходит
зелёным и такую запись оставляет — то есть прогон шага на копии боевой базы
чистую базу от грязной не отличает. Заставить шаг считать строки самому владелец
решил не делать (решение от 2026-08-14): безопасность держится ручной проверкой,
и она названа первым шагом плана перехода.

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

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

Рассмотрено и отвергнуто:

- **Новый шаг, убирающий колонки бота.** Он законен — запрет стоит на правке
  применённого шага, а не на новом, — но необратим по данным: колонки заполнены у
  записей живых людей, и восстановить их после удаления неоткуда. Возврат входа
  завёл бы их заново пустыми.
- **Сужение перечня `source` до `unknown` и `api`.** Строки со значением
  `telegram` в базе есть, и после сужения перечня они перестают проходить
  проверку схемы: панель откажется их сохранять, а поведение записи при чтении
  зависит от библиотеки. Цена — молчаливая порча уже принятых записей.

Поля адресата уходят при этом из **модели** — колонки остаются в схеме, а
аудиозапись их больше не несёт. Это безопасно ровно потому, что колонки адресата
пишет только заведение записи: снимок шага конвейера кладётся отображением, где
их нет вовсе, и потому значение уже принятой записи он не затирает. Правила
`internal/archrules` такую пару держат: колонка, которую никто не пишет, законна,
незаконна колонка, которую пишут, но не читают.

Следствие: константа `entity.SourceTelegram` остаётся в модели. На неё ссылается
применённый шаг `202608140002`, и убрать её значило бы переписать применённый
шаг. В модели она получает комментарий об историческом значении: новых записей с
ним не появляется.

### Владелец записи перестаёт быть необязательным и в модели

Поле владельца в аудиозаписи становится обычной строкой вместо ссылки, которой
позволено отсутствовать. Модель здесь повторяет схему, а не расходится с ней:
значения «владельца нет» больше не существует ни на одном уровне.

Рассмотрено и отвергнуто:

- **Оставить ссылку, которой позволено отсутствовать.** Она заставляет каждого
  читателя решать, что делать с отсутствием, хотя отсутствия больше не бывает.
  Два способа выразить одно значение расходятся молча.
- **Держать обязательность одним приёмом, схему не трогать.** Так было задумано
  сперва, и это оставляло дыру: ничью запись заводили руками в панели, она
  уходила в конвейер, стоила денег на распознавание и не доставалась потом
  никому. Решение владельца от 2026-08-14 — обязательность держит схема.

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

### Отправителя о готовности и об остановке узнаёт опрос, и другого канала нет

Доставка из конвейера убирается вместе с договором об отправителе сообщений.
Правило о недоставленном ответе уходит: недоставке взяться неоткуда.

Рассмотрено и отвергнуто:

- **Оставить заглушку отправителя.** Договор без единой реализации, кроме
  пустой, — это мёртвый шов, который читается как незаконченная работа и
  переживает не одну задачу.
- **Завести уведомление взамен сразу.** Это другой предмет со своей внешней
  зависимостью; задача на него уже стоит в беклоге, и слепить их значит собрать
  два изменения в одно.

### Метка убранного входа не выставляется вовсе

Признак поднятого входа остаётся, метка `telegram` у него больше не появляется.
Ноль вместо неё читается как «вход есть, но не поднялся», то есть как поломка;
владелец, у которого на этот признак стоит отбор, увидел бы аварию на ровном
месте.

### Незнакомые ключи настроек по-прежнему не судятся

Секция `[telegram]` и ключ `server.users_while_list` убираются из структуры
настроек и из образца. Имя ключа написано с опечаткой — `while` вместо `white`, —
и это записано «Расхождением» в `docs/conventions/config.md`; удаление ключа
закрывает и его. Файл, где их забыли, сервис поднимет молча: разбор настроек
незнакомые ключи не проверяет.

Рассмотрено и отвергнуто: **завести отказ старта по незнакомому ключу**. Это
новое поведение настроек, полезное само по себе, но чужое этой задаче: оно
касается всех ключей, а не убранных, и разбирается своей задачей.

## Risks / Trade-offs

- **У сервиса не остаётся входа, которым человек может воспользоваться.** Это
  главный риск изменения, и он не смягчается ничем внутри задачи. Приложения нет,
  своего токена у программы нет, значит после выкладки положить запись можно
  единственным способом: собранным руками запросом с сессией, снятой из браузера
  после входа. Срок этого состояния задаётся чужими задачами — экраном приложения
  и личными токенами, — и внутри этой задачи не назначается. Прецедент в журнале
  ревью: 2026-08-12 поверхность закрыли так, что войти не мог никто, и спасением
  тогда был именно бот.
- **Боевой файл настроек переживёт выкладку с мёртвой секцией** → сервис
  поднимется без бота, и это ровно то, чего мы хотим; секцию убирает человек при
  выкладке, и об этом сказано в плане перехода.
- **Записи, застрявшие в конвейере на минуту выкладки, дойдут до текста, и ответа
  в чат по ним не уйдёт** → отправитель в Telegram ответа не получит вовсе.
  Смягчения нет и быть не может: чат — это и есть убираемый вход. Расшифровка не
  теряется, владелец сервиса видит её в панели.
- **Ничья запись, если она всё же найдётся, шагом не ловится** → она остаётся в
  базе и становится незакрываемой: сохранить её нечем, остановить тоже, а следа
  не остаётся ни в метрике, ни в журнале событий. Смягчение одно и ручное —
  проверка запросом первым шагом плана перехода. Заставить шаг считать строки
  самому владелец решил не делать.
- **Возврат входа стоит восстановления кода** → удаление уезжает одним
  изменением, и его архив вместе с историей git даёт точку возврата. Связь чата с
  учётной записью всё равно потребует нового кода: без неё возвращать вход значит
  возвращать записи без владельца.
- **Правила, потерявшие предмет, останутся в памятке и в модели угроз** →
  инварианты про белый список бота и про ответ отправителю убираются синком
  документации тем же изменением, а не следующей задачей.

## Migration Plan

1. Проверить боевую базу запросом: `SELECT count(*) FROM audio_records WHERE
   owner = ''` и то же по `files`. Оба должны отдать ноль. Прогон самого шага на
   копии этого не показывает — он проходит зелёным и на грязной базе.
2. Собрать образ (`task image`) — сборка образа в гейт не входит, и человек
   обязан прогнать её сам.
3. Выложить (`inv pl -- transcriber` из `pet-project-server`) — запускает человек.
4. Убрать из боевого файла настроек секцию `[telegram]` и ключ
   `server.users_while_list`. Порядок с шагом 3 безразличен: оставленные ключи
   сервис пропускает молча, и для подъёма этот шаг не нужен.
5. Ключ доступа к боту остаётся в хранилище выкладки под возврат входа — решение
   владельца от 2026-08-14. Ротация не делается, бот у Telegram остаётся
   зарегистрированным. Цена решения названа прямо: отправитель голосового не
   получит ни ответа, ни отказа и не отличит выведенный вход от сломанного
   сервиса. Оповещать людей из списка допущенных владелец не стал.
6. Откат — прежний образ. Он потребует вернуть настройки: сервис прошлой версии
   без ключа `telegram.enabled` не поднимается. Схему откат вернёт своим
   обратным шагом — колонка владельца снова примет пустое значение, — и на
   записях это не сказывается: пустых среди них нет.

### Формы решения, между которыми выбирали

Форма выбрана не единственной рассмотренной, и остальные две названы здесь, а не
подразумеваются:

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

## Open Questions

- Критерии приёмки постановка не назвала: они предложены в `tasks.md` и
  подтверждаются человеком на чекпоинте.
- Судьба задач беклога `telegram-account-link` и
  `bot-api-only-through-bot-client`: обе теряют предмет до возвращения входа.
  Решает владелец; это изменение их не трогает.