Историческая редакция · 2026-10-04 · Сверено с ревизией 61e75e9aa9a8719dfb480bf1f5226553b3a21d70. Английский оригинал. Архивный протокол сохранён как историческое свидетельство; публикация не запускает его команды.

Протокол «до и после» для 004/005 (ещё не запускался с моделью)

Это отдельный эксперимент относительно основного сравнения контрольной группы с OKF в PILOT.md. Он сравнивает две ревизии библиотеки Go на одном замороженном входе, используя одинаковые модель, бинарный файл адаптера, настройки, промпт, часы, политику инструментов и порядок испытаний. Результатов модели пока нет. В частности, успешный парный Go-бенчмарк производительности в benchmarks/toolkit/ — оригинал не является результатом оценки качества агента.

Ревизии и страты

Страта Старый Go Исправленный Go Определяющий контракт Интерпретация
005 Исправления Markdown/расширений ed7ddc28cd127682023bd150ee377906b817e099 Закрепить чистый потомок 0f15ab4 Профиль даты, внешний источник 3fcbb9f828c2f23d109c855ee403c3a4c81f3a96 Сравнение регрессии/исправления в рамках одной спецификации.
004 Поддержка ревизии с датой и временем тот же старый коммит тот же исправленный коммит, явно instant-0b87c52 Новый внешний источник 0b87c52c6ef999286c745e19998fdfcd03d5dbee Поддержка нового нормативного контракта. Отклонение момента времени старой версией означает неподдерживаемую ревизию, а не дефект относительно её закреплённого контракта даты.

Учитывайте эти знаменатели отдельно. В старом CLI нет флага --temporal-profile; исправленный CLI по умолчанию использует старый контракт даты. Нельзя незаметно проверять старую группу по новой SPEC или называть отклонённую дату со временем ошибкой старой спецификации. Записывайте ожидаемую неспособность старой группы в 004 как revision_unsupported — отдельный результат проверки возможностей, вне operational_failure и знаменателя фактических ответов LLM; для этого случая нет ответа модели в старой группе, который можно сопоставить в паре. При этом показывайте число таких результатов в полном учёте эксперимента. Неожиданные сбои CLI остаются операционными сбоями.

Зафиксируйте as_of (дату или дату со временем и смещением, по ситуации); ни одна группа не должна определять устаревание по машинным часам. Сторонний снимок 005 — fixtures/interoperability/foreign-68ce7a0/ — оригинал; его происхождение и ожидаемая диагностика указаны в манифесте. Выбранные файлы — проверка соответствия, а не вопросы агенту. Составьте фактические вопросы, ответы на которые независимо представлены в исходных материалах обеих групп. Некоторые вопросы primary_realistic.json цитируют исходный код CLI после исправления, поэтому этот файл нельзя повторно использовать без изменений в данном сравнении.

Автономная предварительная проверка

Команды ниже извлекают историческое дерево, не изменяя рабочее дерево и не обращаясь к сети. Запускайте из корня репозитория. Зафиксируйте исправленный коммит до запуска модели, затем сохраните все значения SHA-256 и версию Go рядом с планом. Исправленное рабочее дерево при закреплении должно быть чистым.

set -e
set -o pipefail
export GOPROXY=off GOSUMDB=off GOTOOLCHAIN=local
OLD=ed7ddc28cd127682023bd150ee377906b817e099
test -z "$(git status --porcelain --untracked-files=all)" || { echo 'commit all experiment inputs first' >&2; exit 1; }
NEW=$(git rev-parse HEAD)
RUN_DIR=$(mktemp -d /private/tmp/okf-agent-before-after.XXXXXX)
mkdir -p "$RUN_DIR/old"
git archive "$OLD" | tar -x -C "$RUN_DIR/old"
GOCACHE="$RUN_DIR/gocache" go -C "$RUN_DIR/old" build -o "$RUN_DIR/old-okf" ./cmd/okf
GOCACHE="$RUN_DIR/gocache" go build -o "$RUN_DIR/new-okf" ./cmd/okf
if "$RUN_DIR/old-okf" validate --path fixtures/interoperability/foreign-68ce7a0 --json --as-of 2026-09-26 > "$RUN_DIR/old-005.json"; then OLD_EXIT=0; else OLD_EXIT=$?; fi
if "$RUN_DIR/new-okf" validate --path fixtures/interoperability/foreign-68ce7a0 --json --temporal-profile date-3fcbb9f --as-of 2026-09-26 > "$RUN_DIR/new-005.json"; then NEW_EXIT=0; else NEW_EXIT=$?; fi
test "$OLD_EXIT" -eq 1 && test "$NEW_EXIT" -eq 0
test -s "$RUN_DIR/old-005.json" && test -s "$RUN_DIR/new-005.json"
printf 'old_exit=%s new_exit=%s\n' "$OLD_EXIT" "$NEW_EXIT"
"$RUN_DIR/new-okf" validate --path fixtures/v02/temporal-profiles/instant --json --temporal-profile instant-0b87c52 --as-of '2026-09-26T12:00:00+07:00' > "$RUN_DIR/new-004.json"
shasum -a 256 "$RUN_DIR/old-okf" "$RUN_DIR/new-okf" "$RUN_DIR/old-005.json" "$RUN_DIR/new-005.json" "$RUN_DIR/new-004.json"
go version

