Идентификаторы критериев приёмки (ACIDs)

Acceptance Criteria IDs (ACIDs) - это короткие стабильные идентификаторы, присваиваемые каждому пункту в списке критериев приёмки (AUTH-1, AUTH-2-1, ENG-3), которые служат двусторонними якорями между спецификацией и кодом, тестами и замечаниями к ревью, закрывающими эти требования. Термин появился в статье про specsmaxxing на acai.sh, где такое соглашение возникло стихийно: субагент сам начал нумеровать требования и ссылаться на них во встроенных комментариях к коду.

Сам паттерн старше названия: сценарии Gherkin, требования в формате EARS и матрицы трассируемости из аэрокосмической отрасли дают нечто похожее на ACIDs. Новизна в 2026 году заключается в том, что они стали связующим звеном между сгенерированным LLM кодом и поддерживаемой человеком спецификацией, а инструменты отслеживают "покрытие приёмкой" (acceptance coverage) точно так же, как стандартные утилиты отслеживают покрытие тестами.

Как это устроено

Спецификация на базе ACIDs строится на трёх принципах:

Стабильная нумерация. Каждое требование получает ID, который не меняется при добавлении, перестановке или удалении других пунктов. Компоненты или разделы (AUTH, BILLING, ENG) задают пространства имён; номера внутри раздела только добавляются (append-only).
Ссылки со стороны кода. Реализация ссылается на закрываемый ACID, чаще всего во встроенных комментариях вида // AUTH-1, хотя подойдёт любой формат, который инструменты могут найти через grep.
Отслеживание состояния. У каждого ACID есть статус: drafted, assigned, in-progress, completed, accepted, rejected, deprecated. Состояние хранится вне исходного файла (дашборд acai.sh - один из вариантов; JSON-sidecar или слой git-notes - другие возможные решения).

Иерархические вложенные идентификаторы (AUTH-2-1) покрывают случай "у этого требования появилось уточняющее подтребование". Соседние метаданные (AUTH-2-note) содержат перекрёстные ссылки и обоснование архитектурных решений, не загромождая сам текст требования.

Почему это работает для кода с участием LLM

Когда реализацию пишет агент, решающими становятся три свойства:

Ревью переключается с файлов на требования. Вместо построчного чтения PR на 600 строк проверяются конкретные ACIDs с вопросом: "действительно ли код, заявляющий реализацию AUTH-3, делает именно это?" Ментальная модель ревьюера совпадает со структурой проверяемого артефакта.
Повторные prompt'ы становятся механическими. "Реализуй AUTH-2-1" - куда более точный prompt, чем "убедись, что токены валидируются корректно". Спецификация и есть prompt; итерации опираются на спецификацию, а не на произвольные уточнения в чате.
Пробелы в покрытии сразу видны. ACIDs без ссылок в коде ещё не реализованы; ACIDs без ссылок в тестах не проверены. Это дешёвая детерминированная проверка, не зависящая от того, насколько адекватно LLM оценивает сама себя.

Жёсткая связь между спецификацией и кодом, которую вносят ACIDs, поначалу смущала автора концепции specsmaxxing: любое изменение спецификации вынуждает рефакторить код. Но на деле именно такая дисциплина и требуется: если спецификация меняется, а код за ней не следует, спецификация была лишь декорацией.

Почему это работает и для людей

ACIDs появились за десятилетия до LLM. В аэрокосмической отрасли и разработке медицинского оборудования давно применяется трассируемость требований (requirement traceability): каждая строчка критически важного для безопасности кода восходит к пронумерованному требованию, что контролируется инструментами аудита. Стандарты ISO 26262 (автомобили), DO-178C (авионика), IEC 62304 (медицинский софт) опираются именно на этот подход. В контексте разработки с LLM новизна не в самой технике, а в том, что затраты на поддержание трассируемости упали практически до нуля, так как рутинный учёт берёт на себя агент.

Компромиссы, отмеченные в статье про specsmaxxing

Затраты на синхронизацию. Переименование ACID или изменение порядка нумерации ломает все ссылки в коде. Флаги deprecated и replaced_by в спецификации - один из способов сгладить проблему; другой - относиться к ACIDs как к неизменяемым и никогда не используемым повторно идентификаторам (append-only).
Дисциплина гранулярности. Спецификации с детализацией уровня "эндпоинт API принимает JSON" дают полезные ACIDs; спецификации уровня "кнопка должна быть синей" порождают шум. Рекомендация acai.sh - ограничивать ACIDs поведением и ограничениями системы, оставляя визуальную полировку UI за скобками.
Привязка к формату. Как только комментарии в коде начинают ссылаться на ACIDs по идентификаторам, формат спецификации становится критически важным звеном. Переход с feature.yaml на OpenSpec или EARS без скрипта миграции превратит все ссылки в коде в битые.

Смежные подходы

Синтаксис EARS (Easy Approach to Requirements Syntax) - строгий формат на естественном языке ("When <trigger>, the <system> shall <response>"). Совместим с ACIDs, но решает другую задачу: EARS определяет, как формулировать требование, а ACIDs - как адресовать его.
Gherkin (Given/When/Then) - та же структура: адресуемые сценарии, на которые ссылается тестовый код. ACIDs обобщают этот подход за пределы одних лишь тестов.
Идентификаторы в таск-трекерах - ссылки на JIRA-1234 в сообщениях коммитов представляют ту же идею, но с более крупной гранулярностью. ACIDs действуют внутри спецификации конкретной функциональности, а не в масштабе всего проекта.
Комментарии TODO со ссылками на тикеты - неформальный вариант того же паттерна с потерями контекста. Отличие ACIDs в том, что они являются частью спецификации, а не разрозненными аннотациями в кодовой базе.

Инструменты

acai - feature.yaml + CLI + дашборд; эталонная реализация по состоянию на 2026 год.
GitHub SpecKit - другой формат (вайб-кодинг с prompt'ами), концепция ACID отсутствует.
OpenSpec, Kiro, Traycer.ai - рассмотрены в обзоре specsmaxxing; предлагают разную степень структурированности.

См. также

specsmaxxing - происхождение термина и подробная аргументация
acai - инструментарий
clean-code-coding-agents - смежный тезис о том, что структура кода должна быть оптимизирована для навигации агентов
ai-assisted-workflow - рабочий процесс Барберо со спецификацией до написания кода, совместимый подход
building-syntaqlite-ai - пример из практики, когда отсутствие дисциплины в спецификациях привело к переделкам
agent-built-deterministic-tools - родственный паттерн: стабильные артефакты, на которые агенты ссылаются вместо повторной интерпретации с нуля
1password-agentic-refactoring - промышленный пример использования агентов, ограниченных спецификацией