Спецификация правок «По душе»: DUSHA-57, DUSHA-58, DUSHA-43, DUSHA-16…19 и корень DUSHA-60

Дата: 21.09.2026. Основание: карточки трекера tracker.salam0nn.ru/p/DUSHA и ручная проверка каждого утверждения 21.09 (код, curl к прод-копии cloud.ru, запуск парсера сборщика на скачанных страницах, живой прогон приложения на эмуляторе). Номера строк даны по main на коммите 2894cd60.

Документ для разработчика: в каждом разделе есть симптом, доказанная причина, точные правки по файлам, тесты, критерий приёмки и что требует выката на cloud.ru.

0. Общие правила

1. DUSHA-57. Битые обложки all-events.ru

1.1. Симптом и что доказано

• В публичном каталоге cloud (GET /api/v1/public/events) 69 событий с площадки All-Events, у всех обложка вида https://all-events.ru/upload/iblock/<dir>/<hash>.jpg. Ручная проверка HEAD: из 40 случайных 30 отвечают 404.
• Для каждой проверенной мёртвой ссылки страница самого события (og:image) отдаёт тот же файл с расширением .png. HEAD на .png → 200. Из 15 мёртвых в выборке 13 оживают заменой расширения, 2 мертвы и как .png.
• Список площадки (https://all-events.ru/events/) отдаёт карточку с background-image: url(/upload/webp/resize_cache/iblock/<dir>/402_245_0/<hash>.webp). Это превью, оно живое.
• Парсер страницы события в текущем коде отдаёт верный .png (проверено запуском parse_detail_html на скачанной странице). Значит на стенде либо страница события не была прочитана, либо новая ссылка не смогла вытеснить старую (см. причину Б).

Вывод: карточка Вадима верно описывает симптом, но причина не «площадка потеряла файлы», а наша догадка про расширение плюс невозможность заменить уже сохранённую ссылку.

1.2. Причины

Как обложка доходит до приложения: cover_source_url → колонка cover_url в выгрузке (ingestion/ui/export.py:381-385) → карточка с content_hash (export.py:158-166, включает cover_url) → events/catalog_import.py на сервере (values['cover_url'], строка ~460; при неизменном content_hash только отметка синхронизации, catalog_import.py:549-553) → Event.cover_url → API. Перехостинг на сервере (_rehost_cover, catalog_import.py:433-451) включается только для хостов из settings.CATALOG_REHOST_HOSTS (_needs_rehost, 425-431); all-events туда не входит.

1.3. Правки

1.3.1. Не угадывать расширение (причина А).

• parse_list.py: upgrade_image_url переименовать в absolute_image_url; функция только делает адрес абсолютным (urljoin) и убирает ?-хвост. Никакой замены resize_cache/webp на .jpg.
• Список (parse_list.py:334-343): image_url карточки = webp-превью как есть (/upload/webp/resize_cache/...webp). Это заведомо живой адрес.
• Страница события (parse_detail.py:194-207): порядок кандидатов оставить (og:image, itemprop image); og:image уже абсолютный и с верным расширением. ev.image_url = og:image, если он есть; иначе itemprop-картинка без переписывания.
• merge_detail (parse_detail.py:331-344) без изменений: image_url со страницы события побеждает список.
• normalize.py:255-272 без изменений: candidates = [image_url, *images] даёт og:image позицию 0, превью списка следующую.

1.3.2. Устаревшие медиа не должны оставаться обложкой (причина Б).

В _upsert_media (persist.py:651) после обхода входящего списка:

stale = записи EventMedia этого события с kind=image,
        source_url не во входящем списке,
        download_status == url_only  (файл никогда не скачивался)

• stale удалять. Записи со статусом done/pending не трогать (у них есть файл).
• Входящий список приходит целиком на каждый прогон, поэтому удаление безопасно: живая ссылка вернётся следующим же прогоном.
• Инвариант: после _upsert_media позиция 0 у события ровно одна и это первая входящая картинка.

1.3.3. Проверка ссылок (причина В), общая для всех сборщиков.

• В DownloadStatus добавить dead. Если колонка event_media.download_status в Postgres является enum-типом, нужна Alembic-миграция ALTER TYPE ... ADD VALUE 'dead'; если это строка, миграция не нужна.
• Новый модуль ingestion/orchestrator/media_check.py:
• check_url(url) -> int: HEAD с таймаутом 5 с, User-Agent как у сборщика; на 405/403 повтор GET с Range: bytes=0-0; сетевые ошибки = код 0. Одна повторная попытка через 2 с.
• verify_new_media(session, run_id): для медиа, созданных в этом прогоне (по created_at/run_id), не более 8 одновременных запросов на хост, результат в extras["check"] = {"status": код, "at": ISO}; при 404/410 → download_status = dead. Живые остаются url_only.
• recheck_dead(session, older_than_days=7): недельная перепроверка мёртвых; ожившие возвращать в url_only.
• Вызов verify_new_media в конце прогона сборщика (там же, где сейчас пишется статус прогона, ingestion/orchestrator/), recheck_dead из ночной maintenance.
• cover_source_url (ui/serializers.py:103) исключает медиа со статусом dead. Тогда выгрузка отдаёт следующую живую картинку или пустую обложку. Пустая обложка честнее битой: приложение рисует цветную плашку с эмодзи темы (DUSHA-30).
• Стоимость: один HEAD на новую картинку; на прогоне all-events это сотни запросов, не тысячи. Таймаут и лимит на хост обязательны, иначе прогон площадки растянется.

1.3.4. Разовая уборка накопленного.

CLI-команда python -m ingestion media-repair --source all_events (добавить в ingestion/cli.py рядом с sources seed list run status coverage ui):

1. Для каждой EventMedia с хостом all-events.ru и путём /upload/iblock/.../*.jpg: HEAD. 200 → оставить. 404 → HEAD на .png; 200 → заменить source_url (дубликат по уникальности event_id + source_url удалить), иначе download_status = dead.
2. Печать сводки: проверено / оживлено / мертво.
3. После уборки cover_url в выгрузке меняется, content_hash меняется, ближайший импорт на сервере обновит Event.cover_url сам (catalog_import.py:555-566). Отдельной серверной команды не нужно.

Ожидание по выборке 21.09: около 85 % мёртвых оживут, остальные уйдут в dead и получат плашку.

1.4. Тесты

tests/test_all_events_normalize.py (уже есть, 8 тестов): - карточка списка с background-image: url(/upload/webp/resize_cache/iblock/8f3/402_245_0/x.webp) → image_url == "https://all-events.ru/upload/webp/resize_cache/iblock/8f3/402_245_0/x.webp", и нигде не появляется .jpg; - страница события с og:image .../8f3/x.png и списочным превью → после merge_detail image_url = .png, превью на позиции 1; - absolute_image_url не меняет расширение ни для .png, ни для .jpeg, ни для .webp.

Новый tests/test_persist_media.py (Postgres-фикстуры из tests/conftest.py): - первый прогон даёт медиа A.jpg (позиция 0); второй прогон даёт B.png (0) и C.webp (1) без A → в базе только B, C, cover_source_url = B; - медиа со статусом done не удаляется при отсутствии во входящем списке; - cover_source_url пропускает dead.

tests/test_media_check.py: check_url на локальном HTTP-сервере (pytest httpserver или http.server в потоке): 200 → живая, 404 → dead, 405 на HEAD + 206 на GET → живая, таймаут → код 0, статус не меняется.

1.5. Приёмка

• На дев-стенде после прогона all-events: SELECT count(*) FROM event_media WHERE source_url LIKE 'https://all-events.ru/upload/iblock/%.jpg' AND download_status='url_only' не растёт; новые обложки all-events = og:image.
• На cloud после выката и импорта: 40 случайных all-events обложек из /public/events → не меньше 38 отвечают 200; в приложении у событий All-Events фотографии, а не плашки (кроме честно мёртвых).
• Ни одной ссылки вида .../upload/iblock/.../*.jpg, построенной из webp, в новых данных.

Требует выката сервиса сборщиков на cloud (Вадим). Приложение не меняется.

2. DUSHA-58. Город в колоде свайпов

2.1. Симптом и что доказано

• GET /api/v1/events/deck?city=Санкт-Петербург с демо-аккаунтом на cloud отдаёт те же 10 карточек четырёх городов (8 Мск, 8 СПб, 2 Екб, 2 НН по двум упоминаниям city_name на карточку) и тот же rest: 952, что и запрос без города.
• GET /api/v1/public/events?city=Санкт-Петербург фильтрует правильно (совпадение по имени города).
• Приложение город в колоду не отправляет вовсе: у метода deck в PodusheApi параметра city нет.

2.2. Причины

2.3. Правки

Сервер (events/services.py).

1. DECK_FILTER_KEYS = ('city', 'interest', 'district', 'from', 'to', 'price').
2. В deck(): python allowed = {k: params.get(k) for k in self.DECK_FILTER_KEYS if params.get(k)} if params else {} qs = self.published_qs() if not allowed.get('city'): qs = self._filter_by_user_city(qs, user) # профиль — значение по умолчанию if allowed: qs = apply_public_filters(qs, allowed) # явный город побеждает профиль apply_public_filters (events/public_filters.py:219-221) уже отбирает city_name__icontains=city. Формат значения: русское имя города, как в /public/events и в приложении.
3. Обновить docstring deck() и комментарий над DECK_FILTER_KEYS (сейчас там сказано, что колода принимает только пять ключей).
4. _filter_by_user_city не трогать: для ленты «лучше чужой город, чем пустая лента» остаётся.

Приложение (android-events).

1. PodusheApi.kt, метод deck: добавить @Query("city") city: String? = null.
2. EventsRepository.kt, deck(filter): передавать city = filter?.city.
3. Колода должна грузиться с городом всегда, а не только после шторки: - DeckViewModel: убрать автозагрузку из init; загрузка только через load(next). - AppNavHost.kt, маршрут Swipes (строка 1081): LaunchedEffect(afisha.filters.city) { deckVm.load(afisha.filters.toFilter()) }; перед этим, если afisha.filters.city.isNullOrBlank(), выставить defaultCity через afishaVm.updateFilters(afisha.filters.copy(city = defaultCity)) (тот же код, что сейчас на открытии шторки, строки 1099-1101). LaunchedEffect(cards.size) на строке 1132 сохранить. - AfishaFilter.isEmpty (EventsRepository.kt:94-97) уже учитывает city, поэтому фильтр только с городом в load(next) не обнуляется.
4. Сброс фильтров (AppNavHost.kt:1175) уже сохраняет город; проверить, что после «Сбросить» колода перечитывается с городом.

2.4. Тесты

tests_dating_tz/test_event_deck.py (есть хелперы _user, _imported(**kwargs) с city_name, _deck(**params)), класс DeckCityTests: - профиль без города, события в Москве и Петербурге, _deck(city='Санкт-Петербург') → только петербургские, rest = их число; - профиль с городом Москва, _deck() → только московские; _deck(city='Санкт-Петербург') → только петербургские (явный выбор побеждает профиль); - _deck(city='Нет такого города') → пусто, rest == 0; - существующий test_foreign_params_are_ignored (или аналог про «чужие параметры») дополнить: q и bbox по-прежнему игнорируются.

Приложение: Paparazzi-кадров для колоды не менять; проверка руками по 2.5.

2.5. Приёмка

• Сервер (после выката): deck?city=Санкт-Петербург → у всех карточек venue.city_name == "Санкт-Петербург"; без параметра у аккаунта с городом Москва → только Москва.
• Приложение: открыть свайпы, не открывая фильтры → только Москва; в фильтрах выбрать Петербург → «Показать» → только Петербург; «Сбросить» → снова Москва. Проверять на сборке против cloud после выката сервера, до него приложение изменений не покажет.

Правка сервера без правки приложения ничего не даёт, и наоборот. Делать обе, выкат сервера через Вадима.

3. DUSHA-43. Прокрутка «Политики» и «Соглашения»

3.1. Симптом и что доказано

Свежая debug-сборка 21.09 на эмуляторе podushe390, вход --es route policy --es kind terms|privacy:

• «Соглашение»: четыре абзаца, ниже пустота. Одно движение вверх, и текст уезжает целиком, лист белый; ещё четыре движения ничего не меняют (снимки совпадают байт в байт). Снимки: https://salam0nn.ru/artifacts/podushe-dusha-43-shots/terms_1_top.png, .../terms_2_after1swipe.png.
• «Политика»: долистывается до последней строки «Дата последнего обновления: 19 августа 2026 г.», лишней пустоты почти нет. Снимки .../privacy_1_top.png, .../privacy_2_end.png.

3.2. Причина

ui/screens/legal/PolicyNodeScreen.kt:62: текст рисуется PdNodeText(... blockHeight = 1824.dp ...) — высота ноды 261:26913 из макета — и в живом режиме (scrollable = true, строка 43/54) тоже. Область прокрутки равна 1824 dp плюс отступы независимо от длины текста. «Соглашение» занимает около 350 dp, остальное пустота. PolicyScreen.kt читает res/raw/terms.md и res/raw/policy.md, выкидывает строки с # и пустые, передаёт scrollable = true.

3.3. Правка

PolicyNodeScreen.kt:62:

blockHeight = if (scrollable) Dp.Unspecified else 1824.dp,   // 261:26913: кадр держит высоту ноды, живой экран — высоту текста

Modifier.pdBlockHeight (ui/kit/NodeText.kt:195-196) при Dp.Unspecified высоту не задаёт; ветка абзацев в PdNodeText (NodeText.kt:99-113) оборачивает Column в Box(modifier.pdBlockHeight(blockHeight)), значит высота станет равна тексту. Модификатор wrapContentHeight(unbounded = true) на строке 68 оставить: он нужен режиму кадра.

Кадр A3-policy-261-26902 (app/src/test/.../ScreensScreenshotTest.kt:196-197) вызывает PolicyScreen(kind = "privacy"), то есть живой режим. Видимые 844 dp сверху не меняются, снимок должен совпасть. Если diff появится, разбирать, а не перезаписывать эталон.

3.4. Тексты

Оба документа сейчас рыба из макета (CONTENT-GAP в PolicyScreen.kt): - res/raw/terms.md: 4 абзаца, «сервиса «Название»»; - res/raw/policy.md: 23 абзаца, но это текст пользовательского соглашения про «ООО «Название»», а не политика конфиденциальности.

Финальные тексты даёт владелец. Формат файла: абзацы по одному на строку, пустые строки и строки с # игнорируются. При замене проверить экран заново по 3.5.

3.5. Приёмка

• «Соглашение»: при коротком тексте прокрутки нет вообще, текст остаётся на месте после любых движений.
• «Политика»: пролистывается до последней строки, за ней пустого экрана нет.
• Кадр a3Policy в Paparazzi без diff.
• Сервер не нужен.

4. DUSHA-16, 17, 18, 19. Консоль оператора (backend/admin-panel)

Консоль это статичный JS без сборки: backend/admin-panel/index.html, assets/core.js, assets/admin.css, разделы в assets/sections/*.js. На cloud деплоится образом admin-spa-image:<тег> (migration/cloud-ru/admin-spa.yaml:34), то есть тоже через тег и Вадима. На cloud выложены те же строки, что в репозитории (проверено 21.09 по https://dushalove.uxbrain.ru/ops/assets/sections/*.js).

4.1. DUSHA-16. Подсказки для разработчиков в интерфейсе

Правило разбора каждой надписи: - описывает устройство системы (таблицы, Redis, адреса разделов, названия моделей, HTTP-методы) → удалить; - объясняет оператору, что сделать на экране → переписать по-русски без жаргона; - сообщение о правах/ошибке → оставить.

Найдено к удалению или переписыванию (файл:строка, текущий текст):

Полный обход: grep -n 'class="note">' sections/*.js, grep -n 'class="sub">' sections/*.js | grep -vP '[А-Яа-я]', grep -n 'class="faint"' sections/*.js. Всё, что в этих списках содержит имена таблиц, полей, HTTP-методов, Redis, drawer, payload, JSON, PATCH, идёт под правило выше.

4.2. DUSHA-17. Обрезанные идентификаторы

Причина: shortId (core.js:453-456) режет UUID до 8 знаков; в журнале событий (overview.js:510-521, строка 519 ${esc(shortId(e.user_id))}) это единственное, что показано о человеке, ссылки нет, скопировать нельзя.

Правки:

1. Сервер, adminpanel/views/analytics.py:118-150 (обе ветки, где собирается page_items): выборку делать с select_related('user') (ProductEvent.user это FK на ExternalUser, analytics/models.py:63-70) и добавить в строку user_name (имя) и user_phone. Пусто, если пользователя нет.
2. overview.js:519: <td>${esc(e.user_name || '—')} <span class="mono faint" title="${esc(e.user_id || '')}">${esc(e.user_phone || shortId(e.user_id))}</span></td>; при наличии e.user_id клик по ячейке открывает карточку пользователя через openUser360(e.user_id) (core.js:632).
3. В core.js рядом с shortId добавить idChip(id): <span class="mono faint idchip" title="${id}" data-copy="${id}">${shortId(id)}</span>, обработчик клика копирует полный идентификатор в буфер и показывает «Скопировано». Применить во всех местах, где идентификатор показан без телефона или имени: moderation.js:85, 90, 156, 182, 355, 406, ingest.js:1126, ops.js:626, 1079, users.js:203, 841, 867, 1057. Где рядом есть телефон или имя (users.js:267, 272, 354-357, 837, 1114, 1478), не трогать.

4.3. DUSHA-18. Ключи вместо слов

Причина: бейджи доверия приходят ключами и печатаются как есть (users.js:583, (p.badges || []).join(', ')); имена событий на карточке пользователя тоже сырые (core.js:844, ... .join(' · ') (+N total)). Словаря нет ни в консоли, ни на сервере (scoring/ оперирует только ключами).

Правки:

1. Новый файл assets/labels.js, подключить из admin.js: js export const BADGE_LABELS = { children_disclosed: 'Дети указаны', criminal_checked: 'Судимость проверена', esia_verified: 'Госуслуги подтверждены', fssp_checked: 'ФССП проверено', }; export const EVENT_LABELS = { /* все имена из KNOWN_EVENT_NAMES */ }; export const label = (map, key) => map[key] || `<span class="mono">${esc(key)}</span>`; Ключи бейджей: scoring/services.py:156-157, scoring/providers/children.py:24-33 и остальные провайдеры scoring/providers/*.py (grep -rn "badge=" scoring/). Имена событий: analytics/models.py:9, KNOWN_EVENT_NAMES (feed_item_shown, feed_opened, event_reaction, geo_ping, company_invite, onboarding_step, like_sent, superlike_sent, pass_sent, undo_pass, app_open, auth_ok, feed_loaded, match_shown, swipe_training_done, age_range_done и далее по списку). Формулировки подписей согласовать с владельцем до слияния.
2. users.js:583 → badges.map(b => label(BADGE_LABELS, b)).join(', ').
3. core.js:844 → имена событий через label(EVENT_LABELS, name), «(+N total)» → «и ещё N».
4. overview.js:596 подписи столбцов диаграммы тоже через EVENT_LABELS с полным title.
5. Неизвестный ключ показывать как есть моноширинным, не прятать: так видно, что словарь отстал.

4.4. DUSHA-19. Чипы слов в реестре лексики

Заголовок карточки не о том; в теле речь о чипах слов на странице «Реестр запрещённой лексики». Причина: ingest.js:930-941 рисует <span class="chip" style="...padding:6px 10px"> с кнопкой <button class="iconbtn">✕</button>, а .iconbtn (admin.css:87) это 36×36 px с рамкой. Для чипов SEO уже есть уменьшенное правило admin.css:962-966 (.seo-kw-chips .chip .iconbtn, .rowtags .chip .iconbtn, ... → 16×16 без рамки), к лексике оно не применено.

Правки: 1. Контейнеру чипов (ingest.js:930) добавить класс rowtags (уже используется для рядов чипов в applogs.js:524, ingest-telegram.js:289, seo-keywords.js:184, seo-panel.js:631). 2. Убрать инлайновый padding:6px 10px и style у кнопки в ingest.js:935-939; высота чипа должна выйти около 22 px, текст занимает большую часть. 3. Переименовать карточку в трекере: «Реестр лексики: чипы слов втрое крупнее текста».

4.5. Приёмка (весь раздел 4)

• Снимки «до/после» тех же четырёх экранов, что на скриншотах Нихромова: «Чаты пользователей», «Обзор платформы», диаграмма событий, «Trust-профили», реестр лексики.
• Ни одной надписи с именами таблиц, методов, Redis, drawer, JSON, PATCH в интерфейсе (grep по правилам 4.1 пустой).
• Журнал событий: имя и телефон, клик открывает карточку пользователя; обрезанные идентификаторы копируются по клику.
• Бейджи и события словами; неизвестный ключ виден моноширинным.
• Требует выката образа консоли на cloud (Вадим). Серверная часть только в 4.2 п.1.

5. DUSHA-60. Корень: площадка, координаты, район, организатор

Три пункта карточки это два корня и одна несделанная функция. Ниже правки, после которых беда не повторяется, и разовая уборка.

5.1. Доказательства (cloud, 21.09)

• 43 события Афиши из Петербурга, Москвы, Екатеринбурга висят на одной площадке dd18546d-… без названия с адресом «423451, респ Татарстан, Альметьевский р-н, г Альметьевск, ул Герцена, д 3в», city_name = "Нижний Новгород", без координат. Ещё 13 событий All-Events на площадке «не определено» (Москва).
• По фильтру города в /public/events: Москва 19 событий с площадкой «Нижний Новгород», Петербург 13 НН + 5 Мск + 2 Екб, Казань 10 НН + 4 СПб + 4 Мск.
• Афиша: 61 из 751 событий без названия площадки, 456 из 751 без координат.
• Организатор пуст у 954 из 954 публичных событий.

5.2. Корень 1: ключ площадки

Причина: ingestion/orchestrator/persist.py:180-186, _stable_place_id: без source_place_id ключ = auto:<normalize_title(name) или "unknown">:<geo_cell или "nogeo">. Города в ключе нет. Все безымянные площадки без координат одного источника получают ключ auto:unknown:nogeo и сливаются в одну запись; одноимённые без координат сливаются между городами. merge (persist.py:380-385) берёт первый непустой адрес и первые координаты, city_code записи никогда не обновляется. Сервер (events/catalog_import.py:272-278) при каждом импорте перезаписывает venue.city_name из карточки события, потому что выгрузка (ingestion/ui/export.py:466-481) город площадки не передаёт.

Правки:

1. persist.py, _stable_place_id(v, city_code): - есть source_place_id → как сейчас; - иначе auto:<city>:<name_norm>:<addr_norm>:<cell|nogeo>, где addr_norm = адрес без пунктуации и регистра (как place_id_for в collectors/telegram/normalize.py:54-56), city = v.city_code or item.city_code; - нет ни названия, ни адреса → вернуть None; _upsert_venue в этом случае возвращает None, событие остаётся без площадки, с городом и координатами события.
2. _upsert_venue: перед merge проверять venue.city_code == (v.city_code or item.city_code); при несовпадении не мержить, а завести новую запись (ключ с городом это уже гарантирует; проверка это защита от старых записей).
3. merge: city_code дописывать, если пуст; при непустом и другом — не трогать и писать предупреждение в лог прогона.
4. ui/export.py, блок venue: добавить city_code и city_name площадки. catalog_import.py:277: city_name площадки брать из card['venue']['city_name'], а не из события.
5. Ночная проверка в ingestion/alerts.py: число событий, у которых venue.city_code != event.city_code; больше нуля → тревога.

5.3. Корень 2: координаты и район не знают города

Причины: - events/geo_areas.py:34-44, area_for_point: поиск полигона по всем GeoArea без фильтра по городу, хотя поле GeoArea.city_name есть (events/models.py:1626) и import_geo_areas его заполняет (import_geo_areas.py:245). - ingestion/geo/backfill.py:70-74: геокодируются площадки city_code == <город прогона> OR city_code IS NULL по индексу одного города (load_index, 34-47). Площадка без города получает точку чужого города. - Проверка «точка внутри города» только у Афиши (collectors/afisha/normalize.py:54-76, _coords и _CITY_BBOX), у остальных нет.

Правки:

1. geo_areas.py: area_for_point(point, city_name) фильтрует GeoArea.objects.filter(kind=DISTRICT, city_name=city_name, boundary__contains=point); district_for_event передаёт event.city_name, для площадки venue.city_name; backfill (69-94) то же. Нет города → района нет.
2. ingestion/collectors/cities.py: в реестр городов добавить bbox (широта/долгота, рамка с запасом 30 км) для каждого кода. _CITY_BBOX из afisha/normalize.py перенести туда и удалить локальную копию.
3. persist.py: единая проверка в _upsert_venue/create/merge и при записи event.lat/lon: точка вне bbox своего города → координаты не пишутся, extras["geo_rejected"] = {"lat","lon","reason":"outside_city"}, статус события needs_geo (как сейчас делает Афиша).
4. geo/backfill.py:74: убрать | (Venue.city_code.is_(None)); площадки без города не геокодировать.
5. После выката: python manage.py backfill_districts --refresh (флаг есть, backfill_districts.py:26) на дев-стенде и cloud после загрузки районов (DUSHA-55).

5.4. Корень 3: организатор

Причина: цепочка обрывается на выгрузке. Сборщики извлекают организатора (OrganizerSpec, collectors/protocol.py:32-35; Timepad timepad/normalize.py:318, 474; всего упоминаний в 25 сборщиках), база сборщика хранит Organizer (persist.py:396-420). ui/export.py организатора не отдаёт (в карточке для сервера поля нет; organizer_brief используется только в UI сборщика). На сервере Event.organizer это FK на ExternalUser (events/models.py:373-380), _organizer_dict (events/services.py:152-170) отдаёт null для событий с площадок. Приложение (ui/screens/afisha/EventPageState.kt:102-105) строит раздел «Организаторы» только из event.organizer и рисует заголовок с пустым списком (EventPageNodeScreen.kt:821-835). Афиша организатора не парсит и почти никогда не даёт.

Правки:

1. Сервер, events/models.py: Event.organizer_name (CharField 512, blank), Event.organizer_url (URLField, blank), Event.organizer_external_id (CharField 128, blank, индекс). Миграция.
2. ui/export.py: в карточку organizer: {"external_id": "org:<id>", "name": ..., "url": ...} | null. catalog_import.py: писать три поля.
3. events/api_schema.py:20-30 и services.py:152-170: organizer становится объектом с полем kind: {"kind":"user", user_id, name, initials, color, ...} или {"kind":"external", name, url}; null только когда нет ни того, ни другого. Обновить документ контракта (DUSHA-61 про расхождения документа и сервера).
4. Приложение: Dtos.kt:118-126 OrganizerDto + kind, url; EventPageState.kt:102-105: для external строка с именем без перехода в профиль, аватар = заглушка организации из макета (нода согласовать с владельцем); если организатора нет, раздел не рисовать.
5. Сборщик Афиши: парсить organizer из JSON-LD, если поле есть; отсутствие организатора у Афиши это норма, не ошибка.

5.5. Разовая уборка

1. Сборщик: команда python -m ingestion venues-rekey [--source afisha]: для всех площадок с source_place_id LIKE 'auto:%' пересчитать ключ по новому правилу через нормализацию исходной карточки (данные площадки есть в venues и event_source_links), перевесить события, удалить записи без событий. Сводка: перевешено / удалено / без площадки.
2. Сервер: после следующего импорта у событий появятся новые venue (по новому external_id), старые общие записи станут сиротами. Команда python manage.py prune_orphan_venues (новая): удалить Venue без событий и без ссылок.
3. Районы: backfill_districts --refresh.
4. Обложки: раздел 1.3.4.

5.6. Тесты

• tests/test_dedup.py или новый tests/test_venue_identity.py: две безымянные площадки без координат в разных городах дают разные ключи; одноимённые без координат в разных городах не сливаются; без названия и адреса ключ None; координаты вне рамки города отбрасываются и помечаются.
• tests/test_geo_backfill.py: площадка с city_code = None не геокодируется; площадка Петербурга не ищется в московском индексе.
• tests_dating_tz/test_events_public_api.py (фикстуры GeoArea с square(), строки 740-751): точка в московском полигоне у события с city_name='Санкт-Петербург' района не получает; backfill с городом не трогает чужие.
• tests_dating_tz/test_api_contract.py: organizer.kind в обоих вариантах и null.
• Сборщик Афиши: карточка с organizer в JSON-LD → OrganizerSpec.

5.7. Решения, которые нужны от владельца до начала

1. Событие без названия площадки и без адреса остаётся без площадки, только с городом.
2. Что показывать в «Организаторы» у событий с площадок, пока внешнего организатора нет: ничего или название источника (в макете такого состояния нет).
3. Грузить ли районы Петербурга сразу после починки (import_geo_areas --city Санкт-Петербург --bbox …).

Требует выката сборщиков, сервера и консоли на cloud, плюс приложения. Без разовой уборки старые склейки не исчезнут.

6. Порядок работ

Каждый шаг: своя ветка, PR в main, комментарий в карточке с тем, чем проверено, карточка «На проверке». Владелец проверяет руками.

7. Как сделано 21.09.2026 (отличия от плана)

Ветки от локального main 2894cd60 (в кузне и на GitHub его 18 коммитов нет, от них зависят и приложение, и сервер): fix/dusha-58-deck-city, fix/dusha-57-all-events-covers, fix/dusha-43-policy-scroll, fix/dusha-16-19-admin, fix/dusha-60-venue-identity; все вместе — integration/dusha-fixes-2026-09-21.