add-evidence

name	add-evidence
description	Приём дополнительных доказательств от клиента в **уже ведущееся** дело. Используй этот скилл, когда юрист говорит «вот дополнительные документы», «клиент прислал ещё файлы», «добавь доказательства», «новые материалы от клиента», «приобщи к делу». НЕ используй для первичного приёма (это `intake`) и для документов оппонента (это `add-opponent`).

add-evidence — Приём дополнительных доказательств

Скилл работает по контракту plan → review → (revise) → apply → verify. Оркестрацию ведёт main-Sonnet. Механическую классификацию, черновые подсказки по имени и типу документа main-Sonnet делегирует Haiku-subagent по контракту 3.3A из shared/subagent-dispatch.md. Main-Sonnet сам принимает решения о встраивании в существующую хронологию, обновляет индекс и пишет итоговые файлы.

Предусловия

• Дело инициализировано: .vassal/case.yaml существует.
• Intake уже выполнен: в .vassal/index.yaml есть хотя бы одна запись. Если индекс пуст — предложи сначала /vassal-litigator-cc:intake.
• Папка Входящие документы/ существует и в ней хотя бы один новый файл.
• Зависимости установлены (setup.sh запущен хотя бы один раз).
• Доступен Task с model: "haiku" для субагентного вызова по контракту 3.3.

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

• plan_timestamp = ГГГГ-ММ-ДД-ЧЧмм
• batch_name = evidence-ГГГГ-ММ-ДД
• plan_path = .vassal/plans/add-evidence-<plan_timestamp>.md
• work_dir = .vassal/work/add-evidence-<plan_timestamp>/
• next_id_hint = next_id из .vassal/index.yaml

Создай пустые .vassal/plans/ и .vassal/work/, если их нет.

Фаза 1 — Plan (main-Sonnet + Haiku-subagent)

1. Прочитай .vassal/case.yaml, .vassal/index.yaml и список файлов в Входящие документы/.
2. Подготовь {{work_dir}}, выполнив скрипт:

   python3 "$PLUGIN_ROOT/scripts/prepare_intake_workdir.py" "$INCOMING_DIR" --work-dir "$WORK_DIR"
   

   Распарси JSON: поля files[] (каждый элемент: source_path, extracted_text_preview, needs_image_to_pdf, archive_src), archives_unpacked, unsupported. Если unsupported[] не пуст — сообщи Сюзерену о неподдерживаемых или проблемных архивах. Передай список files[] в Haiku-subagent для планирования.
3. Для каждого файла или малого батча вызови Haiku-subagent по контракту 3.3A:
   • передай список files[] из JSON скрипта (поля source_path и extracted_text_preview);
   • запроси чистый YAML file/new_name/doc_type;
   • Task: subagent_type: "general-purpose", model: "haiku", description 3-5 слов.
4. Main-Sonnet принимает OUTPUT от Haiku и сам решает:
   • создаётся новый комплект или документ встраивается в существующий;
   • нужен ли bundle_id, role_in_bundle, parent_id, attachment_order;
   • не является ли файл already_processed.
5. Запиши полный markdown-план в {{plan_path}}. План должен явно показывать:
   • новые комплекты;
   • присоединения к существующим комплектам;
   • сироты;
   • конверсии изображений;
   • уже обработанные файлы (пропуск).
6. Если OUTPUT Haiku невалиден — один retry с тем же контрактом. После повторного сбоя остановись и покажи блокер.

Фаза 2 — Review Сюзереном

1. Прочитай {{plan_path}} целиком.
2. Покажи Сюзерену весь план как есть.
3. Отдельно акцентируй секцию «Присоединения к существующим комплектам»: это самое чувствительное место ревью.
4. Спроси: «Подтверждаешь? Или нужны правки?»
5. Подтверждение → Фаза 3. Правки → Фаза 2b. Отмена → остановка.

Фаза 2b — Revise

1. Возьми буквальный текст правок Сюзерена как revise_feedback.
2. Пересобери план в тех же {{plan_path}} и {{work_dir}}.
3. Вернись к Фазе 2.

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

1. После подтверждения прочитай утверждённый {{plan_path}} и примени его без творческих отклонений.
2. Main-Sonnet сам:
   • копирует исходники в .vassal/raw/{{batch_name}}/;
   • конвертирует изображения в PDF;
   • создаёт md-зеркала;
   • раскладывает новые доказательства по действующей хронологии;
   • обновляет .vassal/index.yaml, bundle-поля и .vassal/history.md;
   • очищает Входящие документы/, активный {{plan_path}} и {{work_dir}}.
3. Уже обработанные файлы не получают новый doc-ID и не добавляются в индекс повторно.

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

1. Прочитай .vassal/index.yaml и найди только новые записи с origin.batch: evidence-*.
2. Убедись, что у новых записей:
   • source: client;
   • корректно выставлены bundle_id/role_in_bundle/parent_id, если документ встроен в комплект;
   • для каждого документа вызови python3 "$PLUGIN_ROOT/scripts/classify_ocr_quality.py" --extraction-method <extraction_method> --confidence <confidence> --total-chars <total_chars> --pages <pages> и подставь ocr_quality/ocr_quality_reason из JSON-ответа скрипта. Если total_chars или pages неизвестны или отсутствуют, передавай значение "" или "null" — скрипт обработает их как None и не упадёт.
3. Если отдельный /vassal-litigator-cc:reocr не запускался, для обычного прохода фиксируй ocr_reattempted: false. Если качество низкое, обязательно оставь ocr_quality_reason и вынеси это в итоговое резюме.
4. Проверь, что для каждой новой записи создано зеркало .vassal/mirrors/doc-*.md, а Входящие документы/ очищена от файлов из плана.
5. Финальное резюме Сюзерену: N новых записей, M новых комплектов, J присоединений, S сирот, K изображений → PDF, D пропущено, low/empty OCR: X.

Примечание: legacy-директория .vassal/codex-logs/ может остаться от дел v0.5.x, но v0.6.0 её не создаёт и не использует; текущий прогон фиксируется через .vassal/history.md.

Идемпотентность

План сам детектирует уже обработанные файлы по origin.name + origin.archive_src в .vassal/index.yaml и помечает их как already_processed: true. Такие файлы не индексируются повторно.

Блокер при недоступном Haiku-subagent

Если Task(model=haiku) недоступен или возвращает непарсируемый OUTPUT даже после повторного вызова:

• Сообщи Сюзерену: Haiku-subagent недоступен, add-evidence остановлен. Нужен рабочий Task(model=haiku) по контракту 3.3.
• Покажи конкретную ошибку.
• Не подменяй subagent ручной классификацией в main-Sonnet.