Cookie-консент и 152-ФЗ на потоке (зонтичный кейс, 6 сайтов)

Контекст и задача

Несколько разных заказчиков заказали одинаковый комплект работ для своих сайтов: cookie-попап, консистентный со стилем сайта; страницы «Политика конфиденциальности» и «Политика обработки ПДн»; чекбоксы согласия со ссылками на политики во всех формах; страница реквизитов оператора ПДн. Базовое требование — соответствие 152-ФЗ (актуальные редакции 2024–2026, ужесточение штрафов), GDPR — как бонус (источник: prompt.md §2, §4).

Особое требование к Задаче 1 (cookie): режим «фиктивный» — UI и хранилище выбора работают, но реальную блокировку сторонних скриптов (GA4 Consent Mode v2, отложенный init Я.Метрики, VK Pixel) заказчик подключает сам поверх документированного JS-API. Зона ответственности исполнителя — UI + хранилище + контракт интеграции; для форм (Задача 3) фиксация факта согласия обязательна (prompt.md §4).

Решение должно быть повторяемым между сайтами, но адаптированным к стилю и стеку каждого: один подход — разная реализация деталей.

Что я сделал

Честное разделение по характеру работ (engagement: mixed):

• Greenfield: разработал с нуля плагин cookie-consent-shim (см. «Решение и подход»). Переиспользуется на всех WordPress-сайтах без правок ядра.
• Greenfield на Bitrix: с нуля реализовал тот же функционал нативно под Bitrix для invest-kbr.ru (компонент, инфоблок, HL-блок, страницы соглашений, чекбоксы в формах) — 17 этапов, двуязычно RU+EN.
• Доработка legacy + интеграция: внедрил баннер, политики, чекбоксы и реквизиты на существующих сайтах заказчиков (per-site брендинг, триггеры в футере, acceptance в формах).
• Аудит: read-only SSH/wp-cli аудит каждого сайта (стек, темы, формы, риски безопасности) перед любыми write-операциями.
• Миграция/devops: HTTPS-миграция idealgraduation.ru (siteurl/home + 56 правок в БД через wp search-replace, правки захардкоженных ссылок в шаблонах), security-hardening (изоляция публично доступных бэкап-архивов, .htaccess deny), фикс существующего JS-бага в родительской теме.
• Контент 152-ФЗ: под каждый сайт — отдельный шаблон политики и согласия, опросник заказчика, ознакомительное письмо с принятыми рисками; юридические формулировки с проверкой источников.

Разбивка по под-проектам (под одним зонтиком):

