Многораундовое доказательство сложной теоремы

Текст

---
name: siege
description: "Работает над одной сложной математической задачей по раундам: в каждом раунде судья (judge) пишет несколько самодостаточных вопросов, независимые исполнители (workers) отвечают на них, а судья ведёт реестр (ledger) того, что доказано, опровергнуто и остаётся открытым, пока судья не завершит работу или не кончатся раунды; после этого proof.md прямо говорит, что доказано, а что нет. Запуск занимает часы и десятки запусков исполнителей. Использование: /math-proof:siege [настройки вида NAME=value] <задача, изложенная полностью, или путь к файлу с ней>."
argument-hint: "[NAME=value ...] [DIR=run-directory] <problem statement | problem-file>"
disable-model-invocation: true
disallowed-tools: WebSearch, WebFetch, AskUserQuestion
allowed-tools: Read, Write, Edit, Glob, Grep, Agent, Bash(python3 ${CLAUDE_SKILL_DIR}/scripts/ledger.py *), Bash(python3 ${CLAUDE_PLUGIN_ROOT}/skills/siege/scripts/ledger.py *), Bash(python ${CLAUDE_SKILL_DIR}/scripts/ledger.py *), Bash(python ${CLAUDE_PLUGIN_ROOT}/skills/siege/scripts/ledger.py *), Bash(mkdir *), Bash(cp *), Bash(mv *), Bash(cat *), Bash(test *), Bash(ls *), Bash(wc *), Bash(cmp *), Bash(grep *), Bash(printf *), Bash(echo *)
---

math-proof: siege

Подход

Скилл работает над одной задачей не более MAX_ROUNDS раундов. В каждом раунде судья пишет несколько самодостаточных вопросов, не более WAVE штук до раунда ESC_ROUND. Ниже в шагах они называются запросами (queries). Каждый вопрос уходит свежему исполнителю, который видит только этот вопрос и условие задачи. Судья читает ответы, переписывает сводку хода работы и дополняет реестр утверждений, помеченных PROVED (доказано), REFUTED (опровергнуто) или OPEN (открыто). Одно из утверждений — цель, она задаётся в раунде 1; судья может поставить новую цель в более позднем раунде, в частности поднять её до более значимого утверждения, когда прежнее доказано (доказанная цель остаётся в реестре как запасной результат, к которому судья возвращается, если две волны не приблизили поднятую цель; когда цель поднята, ты сообщаешь об этом пользователю и копируешь доказанный результат в DIR/result-so-far.md). Когда в ответе есть полное письменное доказательство или опровержение цели, ещё два исполнителя проверяют именно этот текст строка за строкой. Как только обе проверки пройдены, судья завершает работу или поднимает цель. До раунда MIN_ROUNDS это единственный способ завершить. Начиная с раунда ESC_ROUND, если полного доказательства или опровержения нет, в раунде может быть до WAVE_DEEP вопросов для исполнителей с повышенным усилием. Все они, кроме не более чем двух, нацелены на то единственное утверждение, которого всё ещё не хватает в доказательстве. Когда раунды заканчиваются, судья пишет самодостаточный proof.md, исполнитель его проверяет, а судья дорабатывает его до окончательного вида. Если цель, на которой закончился запуск, не была и доказана, и дважды проверена в ходе раундов, перед окончательной доработкой проходят ещё дополнительные проходы доработки и последняя волна полных попыток доказательства. В proof.md есть раздел Status, где прямо сказано, что доказано, а что нет. Этот раздел — только сводка: математикой ты не занимаешься сам и в точности следуешь шагам ниже, запуская свежего субагента на каждый шаг судьи и на каждого исполнителя.

Ты — ОРКЕСТРАТОР (ORCHESTRATOR) этого протокола. Математикой ты не занимаешься и не судишь о ней: судейство выполняют свежие субагенты math-proof-judge, по одному на шаг, а рассуждения — свежие субагенты math-proof-worker или math-proof-worker-deep, по одному на запрос (какой из двух, определяется номером раунда — см. Rules). Твоя задача — выполнять шаги ниже в точности, держать файлы в порядке, действовать по единственному механическому вердикту, который печатает скрипт учёта, и никогда не пропускать, не объединять и не переставлять шаги из-за того, что задача кажется лёгкой или трудной. Не читай файлы ответов исполнителей сам (используй test -s, чтобы проверить, существует ли файл; закончен ли он, решает скрипт учёта, а не ты); нигде, где это прочитает судья, не излагай математику своими словами: передавай файлы, а не пересказы. Работай без присмотра до конца: отвечать на вопросы некому.

Аргументы. Вызывающее сообщение выглядит так: $ARGUMENTS В нём указаны задача и, при желании, настройки. Читай его так. Токены вида NAME=value в его начале, где NAME — слово из двух или более заглавных букв и подчёркиваний, а value — целое число (а для DIR — путь, в кавычках, если в нём есть пробелы), — это настройки (семь ниже или DIR, каталог запуска; любое другое такое NAME — ошибка, см. Settings); убери их. Если остаётся одна строка, которая целиком — после удаления окружающих пробелов и одной пары обрамляющих кавычек, с чтением экранированных обратной косой пробелов как пробелов — является путём к существующему файлу (в нём могут быть пробелы; проверяй через Read или Glob, а не через оболочку), этот файл и есть файл задачи; если такого файла нет, а остаток может быть только путём к файлу — одна строка, оканчивающаяся на .md, .txt или .tex, или один токен (без пробелов после снятия кавычек), содержащий «/» или «\», — сообщи пользователю одним предложением, что файла по искомому абсолютному пути нет (назови этот путь) и что задачу можно вместо этого дать целиком текстом после команды, и остановись; в остальных случаях всё оставшееся до конца сообщения И ЕСТЬ условие задачи, дословно — математика, переносы строк и всё прочее (MAX_ROUNDS=8 — это настройка; «n=3», «N=pq», «AB=AC» и «f(x)=…» — математика). Каталог запуска DIR по умолчанию — ./math-proof-run в текущем каталоге; ниже везде используй абсолютный путь к DIR. Если в сообщении нет ни читаемого файла задачи, ни текста задачи, скажи об этом в одном-двух предложениях — с указанием использования, /math-proof:siege [NAME=value …] <условие задачи или путь к файлу с ним>, и что остановленный запуск возобновляется повторной подачей исходной строки в том же каталоге, — и остановись. Настройки (Settings) (используй их, если вызывающее сообщение не переопределяет их по имени): ESC_ROUND = 4 (раунд эскалации: начиная с раунда ESC_ROUND, если цикл всё ещё идёт, предел волны растёт, каждый исполнитель — это math-proof-worker-deep, а в задании на планирование появляются пункты эскалации); WAVE = 4 запроса в раунде не более, в раундах до ESC_ROUND, и WAVE_DEEP = 10 запросов в раунде не более, начиная с раунда ESC_ROUND; MAX_ROUNDS = 14; MIN_ROUNDS = 4 (судья может свободно завершать работу начиная с раунда MIN_ROUNDS, раньше — только при проверенной цепочке в реестре; решает скрипт); REFINE_STEPS = 2; MAX_COMMIT = 9 (оба относятся к ПОЛНОМУ хвосту доказательства; запуск, чья итоговая цель была заверена в ходе раундов, получает КОРОТКИЙ хвост — см. «Хвост доказательства»). Вызывающее сообщение может переопределить любую из этих семи настроек по имени токенами вида NAME=value (например, MAX_ROUNDS=8 WAVE_DEEP=6), поставленными перед задачей, в начале вызывающего сообщения: используй значения как заданы, а токен такого вида (NAME — слово из двух или более заглавных букв и подчёркиваний, value — целое число), чей NAME не входит ни в семь, ни в DIR, считай ошибкой — сообщи пользователю одним предложением, что NAME не является настройкой /math-proof:siege, что допустимые имена — DIR, ESC_ROUND, WAVE, WAVE_DEEP, MAX_ROUNDS, MIN_ROUNDS, REFINE_STEPS и MAX_COMMIT, и что если токен — часть самой задачи, то задачу можно дать путём к файлу, — и остановись до создания чего бы то ни было. (Ведущий токен, у которого левая часть — одна буква или не все заглавные, либо правая часть — не целое число, а также любой «=» глубже внутри условия — это математика, а не настройка.) Везде ниже, где названа настройка, имеется в виду действующее значение. Скрипт учёта — scripts/ledger.py в папке самого скилла: python3 ${CLAUDE_SKILL_DIR}/scripts/ledger.py (ниже называется SCRIPT). Если эта подстановка не заполнена — путь перед /scripts не существует — используй ${CLAUDE_PLUGIN_ROOT}/skills/siege/scripts/ledger.py, а если и она не заполнена, найди через Glob **/skills/siege/scripts/ledger.py в ~/.claude и используй его абсолютный путь (если подходит несколько — самый новый); в любом случае бери путь к скрипту в кавычки в команде, если он содержит пробелы. Перед Setup запусти SCRIPT один раз без дополнительных аргументов: он должен напечатать строку, начинающуюся с «usage:». Если же Python запускается, но сообщает, что не может открыть файл скрипта, значит, неверен путь, а не Python: определи его заново по запасным вариантам выше и запусти ещё раз, а если ни один ledger.py не найден, сообщи пользователю, что файлов плагина нет там, где ожидалось (переустанови math-proof через /plugin), и остановись. Если же оболочка говорит, что python3 не найден, или приходит что-то иное, что не является строкой usage (в Windows ответ, что Python «не найден» и его можно установить из Store, — это тот же случай), дальше используй python вместо python3 в SCRIPT и запусти ещё раз; если и это не удалось, сообщи пользователю одним-двумя предложениями, что /math-proof:siege не смог запустить свой скрипт учёта, — процитируй команду и ответ оболочки, — что нужен Python 3.7 или новее в PATH под именем python3 или python и что та же строка, поданная заново, сработает, когда это будет исправлено; затем остановись.

Setup

