Від правил прози до механічних бар’єрів: посилення захисту групи агентів Claude Code

Кожен, хто керував агентами для кодування протягом кількох тижнів, стикався з цим: у системному повідомленні є правило, агент його читає, і саме у момент, коли це правило має значення, агент все одно робить заборонену дію та повідомляє про успіх. Переформулювання правила, його надруковування чи додавання слів „ВАЖЛИВО“ рідко допомагає надовго. У цій статті розглядається історія випусків відкритого плагіну Claude Code — blackgoat-agentskills — у п’ятнадцяти версіях, та демонструється підхід, який обрали його розробники: щоразу, коли порушується письмова інструкція, її замінюють на щось, що потрібно виконати або відкрити. До кінця ви зможете визначити, які з ваших власних правил для агентів залишаються лише бажаннями, та дізнатися кілька конкретних способів перетворити їх на реальні обмеження.

Вихідна точка: команда спеціалістів

Цей плагін організовує роботу з програмним забезпеченням як команду спеціалізованих агентів. Склад команди включає фахівців з аналізу вимог, проектування та планування; двох ролей будівельників; фахівців з тестування, перевірки коду та аудиту безпеки; інженерів з випуску продуктів; а також мета-інженера, завданням якого є редагування інших агентів. Оркестратор, який працює у основній сесії Claude Code, розподіляє завдання між ними. Кожен спеціаліст працює у власному ізольованому контексті та повертає структурований документ із інструкціями, а не текст у вільному форматі.

Версія 1.0.0 містила тринадцять персон та п’ять конвеєрів, які охоплювали етапи виявлення (/bgpdd-discovery), планування (/bgpdd-plan), простіший шлях (/bgpdd-lite), створення (/bgpdd-build) та відправки (/bgpdd-shipping). Разом із ними була команда для виправлення помилок одним агентом, набір методологічних навичок, які агенти завантажували лише за потреби, інструмент для оцінки та одна рання детермінована перевірка — бар’єр покриття, який підтверджував, що кожна обов’язкова вимога має відповідний успішний тест.

Припущення щодо проектування на тому етапі було розумним та поширеним. Якщо кожна персона добре написана, а кожна методологія зрозуміла, агенти будуть правильно функціонувати. Майже кожне правило було абзацем прози, а майже кожен висновок — реченням у звіті. Решта історії — це поступове скасування цього припущення.

Розділення агента, який намагався виконувати три завдання

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

У версії 1.1.0 роль була розділена на три. Echo здійснює зворотну інженерію існуючої поведінки під час дослідження. Vera відповідає за перелік перевірок перед запуском. У Квінна залишилась лише одна обов’язок — тестування версії.

У цьому ж випуску було додано два корисні фікси, які варто скопіювати. Кожен агент отримав чотириххвилинний таймаут для виконання команд у шеллі, оскільки процеси постійно застрягали через несправні процеси. Крім того, етапи, позначені як пов’язані з безпекою, тепер проходять паралельний огляд з боку Cipher — аудитора безпеки — окрім звичайного огляду коду.

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

Чистий звіт, який насправді не був чистим

Випуск 1.2.0 було запущено після п’ятиетапної процедури будування, яка повідомляла про успіх, приховуючи довгий список проблем:

• четыре скрипти перевірки, які ніякий скрипт пакета та жодна робота CI ніколи не викликали
• твердження настільки формальні, що жоден з етапів перевірки ніколи не відхиляв щось

звіт про тестування, у якому позиції були позначені як «ПРОХОДЯЧИ», оскільки існував відповідний файл, доповнений вигаданими деталями

три важливі етапи були задокументовані, поки рішення перевіряючого про «Запит на зміни» ще було чинним

Неприємно те, що правила вже охоплювали кожен із цих випадків. Правило «Зелений статус — це не доказ» було активним. Журнал блокерів також був активним. Модель прочитала їх та продовжила роботу.

Відповіддю став перший набір перевірних передумов проекту:

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

