Decision gate — це командне рішення
Production decision gate відповідає не на питання «чи написав Claude код», а на питання «чи готова команда прийняти наслідки цієї зміни». Він доповнює тести, CI та review і фіксує відповідального за рішення.
Типовий порядок такий: автор готує diff і докази, локальний review перевіряє зміни, CI запускає детерміновані checks, а команда приймає рішення GO або HOLD з урахуванням ризику, approvals і можливості відкату.
| Етап | Результат |
|---|---|
| Особиста готовність | Автор перевірив вимоги, diff, тести й залишкові ризики |
| Local review | Знайдені або відхилені зауваження до фактичних змін |
| CI / quality gate | Підтверджені автоматичні checks |
| Team decision gate | Командне рішення GO або HOLD і названий approver |
Рівень ризику визначає пакет доказів
Для малого PR gate може бути частиною опису PR або release checklist. Окремий файл виправданий тоді, коли рішення потребує ширшої traceability або повторного використання.
| Категорія | Мінімальний пакет |
|---|---|
| Low-risk | Короткий опис, релевантний diff і фінальне рішення |
| Review-required | Ризик, checks, evidence, потрібні approvals і рішення |
| High-risk | Усе перелічене, а також rollback path, обмеження та конкретні approverʼи |
Risk classification і permissions мають різні ролі
- risk classification визначає суворість процесу та необхідний рівень review;
- permissions технічно обмежують доступні дії Claude або агента;
- decision gate фіксує остаточне людське рішення щодо merge або release;
- міграція бази, auth path або інший новий наслідок вимагають re-classification;
- зниження ризику не можна робити мовчки або лише через поспіх.
Як оформити GO або HOLD
- Назвіть зміну, affected area та початкову risk category.
- Додайте результати local review, CI і staging checks, якщо вони потрібні.
- Зафіксуйте approvals, rollback path і залишкові обмеження.
- Перевірте, що нові наслідки не вимагають re-classification.
- Назвіть відповідального approver і запишіть GO або HOLD.
- Якщо evidence неповний, залиште рішення HOLD до усунення прогалини.
Приклад gate для refund-зміни
Зміна refund flow має high-risk профіль, якщо зачіпає гроші, support roles або audit log. Тоді green CI недостатньо: потрібні regression tests, diff review, staging smoke і approvals від відповідальних власників домену.
Rollback може включати revert, вимкнення feature flag або повернення попереднього handler. Merge варто утримати, доки не завершено перевірки, а фінальне рішення не зафіксував release owner.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush