transcriber/tasks/items/settings-screen.md

✨ Сделать экран настроек и хранить настройки по пользователю

• Тип: feature
• Категория: Очередь — Дом настроек нужен раньше уровней текста и раньше выбора канала уведомлений.
• Зачем: Настроек у пользователя нет вовсе: уровни текста и канал уведомлений задаются общим конфигом сервиса.

У каждого пользователя свои переключатели уровней текста и свой канал уведомлений, и они переживают повторный вход.

Здесь появляется дом настроек — таблица и эндпоинты; применяют их задачи уровней текста и доставки уведомлений.

Затрагивает

• таблица настроек пользователя: переключатели уровней текста, канал и адрес уведомлений, и её миграция;
• эндпоинты чтения и записи своих настроек;
• новый экран приложения, и на нём же место выпуска и отзыва личного токена — сам токен заводит api-tokens, экрана у него нет;
• значения по умолчанию для пользователя, у которого настроек ещё нет;
• docs/database.md — представление данных и значения по умолчанию.

Критерии приёмки

• Изменённая настройка видна после повторного входа и не меняется у соседа. Оракул — тест эндпоинта на двух учётных записях: запись первой, чтение обеими.
• Пользователь без сохранённых настроек читает значения по умолчанию, а не пустой ответ. Оракул — тест чтения для новой учётной записи.
• Чужие настройки не читаются и не пишутся по идентификатору. Оракул — тест запроса к настройкам другого владельца: 404 либо 403, содержимое не отдаётся.
• Экран показывает переключатели уровней и поле канала, а сохранение доходит до эндпоинта. Оракул — тест экрана на подставном API.

Рамки

Применением настроек к конвейеру занимаются llm-insights-adapter, literary-text-level и ntfy-delivery — здесь только дом настроек и экран. Выпуск токенов API живёт на этом же экране, но заводит его api-tokens. Берётся после trusted-header-login: до неё настройки не к кому привязать.