Self-contained app-namespace artisan command (NEVER on production) that funds local imitation clients on a shared B2 supplier, disables DaData (region from tag), rebuilds the routing snapshot, then injects synthetic leads through the real RouteSupplierLeadJob so deals/charges/notifications appear for hands-on UI review. The lead payload encodes the supplier unique_key as a domain so RouteSupplierLeadJob re-resolves the real supplier (parseProjectField then resolveOrStub). Test asserts exit 0 + new deals.
Restores a working migrate:fresh without the reverted blanket catch-all. (1) MonthlyPartitionManager::ensureMonth skips a partitioned table whose parent does not exist yet (targeted pg_class relkind='p' guard) instead of crashing — the initial schema-load runs partitions:create-months before later delta-migrations create their own partitioned tables. (2) migration 0001 runs with $withinTransaction=false so the schema.sql DDL is committed before partitions:create-months opens its second pgsql_supplier connection. (3) re-applies the clean idempotency guards on add_balance_freeze (DROP POLICY IF EXISTS) and add_paused_at (column/index existence checks) since schema.sql already contains those objects. migrate:fresh now rebuilds liderra_testing cleanly; MonthlyPartitionManagerTest 15/15 incl. new resilience guard test.
Reverts 6f81d136 production-migration edits (load_initial_schema withinTransaction=false + try/catch, idempotency guards) and coupled migrate:fresh guard tests to baseline; imitation suite uses DatabaseTransactions on a pre-migrated DB so the reverted migrate:fresh resilience is not needed for Phase 1. Also drops the orphaned ensureMonth webhook_log test (webhook_log removed from PARTITIONED_TABLES in 2026_05_24_140000_drop_legacy_webhook_artefacts).
deals:backfill-region-city fills deals.city from the lead resolved_subject_code (deals -> supplier_lead_deliveries -> supplier_leads) for deals where city is still empty, idempotently and across all tenants (BYPASSRLS). --dry-run reports the count without writing. Whitelisted in artisan-run.yml (dry-run read-only; real run requires confirm_apply). TDD: +4 tests GREEN.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The UI «Город» column binds to deals.city but nothing ever populated it — the region was only stored as a numeric code on supplier_leads + the resolution log. RouteSupplierLeadJob now writes the resolved subject name (RussianRegions::CODE_TO_NAME) into deals.city on deal creation (the lead's real region, even if subject_code is substituted on routing step 3), and updates it in the CSV-merge branch when the webhook resolution outranks the tag. New deals now display the region. TDD: +2 tests in RouteSupplierLeadJobTest; 24 job tests GREEN.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Test env (`SharesSupplierPdo` trait + postgres superuser) обходит RLS, поэтому
trigger `audit_chain_hash()` в тестах пишет global chain, не per-tenant. Это
расхождение с prod (где RLS активен и trigger пишет per-tenant) валидно — но
делает pre-rebuild sanity-check невыполнимым assumption'ом.
Multi-tenant test теперь проверяет только self-consistency post-rebuild:
rebuild должен produce chain matching своему partition_clause.
Pre-Task-4 (global LAG): post-rebuild verify с PARTITION BY tenant_id → mismatch
→ RED (текущее состояние).
Post-Task-4 (per-tenant LAG): post-rebuild verify с PARTITION BY tenant_id →
match → GREEN.
Prod RLS-aware trigger semantics валидируется live `audit:verify-chains`, не в
этом тесте.
Ref: docs/superpowers/plans/2026-05-29-audit-rebuild-per-tenant-fix.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Task 3 плана 2026-05-29-audit-rebuild-per-tenant-fix.md.
3 новых сценария в AuditRebuildChainTest.php:
1. multi-tenant — 2 tenants, 4 rows interleaved, rebuild from firstId →
chain должна остаться intact per-tenant. RED: fails на pre-rebuild
sanity-check (preMismatches=1) — в test env trigger пишет НЕ per-tenant
chain (SharesSupplierPdo trait → BYPASSRLS). Task 4 имплементер должен
разобрать: либо trigger в test env починить (RLS-aware), либо тест
адаптировать к фактической семантике pgsql_supplier.
2. BYPASSRLS auth_log — INSERT direct через pgsql_supplier, partition_clause=''
(global chain within partition). Сейчас PASS случайно (single global LAG
совпадает с tенущим rebuild semantics).
3. single-row partition — 1 tenant, 1 row, rebuild → должна работать.
Сейчас PASS случайно.
+ new const AUTH_LOG_ROW_EXPR mirror'ит AuditChainConfig::TABLES['auth_log'].
Регрессия narrow: 7 tests / 6 passed / 1 failed (RED expected).
Ref: docs/adr/ADR-018-audit-chain-per-tenant-semantics.md
docs/superpowers/plans/2026-05-29-audit-rebuild-per-tenant-fix.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Task 2 плана 2026-05-29-audit-rebuild-per-tenant-fix.md.
Regression-safe refactor: drop private TABLE_CONFIG const + buildRowExpression()
helper, заменить на чтение AuditChainConfig::TABLES (создан в Task 1, commit
4cfd9f6b) + AuditChainConfig::rowExpression($table). Поведение не изменилось —
тот же baseline regression Pest (9 passed pre-refactor → 10 passed post-refactor;
+1 = регрессия-guard VerifyAuditChainsTest.php flipped fail→pass; 2 pre-existing
errors orthogonal к Task 2).
VerifyAuditChainsTest.php — TDD regression guard на cleanness рефактора: проверяет
полноту AuditChainConfig::TABLES (6 таблиц), корректность rowExpression() для
всех таблиц, и отсутствие private TABLE_CONFIG const после refactor'а.
Ref: docs/adr/ADR-018-audit-chain-per-tenant-semantics.md
docs/superpowers/plans/2026-05-29-audit-rebuild-per-tenant-fix.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replays sha256 chain in given audit partition from given id:
1. Uses pgsql_supplier (BYPASSRLS) to see all rows regardless of RLS scope.
2. Bypasses audit_block_mutation trigger via session_replication_role=replica
(session-local SET, does not affect other connections).
3. Recomputes hash per row using the same formula as audit_chain_hash():
digest(COALESCE(prev_hash,''::bytea) || ROW(col1,...,NULL::bytea,...,coln)::text::bytea, 'sha256')
Column order from COLUMN_CONFIG matches TABLE_CONFIG in VerifyAuditChains.
4. Supports --dry-run (count without UPDATE) and --force (skip confirmation).
Validated against breaking partitions:
--partition=activity_log_y2026_m05 --from-id=599
--partition=balance_transactions_y2026_m05 --from-id=462
Tests: 4 tests — activity_log rebuild, balance_transactions rebuild,
dry-run no-op, unknown partition rejection. All pass (4/4 GREEN).
Refs: docs/superpowers/plans/2026-05-29-audit-chain-race-fix.md Task 3
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Two tests:
1. pcntl_fork concurrent-INSERT test (skipped on Windows/no pcntl) —
demonstrates chain branch when 5 workers insert into the same partition
simultaneously; passes after advisory-lock migration.
2. pg_locks advisory lock presence test (Windows-compatible) —
verifies that pg_advisory_xact_lock is actually held in pg_locks
during an INSERT transaction, proving the migration works.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Добавлен БЛОК 5 в IncidentsWatchFailures::handle() — детекция шторма от
одного supplier_lead_id. Если один lead_id генерирует >= threshold-single-lead
failures за окно (default=1000) → severity=high инцидент с root_cause
'single-lead-storm:<lead_id>'. Дедуп по dedup-window как в остальных блоках.
Новая опция: --threshold-single-lead=1000 (configurable).
Мотивация (Finding 2 Stage 5, 2026-05-29): supplier_leads 1110+1157 генерировали
~256k строк в failed_webhook_jobs за 24ч без алерта. Этот блок создаёт incident
уже при 1000+ failures одного лида в 10-минутном окне — что позволяет обнаружить
шторм в течение первого часа.
Связь с Task 2 (fast-fail): вместе эти два изменения stop new storms (Task 2)
и alert on remaining storms (Task 3).
Tests: 4 passing в SingleLeadStormTest.php
- детекция шторма (>= threshold)
- НЕ создаёт incident при распределённых failures
- default threshold=1000
- dedup (второй запуск = 0 новых инцидентов)
Task 3 plan 2026-05-29-supplier-webhook-fast-fail-and-stuck-cleanup.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Closes failed_webhook_jobs storm class (Finding 2, 2026-05-29):
поставщик crm.bp-gr.ru шлёт B1+SMS combo → DomainException в
SupplierProjectResolver → 3 retries → failed() записывает error в supplier_lead
→ RetryFailedSupplierJobsCommand при следующем dispatch видит тот же lead →
~256k строк/сутки.
Fast-fail guard добавлен в RouteSupplierLeadJob::handle() МЕЖДУ двумя
существующими idempotency-guard'ами и parseProjectField. Если supplier_lead.error
содержит terminal pattern ('does not support' / 'platform mismatch' /
'no matching supplier_project') и processed_at IS NULL — job помечает processed_at
и выходит без записи в failed_webhook_jobs.
Correction 1: реальный класс RouteSupplierLeadJob (не ProcessSupplierWebhookJob).
Correction 3: место вставки — после processed_at guard, до parseProjectField.
Tests: 6 passing в SupplierWebhookFastFailTest.php
- fast-fail на 3 terminal patterns
- НЕ fast-fail при error=null (нормальный лид)
- НЕ fast-fail при processed_at уже установлен (idempotency guard первым)
- НЕ fast-fail при transient ошибке (не matching pattern)
Task 2 plan 2026-05-29-supplier-webhook-fast-fail-and-stuck-cleanup.md.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
After the existing webhook-loss drift detection (R-05.1: lead delivered but
webhook missed), CsvReconcileJob now runs a second pass on project_routing_snapshots:
per (snapshot_date, tenant_id) groups, if (expected - delivered) / expected > 20%
→ send TenantBusinessDriftAlertMail (separate from CsvDriftAlertMail).
This catches R-05.2: lead expected by slepok plan but supplier under-delivered.
Same lead can be missing from both CSV (webhook-loss) AND delivered_count
(business-shortfall) — both alerts fire independently.
BUSINESS_DRIFT_THRESHOLD = 0.20
detectAndAlertBusinessDrift() — runs after primary drift inside try{} block,
scoped to the same reconcile window. One email per tenant per snapshot_date.
+ New TenantBusinessDriftAlertMail + emails/tenant_business_drift_alert.blade.php.
+ 2 Pest tests: shortfall>20% triggers mail (80% case), shortfall<=20% does not (10% case).
+ Existing tests narrowed from assertNothingSent() to assertNotSent(CsvDriftAlertMail)
since legacy snapshot data on dev DB may trigger TenantBusinessDriftAlertMail
beyond test's scope.
Full CsvReconcileJobTest suite 11/11 GREEN. Stage 4 §4.4.4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Deleted platform-specific buildUniqueKey($project, $platform). It diverged for
SMS (B2='sender+keyword', B3='sender' alone) → orphan supplier_projects on
sharing rebalance — B2 and B3 rows for the same project couldn't be reconciled
as one group. Now ALL platforms use buildUniqueKeyAgnostic:
site/call → signal_identifier
sms+keyword → sender+keyword
sms (no kw) → sender
3 callers updated: SyncSupplierProjectJob (online + batch paths) and
SupplierProjectImporter. Pest +1 test on Importer SMS commit asserts uniform
unique_key=sender+keyword across B2+B3 (RED before fix, GREEN after).
Full Importer suite 15/15 GREEN, SyncSupplierProjectsJob 12/12 GREEN.
Stage 4 §4.4.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tenant::requiredLeadsForTomorrow() previously summed raw daily_limit_target of
active projects, overcharging preflight when a tenant shared a call/site signal
with other tenants. Supplier caps the group at max(max(limits), ceil(Σ/3)) and
splits it across all clients on the same signal_identifier, so a single tenant's
real share is typically much smaller than its raw limit.
group_limits = limits of all is_active projects sharing
(signal_type, agnostic signal_identifier/sms_sender+keyword)
group_order = max(max(group_limits), ceil(Σ group_limits / 3))
tenant_share = ceil(group_order × (project_limit / Σ group_limits))
Legacy webhook projects (signal_type=null — no supplier sharing) still count
their full limit (regression-protected by existing 'sums daily_limit_target' test).
Empty groupLimits edge → conservative full-limit fallback (cross-conn race).
3 Pest tests: single project (legacy passthrough), 3-tenant share discriminator
(10→4), legacy webhook regression. Stage 4 §4.4.3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extracted SyncSupplierProjectJob::targetWeekdayForNow() — slepok cut-off boundary
is 21:00 МСК, matching supplier's snapshot fix-point. Before fix Carbon::tomorrow
flipped at midnight, mis-aligning portal sync (Thu 23:59 МСК pointed to Fri while
post-21:00 portion of day N belongs to slepok dated N+1 effective day N+2).
hour < 21 МСК → target = today + 1 day
hour >= 21 МСК → target = today + 2 days
3 pure unit tests (Mon 20:00→Tue, Mon 22:00→Wed discriminator, Tue 00:01→Wed
no-midnight-flicker) confirm new logic. Baseline regression verified — 8 pre-
existing Pest failures on Windows-native PG env are NOT caused by this change.
Stage 4 §4.4.2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stage 3 Task 3.2. BalancePreflightSweepJob now mirrors freeze/unfreeze state
onto projects.paused_at so SupplierSnapshotGuard has the right hook to block
delete/change_source while the supplier slepok tail can still arrive:
- On freeze: capture freezeAt = now() once, set tenant.frozen_by_balance_at
AND projects.paused_at (only WHERE paused_at IS NULL) to the same moment.
This gives the snapshot guard a uniform recent paused_at across all of the
tenant's projects.
- On unfreeze: capture frozen_at_was BEFORE save, then clear paused_at only
on projects whose paused_at >= frozen_at_was (== auto-paused by us).
Manual pauses set by the client BEFORE freeze have paused_at < frozen_at_was
and stay preserved.
Spec §4.3.2.
Stage 3 Task 3.1. Add frozen_by_balance_at guard in chargeForDelivery() before
bcmath arithmetic. Even if balance_rub > 0, a tenant flagged by
BalancePreflightSweepJob must not be charged for new lead deliveries. The
InsufficientBalanceException throw triggers the existing auto-pause flow
(RouteSupplierLeadJob::handleInsufficientBalance → projects.is_active=false +
ZeroBalancePausedMail rate-limited). Spec §4.3.1.
Stage 3 Task 3.0. Add 'AND tenants.frozen_by_balance_at IS NULL' to both
EXISTS-on-tenants subqueries in matchEligibleProjects (DIRECT path + B path).
Without this filter, a tenant frozen by BalancePreflightSweepJob continues to
receive leads from the existing slepok, getting charged for deliveries they
explicitly cannot fund. Spec §4.3.1 R-03.
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.
Manual recovery после падения SnapshotProjectRoutingJob cron'а. В отличие от
snapshot:backfill (ON CONFLICT DO NOTHING), snapshot:rebuild сначала DELETE'ит
существующий snapshot за дату, затем INSERT'ит свежий из live state.
Fail-loud strategy (Spec §4.2.6):
1. Heartbeat alarm via SchedulerHeartbeatTracker (Task 2.4 — already wired).
2. LeadRouter Log::error on missing snapshot (Task 2.5 — already wired).
3. Manual recovery: php artisan snapshot:rebuild --date=YYYY-MM-DD.
NO fallback to live projects — explicit downtime + alert is safer than silent
regression.
NB: ->transaction() wrapper НЕ используется — конфликтует с SharesSupplierPdo
shared-PDO в тестах. half-done state допустим: retry восстанавливает; на проде
admin контроль и редкость вызова.
Plan: docs/superpowers/plans/2026-05-26-slepok-routing-protection.md §Task 2.10
Tests added:
- tests/Feature/Console/SnapshotRebuildCommandTest.php — 2 tests.
Status: RED locally (Windows-native PG Project factory signal_type quirk —
same as Task 2.2/2.3, memory project_slepok_protection.md). Command itself
registered (php artisan list | grep snapshot). GREEN expected on CI Linux.
After Stage 2 запуска, 18:05 МСК sync читает project_routing_snapshots за tomorrow
МСК, не live projects.is_active. Это закрывает race 18:02 (snapshot) → 18:05 (sync):
клиент мог нажать «пауза» в эти 3 минуты, но мы всё равно докатываем зафиксированный
slepok поставщику (slepok-инвариант).
collectEligibleProjects() переписан с Project::on()->where('is_active', true)
на Project::on()->join('project_routing_snapshots AS snap', ...). Snapshot уже
отфильтрован по is_active/preflight_blocked/frozen_tenant; повторно проверяем
frozen-фильтр на случай freeze в эти 3 минуты. daily_limit_target /
delivery_days_mask / regions переопределяются значениями snapshot (slepok-семантика);
downstream syncGroup() работает без изменений.
Spec §4.2.4b. Closes race 18:02→18:05.
Plan: docs/superpowers/plans/2026-05-26-slepok-routing-protection.md §Task 2.9
Tests:
- tests/Feature/Jobs/Supplier/SyncSupplierProjectsJobSnapshotTest.php (4 new tests, PASS).
- tests/Feature/Supplier/SyncSupplierProjectsJobTest.php — 12 existing tests patched
with insertSnapshotForTomorrow($project) helper (12/12 GREEN).
- tests/Feature/Supplier/SyncSupplierPreflightFilterTest.php — 2 existing tests
patched (2/2 GREEN).
- tests/Pest.php — global helper insertSnapshotForTomorrow().
Combined sync regression: 19/20 PASS + 1 skipped (pre-existing).
Patched via 2 parallel Sonnet subagents per Pravila §15.1; controller-verified
combined regression.
ProjectService::update() теперь возвращает Project с dynamic applies_from
attribute (CarbonImmutable | null), который ProjectResource подхватит для UI
(«изменения вступят в силу с DD.MM 21:00»).
Логика: для каждого изменённого поля из SupplierSnapshotGuard::SLEPOK_SENSITIVE_FIELDS
вычисляется максимум appliesFrom() — slepok-инвариант (до 18:00 МСК = today 21:00,
после = tomorrow 21:00). NULL = применяется немедленно (none changed / no supplier links).
Plan: docs/superpowers/plans/2026-05-26-slepok-routing-protection.md §Task 2.8
Spec: docs/superpowers/specs/2026-05-26-slepok-routing-protection-design.md §4.2.5
Tests: tests/Feature/Services/Project/ProjectServiceAppliesFromTest.php — 4/4 PASS.
ProjectService regression — 7/7 PASS.
Возвращает CarbonImmutable когда правка slepok-sensitive поля вступит в силу:
правка до 18:00 МСК → сегодня в 21:00 МСК
правка с 18:00 МСК и позже → завтра в 21:00 МСК
Возвращает null когда правка применяется немедленно:
- поле не slepok-sensitive (вне 7 полей SLEPOK_SENSITIVE_FIELDS), либо
- проект не связан с поставщиком (нет project_supplier_links)
7 slepok-sensitive полей: is_active, daily_limit_target, delivery_days_mask,
regions, signal_identifier, sms_senders, sms_keyword.
Spec §4.2.5. Используется ProjectService (Task 2.8) для прикрепления к
UI-ответу метки «изменения вступят в силу с DD.MM HH:MM МСК».
Plan: docs/superpowers/plans/2026-05-26-slepok-routing-protection.md §Task 2.7
NB plan-bug: оригинальные тесты в плане использовали Project::factory()->make()
с id=null, что приводило к WHERE project_id IS NULL → 0 совпадений. Заменил
на ->create() для реального id (factory default signal_type=null nullable в
projects table, не блокирует create()).
Tests added:
- tests/Feature/Services/Project/SupplierSnapshotGuardAppliesFromTest.php
(11 tests including dataset-driven для 7 полей, 11/11 isolated PASS).
Дмитрий