name: Validation Checklist перед deploy чужої роботи
description: Перед заливкою в прод — обов'язково діффити vs baseline, curl-тестувати ендпойнти, перевіряти що головний фікс на місці. Не вірити заявам «зроблено по брифу».
type: feedback
originSessionId: c120c8e1-db10-4b48-a8c7-53b2e93524a5
Коли інший агент (Desktop Claude / людина / зовнішня команда) приносить артефакти за моїм брифом — ПЕРЕД green-light на deploy:
- Diff vs baseline.
diff old/file new/file — побачити кожну зміну. Якщо зміна не відповідає брифу — flag.
- Curl-перевірка ендпойнтів. Якщо бриф каже «функція приймає GET» —
curl -i https://endpoint?... і дивитися реальний статус, не «має приймати».
- Перевірка головного фіксу. Якщо корінь проблеми — X, шукати в новому коді саме рядок який чинить X. Якщо не знайшов — це провал, незалежно від кількості інших змін.
- End-to-end на тестовому SID. Стрельнути
?ver=v2-validate&sid=test-XX і за 5 секунд глянути в БД/лог чи реально приземлилось.
Why: 30.04.2026 Сергій приніс v2 Fluvir-банера від Desktop Claude, який зробив усе що я попросив у (обсолетному) брифі: bootBanner(), try/catch, hardcoded cid, <noscript>, ver=v2. Усі 6 пунктів брифу — ✅. Але:
- Головний фікс (CSP/SafeFrame через GET-pixel) не зробив, бо мій бриф його не описав
- Параметр в
<noscript> URL — ?evt=impression замість ?name=. Curl-тест показав: повертає 200+GIF, але в BQ ніц
Якби я не діфнув і не курлнув — Сергій залив би в DV360, gap залишився б 99.9%, і ще кілька днів витрачено даремно.
How to apply:
- Коли користувач каже «дивись, так ок?» з артефактами — НЕ кажи «виглядає добре» без diff + curl.
- Звітуй ✅ і ❌ окремо. Не приховуй проколи в загальному «нормально».
- Якщо знайшов проблему — давай конкретний патч-сниппет, не «треба пошукати щось».
- Сергій через ось такий cycle (я пишу бриф → інший виконує → я валідую) фактично легалізував Variant C (Validation Checklist) з мого ж раніше повідомлення про «варіанти покращення» — це його обраний робочий процес, а не одноразовий епізод.