Итоговый проект: проверяем артефакты до передачи в работу

Что нужно передать команде

Команда хочет применять ИИ при подготовке проверок OrbitDesk. Ваша задача — показать небольшой, но надёжный процесс: от контракта и предложения помощника до проверенного артефакта. Это не проект на максимальное число тестов. Пакет должен объяснять найденную ошибку, основание исправления и способ повторения без вашей переписки с моделью.

Используйте только данные курса. OD-API-1 — спецификация, не работающий endpoint. OD-DATA-1 — исполняемый SQL для новой SQLite-базы. DOM-файл — локальный пример Playwright без сервера. Сохраните эти границы в отчёте: нельзя расширять вывод о примере на систему, которой вы не касались.

Состав пакета

1. API-review.md: различающиеся проверки прав и публикации, данные и ожидания.
2. 01-fixture.sql: исходные данные с явной версией.
3. 02-queries.sql и results.md: запросы, ожидаемые и фактические строки.
4. dom-exercise.spec.ts: локаторы, состояния, await и изоляция.
5. evaluation.md: рубрика ответа ИИ, ошибки и исправления.
6. report.md: среда, выполненные действия, Not run и ограничения.

Сначала прогноз, затем исполнение

Вручную посчитайте опубликованные задачи: Анна — 1, Борис — 1, Вера — 0. Предскажите, что изменится после соединения двух комментариев t1. Выпишите ID неназначенных задач: t2 и t3. Теперь загрузите фикстуру в новую одноразовую базу и выполните SELECT. Сохраните вывод; при расхождении выясните причину, а не подгоняйте эталон под ответ.

В API-части подготовьте 401 без сессии, 404 для чтения чужого draft, 403 для публикации неавтором-user, 422 для пробельного title и 200 с сохранением автора. Повтор publish с 409 добавьте в последовательность. Если собственной реализации нет, это отредактированный набор сценариев. Он не превращается в HTTP-прогон после успешного SQL.

Код должен иметь наблюдаемый результат

DOM-упражнение можно запустить в локальном проекте с проверенной версией Playwright. Скачиваемый файл ничего не устанавливает сам. Если инструмент недоступен, завершите статическое ревью и пометьте запуск Not run. Не запускайте случайный архив зависимости, придуманной моделью. Для серверной проверки отдельно потребуются согласованный стенд, искусственные сессии и подготовка объектов.

К каждому выполненному действию приложите минимальное доказательство: вывод SQLite, ошибку assertion или наблюдаемое состояние DOM. Полный секретный лог не нужен. Рядом укажите версию фикстуры, чтобы отличить ошибку запроса от изменившихся данных. Успешность одной команды не заменяет проверку всех остальных частей пакета.

Независимое чтение результата

Попросите коллегу прочитать один кейс либо вернитесь к документу позже сами. Можно ли восстановить начальное состояние? Понятен ли диалект SQL? Не назван ли setContent тестом авторизации? Есть ли конкретное улучшение после изменения промпта? На каждый вопрос нужен указатель на артефакт, а не заверение, что всё проверено.

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