У проекта может быть полный набор документов и всё равно не быть ответа, который можно безопасно передать разработке.

В Source Map пробелы выглядят менее впечатляюще, чем готовые строки. Например, документация говорит про exponential backoff, но не задаёт параметры retry policy. Формально материал есть. Практического правила, по которому можно написать проверку, нет.

Самая опасная реакция — позволить агенту заполнить пропуск правдоподобным значением. Так появляется спецификация, которая нигде не была принята. Она выглядит лучше, чем UNKNOWN, но хуже работает в эксплуатации: никто не знает, какое решение пересматривать, когда появится уточнение.

Я разделяю три состояния:

1. Известно. Есть источник, владелец и проверяемое решение. 2. Противоречит. Есть несколько источников, и конфликт вынесен отдельным вопросом. 3. UNKNOWN. Нужного правила нет или его нельзя вывести из доступных материалов.

У каждого состояния должен быть следующий шаг. Для UNKNOWN это не «попросить агента подумать ещё». Это указать, кому задать вопрос, какую часть системы он затрагивает и какая проверка появится после ответа.

Такой формат полезен и при приёмке. Пока вопрос открыт, зелёный технический тест не может считаться доказательством требования. После решения проверка получает основание, владельца и границу применимости.

UNKNOWN не означает, что работа остановлена. Он показывает, где работа ещё не стала решением.