удалён вход Telegram, владелец записи стал обязателен в схеме

- убраны клиент бота, транспорт обновлений, отправитель сообщений, сборка
  входа при старте, секция настроек и зависимость go-telegram-bot-api; из
  конвейера ушла доставка ответа отправителю — исход виден опросом готовности.
  Колонки адресата и значение источника остались в схеме: применённые шаги не
  переписываются
- шаг 202608140003 запрещает пустого владельца у аудиозаписи и у файла;
  существующие строки он не проверяет, и это принято сознательно — искать их
  надо запросом до выкладки
- ревью нашло два пред-существующих дефекта, оба закрыты: пустой второй ответ
  распознавателя стирал сохранённую расшифровку, а пустая расшифровка перестала
  быть заметной вместе с убранной доставкой. Попутно поднят golang.org/x/image
  до v0.45.0 — красный шаг vulns, воспроизводился и на чистом master

openspec/specs/access/spec.md

@@ -10,12 +10,10 @@ OIDC, чем предъявляется сессия, что её прекращ
 только на вопрос «узнан ли пришедший», но и на «чьё он смотрит». Запись из веба
 принадлежит тому, кто её принёс, и чужая неотличима от несуществующей.
 
-Записи, принятые ботом, владельца не имеют вовсе и по API не достаются никому:
-связи чата Telegram с учётной записью приложения сервис не ведёт, её заводит
-отдельная задача.
-
-Вход из Telegram эта capability не нормирует: бот проверяет отправителя своим
-белым списком, и с учётной записью приложения тот список не связан.
+Записи без владельца у сервиса не бывает: колонка владельца пустого значения не
+принимает, и норму эту держит capability `storage`. Прежде такие записи заводил
+вход Telegram — связи чата с учётной записью сервис не вёл, — и 2026-08-14 вход
+убран вместе с этим исключением.
 ## Requirements
 ### Requirement: Вход через внешнего провайдера
 
@@ -350,13 +348,14 @@ MUST не делать. Кто допущен, определяет правил
 
 ### Requirement: У записи есть владелец, и чужую ей не отдают
 
-Сервис SHALL заводить у каждой записи, принятой **по HTTP**, — владельца, то
-есть учётную запись, от имени которой запись принята, — и MUST отдавать данные
-такой записи только её владельцу. Владелец назначается один раз, при приёме, и
-MUST не меняться у записи, у которой владелец есть: совместного доступа, ролей и
-передачи записи другому сервис не знает. Оговорка не случайна — назначить
-владельца записи, у которой его нет, вправе задача, заводящая связь чата
-Telegram с учётной записью.
+Сервис SHALL заводить у каждой принятой записи владельца — учётную запись, от
+имени которой запись принята, — и MUST отдавать данные такой записи только её
+владельцу. Запись без владельца MUST не заводиться ничем — ни приёмом, ни конвейером, ни
+рукой в панели: колонка владельца пустого значения не принимает, и норму эту
+держит capability `storage`.
+
+Владелец назначается один раз, при приёме, и MUST не меняться: совместного
+доступа, ролей и передачи записи другому сервис не знает.
 
 Владелец MUST браться из предъявленной сессии и ниоткуда больше. Владелец,
 пришедший полем запроса, дал бы всякому вошедшему право завести запись на чужое
@@ -368,16 +367,12 @@ Telegram с учётной записью.
 что разграничение прячет. Каким именно ответом это выражено, нормирует
 capability `intake`: там живёт адрес опроса, и держатель нормы обязан быть один.
 
-Пустой владелец MUST не совпадать ни с одной записью — ни со своей, ни с чужой,
-ни с ничьей. Правило записано со стороны **спрашивающего**, а не со стороны
-записи: обязательность владельца, которую держит одна лишь подпись метода, пустую
-строку пропускает, и первый же вызывающий без учётной записи получил бы ровно
-множество записей без владельца, то есть все записи бота.
-
-Записи, принятые из Telegram, владельца не имеют: связи чата с учётной записью
-приложения сервис не ведёт. Такая запись MUST не доставаться по API никому —
-ответ на неё тот же, что и на несуществующую, — а её расшифровка уезжает
-отправителю в чат, как и прежде.
+Пустой владелец MUST не совпадать ни с одной записью. Правило записано со стороны
+**спрашивающего** и остаётся в силе, хотя записей без владельца в хранилище
+больше нет: спрашивающий с пустым владельцем — это вызов, у которого нет учётной
+записи, и отвечать ему надо отказом, а не выборкой. Держится оно отдельно от
+схемы намеренно: схема запрещает **заводить** ничью запись, а это правило
+запрещает **спрашивать** ничьим именем, и одно другое не заменяет.
 
 #### Scenario: Своя запись доступна
 
