Arctic-M — каталог-витрина систем охлаждения ARCTIC

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

Заказчик — официальный российский дистрибьютор бренда ARCTIC (системы охлаждения для ПК: кулеры, СЖО, корпусные вентиляторы, термопасты и термопрокладки, кронштейны, корпуса, серверное охлаждение). Нужен корпоративный сайт-витрина: каталог продукции с фильтрами по категориям, карточки товаров с галереей, 3D-моделями, документами и кнопками покупки на маркетплейсах, новости, раздел дилеров и форма обратной связи. Сайт принципиально не интернет-магазин — покупка происходит на стороне Ozon, Wildberries и Яндекс.Маркета; задача сайта — представить бренд и довести покупателя до маркетплейса, попутно агрегируя оттуда отзывы (CLAUDE.md, arctic-requirements.md, подтверждено живым arctic-m.com).

Исходно имелась готовая статическая вёрстка (arctic/dist/, BEM, Swiper/GLightbox/model-viewer). Требовался перенос её в WordPress «pixel-perfect» с полностью управляемым из админки контентом и нетривиальной товарной логикой (вариации, отзывы).

Что я сделал

Работа смешанная (mixed), единственный исполнитель:

• Greenfield-разработка кастомной темы arctic-m (Classic Theme на базе Underscores): шаблоны главной, каталога, категории с фильтрами, карточки товара, новостей, дилеров, поддержки, поиска, 404; перенос BEM-вёрстки без модификации классов.
• Каталог без WooCommerce: CPT product/dealer/news/inquiry, иерархическая таксономия product_cat, динамические фильтр-атрибуты pa_{slug}, генерируемые из SCF options-страницы (с transient-кэшем).
• Система вариаций товара (гибридная) и отзывы по вариациям (v1.4.0) — ключевая инженерная фича (см. ниже).
• Кастомный плагин arctic-marketplaces для агрегации отзывов из Ozon/WB/Я.Маркет API.
• SCF-аудит архитектуры полей (15 групп, ~132 поля) — несколько итераций audit→fix→review, с устранением рассинхрона «поле ↔ шаблон».
• DevOps/деплой: сравнительное research-исследование (Docker vs simple), развёртывание тестового VPS arctic.sandk.tech, затем hard-cutover миграция на прод arctic-m.com (shared-хостинг hostland.ru) с настройкой SMTP, cron, бэкапов и smoke-тестами.
• Поддержка/итерации: серия версионированных доработок по фидбэку заказчика (v1.4.x), оформленных HTML-отчётами.

Честно: исходная статическая вёрстка существовала до меня (авторство уточняется); моя зона — WP-интеграция, вся динамика, бэкенд, плагин, инфраструктура и деплой.

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

Архитектура каталога. Сознательный отказ от WooCommerce (избыточен для витрины без корзины) в пользу CPT + SCF; фильтрация реализована через кастомные таксономии и tax_query, а не meta_query — выбор обоснован в research как способ избежать медленных JOIN по wp_postmeta (CLAUDE.md/STACK).

Вариации товара (гибрид). SCF-репитер даёт удобное редактирование в админке, а при сохранении хук arctic_sync_variations_to_table (priority 20, после записи метаданных SCF) синхронизирует данные в кастомную таблицу wp_arctic_product_variations с индексами по (product_id, sort_order), (product_id, is_default), (product_id, slug) — для быстрых фронтенд-запросов. Каждая вариация несёт собственную галерею, переопределения характеристик, ссылки и идентификаторы маркетплейсов (ozon_product_id, wb_article, ym_sku). Запись в таблицу — в транзакции, с генерацией уникальных слагов и гарантией единственного default.

Отзывы по вариациям (v1.4.0). Отзывы из Ozon/WB/Я.Маркет складываются в wp_arctic_reviews (UNIQUE (marketplace, external_review_id) для upsert), сводная статистика — по паре «вариация + маркетплейс». На карточке при переключении вариации блок отзывов перезагружается через AJAX (arctic_load_reviews_tab) без перезагрузки страницы, с отменой устаревших запросов при частых кликах, сохранением активной вкладки маркетплейса и переинициализацией галереи/лайтбокса. Schema.org aggregateRating считается как взвешенное среднее по всем вариациям и маркетплейсам — для rich snippets в Google/Яндексе. Особый случай Ozon: API не отдаёт отзывы по конкретной вариации, поэтому забирается вся лента продавца и разбирается по SKU на стороне сайта.

Безопасность. Формы и AJAX — с nonce и проверками; per-IP rate-limit (60 req/min, CGNAT-толерантный) на загрузку отзывов; сквозные sanitize_*/esc_*; API-ключи маркетплейсов хранятся через класс шифрования плагина. Соблюдение WPCS.

Результат

