transcriber/openspec/changes/archive/2026-08-14-record-ownership/design.md

Context

Сессия сегодня отвечает на один вопрос — узнан ли пришедший. На вопрос «чьё он смотрит» не отвечает никто: опрос готовности отдаёт задачу всякому вошедшему по её идентификатору. Так записано и в спеках прямым текстом — обе строки (access, преамбула; intake, «Опрос готовности задачи») обещают, что сужение придёт отдельной задачей. Эта задача та самая.

Учётные записи в сервисе уже есть: их заводит вход через внешнего провайдера, заведённый 2026-08-12. Значит владельцем записи есть кому быть.

Ограничения, из которых собрано решение:

• Данные не переносим — рамки задачи объявляют чистый лист. Значит шагу схемы не нужно ни умолчание для старых записей, ни правило их раздачи.
• Применённый шаг схемы не переписывается (инвариант, critical). Колонка приезжает новым шагом.
• Колонки очереди правятся в четырёх местах пакета хранилища (инвариант, major), и компилятор видит два из них.
• Записи из Telegram владельца получить не могут: связи чата с учётной записью не существует, её заводит telegram-account-link следующей задачей.

Goals / Non-Goals

Goals:

• у задачи расшифровки есть владелец, назначенный при приёме и неизменяемый;
• чужая задача по её идентификатору неотличима от несуществующей;
• конвейер работает по всем записям подряд, владельцем не сужаясь;
• колонка владельца не имеет умолчания: запись не достаётся никому по недосмотру.

Non-Goals:

• совместный доступ, роли, передача записи другому;
• перенос записей, заведённых до этого шага;
• владелец у записи, пришедшей ботом, — его назначает следующая задача;
• список своих записей и удаление: они стоят на владельце, но заводятся своими задачами.

Decisions

Сужение живёт в хранилище, а не в обработчике

Читающий метод репозитория задач принимает владельца и отдаёт задачу, только если она его. Не «прочитать и сравнить в обработчике»: сравнение, стоящее в вызывающем, повторяется в каждом новом вызывающем, и первый же забывший его открывает чужую запись. Компилятор при смене подписи метода приводит всех вызывающих сам.

Отвергнуто: правило доступа коллекции хранилища. Коллекции хранилища знают правила вида «владелец записи равен предъявителю», и в панели они работают. Наш опрос готовности идёт мимо коллекций — своим обработчиком и своим запросом, — и правило коллекции на этом пути не срабатывает вовсе. Опереться на него значит получить защиту, которой не существует, и не заметить этого: тест, ходящий нашим API, был бы зелёным в обоих случаях.

Отвергнуто: второй метод чтения рядом с прежним (GetByID и GetOwnedByID). Это второй способ делать одно и то же, и выбирается он по внимательности вызывающего. Метод остаётся один, и владелец у него обязателен.

Чужая запись отвечает «не найдено», а не «доступ запрещён»

Отказ по чужой записи и отказ по несуществующей — один и тот же ответ, 404 с тем же телом. Отдельный код на чужую запись превращает опрос в перебор: по нему считывается, какие идентификаторы заведены, а идентификатор задачи и есть то, что мы прячем.

Различать их в журнале при этом можно и нужно — журнал читает владелец сервиса, а не тот, кто перебирает.

Владелец — связь на учётную запись, а не строка

Колонка заводится связью с коллекцией пользователей: хранилище само следит за тем, чтобы владельцем стояла существующая учётная запись, а не строка, похожая на её идентификатор.

Целостности при удалении учётной записи связь при этом не удерживает, и прежнее обоснование этого решения было неверным. Проверено по исходникам pocketbase@v0.39.10, core/record_model.go, deleteRefRecords: при выключенном каскадном удалении хранилище вынимает идентификатор из поля связи и сохраняет запись без проверок. То есть удаление учётной записи не уносит её задачи — но делает их ничьими, а по правилу этой же задачи ничья запись не достаётся по API никому. Архив человека становится недостижим молча, и восстановить владельца нечем.

Строка с идентификатором вела бы себя здесь лучше — она пережила бы удаление, — но платила бы тем, что владельцем становится любое значение. Что делать с этим, решает человек на чекпоинте: развилка вынесена в открытые вопросы.

Захват читает колонку владельца

Владелец добавляется во все четыре места правки колонок очереди, включая acquireColumns и acquiredRow, хотя конвейер владельцем не пользуется.

Причина в инварианте: колонка, забытая в этой паре, приезжает из захвата нулевой. Сохранение конвейера сегодня кладёт только свои поля и владельца не трогает — значит потери нет; но снимок задачи, в котором владелец всегда пуст, это ловушка для первого же шага, который начнёт сохранять задачу целиком. Чтение колонки стоит одной строки в каждом из четырёх мест и снимает ловушку насовсем.

Приём назначает владельца из предъявленной сессии

Приём по HTTP уже требует сессию и отказывает 401 без неё. Владелец берётся оттуда же, и другого источника у него нет: параметром запроса владелец не задаётся никогда, иначе всякий вошедший заводит запись на чужое имя.

