Грабля: created_at в SQLite точен до секунды — 7 быстрых смен дают
равные метки, а secondary-сортировка по UUID-id случайна → «последние 5»
выбираются произвольно (флакущий тест + неверно хранимая история).
id теперь autoincrement (обрезка order_by id desc), UUID остаётся
как public_id. Миграция 010 обновлена (таблица только на CT108,
пересоздаётся миграцией заново — см. деплой).
- backup-app.sh: pg_dump 16 (--exclude planet_osm_*), .env+compose в tar,
verify через pg_restore --list, чистка >14 дней
- restore-app.sh: pg_restore 16 --clean --if-exists + TOC без EXTENSION
- ГРАБЛИ pg_wrapper PG18 в контейнере postgres:16: архив версии 1.16
не читается pg_restore 16 (unsupported version) + SET transaction_timeout
нет в PG16 — только /usr/lib/postgresql/16/bin/pg_*
- backend/password_policy.py: validate_new_password (длина, сложность
буквы+цифры, сверка с текущим и историей), record_password_change
(хранит ПРЕДЫДУШИЙ хэш, обрезка до password_history_count),
password_expired + enforce_expiry (пометка must_change_password)
- users.password_changed_at + таблица password_history (010_b23_policy)
- change-password и админ-сброс теперь под полной политикой (сложность
и переиспользование вместо голой длины); get_current_user проверяет
срок действия каждого пароля при запросе
- backend/purge_logs.py: реальный DELETE просроченных audit_events
(+changes) и auth_events; POST /admin/users/maintenance/purge-logs
(manage_security) + CLI python -m backend.purge_logs для cron
- тесты: +19 (258 passed) — валидация/история/срок, purge/идемпотентность/403
- search_engine: max_distance_km передаётся в analyzer (case_data).
- rules_analysis: search_radius = max_distance × _psychotype_radius_multiplier
(среднее по полосам 0-500/0.5-1.5/1.5-2.5/2.5+). Убран двойной учёт
age/season: score_zone.distance_multiplier их уже содержит, а max_distance
их тоже учёл — раньше radius = multiplier×2.0 (хардкод) давал 1.6 км при
радиусе 2.4 км.
- UI: подсказка у «×0.8» — коэффициент скоринга, не радиуса.
- Тест: согласованность summary↔формула.
- rules_analysis._build_zone_reason: детерминированный текст по тем же
факторам, что считает WeightedScorer — рельеф (лесистость %), вода
(расстояние + акцент берегов при не_умеет_плавать), дороги (плотность +
вероятное следование велосипеда), НП (ориентир), совпадение с направлением
последнего свидетеля (точное/соседний румб), полосы психотипа. Финал —
балл оценки.
- ФИКС: weight 'direction' (0.07) был мёртвым — direction_match никогда не
передавался в score_zone (всегда дефолт 0.5); теперь 1.0 при совпадении
с last_seen_direction.
- Фронт уже отображает reasoning на карточках зон — бэкенд-фикс достаточен.
- Тесты: 7 новых на пояснения (детерминированность, факторы, фолбэк). 238 passed.
- Табы, кнопки «Пользователи·Аудит»/«Обновить»/«Открыть анализ», фильтр
операций — dark (#161b22/#21262d/#30363d/#e6edf3), без белых инлайнов.
- ClosedCases.css: светлая форма и чипы → dark-палитра (акцент #238636).
- Аудит: РУ-лейблы case_closed/operation_complete.
- constants.js: LOCATION_TYPES (дорога/тропа/лес/дом-стройка/вода-берег/поле/
не указано), WHO_FOUND_TYPES, FOUND_DIRECTIONS (8 румбов).
- Модал завершения поиска: тип места, кто нашёл, направление — селекты вместо
свободного ввода (данные пригодны для матобработки архива без нормализации).
- Архив /admin (ClosedCases): «Кто нашёл» → тот же селект; LOCATION_TYPES
вынесен в общий модуль.
- POST /operations/{id}/complete: found_alive/дистанция/направление/кто нашёл/
длительность → кейс status=closed + фактические данные + прогон детерминированной
матмодели (model_prediction, accuracy_note в analysis_log) → операция
status=completed + closed_at. Аудит: operation_complete + case_closed.
- ФИКС list_closed_cases: фильтр по to_summary().analysis_log всегда давал None
(analysis_log только в to_detail) → список завершённых был пуст; теперь
фильтр по status='closed' (совместимо с TestDB).
- UI: кнопка «✓ Завершить поиск» на странице анализа (для активных операций),
модал с исходом, после завершения — плашка «Поиск завершён», в архиве
(/admin завершённые) появляется запись с прогнозом модели и точностью.
- Тесты (4): полный флоу, повторное завершение 400, аудит, появление в
/closed-cases. 230 passed.
- UsersAdmin.jsx (/users): список с фильтрами (подразделение/поиск),
форма создания (логин/email/временный пароль/ФИО/должность/юнит/роль),
inline-смена роли и подразделения, отключение/включение, сброс пароля
(все сессии отзываются), статусы цветом. must_change_password
подсвечивается пользователю при первом входе.
- Доступ: бэкенд require_permission('manage_users') — РЦУ РЧС и ОУМЧС;
скоуп координатора фильтрует список по подразделению (кросс-областной
PATCH отбивается 403 на бэкенде).
- Кнопка «Пользователи» из дашборда.
- Dashboard.jsx: счётчики (активных / всего / завершено за 24ч из
/operations/summary), фильтры по статусу, сетка карточек операций
(title, статус-бейдж, подразделение, время обновления), клик →
рабочее пространство (анализ по карточке операции).
- Роут /dashboard, «/» → дашборд (было /desktop).
- CaseForm: после создания карточки автоматически создаётся поисковая
операция (title «Поиск: имя, N лет») — операция не блокирует анализ.
- VCL-density, палитра ЦОУ (#ff4d00 акценты, статусы цветом).
Требование Виктора: несколько одновременных поисков, много пользователей
(каждое ЦОУ = аккаунты), КОНТУР подключается к каждому поиску. За основу —
админка РВС (RBAC + сессии + аудит, паттерн проверен в проде).
План: search_operations (надстройка над cases, не дубль SEARCH_OPERATION
КОНТУРа) + cou_units (справочник ЦОУ с иерархией) + RBAC 4 роли +
гео-скоуп (отличие от РВС) + дашборд активных поисков + contour_operation_id
для B20. Этапы E1 RBAC-ядро → E2 скоуп/аудит → E3 операции → E4 КОНТУР →
E5 B17-ингестия. Границы и критерии приёмки внутри.
СТАТУС: план на ревью, не код.
1. Рекомендации не предписывают перекрывать водоёмы/ж/д — оператор ПРОВЕРЯЕТ
их (правки в rules_analysis, scoring_service ×2 копии, water.py + доки).
2. Геокодирование: район нужен (дубли улиц между районами) — подсказка формата
«пункт, район, адрес» и текст ошибки.
198 passed.
При анализе по case_id координаты карточки (tnp_lat/tnp_lon) не попадали
в SearchInput (читались только payload-lat/lon) → rules_analyze не видел
lat/lon и отдавал базовые fallback-зоны «Ближняя N / Средняя E» —
постоянные направления вверх-вправо на карте независимо от местности.
Фикс: case_id-режим подтягивает lat/lon из tnp_* (gps_* как алиас).
198 passed.
Дизайн Виктора (классика ПСО): возможная зона поиска — круг радиусом
max_distance от ТНП (ядро 0.5R / средняя 0.75R / внешняя R с градацией
плотности вероятности), а приоритетные направления ПОДСВЕЧИВАЮТСЯ
45°-секторами полного радиуса поверх кругов (топ-1 #ff4d00 op0.30,
топ-2 #ff9f1a 0.22, топ-3 #ffd166 0.18, прочие серые 0.10).
Раньше сектора были «пирогами» разного радиуса по score — зона выглядела
лоскутной. Теперь круги показывают охват, подсветка — приоритет.
Решение Виктора: СП(лес) 0.5→1.0. Прежняя таблица учитывала лес дважды
(в НормС и в СП) — подросток 14 лет за 3 часа получал 2.55 км вместо
реалистичных 5.1. Согласуется с априором ПСО (94% находок в 3 км):
радиусы стали верхне-перцентилями, не медианой.
- terrain_map пересчитан относительно среднего леса: лес/простой лес/поле/
луг/город = 1.0; сложный/густой лес 0.5; болото 0.4; горы/овраг 0.6;
дорога/тропа 0.8; дефолт 1.0.
- Контрольные точки тестов пересчитаны (6 шт: 1.92→3.84, 0.33→0.665,
2.43→2.7, 5.4→10.8, 13.5→15.0, stats 0.5→1.0) + операционный тест
подростка 5.1 км.
- settlement_score пока НЕ тронут — на обдумывание (Виктор).
193 passed.
Ближайшая вода бралась по bbox сектора: объект в углу bbox, но вне
45°-пирога, попадал в выборку — вода почти не различала направления
(1.393 км у N/NE/E с одной воды в центре). Теперь строго внутри сектора:
water 1.393–2.337 км по направлениям — честная география.
Два бага в одной строке: водные дистанции делились на cos (вместо
умножения, как дороги) и отдавались как км без /1000. Результат —
850.671 «км» до озера в Браславе (реально 271 м).
Верифицировано против geography: merc×cos = 271.0 м ≈ geo 271.5 м
(дельта 0.1%). Теперь Браслав SE: water 0.271 км, settle 0.119 км.
197 passed.
Закономерность «приоритетная зона вверх-вправо»: score_zone умножает
weight × forest_pct, ожидая ДОЛЮ (тесты скоринга 0.3–0.8), а гео-сервисы
(osm_local и legacy Overpass calculate_forest_coverage) отдавали
ПРОЦЕНТЫ 0..100. Лес получил фактический вес в 100 раз больше задумки —
топ зон систематически занимали чуть более зелёные сектора.
Фикс: osm_local.calculate_forest_coverage возвращают долю 0..1.
Разброс скорингов по Минску: 1.244 → 0.032 (честно однородный город).
Остаточные различия — вода/дороги; дифференциация плотностей город/село —
ревью скоринга (B1), коэффициенты не тронуты.
+регресс-тест 0<=forest_pct<=1. 197 passed.
Мобильная версия выпилена — браузерная геолокация оператора больше не
нужна: ТНП задаётся адресом (кнопка «Найти координаты» → geocode) или
вручную. handleGetLocation и его состояния удалены; .gps-button остался
только у геокод-кнопки.
.gps-button { width:100% } в flex-строке съедал всю ширину, input сжимался
до огрызка. Inline width:auto/flexShrink:0 у кнопки и width:auto/minWidth:0
у инпута.
Sadmin