- убраны клиент бота, транспорт обновлений, отправитель сообщений, сборка
входа при старте, секция настроек и зависимость go-telegram-bot-api; из
конвейера ушла доставка ответа отправителю — исход виден опросом готовности.
Колонки адресата и значение источника остались в схеме: применённые шаги не
переписываются
- шаг 202608140003 запрещает пустого владельца у аудиозаписи и у файла;
существующие строки он не проверяет, и это принято сознательно — искать их
надо запросом до выкладки
- ревью нашло два пред-существующих дефекта, оба закрыты: пустой второй ответ
распознавателя стирал сохранённую расшифровку, а пустая расшифровка перестала
быть заметной вместе с убранной доставкой. Попутно поднят golang.org/x/image
до v0.45.0 — красный шаг vulns, воспроизводился и на чистом master
- в секции [telegram] заведён обязательный ключ enabled: умолчания у него нет,
файл без него негоден; bot_token стал только ключом доступа и при
enabled = false не читается вовсе, а пустой при enabled = true роняет старт
- выключенный вход даёт подъём одним входом без единого обращения к Telegram и
записью INFO вместо прежнего WARN: это выбор владельца, а не отклонение
- отказ разбора файла настроек больше не пересказывает toml — её ParseError
несёт в тексте разбираемое значение, и оборванная строка секретного ключа
уносила его в журнал; теперь называются путь, строка, столбец и последний ключ
- Клиент бота собирается один раз и достаётся отправителю и транспорту;
разрез прошёл по «ответил ли Telegram»: ответ «такого бота нет» роняет
старт, недоступность даёт подъём без Telegram (ADR-2026-08-13). Ожидание
при сборке ограничено сроком — иначе молчащий Telegram вешал подъём.
- Недоставленный ответ не роняет шаг: пишется с job_id и считается метрикой,
уровень по причине — WARN для неподнятого входа, ERROR для неназванного
адресата. Заведены transcriber_intake_up и transcriber_undelivered_reply_count.
- Закрыта утечка токена в журнал: отказ разбора адреса рождается раньше
обращения к клиенту, то есть мимо чистки на его границе.
av