# Proposal

## Why

Отредактированная версия фото задумана принадлежащей только тому фото, чьи правки её
породили: воркер создаёт edit-объекты с владельцем `[]string{photoID}` и комментирует
это прямо. Но копирование фото (`Clone`) переносит **все** привязки `photo_objects`,
включая роли `edit`, `edit_thumb`, `edit_medium`, `edit_preview`. Копия фото, сделанная
после рендера правок, поэтому показывает отредактированную картинку, но не наследует
`edit_params`: в панели правок у копии параметров нет, и первая же новая правка
перезаписывает исходную обработку с нуля. Поведение расходится с замыслом и с
описанием в спеке.

## What Changes

- Копирование фото перестаёт переносить отредактированную версию: в копию
  попадают только обычные роли (`original`, `thumb`, `medium`, `preview`, `playback`).
- Копия фото с правками показывается в исходном виде, параметры правок копии
  остаются пустыми — как и сейчас.
- Обычные варианты по-прежнему разделяются между копиями одного оригинала: правка
  принадлежит фото, а не объекту.
- Спека `media-objects` приводится к этому правилу: уточняется, кому принадлежит
  отредактированная версия и что происходит при копировании.

## Capabilities

### New Capabilities

Нет.

### Modified Capabilities

- `media-objects`: копирование фото не переносит отредактированную версию на копию;
  отредактированная версия остаётся привязанной только к фото, чьи правки её создали.

## Impact

- `backend/internal/photos/store.go` — `Store.Clone` (Postgres): при копировании
  `photo_objects` исключаются роли `edit*`.
- `backend/internal/photos/sqlite_store.go` — `SQLiteStore.Clone` (SQLite): то же
  поведение.
- `backend/internal/photos/edit_render.go` — константы ролей `edit*` используются как
  список исключений (без дублирования строк в двух хранилищах).
- `backend/internal/photos/copy_test.go` — тест на копию фото с отрендеренной
  отредактированной версией.
- Схема БД, HTTP API и клиенты не меняются; миграций нет.