Imported from rybnikov-aa/family (projects/skills-archive/project-renovation-update-from-pdf/SKILL.md). Install upstream with npx skills add rybnikov-aa/family --skill project-renovation-update-from-pdf. Copyright stays with the author.

Актуализация исходных документов проекта «Ремонт» из PDF

Что делает навык

Берёт PDF-файл (заказ материалов, акт выполненных работ, акт взаиморасчётов по работам или по материалам, дополнительное соглашение), вначале определяет его тип, извлекает содержимое и создаёт HTML-документ проекта projects/renovation/ в общем стиле проекта (каркас /projects/styles.css + тема light/dark/system + акцент #e8872e), с датированным именем (report_{yyyy-MM-dd}.html, act_{yyyy-MM-dd}.html и т.д.) и ссылкой на исходный PDF.

Созданные HTML — это «исходные данные» отчётности проекта: смета estimate.html, акты работ Works/, заказы материалов Materials/, акты взаиморасчётов по работам Works/ и по материалам Materials/. На них затем строятся отчёты (навык project-renovation-build-reports).

Главные правила:

• Этапы разделять: сначала только PDF → HTML, отчёты не трогать. При появлении PDF (особенно если в задаче упоминаются и PDF, и отчёты) первым этапом выполняется только распознавание PDF и сохранение HTML по инструкциям преобразования. Не пытаться сразу же обновлять отчёты (Reports/) на этом этапе — это отдельный шаг.
• Переход к обновлению отчётов возможен только после успешного завершения этапа PDF→HTML и подтверждения, что HTML корректен (пользователь подтвердил, либо отчёты запрошены отдельным сообщением). Отчёты строятся только из исходных HTML-файлов проекта (навык project-renovation-build-reports), а не из PDF.
• Тип документа определяется по содержимому PDF (см. «Определение типа документа»). Если тип определить не удаётся — спрашивать у пользователя. Если пользователь говорит, что файл не относится ни к одному из типов — пропустить файл.
• Перезапись запрещена: если файл с целевым именем уже существует — не перезаписывать (см. «Сохранение результатов»).
• Повторно не распознавать уже импортированные PDF. Перед распознаванием каждый PDF сверяется с уже существующими исходными HTML проекта (сметы estimate*.html, акты Works/*.html, заказы материалов Materials/*.html, ведомости *_settlement.html): если документ того же типа и с той же датой уже есть и совпадает с PDF (заголовок, итоги) — пропустить его, HTML не пересоздавать и PDF повторно не распознавать. Повторное распознавание выполнять только если пользователь явно указал это в запросе («перераспознай», «обнови по этому PDF» и т.п.).
• Каждый исходный HTML проекта обязан содержать корректную ссылку на исходный PDF (блок .doc-sources); если в уже существующем документе ссылки нет — добавить её по образцу (см. шаг 5).
• Без блоков подписей и ФИО заказчика. Документы проекта формируются без блоков подписей (.signatures, .approval) — они бессмысленны в HTML и не публикуются. Персональные данные заказчика (ФИО) в документах не публикуются: в ролевых блоках оставлять только роль («Заказчик», «Подрядчик») без имени либо не выводить их вовсе. Имена PDF-файлов на сервере не должны содержать ФИО заказчика.

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

• Пользователь принёс PDF и хочет «актуализировать»/дополнить документы проекта ремонта (новые акты, заказы материалов, взаиморасчёты, доп. соглашения).
• PDF загружены на сервер в public_html/projects/renovation/pdf/ (и подпапки), нужно сделать их видимыми в проекте как HTML-документы.
• Нужно добавить в проект документ с сохранением ссылки на первоисточник (PDF).

Входные данные (PDF)

Расположение PDF на сервере и в репозитории

• PDF загружаются пользователем на сервер в папку public_html/projects/renovation/pdf/ и её подпапки → публичный URL: /projects/renovation/pdf/<подпапка>/<файл>.pdf (или /projects/renovation/pdf/<файл>.pdf, если файл в корне папки).
• Эти подпапки на сервере сохраняются при деплое: скрипт scripts/deploy.mjs зеркалит репозиторий projects/ в public_html/projects/ через cp -a (сливает, не удаляя серверные подпапки вне репозитория), поэтому pdf/, загруженные напрямую, не теряются.
• Для локальной обработки нужны локальные копии PDF. Один из способов (на выбор):
  • пользователь кладёт PDF в репозиторий, например в projects/renovation/pdf/ (папка зеркалится 1:1, URL совпадает с серверным) или в temp/pdf/ для разовой обработки;
  • агент скачивает PDF с сервера по SSH/scp (доступ к серверу — см. навык deploy).
• Ссылки в HTML всегда указывают на серверный URL /projects/renovation/pdf/... — он корректен и на сервере, и локально (если папка pdf/ присутствует в репозитории).

Определение типа документа (шаг 1)

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

Признаки типов

1. Заказ материалов — заголовок/шапка: «Заказ материалов», «Заказ №…», «Закупка материалов», «Товарный чек», «Счёт на оплату» (материалы); таблица с колонками «Наименование / Ед. изм. / Цена / Кол-во / Сумма»; возможны строки «Доставка», «Подъём», «Накладные расходы». Итог — «Итого с накладными расходами».
2. Акт о выполненных работах — «Акт приёмки выполненных работ», «Акт выполненных работ», «Акт о приёмке выполненных работ»; таблица работ с колонками «Наименование работ / Ед. / Цена / Объём / Сумма»; итоги с накладными (5%).
3. Акт о взаиморасчётах — «Акт взаиморасчётов», «Акт сверки взаиморасчётов», «Взаиморасчёты»; ведомость с колонками «Внесено / Использовано / Остаток» (вносимые суммы заказчиком). Требуется уточнение подтипа — см. ниже.
4. Доп. соглашение — «Дополнительное соглашение», «Доп. соглашение», «Допсоглашение»; ссылки на договор/смету, изменения сумм или объёмов.

Акт взаиморасчётов: по работам или по материалам?

Определить подтип по содержимому:

• по работам — ведомость ссылается на работы/акты выполненных работ, строки «выполнено работ», «оплата за работы», «по акту №…», «остаток по работам» → Works/act_{yyyy-MM-dd}_settlement.html;
• по материалам — ведомость ссылается на материалы/заказы, строки «закуплено материалов», «по заказу №…», «оплата материалов», «остаток по материалам» → Materials/report_{yyyy-MM-dd}_settlement.html.

Если однозначно не получается — спросить у пользователя («это взаиморасчёты по работам или по материалам?»).

Не удалось определить тип

Если по содержимому и имени файла тип не определяется — спросить у пользователя и предложить список типов (1–4). Если пользователь отвечает, что файл не относится ни к одному из типов — пропустить файл (не создавать HTML), сообщить об этом в итоге.

Процедура

1. Получи локальные копии PDF и отфильтруй уже импортированные

• Собери список PDF: папка на сервере /projects/renovation/pdf/ (и подпапки), либо локальная папка/файлы, которые дал пользователь.
• Если PDF только на сервере — скачай копии локально (SSH/scp, навык deploy) во временную папку (например, temp/pdf/), сохраняя относительные подпапки — по ним восстановится URL ссылки.
• Отфильтруй уже импортированные PDF: для каждого файла сопоставь его с уже существующими исходными HTML по типу и дате (таблица типов + датированное имя). Если соответствующий HTML уже есть и его данные совпадают с PDF (заголовок, итог) — пропусти файл: не определяй тип заново, не распознавай содержимое и не создавай HTML. Повторное распознавание — только по явному указанию пользователя в запросе. В итоге перечисли, какие PDF пропущены как уже импортированные.

2. Определи тип и дату каждого файла

• Определи тип по разделу «Определение типа документа». Неуверенность — спрашивай.
• Определи дату документа (она идёт в имя файла {yyyy-MM-dd}): из шапки документа («от 05-08-2026», «№2 от 17-07-2026», «Акт составлен 06.08.2026»). Если даты в документе нет — спросить у пользователя. Не использовать дату модификации файла как дату документа.

3. Извлеки содержимое

Используй механику навыка parse-pdf: pdfplumber для таблиц, PyMuPDF для текста/картинок. Выведи структуру (страницы, таблицы, строки/колонки), склей таблицы, разорванные между страницами, удали дубли из-за разрыва страниц. Не выдумывай числа — всё берётся только из PDF.

4. Сгенерируй HTML

Единый макет документа проекта «Ремонт» (см. «Конвенции оформления»): каркас проекта (/projects/styles.css + тема + дизайн-система report.css с акцентом #e8872e), контейнер .doc, шапка .doc-head (заголовок h1 + чипы .meta-item + карточка итога .doc-head-total), таблицы из report.css, тёмная тема из токенов, ссылка возврата <a class="doc-back" href="/projects/renovation/">.

Структура по типам (образцы — существующие файлы projects/renovation/):

• Заказ материалов — образец Materials/report_2026-07-17.html: заголовок «Заказ материалов …», иконка #package, чипы (объект, подрядчик, дата старта), итог .doc-head-total «Итого по заказу», таблица «№ / Наименование / Ед. изм. / Цена / Количество / Сумма», строка row-total «Итого, с учетом накладных расходов» и .total-box.
• Акт выполненных работ — образец Works/act_2026-07-26.html: заголовок «Акт приёмки выполненных работ …», иконка #clipboard, таблица «№ / Наименование работ / Ед. / Цена / Объём / Сумма», итоги раздела row-total, блок .totals-block (всего, накладные 5%, итого с накладными).
• Акт взаиморасчётов — образец Works/act_2026-07-26_settlement.html (по работам) / Materials/report_2026-07-17_settlement.html (по материалам): заголовок «Ведомость/Акт взаиморасчётов (работы/материалы)», иконка #money, ведомость «№ / Дата / Обоснование / Внесено / Использовано / Остаток, итоги .totals-block`.
• Доп. соглашение — по образцу сметы estimate.html, но компактнее: заголовок «Дополнительное соглашение №…», иконка #clipboard, чипы (объект, подрядчик, договор, дата), краткая таблица изменений (позиция / было / стало / сумма), итог изменений.

5. Добавь ссылку на исходный PDF

В конце документа (после итоговых блоков — единообразно во всех документах) добавь блок «Исходный документ (PDF)»:

<div class="doc-sources">
  <svg class="picon" aria-hidden="true"><use href="/projects/icon-sprite.svg#link"></use></svg>
  <span class="doc-sources-label">Исходный документ (PDF):</span>
  <a href="/projects/renovation/pdf/<подпапка>/<файл>.pdf" target="_blank" rel="noopener"
    ><файл>.pdf</a
  >
</div>

Локальные стили (в <head> вместе с остальными табличными стилями) + тёмная тема:

.doc-sources {
  display: flex;
  align-items: center;
  gap: 8px;
  flex-wrap: wrap;
  margin-top: 16px;
  padding: 12px 16px;
  border-radius: 12px;
  background: #f3f7fc;
  border: 1px solid #e2eaf4;
  font-size: 14px;
  color: #3f5672;
}
.doc-sources .picon {
  color: var(--project-accent);
}
.doc-sources a {
  color: var(--project-accent);
  font-weight: 600;
  text-decoration: none;
}
.doc-sources a:hover {
  text-decoration: underline;
}
[data-theme='dark'] .doc-sources {
  background: #16233a;
  border-color: #23344f;
  color: #9fb0c6;
}

Ссылка всегда абсолютная на серверный URL /projects/renovation/pdf/... (см. «Входные данные»).

Блок .doc-sources обязателен во всех исходных документах проекта, включая ранее созданные (сметы estimate*.html, акты Works/*.html, заказы материалов Materials/*.html, ведомости *_settlement.html). Если в существующем HTML ссылки нет — добавить блок .doc-sources (вместе со стилями и тёмной темой) по этому же образцу, указав путь к соответствующему PDF.

6. Сохрани файл (датированное имя, без перезаписи)

• Имя — по таблице типов с датой документа: report_{yyyy-MM-dd}.html, act_{yyyy-MM-dd}.html, act_{yyyy-MM-dd}_settlement.html, report_{yyyy-MM-dd}_settlement.html, estimate_add_{yyyy-MM-dd}.html.
• Проверь существование целевого файла перед созданием. Если файл существует — не перезаписывать:
  • если это тот же документ (повторный импорт того же PDF) — пропустить и сообщить; повторно распознавать такой PDF только по явному запросу пользователя;
  • если это другой документ с той же датой — имя формируется детерминированно, без запроса у пользователя: к датированному имени добавляется номер документа _n{N}, где N — номер из документа (для доп. соглашения — номер соглашения). Примеры: estimate_add_2026-08-05_n3.html (доп. соглашение №3), act_2026-07-26_n2.html (акт №2), report_2026-08-05_n3.html (заказ материалов №3). Если номера в документе нет — добавить суффикс _b, _c и т.д. по порядку (report_2026-08-05_b.html).
• Проект использует датированные имена (report_{yyyy-MM-dd}.html, act_{yyyy-MM-dd}.html, *_settlement.html). Старые нумерованные файлы (report_01.html, act_01.html) уже переименованы в датированные (например, report_2026-07-17.html, act_2026-07-26.html) — новые документы создавать только с датированными именами по таблице типов.

7. Проверь

• Открой созданный HTML в браузере (file:///c:/Users/alex/Code/family/projects/renovation/...).
• Сверь числа с PDF: все позиции, цены, объёмы, суммы и итоги совпадают, ничего не потеряно и не задвоено, кириллица корректна.
• Проверь, что ссылка на исходный PDF открывается (на сервере; локально — если pdf/ в репозитории).
• Проверь тему light/dark и адаптив таблиц.

Доп. соглашение к смете: обновление estimate.html

Доп. соглашение меняет условия договора/сметы (цены, объёмы, позиции). При появлении доп. соглашения (тип 4, HTML-файл estimate_add_{yyyy-MM-dd}.html, полученный из PDF) смету нужно актуализировать. Работаем только с HTML-файлами — входные данные для этого сценария всегда HTML (результат преобразования PDF), а не сам PDF.

Схема хранения сметы

• estimate_seed.html — исходная смета, никогда не меняется. Точка отсчёта для истории.
• estimate.html — актуальная смета, обновляется каждый раз при появлении доп. соглашения.
• estimate_{yyyy-MM-dd}.html — исторические копии актуальной сметы: сразу после обновления estimate.html делается его копия с именем estimate_{yyyy-MM-dd}.html, где дата — дата доп. соглашения (формат yyyy-MM-dd). Файлы хранятся рядом с estimate.html для истории изменений.

Шаг 1. Проверь входной HTML доп. соглашения

• Вход — estimate_add_{yyyy-MM-dd}.html (HTML, созданный при преобразовании PDF по этому навыку).
• Убедись, что HTML корректен (см. «Проверь» в процедуре конвертации), прежде чем применять.

Шаг 2. Сопоставь строки и обнови estimate.html

Возьми за основу текущую estimate.html (актуальную) и внеси изменения из доп. соглашения.

Сопоставление по разделам:

• Если в доп. соглашении содержится целый раздел (например, «Раздел 5. Электрика») — сопоставление строк выполняем только с аналогичным разделом из исходной сметы, а не со всей сметой. Строки из других разделов сметы не затрагиваются.
• Строки доп. соглашения сопоставляются со строками соответствующего раздела сметы по наименованию (текст полностью совпадает, либо частично содержит ключевые слова).

Обработка строк доп. соглашения (по каждой строке):

1. Полное совпадение по наименованию с существующей строкой → обновляем её в смете (цена, объём, сумма) и помечаем синим (row-changed). Дубль не создаём.
2. Частичное совпадение по наименованию → запросить варианты у пользователя:
   • обновляем существующие строки (тогда помечаем их синим row-changed);
   • обрабатываем как новые строки, а существующие частично совпадающие строки считаем отсутствующими в доп. соглашении и обрабатываем их по правилам для отсутствующих (п. 4).
3. Строки, которых нет в смете → считаем новыми, добавляем их в смету и помечаем жёлтым (row-new).
4. Строки сметы, которых нет в доп. соглашении (в рамках сопоставляемого раздела) → запросить варианты у пользователя:
   • оставляем в смете без изменений (возможно, по этим строкам будет отдельное доп. соглашение);
   • удаляем из сметы (тогда в предыдущей версии сметы, из которой удаляли, эти строки необходимо пометить красным row-removed — в актуальной estimate.html их уже нет).

После сопоставления:

• Перенумеруй позиции и разделы в смете (нумерация сквозная: если добавлены строки в «Раздел 5», последующие разделы сдвигаются).
• Пересчитай итоги разделов (row-total), «Итого по всем разделам», накладные и «ВСЕГО с накладными».
• Обнови сумму в doc-head-total на новую сумму сметы.

Цветовая разметка строк (классы + локальные стили в <head> + тёмная тема):

• обновлённые по доп. соглашению — синий row-changed;
• новые строки из доп. соглашения — жёлтый row-new;
• удалённые строки (в предыдущей версии сметы) — красный row-removed.

.row-changed td {
  color: #1a63d6;
  background: rgba(26, 99, 214, 0.06);
}
[data-theme='dark'] .row-changed td {
  color: #7ab0ff;
  background: rgba(122, 176, 255, 0.12);
}
.row-new td {
  color: #8a6d00;
  background: rgba(240, 196, 25, 0.12);
}
[data-theme='dark'] .row-new td {
  color: #f0c419;
  background: rgba(240, 196, 25, 0.16);
}
.row-removed td {
  color: #b12a2a;
  background: rgba(177, 42, 42, 0.08);
  text-decoration: line-through;
}
[data-theme='dark'] .row-removed td {
  color: #ef7d70;
  background: rgba(177, 42, 42, 0.18);
}

• В примечание сметы добавь строку: синим выделены обновлённые строки, жёлтым — новые, красным — удалённые по доп. соглашению, со ссылкой на estimate_add_{yyyy-MM-dd}.html.

Шаг 3. Сделай историческую копию

• Сразу после обновления estimate.html скопируй его в estimate_{yyyy-MM-dd}.html (дата — дата доп. соглашения, формат yyyy-MM-dd), чтобы зафиксировать состояние сметы в истории.
• Не допускать перезаписи: если estimate_{yyyy-MM-dd}.html уже существует — не перезаписывать; спросить у пользователя (например, суффикс _b) либо пропустить.
• estimate_seed.html при этом не трогать (никогда не изменяется).
• Если какие-то строки были удалены из сметы по доп. соглашению — в предыдущей версии сметы (той, из которой удаляли, т.е. текущем estimate.html до обновления или в estimate_seed.html) удалённые строки пометить красным row-removed, чтобы зафиксировать факт удаления в истории.

Шаг 4. Проверь

• Открой estimate.html: изменения из доп. соглашения применены, изменённые строки размечены цветом (синий — обновлённые, жёлтый — новые; светлая и тёмная темы), итоги пересчитаны и сходятся.
• Историческая копия estimate_{yyyy-MM-dd}.html существует и совпадает с актуальной estimate.html.
• estimate_seed.html не изменён.

Конвенции оформления (единый макет документа)

Документы — подстраницы проекта «Ремонт», поэтому:

• <!doctype html>, <html lang="ru" data-theme="light">, inline-скрипт применения темы в <head> (без «мигания»), шрифт Inter, <link href="/projects/styles.css">, затем дизайн-система <link href="/projects/renovation/report.css"> (в подпапках Materials/, Works/ — ../report.css); она задаёт акцент #e8872e, токены тем, таблицы и адаптив.
• Разметка: <div class="container"> → <header class="header"> (бренд + навигация + <div class="theme-toggle" data-theme-toggle></div>) → <main class="page"> → <footer class="footer">; в конце body — <script src="/projects/theme.js" defer></script>.
• Контент в <div class="doc">; в начале — <a class="doc-back" href="/projects/renovation/">← К отчётам проекта</a> (стиль .doc-back — как в существующих документах).
• Контейнер .doc: max-width: 1550px, border-radius: 24px, padding: 30px 24px 40px, box-shadow: 0 16px 48px rgba(0,20,40,.1), overflow-x: auto.
• Шапка .doc-head (грид 1fr auto): h1.doc-head-title отдельной строкой, слева чипы .meta-item (объект, подрядчик, дата старта 30.06.2026), справа .doc-head-total (подпись .head-total-label + .total-big).
• Иконки — только SVG из спрайта /projects/icon-sprite.svg (цвет сохранён), без эмодзи: #package (заказ материалов), #clipboard (акт работ / доп. соглашение), #money (взаиморасчёты), #link (ссылка на исходный PDF).
• Таблицы — из report.css, оборачивать в <div class="table-wrap">. Классы колонок ставить и на <td>, и на <th> (col-unit, col-price, col-qty, col-sum, col-desc и т.п.) — скрытие колонок на узких экранах работает по классам. Классы общего каркаса (.container, .header, .footer, .card, .stats, .stat) внутри документа не использовать. Классы: col-num, col-name, col-unit, col-price, col-qty, col-sum, row-total, row-changed, totals-block, total-box.
• Таблицы без жёсткого min-width (100% ширины); на ≤1100px скрываются «Ед.» и «Цена», на ≤700px — «Объём» через visibility: hidden + width: 0 (колонки не удалять из сетки — colspan в итогах корректный). На телефоне широкая таблица прокручивается внутри .table-wrap — страница не уезжает.
• Числа — как в проекте: неразрывный пробел и запятая как десятичный разделитель (141 127,88 ₽); в PDF может быть точка (134 407.50) — приводить к запятой.
• Тёмная тема — автоматически из report.css (токены); отдельные переопределения не нужны. Проверить светлую и тёмную темы.
• Комментарии в коде и строки UI — на русском.

Сохранение результатов

• Создавать только новые файлы по таблице типов с датой из документа (report_{yyyy-MM-dd}.html и т.д.).
• Не перезаписывать существующие файлы (см. шаг 6 процедуры).
• Не класть документы не в свою папку (материалы → Materials/, работы → Works/, взаиморасчёты → по подтипу, доп. соглашение → рядом с estimate.html).
• Не размещать копии в корне /projects/renovation/ (кроме index.html, доп. соглашений estimate_add_*.html и исторических копий сметы estimate_{yyyy-MM-dd}.html).

После импорта

Импортированные документы — исходные данные для отчётности. Предложить пользователю:

• пересобрать отчёты (Reports/) навыком project-renovation-build-reports, если добавлены акты/заказы/взаиморасчёты или обновлена смета (доп. соглашение);
• при необходимости обновить карточки/статистику на projects/renovation/index.html.

Акты взаиморасчётов — кумулятивные. При импорте нового акта (*_settlement.html) старые остаются без изменений для истории (не перезаписываются). В отчётности учитывается только самый последний акт каждого типа (по дате в имени файла) — см. навык project-renovation-build-reports.

Отчёты не пересобирать в этом же проходе — это отдельный этап, который выполняется только после подтверждения корректности созданных HTML и по явному запросу пользователя (либо отдельным сообщением «пересобери отчёты»). При пересборке использовать только исходные HTML-файлы (estimate.html, Works/, Materials/), а не PDF. Деплой — npm run deploy только после подтверждения пользователя.

Проверка

• Каждый созданный HTML открывается, таблицы и итоги совпадают с PDF.
• Ссылка /projects/renovation/pdf/... корректна и ведёт на исходный PDF.
• Тема light/dark работает, кириллица корректна, ничего не задвоено.
• Целевой файл не был перезаписан; при совпадении даты у другого документа имя сформировано детерминированно (_n{N} — по номеру документа либо _b/_c… при отсутствии номера).
• Для доп. соглашения: историческая копия estimate_{yyyy-MM-dd}.html создана без перезаписи; в актуальной estimate.html строки размечены цветом — обновлённые синим (row-changed), новые жёлтым (row-new); при удалении строк — в предыдущей версии красным (row-removed); итоги пересчитаны; estimate_seed.html не изменён.

Синхронизация документации

• Если в ходе работы изменился макет/структура документов проекта — обновить этот навык и docs/specification-projects.md в том же изменении.

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

• Не выдумывать числа — все суммы/объёмы/цены брать только из PDF.
• Не перезаписывать существующие файлы без согласования.
• Не смешивать десятичные разделители — приводить к запятой.
• Не класть документ в несоответствующую папку (работы в Materials/ и т.п.).
• Не использовать эмодзи как иконки — только SVG из /projects/icon-sprite.svg.
• Не использовать классы общего каркаса внутри документа.
• Не использовать дату модификации файла как дату документа — дата берётся из документа.
• Не пропускать документ, чей тип просто «похож» — при сомнении спрашивать пользователя.
• Не игнорировать строки «Доставка/Подъём» и «Накладные расходы» — они влияют на итоги.
• Не перезаписывать существующую историческую копию estimate_{yyyy-MM-dd}.html.
• При обновлении сметы по доп. соглашению не забыть пересчитать итоги (разделы и общий), разметить строки цветом (обновлённые — синим row-changed, новые — жёлтым row-new, удалённые в предыдущей версии — красным row-removed) и сразу сделать историческую копию estimate_{yyyy-MM-dd}.html. estimate_seed.html не менять никогда.
• При частичном совпадении наименований и при отсутствующих в доп. соглашении строках сметы не принимать решение самому — запрашивать варианты у пользователя.

Пример вызова агента

На сервере в public_html/projects/renovation/pdf/ появились новые PDF: Акт_выполненных_работ_2.pdf и Заказ_материалов_3.pdf. Актуализируй документы проекта.

Пришло доп. соглашение Допсоглашение_к_договору.pdf: сконвертируй в HTML estimate_add_{yyyy-MM-dd}.html, примени изменения в estimate.html (обновлённые строки — синим row-changed, новые — жёлтым row-new), сразу сделай историческую копию estimate_{yyyy-MM-dd}.html; estimate_seed.html не трогай.