server-monitor-manager/agents/antigravity/inbox/from-smm-deliverables/Старые задачи/smm-antigravity-task-locked-restore-fix-2026-08-07.md

Починить PR #15: аналайзеры против dotnet format и RID-чувствительность lock-файлов

Ветка

• Репозиторий: https://github.com/ochenstarik-ui/server-monitor-manager
• Ветка: antigravity/reproducible-builds, PR #15, HEAD 5ca4832
• Рабочая папка: C:\Users\Ochenstarik\projects\smm-antigravity

Новую ветку не создавать — доделывается существующая.

Состояние

PR #15 открыт с красным CI: build падает дважды, build-and-test падает дважды. В описании PR при этом стоит «Verified locally» и «covered by windows-build CI» — ровно тот job, который и падает.

Дефекты вызваны самим PR, оба воспроизводимы, оба имеют неочевидную причину. Разбор ниже.

---

Дефект 1 — включение аналайзеров ломает проверку форматирования

build-and-test, шаг Verify formatting, exit code 2:

warning CA1848: For improved performance, use the LoggerMessage delegates …
    LinkReconciliationBackgroundService.cs(31,17), (78,21), (91,17)
    ControlMaintenance.cs(34,21), (46,17), (74,21), (92,17), (140,13), (212,9)
warning CA1865: Use 'string.StartsWith(char)' instead of 'string.StartsWith(string)'
    TimezoneProvisioningExecutor.cs(76,42)
##[error]Process completed with exit code 2

Причина: Directory.Build.props включил EnableNETAnalyzers и AnalysisLevel=latest-recommended. dotnet format --verify-no-changes проверяет не только форматирование, но и диагностики аналайзеров, и завершается ненулевым кодом при любом их наличии.

TreatWarningsAsErrors был намеренно исключён из задания, чтобы не ломать сборку — но этого оказалось недостаточно: гейт форматирования падает и от обычных warning'ов.

Что решить

Аналайзеры и форматирование — разные проверки, и смешаны они в одном шаге. Выбрать один подход и обосновать выбор в отчёте:

Предпочтительно. Разделить проверки: dotnet format whitespace --verify-no-changes и dotnet format style --verify-no-changes в CI, а диагностики аналайзеров оставить в сборке как warning'и. Тогда гейт проверяет то, ради чего заведён, а аналайзеры дают сигнал, не блокируя.

Допустимо. Оставить dotnet format как есть, но явно подавить конкретные правила в .editorconfig с указанием причины для каждого. Тогда список подавленных правил приводится в отчёте с обоснованием по каждому — CA1848 про LoggerMessage-делегаты в некритичном по производительности пути это одно, а произвольное глушение всего семейства CA — другое.

Недопустимо. Отключить EnableNETAnalyzers или понизить AnalysisLevel, чтобы CI позеленел: это отменяет смысл изменения.

---

Дефект 2 — lock-файлы не учитывают runtime identifier

build (Windows), шаг Restore:

error NU1004: The project's runtime identifiers have changed from.
Project's runtime identifiers: win-x64, lock file's runtime identifiers .
The packages lock file is inconsistent with the project dependencies
so restore can't be run in locked mode.
    ServerMonitorManager.Core.csproj [via ServerMonitorManager.Desktop.csproj]

Причина: packages.lock.json фиксирует не только версии, но и набор runtime identifier'ов. Файлы сгенерированы обычным dotnet restore без -r, поэтому список RID в них пуст. windows-build.yml восстанавливает с -r win-x64, и --locked-mode справедливо отвергает несоответствие.

Локальная проверка это не поймала: без -r восстановление проходит, что и отражено в описании PR как «5 projects restored».

Что решить

Проект публикуется под три RID: win-x64, linux-x64, linux-arm64. Варианты:

Предпочтительно. Объявить <RuntimeIdentifiers> в проектах, которые публикуются под конкретный RID — Control, Agent, Provisioning.Helper, Desktop и транзитивно Core, — и перегенерировать lock-файлы так, чтобы они содержали все три RID. После этого --locked-mode работает во всех сценариях восстановления.

Допустимо. Отдельные lock-файлы под RID, если предыдущий вариант даёт неприемлемый рост файлов.

Недопустимо. --force-evaluate, снятие --locked-mode там, где он падает, или удаление RestorePackagesWithLockFile: это возвращает исходную невоспроизводимость, ради устранения которой задача и заведена.

---

Дефект 3 — гарантия не покрывает то, что реально выпускается

--locked-mode добавлен только в linux-control-agent.yml и windows-build.yml — то есть ровно в те два workflow, которые видны на pull request. Артефакты, которые уходят пользователям, собираются в linux-release.yml, windows-release.yml и linux-platform-matrix.yml, и там восстановление по-прежнему свободное.

Это тот же структурный промах, что и в PR #14 с permissions: проверенным оказалось то, что видно на PR, а непроверенным — путь выпуска.

Добавить --locked-mode во все шаги восстановления и публикации во всех пяти workflow. Именно там воспроизводимость и имеет смысл: подпись артефакта без неё ничего не гарантирует.

Заметьте, что linux-platform-matrix.yml и release-workflow публикуют с --runtime linux-x64 и linux-arm64 — то есть дефект 2 обязан быть закрыт до этого шага, иначе упадут и они.

---

Критерий приёмки

• build и build-and-test зелёные на PR #15;
• --locked-mode присутствует во всех шагах восстановления и публикации всех пяти workflow;
• продемонстрирована работа гарантии: намеренная правка одного lock-файла во временном коммите даёт красный прогон на RID-специфичном восстановлении, затем коммит откатывается — со ссылкой на красный прогон;
• версии пакетов не изменились относительно main — показать сравнение;
• выбранный подход по дефекту 1 обоснован; если правила подавлены, каждое перечислено с причиной;
• git diff --name-only main не содержит файлов из списка границ прошлого задания: LinkService.cs, LinkPolicyApplier.cs, LinkReconciliationBackgroundService.cs, ControlStore.cs, ControlMaintenance.cs, ControlOptions.cs, appsettings.json, src/ServerMonitorManager.Provisioning.Helper/**, deploy/**, CertificateAuthority.cs, CertificateLifecycleService.cs, AgentClient.cs, содержимое файлов в tests/** кроме .csproj;
• TreatWarningsAsErrors по-прежнему не включён;
• PR не смержен.

Отдельное требование к отчёту

Причина обоих дефектов — вывод сделан до того, как CI отработал. Формулировки «Verified locally» и «covered by windows-build CI» стояли в описании PR в тот момент, когда этот самый job был красным.

Поэтому: описание PR обновляется после завершения CI, а не до. В разделе «Verified in CI» приводятся ссылки на конкретные завершённые прогоны с их статусом. Если прогон красный — это указывается прямо, и PR помечается как черновик.

Отсутствие проверки — не дефект отчёта. Утверждение о проверке, противоречащее видимому статусу CI, — дефект, и он дороже самой ошибки в коде, потому что обесценивает все последующие отчёты.

Порядок

Дефект 2 → дефект 3 → дефект 1. Первые два связаны: расширение --locked-mode на release-workflow невозможно, пока lock-файлы не знают о RID.