Петля сверки для спек работает как контроллер в Kubernetes: человек меняет желаемое (спеку), агент сверяет его с фактическим (кодом) и приводит код в соответствие, а тесты замеряют результат. Зелёные тесты проверяют только то, что в них записано, поэтому у каждого MUST должна быть своя проверка, а среде агента нужны запуск кода, тесты, логи, данные, сервисы и песочница.
спекаагенткодтестыТа же петля, что в Kubernetes
Kubernetes — система, которая запускает сервисы и поддерживает их работу на многих серверах. Её главная идея проста: человек описывает, как должно быть («держи три копии сервиса»), а программа-надзиратель, контроллер, постоянно сверяет описание с тем, что есть на самом деле, и исправляет расхождения. Это и есть петля сверки. Для спек работает та же схема: желаемое задаёт человек, а привести код к нему может агент.
Желаемое здесь — словарь агрегатов: одна запись на понятие, требования со словами MUST и SHOULD.
Как читать схему. Четыре колонки — четыре роли петли, две строки — две системы, третья строка переводит термины на простой язык. Желаемое (закрашено) меняет человек. В Kubernetes это чарт и манифест: файлы, где описано, какие части сервиса и в каком числе должны работать. В спеках это словарь агрегатов со словами MUST («обязательно») и SHOULD («желательно»). Исполнитель приводит факт к желаемому: в Kubernetes это контроллер, в спеках агент. Фактическое — то, что есть сейчас: ноды (серверы) и поды (запущенные на них части сервиса) или код. Замер показывает, совпало ли: пробы (короткие автоматические опросы «ты работаешь?») и метрики или тесты и проверки качества. Стрелка вниз сверху значит, что человек меняет только желаемое. Стрелка по кругу снизу значит, что результат замера возвращается исполнителю, и так до совпадения. Пример: человек пишет в словаре «бронь закрывается через 15 минут», агент меняет код, тесты проверяют, а красный тест отправляет агента обратно к коду.
Петля сверки — по документации Kubernetes о контроллерах.
Замер видит только то, что в него заложено
Замер показывает только то, что в него заложено. В Kubernetes проба — короткий автоматический запрос к сервису: «ты отвечаешь?». Если сервис ответил «200» (код успеха), проба зелёная, хотя главное он может не делать: например, очередь заказов стоит. В спеках то же самое с тестами. Если для требования теста нет, все тесты остаются зелёными, и никто не замечает, что оно не выполнено.
Пример — бронь переговорной из статьи Спеки по агрегатам: три требования MUST и одно SHOULD.
сервис ответил «200: работаю»пробазаказы при этом не обрабатываютсяне провереноMUST · брони одной комнаты не пересекаютсяесть тестMUST · статус брони меняется только вперёдесть тестMUST · без подтверждения через 15 минут бронь закрываетсянет проверкиSHOULD · подтверждение приходит в тот же каналсмотрит человекКак читать картинку. Слева Kubernetes: проба получила ответ «200: работаю» и зелёная, но заказы при этом не обрабатываются, то есть проба не проверяла главное. Справа спеки на примере брони переговорной: три требования MUST и одно SHOULD. Два MUST покрыты тестами (брони не пересекаются, статус меняется только вперёд). Третье, «без подтверждения через 15 минут бронь закрывается», не проверяет никто. SHOULD про канал смотрит человек на ревью. Покрыто 2 из 3 MUST, это 67%. Три правила под схемой: у каждого MUST своя проверка; MUST без проверки считается пробелом, который надо закрыть; зелёный результат ещё не значит, что всё верно.
Какие пробы бывают и что они проверяют — Kubernetes: probes.
Среда решает, замкнётся ли петля
Петля замыкается, только если у исполнителя есть всё нужное для сверки. Контроллер Kubernetes работает, потому что кластер даёт ему доступ ко всему необходимому. У агента такая среда называется харнессом: это окружение, в котором он работает, с программами, правами и проверками.
Шесть возможностей на картинке — то, что нужно агенту, чтобы замкнуть петлю, и то, что случается без каждой из них. Без запуска кода агент гадает, как работает программа. Без тестов MUST невозможно проверить. Без логов не видно, что именно сломалось. Без тестовых данных проверка идёт на пустой базе и ничего не показывает. Без доступа к сервисам через MCP интеграции проверяются вслепую. Без песочницы (изолированного места, где можно безопасно пробовать и ломать) страшно разрешать агенту действовать. Если какой-то возможности нет, петля в этом месте разомкнута.