Активно занимаюсь вайб кодингом.

Есть у меня полка. Туда ложатся правила, за которые я ещё не заплатил собственной болью — потому что мойпринцип гласит: правило рождается из прожитого инцидента, а не из чужой «лучшей практики». Возьмёшь чужое правило, боль от которого не прожил сам, — первым же и найдёшь, как его обойти.

На полке лежало правило с условием срабатывания, записанным дословно:

Первый влитый PR с полностью зелёным чек‑листом DoD — и с абсолютно нерабочим сценарием.

Отложил его пару недель назад с мыслью «когда‑нибудь выстрелит». Выстрелило через два дня после того, как я опубликовал статью про этот метод. Триггер сработал — слово в слово.

Что случилось

PR влит, CI зелёный, все галочки DoD стоят. А сценарий не работает — ни секунды, ни на одном реальном стенде. Каскад из трёх багов, и каждый невидим для CI по построению.

Раз. Модуль читал JSON‑реестр из папки shared/ прямо на импорте, при старте приложения. В CI всё отлично — там полный чекаут кодовой базы, папка на месте. А продовый образ собирается из усечённого контекста, куда shared/ не входит. Контейнер уходил в краш‑луп первым же запуском. И вишенка на торте: CI ни разу не запустил сам образ. Он гонял тесты прямо на хосте. Всё зелёное.

Два. Две миграции влились в один день и получили одинаковую версию. А версия у нас — первичный ключ в таблице применённых миграций. Локальный db reset падал на второй же строке: duplicate key. Колонки в БД просто не создавались. CI и этого не видел — он катит миграции голым циклом psql, без проверки на дубли.

Три — просто следствие: колонок нет, ручки отдают 500.

Каждая проверка честно горела зелёным. При этом любой из трёх багов вскрылся бы с первой же попытки живого человека дёрнуть эндпоинт на поднятом стенде. С одной‑единственной попытки.

Урок в один абзац

Детерминированные проверки видят структуру: тесты на месте, статус проставлен, миграции в списке, линтер молчит. Чего они не видят в принципе — работает ли сценарий в той среде, где реально живёт продукт. Зелёный CI и живое приложение — это два совершенно разных факта. И ровно в зазор между ними и пролез инцидент.

Что теперь

Снял правило с полки. Теперь каждый фичевый PR несёт «свидетельство запуска» — артефакт реального прогона со стенда. curl с телом ответа. Скриншот с работающего стенда, а не из Storybook. Хвост настоящего db reset. Не работает сценарий — свидетельство не приложишь, а значит, и PR не откроешь. Цена вопроса — пять минут.

И сверху жёсткий шаг в CI: собрать образ ровно как для прода (без shared/) и импортировать приложение прямо внутри контейнера. Человек может нарисовать красивый отчёт, так и не подняв стенд. docker build обмануть нельзя. Автоматика не умеет врать — в этом весь смысл.

Ирония судьбы

Правило, о котором я написал статью — «доверь контроль правил роботам, а не инструкциям» — сработало на мне самом. Триггер, отложенный на полку две недели назад, предсказал собственный сбой с точностью до слова. Метод съел свой же корм, а укушенным оказался автор.

И, если честно, это лучшее, что могло случиться. Я записал тот триггер, потому что чуял: зазор между «зелёным CI» и «мёртвым сервисом» рано или поздно меня догонит. Догнал через два дня. Зато теперь я при всём желании не смогу это правило обойти — боль‑то теперь моя, не чужая. А правило, за которое ты не заплатил собственной болью, — это не правило. Это благое намерение с чек‑листом.