Проверить ответ: от утверждения к доказательству

Проверяйте три разных слоя

Сначала проверьте форму: все ли строки содержат вход, действие, наблюдаемое ожидание и источник. Затем смысл: соответствует ли ожидание правилу, возможны ли данные, не объединены ли несовместимые предусловия. После этого оцените покрытие выбранной модели: какие требования, состояния или границы вообще представлены. Проход одного слоя не компенсирует провал другого. Аккуратная таблица с десятью одинаковыми успешными сценариями может почти ничего не говорить о границах и доступе.

Для ответа по F1–F4 составьте свой небольшой ориентир до чтения генерации. Поля дают классы и границы, draft/published — состояния видимости, автор/другой участник — различие субъектов. Не нужно заранее написать весь регресс. Достаточно зафиксировать важные различия, по которым вы будете проверять предложенный набор. Это снижает риск принять структуру модели за единственную возможную модель продукта.

Разобранный пример: три дефекта одного набора

Ассистент предложил: title 80 — отклонить; description 0 — отклонить; draft автора открывается автору. Первая строка противоречит включённой верхней границе F1, вторая — F2. Третья согласуется с F3, но не показывает, что другой участник лишён доступа. Если добавить ещё пять вариантов чтения автором, этот пробел не исчезнет. Нужна проверка именно другого субъекта, с тем же черновиком и известным начальным состоянием.

Отдельно разберите набор для published. F4 определяет видимость заголовка участникам команды, но не определяет доступ внешнего пользователя к описанию. Ожидание для внешнего пользователя нельзя молча вывести из того, что команда явно названа в одном правиле. Это существенный риск и вопрос к контракту. Разница между отсутствием проверки и отсутствием требования важна: в первом случае добавляют сценарий, во втором сначала устанавливают ожидаемое поведение.

Короткий журнал ревью

Верификация должна выйти за пределы разговора с моделью

Повторный запрос «ты уверен?» может дать полезную альтернативу, но не является независимым подтверждением. Проверьте длины подсчётом, правило — исходным документом, поведение — на согласованной сборке, если выполняется тест. Для технического примера полезен минимальный набор с известным результатом. Для утверждения о библиотеке откройте документацию нужной версии. Не переносите вывод на другой диалект, роль или состояние без основания.

В конце напишите, что принято, что исправлено, какие вопросы мешают завершению и что не выполнялось. Если учебная проверка касается только ASCII-длин и видимости черновика, не называйте её полной проверкой Unicode, авторизации или готовности к выпуску. Такое ограничение не обесценивает работу: оно делает её воспроизводимой. Следующему специалисту понятно, какие решения можно использовать и где ещё требуется согласование.