• eplintus.ru — WordPress, FSE-тема indekor. Плагин v1.0.3, per-site override через child-тему (палитра #262626/#FFF1B2, Montserrat), триггер в FSE footer (template part), CF7 с acceptance, политика опубликована. Технически завершён (HANDOFF, 2026-05-13).
• kidlife05.ru — WordPress, FSE-тема kid-life, мед-направление (Medflex booking). Плагин v1.0.7 (5 итераций фикса CF7-acceptance под Popup Maker), override floating-кнопки Medflex, ACF Options Page «Реквизиты ПДн» + поле лицензии. Завершён.
• idealgraduation.ru — WordPress, классическая PHP-тема ideal (ивенты/выпускные). Per-site override через mu-plugin (не child-тема — урок проекта), inline-CSS/JS-перемещение триггера в .footer-bottom, CF7 ID 10/79/624. Плюс HTTPS-миграция, security pre-flight, фикс бага родительской темы. Завершён.
• invest-kbr.ru — Bitrix 23.x (инвестиции, КБР), reg.ru shared, БД latin1, RU+EN. Компонент investkbr:cookie.banner, инфоблок «Юридические документы» (ID 130, 5 свойств), HL-блок LegalConsentLog, страницы /agreement/ + /en/agreement/ на bitrix:news.detail, чекбоксы согласия в 5 формах через CFormField, override CSS через Asset Manager. 17 этапов, развёрнут.
• homemaster.pro — WordPress (домофоны/ЖКХ, Мурманск). Плагин v1.0.8, mu-plugin брендинга + PHP-helpers (12 CF7-форм), интеграция регистрации wp-recall, модалка обратной связи, соц-иконки. Деплой выполнен («баннер/политика 2.0 в бою»), ожидаются реквизиты получателей и go на финализацию (progress, 04.06.2026).
• novo-wed.ru — WordPress 6.4.4 (свадебное агентство, Москва). Завершён Этап 3: план (1100 строк), wedding-адаптированный шаблон политики, опросник + 22 ответа, research (979 строк), SVG-иконки Telegram/MAX. Реализация на проде — отдельная сессия после go (на момент последнего коммита не подтверждена).

Решение и подход

Ядро — плагин cookie-consent-shim (PHP, namespace CCS, GPL-2.0): singleton-bootstrap, installer (таблицы/опции), frontend (рендер баннера, enqueue), REST-эндпоинт для кастомных форм, admin (настройки + журнал), CRUD журнала согласий, интеграция CF7, шорткоды. Баннер рендерится на клиенте (совместимость с full-page кэшами). Публичный JS-API window.cookieConsent (get/getAll/isAccepted/open/reset/setAll/getMeta) + CustomEvent'ы cookieConsent:ready/change/withdraw/open/close — стабильный контракт, чтобы код заказчика по реальной блокировке не ломался между релизами. Журнал согласий по формам хранит timestamp, версию политики, HMAC-хеш IP/UA. Страница «Реквизиты ПДн» работает на ACF Pro Options Page, а при отсутствии ACF — на нативном Settings API с совместимыми ключами хранения; шорткод [legal field="."] читает оба источника (приоритет ACF → native → default).

Ключевые инженерные решения, выработанные как переиспользуемые паттерны (источник: HANDOFF.md, progress.md):

• Per-site override через mu-plugin (wp_add_inline_style + хук wp_footer), а не child-тему — изолирует код, не меняет body-class, не вызывает регрессий рендера; child-тема допустима только для FSE-тем.
• Для классических тем без template part — рендер триггера в wp_footer + inline-JS перемещает блок в нужный контейнер футера после DOM-ready.
• Управление z-index и перехватом кликов сторонних floating-виджетов через CSS-переменные плагина и точечные override.
• Backup post_content в meta перед каждой правкой Gutenberg-блоков; правка через strpos/substr или WP API, без жадных regex.

На Bitrix то же решение реализовано средствами платформы: миграционные скрипты создают инфоблок и HL-блок, компонент выводит баннер, журнал согласий пишется в HL-блок, формы дорабатываются через API форм Bitrix — то есть единая концепция 152-ФЗ перенесена на другой CMS-стек.

Результат

Подтверждено по источникам:

• 4 сайта доведены до live/сдачи: eplintus.ru, kidlife05.ru, idealgraduation.ru (технически завершены 2026-05-13, HANDOFF.md) и invest-kbr.ru (17 этапов, развёрнут, progress.md).
• homemaster.pro — деплой выполнен, в стадии финализации приёмки (client-docs/homemaster/progress.md, 04.06.2026).
• novo-wed.ru — завершён этап планирования/подготовки контента (client-docs/novo-wed/plan.md).
• Плагин cookie-consent-shim v1.0.8 переиспользован на всех WordPress-сайтах без правок ядра; бюджет производительности соблюдён (3.6 KB JS / 1.8 KB CSS gzip).
• Под каждый сайт подготовлены клиентские деливераблы: отчёт о работах (HTML), опубликованная политика (HTML), опросник, письмо о принятых рисках.

Финальные статусы приёмки на стороне заказчиков (заполнение реквизитов, подписание писем, подключение реальной блокировки скриптов в оговорённый срок) в репозитории не зафиксированы — не зафиксировано (уточнить).

Стек и обоснование

• PHP / WordPress (плагин + mu-plugins + child-themes) — основной стек заказчиков; плагин как переиспользуемое ядро снижает стоимость каждого нового сайта.
• PHP / Bitrix (компоненты, инфоблоки, HL-блоки, API форм) — для invest-kbr.ru, где WordPress-плагин неприменим; то же решение нативными средствами платформы.
• JavaScript (vanilla) — клиентский рендер баннера и публичный JS-API без зависимостей, чтобы не раздувать LCP/CLS и работать поверх любых кэшей.
• Contact Form 7, ACF/SCF — стандарт форм и кастомных полей в экосистеме заказчиков; реализован fallback на нативный Settings API, чтобы не требовать ACF Pro.
• MySQL, REST API — журнал согласий и эндпоинт для кастомных форм.
• SSH / wp-cli, VPS/shared-хостинги (reg.ru, beget, Timeweb) — аудит и деплой; учтены ограничения shared-хостинга (установка wp-cli phar в ~/.local/bin, fail2ban-окна, отсутствие глобального wp-cli).

Роль ИИ в проекте

Проект выполнен в парадигме doc-driven development с Claude Code (мастер-бриф написан для Opus 4.7 max effort, последующие сессии — Opus 4.7/4.8). Артефакты ИИ-процесса в репозитории:

• prompt.md — мастер-бриф (роль, бизнес-контекст, состав работ, поэтапный план; режим «только исследование/аудит/план» до явного go).
• Per-client PROMPT.md / NEXT-SESSION-PROMPT.md — handoff-промпты для передачи контекста между сессиями (контрольные точки git, что прочитать, текущий статус).
• research.md — веб-исследование юридической базы 152-ФЗ с обязательной сверкой источников на дату работ (явно отброшены несуществующие нормативные ссылки).
• tz-analysis.md, site-audit.md — анализ ТЗ заказчика и read-only аудит сайта.
• plan.md (корневой 1972 строки + per-client), policy-template.md, questionnaire.md/-answers.md — план, шаблоны контента, опросники и ответы.
• progress.md — живые трекеры прогресса с журналом решений и блокеров (по явной просьбе заказчика вместо TaskList).

Рабочий цикл: research → audit → plan → (go-gate) → implement, где каждая write-операция на проде выполнялась только после явного go через AskUserQuestion. Для проверок использовался headless Chrome (DOM/screenshots), деплой — через PHP-helpers и SSH. Отдельной конфигурации .claude//субагентов/AGENTS.md в репозитории нет — оркестрация велась через промпт-документы и handoff'ы.

Инженерные вызовы

• Один функционал, три архитектуры тем WordPress (две FSE + одна классическая) и четвёртый стек (Bitrix) — потребовалось выработать платформо-специфичные паттерны интеграции, сохранив единое ядро.
• CF7-acceptance под Popup Maker (kidlife05) — 5 итераций фиксов ширины <label> через двухслойный CSS-override; результат вынесен в base-CSS плагина, на следующих сайтах работает из коробки.
• Темы с <button type="submit"> вместо CF7 [submit] (idealgraduation) — helper ищет оба варианта как якорь вставки.
• Безопасный деплой на shared-хостингах: dry-run search-replace, контроль целостности файлов (sha256/md5) после rsync, backup post_content в meta, проверка php -l/base64 -d перед запуском на проде, учёт fail2ban-окон.
• Bitrix: работа с БД в кодировке latin1, миграционные скрипты для инфоблоков/HL-блоков, двуязычность RU+EN, бэкап с поэлементной sha256-сверкой (11/11) перед стартом.
• Юридическая корректность: каждое нормативное утверждение со ссылкой на источник; обнаружены и исправлены некорректные отсылки в исходных материалах.