Побудувала механізм перевірок репозиторію — 268 зареєстрованих перевірок коміту, 277 правил лінтингу та 15 власних правил ESLint — а також 146 тестів самих перевірок, щоб стандарт тримала збірка, а не код‑рев'ю.

Ситуація. Стандарти, записані в настановах для учасників проєкту, — лише побажання. З ними всі згодні, а потім настає п’ятниця, зміна маленька, і настанови програють. Планка нульових попереджень могла втриматися лише за умови, що її триматиме щось, окрім доброї волі, — а лінтери, що йдуть у комплекті з кожною мовою, далеко не охоплюють специфічних для проєкту правил, які насправді мають значення: тих, що описують, як має працювати саме ця кодова база.

Завдання. Важливі для проєкту правила мали стати виконуваними, щоб порушення будь‑якого з них зупиняло коміт, а не чекало на рецензента, якому вистачить часу й пам’яті це помітити.

Дія. З цього виріс цілий рушій захисних перевірок. Це 274 скрипти перевірок, із них 268 зареєстровано в хуках комітів, а поруч — 277 лінтерів на JavaScript, 96 валідаторів на shell і 17 на Python, які стежать за тим, до чого готовим інструментам байдуже: що міграцію можна відкотити, що ключ перекладу існує в обох локалях, що зареєстрований маршрут є в описі OpenAPI, що ніхто тихцем не придушив попередження прямо в коді. П’ятнадцять власних правил ESLint тримають у TypeScript патерни, прийняті в проєкті. Одне правило варто назвати окремо: будь‑який коміт із префіксом fix: мусить містити тест, який без цього виправлення падає, — тож виправлена вада лишається виправленою. А оскільки зламана перевірка гірша, ніж її відсутність, — вона пропускає все, і ніхто про це не дізнається, — самі перевірки мають 146 власних тестів.

Результат. На рев’ю час тепер іде не на механіку, а на проєктування, бо механічні зауваження машина висловила ще до того, як гілку відправили в репозиторій. Компроміс реальний, і про нього варто сказати прямо: комітити повільно, а погано написана перевірка, яку доводиться обходити, справді доводить до сказу. Ті 146 тестів існують саме тому, що так уже траплялося.