Раздел карты C1 «Маркетинг и лидогенерация» (пустой) — подбор 10 узлов
#74–#83 (8 ставим сейчас + 2 DEFERRED), 18-я off-phase подкатегория
marketing-tooling. Вариант Б, смешанный акцент, VK вне scope.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
После A8-эпика 21.05 (#68-73 ZAP/Nuclei/Ward + pdn-152fz/threat-model/security-
go-live) у наблюдателя был пробел: classification-map не содержал security-
категории. Реальный classifier (за май) выдаёт 10 значений (refactor/bugfix/
feature/planning/memory-sync/monitoring/other/cleanup/question/docs) — нет
security. Поэтому missed-activations matcher НИКОГДА не рекомендовал A8-узлы
и не мог флагнуть их пропуск. Заказчик подтвердил выбор «А — расширить».
Добавлено:
- "security": ["#73","#69","#68","#70","#71","#72"] — #73 security-go-live
как orchestrator первый, далее CLI-инструменты #69/#68/#70, затем skill-
audit #71/#72. Порядок — порядок приоритета рекомендации.
Описание расширено: классификатор не имеет жёстко прописанного enum
(brain-retro-analyzer.mjs:166 — это free judgment Claude'а при записи
эпизода), добавление ключа в map делает его 'blessed'. Граница: "security"
= задачи где ЦЕЛЬ верификация/улучшение безопасности (сканы/hardening/
аудиты/STRIDE/go-live); НЕ для bug-fix'ов в security-relevant коде (те
остаются "bugfix").
Smoke: JSON валиден, vitest 9/9 passing — matcher работает с новым ключом.
Связано: Pravila §16.4 (conditional rule), project_a8_infosec, A8 install-
sync 21.05 push 61655dc. Тулинг: tools/brain-retro-analyzer.mjs (читает),
tools/missed-activations.mjs (matcher), tools/observer-coverage-checker.mjs
(C5 surface в STATUS.md).
LEFTHOOK_EXCLUDE=adr-judge: то же, что dd9d1f3/cd7e82b/16a575b7 (ReDoS).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
После A8-эпика 21.05 (Tooling v2.20 +6 узлов #68-73 infosec-tooling) lefthook
job 'extract-node-dormancy' не запустился (стейджились data.js A8-эпика,
glob job — docs/Tooling_v8_3.md → расходимость стейджа vs реальные правки).
.node-dormancy.json остался с 67 узлами, A8 узлы #68-73 отсутствовали.
Эффект для missed-activations matcher (Pravila §16.4): A8-узлы не считались
«доступными» при оценке missed-activation — но и не считались dormant.
Просто отсутствовали в словаре → matcher НЕ мог рекомендовать их (даже если
бы classification-map содержал security-категорию).
Регенерация вручную через `node tools/extract-node-dormancy.mjs`:
- Все 6 A8-узлов добавлены: #68/#69/#70/#71/#72/#73 = false (active).
- ZAP (#68) и Ward (#70) — false после A8 install-sync 21.05
(Tooling §4.43/§4.45 dormant true→false уже было синкнуто).
- Всего 73 узла (было 67) — паритет с Tooling §0 канон.
Связано: project_a8_infosec.md, project_automation_map.md.
LEFTHOOK_EXCLUDE=adr-judge: то же, что dd9d1f3/cd7e82b (ReDoS-обход).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Follow-up к 8530144 (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: то же, что dd9d1f3/8530144 (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: то же, что в dd9d1f3 (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 95b0ebb).
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>
Дмитрий