/pre-deploy — доведи, перш ніж стане незворотним

Головна ідея: «виглядає ок у Chrome» — це НЕ доказ. Доказ — на авторитетному шарі (база, файл, код), а не на видимому.

Золотий порядок (ніколи не навпаки):

deploy на preview/dev → verify на живому URL → ПОТІМ gh pr merge / prod.

Цей скіл зібрано з реальних граблів користувача (157 уроків, 44% — саме про verify). Проходь чеклист вголос: для кожного пункта — або доказ, або чесне «пропускаю бо <причина>».

Крок 0 — застав себе перед деплоєм/мерджем

Якщо збираєшся запустити gh pr merge, vercel --prod, supabase functions deploy, railway up або сказати «готово» — СТОП, пройди кроки нижче. Не мерджити, поки не доведено на проді/preview.

Крок 1 — деплой спершу на preview, не на prod

• Vercel: vercel deploy (без --prod) → отримай preview-URL.
• Prod/merge — тільки після verify (Крок 3).
• Пастка vercel --prod: бере поточну робочу теку, НЕ git-гілку і НЕ комміт. Тому: закоміть зміни ПЕРЕД деплоєм (інакше на проді код, якого нема в git — нема історії для відкату).
• Пастка supabase functions deploy: бере ЛОКАЛЬНУ теку, не git-гілку. Якщо працюєш у worktree/іншій гілці — можеш задеплоїти старий код. Перед деплоєм: grep унікальний маркер твоєї зміни у файлі, що реально деплоїться.

Крок 2 — не вір документам, звіряй код та інфру

Перед тим як реагувати на audit / CLAUDE.md / MEMORY / чийсь опис — перевір, чи це ще правда:

• «Поле/символ мертвий?» → grep по коду (можливо, живий через await import чи динамічний виклик).
• «Використовуємо X (база/хостинг)?» → глянь панель провайдера, не опис проєкту.
• «Задача critical/відкрита?» → перевір сам код/PR, не статус у документі.

Правило: документ — це підказка, код/інфра — істина. (Один раз тут згаяно 1.5 год на «тривоги», яких давно не було.)

Крок 3 — verify на АВТОРИТЕТНОМУ шарі (серце скіла)

«Видалив/змінив на сайті» ≠ «видалив/змінив у ресурсі». Перевіряй згори вниз за типом зміни:

Зміна даних / контенту (фото, ціни, товари, тексти)

• Очима на живому URL (не localhost, не кеш — hard-refresh або інкогніто).
• Порахуй у базі напряму: SELECT count(*) ... — цифра збігається з очікуваною?
• Перевір сам ресурс: файл справді в бакеті? Розмір/дата збігаються? (не лише запис у БД).

Видалення / приховування

• Зникло з UI — і зникло з ресурсу: SELECT не повертає рядок; файл реально видалено з бакета; доступ на рівні БД/проксі закрито (не лише кнопка сховалась).

Нове поле в схемі БД

• Проведено по ВСІХ системах: схема → типи → UI → AI-pipeline → cron/фонові → експорти. (Класична грабля: змінив у 36 місцях, забув 13 cron.)

Edge-функція / бекенд

• grep маркера зміни у задеплоєному коді (див. Крок 1) — на проді справді нова версія?
• Виклич живий ендпоінт (curl/UI) — відповідь та, що очікуєш?

Крок 4 — злови тихі збої

Система часто «приймає» дію, тихо ігнорує і виглядає успішно:

• Запит повернув 0 рядків — це очікувано, чи код думає, що дані є?
• RLS/права не «повертають пусто» замість помилки?
• Немає дубля advisory-lock / гонки check-then-increment? (тут одного разу 2 тижні дві синхронізації тихо блокували одна одну).
• Після зміни: стан ДО і ПІСЛЯ реально різний (assertion), а не «команда не впала».

Крок 5 — кеш може брехати старим станом

Якщо зміна не видно — можливо, це кеш, а не баг. Шари від видимого до істинного: браузер (.next/cache, HTTP, localStorage) → CDN/edge (Vercel, Cloudflare, Supabase) → origin/DB → S3/бакет.

• Перевір на найнижчому доречному шарі (БД/бакет), не лише в браузері.
• Next.js Image / OG-preview / PWA — кешуються окремо, можуть тримати старе фото/прев'ю.

Крок 6 — тільки тепер merge

Усе доведено на preview/prod → gh pr merge. Пропиши явний відкат: комміт/гілка/vercel rollback, до якого вернутись, якщо щось спливе.

Правило скіла

Не рапортуй «готово» без доказу з Кроку 3. Якщо доказ отримати не можеш — скажи прямо: «перевірив на шарі X, шар Y перевіриш ти, бо <причина>». Чесне «не перевірив» краще за впевнене «готово».