prepare-hearing

name	prepare-hearing
description	Подготовка к заседанию по multi-document ветке: Opus-subagent собирает red/blue-team заметки и набор ходатайств, Sonnet-main парсит сегменты по контракту 3.1b, Sonnet-subagent оформляет каждый процессуальный документ через arbitrum-docx. Используй, когда юрист просит подготовиться к заседанию, собрать ходатайства, письменные пояснения или иные процессуальные документы к конкретной дате.

prepare-hearing — Подготовка к заседанию

Скилл следует контрактам 3.1b и 3.2 из shared/subagent-dispatch.md. Итог ветки Ф5c: один notes.md и N файлов ходатайство-*.docx в каталоге заседания.

Предусловия

• Существует .vassal/case.yaml.
• Существует .vassal/index.yaml.
• Есть хотя бы одно зеркало в .vassal/mirrors/doc-*.md.
• Доступен Task(model=opus).
• Доступен formatter arbitrum-docx.

Переменные сессии

Определи в начале:

• hearing_date = дата заседания из аргументов или текущая дата YYYY-MM-DD; если аргумент передан, он должен строго пройти regex ^[0-9]{4}-[0-9]{2}-[0-9]{2}$, иначе верни блокер до любых файловых операций
• hearings_root = <case_root>/hearings
• hearing_dir = {{hearings_root}}/{{hearing_date}}
• staging_dir = временный каталог внутри {{hearings_root}}, созданный через mktemp -d или эквивалент, для полной сборки батча до публикации
• notes_path = {{hearing_dir}}/notes.md

Фаза 1 — Preview (main-Sonnet)

1. Прочитай .vassal/case.yaml и .vassal/index.yaml.
2. Найди доступные источники:
   • .vassal/mirrors/doc-*.md
   • при наличии — .vassal/analysis/*.md
   • при наличии — предыдущие материалы из hearings/*/analysis.md
3. Если .vassal/index.yaml пуст, не содержит документов, или после сверки с .vassal/mirrors/doc-*.md не осталось ни одного доступного зеркала документа, верни SKILL_UNAVAILABLE с reason no documents и остановись без создания выходных файлов.
4. Проверь путь публикации:
   • нормализованный {{hearing_dir}} обязан оставаться внутри {{hearings_root}};
   • если каталог {{hearing_dir}} уже существует и не передан --force, остановись с блокером и явно укажи, что повторный запуск на ту же дату требует --force.
5. Покажи Сюзерену preview:
   • какой каталог заседания будет использован: {{hearing_dir}};
   • что ожидается один markdown-OUTPUT по ветке 3.1b:
     • ## Заметки
     • ## Ходатайство N: <тема> для каждого документа;
   • что итогом станут notes.md и отдельные .docx по числу блоков ходатайств;
   • что повторный запуск на ту же дату допускается только с --force, а публикация идёт через временный каталог с атомарным переносом.
6. Дождись подтверждения.

Фаза 2 — Apply (main-Sonnet + Opus-subagent + Sonnet-subagent)

1. Перед любым Task(...) ещё раз проверь, что .vassal/index.yaml содержит документы и список доступных .vassal/mirrors/doc-*.md не пуст; если документов нет, верни SKILL_UNAVAILABLE с reason no documents и остановись без создания выходных файлов.
2. Собери prompt Opus-subagent по контрактам 3.0 и 3.1b:
   • ROLE: Ты юрист-аналитик в скилле prepare-hearing.
   • THINKING: think harder по умолчанию или override из shared/conventions.md.
   • CONTEXT:
     • case_root
     • абсолютные пути к .vassal/case.yaml, .vassal/index.yaml
     • абсолютные пути к .vassal/mirrors/doc-*.md
     • при наличии — абсолютные пути к .vassal/analysis/*.md
     • при наличии — абсолютные пути к hearings/*/analysis.md
   • TASK:
     • подготовка к заседанию через red/blue-team анализ;
     • собрать тактические заметки и список ходатайств на заседание;
     • каждое ходатайство оформить как отдельный сегмент markdown;
     • строго придерживаться структуры ветки 3.1b.
   • OUTPUT: единый markdown строго из двух типов блоков:
     • ## Заметки
     • ## Ходатайство N: <тема> + тело + финальная строка READY_FOR_DOCX: processual