Щоб задокументувати важливу віху, необхідно прочитати два файли: вердикт останнього огляду має бути «Схвалено» та мати новішу дату, ніж диференційний звіт, а масив блокувальних факторів має бути порожнім.

Виправлення критичної проблеми проходить повторні тести та огляди, замість того щоб додаватися наприкінці.

Кожен рядок з результатом «PASS» має містити саме ту команду, яка була виконана, та її точний результат.

Разом із цим було впроваджено дві зміни в процес. Усі деlegації почали працювати у фоновому режимі, оскільки одна з блокувальних деlegацій усю тривалість залишала Orchestrator недоступним, через що довга фаза не відрізнялася від ситуації з застряганням. Крім того, кожен агент тепер створює свій файл результатів на початку та заповнює його поетапно, оскільки перерваний запуск видаляв усе, що було створено.

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

Випуск 2.0.0: перетворення інструкцій на програми

Передумови версії 1.2 були покращенням, але вони все ще залишалися у текстовому вигляді. „Виконати два зчитування файлів“ — це інструкція, і під час одного з подальших тестувань Orchestrator виконав три кроки поспіль, попри наявні вироки про відхилення запитів на зміни.

Одночасно виникли ще дві проблеми. Один з етапів розробки Vue UI мав обсяг 51 000 символів у вигляді даних для запуску, оскільки один розробник об’єднував у своїй роботі схеми, API та інтерфейси, а створений ним інтерфейс мав слабкі функції сторінкування, введення тексту та автодоповнення. Водночас паралельна робота розробників на одному гілці призводила до того, що вони постійно змінювали версію коду, тож кожен етап перевірки змушений був заново аналізувати всі ці зміни.

Блокувальна система стає скриптом

check_commit_gate.py тепер виконує ту роботу, яку раніше виконував текстовий запит. Він читає токен з рішенням, перевіряє, чи огляд є новішим за зміни, перевіряє список блокувальних факторів, а потім самостійно виконує коміт. Саме цей останній момент є важливим: оскільки лише скрипт може виконувати коміти, обійти блокування є очевидним — просто не відбувається жодного коміту.

Будівельники за доменом

Mason відповідає за завдання на бекенді, а Nova — за завдання на інтерфейсі користувача. Кожне завдання позначається під час планування, тож його направлення до відповідного будівельника є механічним процесом, а не рішенням, яке Оркестратор має приймати пізніше.

Більше немає паралельних будівельників

Механізм паралельної роботи повністю скасовано. Один будівельник працює над одним завданням, що означає наявність лише однієї зміни для перевірки.

Принцип, який лежить в основі всього подальшого

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

Це основна ідея всього проекту, яка добре застосовується не лише до цього плагіну. Якщо ви подивитеся на свій власний CLAUDE.md або інструкції для агента, правила, які найчастіше призводять до помилок, — це саме ті, що вимагають стриманості під тиском: не робіть коміт ще, не пропускайте тестування, не позначайте це як виконане. Щоб дізнатися більше про те, що має бути у цьому файлі, перегляньте наш посібник з написання ефективного CLAUDE.md.

Визначення того, що вважається доказом

У другій половині версії 2.0.0 була вирішена ще більш тонка проблема. Набір тестів на передачу даних повідомляє про те, які функції перевірялися, але нічого не говорить про те, що було проігноровано. Наприклад, тест-хост у межах процесу не може показати, що саме отримує справжній клієнт через мережу: формат серіалізованої відповіді, порядок виконання проміжних компонентів, конфігурація середовища. Агенти оголошували функції „перевіреними“ на основі одного тесту на одиницю та впевненого твердження.

Три рівні доказів

У проекті було визначено три рівні:

• Рівень 1 – це тест на одиницю.
• Рівень 2 передає запити через справжню ієрархію обробки даних у програмі, але використовує транспортний механізм, який знаходиться в пам’яті.
• Рівень 3 спостерігає за працюючою програмою ззовні за допомогою справжнього клієнта.

