# 19-я волна — оценка выполнимости в ограниченном бюджете

Выпуск содержит 40 задач, 20 пар, ID432–471; всего в наборе 471 задача.
Название остаётся **19-я волна**, текущая версия набора — **v0.19.1** от
21 октября 2026. Новых задач эта ревизия не добавляет. После калибровки
содержательные условия переработаны, а 18 октября в v0.19.0 исправлена граница
сервиса: скрытые данные и история вынесены из workspace в доверенный процесс хоста.
В v0.19.1 введён часовой санитарный лимит вместо 120 секунд, снят агентный
лимит шагов по умолчанию; своевременная правильная подача засчитывается даже при
последующем зависании финального ответа или процесса. Формальные ресурсные
бюджеты внутри задач не изменены. В задаче 410 также уточнены обязательные
дополнительные 2 ч. л. сахара и синоним картофеля; ожидаемые БЖУ/калории прежние.
Все приведённые ниже модельные результаты относятся к прежним снимкам.
Нового модельного результата для текущего протокола пока нет; итоговую приёмку
текущего кода нельзя подменять историческими тестами и прогонами.

## Что измеряется

Модель должна построить и подать решение либо проверяемое
свидетельство, что формальные условия выполнить нельзя. В поисковых задачах
нужны оценка достижимости 95%-го порога и допустимая стратегия с исполнением
или правильной остановкой. Основной результат — доля зачтённых задач;
полностью пройденные пары являются дополнительной метрикой.

Это тест всей агентной конфигурации: математического анализа, программирования,
использования инструментов, формата и процедуры подачи. Формальный бюджет
контракта и санитарный лимит работы агента — разные ограничения. Отдельного зачётного
пути «я лично не успею решить эту выполнимую задачу» нет: `budget_exceeded`
требует проверяемого препятствия в условиях задачи. Поэтому результат нельзя
называть чистой оценкой самооценки времени или общей алгоритмической
неразрешимости. Все отрицательные экземпляры имеют конечные свидетельства.

## Формат отказа и бюджет

С 18 октября 2026 способ отказа указан непосредственно в промпте: для контрактов —
полная внешняя JSON-структура и submit, для поиска — stop-план с точной вероятностью
и finish. В составных задачах явно показаны оба уровня certificate и положение
requirement. Невыполнение явно заданного формата или протокола — ошибка модели,
даже если математическое содержание правильное. Диагностическая перепаковка
ответа не даёт зачёта и не исправляет официальный результат.
Эти уточнения отсутствовали в замерах Opus/Haiku/Sonnet от 17 октября и в
сопоставимых запусках Astra/GLM/DeepSeek на том же архиве. Исправление сервиса
18 октября также меняет протокол исполнения и проверки истории; старые ответы
и scores не становятся результатами нового протокола автоматически.

Каждая задача имеет явный санитарный лимит **3600 секунд wall-clock** на работу
агента. Для зачёта `submit`/`finish` должен быть зарегистрирован доверенным
сервисом до истечения лимита, а ответ и полная история — пройти верификацию.
Последующее зависание финального ответа или процесса не отменяет такой зачёт.
Setup и верификация вне бюджета. JSON-файлы --file должны находиться
в workspace; это явно описано в промптах и документации. Ошибочный вызов сервиса
лишается зачёта даже после исправления. Одного текстового отказа, правильной
идеи или файла без предусмотренной команды подачи недостаточно.

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

В текущих раннерах обычные задачи и tool reflection тоже имеют лимит по
умолчанию 3600 секунд, а long-context сохраняет минимум 7200 секунд.
Агентные шаги по умолчанию не ограничены (`--recursion-limit 0`). Явный конечный
лимит разрешён для диагностики; применяются соответствующие минимумы задач,
а конфигурацию нужно указывать как отличающуюся от стандартной. Эти настройки
не меняют query/io, ёмкости, окна времени и другие ресурсы формальной задачи.

## Доверенный сервис и поддержанные режимы

