GEHWOL.MARKET — доработки интернет-магазина (152-ФЗ + задачи заказчика)

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

Заказчик (ИП Киселёва А.А., единый оператор сети из 13 региональных витрин на gehwol.market — Ростов-на-Дону + 12 поддоменов) прислал пакет из 7 задач (позже +1) по приведению магазина к 152-ФЗ редакции 2026 и сопутствующим улучшениям контента/коммуникаций. Исходное состояние (по аудиту): ocStore 3.0.2.0, тема revolution, PHP 7.3 (EOL), хостинг Reg.ru shared с историей блокировки db_block за перегрузку MySQL, активный обмен с 1С. Ключевые проблемы: преотмеченные чекбоксы согласия во всех формах (прямое нарушение 152-ФЗ), отсутствие отдельного «Согласия на обработку ПДн» и «Оферты», устаревшая «Политика», «вечная ошибка» капчи, отсутствие FAQ и иконок мессенджеров, неуправляемый cookie-информер. Бизнес-драйвер — оборотные штрафы по КоАП 13.11 (ред. 2025) и риск ФАС по отзывам.

Что я сделал

Единственный исполнитель полного цикла. Честная разбивка по характеру работ (engagement: mixed):

• Аудит (read-only): инвентаризация стека, форм, согласий, капчи, инфо-страниц, подвала, отзывов, объёма категорий — по коду и БД через SSH, бережно к MySQL (точечные SELECT с LIMIT, без тяжёлых дампов). Зафиксированы расхождения локальной копии (2021) и прода.
• Веб-исследование актуальной нормативки на дату 03.06.2026 (152-ФЗ ред. 24.06.2025, отдельное согласие с 01.09.2025, запрет преотметки, оборотные штрафы; ФЗ-168 о русском языке; риски ФАС по «омоложению» отзывов; статус FAQ rich results и польза JSON-LD для AI-выдачи; MAX/Telegram/WhatsApp).
• План и опросник: детальный план по 8 задачам со скелетами OCmod/Twig/SQL, оценкой трудозатрат (~79/116/158 ч), рисками и rollback; интерактивный сбор ответов заказчика.
• Реализация (доработка legacy, после «go»): 152-ФЗ-согласия (9 форм), 3 юр.документа в подвал, актуализация Политики, лог согласий, кастомный FAQ-модуль с 234 Q&A, починка reCAPTCHA, модуль мессенджеров с админ-UI, cookie-консент, обновление дат отзывов (тест-превью с письменной оговоркой о юр.риске).
• Деплой и приёмка: установка через OCmod Refresh, бэкап + rollback на каждый шаг, верификация на Ростове + 2–13 сторах, контроль error.log.
• Контент и юр.тексты: написал Согласие, Оферту, переписал Политику (HTML-фрагменты под инфо-страницы); 234 FAQ Q&A с медицинскими оговорками; клиентские deliverable-отчёты и инструкцию по управлению модулями из админки.

Не выдаётся за greenfield: это аудит + доработка существующего legacy-магазина и контентная работа.

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

• Архитектура внедрения: единый OCmod-пакет gehwol_compliance (правки шаблонов/контроллеров) + три кастомных модуля (gehwol_faq, gehwol_messengers, gehwol_cookie), каждый со своим *.ocmod.xml. Принцип — не трогать vendor-ядро OpenCart; правки переживают обновления и легко откатываются (удалить XML → Refresh).
• 152-ФЗ-согласия (задача 3): снятие checked через position="replace", серверная валидация (включая добор недостающей проверки agree_pol_konf в контроллере predzakaz), новая таблица oc_consent_log с индексами и приватной моделью (SHA-256-хеши IP/UA/контакта с фиксированной солью вместо сырых ПДн; запись обёрнута в try/catch — сбой лога не ломает форму; один лёгкий INSERT — бережно к db_block).
• FAQ (задача 7): модуль admin+catalog, таблицы oc_gehwol_faq/_description с индексом по target, кэширование выборки (1 индексированный SELECT из кэша на страницу), рендер через 4 OCmod-инъекции (home/category controller+twig), аккордеон W3C ARIA + FAQPage JSON-LD; контент-конвейер: Markdown-черновики → локальный парсер tools/parse_faq.php → идемпотентный CLI-импортёр.
• Мессенджеры (задача 5): настройки в oc_setting (store 0), чтение из реестра config → 0 запросов к БД на рендер; inline-SVG, тумблеры мест (шапка/подвал/контакты), управление из админки.
• Cookie (задача 8): порт эталона cookie-multi (WordPress → OpenCart): 2 статических ассета (vanilla JS без jQuery + CSS), одна OCmod-вставка в header.twig, localStorage с TTL и версионированием, публичный контракт window.cookieConsent + события; «фиктивный» режим (UI + хранилище, реальную блокировку заказчик подключает по переданному README).
• Капча (задача 6б): эмпирическая диагностика (зонды api2/anchor, контрольный v2-ключ) → корневая причина «Invalid key type» = ключ v3 при v2-виджете; перевод темы на v3 invisible + бэкенд-проверка score≥0.3 с логом для тюнинга.
• Нетривиальные находки темы revolution (задокументированы в проектную память): подвал store 0 рендерится из таблицы oc_theme, а не из файла/OCmod → правки в двух местах; языковые строки грузятся через storage/modification → нужен Refresh + сброс OPcache; инвертированное поле noindex; построчный поиск движка OCmod (многострочные anchor не срабатывают, смещение через offset).