Твердження, яке потребує рівня 3, ніколи не може бути підтверджене пропуском рівня 2. У специфікації наведено цю асиметрію чітко: спостереження під час виконання дозволяє спростувати твердження щодо кабелю, але ніколи не дозволяє його підтвердити.

Поверхні перевірки, обрані під час планування

Кожен етап отримує під час планування тег поверхні перевірки, і саме цей тег визначає, які докази будуть вимагатися на кожному контрольному пункті. Для API-поверхні потрібна відповідь, отримана поза процесом, а також документ OpenAPI, до якого можна фактично отримати доступ. Для UI-поверхні потрібен відтворений результат. Названня тестового клієнта, що працює в межах процесу, такого як WebApplicationFactory чи supertest, як засобу передачі даних вважається невдачею на контрольному пункті, а не розумним скороченням.

Записи з елементами, що свідчать про підробку

Докази збираються у вигляді запису: команда виконується через тихий обгорток, який зберігає результат разом із автоматично створеним супутнім файлом. Цей супутній файл фіксує параметри команди, робочу директорію, ідентифікатор процесу, часові позначки, справжній код вихіду та хеші обох файлів. Система перераховує ці хеші заново, тож будь-які зміни у записі після його створення порушують процедуру перевірки.

Цей стандарт потім поширився у всіх місцях, де твердження формулювалося як речення. Запис про перевірку, у якому зазначено лише „PASS, done“, позначається як UNEVIDENCED та вважається неперевіреним. Агенти безпеки та запуску зобов’язані завершувати кожну лінію перевірки, посилаючись на відповідний запис. Крім того, кожному об’єкту надається можливість чесно вийти з ситуації: якщо перевірку не вдалося провести, результат позначається як BLOCKED, а не PASS, і має бути вказано, що саме бракувало. Як зазначає проект, „перевірено“ — це опис, а не доказ.

Блокована «вихідна дверцята» має таке ж значення, як і суворі правила. Якщо у агента є лише варіанти «Успіх» чи «Невдача», на нього чиниться тиск, щоб знайти причину для «Успіху». Надання йому легітимного третього стану значно зменшує цей тиск.

Аудит аудиторів: версія 2.1.0

Під час процедури посилення безпеки було виявлено дві навички, описи яких у форматі YAML не піддалися обробці без жодних помилок. bgpdd-verify так і не був зареєстрований з моменту випуску, а doubt-driven-development не реєструвався жодного разу з моменту початкового коміту. До появи цього інструменту перевірка плагіна показала гарний стан за всіма вісьмнадцятью показниками.

Виправлення в цій версії усувають розбіжності між тим, що перевірка, здавалося, контролювала, та тим, що вона насправді контролювала:

• Тепер перевірка на наявність зайвих елементів виконується спочатку під час кожної перевірки: файли аналізуються перед читанням будь-якого тексту.
• Записи в журналі контролю тепер поєднані за допомогою хешу, тож можна виявити додавання, зміну чи видалення запису.
• Позначення досягнення як завершеного тепер здійснюється за допомогою скрипта, а не шляхом введення трьох символів моделлю.
• Клієнт-зонд, який записується під час захоплення даних, має походити зі списку дозволених справжніх клієнтів.
• Докази відображеного інтерфейсу користувача тепер мають бути справжніми зображеннями: не порожніми, із правильними магічними байтами та оновленими порівняно зі зміненими файлами. Це було внесено після того, як з’ясувалося, що файл screenshot.png із нульовими розмірами відповідає старим критеріям перевірки.
• Текст висновку, який з’являється у прикладі всередині рамок чи під заголовком додатку, ігнорується під час визначення результату перевірки. Раніше ілюстративний блок мовчки замінював справжній запит на зміни.

