у записи появился владелец: чужую больше не отдают

- колонка `owner` связью с `users` в обеих коллекциях новым шагом схемы
  `202608140001`; чтение задачи сужено владельцем, и чужая, ничья и
  несуществующая дают один ответ; правило просмотра файлов сужено им же
- приём по HTTP берёт владельца из сессии, а предъявителя без учётной записи
  пользователя отвергает до чтения тела: позже пришлось бы убирать уложенный
  файл, а уборки файлов сервис не умеет. Выборка воркера владельцем не сужается
- удаление учётной записи с записями отвергается стражем, и вешает его сама
  сборка хранилища: сборка, забывшая его позвать, теряла защиту молча

openspec/specs/access/spec.md

@@ -6,15 +6,17 @@
 OIDC, чем предъявляется сессия, что её прекращает и какие адреса остаются
 открытыми.
 
-Разграничения записей по владельцу здесь **нет**: всякий вошедший видит ровно
-то же, что видел прежде аноним. Его заводит отдельная задача, и до неё сессия
-отвечает только на вопрос «узнан ли пришедший», а не «чьё он смотрит».
+Здесь же разграничение записей по владельцу: с 2026-08-14 сессия отвечает не
+только на вопрос «узнан ли пришедший», но и на «чьё он смотрит». Запись из веба
+принадлежит тому, кто её принёс, и чужая неотличима от несуществующей.
+
+Записи, принятые ботом, владельца не имеют вовсе и по API не достаются никому:
+связи чата Telegram с учётной записью приложения сервис не ведёт, её заводит
+отдельная задача.
 
 Вход из Telegram эта capability не нормирует: бот проверяет отправителя своим
 белым списком, и с учётной записью приложения тот список не связан.
-
 ## Requirements
-
 ### Requirement: Вход через внешнего провайдера
 
 Сервис SHALL заводить сессию только по итогу входа у внешнего провайдера OIDC.
@@ -345,3 +347,64 @@ MUST не делать. Кто допущен, определяет правил
 - **WHEN** сервис поднимается с пустым или негодным ключом секции входа
 - **THEN** старт кончается отказом, а отказ называет имена ключей
 - **AND** значений этих ключей в отказе нет
+
+### Requirement: У записи есть владелец, и чужую ей не отдают
+
+Сервис SHALL заводить у каждой записи, принятой **по HTTP**, — владельца, то
+есть учётную запись, от имени которой запись принята, — и MUST отдавать данные
+такой записи только её владельцу. Владелец назначается один раз, при приёме, и
+MUST не меняться у записи, у которой владелец есть: совместного доступа, ролей и
+передачи записи другому сервис не знает. Оговорка не случайна — назначить
+владельца записи, у которой его нет, вправе задача, заводящая связь чата
+Telegram с учётной записью.
+
+Владелец MUST браться из предъявленной сессии и ниоткуда больше. Владелец,
+пришедший полем запроса, дал бы всякому вошедшему право завести запись на чужое
+имя.
+
+Обращение к чужой записи MUST быть неотличимо от обращения к несуществующей.
+Отдельный отказ «доступ запрещён» превращает опрос в перебор — по разнице
+ответов считывается, какие записи заведены, а идентификатор записи и есть то,
+что разграничение прячет. Каким именно ответом это выражено, нормирует
+capability `intake`: там живёт адрес опроса, и держатель нормы обязан быть один.
+
+Пустой владелец MUST не совпадать ни с одной записью — ни со своей, ни с чужой,
+ни с ничьей. Правило записано со стороны **спрашивающего**, а не со стороны
+записи: обязательность владельца, которую держит одна лишь подпись метода, пустую
+строку пропускает, и первый же вызывающий без учётной записи получил бы ровно
+множество записей без владельца, то есть все записи бота.
+
+Записи, принятые из Telegram, владельца не имеют: связи чата с учётной записью
+приложения сервис не ведёт. Такая запись MUST не доставаться по API никому —
+ответ на неё тот же, что и на несуществующую, — а её расшифровка уезжает
+отправителю в чат, как и прежде.
+
+#### Scenario: Своя запись доступна
+
+- **GIVEN** человек вошёл и принял запись
+- **WHEN** он спрашивает состояние этой записи своей сессией
+- **THEN** ответ несёт состояние записи
+
+#### Scenario: Чужая запись неотличима от несуществующей
+
+- **GIVEN** запись принята одним вошедшим
+- **WHEN** её состояние спрашивает другой вошедший
+- **THEN** ответ тот же, что и на неизвестный идентификатор, — и кодом, и телом
+
+#### Scenario: Владельца не задают запросом
+
+- **WHEN** запрос на приём записи несёт своё значение владельца
+- **THEN** владельцем принятой записи становится предъявитель сессии
+
+#### Scenario: Запись из Telegram не достаётся по API
+
+- **GIVEN** запись принята ботом
+- **WHEN** её состояние спрашивает вошедший человек
+- **THEN** ответ тот же, что и на неизвестный идентификатор
+
+#### Scenario: Пустой владелец не открывает ничего
+
+- **GIVEN** заведены три задачи: своя, чужая и принятая ботом
+- **WHEN** состояние каждой спрашивают с пустым владельцем
+- **THEN** ответ на все три тот же, что и на неизвестный идентификатор
+

