Два edge'а, всплывших при ре-тесте фикса e7a1b104 на боевом:
1. Fallback для пустого eligible-tomorrow: проект с workdays Mon-Fri,
синхронизированный вечером пятницы → tomorrow=Sat → eligible=[].
computeOrder([])=0, distribute(0)=0/0/0, portal: "Введите limit!".
Если eligible пуст, но группа active — взять computeOrder по всей
активной группе (per-day eligibility соблюдается workdays).
2. Pause-limit: portal требует non-zero limit даже при status=paused.
При паузе последнего активного group=[], order=0, "Введите limit!".
Решение: max(1, sp.current_limit) — сохраняем существующий лимит,
заказы остановлены статусом=paused.
Подтверждено вживую на проде liderra.ru: pause→status=false lim=10,
resume→status=true reg=21. #1/#2/#3 при изменении: 10/10/10.
Регрессия: 37/37 (Sync + Update + Actions).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Закрывает замечания заказчика (22.05.2026) по проектам/поставщику. Все 4 куска
имеют общий корень: online-синхронизация одного проекта работала с данными ЭТОГО
проекта, а не пересчитывала всю «группу» (проекты разных tenant'ов с одним
identifier) — отсюда переплата ×3 при изменении лимита, затирание регионов/дней
группы, неотправленная пауза, и осиротевшие проекты при смене источника.
1. Групповой пересчёт в SyncSupplierProjectJob::handleOnline (#1 при изменении,
#2 дни, #3 регионы, C2/C3): union regions, computeOrder eligible,
distributeForPlatform — те же расчёты, что в ночном syncGroup. Online и
ночной теперь дают идентичный supplier-state, расхождение устранено.
2. Пауза #10:
- ProjectController::toggleActive — диспатчит SyncSupplierProjectJob;
- ProjectService::bulkPauseResume — диспатчит sync per project;
- DTO status вычисляется из groupActive (paused когда группа без активных);
- sp.inactive_since пишется при пересинке (для UI/DTO консистентности).
3. Смена источника #8/#9 в ProjectService::update:
- до update снимается старый buildUniqueKeyAgnostic;
- если изменился — отвязываем старые supplier_projects от этого project
(pivot + legacy FK), DeleteSupplierProjectJob удаляет их у поставщика
при отсутствии других потребителей, либо пересинкает агрегат.
4. Перенос auto-link корня из feat/root-domain-auto-link: новый
App\Support\SupplierIdentifier::extractRootDomain + блоки auto-link в
обоих джобах (online + nightly).
Тесты: TDD на каждый кусок. SyncSupplierProjectJobTest +2 (group recompute,
pause). ProjectUpdateDedupTest +1 (source detach + cleanup dispatch).
ProjectsActionsTest +2 (toggle + bulk pause dispatches).
Регрессия: 186/186 passed (Project/Plan5/Projects + Supplier), 502 assertions.
Деплой: дельтой на боевой (база = root-domain ветка; на боевом джобы СТАРЕЕ
main, deliver через копию изменённых файлов + config:cache + restart queue).
План: docs/superpowers/plans/2026-05-22-замечания-проекты-чеклист.md
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
projects имеет UNIQUE(tenant_id, name); многие импортируемые проекты делят тег
(«КРК», «Ваш инвестор» приходят на десятки телефонов) — старая deriveName
возвращала только тег → коллизия после первой записи. Новая deriveName:
«tag · identifier» при наличии обоих (tag != 'РФ'); fallback на identifier;
'проект' как last resort. Существующий тест name=79001112222 для sms(tag='РФ')
по-прежнему проходит (identifier→fallback).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
C1 (Critical): восстановлена per-project транзакция в commit() через гейт
DB::connection('pgsql_supplier')->getPdo()->inTransaction() — в проде BEGIN/COMMIT
на каждый item (Project+sps+pivot атомарно, no orphan-Project при сбое в группе);
под SharesSupplierPdo+DatabaseTransactions гейт detects общий PDO и пишет inline
(избегает «already active transaction»). Runbook §«Атомарность» переписан.
M3 (Minor): deriveName для sms берёт sms_senders[0] как fallback вместо литерала 'проект'
(когда тег пустой/'РФ').
N1+N2 (test gaps): +тест workdays union по двум площадкам с разными расписаниями
(B1 [1,2,3] ∪ B2 [4,5] → mask 31); +тест sms regions_reverse skip (отдельный
кодовый путь от site/call); +тест sms name из sender при пустом теге.
I1 ОТКЛОНЁН: рецензент предложил вернуть array_values() в parseGibddRegions,
но Larastan однозначно подтвердил `arrayValues.list` — preg_split с
PREG_SPLIT_NO_EMPTY + array_map даёт list, и возврат array_values был бы no-op +
триггерил бы stan-ошибку. Оставлено как было после стан-фикса.
Tests: 32/32 GREEN (29 + 3 new). Source stan-clean (38 ошибок без изменений —
все в test-files quirk #25 + ide-helper drift, не в source).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
findOrFail -> find + ранний выход при null: 'лид удалён/не существует' — терминальная, не транзиентная ошибка. Раньше ModelNotFoundException -> queue->failed() писал в failed_webhook_jobs -> RetryFailedSupplierJobsCommand бесконечно перезапускал (инцидент 21-22.05: 25k+ записей по удалённому лиду №1). +тест RED->GREEN.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ImpersonationController читал/писал impersonation_tokens+tenants через дефолтное подключение (crm_app_user, RLS on). У saas-admin нет tenant-контекста (middleware 'tenant' на /api/admin/* не висит) -> app.current_tenant_id не задан -> SELECT падал SQLSTATE 42704. На dev маскировалось postgres-superuser'ом. Фикс: запросы к impersonation_tokens/tenants через BYPASSRLS pgsql_supplier (как AdminSupplierIntegrationController; модель уже документирует BYPASSRLS-доступ). Транзакция в verify() убрана — increment атомарен, isUsable() гейтит attempts<5. Тест: +SharesSupplierPdo + regression на подключение; baseline getJson 2->3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Портал поставщика НЕ делит лимит по площадкам сам (Plan 3 R6 «verified 15→5»
оказался ложным — проверено вживую 2026-05-21 через listProjects): каждый
B-проект честно набирает до своего лимита, поэтому одинаковый лимит на B1/B2/B3
= заказ ×N (звонки/сайт ×3, sms+keyword ×2) → переплата поставщику.
Восстановлен per-platform split (был удалён в R6):
- SupplierQuotaAllocator::distributeForPlatform(order, platforms) —
largest-remainder, Σ долей == заказу (18→6/6/6, 10→4/3/3, 5→3/2).
- SyncSupplierProjectJob (online) + SyncSupplierProjectsJob (ночной):
create / dead-donor / missing / update — по одной save на площадку с её долей.
Online делит daily_limit_target; ночной делит групповой computeOrder.
Сторона выдачи клиенту не затронута (RouteSupplierLeadJob по-прежнему режет по
лимиту клиента). Утечка была только на стороне заказа у поставщика.
Tests: allocator 27/27, online job 9/9, nightly job 12/12, broad supplier
suite green. 2 SupplierPortalClient PlaywrightBridge-теста падают только в
worktree-окружении (нет node-модуля playwright) — pre-existing, доказано stash.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- update(): WebhookUrlGuard блокирует сохранение private/reserved/loopback IP →
422 validation error на target_url; небезопасные адреса не попадают в БД,
любой будущий потребитель (test() + outbound-доставка) читает только безопасные
- NB: будущая outbound-доставка обязана ВДОБАВОК звать guard перед отправкой
(DNS-rebinding); outbound-pipeline пока не построен (комментарий в update())
- тесты: +PUT private-IP→422 не сохраняет; webhook target_url → публичные
IP-литералы (убрал DNS-резолюцию example.ru-хостов, webhook-suite 93s→5s)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Лидерра нумерует субъекты по конституционному порядку (RussianRegions:
Красноярский=29), поставщик crm.bp-gr.ru — по автокодам ГИБДД (Красноярский=24,
Архангельск=29). Sync слал Лидерра-код как есть → поставщик выбирал ЧУЖОЙ регион
(заказчик выбрал Красноярский край — у поставщика встал Архангельск). На dev не
всплывало: проверяли на «вся РФ» (пустой regions).
Фикс: App\Support\SupplierRegions::mapToSupplier — карта 79 субъектов, построена
сверкой имён RussianRegions ↔ live-дерево формы «Добавить проект» поставщика
(recon 2026-05-21, node-key="id"). Перевод в единственной точке выхода —
SupplierPortalClient::toPayload (покрывает create/update/multiFlag). Тег остаётся
человекочитаемым именем Лидерры.
10 субъектов Лидерры поставщик не предлагает (Московская/Ленинградская/Крым/
Севастополь/ДНР/ЛНР/Запорожская/Херсонская/Ненецкий АО/ЯНАО) — их коды
отбрасываются с warning'ом (георфильтр для них у поставщика недоступен).
Тесты: SupplierRegionsTest (перевод/отброс/dedupe/биекция);
SupplierPortalClientRtProjectTest обновлён (regions [77]→[72] после перевода).
Проверено вживую на тест-сервере: проекты 14/15 пере-синхронизированы, доноры
12742042/12766120 у crm.bp-gr.ru → regions=24 (Красноярский), reverse=false.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Джоб создания/правки проекта запускается из очереди, где SetTenantContext не
отрабатывает (нет app.current_tenant_id GUC). Под боевой ролью crm_app_user первый
же Project::find() падал SQLSTATE 42704 (unrecognized configuration parameter
app.current_tenant_id) за ~2мс — до контакта с поставщиком: проект у поставщика не
создавался, в UI вечный «Sync pending». На dev не всплывало (postgres superuser
обходит RLS). Единственный supplier-flow джоб, который был на дефолтном подключении.
Фикс: const DB_CONNECTION = 'pgsql_supplier' + все DB-операции через ::on()/
DB::connection() — как у SyncSupplierProjectsJob/DeleteSupplierProjectJob/CsvReconcileJob.
Тесты: SupplierConnectionTest +constant-assert; SyncSupplierProjectJobTest
+поведенческий connection-assert (DB::listen → projects-запросы на pgsql_supplier);
Plan5/SyncSupplierProjectJobTest +SharesSupplierPdo (джоб теперь пишет через
pgsql_supplier → нужен shared PDO под DatabaseTransactions).
Проверено вживую на тест-сервере: проекты 14/15 синхронизированы, 6 доноров у
crm.bp-gr.ru (12742042-44 / 12766120-22), aggregateSyncStatus=ok.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Закрывается крестиком, закрытие запоминается в localStorage. Чисто фронтенд (информация, без блокировок, без бэкенда). +3 Vitest.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
handleOnline/syncGroup: сверка external_id со списком живых проектов портала (listProjects); пересоздание удалённых на портале доноров in-place без удаления записей (на supplier_projects могут висеть лиды/списания). online-режим заполняет supplier_b1/b2/b3_project_id, чтобы UI sync-бейдж не залипал в pending. +3 Pest.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DeleteSupplierProjectJob: если после удаления Лидерра-проекта у донора
(supplier_project) не осталось других потребителей (pivot
project_supplier_links) — удаляет его у поставщика и локально;
если потребители есть — НЕ удаляет, диспатчит SyncSupplierProjectsJob.
2 Pest-теста (no-consumers / remaining-consumers) GREEN.
phpstan-baseline: +once() Mockery chain (аналог andThrow baseline).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Дмитрий