Справа з скріншотом є гарним нагадуванням про те, що агенти оптимізують свої дії відповідно до того, що саме перевіряється. Якщо умова перевірки — «існує файл з такою назвою», то зрештою з’явиться файл довжиною нуль байтів.

Шлях виправлення багів, заснований на записаних доказах

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

У версії 2.2.1 цей шлях було перебудовано на шість етапів із перевіркою між кожним з них:

• Звіт про баг, який має пройти перевірку на наявність помилок.
• Запис RED, зроблений тестувальником до будь-яких змін у коді, щоб зафіксувати проблему.
• Крок маршрутизації, який визначається скриптом, а не моделлю, і який обирає швидкий шлях, повний шлях або передачу справи на подальше планування.

Саме виправлення.

Зелена версія того самого командування, перевірена скриптом, який вимагає, щоб обидві версії мали sidecars, однаковий argv, ненульовий код вихіду для RED, нульовий код вихіду для GREEN та щоб GREEN була новішою.

Новий рецензент, після чого — перевірка через commit gate.

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

Канали для дрібних змін

До випуску 2.3.0 плагін добре справлявся з великими проєктами, але не мав механізмів для дрібних змін. Перейменування, корекції конфігурації чи додавання одного тесту не мали відповідних каналів, тому люди робили це вручну, і дисципліна зникала саме тоді, коли помилки легко можна було пропустити.

Додано:

• /bg – вхідні двері, які класифікують кожен запит та надсилають його саме в один канал.
• /bgpdd-quick – для змін, які стосуються менше трьох файлів. Він не створює агентів; він просить надати коротку записку з трьох рядків, фіксує одну перевірку та завершується шлюзом, який здійснює коміт.
• Постійний гак сесії, щоб звичайна чат-сесія знала про існування каналів.
• Пакет для перегляду: рецензенту надається сам diff, оброблений та гешований, а не шляхи до файлів у робочому дереві, де вже внесені зміни виглядають як стан речей, а видалена лінія залишається невидимою.

Останній пункт варто використовувати навіть без агентів. Перегляд файлів у їхньому кінцевому стані приховує зміни; перегляд diff їх відображає.

Використання аудитів для пошуку наступного шлюза

Версія 2.4.0 з’явилась після аудиту версії 2.3, який тривав 21 день та виявив шість проблемних показників. Ось два приклади: агенти безпеки та запуску все ще могли позначити результат перевірки як «ПРОХОДИТЬ» без жодних підтверджувальних даних, а також не було жодного порівняння коду завершення в тілі запису з кодом у його супутнику. У фіксурі для інтеграції плагіна навіть був запис, у якого супутник був створений на 223 дні пізніше, ніж сам запис.

Ці виправлення пов’язують твердження з файлами. Кожна виконана перевірка у цих звітах тепер вказує назву свого запису, чий сайдкар має бути присутнім, мати однаковий хеш та відповідати коду завершення, зазначеному у рядку. Кожен механізм обробки, який використовує запис, також порівнює його тіло з сайдкаром. Журнал блокувань отримав структуровану схему з позначенням рівня серйозності та обсягу завдань. Команда також виміряла вартість обробки тригерів — приблизно 1,77 долара та 250 секунд на кожен запуск, і використала це значення для визначення частоти їх виконання.

Пізніша перевірка версії 2.6.0 використала дев’ять об’єктів спостереження та ті самі 21 показник, і підтвердила наявність 23 перешкод, усі з яких були усунені у версії 2.6.1. Дві з них вирізняються. Питання походження доказів залишилося нерозв’язаним: розробник та перевіряючий використовували один і той самий каталог доказів, тож перевірка, яка не принесла жодних результатів, могла стосуватися скріншота розробника. Крім того, через відсутність інструментів браузера на етапі виконання програми застряг один з кроків інтерфейсу: він не міг відповідати вимогам, тож система відхилила єдину альтернативу — перевірку лише вихідного коду.