openspec/specs/intake/spec.md

@@ -36,8 +36,24 @@ Telegram, дописывает его сюда.
 Куда именно ложится принятая запись, приёму не принадлежит: раскладку выбирает
 хранилище, и нормирует её capability `storage`.
 
-Владельца у принятой записи приём не заводит: после входа видно ровно то же, что
-видно было анонимно.
+Владельцем принятой записи приём SHALL назначать предъявителя сессии. Проверка
+стоит здесь, а не только в схеме хранилища: колонка владельца допускает пустое
+значение ради записей из Telegram, и приём по HTTP — то место, где
+обязательность держится.
+
+Предъявитель, чья сессия не даёт учётной записи пользователя, MUST получать
+отказ `403` и MUST получать его **до чтения тела** — там же, где стоит отказ по
+отсутствию сессии. Сессия владельца панели — именно такой случай: узнан он всё
+же узнан, а записи в коллекции пользователей у него нет, и владельцем записи он
+стать не может.
+
+Код здесь другой, чем у запроса без сессии, и это не оплошность: `401` значит
+«предъяви себя», а предъявитель себя предъявил. Утечки по разнице кодов нет —
+оба ответа говорят о самом спрашивающем, а не о том, какие записи заведены.
+
+Отказ **после** укладки записи потребовал бы убрать уже сохранённый файл, а
+уборки файлов сервис не умеет вовсе: норма, обязывающая к недостижимому, не
+пишется.
 
 #### Scenario: Запись принята
 
@@ -47,6 +63,14 @@ Telegram, дописывает его сюда.
 - **THEN** ответ имеет код `201`, а в теле лежат непустой `job_id` и `status`
   со значением `created`
 - **AND** содержимое записи целиком лежит в хранилище одним файлом
+- **AND** владельцем заведённой задачи стоит предъявитель сессии
+
+#### Scenario: Сессия не даёт учётной записи пользователя
+
+- **GIVEN** предъявлена сессия владельца панели
+- **WHEN** он шлёт `POST /api/audio` с полем `audio`
+- **THEN** ответ имеет код `403`
+- **AND** ни файла, ни задачи не заводится
 
 #### Scenario: Сессии нет
 
@@ -214,24 +238,24 @@ Telegram, дописывает его сюда.
 ### Requirement: Опрос готовности задачи
 
 Сервис SHALL отдавать состояние задачи расшифровки по запросу