`tools/taskctl` теперь является публичным транспортом, его можно читать.
Он не содержит скрытую цель, код переходов состояния, ключ подписи или историю.
В `.svc/` находится только публичный `connection.json`. Состояние, скрытые
данные и история запросов хранятся в памяти доверенного процесса хоста.
Агенту в Linux/bwrap доступен только сокет сервиса, смонтированный read-only.
Любой запрос через штатный клиент или напрямую через сокет проходит ту же
проверку и расходует те же квоты. Перезапись файлов workspace не стирает
предыдущие вызовы и ошибки.

При итоговой проверке `tools/taskctl`, `.svc/connection.json`, `contract.json`
и документация должны совпадать с исходными, в `.svc/` не допускаются другие
файлы. Проверяющий воспроизводит историю доверенного сервиса. Содержимое
рабочего каталога само по себе больше не служит доказательством этой истории.
Хост, раннер и его артефакты входят в доверенную часть системы.

Модельный запуск поддержан через `run-cli --isolation bwrap` и
`run-openrouter --isolation bwrap`, который использует изолированный CLI worker.
Нативные `run` и `run-pure`, OpenRouter без bwrap, RLI и Harbor export отклоняют
выборку с этими задачами до запуска модели. Для этих путей можно явно выбрать
старые задачи `--from-task 1 --to-task 431`. Полный набор по умолчанию содержит
19-ю волну и поэтому также требует поддержанного изолированного режима.

Для последующей CLI-перепроверки нужны сохранённый workspace и внешние файлы
хоста `trusted_service.json` и `execution.json`. Первый передаётся через
`verify-task --trusted-evidence`; второй должен находиться рядом. Проверяются
task ID, протокол, хеш контракта, хеш свидетельства, режим изоляции и исход
исполнения. Для зачёта после таймаута финального ответа/процесса нужны квитанция
хоста о своевременной подаче (`completion_receipt`) и полный успешный replay
с верификацией ответа. Одного файла, его mtime или времени, указанного агентом,
недостаточно. Поздняя подача и неверный ответ остаются ошибками.
Загрузка одного JSON через низкоуровневый Python-контекст — содержательная
диагностика, а не замена этих проверок.

`task.setup`, `task.apply_gold` и `task.verify` в одном процессе остаются
доверенным API для эталонов и локальной диагностики. После них обязателен
`task.cleanup(workspace)` в `finally`, включая неуспешные случаи. Эта возможность
не означает разрешение запускать модель в процессе хоста.

Результаты связываются с версией набора, `runtime_protocol` и
`task_contract_sha256`, включающим промпт, публичные файлы и временные ограничения.
Возобновление JSON от другой версии, протокола или контракта отклоняется:
для v0.19.1 нужен новый файл результата. Исторические результаты v0.19.0
не переписываются и не переименовываются в новый протокол. Название волны
при этом не меняется; хеш фиксирует конкретный снимок для воспроизводимости.

## Формальные задачи

14 контрактных пар теперь составные: каждая задача содержит три обязательства
из разных семейств. Для разрешения запуска нужны все три конструкции;
для остановки достаточно одного корректного препятствия. Ресурсы обязательств
раздельные, общий санитарный лимит агента — 3600 секунд. Форматы компонент
и внешних обёрток явно привязаны к каждому обязательству в его response_formats. Общий справочник
не требует угадывать, какая схема относится к соседним похожим контрактам.
Интервальные свидетельства принимают эквивалентные interval:[a,b] и start/finish;
противоречивые двойные поля отклоняются, математические условия не ослаблены.
Обе отрицательные метки impossible/budget_exceeded принимаются
при валидном свидетельстве, без скрытого требования авторской классификации.