@@ -396,15 +391,13 @@ capability `intake`: там живёт адрес опроса, и держат
 - **WHEN** запрос на приём записи несёт своё значение владельца
 - **THEN** владельцем принятой записи становится предъявитель сессии
 
-#### Scenario: Запись из Telegram не достаётся по API
+#### Scenario: Ничью запись завести нечем
 
-- **GIVEN** запись принята ботом
-- **WHEN** её состояние спрашивает вошедший человек
-- **THEN** ответ тот же, что и на неизвестный идентификатор
+- **WHEN** запись пытаются завести с пустым владельцем
+- **THEN** хранилище её не сохраняет
 
 #### Scenario: Пустой владелец не открывает ничего
 
-- **GIVEN** заведены три задачи: своя, чужая и принятая ботом
+- **GIVEN** заведены две записи: своя и чужая
 - **WHEN** состояние каждой спрашивают с пустым владельцем
-- **THEN** ответ на все три тот же, что и на неизвестный идентификатор
-
+- **THEN** ответ на обе тот же, что и на неизвестный идентификатор

openspec/specs/intake/spec.md

@@ -6,12 +6,9 @@
 записью, что уезжает в ответ и что происходит, когда запись не удалось
 прочитать. Плюс наличие входов: с каким из них сервис вправе подняться.
 
-Приём по существу описан пока **только для HTTP** — того, что нормируют
-проверки. Про вход Telegram нормировано одно: настроен он или нет и что из этого
-следует для подъёма. Кто допущен к боту и как забирается присланная им запись,
-требованиями по-прежнему не описано — требование, написанное без проверки, это
-предположение, а не норма. Первая задача, которая трогает поведение приёма из
-Telegram, дописывает его сюда.
+Вход у сервиса один — приём по HTTP, — и описан он тем, что нормируют проверки.
+Второй вход, Telegram, убран 2026-08-14 вместе со своими требованиями; его
+возвращение заводит их заново, вместе со связью чата и учётной записи.
 ## Requirements
 ### Requirement: Приём записи по HTTP
 
@@ -40,10 +37,12 @@ Telegram, дописывает его сюда.
 Куда именно ложится принятая запись, приёму не принадлежит: раскладку выбирает
 хранилище, и нормирует её capability `storage`.
 
-Владельцем принятой записи приём SHALL назначать предъявителя сессии. Проверка
-стоит здесь, а не только в схеме хранилища: колонка владельца допускает пустое
-значение ради записей из Telegram, и приём по HTTP — то место, где
-обязательность держится.
+Владельцем принятой записи приём SHALL назначать предъявителя сессии. Обязательность
+владельца при этом MUST держаться и схемой хранилища: колонка владельца пустого
+значения не принимает вовсе, и норму эту держит capability `storage`. Проверка в
+приёме от этого не лишняя — она отвечает отправителю понятным отказом до того, как
+запись попадёт в память, а схема отвечала бы отказом сохранения после укладки
+файла.
 
 Предъявитель, чья сессия не даёт учётной записи пользователя, MUST получать
 отказ `403` и MUST получать его **до чтения тела** — там же, где стоит отказ по
@@ -154,11 +153,9 @@ Telegram, дописывает его сюда.
 нормирует требование ниже; наружу расширение выходит только приведённым к
 известному виду — этому отдано отдельное требование.
 
-Сценарии судят приём по HTTP, потому что имя, данное отправителем, доходит до
-сервиса только оттуда: из Telegram приходит путь, выданный самим Telegram, а не
-имя человека. Правка при этом ложится на общий шаг заведения задачи, через
-который идут оба входа, поэтому своей нормы приём из Telegram здесь не получает —
-её напишет задача, которая тронет его поведение.
+Оговорка про второй вход из требования ушла вместе с ним: имя, данное
+отправителем, доходит до сервиса единственным путём — приёмом по HTTP, — и
+сценарии судят именно его.
 
 #### Scenario: Имя записи не видно в журнале принятой записи
 
@@ -265,15 +262,15 @@ Telegram, дописывает его сюда.
 Остановленная запись MUST отдавать рубеж, на котором она остановлена, и MUST
 нести признак остановки отдельным полем `halted` со значением истины. Машинный
 текст отказа MUST в ответ не попадать: он принадлежит журналу владельца сервиса,
-а не отправителю. Отправитель узнаёт о неудаче ответом там, откуда пришла
-запись, — это нормирует capability `pipeline`.
+а не отправителю. Этот адрес — **единственное** место, где отправитель узнаёт о
+неудаче: доставки ответа отправителю у сервиса больше нет, и признак остановки
+здесь несёт всю обязанность целиком.
 
 Отказ без сессии MUST не зависеть от того, есть такая запись или нет: иначе по
 кодам ответа перебирается список заведённых записей.
 
 Запись, принадлежащая другому, MUST отвечать тем же, чем отвечает неизвестный
