QA-конвейер заблокировал деплой с 19 нарушениями. И это хорошо

• 19 RED: критичные нарушения, блокируют деплой
• 31 YELLOW: мягкие предупреждения, деплой проходит, но висят как долг
• Статус: BLOCKED. Заливка на FTP физически не запускается
• Время: 11:48:02. Один взгляд в отчёт и сразу понятно где чинить

Самое неприятное и самое полезное. Формулировка «гарантия 4 недели после приёмки» расползлась с описания услуги на 5 страниц: главную, страницу продуктов, страницу проектов «Диспетчер», «Контент-фабрика 50 инфлюенсеров» и в шаблон.

В договоре с клиентом эта фраза на своём месте. Стороны подписали, всё прозрачно. На публичном сайте она нарушает мои собственные правила из §10 SUPER_PROMPT: никаких маркетинговых гарантий результата. Договорная гарантия живёт в документе клиента, а не на странице сайта.

Ещё одна находка: на странице кейса автосервиса в OG-метатеге (служебный тег, который задаёт превью ссылки в соцсетях) торчало имя бренда клиента, которого я обязался не упоминать в публичных коммуникациях. На странице написано «студия автосвета», а в OG сидел реальный бренд. Типичная ситуация: переименовываешь page-title и забываешь про OG, потому что глазами он не виден.

8 итераций pre/post QA-отчётов за один день, с 11:48 до 14:43. Схема одна: правлю файл, запускаю deploy_mwb.py (скрипт публикации), QA-чек либо пропускает, либо снова блокирует с уточнённым отчётом.

Финальный отчёт QA-POST в 14:43:17: статус OK, RED 0, YELLOW 0. С первой попытки до полного OK прошло 2 часа 55 минут. Без автомата это была бы полу-ручная вычитка через grep с неизбежными пропусками или честно написанная статья за 8 часов с привлечением второго человека.

Ценность не в сэкономленном времени на правки. Исчезает тревога «что я там забыл проверить». Когда отчёт говорит OK, он действительно OK по тем правилам, которые в него зашиты.

Главная польза не в том, что скрипт «находит нарушения». Он защищает меня от моей же небрежности: скопировал блок текста с одной страницы на другую и не вспомнил, что внутри была договорная формулировка под конкретного клиента.

Память на «откуда этот блок 3 месяца назад» просто не работает. Скрипт один раз получил список запретов и проверяет его при каждом деплое: без усталости, без «ладно, в этот раз пройдёт».

Это qa_check.py, скрипт на Python ~300 строк. При каждом запуске deploy_mwb.py сначала вызывается run_qa("pre"). Он сканирует все HTML-файлы в _build/content/ и собранные страницы по regex-шаблонам (регулярным выражениям):

• guarantee_result: обещания результата без оговорок (маркетинговые гарантии, не договорные)
• client_brand_leak: имена клиентов из списка обезличенных
• ai_stamp: характерные AI-маркеры в текстах (распиаренные слова-паразиты)
• banned_brand: список финально запрещённых партнёров и брендов

Каждое правило — кортеж из (regex, описание, severity). RED блокирует deploy, YELLOW только предупреждает. Отчёт сохраняется в site/reports/qa-pre-YYYYMMDD-HHMMSS.md и параллельно отправляется в Telegram владельцу. После успешного deploy запускается run_qa("post"): он curl-ит живые URL и проверяет 200 OK.

• Сайт агентства с клиентскими кейсами, NDA или обезличиванием
• Публикуете тексты часто (1+ раз в неделю): что-то упустить реально
• Используете AI для черновиков. Он любит «революционно/бесшовно», их надо отлавливать
• Есть свой свод запретов по тону, брендам, гарантиям. Без машины он не соблюдается
• Работаете один или малой командой, второй человек для вычитки не предусмотрен

Соберу такой QA-контур под ваш сайт за выходные

Пишем список запретов под ваш бренд, вшиваем в pre-deploy hook, настраиваем алерты. После этого деплой проходит через автомат и не пропускает то, что вы не хотите видеть в проде.