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