# 🔬 Сверка файла с записью при отдаче

- **Тип:** research
- **Категория:** Очередь — Ответ нужен до удаления записи и до нарезки на фрагменты: обе задачи правят обе стороны связи файла с записью
- **Зачем:** Владение судится у записи, а файл открывается по её ссылке без сверки files.record_id и files.owner_id; схема этой связи не держит, и обе стороны будут править delete-record и long-audio-chunking.
- **Теги:** review-2026-08-23

Владение судится у записи: обработчик находит запись по идентификатору, сверяет
владельца и открывает файл по ссылке из этой записи. Сверки `files.record_id` и
`files.owner_id` при этом нет, и схема такой связи не держит намеренно.

Пути наружу сегодня нет — ссылку в запись кладёт только сервис, — и потому это
разведка, а не починка. Но обе стороны связи будут править `delete-record` и
`long-audio-chunking`: первая убирает файлы вместе с записью, вторая заводит у
одной записи несколько копий. Сверять надо при первой же правке файлов, пока
сторон две, а не десять.

Гипотеза прохода `review-adversary` (V5) ревью change
`2026-08-23-storage-without-pocketbase`, понижённая триажем: свойство без
построенного пути.

## Вопрос

Чем держится принадлежность файла записи — сверкой при отдаче, связью в схеме
или тем и другим, — и что из этого стоит завести до того, как у записи станет
несколько копий?

## Куда ляжет ответ

Записка `docs/research/`, а нормативная половина — в спеку `storage`
требованием. Из ответа выходят рамки для `delete-record` и
`long-audio-chunking`: обе правят обе стороны связи.

## Рамки

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