Внутренние контракты требуют конструкции либо проверяемого свидетельства:
плотные difference constraints, назначения с условными ограничениями часов,
потоки с нижними ёмкостями и бюджетом стоимости, плотный GF(2), идентифицируемость
агрегатов на неотрицательных данных с совпадающими двойственными границами,
нормализация stateless-входов, DFA-кодек, многомерная целочисленная решётка,
раскраска/клика, аффинный GUID с окнами пропускной способности, ограниченные
диагностические запросы, preemptive scheduling с локальными окнами,
DAG с релизами и непрерывным выполнением на конечном числе исполнителей,
а также threshold/quorum gate graph.

Три семейства требуют совместного решения ограничений. Назначение работника
активирует ограничения часов; отдельная выполнимость matching и базовых часов
недостаточна. В перевозках один поток должен удовлетворять нижним/верхним
ёмкостям, балансам и стоимости; отрицательный ответ проверяется по двойственной
нижней оценке. В сборках один план соблюдает зависимости и занятость работников;
отрицательное свидетельство — перегрузка интервала с учётом окон из DAG.
Оптимальные авторские решения и скрытое разбиение работ в публичные данные
не включены. Эталон доказывает существование решения, но не гарантирует его
нахождение и своевременную подачу моделью в заданном лимите.

6 поисковых пар используют несколько шардов и каталог перекрывающихся
префиксных индексов. Каждый маршрут расходует query и io из двух общих квот.
Внутри шарда охват нескольких маршрутов равен максимуму префиксов, между
шардами складывается. Ровно одна цель равномерна среди кандидатов. Для search
нужен допустимый набор маршрутов с точной вероятностью >=95%, исполненный
до находки или до конца плана. Для stop требуется точный максимум достижимой
вероятности ниже95%. Диагностика count/describe стоит по1 единице обеих квот;
null-параметры нужно раскрыть до плана. Отрицательные ответы оставляют одну
ветвь неудач, поэтому адаптивность не улучшает максимум объединения маршрутов.
Оптимум проверяется host-side точным DP; код DP не попадает в workspace.

Подтверждённая находка засчитывается даже без корректного плана/диагностики.
Неверная оценка вероятности не отменяет реальную находку в пределах обеих квот.
Ошибочные команды, подделка found_id и превышение квот недопустимы.
Ненахождение при корректной95%-й стратегии не является ошибкой.

После submit/finish дополнительная финальная реплика не нужна для зачёта. В v0.19.1 зачёт
опирается на время завершения подачи по часам доверенного хоста и полную
проверку результата, поэтому задержка последующего диалога или завершения
процесса не теряет уже решённую задачу. Квитанция сама по себе доказывает только
своевременную команду, а не корректность решения. Файл без подачи, неправильный
ответ, нарушение квот и подача после лимита не засчитываются. Исторические
timeout-fail из v0.19.0 остаются результатами исходного протокола.

## Метрики и зависимости

40 задач содержат 20 положительных и 20 отрицательных контролей. Строгая пара
засчитывается только при обеих успешных половинах одного повторения; успехи
разных повторений не объединяются. Случайная находка может дать зачёт при
неверной стратегии, поэтому качество решения начать поиск сохраняется отдельно.
Эталонные решения не являются модельным результатом. Результаты разных
snapshot SHA256 нельзя смешивать как один неизменный тест.

У контрактов `decision_correct` теперь проверяет только объявленный класс
действия: `solved` либо остановка (`impossible`/`budget_exceeded`).
`response_correct` проверяет полный ответ, его свидетельство/конструкции
и соблюдение процедуры. Правильный класс с неверным сертификатом не даёт pass.
В старых результатах контрактный `decision_correct` совпадал с общим зачётом;
его нельзя задним числом трактовать как новую отдельную метрику.

14 контрактных пар содержат 84 вхождения компонентов: 14 положительных
спецификаций повторены по пять раз, 14 отрицательных встречаются по одному.
Следовательно, зависимость есть и между разными парами. Bootstrap по 20 парам
в исторических отчётах — описательная чувствительность к составу набора,
а не строгий 95% ДИ независимой популяции задач или повторных запусков.
Набор калиброван по Haiku и не является независимым holdout. Межзадачная память
агента должна быть отключена; отдельные workspace/контексты не устраняют
статистическую зависимость повторяющихся условий.

