Историческое издание для чтения. Сверено 2026-10-04 с ревизией
61e75e9aa9a8719dfb480bf1f5226553b3a21d70. Протокол и результаты ниже сохраняют исходный исторический статус; это не новый запуск и не разрешение на выполнение. Английский оригинал.
Это отдельный эксперимент от контрольного и экспериментального пилота задачи 012. Go-анализатор в upkeep_study.go — оригинал работает автономно и не обращается к модели. Его отчёт не подтверждает пользу проверки, пока не собраны реальные строки автора и независимого потребителя. Результат проверки свидетельствует о процессе, а не доказывает истинность изменённой документации.
Зафиксируйте JSON-план до обращения к модели. Два конкретных начальных случая в corpus/upkeep_cases.json — оригинал детерминированно получаются из сохранённого corpus/backfill_cases.json — оригинал: замена решения A на B и сохранённый материал обработчика, который становится обрезанным. Начальные наборы проходят Go-валидатор OKF. Чтобы привязать случаи к реальному эксперименту, выполните:
go run ./benchmark/agent/upkeepstudy prepare \
-corpus benchmark/agent/corpus/backfill_cases.json \
-out /path/to/new-plan.json -id RUN_ID -repeats 1 \
-writer-model PINNED_WRITER -consumer-model PINNED_CONSUMER \
-writer-prompt-sha256 HASH -consumer-prompt-sha256 HASH \
-checker-sha256 HASH
Выходной файл создаётся только по новому пути и содержит SHA-256 исходного набора. В заметках запуска укажите ревизию источника, SHA-256 двоичного файла проверки, версии и настройки моделей автора и потребителя, хеши инструкций, время, набор, число повторений, доступ к инструментам, ограничения числа испытаний, времени, токенов и стоимости и правило остановки. UpkeepStudy хранит поля, проверяемые автономным анализатором; остальные сохраняются в заметках. Не меняйте план после просмотра ответов.
Для каждого случая и повторения создайте два чистых изолированных рабочих дерева с одинаковыми байтами InitialCode и InitialBundle. SHA-256, возвращённый upkeepStartingHash, записывается как starting_sha256 в обе строки автора. Используйте одинаковые модель автора, настройки и запрос задачи. Порядок групп случайный; для каждого автора начинайте новую сессию. Передавайте только Go-проекцию UpkeepCase.WriterRequest(); не отправляйте полный план, эталонный объект Expected или вопрос потребителя. Окружающие AGENTS или проектные инструкции не должны упоминать поддержку знаний ни в одной группе. В checker_off нет напоминания о поддержке знаний.
checker_on добавляет заранее зарегистрированное добровольно включаемое напоминание и вызывает закреплённый okf-upkeep с исходным состоянием, сохранённым до правок автора. Передайте автору первый результат needs_review; разрешите одну доработку и сохраните окончательный необработанный JSON. Проверка остаётся рекомендательной, чтобы обе группы могли завершить работу. В её конфигурации relevant_paths должны явно включать decision.go и handler-capture.txt, а набор должен находиться под bundle_root. До запуска модели проверьте в предварительном режиме, что оба пути дают needs_review; иначе воздействие для обрезанных доказательств ничего не меняет.
TargetCode в обеих группах. Сохраните фактический FinalCode и все материалы FinalBundle, а не заявленный самим автором флаг обновления. Проверьте каждый итоговый набор закреплённым Go CLI OKF и сохраните код завершения и статус в заметках. Для неудачного автора также создаётся строка с failure; не заменяйте и не удаляйте испытание незаметно.ConsumerQuestion и итоговый набор автора через UpkeepCase.ConsumerRequest(finalBundle). Не отправляйте полный план, задачу/целевой код или эталонный Expected. Сохраните SHA-256 видимых материалов и необработанный Observation: ответ, идентификаторы доказательств, токены и ошибки. Идентификатор сессии потребителя должен отличаться от всех сессий авторов.Анализируйте зафиксированный план и сохранённые строки:
go run ./benchmark/agent/upkeepstudy \
-plan /path/to/plan.json -rows /path/to/rows.json
Анализатор проверяет совпадение начальных хешей, одинаковый целевой код, статус включённой/выключенной проверки, независимые идентификаторы сессий, точные хеши наборов, видимых потребителю, и наличие процитированных материалов в наборе. doc_update_rate считает новый или изменённый Markdown-файл. concept_update_rate исключает index.md и log.md, чтобы изменение только журнала не считалось обновлением знаний. Удаления — отдельные показатели doc_deleted и concept_deleted; удаление устаревшей заметки не считается обновлением. Обе доли используют в знаменателе все заранее зарегистрированные случаи × повторения. answer_quality_rate — доля ответов, точно совпадающих с заранее зарегистрированным ответом или допустимым вариантом и содержащих ожидаемый идентификатор доказательства. Знаменатель также включает все случаи × повторения; устаревшие, неверные, отказные, не поддающиеся оценке и неудачные испытания остаются видны. Отчёт имеет valid только тогда, когда для каждой пары есть строки автора и потребителя без сбоев. Для малых выборок используйте описательные числа; проценты из внешних источников не являются утверждением о продукте.
Два зафиксированных случая используют вопросы о смене решения и неполных доказательствах из набора задачи 010. Сохранённый экспериментальный набор backfill уже исправлен, поэтому генератор строит для каждого случая состояние до изменений. Не добавляйте вопрос о текущем коде, пока у него нет отдельного изменения автора и доказательства, видимого потребителю; иначе он продублирует испытание смены решения.
valid означает соответствие сохранённых строк этому автономному контракту. Он не удостоверяет изоляцию среды модели или реальный вызов проверки/Go CLI программой запуска. Сохраняйте журналы команд, хеши двоичных файлов и необработанные метаданные адаптера рядом со строками; проверяйте их отдельно. Не выводите актуальность только из reviewed_updated.