-идентификатор, — кодом `404` и тем же телом. То же MUST относиться к записи без
-владельца: запись, принятая ботом, по этому адресу не достаётся никому.
+идентификатор, — кодом `404` и тем же телом.
 
 #### Scenario: Запись найдена
 
@@ -325,117 +322,25 @@ Telegram, дописывает его сюда.
 ### Requirement: Поднятые входы видны наблюдателю
 
 Сервис SHALL отдавать признак поднятости по каждому входу приёма отдельной
-метрикой. Признак MUST выставляться при сборке входа и MUST различать поднятый
-вход и неподнятый.
+метрикой и MUST выставлять метку только тому входу, который у сервиса есть.
+Метки убранного входа в метриках MUST не быть вовсе: признак со значением нуля
+читался бы как «вход есть, но не поднялся», то есть как поломка, а вечная
+единица рядом с ним — как исправность того, чего нет.
 
-Требование стоит на том, что иначе потерянный вход не виден ничем: проба
-здоровья отвечает «сервис работает» и при неподнятом боте, а запись журнала
-живёт до ротации и вопрос «работает ли вход сейчас» не отвечает. Метрика —
-единственный канал наблюдения, который у владельца автоматизирован.
+Проверяемое здесь одно — **набор меток**, и это честнее прежнего. Вход остался
+один, страница метрик отдаётся тем же сервером, что и приём, и значение нуля у
+единственной метки недостижимо: чтобы прочитать признак, надо дотянуться до
+входа, о котором он сообщает. Прежнее обоснование — «иначе потерянный вход не
+виден ничем» — было верно, пока входов было два; сегодня неподнятый вход виден
+неудачей чтения самих метрик.
 
-#### Scenario: Вход Telegram не поднят
+Различать поднятый и неподнятый вход признак MUST снова, как только входов у
+сервиса станет больше одного.
 
-- **GIVEN** сервис поднялся без Telegram
+#### Scenario: В метриках только оставшийся вход
+
+- **GIVEN** сервис поднялся
 - **WHEN** наблюдатель читает метрики
