Вычитка DOCX с отслеживаемыми правками

Оставлять исходный файл неизменным. Создавать рядом отдельную копию <имя> (с правками).docx.

Использовать быстрый контур scripts/proofread_fast.py вокруг готового движка scripts/redline_docx.py; не собирать OOXML временными скриптами и не подключать общий skill documents. Контур объединяет intake и extraction в одну команду, а review и audit — в другую. Обычный finish не требует LibreOffice и Poppler. Для опционального --visual нужны доступные в PATH команды LibreOffice soffice и Poppler pdftoppm.

Рабочий процесс

1. Если настроен knowledge_base_path, выполнить один узкий поиск терминологии: не более пяти релевантных карточек. Не открывать широкий корпус и оригиналы, если пользователь не просил проверять факты.

2. Одной командой подготовить файл и извлечь текст:

   python3 .agents/skills/proofread/scripts/proofread_fast.py prepare "ВХОД.docx"

   Если текущая рабочая область содержит каталог ПРОЕКТЫ, внешний файл, включая файл из Downloads, перемещается без перезаписи в отдельную папку ПРОЕКТЫ/<имя документа>/. Файл внутри рабочей области остаётся на месте. Если такого каталога нет, файл остаётся на месте; для явного intake можно передать --work-root "ПУТЬ".

   Номер [N] — адрес абзаца или ячейки. Повторяющийся одинаковый текст в выводе показывается один раз, но review по умолчанию исправляет все его копии. Маркер ⟨SHY⟩ означает мягкий перенос в исходном OOXML и не является частью текста для old.

3. Найти явные ошибки: опечатки, согласование, управление, пунктуацию, регистр, кавычки, тире, нумерацию, единообразие сокращений и неудачные канцелярские конструкции. Смысловые и числовые изменения вносить только при достаточном основании.

   Не считать визуально слитные слова ошибкой автоматически. Сначала проверить маркер ⟨SHY⟩ в выводе extract:

   • если между частями уже стоит мягкий перенос, считать его намеренным по умолчанию и не добавлять пробел, пока контекст явно не доказывает ошибку;
   • если мягкого переноса нет, а два самостоятельных слова действительно записаны слитно, считать это вероятной опечаткой и исправлять;
   • не удалять мягкие переносы при общей типографической нормализации.

4. Создать edits.json рядом с документом:

   {
     "author": "Корректор",
     "edits": [
       {
         "block": 12,
         "old": "текст с ошибкой",
         "new": "исправленный текст",
         "comment": "Формулировка допускает два прочтения; выбран вариант, согласованный с контекстом."
       }
     ]
   }

   Для author использовать revision_author из org_details.md, если он настроен; иначе оставить обезличенное значение Корректор. Использовать точный и минимально достаточный old: не заменять предложение целиком, если достаточно исправить слово, окончание или знак. Для удаления указать пустой new. Поле comment необязательно. Добавлять его только там, где читателю действительно нужно объяснение: при неоднозначности, смысловом или фактическом уточнении, неочевидном выборе нормы либо спорной стилистической правке. Не добавлять комментарии к пробелам, знакам препинания, регистру, кавычкам, тире, очевидным опечаткам и другим механическим исправлениям. Для правки только выбранного абзаца при наличии одинаковых копий добавить "all_duplicates": false; в остальных случаях оставлять значение по умолчанию true. Не допускать пересекающихся правок в одном абзаце.

5. Одной командой создать результат, выполнить встроенный preflight и структурный аудит:

   python3 .agents/skills/proofread/scripts/proofread_fast.py finish "ВХОД.docx" --edits edits.json

   По умолчанию результат — <имя> (с правками).docx; другой путь задаётся через --output. review сначала выполняет preflight и не заменяет выходной файл при NOT FOUND, AMBIGUOUS, overlaps, old == new и других ошибках. Устранить все найденные проблемы и повторить команду. Не запускать отдельный check: review уже включает preflight. Команда сохраняет результат атомарно только после успешных review и audit.

6. Принять файл только если в JSON-результате revision_runs == yellow_runs, количества комментариев и якорей совпадают. Нулевое количество комментариев допустимо.

   Для документа со сложными таблицами, колонтитулами, текстовыми блоками или крупными заменами, а также по прямому запросу пользователя добавить --visual. В этом режиме принять файл только если обе версии отрендерены, PNG непустые и page_count_changed имеет ожидаемое значение. Просмотреть каждую PNG-страницу из qa_output при 100 % и проверить отсутствие обрезки, наложений, повреждённых таблиц, пропавших символов и смещения колонтитулов.

7. Вернуть только итоговый DOCX. Кратко указать число содержательных комментариев, включая ноль, и сообщить, выполнялась ли визуальная проверка. Не отдавать edits.json, PDF и PNG без запроса.

Типографика русского текста

• Инициалы писать слитно, без пробелов: В.И. Фамилия. Между инициалами и фамилией использовать неразрывный пробел. Не вставлять пробелы внутрь устойчивых сокращений: в т.ч., т.е., т.к., и т.д., и т.п.. Перед единицами и знаком процента использовать неразрывный пробел.
• Не использовать длинное тире —. Среднее тире – ставить с пробелами между частями предложения, в том числе на месте нулевой связки и перед пояснением: реабилитация – непрерывный процесс. В числовых и временных диапазонах ставить среднее тире без пробелов: 2025–2026 годы, с. 5–10.
• Дефис - оставлять внутри сложных слов, сокращений и буквенно-цифровых обозначений: медико-социальный, вице-президент, 3D-модель.
• Использовать русские кавычки «...», внутри использовать „...“.
• Во всем документе заменять Ё на Е, а ё на е, включая имена собственные. Не добавлять букву ё при исправлениях.
• Не нормализовать всё форматирование документа без прямой просьбы.