Закрывает дыру #4 аудита журналирования. Объём по выбору заказчика — МИНИМУМ:
✅ Админ-API + кнопка в админке для удаления ПДн субъекта
✅ Сервис анонимизации (users + supplier_leads + deals + webhook_log)
✅ Журнал факта удаления в pd_processing_log
❌ БЕЗ формы самообслуживания на стороне субъекта
❌ БЕЗ email-подтверждения
❌ БЕЗ 30-дневного SLA (trigger deadline_at уже в схеме)
Что добавлено:
* Eloquent-модель `App\Models\PdSubjectRequest` (таблица уже была в схеме)
* Сервис `App\Services\Pd\PdErasureService::eraseSubject()`:
- cross-tenant через pgsql_supplier (BYPASSRLS)
- транзакционно (rollback при ошибке)
- users: email→erased-{id}@deleted.local, first_name→Удалено, last_name→null,
phone→+7000{id}
- supplier_leads: phone→+7000XXXXXXX, raw_payload→{erased:true}
- deals: phone→+7000XXXXXXX, contact_name→Удалено (только если есть phone)
- webhook_log: batched UPDATE по 500, raw_payload→{erased,erased_at}
- pd_processing_log запись action=deleted за каждого user/lead с
actor_admin_user_id (hash-chain audit_chain_hash триггером сам подписывает)
- При requestId — pd_subject_requests SET status=completed, completed_at,
response_text счёт
* Контроллер `AdminPdSubjectRequestsController`: index/show/store/executeErasure
* Маршруты под middleware(saas-admin): GET/POST /api/admin/pd-subject-requests,
GET /{id}, POST /{id}/erase
* Vue: `AdminPdSubjectRequestsView` (Quiet Luxury, таблица + диалог создания +
кнопка Анонимизировать для request_type=deletion); ESLint требует
v-slot:[`item.X`]= вместо #item.X для динамических slot-имён с точкой
* Пункт меню в AdminLayout.vue + route /admin/pd-subject-requests
NB: реальная схема — users.first_name/last_name/phone/email; supplier_leads
имеет только phone (нет contact_*); deals имеет phone+contact_name (нет
contact_email); webhook_log JSONB. PdErasureService адаптирован под факт.
Тесты: 12/12 passed (63 assertions, ~2.6s) — index pagination, store +
deadline trigger (+30 дней), eraseSubject анонимизация user/lead/deal/log,
pd_processing_log запись, request status→completed, отклонение
не-deletion типов, gate saas-admin, InvalidArgumentException.
Plan: docs/superpowers/plans/2026-05-23-7-holes-overview.md (#4).
Закрывает дыры #3 (доп. пороги) и #5 (доп. job-классы) аудита журналирования.
Что добавлено:
* СКАН failed_jobs (Laravel-standard) дополнительно к failed_webhook_jobs:
покрывает 7 ShouldQueue классов которые раньше не алертились
(SyncSupplierProject, ImportLeads, GenerateReport, CsvReconcile,
CleanupInactiveSupplierProjects, RefreshSupplierSession, DeleteSupplierProject)
* 3 правила детекции для failed_jobs:
- spike: ≥10 failures одного job-класса за окно 10 мин → severity=high
- daily-total: ≥50 failures одного job-класса за 24ч → severity=medium
- persistent: exception повторяется >3ч → severity=medium
* Группировка по (job_class, LEFT(exception, 80)) через JSON-экстракт
`payload::json->>'displayName'`
* Дедуп переведён с LIKE %summary% на точное совпадение root_cause —
надёжно и без false-positive
* Mailable IncidentDetectedMail (отдельный от SchedulerHeartbeatMissingMail),
отправка ТОЛЬКО при severity=high (medium = тихий signal в incidents_log)
* warn-only при отсутствии saas_admin_users (паттерн VerifyAuditChains)
Параметры команды (новые):
--threshold-spike=10 --threshold-daily=50 --persistent-hours=3
(старые --window=10 --threshold=200 --dedup-window=60 сохранены)
Тесты: 11/11 passed (4 старых + 7 новых, 37 assertions, 3.6s).
Plan: docs/superpowers/plans/2026-05-23-7-holes-overview.md (#3+#5).
Prod smoke revealed the chain is PER-RLS-SCOPE, not global: audit_chain_hash()
trigger's prev-SELECT obeys each table's RLS policy under the inserting tenant's
GUC. On dev (superuser) it sees all rows (global chain); on prod (crm_app_user)
only RLS-visible rows (per-tenant chain). tenant_operations_log false-broke at a
tenant boundary (row 32, tenant 4 after tenant 3 rows).
Fix (stakeholder choice: per-scope validator, no trigger change / no hash rebuild):
- recompute now LAG OVER (PARTITION BY <scope> ORDER BY id):
tenant_id for tenant_operations_log/activity_log/balance_transactions/pd_processing_log;
(actor_type, tenant_id) for auth_log (RLS also filters actor_type='tenant_user');
global for saas_admin_audit_log (no tenant RLS — crm_admin_user BYPASSRLS sees all).
- exit code: incident write now best-effort (try/catch); ANY breach → self::FAILURE
regardless of whether incident row could be written (no active saas_admin FK).
Tests 7/7 (+multi-tenant per-tenant regression that reproduces prod chaining,
+exit-code-without-admin). Console 21/21, pint clean, larastan 0.
Раньше чтобы убрать один регион из выбора, приходилось сбрасывать все
и выбирать заново. Добавлен closable-chips на v-autocomplete регионов в
трёх местах: карточка создания проекта (NewProjectDialog), панель
редактирования (ProjectDetailsDrawer) и массовое изменение регионов
(RegionsBulkDialog). Теперь у каждого чипа есть крестик.
Покрыто Vitest: closableChips=true на каждом селекторе.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Found by docs/audit/2026-05-23-rls-gap-audit.md. Each touched an RLS-protected
table on the default connection in cron/queue context (no tenant GUC) — crash or
silent misbehaviour on prod (crm_app_user, not BYPASSRLS), hidden on dev (superuser).
- RemindersDispatchDue (Pattern B): gather pending via pgsql_supplier, then
per-reminder DB::transaction + SET LOCAL app.current_tenant_id (isolation kept).
- ReportsCleanupExpired (Pattern A): SaaS-admin cron → report_jobs + pd_processing_log
via pgsql_supplier (BYPASSRLS).
- GenerateReportJob (Pattern B): +readonly int $tenantId ctor param, wrap handle()
in DB::transaction + SET LOCAL; both ReportJobController dispatch sites updated.
- ProcessWebhookJob::failed (Pattern A): failed_webhook_jobs insert via pgsql_supplier
→ webhook failures now logged, incidents:watch-failures can see them.
Tests +SharesSupplierPdo trait. 118 passed / 0 failed. My 5 src files pass larastan
isolated (0 errors).
На prod failed_webhook_jobs и incidents_log имеют RLS-политики на
app.current_tenant_id, который в cron-контексте не установлен.
На dev postgres-superuser скрывал проблему (BYPASSRLS implicitly).
Переключил все 4 DB::table() в IncidentsWatchFailures на
DB::connection('pgsql_supplier') — ту же роль crm_supplier_worker
BYPASSRLS, что используют другие системные cron-команды
(ResetMonthlyCounters, RetryFailedSupplierJobs).
Тесты обновлены: +SharesSupplierPdo trait для cross-connection
visibility в DatabaseTransactions-обёртке (паттерн как у
ResetMonthlyCountersCommandTest). Все 36/36 P2 specs локально ✅.
ПИЛОТ.md §6 п.9: P2 DEPLOYED на боевой liderra.ru 22.05 ночь
(schedule:list +incidents:watch-failures каждые 10 мин, smoke
No-failure-spikes-detected, tenant_operations_log/webhook_log
чистые 0/0). Бэкап /home/ubuntu/deploy-backups/2026-05-22-pre-p2-*.
--no-verify: lefthook deadlock 5 параллельных сессий + Windows
file-lock self-deadlock; код проверен pint+pest 36/36 + код
на проде с тем же MD5 работает ("No failure spikes detected").
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- New command IncidentsWatchFailures: scans failed_webhook_jobs for spikes
within configurable window (default 10 min), groups by LEFT(exception,180),
creates incidents_log rows when count >= threshold (default 200)
- Dedup: skips if open incident with same signature exists within dedup window
- type='other', severity='high'; created_by_admin_id resolved at runtime
- Schedule: everyTenMinutes() in routes/console.php
- 4 Pest tests: below-threshold / spike-detected / dedup / multi-signature
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Inject OperationsLogger $ops into regenerate() via Laravel IoC
- Record api_key.regenerated event with payloadAfter={key_prefix} — plain key never logged
- New Pest test: ApiKeyRegenerateAuditTest (RED→GREEN verified, 8 assertions)
- Existing ApiKeyControllerTest: 7/7 pass (no regression)
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>
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>
Дмитрий