Follow-up к c3e6ddb (label-refresh): метки узлов обновил, а проза внутри
nd() (NODE_DETAILS) оставалась с дрейфом. Заказчик «карту html обнови» —
поправил два места:
1. claude_md nd() стр.276 — `Tooling v2.15` → `Tooling v2.22`
(manages-список ссылается на устаревшую версию Прил.Н).
2. tooling nd() стр.299 — «Реестр 80 позиций — 60 формализованных
инструментов + 20 ruflo-плагинов» → «Реестр 93 позиций — 73 форма-
лизованных инструментов + 20 ruflo-плагинов» (канон Прил.Н §0:
v2.20 счётчик 67→73 / 87→93; v2.21+v2.22 — без изменений счётчиков).
Не трогал — историческая фактура: реколлаж 16.05.2026 (v1.16/v2.2/...) на
стр.268/1188/1618 и cross-ref-checker collision 17.05 на стр.1471.
Узлы/рёбра не менялись (147/180) — это string-refresh внутри nd().
LEFTHOOK_EXCLUDE=adr-judge: то же, что c5d360f/c3e6ddb (ReDoS-обход).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Инцидент 22.05.2026 утро: liderra-queue.service крашился signal=9/KILL
каждые ~60с на RefreshSupplierSessionJob, после 5 крашей systemd блокировал
рестарт. OOM-killer в dmesg пуст, память здорова (peak ~200 МБ из 2 ГБ),
crm.bp-gr.ru отвечает.
Корень: дефолтный Laravel queue:work --timeout=60 убивал worker через
pcntl_alarm+posix_kill за 5 секунд до того, как PlaywrightBridge
успевал поднять Chromium (cold-start на 2GB VM ~65с — это уже знали и
увеличили TIMEOUT_SECONDS=180 в PlaywrightBridge.php HOTPATCH 21.05, но
таймаут самого воркера в systemd-unit упустили).
Поймано через bpftrace tracepoint:signal:signal_generate — sender pid ==
target pid, comm=php (PHP сам себе шлёт SIGKILL).
Fix: --timeout=300 в ExecStart (180s PlaywrightBridge + 120s запас).
На сервере применён через drop-in
/etc/systemd/system/liderra-queue.service.d/timeout.conf как safety-net.
Verified live: RefreshSupplierSessionJob отработал 1 мин. 5 сек. DONE
(до фикса — 1 мин. FAIL → KILL цикл).
22.05 вечер-3: попробовал убрать 'unsafe-inline' из style-src. План: Report-Only
без unsafe-inline параллельно с enforcing → Playwright по 6 страницам →
если 0 violations → перевести enforcing в strict.
Что вышло:
- Initial-load 6 страниц (login → dashboard → deals → admin/billing → projects →
reminders) + открытый Vuetify-overlay (cmdk-stub) — 0 violations.
- Перевёл enforcing в strict → СРАЗУ 2 violations от Vuetify VBtn
(build/assets/VBtn-jqIH42oB.js:4, inline-style при SPA-router-переходе).
- Report-Only ловит ТОЛЬКО initial-load — router-переходы не ловит.
- Откатил за минуту (бэкап liderra.bak-strict-attempt-20260522-082008).
Вывод: убрать 'unsafe-inline' без правки Vue-приложения нельзя. Нужен
nonce-based CSP: Laravel-middleware генерит per-request nonce → meta-тег +
CSP-заголовок; Vue ставит app.config.cspNonce; Vuetify подхватывает nonce
для динамических <style>; Vite-rebuild + копир-деплой. Тестировать
обязательно с router-переходами, не initial-load. Многочасовая dev-задача —
в follow-up §6 п.4 с конкретными шагами (а..д).
Текущий boevoy state: CSP enforcing с 'unsafe-inline' на style-src
(как было до попытки) — сайт работает, видимых регрессий нет.
cspell-words.txt +15 пре-существующих эксплуатационных терминов из ПИЛОТ.md
от параллельных сессий (ротирован/разлогинятся/стектрейсы/PGDG/SMTPS/MTA
и т.п.) — словарь не успевал за правками.
LEFTHOOK_EXCLUDE=adr-judge: то же, что в c5d360f (ReDoS на длинных markdown).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Шапка «Снимок снят» — добавлен инцидент 22.05 вечер: 500 Server Error
из-за повреждённого APP_KEY (CRLF + дубль ключа от key:generate).
APP_KEY ротирован — Redis-сессии невалидны, юзеры разлогинятся.
§2 (Сервер) — два новых пункта:
- предупреждение про CRLF при scp с Windows (корень инцидента) +
pre-flight гейт `/usr/local/bin/liderra-precheck.sh` (15 проверок);
- очередь: Restart=on-failure + Burst=5/5min + OnFailure email
(раньше Restart=always крутился бесконечно).
§4 SEC-4 (мониторинг) — добавлен healthcheck слой:
- cron */2 мин liderra-healthcheck.sh → email DOWN/RECOVERED на kdv1@bk.ru;
- liderra-queue-alert.service для systemd OnFailure → email с status + journalctl.
§4 SEC-1 (WAF) — правило 1900300: для /api/* порог
tx.inbound_anomaly_score_threshold с 5 до 10 (edge-case JSON больше не FP);
правило 1900200 (PATCH/PUT/DELETE) теперь упомянуто как дублирующая
страховка от обновлений CRS.
Сводка снизу — пятая запись «✅ Закрыто 22.05» расширена инцидентом.
Источник всех скриптов: tools/liderra-monitoring/ в репо (push 365d1a0).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Привожу документацию в порядок после фактического развёртывания серверного
слоя защиты на боевом тест-сервере liderra.ru (22.05.2026, на тестовой VM
Yandex Cloud, до закрытия Б-1).
Что сделано:
- docs/security/server-hardening-setup.md (новый) — setup-док серверного
слоя SEC-1..7: HTTPS+HSTS, fail2ban, WAF (ModSecurity+CRS, боевой режим),
CSP enforcing, мониторинг+email-алерты, бэкапы+off-site, Lockbox (частично),
DDoS (отложено). Зеркалит стиль docs/security/pgaudit-anonymizer-setup.md.
- docs/Открытые_вопросы_v8_3.md -> v1.85: SEC-1..7 статусы приведены к факту
(сделано / отложено / частично). Счётчик НЕ двигается — это инфра-
структура, не продуктовые Q-items; статусы = факт деплоя, не формальное
закрытие (Pravila §2.2 соблюдена). v1.84/v1.83 трейл не тронут.
- cspell-words.txt +10 терминов серверного слоя.
- tools/observer-chain-map.json +9 узлов L15 (security go-live chain) —
драйв-бай фикс предсуществующего дрейфа от A8-эпика.
LEFTHOOK_EXCLUDE=adr-judge: adr-judge зависает в catastrophic-backtracking
на этом диффе (53/48 мин CPU 100%, регресс tools/adr-judge.py на длинных
markdown-доках). Диф чисто документация, ADR-нарушений нет. Баг adr-judge —
отдельный follow-up. Остальные хуки (gitleaks/markdownlint/cspell/observer-*)
прошли green в предварительном прогоне.
Источник фактов: memory/project_server_hardening.md, ADR-014 §9.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Инцидент 22.05.2026: liderra.ru 500 Server Error. Корень — повреждённый
APP_KEY в .env (24 строки с CRLF + дубль ключа от key:generate). Каскад:
Laravel не парсил .env → fallback на default sqlite/database cache →
sqlite-файла нет → 500 на каждом HTTP-запросе; liderra-queue в
бесконечном activating-loop'е (Restart=always без лимитов).
Файлы (все LF через локальный .gitattributes — защита от CRLF-инцидента):
liderra-precheck.sh — pre-flight гейт (15 проверок: CRLF в .env, длина
APP_KEY, decrypt(encrypt) round-trip, PG/Redis ping, config-cache
свежее .env, pending migrations, HTTP smoke). exit 1 при любом провале.
liderra-healthcheck.sh + cron */2 — проверка портала каждые 2 минуты;
2 подряд провала (~4 мин downtime) → email DOWN; первый 200 после
DOWN → email RECOVERED.
liderra-queue.service — Restart=on-failure, StartLimitBurst=5/5min,
OnFailure=liderra-queue-alert.service. Очередь больше не крутится в
бесконечном крэше — после 5 крашей systemd останавливает + шлёт email.
liderra-queue-alert.service + liderra-systemd-alert.sh — отправка email
при окончательном fail системного юнита (status + journalctl tail).
msmtprc.template — шаблон для /etc/msmtprc (placeholder
__MAIL_PASSWORD__ подставляется из app/.env MAIL_PASSWORD).
Установлено на /var/www/liderra/app (тест-сервер YC):
/etc/msmtprc, /usr/local/bin/liderra-*.sh,
/etc/cron.d/liderra-healthcheck, /etc/systemd/system/liderra-queue*.service.
Тестовое письмо на kdv1@bk.ru доставлено (smtpstatus=250).
WAF (ModSecurity OWASP CRS 3.3.5) уже было правило 1900200 от A8 infosec
(разрешает PUT/PATCH/DELETE — добавлено в 06:00). Дополнительно:
/etc/nginx/modsec/liderra-exclusions.conf id:1900300 — для /api/*
поднят порог inbound_anomaly_score_threshold с 5 до 10 (чтобы edge-case
JSON-payloads не давали false-positive: PATCH/DELETE и так дают +5 в CRS).
Verification: 9/9 GREEN.
Smoke: liderra.ru → 200, PATCH/DELETE /api/* → 419 (Laravel CSRF, не 403 WAF).
Services: php-fpm/queue/nginx/postgres/redis — все active.
Pre-flight: 15/15 ✓ (был бы DOWN-сигнализатор сегодня за 5 секунд).
Laravel production.ERROR за последние 10 минут: 0.
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>
Разовая artisan-команда supplier:import-projects: усыновляет активные проекты
с crm.bp-gr.ru (lkomega) под тенант info@lkomega.ru по правилам Лидерры
(B1/B2/B3 → один проект, лимит = сумма площадок), без записи на портал.
dry-run по умолчанию, --commit для реальной записи.
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>
SMTP smtp.yandex.ru:465 от verify@liderra.ru работает (MX/SPF/DKIM на reg.ru
подтверждены). SEC-4 «нет MTA» → email-канал появился. NB: фича регистрации
по коду в ветке feat/test-deploy, на боевой сервер кодом ещё не выкачена.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
APP_URL исправлен на боевом (https://liderra.ru + SANCTUM_STATEFUL_DOMAINS apex+www,
конфиг закэширован). §2 отражает факт, §6 — пункт снят, добавлен опц. SESSION_SECURE_COOKIE.
Co-Authored-By: Claude Opus 4.7 <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>
Дмитрий