Результат

• 8/8 задач закрыты по реализации на живом сайте (по cookie — ручная приёмка пользователем pending). Источник: progress.md, prompt-next-session.md §7.
• Подтверждено независимо (WebFetch публичной главной gehwol.market): в подвале выведены 3 юр.документа — «Политика конфиденциальности», «Согласие на обработку персональных данных», «Публичная оферта» — то есть результат задач 1–2 виден на проде.
• 234 FAQ Q&A внедрены и редактируются из админки; 9 форм приведены к 152-ФЗ с доказательным логом; reCAPTCHA принята реальным сабмитом (success=1 score=0.9); блок мессенджеров и cookie-консент работают на всех 13 сторах (progress.md §5.0-octies/nonies).
• Каждый шаг — с бэкапом и инструкцией отката; error.log без новых ошибок; верификация на Ростове + Краснодаре + Грозном (и полный свип 13–14 витрин для мессенджеров/cookie).
• Числа трудозатрат (~79/116/158 ч) — это плановая оценка, не подтверждённый факт по таймтрекингу. Прочие эффекты (конверсия, трафик, штрафы) в артефактах не зафиксированы — не зафиксировано (уточнить).

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

PHP 7.3-совместимый код (апгрейд PHP заказчик отложил) на OpenCart/ocStore 3.0.2.0 + Twig. OCmod выбран как способ внедрения, переживающий обновления ядра/темы и легко откатываемый; кастомные модули (admin+catalog MVC-L) — там, где нужны хранение и управление из админки (FAQ, мессенджеры). MySQL с обязательными индексами и кэшированием выборок — из-за истории db_block. Vanilla JS для cookie (без зависимостей, минимальная поверхность, CLS=0). reCAPTCHA v3 invisible — по решению заказчика чинить Google, а не переходить на Yandex SmartCaptcha. JSON-LD (FAQPage) — под AI-выдачу и Яндекс, несмотря на сворачивание FAQ rich results в Google.

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

Проект целиком выполнен в режиме AI-augmented разработки на Claude Code (Claude Opus 4.8, 1M context, xhigh/max effort) — это явно зафиксировано в артефактах:

• Промпт-инжиниринг постановки: docs/prompts/prompt-gehwol-152fz-audit-plan.md — развёрнутая ролевая постановка (senior OpenCart-инженер + эксперт по 152-ФЗ), поэтапный алгоритм (research → read-only audit → plan), жёсткие гард-рейлы (никаких записей до «go», бережно к БД, не выносить секреты), формат итогового документа.
• Doc-driven development: журнал docs/reports/progress.md + стартовая выжимка docs/prompts/prompt-next-session.md для преемственности между сессиями (протокол обновления в конце каждой сессии); план в .claude/plans/ (упоминается hidden-fluttering-sun.md).
• Проектная память Claude Code как способ накопления нетривиальных находок: gehwol-revolution-rendering-quirks, gehwol-php-cli-vs-web-env (урок «CLI ≠ web-FPM»).
• Инструменты агента: WebSearch/WebFetch (сверка нормативки на конкретную дату с источниками), Bash/SSH (read-only аудит кода и БД), TaskCreate/TaskUpdate, headless-Chrome смоук-тесты.
• Перенос методологии из соседнего проекта cookie-multi (эталон глубины по 152-ФЗ и cookie-консенту; адаптация WordPress → OpenCart). Цикл research→audit→plan→implement с подтверждением каждого утверждения ссылкой на файл/команду — сквозной принцип всего кейса.

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

• Legacy на shared-хостинге с историей db_block: все решения проектировались под минимум запросов (кэш, индексы, чтение из реестра config, лёгкие INSERT), правки БД — только с бэкапом и вне пик.
• Мультистор из 13 витрин на одной теме: правки шаблона применяются ко всем сразу, но контент/настройки различаются по store_id; добавляла сложности скрытая подмена подвала store 0 через таблицу oc_theme (правки в двух местах).
• Среда рендера revolution: языковые строки и шаблоны грузятся через storage/modification → правка оригинала невидима без Refresh + сброса OPcache; построчный движок OCmod не видит многострочные anchor.
• CLI ≠ web-FPM: первая гипотеза бага капчи (allow_url_fopen=Off) была построена на SSH-CLI и оказалась ложной; реальный веб-FPM имеет другие возможности — достоверно проверяемо только разовым webroot-скриптом по HTTPS.
• Юридические компромиссы: «омоложение» дат отзывов (задача 4) выполнено как тест-превью по прямому указанию заказчика с письменной оговоркой о риске ФАС и инструкцией отката из бэкапа — вместо того чтобы молча выполнить или отказать.
• PHP 7.3-совместимость без современного синтаксиса при сохранении читаемости и безопасности.