1. Если DIR/state.md уже существует, это возобновление: проверь, что существующий DIR/problem.md — это та же задача, что тебе дали (сравни текст, не учитывая различия в пробелах и концах строк; для файла — cmp) — если они различаются, скажи одним предложением, что в DIR лежит запуск по другой задаче и что DIR=<другой каталог> выбирает новый, и остановись; если это та же задача и в state.md записано «phase: finished», этот запуск завершён: скажи, где лежит DIR/proof.md (и DIR/result-so-far.md, если он есть), что DIR=<другой каталог> начинает новый запуск, и остановись; в остальных случаях прочитай DIR/problem.md целиком, прочитай state.md и возобнови с той фазы, которая в нём записана, а не начинай заново, никогда не повторяя шаг, чьи выходные файлы существуют, и никогда не переписывая DIR/problem.md (если вызывающее сообщение задаёт настройки, отличающиеся от записанных в state.md, добавь одну строку о том, что запуском управляют записанные, в том же сообщении, где идёт твой следующий вызов инструмента — это уведомление, а не остановка). Если записанная фаза — волна, начни с SCRIPT answers по основам имён запросов этой волны (см. правило волны в Rules) и запускай исполнителей только для запросов, о которых скрипт не сообщает «отвечен», каждому частичному — с абзацем {EARLIER}; этот запуск считается первым запуском волны, поэтому единственный повторный запуск после него по-прежнему положен. Если запрос уже отвечен, а строки индекса для него нет, добавляется строка «{Q} | answered | (finished before this session resumed)»; если у запроса уже есть строка индекса, вторая не добавляется — его новый статус дописывается в ту строку как « | re-run: status | abstract». Иначе создай DIR и DIR/judge/ (mkdir -p) и положи задачу в DIR/problem.md: если она пришла файлом, скопируй этот файл туда байт в байт через cp; если она пришла текстом в вызывающем сообщении, запиши ровно этот текст (ничего не добавляя, не убирая и не переформулируя) в DIR/problem.md. Затем следующим же действием прочитай DIR/problem.md целиком — ты вставляешь его текст в каждое задание судье и каждый промт исполнителя (см. Rules).
2. Запиши DIR/state.md (протокол math-proof siege, семь настроек с действующими значениями — с пометкой тех, которые переопределило вызывающее сообщение, — «phase: round 1 plan, attempt 1»). При возобновлении управляют значения, записанные в state.md.

Цикл раундов — для r = 1, 2, …, MAX_ROUNDS

(a) Планирование (Plan). Запусти ОДНОГО math-proof-judge, чей промт — это PLAN BRIEF ниже, где подставлены {r}, DIR и зависящие от раунда слоты (а при повторной попытке сверху добавлен абзац с поправкой, который дал тебе скрипт). Слоты: {CAP} — предел числа запросов в этом раунде: настройка WAVE при r < ESC_ROUND, настройка WAVE_DEEP при r ≥ ESC_ROUND — и то же число идёт в команду проверки из (b); {MAX_ROUNDS} — настройка MAX_ROUNDS, записанная числом; {HORIZON}, {CONCLUDE_RULE}, {ESC_SUMMARY} и {ESC_WAVE} — тексты, приведённые после задания для данного r (несколько из них пусты до раунда ESC_ROUND: пустой слот не вставляет ничего, даже пробела или пустой строки). Это попытка 1 раунда r. (b) Проверка (Check). Сначала, если DIR/judge/screen_r{r-1}.md существует, а в строках раунда r−1 в DIR/index.md ещё нет вердикта проверки, допиши каждый его вердикт (« | OK» или « | DEGENERATE: …») в строку индекса соответствующего запроса — обычная работа с файлами; при вердикте DEGENERATE ничего повторно не запускается. Затем выполни SCRIPT check DIR {r} {CAP} {MIN_ROUNDS} {attempt} ({CAP} — предел этого раунда, WAVE или WAVE_DEEP, в точности как в (a) — если передать WAVE в раунде ESC_ROUND или позже, часть волны будет молча отложена в сторону). Скрипт сам нумерует строки реестра раунда и дописывает их в DIR/ledger.md и печатает ровно одну строку-вердикт; действуй по её первому слову (если же он печатает строку, начинающуюся с ERROR:, сама команда составлена неверно — сначала DIR, абсолютным путём, затем четыре числа; исправь команду и запусти заново, это не считается попыткой планирования):

• WAVE n FLOOR f … — скопируй DIR/round{r}_summary.md поверх DIR/summary.md, запомни f (наименьшее число запросов этой волны, которые могут вернуться отвеченными или частичными, см. Rules), выдай ниже уведомление о смене цели, если оно положено, затем перейди к (c) с файлами запросов DIR/round{r}_q1.md … DIR/round{r}_q{n}.md (скрипт при необходимости перенумеровал их подряд).
• CONCLUDE … — скопируй DIR/round{r}_summary.md поверх DIR/summary.md, запиши строку-вердикт в state.md как причину окончания цикла, выдай ниже уведомление о смене цели, если оно положено, и выйди из цикла к хвосту доказательства.
• RETRY: <correction> — повтори шаг планирования (a) как следующую попытку, поставив текст после «RETRY: » как добавленный первый абзац задания; затем снова выполни (b), увеличив номер попытки на единицу.
• TAIL: <reason> — шаг планирования провалился три раза; запиши причину в state.md, скопируй DIR/round{r}_summary.md поверх DIR/summary.md, если он существует и не пуст, и выйди из цикла к хвосту доказательства — если только нет ни DIR/summary.md, ни какого-либо файла .answer.md или .partial.md (не из чего составлять черновик): тогда остановись и доложи.

Уведомление о смене цели: при вердикте WAVE или CONCLUDE, если в ответе на запуск планирования, принятом этим вердиктом (последняя попытка), есть предложение, начинающееся с «Goal change:» (судья в этом раунде заменил цель, поднял её или вернулся к цели — пункт 2 задания), передай пользователю это предложение в кавычках одной строкой текста в том же сообщении, где идёт твой следующий вызов инструмента (это уведомление, а не вопрос: сообщение из одного текста завершило бы твой ход — не останавливайся и не жди), и запиши ту же строку в state.md. Если предложение начинается с «Goal change: raised», сначала скопируй файл или файлы, которые оно называет как содержащие доказательство прежней цели (test -s для каждого), в DIR/result-so-far.md — один файл: cp; несколько: одним cat <файлы в названном порядке> > DIR/result-so-far.md (каждый заканчивается своей завершающей строкой, которая их разделяет) — перезаписав любой прежний result-so-far.md, и закончи свою строку словами «доказанный на данный момент результат лежит в DIR/result-so-far.md». Если предложение не называет файла, возьми <stem> из локатора после последнего «—» в последней строке вида «N. PROVED: [GOAL] …» в DIR/ledger.md (grep) и используй DIR/<stem>.answer.md, либо DIR/<stem>.partial.md, если существует только он; сначала проверь каждый файл через test -s, и если ни одного нет, пропусти копирование и скажи об этом в своей строке. Этот файл нужен пользователю, который остановит запуск здесь; ничто позже его не читает, а proof.md остаётся результатом запуска. (В задаче, где утверждение зафиксировано, поднятия не бывает — поднимать не до чего, — поэтому файл не записывается; замена цели всё равно объявляется.) В любом случае запиши в state.md номер R последнего раунда, чья волна действительно прошла (R = r после завершения (c)–(d); если цикл покинут в раунде r до его волны, R = r−1; R = 0, если ни одна волна не проходила). DRAFT BRIEF нуждается в нём. (c) Волна (Wave). Проведи волну из файлов запросов раунда (см. Rules: по одному исполнителю на файл — math-proof-worker в раундах до ESC_ROUND, math-proof-worker-deep начиная с раунда ESC_ROUND, — все в одном сообщении, вердикты answers скрипта, строки индекса, один повторный запуск неотвеченных запросов, затем правило остановки FLOOR). (d) Скрининг (без запуска). Отдельного шага скрининга нет: судья планирования следующего раунда сам проверяет ответы этой волны (PLAN BRIEF, пункт 0) и пишет DIR/judge/screen_r{r}.md; шаг (b) следующего раунда копирует его вердикты в индекс. Обнови state.md («phase: round {r+1} plan, attempt 1»; R = r) и продолжай цикл.

Хвост доказательства (после окончания цикла по CONCLUDE, TAIL или завершению раунда MAX_ROUNDS)

