Повод — письмо тревоги 31.07.2026 05:30 МСК: сверка №1417 отрапортовала «потеряно 7».
Разбор на бою показал, что вебхук по тем же семи пришёл через 2,5 минуты (05:32:32 ×2 +
05:33:03 ×5) и получил «уже есть». Потери не было: поставщик кладёт строку в журнал
отданного РАНЬШЕ, чем шлёт вебхук, а наша сверка (каждые 30 мин) попадала в эту щель.
Цена ошибки не только ложная тревога: добранная карточка беднее живой (в журнале нет
tag/time/phones) — у 4 из 7 не определился регион, у сделок пустые регион и город.
1. Отсрочка добора (CsvReconcileJob::GRACE_MINUTES = 15). Недостача, увиденная впервые,
уходит в карантин (Redis, карта vid => время первого обнаружения) и добирается только
следующим прогоном, если провисела дольше отсрочки. Реальная потеря доезжает максимум
через полчаса. Потеря карантина безопасна: в худшем случае добор на прогон позже.
drift и «потеряно» в письме считаются ТОЛЬКО по просроченному; «в пути» — отдельно
(новая колонка supplier_csv_reconcile_log.pending_count).
2. Журнал вебхука поставщика (новая таблица supplier_webhook_log). Прежний
logSupplierWebhook писал в webhook_log, снесённую 24.05 вместе с legacy-каналом, и
молча выходил по Schema::hasTable — журнала не было ВООБЩЕ. Из-за этого 70 отказов 404
за 10 дней никто не видел; нашлись случайно в логе nginx. Пишем статус, адрес
отправителя, запрошенный хост и отпечаток присланного ключа (первые 8 символов md5 —
отвечает «наш ключ или чужой», секретом не является). Отказы дополнительно уровнем
warning: на бою LOG_LEVEL=warning, info в журнал не попадает.
3. Текст письма-тревоги переписан: «потеря» = только то, что не дошло даже за отсрочку;
«в пути» показывается отдельной строкой и потерей не считается.
4. В catch сверки — Log::error ПЕРВЫМ действием, до обращений к БД: при испорченной
транзакции следующий запрос бросал своё исключение и настоящая причина терялась.
Проверено: тесты поставщика и вебхука 230/230 (в т.ч. 5 новых на карантин, поздний
вебхук, отчёт «в пути» и смоук шаблона письма), Larastan 0, Pint чисто. Прогон всей базы
3566/3575; 5 падений — чужие и до этих правок (замерено откатом файлов): биллинг на стыке
месяцев и маршруты телеграм-ветки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ProjectResource.source_change_message = ProjectRuleMessages.sourceChanged (тот же текст,
что in-app уведомление 6.2). Диалоги подтверждения (дроуэр + окно Редактировать) тянут его
из API с fallback на локальный текст. Бэкенд — единственный источник строк правил, экран и
колокольчик не расходятся. Проверено глазами (epic6-unified-rule-text-confirm.png). Тесты:
ProjectResource 5/5, дроуэр 27/27, EditProjectDialog 7/7.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Эпик 1 Task 1.1: поля source_locked/unlock_at/projected в ProjectResource уже отдаются
из SupplierSnapshotGuard::lockState (спека source-edit-lock-ux). Добавлен недостающий
характеристический тест состояния (в) — проект на паузе в grace-окне.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Набор полностью зелёный (55 to 0; 1713 pass + 4 skip). Всё тест-сторона:
- AuditChainRaceConditionTest: advisory-lock в audit_chain_hash РЕАЛЬНО присутствует
(миграция 2026_05_30 применяется) — падало наблюдение: bind-параметр в SQL-сдвиге
(? >> 32) не сдвигал → classid не совпадал. Декомпозицию ключа считаем в PHP.
NB: db/schema.sql хранит функцию БЕЗ блокировки (минорный дрейф канона; прод через
миграцию защищён) — стоит перегенерить schema.sql отдельно.
- SupplierConnectionTest WARN#2: matchEligibleProjects ограничен cap=LeadDistributor::CAP=3;
ждать 3 из 6 видимых тенантов (кросс-tenant видимость под BYPASSRLS; при RLS было бы 0).
- SupplierWebhookTest + ValidationFormatTest: фаза 3 намеренно приняла проект без
B-префикса как DIRECT (не теряем заявки) — тесты под новый контракт (202 / 422 по vid).
- SupplierPortalClientTest: fake-паттерн под старый URL /admin/rt-projects-load; клиент
зовёт /admin/visit/rt-projects-load — обновлён паттерн.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SupplierSnapshotGuard::lockState (pure, без DB) + ProjectResource отдаёт source_locked/source_unlock_at/source_unlock_projected; ProjectController withCount(supplierProjects). Логика гарда не изменена.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ProjectResource теперь включает поле `applies_from` (ISO8601 строка | null) в
JSON-ответе. Установлен ProjectService::update() для slepok-sensitive правок
(Task 2.8 dynamic attribute).
UI Vue/composables/Vitest часть откладывается на отдельную сессию — это
backend-only commit для бэкенд-инструмента UI-сообщения.
Spec §4.2.5.
Plan: docs/superpowers/plans/2026-05-26-slepok-routing-protection.md §Task 2.11
Tests: tests/Feature/Http/Resources/ProjectResourceAppliesFromTest.php — 2/2 PASS.
Reproduces 302-redirect bug observed on prod 2026-05-25 — when supplier
crm.bp-gr.ru POSTs without Accept: application/json, Laravel renders
ValidationException as redirect to /, losing body. Test calls webhook
without Accept header and asserts JSON 422 response. Will fail until
bootstrap/app.php has render(ValidationException) for api/webhook/supplier/*.
SupplierWebhookLoggingTest.php queried webhook_log table which was dropped
in Phase 4 DROP migration (schema v8.35). This file was missed in Phase 3
cleanup (WebhookReceiveTest.php was deleted but SupplierWebhookLoggingTest
was a separate file testing the same dropped infrastructure).
4 tests deleted — all tested webhook_log INSERT/SELECT which is now gone.
SupplierWebhookTest.php (new controller tests) remains unchanged.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Defense-in-depth: secret (≥32 chars system_setting) + IP allowlist (CIDR).
Несовпадение → 404. UNIQUE vid → 200 OK на дубль (idempotency).
Тесты пока FAIL (route регистрируется в Task 7 — пишем "красные" тесты заранее
для TDD-цикла).
Spec §5.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Дмитрий