Итоговый эксперимент должен вызывать каждый закреплённый бинарный файл, а не собирать старую управляющую программу в старом рабочем дереве. Записывайте NEW как полный ID коммита, хеш фикстуры, хеши обоих бинарных файлов, код завершения, диагностику и длительность. Ожидаемый OLD_EXIT=1 вызван старой диагностикой 005; при любой другой паре кодов завершения предварительная проверка завершается ошибкой. Итоговая управляющая программа также должна сохранять ненулевые коды завершения и их JSON-отчёты. Проверяйте случаи 005 профиля даты по неизменённому документу 3fcbb9f, а случаи моментов времени — по 0b87c52. Старый исходный код содержит только spec-v02.md; внутри собственного дерева он не может пройти текущую проверку pinnedInputs для документа моментов времени.

На выбранном снимке из пяти файлов эта автономная команда зафиксировала 12 ошибок со старым CLI и 0 с исправленным CLI профиля даты (в обоих случаях 0 предупреждений без --strict). Эти количества проверяют поведение валидатора, а не ответы агента.

Протокол запуска модели, который нужно реализовать до запроса ограниченного запуска

  1. Закоммитьте небольшой корпус вопросов, стабильный между ревизиями. Для каждого случая сохраните одинаковые байты и вопрос для старой/новой группы, эталонный фактический ответ, ссылку на источник, страту контракта и ожидаемую возможность. Включите как минимум пункт журнала с переносом строк, заголовок/вступление корня, неизвестное корневое поле upkeep — оригинал, маркер сноски внутри встроенного кода и временной случай «дата против даты со временем». Проверьте корпус автономными AAA-тестами и вычислите его хеш до первого вызова модели.
  2. Передавайте обеим группам одинаковый видимый модели промпт и обычные исходные артефакты. Добавляйте только соответствующую проекцию/результат CLI с метками SHA бинарного файла и ревизии контракта. Используйте один бинарный файл адаптера, фиксированные ID и версию модели, настройки рассуждений и разрешения инструментов. Чередуйте или рандомизируйте парный порядок с сохранённым начальным числом; выполните минимум два повтора, чтобы выявить вариативность. Адаптер должен начинать новый разговор для каждого испытания. Исходный текст остаётся недоверенным свидетельством и не может изменять политику экспериментальной программы.
  3. Для каждого испытания создайте изолированный пакет и вызовите выбранный бинарный файл с validate --json --as-of 2026-09-26 и, где применимо, parse <file> --json --as-of 2026-09-26; команды parse старой и новой версий принимают --as-of. Используйте селектор даты только с новым бинарным файлом для страты 005. Для 004 используйте исправленный селектор моментов времени и замороженное --as-of 2026-09-26T12:00:00+07:00 и для validate, и для parse; зарегистрируйте неподдерживаемую ревизию старого CLI как результат проверки возможностей без вызова модели. До вызова модели сохраните код завершения процесса, хеш stdout/stderr, разобранную диагностику, хеш команды/аргументов и длительность. Сохраняйте строку даже при сбое CLI. Ошибка запуска процесса, аварийное завершение, неподдерживаемый вызов или неразбираемый вывод — это operational_failure; не просите модель угадывать и не оценивайте это как фактическую ошибку. Корректно сформированный отчёт валидации может иметь ненулевой код завершения из-за диагностики: показывайте такой отчёт модели и отдельно классифицируйте каждое диагностическое сообщение по закреплённой SPEC. Таким образом, ложноположительные срабатывания старого CLI в 005 остаются самим проверяемым механизмом, а не отсутствующими испытаниями модели.
  4. Предзарегистрируйте число случаев, повторы, все ожидаемые строки, допустимые варианты ответов, знаменатель, правила признания запуска недействительным, мягкие остановки по наблюдаемым токенам/стоимости и жёсткие пределы вызовов/времени. Сохраните план до первого платного вызова и синхронизируйте каждую строку. Анализируйте correct, stale, wrong, refusal, ungradable и operational_failure отдельно; отсутствующие строки остаются в знаменателе завершённости. Опубликуйте исходные строки, парную таблицу по стратам, сбои и ограничения. При малом n сообщайте только описательные различия.

Текущий okf-agent-eval не может выполнить этот протокол запуска модели без изменений: exposeGoCLI вызывает встроенный internal/okfcli.Run, жёстко задаёт профиль моментов времени и отбрасывает корректно сформированный отчёт валидации, если команда возвращает ненулевой код. Путь внешнего бинарного файла должен сохранять такие отчёты, включая старую ложноположительную диагностику. pinnedInputs также требует, чтобы -commit совпадал с HEAD этого рабочего дерева.

Исторический коммит появился до создания benchmark/agent — оригинал. Простая передача старого SHA в -commit или использование -exploratory ошибочно обозначили бы текущий код как базовую версию. Добавьте в управляющую программу Go вход для закреплённого внешнего CLI, записывайте его SHA для каждой группы и явно задавайте временной селектор; другой вариант — написать небольшой слой оркестрации на Go с существующими контрактами Runner, Row и анализатора. Сохраняйте адаптер и оценщик неизменными для обеих групп. Пока это не реализовано и разрешённый запуск модели не завершён, измерение «до/после» для задачи 012 остаётся открытым.