-- **THEN** признак поднятости входа Telegram равен нулю
-- **AND** признак поднятости входа HTTP равен единице
-
-### Requirement: Признак включения решает, поднимается ли вход Telegram
-
-Намерение владельца SHALL объявляться отдельным признаком включения входа
-Telegram, а ключ доступа MUST означать только доступ. При выключенном входе
-сервис MUST подниматься без Telegram и MUST не смотреть на ключ доступа вовсе.
-При включённом входе пустой ключ MUST быть отказом старта: сообщение называет имя
-незаполненного ключа и MUST не нести его значения.
-
-Признак включения MUST быть в настройках задан. Умолчания у него нет: файл, где
-признака нет вовсе, негоден, и сервис MUST выходить с ошибкой настройки, назвав
-недостающий ключ. Умолчание здесь было бы угаданным намерением, а признак заведён
-затем, чтобы намерение объявляли: любое умолчание делает одну из двух ошибок
-тихой — либо бот молча пропадает, либо файл без признака молча работает.
-
-Выключенный вход MUST быть назван в журнале **ровно одной** записью уровня `INFO`
-при старте. Это выбор владельца, а не отклонение, и предупреждать о нём не о чем;
-предупреждение остаётся за тем, чего владелец не выбирал.
-
-При включённом входе сервис SHALL подниматься, когда вход поднять не удалось, и
-MUST продолжать работу оставшимся входом: приём по HTTP, опрос готовности и
-конвейер расшифровки работают в полном объёме. Неподнятый вход MUST быть назван в
-журнале **ровно одной** записью уровня `WARN` при старте — с причиной и без
-значения ключа.
-
-Исключение одно, и оно проходит по тому, **ответил ли Telegram**. Ответ «такого
-бота нет» — ошибка настройки: бот по этому ключу не появится ни от ожидания, ни
-от повтора, и старт MUST кончаться отказом. Сервис, молча потерявший бота после
-опечатки в ключе, перестаёт отвечать своим отправителям, и узнать об этом было бы
-неоткуда.
-
-Всё прочее — недоступность: сеть, DNS, авария Bot API, истёкший срок ожидания.
-Она MUST не влиять на подъём. Основной вход сервиса — не Telegram, и ронять его
-целиком из-за чужой аварии нельзя: перезапуск в такую минуту оставил бы без
-работы и приём по HTTP, и панель, и конвейер, которому Telegram не нужен вовсе.
-
-Ожидание при сборке MUST быть ограничено сроком. Без него недоступность
-неотличима от подъёма: обращение к Telegram стоит на пути старта, и молчащий
-собеседник останавливал бы его бессрочно — без записи, без порта и без пробы
-здоровья.
-
-Требование нормирует **наличие входа**, а не приём из него.
-
-#### Scenario: Вход выключен
-
-- **GIVEN** в настройках сервиса вход Telegram выключен
-- **WHEN** сервис запускается
-- **THEN** он поднимается и принимает записи по HTTP
-- **AND** конвейер расшифровки работает
-- **AND** бот не заведён, а в журнале ровно одна запись уровня `INFO` о том, что
-  вход выключен настройкой
-
-#### Scenario: Вход выключен, а ключ доступа задан
-
-- **GIVEN** в настройках сервиса вход Telegram выключен
-- **AND** ключ доступа при этом заполнен
-- **WHEN** сервис запускается
-- **THEN** он поднимается без Telegram, и бот не заводится
-- **AND** к Telegram не уходит ни одного обращения
-
-#### Scenario: Вход включён, а ключа доступа нет
-
-- **GIVEN** в настройках сервиса вход Telegram включён
-- **AND** ключ доступа пуст
-- **WHEN** сервис запускается
-- **THEN** старт кончается отказом
-- **AND** сообщение об отказе называет имя незаполненного ключа
-
-#### Scenario: Признака включения в настройках нет
-
-- **GIVEN** в настройках сервиса нет признака включения входа Telegram
-- **AND** ключ доступа заполнен и Telegram признаёт по нему бота
-- **WHEN** сервис запускается
-- **THEN** старт кончается отказом настройки
-- **AND** сообщение об отказе называет недостающий ключ
-
-#### Scenario: Вход включён и ключ годен
-
-- **GIVEN** в настройках сервиса вход Telegram включён
-- **AND** стоит ключ, по которому Telegram признаёт бота
-- **WHEN** сервис запускается
-- **THEN** он поднимается и работает обоими входами
-
-#### Scenario: Telegram не отвечает
-
-- **GIVEN** в настройках сервиса вход Telegram включён и ключ непуст
-- **AND** Telegram недоступен либо не отвечает дольше отведённого срока
-- **WHEN** сервис запускается
-- **THEN** он поднимается и принимает записи по HTTP
-- **AND** бот не заведён, а в журнале запись уровня `WARN` с причиной
-- **AND** запись не несёт значения ключа
-
-#### Scenario: Telegram ответил, что такого бота нет
-
-- **GIVEN** в настройках сервиса вход Telegram включён и ключ непуст
-- **AND** Telegram отвечает отказом на этот ключ
-- **WHEN** сервис запускается
-- **THEN** старт кончается отказом
-- **AND** ни журнал, ни текст отказа не несут значения ключа
+- **THEN** признак поднятости несёт метку входа HTTP со значением единицы
+- **AND** метки убранного входа Telegram в метриках нет вовсе
 

openspec/specs/pipeline/spec.md

@@ -3,14 +3,14 @@
 ## Purpose
 
 Конвейер расшифровки: как аудиозапись движется по рубежам, что делает воркер,
-когда работы нет, что считается отказом шага и что бывает с ответом отправителю,
-когда доставить его некуда.
+когда работы нет, и что считается отказом шага.
 
 Описаны цепочка рубежей и смысл рубежа, остановка признаком и её причины, оба
 сторожа — число отказов и время в рубеже, — откладывание работы отдельно от
 перехода, неделимость захвата и срок его протухания, условие записи результата
 держателем захвата, нарастающая пауза перед повтором, число воркеров настройкой,
-журнал событий записи и недоставка ответа при неподнятом входе.
+журнал событий записи и молчание конвейера наружу: обращений к отправителю он не
+делает вовсе, и свой исход тот узнаёт опросом готовности.
 
 Сознательно не описаны: освобождение ресурсов внешних клиентов и **какие отказы
 считаются приговором записи, а какие поводом к повтору**. Второе — не пробел
@@ -101,7 +101,7 @@
 захват, перевыданный другому — по протуханию срока или после того, как человек
 снял признак остановки в панели, — обязан обращать запись первого в отказ.
 Условие, проверяющее лишь непустоту признака или срок, пропустило бы обоих, и
-два шага записали бы в одну запись и оба ответили бы отправителю.
+два шага записали бы в одну запись по очереди, испортив её результат.
 
 Одна и та же запись MUST доставаться ровно одному захватившему. Двум вызывающим,
 пришедшим за работой одновременно, запись MUST достаться одному, а второй MUST
@@ -155,14 +155,18 @@
 всё ещё принадлежит ему. Запись MUST быть условна по **признаку этого захвата** —
 значению, уникальному для каждого захвата, — а не по занятости записи вообще.
 Шаг, чей захват за время работы достался другому, MUST завершиться без записи
