transcriber/openspec/changes/archive/2026-08-13-start-without-telegram-token/proposal.md at a5bc322814cd28ae0716297f411cd17a66b47dc2

Files

T

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

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

2026-08-13 19:10:08 +03:00

3.9 KiB

Raw Blame History

Why

Сервис принимает записи двумя входами — ботом Telegram и HTTP API, — но поднимается только тогда, когда настроены оба: пустой токен бота кончает старт отказом раньше, чем встаёт HTTP-сервер. Боевым токеном запускаться запрещено, и из этого следует, что поднять сервис и посмотреть на него живьём не может никто: всякая задача, меняющая поведение, проверяется одними тестами.

Намерение «работать без Telegram» в сервисе уже есть — отдельное значение «токен не задан» и терпимость к отказу сборки бота при старте, — но один путь его отменяет, и потому оно ничего не значит.

What Changes

Ненастроенный вход Telegram больше не мешает подъёму: сервис встаёт и работает оставшимся входом — принимает записи по HTTP, расшифровывает их и отдаёт текст туда же. Об отсутствии бота сервис говорит одной строкой журнала при старте, а не молчанием.
Задача, пришедшая из Telegram и дошедшая до ответа тогда, когда бота нет, доводится до конца, а факт недоставки уезжает в журнал владельца. Сегодня такая задача уронила бы процесс.
Запрет запускаться боевым токеном остаётся: рядом с ним появляется способ поднять сервис без токена вовсе.

Ломки нет: с заданным токеном не меняется ничего.

Capabilities

New Capabilities

Новых нет: оба требования ложатся в capability, чей раздел Purpose сам называет их своим предметом и приглашает дописать.

Modified Capabilities

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

Impact

сборка сервиса при старте: отправитель ответов и клиент бота;
ответ отправителю в конвейере расшифровки;
секция [telegram] конфига и её образец config.dist.toml;
CLAUDE.md, раздел «Запреты» — рядом с запретом на боевой токен встаёт способ подняться без него;
docs/review.md, подраздел «Недоступно проверке» — строка о недоступности живого прогона сужается;
docs/architecture.md — перечень capability и то, что каждая нормирует.

Внешних зависимостей, схемы хранилища и контракта HTTP API изменение не трогает.

3.9 KiB Raw Blame History

Why