Аудит открытых issues: актуальность, приоритеты и очистка backlog (июль 2026)

## Цель

Зафиксировать результат аудита всех открытых issues основного репозитория: что всё ещё воспроизводится на текущем `main`, что уже исправлено кодом, какие задачи нужно закрыть, переписать или разделить и в каком порядке с ними работать.

Аудит проведён по `main` на коммите `d2103f4`. Проверены постановки и комментарии всех 12 открытых issues, текущий код, миграции и связанные PR. Этот issue — координационный roadmap, а не задача на один общий PR.

## Краткий итог

- критических P0-блокеров среди открытых issues нет;
- 3 задачи следует выполнить в первую очередь: #793, #609, #649;
- 2 задачи требуют перепроектирования и разделения: #16, #590;
- 1 продуктовая задача актуальна и готова к уточнению scope: #726;
- 1 задача требует продуктовой спецификации до разработки: #756;
- 5 задач рекомендуется закрыть: #7, #73, #424, #606, #619.

| Issue | Состояние по коду | Рекомендация | Приоритет |
|---|---|---|---|
| #793 | Реальный дефект корректности | Оставить и исправить | P1 |
| #609 | Реальный дефект метрик | Оставить и исправить | P1, quick win |
| #649 | Реальная проблема логирования | Оставить и исправить | P1, quick win |
| #16 | Проблема актуальна, предложенное решение устарело | Переписать и разделить | P2 |
| #726 | Актуальная UX-фича | Оставить, уточнить scope | P2 |
| #756 | Недостаточно определено | Сначала продуктовый разбор | P3 |
| #590 | Частично выполнено, удаление рискованно | Превратить в roadmap и разделить | P3 |
| #619 | Исправлено рефакторингом | Закрыть `completed` | — |
| #606 | Mostly fixed, новых примеров нет | Закрыть `completed` | — |
| #73 | Уже реализовано | Закрыть `completed` | — |
| #424 | Ответственность frontend-карты | Закрыть как moved | — |
| #7 | Устаревшая незавершённая концепция | Закрыть `not planned` | — |

## P1: сделать в первую очередь

### #793 — определять завершённый поиск по папке