3. Вызови Task с параметрами:
   • subagent_type: "general-purpose"
   • model: "opus"
   • description: 3-5 слов
4. Проверь OUTPUT через валидационный скрипт:
   • передай полный текст OUTPUT Opus-subagent в python3 "$PLUGIN_ROOT/scripts/validate_opus_output.py" --skill prepare-hearing --contract 3.1b --stdin;
   • скрипт должен вернуть valid=true.
5. Если valid=false, ровно один раз перезапусти Opus-subagent с напоминанием о контракте 3.1b и формате сегментов ## Ходатайство N: ..., затем повтори валидацию тем же скриптом. Если и после retry valid=false, верни PARSE_FAILED и остановись без запуска Sonnet-subagent.
6. До любых записей вычисли полный batch публикации:
   • всё до первого блока ## Ходатайство ... подготовь как содержимое будущего notes.md, но пока не записывай на диск;
   • создай {{hearings_root}}, если он отсутствует;
   • если {{hearing_dir}} уже существует и не передан --force, остановись до записи и сообщи о необходимости --force;
   • если передан --force, готовь новый выпуск в {{staging_dir}}, а замену {{hearing_dir}} делай только после полного успеха через атомарный перенос каталога;
   • все итоговые пути нормализуй и проверь, что они остаются внутри {{hearings_root}}; при выходе за пределы немедленно остановись.
7. Для каждого сегмента заранее вычисли целевой файл:
   • index = номер ходатайства из заголовка;
   • title = тема из заголовка;
   • body = текст сегмента без финальной строки READY_FOR_DOCX: processual;
   • slug(title) = безопасный ASCII-slug только из [a-z0-9-], полученный детерминированной нормализацией темы; пустой slug заменяй на document;
   • doc_name = ходатайство-{{index}}-<slug(title)>.docx;
   • проверь, что имена файлов уникальны внутри batch.
8. Запиши notes.md и все .docx только в {{staging_dir}}, а не в {{hearing_dir}}.
9. Для каждого сегмента запусти Sonnet-subagent по контракту 3.2:
   • markdown_input = body
   • case_meta = поля из .vassal/case.yaml
   • out_dir = {{staging_dir}}
   • doc_name = вычисленное имя файла
10. Если Sonnet-subagent возвращает SKILL_UNAVAILABLE, main-Sonnet сам вызывает arbitrum-docx для этого сегмента.
11. Если хотя бы один сегмент не сформирован, проверка путей не пройдена, либо formatter падает:

• удали {{staging_dir}};
• не записывай notes.md в финальный каталог;
• не оставляй частичных артефактов в {{hearing_dir}}.

12. Только после успешной генерации notes.md и всех N .docx выполни атомарную публикацию:

• без --force: переименуй {{staging_dir}} в {{hearing_dir}};
• с --force: сначала атомарно отведи старый {{hearing_dir}} в резервный sibling-каталог, затем атомарно переименуй {{staging_dir}} в {{hearing_dir}}, после успеха удали резервную копию.

Фаза 3 — Verify (main-Sonnet)

1. Проверь, что существует {{notes_path}}.
2. Проверь, что в {{hearing_dir}} созданы N файлов ходатайство-*.docx, где N равно числу валидных сегментов.
3. Для каждого .docx проверь:
   • файл существует;
   • файл не пустой.
4. Покажи Сюзерену короткое резюме:
   • путь к notes.md;
   • сколько ходатайств сформировано;
   • список итоговых .docx.

Дисциплина

• Не объединять несколько ходатайств в один .docx.
• Не пропускать секцию ## Заметки.
• Не записывать notes.md через arbitrum-docx.
• Не использовать single-document ветку 3.1a для prepare-hearing.
• Не публиковать файлы напрямую в {{hearing_dir}}: сначала полный batch в {{staging_dir}}, потом атомарный перенос.
• Не принимать hearing_date, не проходящий строгую маску YYYY-MM-DD.
• Не использовать тему ходатайства как имя файла без безопасного slug.
• Не перезаписывать существующий каталог заседания без явного --force.

Блокер

Если Task(model=opus) недоступен, дважды возвращает невалидный multi-document OUTPUT, или хотя бы один сегмент не проходит парсинг/форматирование:

• сообщи Сюзерену конкретную ошибку;
• не запускай частичную генерацию по невалидным сегментам;
• не подменяй контракт 3.1b ручной нарезкой произвольного текста.