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

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

Двигает пункты 1, 2 и 3 «Завершения» цели: у каждого пользователя свои
переключатели уровней текста и свой канал уведомлений, и они переживают
повторный вход.

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

## Затрагивает

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

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

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

## Рамки

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