Сначала определи форму хвоста: запусти SCRIPT gate DIR. Если его вывод начинается с CONCLUDE, реестр утверждений содержит главную цель, решённую и заверенную двумя отдельными проверочными запросами, и хвост КОРОТКИЙ: (e) черновик, (f) без шага доработки, без шага выбора — построй DIR/r3_verify.md сам конкатенацией в оболочке, описанной в (g), и не пиши файлов r3_q —, (h) волна фиксации, состоящая из одного DIR/r3_verify.md, (i) окончательная доработка. Если он печатает что-то иное (обычно REJECT: …), хвост ПОЛНЫЙ: шаги (e)–(i) в точности как написано ниже — кроме того, что строка, начинающаяся с ERROR:, означает, что сама команда gate составлена неверно (сначала DIR, абсолютным путём): исправь её и запусти заново, прежде чем принимать решение. Запиши «tail: short» или «tail: full» и строку gate в state.md. Два запасных варианта защищают короткий хвост. Если его волна только проверки заканчивается после одного повторного запуска без DIR/r3_verify.answer.md, переключись на ПОЛНЫЙ хвост с (g) (запиши «tail: short, then full — no verify answer»). А если ПЕРВЫЙ ответ окончательной доработки короткого хвоста начинается с «MAIN CLAIM: NOT PROVED» (проверь это до автономной проверки grep из шага (i)), заверенная цепочка не пережила проверочный запрос — запиши «tail: short, then full» в state.md, переименуй DIR/r3_verify.md и (если он есть) DIR/r3_verify.answer.md в DIR/r3_verify.first.md / DIR/r3_verify.first.answer.md, и аналогично любой DIR/r3_verify.partial.md в DIR/r3_verify.first.partial.md (дописав « | renamed r3_verify.first» к строке индекса r3_verify), и выполни (g), (h) и (i) ещё раз как в ПОЛНОМ хвосте (судья выбора тогда видит proof.md судьи окончательной доработки и, по имени в индексе, первый отчёт проверки); этот запасной вариант применяется не более одного раза, и второй проход доводит (i) до конца, какова бы ни была первая строка его ответа. (e) Черновик (Draft). Один math-proof-judge с DRAFT BRIEF ({R} из state.md; {PARTIALS} — это текст, приведённый после DRAFT BRIEF, когда хвост ПОЛНЫЙ и R ≥ ESC_ROUND, и пустой в остальных случаях — КОРОТКИЙ хвост или R < ESC_ROUND; если R = 0, замени в брифе оговорку «результаты последнего раунда» на «(ни одна волна не завершилась до конца раундов — работай по сводке и реестру)») → DIR/proof.md. Применяется правило дополнительных запросов (см. Rules; этот повторный запуск, если он происходит, — часть этого шага). Если DIR/proof.md не существует к концу шага, запусти судью черновика ещё раз с добавленным первым абзацем «DIR/proof.md не был записан; запиши его сейчас по материалам, названным ниже.»; если и после этого его нет, остановись и доложи. (f) Доработка (Refine), REFINE_STEPS раз в ПОЛНОМ хвосте (шаги называются refine_2, refine_3, … по порядку, их REFINE_STEPS штук), в КОРОТКОМ хвосте вообще не выполняется: по одному math-proof-judge с REFINE BRIEF на каждый (правило дополнительных запросов действует, один раз на шаг). (g) Выбор (Select). Один math-proof-judge с SELECT BRIEF → до MAX_COMMIT файлов DIR/r3_q{k}.md и ровно один DIR/r3_verify.md. Если DIR/r3_verify.md после этого не существует, создай его в оболочке, ничего не перепечатывая, как конкатенацию: строк «Документ ниже — черновик доказательства. Проверь рассуждение шаг за шагом: для каждого неравенства, перестановки, цитируемого результата и «отсюда следует» спроси, действительно ли это следует так, как написано. Перечисли все ошибки и пробелы по убыванию серьёзности и прямо скажи, доказано ли главное утверждение.», пустой строки, строки «## Черновик доказательства», пустой строки и файла DIR/proof.md. (h) Волна фиксации (Commit wave). Запусти каждый DIR/r3_q{k}.md (в КОРОТКОМ хвосте их нет) плюс DIR/r3_verify.md как одну волну (для этой волны шага скрининга нет). (i) Окончательная доработка (Finalize). Один math-proof-judge с FINALIZE BRIEF ({PARTIALS_FIN} — текст, приведённый после FINALIZE BRIEF, когда хвост ПОЛНЫЙ и R ≥ ESC_ROUND, и пустой в остальных случаях) → итоговый DIR/proof.md. Затем автономная проверка: выполни grep -noE 'r[0-9]+_q[0-9]+|round[0-9]+_q[0-9]+|extra_q[0-9]+|r3_verify|[A-Za-z0-9_]+\.answer\.md|[A-Za-z0-9_]*summary\.md|synthesis\.md|ledger\.md|notes\.md|index\.md' DIR/proof.md || true (обычная работа с файлами; математику ты не читаешь; пустой вывод означает, что proof.md чист). Если он что-то печатает, proof.md всё ещё ссылается на файлы запуска, которые рецензент открыть не может: запусти судью окончательной доработки ЕЩЁ ОДИН раз с FINALIZE BRIEF, перед которым стоит добавленный первый абзац «DIR/proof.md всё ещё ссылается на файлы запуска (grep нашёл: {совпадения, не более десяти, через запятую}). Рецензент читает один proof.md и открыть их не может. Перепиши DIR/proof.md так, чтобы каждое рассуждение, на которое он опирается, было полностью выписано внутри самого proof.md, без ссылок на какие-либо файлы этого каталога.», запиши «standalone-check: resent» в state.md и прими любой proof.md, который оставит этот запуск (проверку не повторяй). Обнови state.md («phase: finished»). Ответь пользователю: где лежит proof.md, сколько раундов прошло и почему цикл закончился (строка-вердикт скрипта), сколько запросов исполнителям было запущено, сколько из них отвечено и сколько закончились частичными, заменялась ли или поднималась ли цель (одна строка, из state.md; если DIR/result-so-far.md существует, скажи, что в нём лежит прежний результат в том виде, как его написал исполнитель, проверенный только в той мере, как записано в строке о смене цели, и что proof.md и его раздел Status заменяют его), и абзац Status судьи из его ответа окончательной доработки в виде цитаты. Не пересказывай и не оценивай математику сам.

Правила, действующие на всём протяжении

• Каждый шаг судьи и каждый исполнитель — это НОВЫЙ запуск субагента (инструмент Agent) с явно заданным subagent_type; никогда не опускай его. Субагенты поставляются вместе с этим плагином, и в твоём списке агентов они обычно показаны под именами с областью плагина — math-proof:math-proof-judge, math-proof:math-proof-worker, math-proof:math-proof-worker-deep. Выбирай имя отдельно для каждой из трёх ролей: используй короткое имя (math-proof-judge, math-proof-worker, math-proof-worker-deep), если твой список агентов его предлагает, иначе — имя с областью; смешивать две формы можно (копия с коротким именем в каталоге агентов пользователя или проекта — это способ, которым пользователь меняет настройки одной роли, и она должна иметь приоритет). Если одна из трёх не указана ни под одним именем, сообщи пользователю, что субагентов плагина math-proof нет в списке агентов этой сессии — пусть откроет /plugin, проверит, что math-proof установлен и включён, перезапустит Claude Code и подаст ту же строку /math-proof:siege заново, — и остановись до раунда 1. Запиши в state.md имя, использованное для каждой роли. Шаги судьи используют math-proof-judge. Исполнители — волны раундов и их повторные запуски — используют math-proof-worker в раундах до ESC_ROUND и math-proof-worker-deep в раунде ESC_ROUND и каждом более позднем; исполнители хвоста доказательства (волны дополнительных запросов, волна фиксации, r3_verify) используют math-proof-worker-deep, если волна проходила в раунде ESC_ROUND или позже (R ≥ ESC_ROUND в state.md), и math-proof-worker в остальных случаях. Выбор определяется исключительно номером раунда, никогда твоим собственным мнением о том, как идёт попытка. Никогда не используй повторно, не возобновляй и не отправляй сообщения более раннему субагенту. Не передавай model инструменту Agent: судьи и исполнители работают на модели этой сессии. Запускай всю волну ОДНИМ сообщением, чтобы исполнители работали параллельно; никогда не запускай субагента в фоне.
• В каждом задании и промте исполнителя ниже DIR означает абсолютный путь к каталогу запуска, а остальные {слоты в фигурных скобках} — названные значения; подставь их и отправь текст в остальном ДОСЛОВНО. Не добавляй ободрений, подсказок, мнений о задаче, сроков или сводок результатов ни в одно задание или промт.
• Одно фиксированное дополнение к КАЖДОМУ запуску math-proof-judge: после задания добавь пустую строку, строку «Условие задачи (для справки — авторитетный текст находится в DIR/problem.md; руководствуйся файлом везде, где эта копия расходится с ним или выглядит искажённой):» и затем полное содержимое DIR/problem.md байт в байт (ты прочитал его при подготовке). Это справочный материал, чтобы уже первый запрос судьи содержал условие задачи; он не меняет ни одной инструкции задания, а правило заданий о том, что судья не должен копировать условие в файлы запросов, остаётся в силе; DIR/problem.md, который называет каждое задание, остаётся авторитетным текстом. (Промты исполнителей несут тот же текст в фиксированной форме, данной ниже.) Вставляй его точно: копируй текст, который ты прочитал из DIR/problem.md, символ в символ, никогда по памяти и никогда не перепечатывая.
• Ты никогда сам не пишешь и не правишь файлы запросов, файлы ответов (законченные или частичные), сводки, файлы реестра, notes.md или proof.md. Единственные файлы, которые ты пишешь, — state.md, index.md, копия задачи, запасной r3_verify.md и result-so-far.md (оба только копированием или конкатенацией); помимо этого ты только копируешь или перемещаешь файлы там, где это велит шаг (cp/mv: summary.md и переименования r3_verify.first в хвосте доказательства). Ты не читаешь файлы ответов дальше проверки того, что они существуют (test -s); какие из них закончены, решает скрипт учёта (SCRIPT answers, ниже), а никогда не ты.
• Промты исполнителей всегда в точности такие, где {Q} — основа имени файла запроса (например, round2_q3, extra_q1, r3_q2, r3_verify), {PROBLEM} — полное содержимое DIR/problem.md байт в байт, а {EARLIER} — пустая строка — кроме случая запуска запроса, о котором последний запуск answers этой волны сообщил «partial»: тогда {EARLIER} — это абзац, приведённый после этого промта, с пустой строкой до и после него: «Файл задачи: DIR/{Q}.md — прочитай его первым; задача относится к условию, приведённому ниже (авторитетный текст задачи хранится в DIR/problem.md; прочитай его, если что-либо в копии ниже выглядит искажённым). Пиши ответ в DIR/{Q}.answer.md по ходу работы, а когда закончишь, каким бы ни был итог, сделай последней строкой файла вот эту завершающую строку, в точности: === END OF ANSWER {Q} === {EARLIER} Условие задачи (дословно, для справки): {PROBLEM}» {EARLIER}, когда он не пуст, — в точности: «Предыдущая попытка исполнителя над этой задачей была прервана на полпути; её незаконченный ответ лежит в DIR/{Q}.partial.md — прочитай его после файла задачи, используй из него всё, что можешь проверить сам, ничему в нём не доверяй как установленному и напиши собственный полный ответ в DIR/{Q}.answer.md, закончив его завершающей строкой выше.» По завершающей строке отличают законченный ответ от такого, где исполнителя прервали на середине (лимитом использования, ошибкой или пределом числа ходов); её проверяет скрипт учёта, а ты — никогда.
• Проведение волны файлов запросов означает: запустить по одному исполнителю того типа, который использует эта волна (math-proof-worker или math-proof-worker-deep, см. первое правило), на каждый файл, все в одном сообщении. Когда все вернулись — и не раньше: исполнитель, который ещё работает, всё ещё пишет свой файл — выполни SCRIPT answers DIR {Q1} {Q2} … с основами имён файлов запросов волны, отдельной командой, и прочитай, что он печатает, прежде чем писать какую-либо строку индекса или что-либо запускать. Он решает, ничего не читая, какие файлы ответов закончены, и печатает по одной строке на запрос — «{Q}: answered» (DIR/{Q}.answer.md заканчивается завершающей строкой этого запроса: его исполнитель его закончил), «{Q}: partial» (исполнитель что-то записал, но не закончил; скрипт переместил этот незаконченный файл в DIR/{Q}.partial.md, чтобы файл .answer.md всегда означал законченный ответ) или «{Q}: no answer» — и затем строку «TOTAL (n queries): …» с тремя счётчиками (если вместо этого он печатает строку ERROR, можно спокойно исправить команду — сначала DIR, затем основы имён вроде round2_q1 — и запустить снова). Допиши в DIR/index.md ОДНУ строку на запрос: «{Q} | answered | », «{Q} | partial | » или «{Q} | no answer | » как сказал скрипт, а затем первые 300 символов ответа исполнителя тебе (его краткое изложение, а не содержимое файла ответа), заменив переводы строк пробелами, чтобы запись осталась в одной строке. Затем, если — и только если — какой-то запрос волны не отвечен, перезапусти свежего исполнителя на каждый такой запрос (один раз, все в одном сообщении; для отвеченных запросов ничего не запускай; промт частичного запроса несёт абзац {EARLIER}, который передаёт новому исполнителю незаконченный файл), и когда все вернутся, снова выполни SCRIPT answers со ВСЕМИ основами имён волны (отвеченных запросов это не затрагивает) и допиши к существующей строке индекса каждого повторно запущенного запроса (инструментом Edit; второй строки для запроса не добавляется) « | re-run: answered | », « | re-run: partial | » или « | re-run: no answer | » в соответствии с новым отчётом, а затем первые 300 символов ответа нового исполнителя, как раньше (запрос, прерванный дважды, остаётся частичным; скрипт оставляет более длинный из двух незаконченных файлов как DIR/{Q}.partial.md, а другой рядом как DIR/{Q}.partial.prev.md). Итак, строка индекса выглядит как «{Q} | status | abstract», иногда с продолжением « | re-run: status | abstract», и статус повторного запуска, если он есть, — действующий; задания планирования, черновика, доработки и окончательной доработки объясняют судьям, что такое частичный файл. Никогда не запускай исполнителя на запрос между возвратом исполнителя и запуском answers, который его учитывает. Запомни строку TOTAL последнего запуска answers для волны — того, что по всем её основам имён, так что его число n равно размеру волны: ею пользуются правило FLOOR ниже и state.md.
• Пользователь не будет отвечать тебе в течение этой сессии: никогда не заканчивай ход вопросом, как поступить, не жди подтверждения и никогда не останавливайся досрочно из-за того, что что-то пошло не так — решай по этим правилам и продолжай, пока протокол не закончится или пока правило ниже не велит остановиться. Субагент, вернувший ошибку, прерванный результат или пустой ответ, записывается в index.md / state.md, и протокол продолжается; один потерянный исполнитель — это нормально; шаг судьи, вернувшийся с ошибкой или прерванный, перезапускается один раз немедленно. Если один и тот же шаг судьи проваливается (завершается ошибкой или не пишет ни одного из своих файлов) дважды подряд, остановись и доложи, где всё стоит. Если после окончания волны раунда и её одного повторного запуска answered + partial в последней строке TOTAL меньше числа FLOOR, которое скрипт напечатал в своём вердикте WAVE (вердикты скрининга в расчёт не идут), остановись и доложи: что-то системное неисправно, и продолжать — значит впустую тратить шаги судьи — скажи пользователю, что вероятнее всего причина в лимите использования или сбое, оборвавшем работу исполнителей, что файлы запуска целы и что подача той же строки /math-proof:siege в этом каталоге возобновит запуск, когда причина исчезнет. (Если n в этой строке TOTAL меньше размера волны, ты запустил answers только для части основ — сначала запусти его для всех.) У волн дополнительных запросов и фиксации порога нет.
• Дополнительные запросы: когда задание черновика или доработки это разрешает, судья может написать до 3 файлов с именами DIR/extra_q{k}.md, используя следующие неиспользованные номера k; на весь запуск положен бюджет в 10 (как только существует DIR/extra_q10.md, больше записывать нельзя — задания об этом говорят). Когда в ответе судьи сказано, что он записал файлы дополнительных запросов, убедись, что они существуют, проведи их как волну (ответы ложатся в DIR/extra_q{k}.answer.md, а для запроса, прерванного дважды, — в DIR/extra_q{k}.partial.md; какой именно вариант, показывает индекс), затем перезапусти тот же шаг ОДИН РАЗ с добавленным первым абзацем: «Твои дополнительные запросы получили ответы: прочитай DIR/extra_q*.answer.md (индекс показывает, какие из них существуют). Закончи шаг сейчас; не пиши в этом шаге новых дополнительных запросов.» Вторая партия дополнительных файлов от перезапущенного шага остаётся на диске без ответа.
• Переписывай DIR/state.md после каждого шага: протокол, настройки, текущая фаза, счётчики попыток и растущий журнал по одной строке на шаг; строка планирования каждого раунда также записывает предел волны, переданный команде проверки, а строка каждой волны — тип запущенных исполнителей и последнюю строку TOTAL (например, «cap 10, math-proof-worker-deep ×9, answered 8, partial 1, no answer 0»). Это твоя единственная память на случай, если этот разговор когда-нибудь сожмут; если ты не уверен, где находишься, снова прочитай state.md и ${CLAUDE_SKILL_DIR}/SKILL.md.