-результата и без ответа отправителю.
+результата.
 
 Требование закрывает то, чего неделимость захвата не закрывает: захват протухает
 не только у мёртвого воркера, но и у живого — шаг, идущий дольше своего срока,
 теряет запись, продолжая работать. Снять захват может и человек, вернувший
 остановленную запись в работу. Без условия по уникальному признаку два воркера
-пишут в одну запись по очереди, счётчик отказов сбрасывает тот, кто уже не
-владелец, а отправитель получает два ответа на одну запись.
+пишут в одну запись по очереди, а счётчик отказов сбрасывает тот, кто уже не
+владелец.
+
+Довод про два ответа отправителю из требования ушёл вместе с доставкой: обращений
+наружу шаг не делает. Требование от этого не ослабло — порча записи двумя
+пишущими остаётся его предметом целиком.
 
 Шаг MUST записывать только те поля, которыми распоряжается сам. Запись он держит
 снимком с момента захвата и до записи — это часы, — и безусловная запись снимка
@@ -185,7 +189,6 @@
 - **AND** за это время та же запись досталась другому захвату
 - **WHEN** первый шаг доходит до записи результата
 - **THEN** результат не записывается
-- **AND** отправителю ничего не отправляется
 
 #### Scenario: Человек снял остановку под работающим шагом
 
@@ -263,89 +266,18 @@ MUST расти с числом её отказов до объявленног
 - **THEN** задержка до следующей проверки каждый раз одна и та же
 - **AND** число отказов записи не растёт
 
-### Requirement: Недоставленный ответ не роняет шаг
-
-Шаг конвейера SHALL доводить запись до достигнутого рубежа, когда ответ
-отправителю доставить не удалось, и MUST не считать недоставку отказом шага.
-Недоставка MUST быть записана в журнал владельца, MUST нести идентификатор
-записи, MUST называть причину и MUST считаться отдельной метрикой с причиной
-меткой.
-
-Причин у недоставки две, и исход у них общий: **вход отправителя не поднят** —
-запись заведена прошлым запуском, а сервис поднялся без этого входа; и **адресат
-у записи не назван** — источником значится Telegram, а чата в записи нет.
-
-Уровень записи MUST различать эти причины. Неподнятый вход — объявленный режим,
-и его уровень «может стать проблемой». Неназванный адресат — симптом порчи
-записи: у записи из Telegram чат есть всегда, и пропасть он может только от
-дефекта, самый коварный источник которого назван инвариантом проекта про колонки
-очереди. Один уровень на обе причины утопил бы этот сигнал в потоке штатных
-записей о ненастроенном боте.
-
-Общий исход — не упрощение, а следствие момента: ответ уходит **после** того, как
-достигнутый рубеж сохранён. Работа к этой минуте сделана, и объявленный отказ
-засчитался бы воркеру сбоем и лёг бы владельцу записью отказа — то есть соврал бы
-про исход дважды. Повтор делу не помогает: ни бот, ни адресат от ожидания не
-появятся. Поэтому запись остаётся на достигнутом рубеже, в повтор не уходит и
-**признака остановки не получает**, а причина недоставки живёт в записи журнала,
-а не в рубеже записи.
-
-То же MUST относиться к недоставке сообщения об **остановке**: остановка уже
-сохранена, и недоставка её MUST не отменять.
-
-Идентификатор записи в этой строке обязателен: без него владелец видит, что
-ответ не ушёл, но не может найти, чей. Текст расшифровки и сообщение отправителя
-в эту запись MUST не попадать — приватность содержимого записи требование не
-ослабляет.
-
-Отложенной доставки это требование не заводит: ответ, не ушедший сегодня, не
-уходит и потом. Забрать расшифровку можно там же, где лежат остальные.
-
-#### Scenario: Вход отправителя не поднят
-
-- **GIVEN** запись принята входом Telegram прошлым запуском сервиса
-- **AND** сервис поднялся без этого входа
-- **WHEN** шаг конвейера доходит до ответа отправителю
-- **THEN** шаг завершается без отказа, и воркер не считает прогон сбоем
-- **AND** запись остаётся на достигнутом рубеже, в повтор не уходит и признака
-  остановки не получает
-- **AND** в журнале есть запись уровня `WARN` о недоставке с идентификатором
-  записи и причиной
-- **AND** счётчик недоставленных ответов вырос с этой причиной меткой
-- **AND** ни текста расшифровки, ни сообщения отправителя в этой записи нет
-
-#### Scenario: Адресат у записи не назван
-
-- **GIVEN** у записи источником значится Telegram, а чат не назван
-- **WHEN** шаг конвейера доходит до ответа отправителю
-- **THEN** шаг завершается без отказа, и воркер не считает прогон сбоем
-- **AND** запись остаётся на достигнутом рубеже
-- **AND** в журнале есть запись уровня `ERROR` о недоставке с идентификатором
-  записи и причиной: неназванный адресат — симптом порчи записи
-
-#### Scenario: Не доехало сообщение об остановке
-
-- **GIVEN** запись остановлена признаком
-- **AND** вход отправителя не поднят
-- **WHEN** шаг доходит до ответа отправителю
-- **THEN** признак остановки у записи остаётся
-- **AND** в журнале есть запись о недоставке с идентификатором записи и причиной
-
-#### Scenario: Отвечать некуда, потому что запись пришла не из Telegram
-
-- **GIVEN** запись принята по HTTP
-- **WHEN** шаг конвейера доходит до ответа отправителю
-- **THEN** шаг завершается без отказа и без записи о недоставке
-
 ### Requirement: Выборка воркера владельцем не сужается
 
 Воркер SHALL брать записи всех владельцев подряд и MUST не учитывать владельца
