Сюжет я разрабатывал с Codex, для программирования использовал Claude Code. Результат этой работы нужно проверять по существу: игра действительно проходится или просто состоит из корректных файлов? ИИ может быстро подготовить много сцен и много тестов. Их количество не отвечает на вопрос, способен ли игрок пройти выбранный путь.
Открыть игру «Осквернённый Грааль: Ненаписанная легенда».
Этап сквозных проверок первой части сохранился в коммитах 21 сентября. По ним видно, что проверялось и какие утверждения появились. Название клиента для программирования подтверждено мной; журнал отдельных вызовов и авторство каждого теста из Git не следуют.
Начать с риска, который должен проверить агент
Первый риск — структурный: сцена ссылается на отсутствующий переход. Второй — поведенческий: переход есть, но его условие невозможно выполнить. Третий возникает от порядка посещения: ранняя ветка работает, а поздняя ждёт уже недоступного персонажа. Задание «проверь весь сценарий» смешивает эти разные проверки.
В AGENTS.md проекта прямо сказано, что статический валидатор не заменяет прохождение веток. Требуются достижимость, хронология, состояния персонажей, отсутствие раннего раскрытия тайн и циклов. Такой контекст нужен кодовому агенту до выбора тестового подхода.
Какие процедуры подготовлены для проверки
Роль test-strategist направляет к VALIDATION.md и перечисляет риски: повтор команды, откат, конкурентные вкладки, границы срока и отложенные эффекты. Ей предписаны управляемые seed и часы; блокировки проверяются на PostgreSQL, чистые правила — отдельно от БД.
Роль qa-runner решает другую задачу: проверить manifests и среду, запустить существующие команды, сообщить фактический результат, не ослаблять assertions и не очищать игровую базу. Общая процедура local-dev задаёт тестовую БД и сервисы именно этого проекта. Так написание проверки и её исполнение не смешиваются в одно обещание «всё зелёное».
Эти роли находятся в первом сохранённом пакете, но их фактический запуск отдельными субагентами на этом этапе не подтверждён. Ими могла руководствоваться основная сессия; можно было использовать их при разрешённом делегировании. Нельзя выдавать наличие Markdown-файла за состоявшуюся независимую проверку.
Передать Claude Code маршрут и ожидаемый результат
Для воспроизводимого поручения нужны исходное состояние, допустимые действия и признаки завершения. Пример ниже составлен по устройству существующих тестов, это не сохранённый исторический промпт:
Проверить выбранные порядки посещения трёх регионов
через настоящий движок и текущий контент.
Не подменять трудное условие прямой записью нужного флага.
После маршрута проверить завершение, ожидаемый исход,
итоговый объект того же героя и расход игрового времени.
Отдельно указать ветки и инфраструктурные риски вне этого набора.Человек выбирает, какой маршрут соответствует обещанию игры. Агент может собрать повторяющиеся действия в драйвер и перечислить перестановки, но не должен упростить прохождение телепортацией через условие, которое требуется проверить. Это видно только при чтении самого теста, а не его названия.
Маршрут через настоящий движок
В CampaignWalkthroughTest используется StoryDriver — помощник для прохождения через игровой движок. Тест загружает текущий контент, создаёт героя, проходит начало и выполняет последовательность выборов из авторских маршрутов.
Для трёх свободно посещаемых регионов II–IV перечислены все шесть порядков. Это конечный набор перестановок, который удобно сделать поставщиком данных. Ошибка, возникающая только при позднем посещении одного региона после другого, перестаёт зависеть от случайного выбора ручного проверяющего.
После регионов маршрут продолжается до завершения, эпилога и итогового наследия кампании. Проверяются не только отсутствие исключения, но и конкретные поля: история завершена, выбран ожидаемый исход, итоговый объект существует и относится к тому же герою.
Есть и проверка того, что выбранный герой не появляется второй раз среди неигровых персонажей. Это пример утверждения, которое родилось из устройства истории. Обычный тест HTTP 200 такого противоречия не обнаружит.
Дальше добавили неудобные сценарии
Следующие коммиты добавляют личные линии всех шести героев и маршрут со всеми опозданиями. Последний проверяет содержательное требование: пропущенный срок меняет историю, а не случайно лишает её продолжения. Отдельный тест смотрит расход календарного времени — успешный финал не должен скрыть сломанный календарь.
Шесть порядков регионов не означают все комбинации решений. Внутри остаются развилки и ресурсы. Поэтому от агента нужен отчёт о покрытом свойстве, а не итог «тупиков нет». Для HTTP есть другой слой: повтор запроса, чужая кампания, конфликт вкладок и закреплённый релиз.
Принять доказательство и назвать его предел
В итоговой точке продолжения от 21 сентября следующим шагом указан игровой тест людьми. Текущий автоматический набор не оценивает скуку, понятность подсказки и эмоциональную цену выбора. Человек может пройти допустимый путь и всё равно решить, что сцена не работает.
При подготовке статьи весь игровой набор заново не запускался. Основания разбора — код и история проверок, а не новый отчёт об успешном выполнении. Это тот же стандарт, который я требую от помощника: команда, версия, наблюдаемый результат и оставшееся ограничение.
Для следующего изменения я бы выбирал проверку по риску: новая фраза требует чтения в сцене, новое условие — сценария отказа и успеха, новый порядок глав — прохождения. Несколько агентов могут помочь собрать доказательства, но решение, достаточно ли их для выпуска игры, остаётся моим.