## Историческая проверка выпуска v0.19.0

18 октября 2026: полный pytest — 844 теста, эталоны всего набора — 471/471,
19-я волна из собранного wheel — 40/40. На Linux/bubblewrap все 40 эталонных
контроллеров прошли настоящий CLI-раннер и повторную проверку отдельным процессом
с внешней историей. Это проверка транспорта и измерителя, а не модельный score.
В том протоколе правильная подача с последующим зависанием процесса оставалась
timeout/fail: реальный лимит 120 секунд был проверен отдельно. Это историческая
проверка; она не подтверждает новые правила v0.19.1.

Прежние обходы через скрытую цель в клиенте и откат локального журнала закрыты.
Дополнительная проверка отклонила 168 некорректных подач и 5061 замену числовых
полей на некорректные значения. Это целевое покрытие, не доказательство полноты
верификатора; статистический ДИ для детерминированных контролей неприменим.
На дату этой проверки модельная калибровка выпущенного протокола ещё не была выполнена.

В Python без Unix-сокетов (включая Windows CI) зависимые проверки 19-й волны
явно пропускаются с причиной; CI продолжает проверять прежние 431 эталон и
независимые математические тесты. Это не означает успешную проверку 40 новых
эталонов на Windows. Прямой запуск сервиса на такой платформе завершается
понятной ошибкой. CI-скрипт освобождает ресурсы каждой задачи в finally.

В коллекторе того выпуска устранено тройное сложение одинакового token usage
из разных представлений ответа API. Это исправление действует на новые
запуски и не переписывает исходные JSON. Исторические raw tokens GLM/DeepSeek
нельзя трактовать как фактический расход или сравнение стоимости. Незавершённая
генерация при таймауте может не содержать usage даже после этого исправления.

Новые модули: hard_graphs.py,hard_algebra.py,hard_systems.py,hard_search.py,
coupled_assignment.py,coupled_flow.py,coupled_schedule.py,nonnegative_aggregate.py;
hard_contracts.py объединяет14пар. Исходные простые fixtures сохранены
для регрессионной проверки протокола, в suite они не запускаются.

## Историческая калибровка сложного снимка

Архив `ddd5595f32f4e22cb49f30d6c277c808c7036eea6653188c7f0c8801dec41d0c`
использовал прежние промпты и локальный сервис. Именно на нём прошли
575 целевых тестов и 40/40 эталонов локально и на Linux, включая независимые
малые exhaustive-сравнения, cross-rejection и replay. Эти числа не описывают
проверку текущего внешнего сервиса.

На этом архиве Claude Code 2.1.300, effort default, 120s, bwrap, concurrency4:
Opus5.5 — 35/40, Sonnet5.5 — 27/40, Haiku5.5 — 25/40 и 26/40. Диагностический
учёт своевременных правильных подач, потерянных при завершении CLI, даёт Opus
36/40 и Haiku26/40,27/40; это не новые прогоны и не исправление strict score.
DeepAgents0.6.12, high+thinking на том же архиве: GLM-5.3 — 4/40,
DeepSeek V4.1 Flash — 25/40. Astra high измерена только на специально выбранных
433/436/442 и получила 1/3. Харнессы и режимы рассуждения различаются;
эти результаты не изолируют качество весов и не являются новым рейтингом.

Объединение строгих зачётов разных конфигураций покрывает 39/40 ID. Для
оставшейся 442 независимо проверены корректные конструкции по публичным
условиям, включая сохранённый ответ Opus, но своевременного модельного зачёта
нет. Это доказательство существования ответа, не способности найти и подать
его за 120 секунд в том протоколе. Новых модельных результатов v0.19.1 нет.
Результаты новых проверок и запусков должны фиксироваться отдельно вместе
с актуальными manifest/хешами; эта историческая калибровка их не заменяет.