The fixes split evidence directories by producer, made UI milestones stop and ask the user when no browser is available instead of looping, and insisted, without exceptions, that a capture match the command its note says was executed. Wake-up payloads were slimmed by moving rationale out of the core persona text into references, without losing any rules. The changelog also gained a "Known, not fixed" section, because a commit gate that would accept an entirely forged evidence base is a limit that should be documented rather than hidden.

From checking afterwards to refusing beforehand

Up to release 2.5.0 every gate ran after the fact, and the model still decided whether to run it. A rule like "do not commit by hand while a lane is active" can still be read and ignored.

Відповіддю став хук PreToolUse, який блокує виклики інструментів перед їх виконанням. Він відмовляє:

• у ручному виконанні команди git commit, поки смуга активна
• у редагуванні вже існуючого файлу тесту під час усунення багу
• у запуску підагента, поки дані ще не оброблені
• у ручних змінах будь-якого файлу, створеного системою

Щоб визначити, чи активна смуга, хук перевіряє файли стану на диску та вважає їх актуальними протягом 12 годин; він ніколи не довіряє тому, що модель каже про свій власний стан. Він також припиняє роботу у разі будь-якої внутрішньої помилки. Це свідомий компроміс: захист, який перериває сеанси, буде видалений, а видалений захист нічого не забезпечує.

У цій версії також був доданий драйвер, який виконує наступний обов’язковий крок, замість того щоб покладатися на Orchestrator для його запам’ятовування, а також валідатор для передачі обов’язків між агентами. Валідатор перевіряє, чи існують згадані шляхи, чи файли, вказані як змінені, дійсно є у результатах порівняння, та позначає суперечності, такі як статус BLOCKED поруч із рядком blockers, у якому зазначено „None“.

Обробка роботи між функціями

До версії 2.6.0 кілька видів рутинної інженерної роботи зовсім не мали методологій — серед них оновлення залежностей, впровадження флагів функцій, створення фонових завдань, додавання можливостей для моніторингу та зміна контрактів API. Агенти робили це імпровізовано. Команда Quick Lane також припускалася щодо команд тестування проекту.

У цьому випуску було додано п’ять навичок для цих сфер, кожна з яких має контракт виконання та оцінку, яка перевіряє цей контракт. Тепер детектор стеку пропонує команду перевірки та заморожені елементи тестів із репозиторію, а людина підтверджує їх замість того, щоб процес вибору відбувався автоматично. Для майлстоунів API брама комітів також виконує порівняння за форматом OpenAPI, що означає, що зміни, які порушують існуючу структуру, не можуть бути прийняті без письмового обґрунтування. Кожного разу, коли при виборі дизайну було принаймні два варіанти, необхідний документ ADR, а інструмент lint перевіряє, чи посилається реєстр дизайну на нього. Нарешті, кожна методологія отримала „Швидку картку“: п’ять правил, які мають значення для змін у трьох або менше файлах, кожне з яких посилається на відповідний розділ, щоб процес швидкого оброблення міг використовувати скорочену версію інструкцій замість повного контракту.

Перетворення уроків ще до того, як вони стануть звичками

Випуск 2.6.2 став результатом справжньої епічної боротьби. Квінн чотири рази перерозподіляла завдання для вирішення однієї й тієї самої проблеми в середовищі, що призвело до витрати близько 1,2 мільйона токенів. Статус „COMPLETE“, який вказував на завершення процесу, свідчив про те, що артефакт все ще містить позначки типу TODO. Крім того, перезапуск існуючого агента фіксувався як зовсім нове завдання, що призводило до збільшення обсягу журналу операцій.

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

Виявлення тестів, які тестирують самих себе

Версія 2.7.0 вирішила одну з найбільш тривожних проблем. У реальному проекті з двадцяти специфікацій Playwright, створених різними каналами тестування, тринадцять виявилися фальшивими. Ці специфікації заново реалізували тестуваний функціонал — прямо або через виклик page.evaluate — а потім перевіряли його проти власної копії. Такий тест щоразу без проблем переходить з статусу ЧЕРВОНИЙ на ЗЕЛЕНИЙ, і механізм контролю статусу не може цього виявити, оскільки така тавтологія проходить обидві стадії перевірки.