-при выборе очередной записи. Запись без владельца — принятая ботом — MUST
-обрабатываться наравне с прочими.
+при выборе очередной записи.
 
 Владелец решает, кому запись показывать, а не кому её считать. Сужение выборки
-владельцем остановило бы расшифровку записей бота вовсе, а записи остальных
-поставило бы в зависимость от того, кто первым завёл учётную запись.
+владельцем поставило бы записи одних людей в зависимость от того, кто первым
+завёл учётную запись.
+
+Оговорка про записи без владельца из требования ушла: заводить их стало нечем —
+колонка владельца пустого значения не принимает, и норму держит capability
+`storage`.
 
 Владелец записи MUST переживать работу конвейера: шаг, сохраняющий свой
 результат, владельца не трогает и не затирает.
@@ -356,12 +288,6 @@ MUST расти с числом её отказов до объявленног
 - **WHEN** воркер забирает работу
 - **THEN** ему достаются обе, в порядке заведения
 
-#### Scenario: Запись без владельца обрабатывается
-
-- **GIVEN** заведена запись, принятая ботом, — без владельца
-- **WHEN** воркер забирает работу
-- **THEN** она достаётся ему наравне с прочими
-
 #### Scenario: Шаг конвейера владельца не затирает
 
 - **GIVEN** запись с владельцем прошла шаг конвейера
@@ -463,38 +389,6 @@ MUST расти с числом её отказов до объявленног
 - **THEN** число отказов, пауза и время входа в рубеж сброшены
 - **AND** ближайший захват выдаёт запись, а не останавливает её снова
 
-### Requirement: Всякая остановка сообщает отправителю
-
-Остановка записи по любой причине SHALL сообщать отправителю о неудаче ровно
-так же, как сообщает о ней отказ шага, и MUST быть видна владельцу сервиса
-записью в журнале.
-
-Требование стоит на инварианте проекта «Принятая запись не теряется молча»:
-инвариант допускает два исхода — запись пригодна к повтору либо об отказе
-сказано, — а остановленная запись захвату не выдаётся, значит первый исход
-исключён.
-
-Причин остановки больше одной, и обязанность общая для всех: исчерпанные
-отказы, застревание в рубеже, приговор шага. Обязанность, записанная у одной
-причины, у остальных читалась бы как снятая.
-
-Ответ уходит **после** того, как признак остановки сохранён, и недоставка этого
-ответа MUST не отменять остановку: её нормирует требование «Недоставленный ответ
-не роняет шаг».
-
-#### Scenario: Остановка по отказам сообщает отправителю
-
-- **GIVEN** запись остановлена по исчерпании отказов
-- **WHEN** шаг доходит до ответа отправителю
-- **THEN** отправитель получает сообщение о неудаче
-
-#### Scenario: Остановка по времени сообщает отправителю
-
-- **GIVEN** запись остановлена по пределу времени в рубеже
-- **WHEN** шаг доходит до ответа отправителю
-- **THEN** отправитель получает сообщение о неудаче
-- **AND** в журнале владельца есть запись об остановке с причиной
-
 ### Requirement: Время в рубеже ограничено
 
 У аудиозаписи SHALL быть время входа в рубеж, и оно MUST ставиться только при
@@ -674,8 +568,8 @@ MUST не быть привязаны к отдельному шагу: кажд
 
 Запись, захваченная с числом отказов сверх заданного предела, MUST
 останавливаться признаком тем, кто её захватил, и MUST не отдаваться шагу в
-работу. Об этой остановке отправителю сообщается наравне с прочими — норму
-держит требование «Всякая остановка сообщает отправителю».
+работу. Остановка эта видна отправителю опросом готовности наравне с прочими —
+норму держит capability `intake`.
 
 Этот сторож MUST отвечать только за повторы внутри шага. Время, проведённое
 записью в рубеже, MUST мериться отдельным сторожем: одно число не справляется ни
