Проверка выполнимости V-AC

Обзор

Критерий верификации (V-AC) может быть написан, проверен и ссылаться на верный номер AC, но при этом оставаться невыполнимым при любой корректной реализации — потому что runtime-команда, на которую он опирается, проверяет то, что семантика рантайма никогда не раскрывает. Этот гейт активируется, когда чеклист валидации плана содержит любой V-AC, чья проверка — runtime-команда: docker exec/kubectl exec, curl/wget/Playwright против работающего сервиса, утверждения о состоянии/логах через systemctl/journalctl, живые запросы redis-cli/psql/mongosh, либо любое утверждение о окружении/памяти/состоянии работающего процесса. Статические V-AC (test -f, grep по файлу, коды выхода lint/unit) в этом гейте не нуждаются — они детерминированы относительно рабочего дерева.

Какой сбой предотвращает этот гейт

Мотивирующий инцидент: AC, утверждающий «переменная окружения X установлена в Y на работающем сервисе», проверялся через docker exec <container> printenv X. Но printenv читает окружение shell, а не значение, которое держит работающий Node-процесс после того, как в коде выполнено process.env[X] = Y. Утверждение не могло пройти никогда, независимо от корректности реализации — но пережило ревью плана, потому что ревьюер сопоставил номер AC и форму команды, не выполнив её на реальном (или скелетном) рантайме. Дословное зеркалирование AC↔V-AC и семантическое ревью совпадения необходимы, но не достаточны: V-AC должен быть ещё и выполнимым, а выполнимость — свойство семантики рантайма, а не текста.

Контракт

Для каждого runtime-command V-AC план должен продемонстрировать — до фиксации в чеклисте валидации — что команда способна вернуть результат PASS при корректной реализации. Приемлемые доказательства, в порядке предпочтения:

1. Dry-run на реальном рантайме. Выполнить команду против работающего dev/staging/test-сервиса (или заглушки, имитирующей финальный) и подтвердить наблюдаемый корректный результат на заведомо корректной фикстуре. Привести результат прямо в плане.
2. Семантическое доказательство пути наблюдения. Если рантайм недостижим на этапе планирования, назвать точный механизм, через который утверждаемое значение становится наблюдаемым — например, «значение логируется через логгер приложения и проверяется через journalctl -u <unit> | grep», или «значение отдаётся в JSON /healthz и проверяется через curl … | jq». Команда, для которой путь наблюдения назвать нельзя, считается невыполнимой.
3. Переформулировка в выполнимое утверждение. Если ни одно из вышеперечисленного не выполняется, заменить V-AC на наблюдаемое — строку лога, поле HTTP-ответа или сохранённый побочный эффект вместо внутрипроцессного значения, которое рантайм никогда не раскрывает.

Частые невыполнимые паттерны

• docker exec C printenv X для значения, установленного через process.env[X]=Y в коде — printenv читает окружение shell, а не изменённое окружение живого процесса. Замена: проверять строку лога приложения или поле health-эндпоинта /config, отражающее X.
• curl <url> до того, как сервис забиндил порт/существует роут — несопоставленный роут вернёт 404 независимо от корректности. Замена: сначала grep роутера на реальный путь, затем проверять сопоставленный роут.
• kubectl exec … cat /proc/1/environ для переменной, изменённой в рантайме — /proc/1/environ это окружение запуска, замороженное на момент exec. Замена: раскрыть значение через эндпоинт приложения или структурированный лог.
• systemctl show -p Environment для переменной, устанавливаемой приложением — показывает объявленное юнитом окружение, а не значения, установленные внутри процесса. Замена: проверять через собственную поверхность наблюдаемости приложения.

Вывод

Фиксируйте вердикт выполнимости прямо в плане рядом с каждым runtime-command V-AC, чтобы ревьюер мог воспроизвести его без повторного запроса:

• V-AC-N — feasible (dry-run: <команда> → <наблюдаемый PASS-результат>)
• V-AC-N — feasible (observation path: <названный механизм>)
• V-AC-N — infeasible as written → re-scoped to <новое утверждение>

Runtime-command V-AC без аннотации выполнимости — дефект планирования: исправить план (доказать или переформулировать) до перехода к /dr-do. Обнаружение невыполнимого V-AC на этапе планирования стоит одного dry-run или одного grep; обнаружение на /dr-do или /dr-verify стоит целого цикла пайплайна плюс переформулировку V-гейта.