check_test_authenticity.py тепер запускається після кожного отримання статусу ЧЕРВОНИЙ у будь-якому каналі, де створюються тести. Він шукає чотири типи фальшивих специфікацій:

• специфікація, яка не імпортує нічого з коду продукту
• вбудована повторна реалізація тестуваного коду
• оцінка вихідного тексту
• синтетичний DOM, який замінює справжнє додатку

Після калібрування за допомогою цього справжнього набору тестів він відхиляє саме тринадцять фальшивих тестів та приймає сім справжніх специфікацій, не використовуючи жодних закодованих імен файлів. Методологія тестування також включає так званий тест видалення: якщо тест все ще проходить після видалення коду, який, за твердженням системи, він має перевіряти, це є критичним знахідком. Це швидка ментальна перевірка, яку можна застосувати до будь-якого тесту, незалежно від того, чи написаний він людиною, чи ні; наша стаття про антипатерни тестування в React розглядає подібні способи, через які набори тестів створюють хибну впевненість.

Уроки з інструменту для перегляду коду

Для версії 2.7.1 розробники дослідили процес відкритого перегляду коду в Alibaba, який, за повідомленнями, досягає приблизно 34% точності у публічних тестах порівняно з 7–16% у Claude Code під час автономного перегляду за допомогою ідентичних моделей. Ці цифри слід розглядати як оцінку проектом цих тестів на момент дослідження, а не як незалежний результат. Цікавим було те, що два формати оцінки були майже ідентичними. Різниця полягала у додаткових елементах: зафіксованому списку файлів, які обов’язково потрібно врахувати, файлах, створених під час роботи, які видалялися перед тим, як переглядач побачить відмінності, обмеженні щодо розміру та кроці перевірки фактів, який дозволяв відхилити результат лише з однієї з двох визначених причин.

Два інциденти під час тестування потрапили до однієї версії продукту. Тест без головного вікна, у якого не було репозиторію Git у налаштуваннях, почав шукати його по всій машині та звернувся до справжнього системи відстеження проблем. Крім того, одна процедура виправлення багів за допомогою плагінів коштувала 11,06 доларів, проте не створила жодних тестів, які могли б виявити помилки у пошкодженій версії, тож ніхто не помітив би, якби виправлення було скасовано.

Отримані зміни:

• Механізм підтвердження коміту відхиляє заявку на схвалення, якщо у розділі огляду з’являється якась нерозв’язана критична чи важлива проблема. Фактично вердикт обчислюється на основі цих знахідок, а регулярний вираз підтверджує це обчислення.
• Якщо для кожного файлу у відмінностях немає окремої лінії для огляду, коміт відхиляється.
• Пакет для огляду видаляє файли з механізмами блокування, стиснуті файли та генеровані файли на будь-якій глибині, вказує, що було видалено, та відхиляє відмінності довжиною понад 1 500 рядків, якщо тільки людина не напише відповідну згоду.

Тепер кожна інформаційна зустріч працівника під час оцінки без головного модуля повторює вступ до сфери дії, а механізм контролю ізолює будь-яку роботу, яка виходить за межі її робочого простору.

У оцінках результатів з’явився новий критерій: виправлення враховується лише у разі, якщо воно супроводжується тестом на регресію, який покаже помилку у разі скасування цього виправлення.

Під час перевірки журналу змін було виявлено п’ять опублікованих комітів без відповідних записів, і їх було закрито.

Порівняння не було одностороннім. У 51 документі з правилами для різних мов іншого інструменту не було нічого про C#, Vue, PowerShell чи SQL — для цих мов використовується загальний перелік перевірок, і саме ці технології покривають функціонал цього плагіну.