Risks / Trade-offs

• Колонка обязательна в схеме → приём из Telegram перестаёт вставлять записи. Критерий приёмки требует обязательности, рамки запрещают назначать владельца записям бота, и вместе это ломает основной сегодня вход. → Развилка вынесена в открытые вопросы и на чекпоинт; ниже разобраны три способа с ценой каждого.
• Записи бота остаются без владельца и потому невидимы в API. Это желаемое поведение (ответ бот отдаёт сам, в чат), но оно значит, что после telegram-account-link записи придётся связать с учётной записью задним числом — а рамки объявляют владельца неизменяемым. → Граница названа здесь и передаётся той задаче: неизменяемость относится к записи, у которой владелец есть.
• Тест на две сессии дороже прежних. Нужны две учётные записи в тестовой базе и две куки. → Заводятся тем же способом, что и в тестах входа.
• Публичный контракт меняется: GET /api/status/{id} на чужую задачу отвечает 404 там, где отдавал содержимое. → Ломка намеренная и объявлена в предложении; форма ответа при этом не трогается.

Migration Plan

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

Отката приложения нет — решение владельца от 2026-08-14. Прежний образ поверх новой схемы поднялся бы: колонку он не читает, и она ему не мешает. Но и не пишет — записи, принятые по HTTP в таком окне, остались бы без владельца и после возврата вперёд не достались бы создателю уже никогда, молча. Способ выхода из беды поэтому другой: восстановить базу из резервной копии либо выпустить новый релиз вперёд.

Open Questions

Обязательна ли колонка владельца в схеме? Решает человек на чекпоинте. Критерий приёмки задачи требует «обязательна и без умолчания», рамки той же задачи запрещают назначать владельца записям бота. Три способа:

1. Колонка не обязательна в схеме, обязательность держит приём по HTTP. Запись из веба без владельца завести нельзя — отказывает приём; запись бота лежит без владельца и по API невидима никому. Цена: «обязательна» держит код, а не схема, и прямое обращение к базе мимо приёма может завести запись без владельца. Критерий приёмки выполняется наполовину и требует переформулировки. Рекомендую этот.
2. Колонка обязательна, записи бота получают служебную учётную запись. Схема держит обязательность целиком. Цена втрое больше, чем казалось: учётная запись, за которой не стоит человек, делает сервис источником учётных записей — а паспорт объявляет управление ими вне цели; завести её штатным путём нельзя вовсе, потому что создание записи разрешено только контексту обмена OIDC, и понадобится ещё один шаг схемы; после telegram-account-link записи придётся переназначать, нарушая неизменяемость владельца в первой же следующей задаче. Способ рекомендую снять с выбора.
3. Колонка обязательна, связь чата с учётной записью делается здесь же. Критерий выполняется буквально. Цена: задача вбирает в себя следующую и вырастает примерно вдвое — а telegram-account-link заведена отдельной строкой беклога намеренно.

Сужается ли по владельцу сам файл записи? Нашли независимо все три прохода ревью дизайна, и это крупнее прочего. Разграничение, спроектированное выше, закрывает опрос состояния — то есть метаданные задачи, — а само аудио лежит в другой коллекции, у которой владельца нет и по этому плану не появится. Правило просмотра там пускает всякого вошедшего, и знание идентификатора файловой записи по-прежнему равно праву скачать чужую запись. Запись задачи между тем называет затронутой «таблицу задач и таблицу файлов», а модель угроз обещает владельца у задачи и файла именно этой задачей.

Дороже всего не сама дыра, а отметка о закрытии: после мерджа паспорт и модель угроз перепишут разграничение как сделанное, и открытый путь перестанет быть виден. Способы:

1. Владелец и у файла, тем же шагом схемы, правило просмотра сужается им. Задача растёт на колонку, правило и свой тест. Полное закрытие.
2. Обратная ссылка с файла на задачу, владелец выводится через неё. Дешевле в схеме, дороже в правиле; вдобавок ссылка на файл в задаче переставляется каждым шагом конвейера, и исходная копия после конвертации не связана ни с чем.
3. Оставить как есть и записать границу честно — строкой Non-Goals с адресом задачи-преемника, и не переписывать паспорт с моделью угроз словом «закрыто». Дешевле всего сегодня, но разграничение остаётся половинчатым.

Что делать с записями удалённого пользователя? Связь при выключенном каскаде снимает ссылку — записи остаются, но становятся ничьими и недостижимыми по API навсегда. Способы: запретить удаление учётной записи, пока у неё есть записи; держать рядом со связью неизменяемый снимок идентификатора; признать потерю ценой и записать её. Сегодня удаления пользователей в сервисе нет вовсе, так что третий способ ничего не ломает сейчас — но он же превращает архив в то, что теряется одной кнопкой в панели.

Подтверждение ломки публичного контракта. GET /api/status/{id} на чужую задачу начнёт отвечать 404 там, где отдавал содержимое. Проект относит публичный контракт HTTP API к необратимому и требует спрашивать человека всегда — здесь и спрашивается.