Статус сейчас полностью берётся из распознавания заголовка в [`SearchParser`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/identify_updates_of_topics/_utils/search_parser.py#L70-L82). `folder_id` сохраняется, но при переносе темы код только пишет лог и не формирует изменение статуса: [`ChangeDetector`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/identify_updates_of_topics/_utils/change_detector.py#L76-L82).

Из-за этого тема с нейтральным заголовком в папке завершённых поисков может остаться со статусом `Ищем`.

Предлагаемый scope отдельного PR:

1. Получать список папок с `folder_subtype='searches finished'`.
2. Сохранять точные терминальные статусы из заголовка (`НЖ`, `НП`, `Найден`).
3. Если точного терминального статуса нет, но папка завершённая — использовать `Завершен`.
4. Перенос в завершённую папку должен создавать `topic_status_change`.
5. Добавить тесты на перенос активная → завершённая, завершённая → активная, точные терминальные статусы и event/info папки.

### #609 — исправить единицы метрик `send_notifications`

Проблема всё ещё присутствует: [`_process_logs_with_completed_sending`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/send_notifications/_utils/services/notification_sender.py#L209-L226) получает секунды из `seconds_between_round_2()`, но называет и логирует значения как минуты.

Дополнительно:

- порог `max_parse_time >= 2` фактически сейчас равен двум секундам, хотя по смыслу ожидались минуты;
- `[s0]` остался в итоговом сообщении: [`finish_analytics`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/send_notifications/_utils/services/notification_sender.py#L98-L129).

Нужен маленький PR:

- ввести явное преобразование в минуты;
- разделить метрики скорости в секундах и задержки в минутах;
- проверить admin threshold;
- убрать `[s0]`;
- добавить unit-тесты на 30 секунд, 2 минуты и несколько минут.

### #649 — снизить шум и объём `compose_notifications` логов

В `info` всё ещё выводятся полные списки `user_id`, настройки отдельных пользователей и полный текст уведомления:

- [`users_list_composer.py`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/compose_notifications/_utils/users_list_composer.py#L34-L70);
- [`message_composer.py`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/compose_notifications/_utils/message_composer.py#L120-L132).

На `info` следует оставить только идентификатор изменения/поиска, количества до и после фильтров, длительности и итоговое число сообщений. Payload, координаты и пользовательские ID — `debug` с ограничением размера либо удалить. Это одновременно снижает стоимость логов, шум и экспозицию пользовательских данных.

## P2: актуальные задачи, требующие нормального scope

### #16 — стабильная региональная подписка вместо forum folder ID

Основная проблема актуальна: `user_regional_preferences` с конкретными folder ID остаётся источником истины как для интерфейсов, так и для [`compose_notifications`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/compose_notifications/_utils/_mixins/user_filter_mixin.py#L106-L114).

`user_pref_region` сейчас фактически используется как флаг «пользователь настраивал регион», а не как полный источник подписок: [`RegionMixin`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/_dependencies/user_repository/region.py#L13-L67). Реализовывать issue буквально как ещё один частичный dual-write опасно.

Предлагается разделить на три самостоятельных issue:

1. **Модель стабильной региональной подписки** — выбрать ключ (`division_id`, `region_id` либо отдельная сущность) и отношение регион → актуальные forum folders.
2. **Dual-write и backfill** — заполнить новую модель из `user_regional_preferences`, временно писать обе и добавить reconciliation-отчёт.
3. **Переключение чтения** — перевести `compose_notifications`, карту и интерфейсы на стабильную модель, затем вывести legacy-таблицу из эксплуатации.

Снять `good first issue`: это миграция данных с риском потери уведомлений.

### #726 — кнопка «Отслеживать поиск» в новом уведомлении

Follow-механизм существует в списке поисков, но новое уведомление содержит только кнопку карты: [`NotificationMaker`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/compose_notifications/_utils/notifications_maker.py#L125-L141).

Для первого PR предлагается явно ограничить scope Telegram:

- добавить кнопку «Отслеживать поиск» с `search_id`;
- сделать отдельный идемпотентный callback, а не переиспользовать handler клавиатуры списка поисков;
- после успеха менять состояние кнопки;
- проверить, что callback относится к нужному пользователю;
- добавить тесты записи в `user_pref_search_whitelist`.

VK/MAX при необходимости оформить отдельными issues.

## P3: сначала уточнение или безопасная подготовка

### #756 — настройка «не присылать Дома»

Issue не содержит описания, а «Дома» в текущем коде не является однозначным нормализованным статусом. Не определено, нужно ли скрывать комментарий, состояние выезда или другой operational event.

До разработки нужны:

- 5–10 реальных примеров;
- точное определение сигнала;
- ожидаемый результат для каждого примера;
- решение, действует ли настройка на все мессенджеры;
- критерии ложных срабатываний.

Если правило нельзя сформулировать, issue лучше закрыть `not planned`, а не реализовывать фильтр по подстроке `Дома`.

### #590 — удаление ненужных таблиц

Issue частично устарел. Уже существуют миграции:

- `002_remove_stale_table_and_fields.sql` для `notif_mailing_status`;
- [`006_drop_unused_tables.sql`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/doc/migrations/006_drop_unused_tables.sql) для `feedback`, `news`, `old_dict_regions` и зависимых views.

При этом некоторые обсуждавшиеся кандидаты используются: `dict_search_activities` читается `compose_notifications`, `geo_divisions` используется географией и views.

Предлагается:

1. read-only аудит production schema, views, foreign keys, размеров и внешних jobs;
2. перечень подтверждённо неиспользуемых объектов;
3. отдельная reversible migration на каждую логическую группу;
4. backup/rollback и период наблюдения;
5. только затем удаление тестовых моделей.

После создания конкретных дочерних задач #590 можно закрыть как заменённый roadmap. Не удалять таблицы только на основании отсутствия упоминаний в Python-коде.

## Рекомендуемые закрытия

### #619 — закрыть `completed`

После #910 `send_notifications` больше не передаёт общий psycopg2 cursor. SQL вынесен в `DBClient`, а каждый метод открывает собственный SQLAlchemy connection/transaction через [`DBClientBase.connect()`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/_dependencies/common/db_client.py#L12-L23). В `src/send_notifications` больше нет прямых `cursor()`.

Если `cursor already closed` повторится, нужен новый issue с современным stack trace, а не продолжение задачи по удалённой архитектуре.

### #606 — закрыть `completed`

Автор отметил `mostly fixed` после #713. Нормализация телефонов и обработка вложенных ссылок покрыты тестами; после мая 2025 года новых воспроизводимых примеров не появилось.

Новые дефекты следует заводить отдельно с HTML-фрагментом форума, фактическим и ожидаемым сообщением.

### #73 — закрыть `completed`

Фразы «Последний раз редактировалось» и «всего редактировалось» уже удаляются в [`content.py`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/_dependencies/forum/content.py#L212-L227). Желательно добавить отдельный regression-тест на полный пример из issue, но сама функциональность реализована.

### #424 — закрыть как moved / wrong repository

Backend уже возвращает `СТОП`: запрос карты исключает `НЖ`, `НП`, `Завершен`, `Найден`, но не `СТОП`: [`user_provide_info/_utils/database.py`](https://github.com/cherrytea-dev/la_searcher_bot/blob/main/src/user_provide_info/_utils/database.py#L82-L90).

Показ/скрытие и временный фильтр принадлежат frontend-карте. Связанная задача уже существует: https://github.com/cherrytea-dev/la_searcher_map/issues/1. Требование временного показа следует перенести туда, а #424 закрыть со ссылкой.

### #7 — закрыть `not planned`

`urgency` не читается notification pipeline. Есть таблица и признак в settings summary, но нет scheduler, SLA, правил справедливости и защиты от starvation. Собирать пользовательскую настройку без определённого поведения создаёт мёртвые данные и ложное ожидание.

Если queue lag снова станет продуктовой проблемой, нужна новая задача на измеренный scheduler: классы событий, rate limits мессенджеров, SLA и fairness, а не просто поле «важность пользователя».

## Дополнительно отсутствующие задачи

В основном backlog пока не перенесён аудит безопасного переключения с legacy на уже реализованный `phpbb_posts_history` путь. Контекст зафиксирован в https://github.com/volodkindv/la_searcher_bot/issues/21.

Рекомендуется создать в основном репозитории три самостоятельные задачи:

1. корректный checkpoint по фактическому максимальному `history_id`;
2. backlog/lag и наблюдаемость phpBB-пути;
3. shadow-сравнение и безопасное переключение с legacy с fallback.

Если падение DB-теста из PR #946 с повторным `geo_folders.folder_id=154` воспроизведётся ещё раз, его также следует оформить отдельным issue на изоляцию фикстур.

## Предлагаемый порядок работ

1. #793 — корректность статуса по папке.
2. #609 — единицы метрик и admin threshold.
3. #649 — уровни и содержимое логов.
4. Создать три main issues для phpBB checkpoint/observability/rollout.
5. Разделить #16 и начать с модели стабильной географии.
6. Реализовать Telegram scope #726.
7. Получить продуктовую спецификацию по #756.
8. Выполнять #590 только после production schema audit.

## Чек-лист завершения этого аудита

- [ ] Maintainer согласовал классификацию и приоритеты.
- [ ] Закрыты либо аргументированно оставлены #7, #73, #424, #606, #619.
- [ ] Уточнены acceptance criteria #609, #649, #726, #793.
- [ ] #16 разделён на model/backfill/read-switch.
- [ ] #590 разделён на production audit и отдельные migrations.
- [ ] По #756 принято продуктовое решение.
- [ ] В основном репозитории созданы задачи phpBB checkpoint/observability/rollout.

This is a coordination roadmap covering issues #793, #609, #649, #16, #726, #756 and #590 rather than a standalone code change. Start by reading the linked Python entry points, migrations, and the audit commit d2103f4. Done means maintainer agreement, the listed issues are closed or scoped into child tasks, and the audit checklist is completed.

Written by the indexing model from the issue text.