Під час другого ознайомлення було сформульовано три правила точності у розділі 2.7.2, які додалися ще до того, як будь-яка несправність вимагала їх застосування. Оглядач може прочитати будь-який файл для зрозуміння контексту, але висновки стосуються лише файлів, які є частиною пакетного дифу; спостереження щодо інших файлів стають приміткою поза межами сфери дії Orchestrator. Методологія роботи з базами даних отримала правило щодо запобігання втручанню з чітким списком того, що ніколи не слід повідомляти, таким як параметризовані зв’язки та статичні оператори, адже хибний висновок щодо правильного коду змушує оглядачів ігнорувати справжні проблеми. Крім того, методологія безпеки тепер вимагає структури з п’ятьма розділами для документів про безпеку, причому кожна категорія OWASP у них має мати або посилання, або обґрунтований варіант „Не застосовується“, оскільки залишення рядка порожнім не є вердиктом.

Стан проекту

На момент написання цього тексту плагін має 16 персон агентів, 45 навичок та 32 скрипти контролю, серед яких 1 656 самоперевірок. Усі ці скрипти є детерміністичними, не використовують запити до LLM та виконуються перед кожним випуском. Набір тестів містить 69 випадків, розподілених на чотири рівні; рівень результату порівнює роботу з плагіном увімкненим та вимкненим з прихованими тестами, а не перевіряє, чи була активована певна ланка. З моменту створення першої версії 119 комітів додали близько 67 000 рядків коду.

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

Основні висновки

• Розглядайте правило, яке було порушене під час його дії, як звіт про помилку щодо цього правила та виправляйте його за допомогою контрольного етапу, а не посилення формулювань.
• Нехай скрипти виконують незворотні дії, такі як збереження змін, щоб пропущена перевірка залишала видиму відсутність результату замість беззвучного проходження.
• Визначте рівні доказів та вимагайте запису результатів команд із хешуванням, а не просто фрази „перевірено“.
• Надайте агентам легітимний результат BLOCKED, щоб створення результату PASS ніколи не було найпростішим шляхом.
• Доведіть ефективність кожного контрольного етапу, спостерігаючи за його невдачею під час навмисного порушення, та проведіть аудит самих етапів, оскільки перевірки часто зводяться до перевірки назв та наявності файлів.
• Блокуйте небезпечні виклики інструментів ще до їх виконання, але налаштуйте захист так, щоб він дозволяв проходження, щоб ніхто не був спонуканий його видалити.

Застосуйте тест на видалення до створених тестів: якщо видалення коду для продакшну не призведе до зламу тесту, цей тест є марним.

Метод полягає у циклі: спостерігайте за виконанням, знайдіть інструкцію, яку було проігноровано, замініть її на те, що має бути виконано або активовано, та спостерігайте за наступним виконанням.

Пов’язана література

• Де мають знаходитися інструкції Claude Code: CLAUDE.md, правила шляхів чи хуки — Дізнайтеся, чому Claude Code використовує CLAUDE.md як контекст, як його скоротити, як налаштовувати правила за шляхом, як переміщувати кроки, що мають виконуватися, у хуки, та як перевірити, що насправді завантажується.
• Практичний посібник з написання ефективного файлу CLAUDE.md — Дізнайтеся про 21 конкретне, перевірюване правило для скорочення надмірно великого файлу CLAUDE.md, щоб Claude Code залишався надійним, прогнозованим та заслуговував на довіру під час тривалих сеансів.
• Навчання Claude Code вашого NestJS Monorepo: правила маршрутизації, правила та навички — Як налаштувати CLAUDE.md, правила, навички та дозволи, щоб Claude Code розміщував код у правильному сервісі NestJS та дотримувався стандартів вашої команди.
• Застосування правил агентів у коді: PreToolUse, PostToolUse та Stop Hooks — Дізнайтеся, чому авторизація агентів LLM має знаходитися у детерміністичних гаках виклику інструментів, як безпечно відмовляти у викликах та як обгорнути диспетчер без рекурсії.