PLAN BRIEF (раунд {r} из не более чем {MAX_ROUNDS}; {CAP}, {HORIZON}, {CONCLUDE_RULE}, {ESC_SUMMARY} и {ESC_WAVE} зависят от r, см. (a) и ниже)

Шаг: планирование раунда {r} из не более чем {MAX_ROUNDS}.{HORIZON} Файлы: задача — в DIR/problem.md; твои рабочие заметки — в DIR/notes.md; сводка хода работы с прошлого раунда — в DIR/summary.md (в раунде 1 её нет); реестр утверждений — в DIR/ledger.md (отсутствует или пуст, пока в него ничего не записано); результаты прошлого раунда — это файлы DIR/round{r-1}_q*.answer.md, чья строка в DIR/index.md имеет статус «answered» (каждая строка выглядит как «query | status | abstract», иногда с продолжением «| re-run: status | abstract», и тогда действует статус повторного запуска; в раунде 1 их нет), а также DIR/extra_q*.answer.md, если они существуют. У запроса со статусом «partial» вместо этого есть файл DIR/round{r-1}_q{k}.partial.md: заметки движка, который был прерван на полпути. Прочитай и его, ради зацепок и материала для новых запросов, но ничто в нём не установлено — он может подсказать строку OPEN или запрос, но никогда сам по себе — строку PROVED (одно исключение: если в нём лежит полное письменное доказательство или опровержение утверждения [GOAL] либо более ранней, с тех пор поднятой цели, которую всё ещё охватывает правило аудита ниже, то это доказательство считается «имеющимся на руках» для правила аудита точно так, как если бы файл был закончен — ты также пишешь заверенную строку [GOAL], которой требуют правила аудита и завершения, с основой имени этого запроса (например, round3_q2) как локатором — и дальше решают проверочные запросы). (Каждый законченный файл результата заканчивается служебной строкой «=== END OF ANSWER … ===»: она не часть математики; не включай её ни в что, что ты склеиваешь или цитируешь.) Сначала прочитай задачу, свои заметки, сводку, реестр и индекс, затем файлы результатов прошлого раунда — каждый файл один раз, целиком. 0. Сначала скрининг (раунды 2 и позже). Читая файлы результатов прошлого раунда, проверь, что каждый является настоящей попыткой ответить на свой запрос, а не отказом, пустым или почти пустым файлом, текстом не по теме или работой над другой задачей. Запиши DIR/judge/screen_r{r-1}.md по одной строке на запрос этого раунда, в точности «round{r-1}_q{k}: OK» или «round{r-1}_q{k}: DEGENERATE: причина в одну строку» («DEGENERATE: no answer» для запроса, чей статус — no answer; .partial.md частичного запроса проверяется тем же критерием, что и законченный файл — незаконченность сама по себе не вырожденность), и во всём, что ниже, игнорируй каждый файл, который ты пометил DEGENERATE. Это скрининг, а не оценка: неверный, слабый или неполный ответ всё равно OK. Ты руководишь структурированной многораундовой попыткой решить трудную математическую задачу. В каждом раунде ты составляешь запросы, которые независимо отправляются глубокому движку рассуждений с очень большим бюджетом на размышления; результаты возвращаются файлами, и ты сворачиваешь установленное в сводку хода работы, прежде чем составлять следующий раунд. Это раунд {r} из не более чем {MAX_ROUNDS}.{HORIZON} {CONCLUDE_RULE} Сделай три вещи по порядку. 1. Обнови сводку хода работы. Перепиши её с нуля в DIR/round{r}_summary.md: она ЗАМЕНЯЕТ предыдущую сводку и является единственной памятью последующих раундов (и итоговой сборки доказательства) о том, что было раньше, поэтому переноси вперёд всё, что остаётся актуальным. Записывай: что установлено, со ссылкой на файл результата, который это показал (например, round2_q3); многообещающий частичный прогресс; тупики и почему каждый является тупиком; и открытые пробелы между текущим состоянием и целью. Будь честен: завышенная сводка отравляет каждый последующий раунд. Не больше 6000 слов. Затем реши, куда целиться дальше: закончи сводку разделом, называющим, на чём должен сосредоточиться следующий раунд, — заострить самый сильный частичный результат, закрыть самый несущий открытый пробел, проверить то, от чего попытка теперь зависит, или отказаться от тупиковой линии ради свежего взгляда. Ранние раунды обычно исследуют (разные независимые переформулировки и подходы); поздние раунды обычно эксплуатируют (сфокусированные попытки, проверка ключевых шагов). Выбор каждый раз за тобой.{ESC_SUMMARY} 2. Обнови реестр утверждений. Наряду со сводкой запуск ведёт нумерованный реестр утверждений, каждое помечено PROVED, REFUTED или OPEN. В отличие от сводки, реестр никогда не переписывается: строки, которые ты пишешь сейчас, ДОПИСЫВАЮТСЯ дословно (нумерация добавляется за тебя), а существующая запись утрачивает силу только добавлением явной строки RETRACT с её номером. Запиши DIR/round{r}_ledger_block.md, содержащий ТОЛЬКО новые строки этого раунда, по одной на строку, каждая вида «PROVED: утверждение в одно предложение — локатор», «REFUTED: утверждение в одно предложение — локатор», «OPEN: утверждение в одно предложение — локатор» (локатор = основа имени файла результата, например round2_q3), или «RETRACT 4: причина в одно предложение, почему запись 4 больше не действует». Добавляй строку для каждого несущего утверждения, которое этот раунд решил или открыл, новую строку для любого утверждения, чей статус изменился (самая новая строка про утверждение отменяет более старые), и строку RETRACT для всего, что теперь известно как неверное. Держи строки по одному предложению: полный реестр дословно переносится в каждый последующий раунд и в итоговую сборку доказательства — это единственная память об этой попытке, которую нельзя свернуть. Пометь строку, формулирующую главную цель, тегом [GOAL] сразу после слова статуса («PROVED: [GOAL] …», «OPEN: [GOAL] …»), а тегом [AUDIT] пометь строку PROVED, фиксирующую, что отдельный проверочный запрос проверил полную письменную цепочку доказательства (назови локатор этого запроса и сошлись на заверяемую запись как «entry N» или «#N»). Ставь теги по мере появления строк. В раунде 1 напиши ровно одну строку [GOAL]. Если задача фиксирует утверждение, которое нужно решить, то это утверждение — всё утверждение как поставлено, все его части — и есть цель; если задача открытая (улучшить, расширить или усилить данную работу; найти значимый результат о чём-либо), выбери цель сейчас — одно точное утверждение, самый значимый результат, который, по твоей оценке, эта попытка может установить, — и запиши его как строку [GOAL], OPEN, пока не решено. (i) Строки статуса. Пиши ещё одну строку [GOAL] для того же утверждения только при смене его статуса (OPEN → PROVED или REFUTED, либо обратно в OPEN, когда проверочный запрос находит пробел — тогда ещё и RETRACT строки PROVED) — и тогда именно в том раунде, чьи файлы результатов впервые содержат полное письменное доказательство, чтобы проверочные запросы, которые ты составляешь на том же шаге, заверяли строку, которая уже пронумерована, когда придут их ответы, — либо чтобы вернуться к нему по пункту (iv) ниже; никогда не переписывай её просто другими словами, поскольку считается только самая новая строка [GOAL], а строка [AUDIT] должна ссылаться по номеру на заверяемую ею запись [GOAL], которая является самой новой, если с тех пор цель не двигалась (строки в твоём блоке нумеруются дальше от последней записи DIR/ledger.md в порядке файла). (ii) Смена цели. Цель не зафиксирована: на любом более позднем шаге планирования ты можешь поставить новую цель, написав новую строку OPEN [GOAL], и она станет целью с этого момента (это не повод целиться низко в раунде 1: выбирай цель раунда 1 в точности как выше); во всём этом задании «строка [GOAL]» и «утверждение [GOAL]» означают самую новую действующую строку [GOAL] и её утверждение. Есть две причины поставить новую цель. Заменить цель (RETRACT прежней строки [GOAL] — если она была PROVED и доказательство держится, перезапиши то, что она доказала, как обычную строку PROVED без тега — затем напиши новую), если она оказалась ложной, некорректной или уже известной, а также если ты обнаруживаешь, что она уже, чем утверждение, которое ставит сама задача, или отличается от него, — тогда поставленное утверждение становится новой целью (это замена, а не поднятие, даже если более узкая цель уже была PROVED: в задаче, которая фиксирует своё утверждение, вердикт запуска относится к этому утверждению); для цели, которую ты сам выбрал в раунде 1 в открытой задаче, опровержение означает «замени и продолжай» (о цели, к которой ты поднялся, см. (iii)), а строка REFUTED [GOAL] завершает запуск, только когда это утверждение поставила сама задача. Или поднять цель: когда текущая цель PROVED, если более значимый результат теперь кажется достижимым за оставшиеся раунды — более сильное утверждение или общий случай доказанного — напиши новое утверждение как строку OPEN [GOAL] (локатор roundN_plan, где N — номер этого раунда), на том же уровне требований, что и выбор раунда 1 (одно точное утверждение, которое, по твоей оценке, эта попытка может установить, а не такое, которое, насколько ты можешь судить, ложно, некорректно или уже известно). Поднятие — всегда строка OPEN: никогда не пиши как строку PROVED [GOAL] утверждение, более сильное, чем то, что файлы результатов действительно доказывают. Когда задача сама поставила утверждение и оно доказано как поставлено, поднимать не до чего: завершай. (iii) Что оставляет на месте поднятие. Когда ты поднимаешь цель, не отзывай доказанную цель и её строки [AUDIT]: они остаются в силе как обычные записи, и именно этот результат итоговый документ представляет, если поднятая цель не достигнута. Если же проверочный запрос находит пробел в доказательстве цели, от которой ты поднялся, сделай RETRACT её строки PROVED [GOAL] — никогда не оставляй в силе строку PROVED [GOAL], чьё доказательство не прошло проверку, — и заново реши по (ii), какое утверждение является целью (чтобы вернуться к более ранней, запиши её как самую новую строку OPEN [GOAL] и нацель волну на пробел). Опровержение (REFUTED) поднятой цели не является вердиктом запуска, и его опровержению не нужны проверочные запросы (правило аудита ниже — для цели, на которой запуск может завершиться): запиши его как строку «REFUTED: [GOAL] …» с названием опровергающего файла, затем заново сформулируй под ней доказанную тобой цель, как описывает (iv), и завершай на ней. Поднятие — это суждение, а не обязанность: если ничего явно более значимого не кажется достижимым, завершай на доказанной цели по правилу завершения, приведённому выше в этом задании; а если первые две волны, нацеленные на поднятую цель (волна раунда, в котором ты поднял цель, — первая), не приблизили её — нет ни её доказательства, ни нового пути к нему, — то на следующем шаге планирования вернись к уже доказанной цели и завершай. Возвращение имеет приоритет над цепочкой и правилами прогресса из сводки и над правилом эскалации ниже, которые направляют волну на застрявшее утверждение, только пока оно остаётся целью: шаг с возвращением не составляет никаких запросов, кроме проверочных, которых правило аудита всё ещё требует для цели, к которой он возвращается (одна волна аудита, затем завершение). Кроме возврата к уже доказанной цели, не меняй цель на более слабую только потому, что её трудно доказывать: то, что установлено на пути к недостигнутой цели, представляется шагами написания доказательства так, как есть. Более сильные или дальнейшие результаты, которые ты не принимаешь целью, остаются обычными строками PROVED/OPEN и относятся к разделу доказательства «Other routes». (iv) Возвращение. Чтобы вернуться к цели, доказанной ранее (поднятое утверждение не поддалось), заново сформулируй её в блоке этого раунда как строку «PROVED: [GOAL] …» со ссылкой на её более раннюю запись как «entry N» или «#N», поставив её после любой другой строки [GOAL], которая есть в блоке, чтобы она стала самой новой (строки нумеруются в порядке файла), и под ней заново сформулируй её заверения как строки [AUDIT], каждая с локатором своего проверочного запроса, как раньше, и номером новой строки в той же форме (посчитай: если DIR/ledger.md заканчивается записью 23, а заново сформулированная цель — вторая строка твоего блока, это запись 25) — достаточно одной такой строки, если строка заново сформулированной цели ссылается на более раннюю запись, иначе две, из отдельных запросов; затем завершай по правилу завершения. Оставь файл пустым, если никакое утверждение не было решено, открыто, изменено или отозвано. 3. Составь запросы следующего раунда — или заверши. Тогда и только тогда, когда имеющийся материал полностью устанавливает цель, запиши DIR/round{r}_DONE.md с одной строкой, называющей, где материал её устанавливает, и не пиши запросов (если на этом шаге ты поднимаешь цель, составь вместо этого волну для неё — никогда не пиши DIR/round{r}_DONE.md на том же шаге, что и поднятие). Иначе напиши от 1 до {CAP} файлов запросов DIR/round{r}_q1.md, DIR/round{r}_q2.md, … (подряд идущие номера), нацеленных на выбранную тобой мишень. Пока строка [GOAL] имеет статус OPEN, параллельные запросы дёшевы и независимы, поэтому предпочитай использовать большую часть бюджета; делай их по-настоящему разными попытками взять мишень, а не переформулировками одной попытки. Когда полное письменное доказательство (или опровержение) утверждения [GOAL] на руках, волна сжимается: составь проверочные запросы, которых требует правило аудита ниже, плюс не более 2 других, нацеленных на то, что понадобится итоговому документу с доказательством (полная запись следствия, доказательство леммы, которая только цитировалась, независимое второе доказательство). Если же на этом шаге ты поднимаешь цель (пункт 2), волна не сжимается: проверочные запросы для доказанной цепочки всё равно уходят — когда их заверения вернутся в более позднем раунде, запиши их как строки [AUDIT] с их локаторами и ссылкой по номеру на запись PROVED той цели, которую они заверяют, даже если цель с тех пор сдвинулась, — а остальная часть волны, до предела, составляется для новой строки OPEN [GOAL]. Когда это задание содержит правило эскалации ниже, эта часть волны подчиняется ему, а поднятое утверждение считается утверждением [GOAL], доказательства которого нет на руках: сначала вернись и дай сводке раздел «The chain and the missing statement» для поднятого утверждения (правило сводки (iii); если пока ничто его не сводит к чему-то, само поднятое утверждение и есть недостающее утверждение, а его строка OPEN [GOAL] служит его записью в реестре), затем составь эту часть волны по правилу эскалации. Каждый запрос должен быть самодостаточным: движок рассуждений видит ТОЛЬКО этот файл запроса, за которым следует полное условие задачи, — ни сводки, ни реестра, ни других результатов, ни другого раунда, — поэтому включай прямо в текст любой прежний результат или частичное рассуждение, на котором запрос строится (длинные фрагменты вставляй из файла ответа через оболочку, а не перепечатывая). НЕ копируй само условие задачи ни в какой запрос. Правило целеполагания (действует в каждом раунде). Из составленных тобой запросов как минимум половина (с округлением вверх) должна ПЫТАТЬСЯ решить открытые вопросы, которые этот запуск сам отметил: открытые вопросы, названные в файлах результатов, утверждения OPEN в реестре и открытые пробелы в твоей сводке. Помечай каждый такой запрос, делая его ПЕРВУЮ строку в точности «kind: attempt», и называй внутри него конкретный открытый вопрос, который он пытается решить. Запрос-попытка пытается РЕШИТЬ свой вопрос — доказать, опровергнуть или свести к чему-то строго более лёгкому, — а не обозревать его, заново выводить известное вокруг него или шлифовать документ. Вердикт, что вопрос «established: open» (или что цель выходит за пределы современного уровня знаний), НЕ окончателен, и последующие раунды не должны наследовать его как решённый: заново открой вопрос и нацель запросы-попытки прямо на него. Правило аудита (действует в каждом раунде). Всякий раз, когда файл результата на руках даёт полное письменное доказательство (или опровержение) утверждения [GOAL] — или цели, от которой ты поднялся, на этом шаге или раньше (не опровержение цели, до которой ты поднялся: пункт 2 (iii)), — которое заверили менее двух проверочных запросов, как минимум столько запросов этого раунда, сколько ещё не хватает (два или один), должны быть независимыми проверочными запросами этой письменной цепочки — если несколько файлов результатов дают полное доказательство, выбери самое полное и отправь оба проверочных запроса против этой же цепочки. Каждый несёт полное рассуждение дословно — собери файл запроса оболочкой из файла ответа (cat, sed; из частичного файла — по исключению, приведённому у перечня файлов выше), не перепечатывай и не пересказывай его, — и просит пошаговую проверку каждого вывода, заканчивающуюся явным вердиктом о том, доказывает ли цепочка утверждение в точности как оно сформулировано; они считаются запросами-попытками (первая строка «kind: attempt», с названием записи [GOAL], которую они проверяют); два заверения удовлетворяют условию — добавляй третье, только если оно проверяет то, чего два других не проверяют. Когда такое заверение приходит положительным, запиши его как строку PROVED [AUDIT] с его локатором и ссылкой по номеру на запись [GOAL], которую оно заверяет (завершённая строка этой цели, даже если цель с тех пор была поднята); когда реестр после этого удовлетворяет условиям (см. выше), завершай.{ESC_WAVE} Правило обращения к первоисточнику. Текущая сводка — это сжатие, и она может опустить или исказить то, что результат на самом деле говорил. Всякий раз, когда ты опираешься на прежний результат или противоречишь ему — при переписывании сводки, в строке реестра, при выборе мишени или при решении завершить, — сначала прочитай файл ответа этого результата и исходи из того, что в нём на самом деле сказано, а не из пересказа в сводке. Наконец, перепиши DIR/notes.md и ответь менее чем в 150 слов: завершено или нет, сколько файлов запросов и сколько из них запросы-попытки, и мишень одним предложением. Если в этом раунде ты заменил цель, поднял её или вернулся к цели (пункт 2), добавь ещё одно предложение, не входящее в 150 слов, начинающееся с «Goal change:» — что из трёх, какой была цель и какая она теперь (каждая — короткой фразой), и уже доказанный результат, если он держится, с номером его записи в реестре и числом проверочных запросов, заверивших его на данный момент; при поднятии также назови полным путём файл или файлы ответов, содержащие полное доказательство этого результата (форма: «Goal change: raised — entry N, proved in DIR/roundK_qJ.answer.md (certified by M verify queries so far), is …; the goal is now …»).

{CONCLUDE_RULE} при r < MIN_ROUNDS — в точности: «Ты можешь завершить в этом раунде, до раунда {MIN_ROUNDS}, как только в реестре утверждений главная цель будет решена — строка PROVED или REFUTED с тегом [GOAL] («PROVED: [GOAL] …») — и будут как минимум две строки PROVED с тегом [AUDIT]. Каждая строка [AUDIT] — это заверение, возвращённое отдельным проверочным запросом, который проверил полную письменную цепочку доказательства (а не набросок или план); она должна назвать локатор этого запроса (например, round3_q2) и сослаться на строку [GOAL] или на строку, на которую та ссылается, по номеру записи в реестре, написанному «entry 12» или «#12», — как минимум одна строка [AUDIT] ссылается на саму строку [GOAL]. Когда реестр удовлетворяет условиям, реши на этом шаге одно из двух: завершить или поднять цель (пункт 2 ниже говорит, когда и как) и составить волну для поднятой цели. Не проводи дополнительных волн только ради того, чтобы дойти до раунда {MIN_ROUNDS}, или ради шлифовки — шлифовку делают следующие за этим шаги написания доказательства. Ставь теги по мере появления строк. Если реестр пока не удовлетворяет условиям, составь волну (правило аудита ниже говорит, когда она должна содержать проверочные запросы).» — а при r ≥ MIN_ROUNDS — в точности: «Начиная с этого раунда ты можешь завершить, как только имеющийся материал полностью устанавливает утверждение [GOAL] — за исключением того, что если на руках есть полное письменное доказательство, которое заверили менее двух проверочных запросов, то правило аудита ниже действует и в этом раунде (одна волна аудита, затем завершение) — а когда такое доказательство на руках, блок реестра этого раунда уже должен содержать решённую строку [GOAL], записанную в обычной форме реестра «PROVED: [GOAL] …» (или «REFUTED: [GOAL] …») без чего-либо между словом статуса и тегом — то, что оно пока не заверено, не требует отдельной пометки, заверение фиксируют строки [AUDIT], — на том же шаге, на котором составляются его проверочные запросы. Когда утверждение [GOAL] установлено, ты либо завершаешь (после его волны аудита, где применяется правило аудита), либо поднимаешь цель (пункт 2 ниже; поднятие не обязано ждать аудитов), но никогда не делаешь оба действия на одном шаге: шаг, поднимающий цель, не пишет файла DONE, поскольку поднятая цель решается волной, а не завершением. Если ты поднял цель в более раннем раунде, а поднятое утверждение не поддалось, ты можешь завершить на уже доказанной цели, заново сформулировав её как самую новую строку [GOAL], как описывает пункт 2 (iv). В последнем раунде делай именно так, а не позволяй раундам просто кончиться.»

{HORIZON} пуст при r ≤ MAX_ROUNDS−2; при r = MAX_ROUNDS−1 — в точности: « Так что после этого раунда может пройти не более одного раунда.», а при r = MAX_ROUNDS — в точности: « Так что это последний раунд: то, что вернут его запросы, идёт сразу в шаги написания доказательства, без дальнейшего раунда, который мог бы на это отреагировать.» (Обрати внимание на ведущий пробел. {MAX_ROUNDS} в задании — это настройка MAX_ROUNDS, записанная числом, в каждом раунде.)

{ESC_SUMMARY} пуст при r < ESC_ROUND; при r ≥ ESC_ROUND — в точности (с ведущим пробелом): « Начиная с этого раунда сводкой управляют ещё четыре правила; поскольку правило (iii) требует от тебя собственной математики, запиши файл сводки с перенесённым материалом и пунктами (i)–(ii), прежде чем прорабатывать (iii), затем дополни его — сообщение, потраченное только на размышления, может быть прервано, и то, что не записано, теряется. (i) Постоянные результаты: веди раздел с таким названием, перечисляя каждую строку реестра PROVED, которая является теоремой о задаче в целом (для всех параметров), точной переформулировкой или сведением утверждения [GOAL] к названному более простому или классическому утверждению, либо полным решением естественного частного случая — каждую с её локатором, — даже если она сама не может довести цель до конца; никогда не убирай запись из этого раздела (вместо этого пометь её «не на текущей линии»), потому что если цель не достигнута, итоговый документ строится вокруг них. (ii) Тупики: путь считается тупиковым только по точному утверждению, которое было REFUTED, и по файлу результата, который его опроверг, и записывается именно в такой форме. Один файл результата, сообщающий о препятствии, неудачном поиске внутри одного анзаца или одного кандидата или о том, что путь охватывает только часть цели, закрывает этого кандидата, а не путь: перечисли такие пути среди открытых пробелов как «отложен, не опровергнут», открытый для повторной атаки. (iii) Цепочка и недостающее утверждение. Сначала реши, есть ли на руках полное письменное доказательство или опровержение утверждения [GOAL]. Файл результата, доказывающий недостающее утверждение прошлого раунда точно в том виде, как оно сформулировано, когда этой цепочке больше ничего не нужно, ЯВЛЯЕТСЯ таким: в этом случае запиши строку [GOAL] как PROVED (или REFUTED, если это опровержение) в блок реестра этого раунда, сославшись по номерам на записи, которые использует цепочка, и назвав локатор нового доказательства, и составь проверочные запросы правила аудита так, чтобы они несли ВСЮ цепочку — рассуждения цитируемых записей и новое доказательство, каждое вставленное из своего файла ответа, соединённые выводом цепочки в точности так, как его излагает сводка прошлого раунда. Если полное письменное доказательство или опровержение на руках, этим путём или любым другим, пропусти остаток (iii) и весь (iv). Иначе сводка содержит раздел с заголовком в точности «The chain and the missing statement», переписываемый каждый раунд, из четырёх помеченных частей. Chain (цепочка): вывод, по которому утверждение [GOAL] (или его отрицание, когда идёт линия опровержения — тогда читай «доказательство недостающего утверждения» ниже соответственно) следует из результатов, уже PROVED, — они цитируются по номеру в реестре, только формулировки — вместе ровно с ОДНИМ ещё не доказанным утверждением; выпиши вывод по шагам так, чтобы читатель, у которого есть цитируемые записи и доказательство этого одного утверждения, имел бы полное доказательство. Если материал пока не сводит цель к единственному утверждению, возьми в качестве недостающего утверждения самое сильное промежуточное утверждение, которое основной линии нужно следующим, и скажи в цепочке, что останется после него. Missing statement (недостающее утверждение): это одно утверждение, выписанное полностью и самодостаточно — каждый квантор, каждый объект определён, и вместе с ним указана каждая гипотеза задачи, которой оно может пользоваться (утверждение, лишённое нужной ему гипотезы, становится ложным, и его опровержение тогда дискредитирует здравую линию). Оно может нести собственные гипотезы — ограничение на часть объектов или на часть диапазона параметров, — только если цепочка показывает со ссылками на записи PROVED, что всё вне этих гипотез уже решено; утверждение, доказательство которого всё равно оставило бы нерешёнными некоторые из объектов, допускаемых задачей, — это частный случай, а не недостающее утверждение. Из утверждений, которые завершили бы цепочку, предпочитай самое простое и конкретное. Внеси его в реестр как строку OPEN (в качестве локатора пиши roundN_plan, где N — номер этого раунда) при первой формулировке и всякий раз, когда меняется его формулировка — и тогда ещё и RETRACT строки OPEN той формулировки, которую оно заменяет, — чтобы последующие раунды и запросы могли на него ссылаться. Why it should hold (почему оно должно выполняться): твой собственный набросок, не более пятнадцати строк, почему ты в это веришь и каким рассуждением его можно было бы доказать — занимайся этой математикой сам: если ты видишь возможный механизм, любого рода, который его даст, сформулируй его точно; твоя гипотеза, которую движки затем докажут или опровергнут, — одна из самых полезных вещей, которые даёт этот шаг. Tried so far (что пробовали): по одной строке на каждый запрос, уже потраченный на это утверждение или его более раннюю формулировку, — локатор, использованный подход и результат (доказательство частного случая, эквивалентная переформулировка, препятствие, ничего); одинаковые копии одной задачи делят строку; указанный так подход считается опробованным. (iv) Проверка прогресса. Открой раздел о мишени словами о том, дали ли последние два раунда прогресс по цепочке, причём прогрессом считается ТОЛЬКО: доказательство недостающего утверждения; доказательство утверждения [GOAL]; новый результат PROVED, верный для каждого объекта, который допускают гипотезы, и сокращающий цепочку; или замена недостающего утверждения строго более простым (более простым, а не просто более узким), с заново выведенной цепочкой. Решение ещё одной части объектов при открытой трудной части недостающего утверждения — так что утверждение лишь сужается — или эквивалентная его переформулировка записываются в (i), но не являются прогрессом в этом смысле. Если прогресса не было, напиши «main line stalled — no universal progress», скажи одной строкой, что в твоём наброске или разложении отличается от прошлого раунда, и не отвечай на это открытием ещё одного частного случая или обращением к другим путям ради широты: волна (если только пункт 2 (iii) теперь не велит вернуться к уже доказанной цели и завершить) идёт на само недостающее утверждение по Closing rule ниже, а меняться должен твой собственный набросок в (iii) — другой механизм для того же утверждения или другое разложение цепочки с другим недостающим утверждением. Если файл результата ОПРОВЕРГ недостающее утверждение в точности как сформулировано, не спасай его простым исключением класса контрпримера (если только запись PROVED уже не решает этот класс и цепочка этого не говорит): либо сформулируй исправленное недостающее утверждение и заново выведи для него цепочку полностью, либо запиши линию как тупиковую по (ii) и построй цепочку следующей наиболее многообещающей линии. Начиная с этого раунда «проверка» как мишень означает только аудиты цели по правилу аудита и ту единственную проверку цепочки, которую допускает пункт (c) правила Closing rule.»

{ESC_WAVE} пуст при r < ESC_ROUND; при r ≥ ESC_ROUND — в точности (с ведущим пробелом; {CAP} подставляется как в других местах): « Правило эскалации (этот раунд и каждый последующий, пока на руках нет полного письменного доказательства или опровержения утверждения [GOAL] — как только оно есть, включая случай, описанный правилом сводки (iii), когда доказанное недостающее утверждение завершает цепочку, правило аудита и сжатая волна выше берут управление на себя, а (a)–(c) ниже тогда игнорируются). Движки, отвечающие в этом раунде, имеют куда больший бюджет на размышления, чем в начальных раундах, и волна может содержать до {CAP} запросов: используй большую их часть и трать её на недостающее утверждение твоей цепочки, сформулированное полностью, а не на обзоры и не на широту ради самой широты. (a) Каждый запрос атакует: он пытается решить недостающее утверждение, само утверждение [GOAL] или вопрос, ответ на который решил бы или строго свёл бы одно из них (решение лишь для части объектов не является сведением). Не трать запросы на изложение, шлифовку, повторный вывод или проверку результатов, которые не завершают цепочку [GOAL] — этим занимаются шаги написания доказательства после раундов, со своим бюджетом запросов, — так что единственные проверочные запросы раунда — это запросы правила аудита (проверочные запросы, заверяющие цель, которая была доказана, а потом поднята, считаются запросами правила аудита) и та единственная проверка цепочки, которую допускает пункт (c). Не трать запрос на просьбу к движку вспомнить или восстановить доказательство из литературы, утверждения [GOAL] или чего-либо другого: у движков нет библиотеки, и такая задача не даёт им материала для рассуждений (использование известных теорем внутри атаки — другое дело, и оно допустимо). (Только в последних двух раундах — начальная строка этого задания «Step: plan round …» тогда скажет об этом явно, словами «one further round» или «the final round»; если в ней нет ни того, ни другого, это не один из них — до двух запросов могут вместо этого проверить или полностью записать постоянные результаты, которые будет представлять итоговый документ.) (b) Closing rule (правило завершения). Напиши ОДИН файл задачи, который просит полное доказательство в точности недостающего утверждения твоей цепочки — или же явный контрпример к нему — и содержит: утверждение дословно так, как его излагает сводка; каждый прежний результат, на который оно может опираться, вставленный полностью вместе с доказательством из файлов ответов (cat, sed — никогда не пересказывая); вывод [GOAL] из него по цепочке, чтобы движок видел, для чего утверждение нужно, и мог сказать об этом, если сам этот вывод ошибочен; твой набросок того, почему оно должно выполняться, предложенный как подсказка, которую движок вправе отбросить; и явное предложение о том, что доказательство утверждения лишь для части охватываемых им случаев — подкласса его объектов или поддиапазона его параметров — не отвечает на вопрос, хотя о нём следует сообщить, если больше ничего найти не удалось. Сохрани его как файл запроса q1 этого раунда (первый из названных выше файлов) и скопируй байт в байт (cp) в q2 и q3: три движка независимо пытаются решить одно и то же утверждение — независимые попытки над одним корректно поставленным утверждением здесь ценнее, чем по одной попытке на три утверждения. Эти одинаковые копии задуманы (указание выше против переформулировок одной попытки на них не распространяется), и все три — запросы-попытки (первая строка «kind: attempt», с названием недостающего утверждения как открытого вопроса, который они пытаются решить). (c) Остальные запросы — используй большую часть предела — тоже идут на недостающее утверждение, каждый самодостаточен (несёт те же вставки, если ниже не сказано иное), и каждый — либо ещё одна побайтовая копия задания из Closing rule (допустимо: это ещё одна независимая попытка), либо что-то по-настоящему от него отличающееся: атака названным подходом, которого нет в списке «Tried so far» (назови его в задании; движок может отойти от него, если объяснит почему); или продолжение подхода из списка с частичного результата, который он вернул, с этим результатом, вставленным в текст; или самый трудный отдельный шаг твоего собственного наброска, вырезанный и поставленный как самодостаточное утверждение; или единственное препятствие, поднятое файлом результата против утверждения, поставленное как то, что нужно преодолеть или заострить до контрпримера. В первом раунде, когда ставится недостающее утверждение, и снова всякий раз, когда меняется его формулировка, один из этих запросов вместо этого пытается ОПРОВЕРГНУТЬ его в точности как сформулировано — явным построением или выводом из него чего-то заведомо ложного. Когда одно и то же недостающее утверждение уже атаковали в двух предыдущих раундах, одному из этих запросов даётся только само утверждение и формулировки цитируемых записей (без доказательств, без наброска), и его просят сначала самому вывести, что утверждение завершило бы [GOAL], а затем атаковать его первым ходом, которого не использовала ни одна из перечисленных попыток, — движок, который обнаруживает, что вывод не проходит или что утверждение неправдоподобно, говорит об этом, и это результат, на который нужно реагировать по правилу сводки (iv). НЕ БОЛЕЕ ДВУХ запросов волны могут идти в другое место: на пути, от которых основная линия не происходит (отложены, не опровергнуты, по правилу сводки (ii)), или — не более одного из них — на проверку одного шага PROVED, на котором держится цепочка и который ещё не проверял отдельный запрос. Все они — запросы-попытки (первая строка «kind: attempt»).»

DRAFT BRIEF

Шаг: черновик доказательства. Файлы: задача — в DIR/problem.md; твои рабочие заметки — в DIR/notes.md; твоя текущая сводка всего, что установила попытка, — в DIR/summary.md; реестр утверждений — в DIR/ledger.md; результаты последнего раунда — это самые новые файлы DIR/round{R}_q*.answer.md, помеченные answered и не DEGENERATE в DIR/index.md; файлы результатов всех более ранних раундов и DIR/extra_q*.answer.md лежат там, и к ним можно обращаться по имени (файл DIR/…_q{k}.partial.md, там, где индекс помечает запрос как partial, — это незаконченные и непроверенные заметки прерванного движка: только зацепки, ничто в нём не установлено; а строка «=== END OF ANSWER … ===», закрывающая каждый законченный файл, — служебная, а не математика). Сначала прочитай задачу, заметки, сводку, реестр и результаты последнего раунда. Ты руководишь структурированной многораундовой попыткой решить трудную математическую задачу. Раунды завершены. Теперь твоя задача: написать DIR/proof.md, содержащий сильнейший путь к цели — самое полное рассуждение, которое нашла попытка, — с полностью выписанным рассуждением,{PARTIALS} плюс короткую заметку о каждом другом пути, который стоит зафиксировать, и честное изложение всего, что остаётся пробелом, — чётко помеченный пробел ценнее замазанного. Если самая новая строка [GOAL] не PROVED — либо PROVED, но не заверена двумя строками [AUDIT], и её письменное доказательство не выдерживает твоей собственной проверки — а в реестре в силе есть строка PROVED [GOAL] для другого утверждения (цель, которая была достигнута, а затем поднята; если таких несколько, самая недавняя), то именно эта доказанная цель является главным утверждением proof.md. Изложи её как теорему документа и выпиши её полное рассуждение целиком по файлам результатов, которые называет для неё реестр (если файл, названный реестром, — это файл .partial.md, возьми текст из файлов проверочных запросов, которые его несли и чьи ответы его заверили); это не один из менее значимых результатов. Поднятая цель идёт после неё, как утверждение, которое пытались доказать, вместе со всем, что было установлено на пути к ней, и раздел Status говорит, что есть что. Используй python3 всякий раз, когда конкретное вычисление подтвердит или убьёт шаг: проверь предполагаемое тождество на примерах, проверь константу, численно проверь заявленный контрпример. Проверка лучше веры. Если один или несколько целевых запросов глубокого рассуждения решили бы несущий вопрос, ты можешь записать их как следующие неиспользованные файлы DIR/extra_q{k}.md (не более 3 на этом шаге; ни одного, если уже существует DIR/extra_q10.md), каждый самодостаточный — движок видит только этот файл, за которым идёт условие задачи, — поэтому включай прямо в текст всё, на чём он строится, и не копируй в него задачу, — и скажи в своём ответе, что ты это сделал; на них ответят, и тебя вызовут ещё раз. Запиши DIR/proof.md на этом шаге в любом случае. Перепиши DIR/notes.md. Ответь менее чем в 150 слов.

{PARTIALS} пуст в КОРОТКОМ хвосте и всегда, когда R < ESC_ROUND; в ПОЛНОМ хвосте при R ≥ ESC_ROUND — в точности (с ведущим пробелом): « и — поскольку самая новая строка [GOAL] не заверена — также выписанные полностью вместе с доказательствами в основном тексте (после теоремы более ранней доказанной цели, когда применимо предложение ниже о поднятой цели) и перед изложением того, что остаётся открытым: каждый результат PROVED в реестре или сводке, который решает естественный частный случай, даёт точную переформулировку или сведение цели (изложи как теорему: «утверждение верно для всех … при условии …»), либо отождествляет цель или её открытое ядро с названным известным утверждением, самые общие первыми — для цели, которую попытка не решила, рецензент судит о ней по сведениям и частичным результатам, которые она действительно устанавливает, так что это и есть документ, а не побочные заметки;»

REFINE BRIEF (имя шага {S} = refine_2, refine_3, … по порядку)

Шаг: {S}. Файлы: задача — в DIR/problem.md; твои рабочие заметки — в DIR/notes.md; текущий черновик — DIR/proof.md; файлы результатов — DIR/round*_q*.answer.md (результаты всех раундов) и DIR/extra_q*.answer.md, перечисленные со статусом в DIR/index.md (у запроса со статусом там «partial» вместо этого есть DIR/…_q{k}.partial.md, незаконченные и непроверенные заметки прерванного движка: зацепки, а не результаты; а строка «=== END OF ANSWER … ===», закрывающая каждый законченный файл, — служебная, а не математика); реестр утверждений — DIR/ledger.md, а текущая сводка — DIR/summary.md. Сначала прочитай задачу, свои заметки и черновик; обращайся к любому файлу результата по имени, когда понадобится. Ты ведёшь структурированную параллельную попытку решить трудную математическую задачу и находишься между волнами. Твоя задача на этом шаге: сделать proof.md строго лучше. Заново выведи самые слабые шаги, ищи ошибки как враждебный рецензент и используй python3, чтобы проверить каждое конкретное вычислительное утверждение, на которое ты опираешься. Если один целевой запрос глубокого рассуждения решил бы несущий пробел, ты можешь записать его как следующий неиспользованный DIR/extra_q{k}.md (не более 3 на этом шаге; ни одного, если уже существует DIR/extra_q10.md), самодостаточный — движок видит только этот файл, за которым идёт условие задачи, — поэтому включай прямо в текст всё, на чём он строится, и не копируй в него задачу, — и скажи в своём ответе, что ты это сделал. Затем перепиши DIR/proof.md целиком, предварительно сохранив входящий черновик как DIR/judge/{S}_previous_proof.md. Будь честен в том, что остаётся пробелом, — чётко помеченный пробел ценнее замазанного. Перепиши DIR/notes.md. Ответь менее чем в 150 слов.

SELECT BRIEF

Шаг: выбор путей для волны фиксации. Файлы: задача — в DIR/problem.md; твои рабочие заметки — в DIR/notes.md; черновик доказательства — в DIR/proof.md; результаты последнего раунда (и любой более ранний файл результата, который тебе нужен) по DIR/index.md (запрос, помеченный там как «partial», имеет лишь непроверенные заметки в DIR/…_q{k}.partial.md от движка, прерванного на полпути); реестр утверждений — DIR/ledger.md. Ты ведёшь структурированную параллельную попытку решить трудную математическую задачу; у тебя есть черновик доказательства и полные результаты поиска. Твоя задача — шаг фиксации протокола: любой результат с конкретным путём (названная цепочка лемм, конкретная конструкция) к цели получает запрос фиксации с полным бюджетом на размышления: «Маршрут: [путь]. Напиши полное строгое доказательство.». Плюс один проверочный запрос, который проверяет рассуждение черновика доказательства шаг за шагом. (Если цель была доказана, а более поздняя, поднятая цель — нет, главное утверждение черновика — доказанная цель; конкретные пути к поднятой цели по-прежнему можно фиксировать.) Выбери не более {MAX_COMMIT} путей, которые стоит зафиксировать (меньше — тоже хорошо: только пути с чем-то конкретным). Для каждого напиши запрос как DIR/r3_q1.md, DIR/r3_q2.md, …, включив фактическое содержание пути (а не ссылку на него — движок не видит ничего, кроме файла запроса, за которым идёт условие задачи). НЕ копируй условие задачи ни в какой запрос. Также напиши ровно один DIR/r3_verify.md, содержащий полный текущий черновик доказательства (скопированный целиком из DIR/proof.md оболочкой — cat, — а не перепечатанный) и просящий пошаговую проверку: для каждого неравенства, перестановки, цитируемого результата и «отсюда следует» — действительно ли это следует так, как написано; перечислить каждую ошибку или пробел по убыванию серьёзности и прямо сказать, доказано ли главное утверждение. Используй python3, если быстрое вычисление решит, какие пути настоящие. Перепиши DIR/notes.md. Ответь менее чем в 100 слов списком записанных файлов.

FINALIZE BRIEF

Шаг: окончательная доработка. Файлы: задача — в DIR/problem.md; твои рабочие заметки — в DIR/notes.md; черновик доказательства, ушедший в волну фиксации, — в DIR/proof.md; результаты волны фиксации — DIR/r3_q*.answer.md, а отчёт проверочного запроса — DIR/r3_verify.answer.md (DIR/index.md показывает, какие из них существуют; если ни одного нет, дорабатывай по черновику; запрос, помеченный в индексе как «partial», вместо этого имеет DIR/r3_q{k}.partial.md или DIR/r3_verify.partial.md, незаконченные заметки прерванного движка — непроверенные, так что доказательство в них — это зацепка для проверки, а не результат, а пробелы, перечисленные в прерванном проверочном отчёте, всё равно стоит проверить, хотя отсутствие его итогового вердикта ничего не говорит ни в ту, ни в другую сторону; строка «=== END OF ANSWER … ===», закрывающая каждый законченный файл, — служебная); реестр утверждений — DIR/ledger.md. Прочитай всё это. Ты ведёшь структурированную параллельную попытку решить трудную математическую задачу. Волна фиксации вернулась. Твоя задача — заключительный шаг протокола: собрать итоговый proof.md из лучшего результата фиксации (или из черновика, если ни один запрос фиксации не дал лучшего). Итерируй: если проверочный запрос нашёл пробелы, исправь то, что можно исправить, по имеющемуся материалу; используй python3, чтобы проверить каждое конкретное вычислительное утверждение, на которое ты опираешься. Будь честен в итоговом документе в том, что остаётся пробелом, — чётко помеченный пробел ценнее замазанного. Итоговый документ должен излагать ответ на задачу и давать полное рассуждение, затем короткий раздел «Status», прямо говорящий, доказано ли полностью главное утверждение, и перечисляющий всё, что остаётся пробелом, и короткий раздел «Other routes» обо всём остальном, что стоит зафиксировать{PARTIALS_FIN}. Если самая новая строка [GOAL] не PROVED — либо PROVED, но не заверена двумя строками [AUDIT], а её письменное доказательство не выдерживает проверочного отчёта и твоих исправлений — а в реестре в силе есть строка PROVED [GOAL] для другого утверждения (цель была поднята после достижения; если таких несколько, самая недавняя), то главное утверждение — это доказанная цель, изложенная и доказанная как теорема документа, а не представленная как менее значимый результат. Поднятая цель сообщается после неё как та, что пытались доказать, а не как пробел в главном утверждении, и раздел Status прямо говорит, какое утверждение главное и что поднятая цель не достигнута. proof.md читает самостоятельно рецензент, который не может открыть ни один другой файл этого каталога: никогда не ссылайся в нём на файлы запуска (r*_q*, extra_q*, *.answer.md, проверочный отчёт, заметки, скрипты); выписывай каждое рассуждение, на которое опираешься, полностью в proof.md, переписывая его по файлам исполнителей, если нужно. Сначала сохрани входящий черновик как DIR/judge/finalize_previous_proof.md, затем запиши итоговый DIR/proof.md. Перепиши DIR/notes.md. Ответь менее чем в 200 слов: сначала строка, начинающаяся в точности «MAIN CLAIM: PROVED» или «MAIN CLAIM: NOT PROVED» (вердикт твоего раздела Status о главном утверждении proof.md, как оно определено выше; PROVED здесь означает, что главный результат документа — доказательство или опровержение этого утверждения — полон), затем в той же строке тире и это главное утверждение одной фразой, затем абзац Status.

{PARTIALS_FIN} пуст в КОРОТКОМ хвосте и всегда, когда R < ESC_ROUND; в ПОЛНОМ хвосте при R ≥ ESC_ROUND — в точности (с ведущим пробелом): « (только намеченные или не развитые пути — тогда как каждое сведение, переформулировка или частный случай PROVED, относящиеся к цели, принадлежат основному тексту, выписанные полностью, самые общие первыми)»

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-plugins-official/tree/main/plugins/math-proof/skills/siege, лицензия Apache-2.0. Изменения: перевод на русский язык.