-`GET /api/status/:id` **только узнанному отправителю**. Запрос без сессии MUST
-получать код `401`, и тело такого ответа MUST не нести ни состояния задачи, ни
-текста расшифровки. Ответ узнанному отправителю MUST нести идентификатор полем
-`job_id`, состояние полем `status` и время заведения полем `created_at`, а текст
-расшифровки полем `transcription_text`, и это поле MUST отсутствовать в ответе,
-пока текста нет: пустая строка на месте отсутствующего текста читается как
-«расшифровка пуста».
+`GET /api/status/:id` **только её владельцу**. Запрос без сессии MUST получать
+код `401`, и тело такого ответа MUST не нести ни состояния задачи, ни текста
+расшифровки. Ответ владельцу MUST нести идентификатор полем `job_id`, состояние
+полем `status` и время заведения полем `created_at`, а текст расшифровки полем
+`transcription_text`, и это поле MUST отсутствовать в ответе, пока текста нет:
+пустая строка на месте отсутствующего текста читается как «расшифровка пуста».
 
 Отказ без сессии MUST не зависеть от того, есть такая задача или нет: иначе по
 кодам ответа перебирается список заведённых задач.
 
-Выборку по владельцу опрос не сужает: узнанный отправитель видит любую задачу по
-её идентификатору ровно как прежде. Сужение придёт отдельной задачей.
+Задача, принадлежащая другому, MUST отвечать тем же, чем отвечает неизвестный
+идентификатор, — кодом `404` и тем же телом. То же MUST относиться к задаче без
+владельца: запись, принятая ботом, по этому адресу не достаётся никому.
 
 #### Scenario: Задача найдена
 
 - **GIVEN** отправитель предъявил сессию
-- **WHEN** программа спрашивает состояние заведённой задачи
+- **WHEN** он спрашивает состояние своей задачи
 - **THEN** ответ имеет код `200` и несёт `job_id`, `status` и `created_at`
 
 #### Scenario: Сессии нет
@@ -246,10 +270,18 @@ Telegram, дописывает его сюда.
   состояние по неизвестному идентификатору
 - **THEN** оба ответа имеют код `401`
 
+#### Scenario: Чужая задача неотличима от неизвестной
+
+- **GIVEN** задача заведена одним вошедшим
+- **WHEN** её состояние спрашивает другой вошедший
+- **THEN** ответ имеет код `404` и то же тело, что и ответ по неизвестному
+  идентификатору
+- **AND** тело ответа не несёт ни состояния задачи, ни текста расшифровки
+
 #### Scenario: Расшифровки ещё нет
 
 - **GIVEN** отправитель предъявил сессию
-- **WHEN** программа спрашивает состояние задачи, которая ещё не дошла до текста
+- **WHEN** он спрашивает состояние своей задачи, которая ещё не дошла до текста
 - **THEN** поля `transcription_text` в ответе нет вовсе
 
 #### Scenario: Задачи с таким идентификатором нет

openspec/specs/pipeline/spec.md

