# Ревью дизайна — telegram-enabled-flag

Метка `medium`, назначена агентом `review-scope` (размер среднее, сложность
знакомое). Режим по графу. Состав по метке: `specs` (режим «дизайн ДО кода») и
`rubric`. Триажа на этой стадии нет — сток стадии — шаг отработки замечаний.

## Находки и что с ними сделано

| Проход | Находка | Severity | Исход |
| --- | --- | --- | --- |
| specs | У выключенного входа нет оракула: «бот не заведён, отказа нет» остаётся верным и когда ветка встала **после** обращения, а обращение ушло боевым токеном в живой Telegram | major | принята. Заведён шов `telegramFromConfig(cfg, newBot, logger)`, шаг 3.3 судит по счётчику вызовов, а не по исходу |
| specs | `ADR-2026-08-13-telegram-outage-does-not-block-startup` утверждает, что старт роняет ровно один исход сборки клиента; после изменения их два | minor | принята. Шаг 4.7: новый ADR и парный статус прежнему |
| specs | `docs/architecture.md` (перечень capability) и `docs/review.md` (рецепт живого прогона) останутся ложными: они учат поднимать сервис пустым токеном | minor | принята. Шаги 4.5 и 4.6 |
| specs | Ошибочный `enabled = false` из шаблона выкладки — оставшееся русло молчаливой потери бота — в рисках не назван | minor | принята. Строка в `Risks / Trade-offs` |
| rubric | Отказ разбора файла настроек может унести секрет в журнал: `toml.ParseError` встраивает разбираемое значение в текст | major | **снята из объёма, ушла в урожай.** Путь существует сегодня (`LoadConfig` заворачивает через `%w`, `main.go:49` печатает целиком) и этой работой не заводится; у починки своя цена — потеря подробности отказа |
| rubric | Задача, принятая из Telegram до выключения входа, завершится, а ответ не уйдёт | major | **снята: ложноположительная.** Уже нормировано `openspec/specs/pipeline/spec.md`, «Недоставленный ответ не роняет шаг», сценарий «Вход отправителя не поднят»: `WARN`, метрика, идентификатор задачи. Проход читал только `intake`; `specs` пришёл к тому же выводу независимо |
| rubric | Откат образа при `enabled = false` и непустом ключе тихо поднимает выключенного бота | minor | принята. Абзац в `Migration Plan` |
| rubric | `docs/conventions/config.md`, раздел «Структура в коде», останется утверждать, что умолчание есть у каждого поля | minor | принята. Шаг 4.4 расширен на второй раздел |

## Правки, сделанные по урожаю

Дельта-спеки не менялись ни одной правкой — значит разметка не повторялась и
метка осталась `medium`. Правки легли в `design.md` (шов сборки, два риска,
абзац отката) и в `tasks.md` (шаги 2.2, 3.2, 3.3, 4.4, 4.5, 4.6, 4.7, рубрика в
критерии приёмки).

## Сознательно не сделано

Сценарий «Вход выключен» не получил строки `**AND** признак поднятости входа
Telegram равен нулю`. Её держит соседнее требование «Поднятые входы видны
наблюдателю», чей сценарий стоит на премиссе «сервис поднялся без Telegram» и
новое состояние покрывает. Правка изменила бы дельта-спеку и потребовала бы
повторной разметки, не дав сегодня ничего.

## Границы спеки — что осталось неопределённым

- **Небулево значение признака** (`enabled = "yes"`) попадает в общий отказ
  разбора и имени ключа не называет, хотя оба соседних сценария отказа этого
  требуют.
- **Несколько негодных секций разом**: `[auth]` и `[telegram]` проверяются
  порознь, и спека не говорит, обязан ли отказ перечислить все ключи.
- **`update_timeout` при выключенном входе** — читается или игнорируется, не
  нормировано. Вреда нет, но вопрос стал видимым: сборка получает секцию целиком.
- **Проба готовности при выключенном входе** ни одним требованием не связана с
  признаком. Граница существовала и до изменения.

## Границы покрытия стадии

- Кода нет по построению: направление `spec → code` недоступно, судилось только
  задуманное.
- Рубрика составлена не открывая код и дизайн — иначе она подстроилась бы под
  увиденное.
- Решения (`docs/adr/`) и измеренные числа (`docs/research/`) прогон ревью не
  открывает: расхождение изменения с записанным решением ловит не он, а сверка
  документации. Здесь оно всё же всплыло — проход `specs` наткнулся на ADR через
  ссылку из `design.md`, а не обходом каталога.
- Ничего не запускалось: `openspec validate --strict` — единственная выполненная
  команда.
- `review-architecture` на предложении не запускался: он живёт с метки `large`.
  Вопрос «не появился ли второй способ делать то же самое» на этом изменении не
  задавал никто.
- Шаблон настроек в `pet-project-server` лежит в чужом репозитории и во вход не
  входил ни одному проходу.