• Сайт развёрнут и работает в проде: https://arctic-m.com/ подтверждённо отдаёт каталог, карточки, REST и sitemap; WordPress-платформа, ссылки на Ozon/WB/Я.Маркет присутствуют (WebFetch).
• Hard-cutover миграция test→prod: downtime ~17 мин, перенесено 1.3 GB / 5142 файла uploads, 53 таблицы, 232 URL-замены, 7/7 smoke-тестов OK, настроены SMTP (FluentSMTP) и WP-Cron (arctic-deploy-arctic-m-com-report.html).
• Per-variation отзывы: 65 товаров с отзывами по вариациям, ~116 000 отзывов учтено в SEO-рейтинге каталога, 91% отзывов в БД привязано к конкретной вариации после пересинка; устранён баг перезаписи отзывов Ozon (arctic-per-variation-reviews-report.html).
• Бизнес-эффект «звёздочек» в выдаче (rich snippets) на момент отчётов — ожидаемый, но не зафиксирован замером (поисковикам нужна переиндексация 2–3 недели) — уточнить у автора.

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

• WordPress 6.9.4 + PHP 8.0+/8.4, Classic Theme (Underscores) — максимальный контроль для pixel-perfect переноса; Block Theme/FSE отклонён.
• SCF (Secure Custom Fields) вместо ACF — по требованию заказчика; репитеры/опшн-страницы.
• Без WooCommerce — витрина без корзины; каталог на CPT + кастомных таксономиях.
• Кастомная таблица для вариаций — производительность фронтенд-запросов вместо тяжёлого meta_query.
• Vanilla CSS + нативные ES-модули вместо Vite — осознанный отказ от сборщика (коммит «replace Vite with vanilla asset pipeline») ради принципа «SFTP → сайт работает» и моментальных правок; обосновано в SIMPLE-DEPLOY-RESEARCH.
• Инфраструктура: тест — VPS (Ubuntu, MariaDB, Redis, nginx/PHP-FPM); прод — shared hostland.ru (MySQL 8.0, PHP 8.4, без Redis), адаптация конфигурации под ограничения тарифа.
• Маркетплейс-API: Ozon Seller API, Wildberries Feedbacks API, Yandex Market Partner API; cron-синхронизация, логирование, graceful degradation на кэш при недоступности API, rate-limit (пауза 0.25 c).

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

Проект — показательный пример AI-augmented разработки (Claude Code) с дисциплиной doc-driven dev:

• Оркестрация через GSD (gsd-pi): milestones/slices/tasks, авто-коммиты (chore(M001/S01):.), журнал решений (.gsd/DECISIONS.md), метрики; обязательный RESEARCH перед каждым этапом.
• CLAUDE.md как контекст-инжиниринг: senior-WP-персона, зафиксированный стек, жёсткие ограничения (не WooCommerce, не ACF, не Block Theme, не менять BEM, префикс arctic_), целевая структура темы, требования к безопасности.
• Библиотека структурированных промптов под конкретные задачи и циклы: prompt-scf-audit*.md → prompt-scf-fix.md → prompt-scf-review.md (полный цикл research→audit→implement→review для SCF, несколько итераций/волн P0–P3 на ветке milestone/M001); prompt-variations-plan.md (план гибридной системы вариаций); prompt-wordpress-docker.md vs prompt-wordpress-simple.md (параллельный сравнительный research деплоя, ~80+ веб-запросов); prompt-client-feedback.md, prompt-admin-docs.md.
• Артефакты-отчёты: каждый релиз/доработка оформлены как HTML-отчёт (деплой, per-variation reviews, post-release fixes v1.4.2, video-fix, variant-fallback) — трассируемость работы.

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

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

• Гонка/перезапись отзязей Ozon: при синке товара с несколькими вариациями каждая следующая затирала предыдущую (отзывы хранились на уровне товара, не вариации). Решение: привязка отзыва к SKU вариации, ограничение удаления собственным SKU, отдельная сводная строка на пару «вариация+маркетплейс», временная страховка от удаления на период миграции.
• Мгновенное переключение вариаций без «миганий»: AJAX-перерисовка блока отзывов с отменой устаревших запросов, сохранением вкладки маркетплейса и переинициализацией лайтбоксов.
• Корректный агрегированный рейтинг для SEO: взвешенная формула по всем вариациям и трём маркетплейсам, публикация JSON-LD только при наличии оценок (требование Schema.org).
• Различие сред test↔prod: уход с рут-VPS (Redis, system cron, unix-socket) на shared-хостинг (нестандартный порт БД 127.0.0.1:3308, отсутствие Redis/cron-панели, переключение PHP 7.4→8.4) — точечная адаптация конфигурации, удаление висячих зависимостей плагинов, schema-only перенос таблиц Action Scheduler, атомарный mv-switch с планом отката (snapshot www_old).
• Производительность фильтрации каталога: таксономии + tax_query + transient-кэш реестра атрибутов вместо медленных meta-JOIN.