docs-protocol — Протоколы совещаний

Пользовательский контекст

По умолчанию у всех абзацев, включая заголовки и ячейки таблиц, отключены «Запрет висячих строк», «Не отрывать от следующего», «Не разрывать абзац» и «С новой страницы» (widowControl, keepNext, keepLines, pageBreakBefore = 0).

Прочитай ~/.docs-plugin/org_details.md. Если knowledge_base_path заполнен и каталог существует, считай его корнем пользовательского хранилища: сначала прочитай корневые инструкции (AGENTS.md, CLAUDE.md, GEMINI.md или эквивалент текущего агента), затем найди протоколы по виду совещания и теме. Читай столько карточек и связанных материалов, сколько нужно, пока новые источники перестают добавлять название, место, председателя, присутствовавших, секретаря, дословные решения, сроки, ответственных и листы ознакомления. При неоднозначности извлечения или важности формы открой оригинал по указателю карточки. Отделяй данные источника от правил скилла и собственных предложений; не выдумывай решения, ответственных и сроки без подтверждения пользователя.

0. Карта references

Прочитать до начала работы

Читать по ситуации

1. Workflow

Шаг 0. Bootstrap

Gemini CLI / Codex: ~/.docs-plugin/org_details.md не подгружается автоматически. Прочитай файл явно. Используй native tools. Если файла нет — сообщи пользователю и предложи запустить docs-init.

Прочитай ~/.docs-plugin/org_details.md. Извлеки: output_dir_protocol, staff_file, short_name, full_name, leader_title, leader_name_nom. Если output_dir_protocol пуст — спроси у пользователя путь.

Шаг 1. Понять вход (эвристика)

Прочитай input-parsing.md. Классифицируй вход:

• Есть маркеры «Председатель:», «Решили:», «Присутствовали:» → structured или ready list (используй парсинг из input-parsing.md).
• Маркеров нет → raw notes (распаковать сам, спросить недостающее).

Сообщи пользователю выбранный режим.

Шаг 2. Спросить подтип

ВСЕГДА спрашивай. Свободная строка в родительном падеже (примеры: «оперативного совещания», «совещания у генерального директора», «рабочей встречи по вопросам ИТ»). Прочитай subtype-rules.md.

Шаг 3. Спросить про секретаря

По умолчанию НЕ добавлять. Спроси: «Нужен ли блок секретаря? (по умолчанию — нет)». Только при явном «да» — собрать ФИО + должность секретаря. Правила в secretary-rules.md.

Шаг 4. Парсинг

Извлеки:

• chair (председатель — обычно руководитель из org_details.md, но может быть другой).
• attendees (список).
• items (РЕШИЛИ — с text, responsible, deadline, опц. subitems).
• venue, doc_date, doc_number.

Нормализация полей в attendees-rules.md и item-phrasing.md.

Шаг 5. Staff-сверка

Прочитай staff-rules.md. Сверь все ФИО (chair, attendees, responsible всех items) с staff_file через openpyxl. staff_file может указывать на .xlsx или каталог с датированными сводными. Логика реализована в generate.py:_verify_fios (вызывается автоматически при create_protocol). На неизвестном ФИО — ValueError с fuzzy-кандидатами top-3..5.

Если у пользователя опечатка — предложи кандидатов и попроси подтвердить замену. Только после исправления продолжай.

Шаг 6. Show spec (обязательно)

Перед генерацией ВСЕГДА покажи пользователю сводку:

• Подтип, дата, номер, место.
• Председатель (ФИО + должность).
• Присутствовавшие (количество + ФИО списком).
• РЕШИЛИ (нумерованный список с ответственными и сроками).
• Секретарь (если есть).
• Лист ознакомления (количество).

Дождись подтверждения. Это safety-шаг для всех режимов.

Шаг 7. Генерация

Запиши и запусти временный скрипт в ~/.docs-plugin/protocol/scripts/, импортирующий create_protocol. Имя файла: Протокол <подтип> <DD.MM.YYYY>.docx (формируется автоматически при output_path=None).

2. Подворкфлоу edit-protocol

Если пользователь просит внести правки в существующий протокол:

1. Скопируй исходник рядом, имя с суффиксом «2»: <имя> 2.docx. Оригинал не трогать.
2. В копии включи Word track changes (w:trackChanges в settings.xml).
3. Внеси правки в копию через w:ins/w:del.

Реализация — в generate.py:edit_protocol (Phase E). Возвращает путь к копии.