Dopsoglasheniya Po Oplate

Допсоглашения По Оплате

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю «Допсоглашение об оплате аренды»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Ownership

Это доменный asset, принятый в библиотеку через repo-контракт и подготовленный к публикации как командный skill.

• исходный автор workflow: Елизавета;
• текущий owner в registry: см. skill.yaml;
• публичный skill содержит процесс, обезличенные примеры и проверяемый генератор, но не хранит raw-реквизиты, приватные договоры или внутренние эталонные блоки.

Когда Использовать

Используйте skill, когда пользователь просит сделать ДС, допник или дополнительное соглашение к договору аренды/найма по одному из трех сценариев:

• перенос оплаты на постоплату;
• разовый вычет из арендной платы;
• разовое изменение суммы аренды за конкретный месяц.

Skill должен собирать документ как конструктор: шапка, преамбула арендатора, преамбула арендодателя, тело под тип ДС и подписной блок.

Privacy Boundary

Не переносите в публичный repo raw-реквизиты, приватные договоры, ИНН, номера свидетельств, личные адреса объектов или внутренние эталонные формулировки без явного privacy-review.

В этом skill зафиксирована структура и проверяемый процесс. Рабочие реквизиты берутся из предоставленного договора и показываются пользователю на сверку перед генерацией. Если для конкретной команды нужны закрытые эталонные блоки, храните их в приватном источнике и подключайте как входные данные, а не как публичный repo text.

Контрфактический Гейт Рабочего Вопроса

Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений.

Перед любым вопросом проведи контрфактическую проверку: Представь наиболее вероятные ответы пользователя. Назови, какое решение, действие или часть результата изменит каждый ответ. Если следующий шаг при всех ответах одинаков — вопрос запрещён. Если пользователь уже зафиксировал выбор — запиши его, не открывай заново. Если неизвестное техническое и его можно проверить самостоятельно — проверь, не спрашивай. Задавай только ближайший вопрос, ответ на который реально меняет результат.

Процесс

1. Найдите договор, на основе которого нужно сделать ДС.
2. Определите формат договора:
   • .docx можно читать механически;
   • .pdf сначала проверьте на текстовый слой;
   • скан без текстового слоя требует OCR или ручного визуального чтения.
3. Извлеките реквизиты сторон, дату договора, адрес объекта, вид договора и исходный порядок оплаты.
4. Покажите пользователю извлеченные реквизиты на сверку до генерации. Особенно сверяйте ИНН, даты, номера свидетельств, ФИО и адрес.
5. Определите номер ДС: проверьте папку объекта на предыдущие допсоглашения. Не хардкодьте N 1; если номер неясен, спросите пользователя.
6. Уточните тип ДС и параметры:
   • для постоплаты: период, день оплаты, условия возврата к обычному порядку;
   • для вычета: месяц и сумма цифрами и прописью;
   • для изменения суммы: месяц и новая сумма цифрами и прописью.
7. Соберите JSON config для scripts/build_ds.py и сгенерируйте DOCX.
8. Проверьте документ визуально: A4, Times New Roman, корректные преамбулы, суммы цифрами и прописью, подписи не разрываются.
9. Покажите пользователю результат и список реквизитов, по которым собирался ДС.

Конструктор

Используйте references/bloki-DS.md как карту веток. Он намеренно содержит обезличенные шаблоны и поля конфигурации, а не приватные реквизиты конкретных контрагентов.

Генератор принимает два обязательных пользовательских слоя:

• tenant.full_clause и tenant.short_name - формулировка арендатора из договора;
• landlord - статус и реквизиты арендодателя, извлеченные из договора.

Если в договоре встретилась новая ветка, не подгоняйте ее под ближайшую старую. Зафиксируйте новый случай, покажите пользователю, что именно изменилось, и предложите отдельный patch в reference-файл после privacy-review.

Антипаттерны

• Не генерируйте юридически значимый документ без сверки извлеченных реквизитов.
• Не считайте OCR безошибочным источником для ИНН, дат и номеров свидетельств.
• Не подставляйте статус арендодателя по догадке.
• Не выдумывайте сумму, месяц, день оплаты или номер ДС.
• Не оставляйте пустые поля в готовом DOCX.
• Не превращайте этот skill в юридическое заключение: он собирает документ по утвержденному шаблону и требует человеческой проверки.

Опрос После Использования

Опрос задаётся один раз — после передачи готового DOCX и финальной проверки, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании dopsoglasheniya-po-oplate было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/dopsoglasheniya-po-oplate/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил реквизиты, OCR дал неверное значение, генератор собрал неверную ветку, документ визуально сломался или пришлось добавлять новый case в конструктор, запишите приватную карточку в ~/.codex/skill-runs/dopsoglasheniya-po-oplate/exception-log.jsonl.

Пишите факты: какой договор был входом, какой тип ДС собирался, что было извлечено, где возникла ошибка, какая предпосылка оказалась неверной и что делать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.

Definition Of Done

Задача закрыта, когда:

• тип ДС и параметры подтверждены пользователем;
• реквизиты сторон сверены с договором;
• номер ДС проверен по папке объекта или явно подтвержден пользователем;
• DOCX сгенерирован без пустых полей;
• документ визуально проверен;
• пользователь видит, из каких реквизитов и веток был собран результат.