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

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

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

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

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