Инвариантом в спецификации называют правило, которое должно соблюдаться всегда: при любой задаче, любом изменении и любом исполнителе. Операции в учёте не удаляются. Баланс не меняется вне транзакции. Поле в ответе API, которым уже пользуются клиенты, не переименовывается. Требования описывают, что построить, инварианты описывают, что в ходе строительства нельзя сломать.
Слово пришло из математики и программирования. Там инвариантом называют свойство, которое не меняется, что бы ни происходило с системой: сумма углов треугольника, условие, верное на каждом шаге цикла. В спецификации смысл тот же, только применён к поведению системы и к работе тех, кто её меняет.
Требование можно выполнить частично, отложить или пересмотреть. Архитектурный принцип помогает выбрать решение, когда требований не хватает, и иногда уступает другому принципу. Инвариант не уступает ничему. Если задача требует его нарушить, работа останавливается, и решение принимает человек.
Поэтому инвариантов в проекте мало, обычно от трёх до десяти. Когда инвариантом объявляют всё подряд, они перестают отличаться от пожеланий, и исполнитель начинает выбирать, какие из них соблюдать.
В стандарте ANSS у инварианта четыре поля: название, что нельзя, почему и как проверить. Например, для приложения, которое должно запускаться без установки пакетов: нельзя подключать внешние npm-модули, потому что приложение должно работать без npm install, а проверка состоит в том, что в коде нет импортов из node_modules.
Главное поле последнее. Проверка должна быть конкретной: запрос к базе, ограничение в схеме данных, тест, строка в diff. Инвариант без проверки остаётся добрым намерением, соблюдение которого никто не может подтвердить.
Человек в команде годами слышит, что в этой системе трогать нельзя. ИИ-агент этого не знает. Чего нет в задаче, он восполняет решениями из обучающих данных, и под давлением задачи может «починить» ошибку, удалив проверку, которая ей мешала.
Записанный инвариант даёт агенту границу, которую он видит до начала работы, и правило поведения на случай конфликта: остановиться и спросить. Поле проверки позволяет агенту сверить с ним собственный результат, а человеку при приёмке убедиться, что граница цела. Поэтому в спецификации для ИИ инварианты стоят в разделе, который агент читает первым.
В спецификации для сети ломбардов самые важные инварианты пришли из разговора с владельцем бизнеса. Запись о приёме изделия не сохраняется без фото. Куда уходит изделие после приёма, решает только владелец. Скупка по цене за грамм вне заданного диапазона требует его подтверждения. Каждое из этих правил закрывает конкретный способ злоупотребления со стороны сотрудника, и у каждого есть проверка в коде: сервер отклоняет запрос без фото, смена маршрута изделия невозможна без отметки владельца. Спецификация опубликована как пример в репозитории ANSS.
В ТЗ для этого сайта раздел инвариантов есть всегда: тексты выводятся дословно, файлы вне перечня не меняются, новых стилей нет. Проверка у них общая и простая, это состав изменённых файлов перед коммитом. Если в нём появился файл вне перечня, работа останавливается до ответа.
Какие правила в процессе нельзя нарушать никогда, даже ради срочной задачи. Как каждое из них проверяется и кто эту проверку выполняет: код, тест или человек при приёмке. Что делает исполнитель, когда задача упирается в инвариант. И кто вправе инвариант изменить: это решение человека, его не принимает агент и не принимает подрядчик по ходу работы. Проверки инвариантов входят в критерии приёмки.
Связанные термины: Спецификация для ИИ · Критерии приёмки · ИИ-агент · Точка отказа
Нужно записать правила, которые ИИ и подрядчик не должны нарушать? Спецификация для ИИ →