Повторное ревью после FIX

AI Development Harness · 29 октября 2026

Сценарий: исправили одну ошибку, получили новый аудит

Первое независимое REVIEW обнаружило неверную обработку пустого списка. FIX исправил условие и добавил регрессионный тест. Если повторный проверяющий начинает исследовать весь проект с нуля, работа может бесконечно расширяться: каждый круг приносит новые замечания, не связанные с исправлением.

Полное первое ревью остаётся обязательным. Повторное после FIX отвечает на два конкретных вопроса: устранена ли подтверждённая ошибка и не сломало ли исправление соседнее поведение. Это ограничение объекта проверки, а не снижение требований к доказательствам.

Точный набор изменений и причинная связь

До смыслового FIX Harness сохраняет дерево Git до FIX через альтернативный индекс. Снимок включает подготовленные и неподготовленные к коммиту изменения и неигнорируемые неотслеживаемые файлы, не меняя обычный индекс. Набор изменений привязан к executionId, исходному FAIL или подтверждённому наблюдению после PASS, отпечаткам замечаний и ревизии после FIX.

Первое независимое REVIEW → FAIL с подтверждённым замечанием
                 ↓
Снимок до FIX → исправление + регрессионный тест
                 ↓
Проверки по контракту → свежие доказательства
                 ↓
REVIEW fix_delta: исходное замечание + точные изменения + прямые регрессии
                 ↓
PASS → проверка завершённости

Новое замечание обязано указывать изменённый путь и причинное обоснование fixDeltaCausality. Совпадения имени файла мало: нужно показать операцию, вход и наблюдаемый результат. Старый дефект неизменённого поведения сообщается отдельно. Обязательные независимые проверки безопасности и тестов получают тот же ограниченный набор изменений.

Если утрачено дерево Git, ревизия устарела или набор изменений повреждён или набор изменений превышает 1 MiB, REVIEW возвращает BLOCKED. Не запускайте Git GC между FIX и REVIEW. Повторное полное ревью допускается по явному запросу пользователя: HARNESS_REVIEW_FULL=1 при запуске диспетчера.

Выборочные тесты требуют отдельного контракта

Ограниченный REVIEW не включает автоматически выборочный запуск тестов. Без явной проектной карты verification.impactMap проверка всегда полная. Карта перечисляет команды из STEP, все существенные входные данные, зависимости dependsOn, покрываемые критерии приёмки и возможность повторного использования.

verification:
  impactMap: docs/verification/impact-map.json

Это пример пути внутри проекта, а не обязательное имя. Полноту зависимостей проверяет независимый проверяющий плана. Harness проверяет форму, соответствие командам и критериям приёмки и хэши; он не умеет доказывать, что произвольный шаблон путей охватывает все скрытые зависимости.

Например, изменение обработки пустого списка повторяет проверку списка и зависимую проверку экспорта. Неизменённая проверка независимого форматтера может использовать прошлый PASS лишь при действующей карте, исходном полном PASS, локальном подтверждении происхождения и неизменном окружении. Если общая функция используется обоими компонентами, она должна входить во входные данные обоих либо влияние должно передаваться через поле dependsOn.

Новые доказательства вместо переписанного старого PASS

Канонический инструмент записи выпускает новые доказательства для текущего объекта, отмечая выполненные и переиспользованные результаты. Подтверждение связано с точным содержимым доказательств, основой контекста и контракта и состоянием кода. Ручная замена FAIL на PASS не создаёт доказательство.

verify-selected.py помогает проверять выбранные настроенные команды во время FIX, но возвращает completionProof=false. При точном совпадении объекта, карты, контекста и окружения результат может войти в новый канонический PASS. Разделение монолитной команды на группы требует предварительного полного запуска самой команды и всех групп на одной ревизии.

Краткое продолжение после MANUAL_REQUIRED — отдельный механизм: автоматические PASS живут не более 30 минут, требуют совпадения всех входов и не подходят для исключённых высокорисковых STEP. Ручные и продуктовые наблюдения должны подтверждать текущий объект.

Когда выполняется всё

Нет карты, локальной контрольной записи, пригодного дерева Git или подтверждения происхождения — полный прогон. Не покрыт изменённый путь, изменились REQ/ADR/критерии приёмки/план, карта, файл фиксации зависимостей, набор инструментов или полное унаследованное окружение — полный прогон. В доказательства попадает хэш содержимого окружения, а не значения секретов. Высокорисковые STEP и непроверяемые внешние зависимости также не позволяют безусловно переиспользовать PASS.

Если входы изменились во время проверки или записи, результат не приписывается новой ревизии: VERIFICATION_INPUTS_STALE. Свежий FAIL выборочной команды аннулирует локальные подтверждения; следующая проверка начинается полностью. Полный запуск можно запросить явно:

python3 .harness/tools/verify-step.py STEP-017 --full

Сокращённый набор команд не доказывает экономию времени сам по себе. Для утверждений о скорости нужны сопоставимые измерения; протокол прежде всего защищает полноту приёмки.

Источники и следующий шаг

Контракт повторного REVIEW · Карта влияния и происхождение результатов проверок. Продолжение: поздний дефект после PASS; справочник — проверки Harness.