@@ -689,7 +583,7 @@ MUST не быть привязаны к отдельному шагу: кажд
 - **WHEN** запись проходит заданное число отказов
 - **THEN** у неё появляется признак остановки
 - **AND** следующий захват её не выдаёт
-- **AND** отправитель получает сообщение о неудаче
+- **AND** опрос готовности отдаёт владельцу записи признак остановки
 
 #### Scenario: Шаг уносит процесс, не объявив отказа
 
@@ -710,3 +604,39 @@ MUST не быть привязаны к отдельному шагу: кажд
 - **WHEN** смотрят её число отказов
 - **THEN** оно не приблизилось к пределу
 
+### Requirement: Конвейер ответа отправителю не шлёт
+
+Шаг конвейера SHALL доводить запись до достигнутого рубежа и MUST не обращаться
+к отправителю вовсе — ни с готовым текстом, ни с сообщением о неудаче. Исход
+своей записи отправитель узнаёт опросом готовности и в панели владельца; адрес
+опроса и содержимое ответа нормирует capability `intake`.
+
+Требование заведено взамен доставки в чат, убранной вместе с входом Telegram.
+Без него молчание конвейера читалось бы как недоделка: прежде ответ уходил, и
+всякий, кто помнит это, ищет в шаге отправку, а её отсутствие принимает за
+потерянную ветку.
+
+Инвариант проекта «Принятая запись не теряется молча» держится теперь опросом
+готовности — там остановка видна признаком — и журналом владельца, где у неё
+стоит причина. Обязанность при этом сменила направление: прежде об отказе
+сообщали, теперь отказ доступен спросившему. Отправитель, который не
+спрашивает, об остановке не узнаёт.
+
+Записи, которой этот канал недоступен, не бывает: у каждой записи есть владелец,
+и опрос отдаёт ему её исход. Держится это обязательностью владельца в схеме
+хранилища — норму держит capability `storage`.
+
+#### Scenario: Готовый текст отправителю не уходит
+
+- **GIVEN** запись дошла до конечного рубежа
+- **WHEN** шаг конвейера её завершает
+- **THEN** ни одного обращения наружу с текстом расшифровки не уходит
+- **AND** текст достаётся опросом готовности
+
+#### Scenario: Остановка видна опросом, а не сообщением
+
+- **GIVEN** запись остановлена по исчерпании отказов
+- **WHEN** владелец записи спрашивает её рубеж
+- **THEN** ответ несёт достигнутый рубеж и признак остановки
+- **AND** в журнале владельца сервиса есть запись об остановке с причиной
+

openspec/specs/storage/spec.md

@@ -17,8 +17,8 @@
 ### Requirement: Сервис поднимается на чистом каталоге данных
 
 Сервис SHALL приводить хранилище в рабочий вид сам: на пустом каталоге данных он
-MUST завести свою схему и принимать записи обоими входами без единого ручного
-шага до первого запуска.
+MUST завести свою схему и принимать записи своим входом — приёмом по HTTP — без
+единого ручного шага до первого запуска.
 
 Прежние данные не переносятся. Каталог, оставшийся от прежней раскладки, MUST не
 читаться и не считаться источником: сервис начинает с чистого листа, и это
@@ -267,14 +267,14 @@ MUST завести свою схему и принимать записи об
 печатается оно в журнал контейнера, откуда строку не убрать: бессрочное отдало бы
 панель всякому читателю логов навсегда.
 
-Пока владелец пароля не задал, сервис MUST работать обоими входами: панель без
-владельца не мешает принимать записи.
+Пока владелец пароля не задал, сервис MUST принимать записи: панель без владельца
+приёму не мешает.
 
 #### Scenario: Владелец пароля ещё не задал
 
 - **GIVEN** каталог данных пуст и владелец панели не заведён
 - **WHEN** сервис запускается
-- **THEN** он принимает записи обоими входами
+- **THEN** он принимает записи
 - **AND** ни один ключ конфигурации не несёт пароля от панели
 
 #### Scenario: Владелец заведён, приглашение больше не печатается
@@ -289,10 +289,13 @@ MUST завести свою схему и принимать записи об
 учётной записью, — и эта колонка MUST не иметь умолчания: запись, чей владелец
 не назван, не достаётся никому по недосмотру схемы.
 
-Колонка MUST допускать пустое значение, и это решение с названной ценой: записи,
-принятые ботом, владельца не имеют, потому что связи чата Telegram с учётной
-записью сервис не ведёт. Обязательность для приёма по HTTP держит сама
-capability `intake`, а не схема.
+Колонка MUST не допускать пустого значения. Прежде допускала, и цену платили за
+записи, принятые ботом: связи чата с учётной записью сервис не вёл. С убранным
+входом заводить ничью запись стало некому, и обязательность переезжает из одного
+лишь приёма в схему — туда, где её держит хранилище, а не договорённость. Разница
+не косметическая: пока обязательность жила в приёме, ничью запись заводили руками
+в панели, и она уходила в конвейер, стоила денег на распознавание и не доставалась
+потом никому.
 
 Владелец MUST не назначаться и не меняться конвейером.
 