@@ -15,7 +15,6 @@ done | failed`, отмена контекста посреди шага и ос
 требования на него не написаны, потому что требование без проверки —
 предположение, а не норма. Первая задача, которая трогает любое из
 перечисленного, дописывает его сюда.
-
 ## Requirements
 ### Requirement: Пустой прогон воркера — не отказ
 
@@ -325,3 +324,35 @@ MUST расти с числом её попыток до объявленног
 - **GIVEN** задача принята по HTTP
 - **WHEN** шаг конвейера доходит до ответа отправителю
 - **THEN** шаг завершается без отказа и без записи о недоставке
+
+### Requirement: Выборка воркера владельцем не сужается
+
+Воркер SHALL брать задачи всех владельцев подряд и MUST не учитывать владельца
+при выборе очередной задачи. Задача без владельца — принятая ботом — MUST
+обрабатываться наравне с прочими.
+
+Владелец решает, кому запись показывать, а не кому её считать. Сужение выборки
+владельцем остановило бы расшифровку записей бота вовсе, а записи остальных
+поставило бы в зависимость от того, кто первым завёл учётную запись.
+
+Владелец задачи MUST переживать работу конвейера: шаг, сохраняющий свой
+результат, владельца не трогает и не затирает.
+
+#### Scenario: Задачи двух владельцев проходят одним воркером
+
+- **GIVEN** заведены задачи двух разных владельцев в одном состоянии
+- **WHEN** воркер забирает задачи этого состояния
+- **THEN** ему достаются обе, в порядке заведения
+
+#### Scenario: Задача без владельца обрабатывается
+
+- **GIVEN** заведена задача, принятая ботом, — без владельца
+- **WHEN** воркер забирает задачи её состояния
+- **THEN** она достаётся ему наравне с прочими
+
+#### Scenario: Шаг конвейера владельца не затирает
+
+- **GIVEN** задача с владельцем прошла шаг конвейера
+- **WHEN** шаг сохраняет свой результат
+- **THEN** владелец задачи остаётся прежним
+

openspec/specs/storage/spec.md

@@ -10,7 +10,6 @@
 Сознательно не описаны: перенос прежних данных — его нет по решению задачи
 `pocketbase-storage`; удаление записей и файлов — сервис объявлен архивом
 2026-08-11, а удаление приносит задача `delete-record`.
-
 ## Requirements
 ### Requirement: Сервис поднимается на чистом каталоге данных
 
@@ -106,9 +105,14 @@ MUST завести свою схему и принимать записи об
 
 Одной пометки мало: защищённый файл судится **коротким токеном файла**, который
 узнанный отправитель берёт у хранилища, предъявив сессию, — и правилом просмотра
-коллекции. Правило MUST пускать всякого узнанного: незаданное означает «только
-владелец панели», и тогда файла не получит и вошедший. Сужения по владельцу
-здесь нет — его заводит отдельная задача.
+коллекции. Правило MUST пускать только владельца файла: незаданное означает
+«только владелец панели», и тогда файла не получит и вошедший, а прежнее «всякий
+узнанный» отдавало чужое аудио тому, кто знает идентификатор записи.
+
+Токен файла хранилище выдаёт **на предъявителя**, а не на файл, и о файле при
+выдаче не спрашивает. Значит владельца судит переход по ссылке, а не выдача
+токена: отказ наступает там, и требовать его от выдачи значит требовать
+механизма, которого нет.
 
 Отсюда порядок для потребителя: сессия → токен файла → ссылка с этим токеном.
 Браузер с одной лишь кукой файла не получит, и это свойство хранилища, а не
@@ -272,3 +276,118 @@ MUST завести свою схему и принимать записи об
 - **WHEN** сервис запускается снова
 - **THEN** приглашения завести владельца в журнале нет
 
+### Requirement: Владелец задачи лежит связью с учётной записью
+
+Хранилище SHALL держать владельца задачи расшифровки отдельной колонкой — связью
+с учётной записью, — и эта колонка MUST не иметь умолчания: запись, чей владелец
+не назван, не достаётся никому по недосмотру схемы.
+
+Колонка MUST допускать пустое значение, и это решение с названной ценой: записи,
+принятые ботом, владельца не имеют, потому что связи чата Telegram с учётной
+записью сервис не ведёт. Обязательность для приёма по HTTP держит сама
+capability `intake`, а не схема.
+
+Колонка приезжает **новым шагом схемы**: применённый шаг не переписывается.
+Записей, заведённых до этого шага, сервис не переносит — проект заводится с
+чистого листа.
+
+#### Scenario: Колонка появляется на пустой базе
+
+- **WHEN** сервис поднимается на чистом каталоге данных
+- **THEN** у таблицы задач есть колонка владельца
+- **AND** умолчания у неё нет
+
+### Requirement: Файл записи сужается владельцем наравне с задачей
+
+Хранилище SHALL держать владельца и у файла записи — той же связью с учётной
+записью, тем же шагом схемы, — и правило просмотра файлов MUST пускать к файлу
+только его владельца. Прежнее правило пускало всякого узнанного, и знание
+идентификатора файловой записи равнялось праву скачать чужое аудио.
+
+Без этого требования разграничение закрывает метаданные задачи и оставляет
+открытым содержимое — то самое, что оно и заведено прятать. Хуже самой дыры была
+бы отметка о закрытии: паспорт и модель угроз называют исполнителем этой работы
+именно эту задачу, и слово «закрыто» скрыло бы открытый путь.
+
+Владелец файла MUST назначаться там же, где владелец задачи, — при приёме, из
+предъявленной сессии, — и MUST оставаться пустым у файлов, заведённых конвейером
+для записи без владельца.
+
+Ссылка на файл в задаче переставляется каждым шагом конвейера, поэтому владелец
+файла MUST лежать своей колонкой, а не выводиться через задачу: исходная копия
+после конвертации не связана с задачей ничем.
+
+Отказ наступает **на переходе по ссылке**, а не на выдаче токена файла: токен
+хранилище выдаёт на предъявителя, а не на файл, и о файле при выдаче не
+спрашивает вовсе. Требовать отказа при выдаче значит требовать механизма,
+которого нет, — а проверка, написанная под такое требование, зеленела бы, не
+касаясь пути, по которому аудио и уходит.
+
+#### Scenario: Чужой файл не отдаётся
+
+- **GIVEN** запись принята одним вошедшим
+- **WHEN** другой вошедший идёт по ссылке на файл этой записи со своим токеном
+- **THEN** содержимого он не получает
+
+#### Scenario: Свой файл отдаётся
+
+- **GIVEN** человек принял запись
+- **WHEN** он идёт по ссылке на файл своей записи со своим токеном
+- **THEN** содержимое отдаётся
+
+#### Scenario: Файл записи из Telegram не отдаётся по API
+
+- **GIVEN** запись принята ботом, и владельца у неё нет
+- **WHEN** вошедший человек идёт по ссылке на её файл со своим токеном
+- **THEN** содержимого он не получает
+
+### Requirement: Учётная запись с записями не удаляется
+
+Хранилище SHALL отвергать удаление учётной записи, у которой остались задачи
+расшифровки **либо файлы**. Отказ MUST называть причину, и MUST доезжать до
+спрашивающего: хранилище пропускает наружу только свою ошибку роутера, а всякую
+другую подменяет сообщением про обязательную связь — подсказкой, по которой
+владелец панели пойдёт удалять записи руками.
+
+Считаются обе коллекции с владельцем. Файл переживает свою задачу: шаг конвейера
+заводит его до сохранения задачи, и потерянный захват оставляет файл с владельцем
+и без ссылки.
+
+Запрет MUST ставить сама сборка хранилища, а не вызывающий: сборка, забывшая его
+позвать, теряет защиту молча — и теряла, пока запрет вешался отдельной строкой
+запуска, а окружение проверок его не ставило вовсе.
+
+Удаление при этом не только панельное: умолчание библиотеки разрешает вошедшему
+удалить **свою** учётную запись запросом, так что запрет закрывает и публичную
+поверхность.
+
+Требование заведено вместо прежнего «удаление не уносит задачи следом»: оно
+выглядело выполненным, а на деле хранилище при выключенном каскаде **снимает
+ссылку** — задачи остаются, но становятся ничьими, а ничья задача не достаётся
+по API никому. Архив человека исчезал бы молча и восстановлению не подлежал:
+прежнего владельца не остаётся нигде.
+
+Цена требования названа прямо: владелец панели упирается в отказ, а способа
+удалить записи в сервисе пока нет вовсе — его приносит задача про удаление
+записи. До неё удаление учётной записи с записями невозможно, и это осознанный
+тупик, а не недосмотр.
+
+#### Scenario: Удаление учётной записи с записями отвергается
+
+- **GIVEN** у учётной записи есть задачи расшифровки
+- **WHEN** её удаляют
+- **THEN** удаление не проходит, а отказ называет причину
+- **AND** задачи и их владелец остаются прежними
+
+#### Scenario: Учётная запись с одними файлами тоже не удаляется
+
+- **GIVEN** у учётной записи остались файлы, но задач нет
+- **WHEN** её удаляют
+- **THEN** удаление не проходит, а владелец файлов остаётся прежним
+
+#### Scenario: Учётная запись без записей удаляется
+
+- **GIVEN** у учётной записи нет ни задач, ни файлов
+- **WHEN** её удаляют
+- **THEN** удаление проходит
+