Статьи

Ошибку нашли после REVIEW PASS: как безопасно исправлять поздние дефекты

Как зафиксировать поздний дефект без переписывания принятой истории: неизменяемое наблюдение, точный объект исправления, новые проверки и REVIEW.

Сценарий: ревью прошло, воспроизведение появилось позже

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

Harness сохраняет принятую историю и регистрирует новый воспроизводимый факт. Дальнейший путь зависит от того, завершён ли STEP полностью: PASS ревью и статус «Выполнено» — разные факты.

Наблюдение вместо переписывания отчёта

Сохраните воспроизведение в файле проекта и зарегистрируйте его через .harness/tools/late-defect.py по контракту исходного STEP. Новое неизменяемое наблюдение рядом с REVIEW содержит ссылку на доверенный PASS, буквальный критерий приёмки, исходные условия, действие, ожидаемый и наблюдаемый результаты, хэш воспроизведения и список invalidatedChecks.

Given: список записей пуст
When: пользователь экспортирует отчёт
Expected: создаётся корректный пустой отчёт
Observed: файл невозможно открыть
invalidatedChecks: проверка экспорта и зависимые проверки

Это пример структуры сценария; фактические команды и результаты надо получить на проекте. Хэш содержимого связывает содержимое наблюдения с именем: незаметно изменить его как обычную заметку нельзя. Само утверждение модели без воспроизведения не становится новым доказательством.

STEP ещё выполняется

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

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

REVIEW PASS + STEP in_progress
          ↓ проверенное наблюдение и свежее исходное подтверждение
STEP FIX → новые проверки → REVIEW fix_delta → проверка завершённости

CTS разрешает переход REVIEW PASS → FIX внутри цепочки или RUN только после проверенного наблюдения. Если RUN уже завершён, вызывайте явный STEP FIX STEP-NNN. Старый результат проверки не становится свежим после исправления: нужны новые канонические проверки и независимое ревью.

STEP уже завершён

Создайте отдельный корректирующий STEP обычным STEP ADD, свяжите его с наблюдением, запланируйте точное исправление и регрессионные проверки. Исходный STEP остаётся завершённым в принятой истории. Новый STEP имеет собственные границы задачи, объект проверки и критерии приёмки.

Исторический завершённый STEP + неизменяемый REVIEW PASS
                         ↓ новый подтверждённый дефект
STEP ADD → PLAN → исправление → проверки → независимый REVIEW
                         ↓
Завершение корректирующего STEP

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

Когда можно использовать незатронутые результаты

Проверенная verification.impactMap нового STEP может ссылаться на reuse.sourceStep и путь наблюдения. Harness допускает только локально сохранённые проверенные PASS при неизменных исходных REVIEW и доказательствах, совпадающих хэшах кэша и подтверждения и идентичных id / command / inputs / dependsOn / reusable. Критерии нового STEP доказывает его текущая проверка.

Указанные invalidatedChecks обязательно выполняются заново. Неизвестные зависимости, отсутствие исходного кэша или подтверждения, новый клон, изменение окружения или высокие риски исходного либо нового STEP означают полный прогон. Историческим данным не присваивается новый хэш объекта.

Даже при повторном использовании части команд канонический инструмент записи выпускает новые доказательства для исправления, а проверка завершённости требует свежий успешный результат проверки и независимый REVIEW. Изменение контракта или потребность в более широком исправлении требуют нового плана, а не самовольного расширения границ задачи.

Проверяемые источники

Поздний дефект и корректирующий STEP · набор изменений FIX и актуальность доказательств. Связанные страницы: процесс исправления и повторный REVIEW после FIX.