@@ -301,6 +304,14 @@ capability `intake`, а не схема.
 - **WHEN** сервис поднимается на чистом каталоге данных
 - **THEN** у аудиозаписи есть колонка владельца
 - **AND** умолчания у неё нет
+- **AND** пустого значения она не принимает
+
+#### Scenario: Запись без владельца не сохраняется
+
+- **GIVEN** сервис поднят
+- **WHEN** аудиозапись пытаются сохранить с пустым владельцем — приёмом,
+  конвейером или руками в панели
+- **THEN** хранилище её не сохраняет
 
 #### Scenario: Конвейер владельца не назначает
 
@@ -313,9 +324,16 @@ capability `intake`, а не схема.
 Хранилище SHALL держать владельца и у файла записи — той же связью с учётной
 записью, — и правило просмотра файлов MUST пускать к файлу только его владельца.
 
-Владелец файла MUST назначаться там же, где владелец записи, — при приёме, из
-предъявленной сессии, — и MUST оставаться пустым у файлов, заведённых конвейером
-для записи без владельца.
+Владелец файла MUST назначаться при приёме, из предъявленной сессии, а колонка
+файла MUST не допускать пустого значения наравне с колонкой записи. Прежде пустое
+значение оставалось у файлов, заведённых конвейером для записи без владельца;
+таких записей больше не заводится, и разное правило у записи и у её файла
+читалось бы как недосмотр.
+
+Файл, заведённый шагом конвейера, — приведённую копию заводит именно он —
+MUST получать владельца своей записи. Иного источника владельца у файла нет, и
+шаг, оставивший его пустым, упрётся в отказ сохранения: запись накопит отказы и
+остановится признаком на первом же приведении.
 
 Ссылки на файлы у записи две — на принятую копию и на приведённую, — и обе живут
 до конца, но владелец файла MUST по-прежнему лежать своей колонкой, а не
@@ -340,12 +358,18 @@ capability `intake`, а не схема.
 - **WHEN** он идёт по ссылке на файл своей записи со своим токеном
 - **THEN** содержимое отдаётся
 
-#### Scenario: Файл записи из Telegram не отдаётся по API
+#### Scenario: Файл без владельца не сохраняется
 
-- **GIVEN** запись принята ботом, и владельца у неё нет
-- **WHEN** вошедший человек идёт по ссылке на её файл со своим токеном
-- **THEN** содержимого он не получает
+- **GIVEN** сервис поднят
+- **WHEN** файл записи пытаются сохранить с пустым владельцем
+- **THEN** хранилище его не сохраняет
 
+#### Scenario: Приведённая копия получает владельца записи
+
+- **GIVEN** запись с владельцем дошла до приведения
+- **WHEN** шаг заводит приведённую копию файла
+- **THEN** владельцем копии стоит владелец записи
+- **AND** шаг завершается без отказа
 ### Requirement: Учётная запись с записями не удаляется
 
 Хранилище SHALL отвергать удаление учётной записи, у которой остались
@@ -551,3 +575,31 @@ MUST быть помечено защищённым.
 - **WHEN** записи назначают шестую тему
 - **THEN** назначение не проходит
 
+### Requirement: Пустой результат не кладётся поверх сохранённого
+
+Хранилище SHALL не заменять сохранённое содержимое приложения записи — текст и
+структуру реплик — пустым. Замена пустым MUST оставлять прежнее значение и
+считаться сделанной работой, а не отказом.
+
+Требование стоит на повторном опросе одной и той же операции распознавания.
+Повтор — обычное дело: держатель захвата умер, сохранение рубежа отказало,
+человек снял признак остановки в панели. Провайдер при этом вправе ответить
+пустым потоком, отказом это не считается, и безусловная замена стирала бы
+расшифровку живого человека — без следа и без возврата, потому что сервис
+объявлен архивом и удаления по требованию не знает.
+
+Та же защита MUST стоять у сырого ответа провайдера: разное правило у двух
+хранителей одного результата читается как недосмотр, и один из них молча теряет
+то, ради чего второй заведён.
+
+Норма записана со стороны **хранилища**, а не шага: шагов, кладущих текст,
+больше одного, и правило, записанное у одного из них, у остальных читалось бы
+как снятое.
+
+#### Scenario: Пустой второй ответ не стирает расшифровку
+
+- **GIVEN** расшифровка записи сохранена
+- **WHEN** ту же операцию опрашивают снова, и провайдер отвечает пустым
+- **THEN** сохранённая расшифровка остаётся прежней
+- **AND** шаг завершается без отказа
+