Задания, отчёты и патчи, лежавшие в C:\Users\Ochenstarik\projects и в домашней папке, перенесены в agents/. Разложено по агентам там, где имя файла позволяло определить автора; остальное — в _salvage-2026-08-18/ и разбирается вручную. Патчи в notes/salvage-2026-08-18/ — незакоммиченная работа из брошенных рабочих копий: она существовала только на диске. Тяжёлое (релизные архивы, инсталляторы, наборы данных) в репозиторий не попало: оно лежит рядом, в Agent_projects/_archive и Agent_projects/_data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9.3 KiB
Antigravity: довести сертификаты до PR и разобрать dependabot
Состояние
main@80b4797— содержитfix(enrollment): repair node enrollment path (#24)от Hermes;- ветка
antigravity/cert-lifecycle@9d2fe1c— CI зелёный, сmainсливается без конфликтов, PR не открыт; - открыто шесть PR от dependabot: #18–#23.
Часть 1 — доделать antigravity/cert-lifecycle
Работа принята по существу: ClientCertificateDays в ControlOptions с умолчанием 30 и сохранённым [DynamicDependency], AddYears(1) заменён на AddDays(...), автопродление Agent при остатке меньше трети с сохранением работы при недоступном Hub, событие certificate.expiring, docs/certificate-rotation.md, все семь обязательных тестов, 101 тест зелёный. Границы соблюдены — ни одного файла из области Hermes.
Осталось пять пунктов.
1.1. Ребейз на текущий main
Ветка сделана до merge #24. Конфликтов нет, но база должна быть актуальной: #24 менял привязку конфигурации Agent, а ваша работа трогает AgentClient.cs.
1.2. Убрать TEST_EVIDENCE.md из репозитория
Файл закоммичен в корень. Отчёт — артефакт PR, а не содержимое репозитория. Перенести содержимое в описание PR, файл удалить из ветки.
1.3. Проверка на trimmed-артефакте по production-пути
Сделано было так:
dotnet publish ... -r win-x64 --self-contained -p:PublishTrimmed=true
.\ochenstarik-smm-control.exe --Control:ClientCertificateDays 999
Это командная строка на win-x64. В проде конфигурация приходит переменными окружения из control.env через EnvironmentFile= в systemd-юните, на linux-x64. Сломанным под триммингом был именно env-путь — в AgentOptions не оказалось [DynamicDependency], и Agent молча брал умолчания.
Повторить проверку так, как оно работает в бою:
dotnet publish src/ServerMonitorManager.Control/ServerMonitorManager.Control.csproj \
-c Release -r linux-x64 --self-contained -p:PublishTrimmed=true -p:PublishSingleFile=true -o /tmp/ctl
Control__ClientCertificateDays=999 /tmp/ctl/ochenstarik-smm-control
Ожидается отказ старта с ошибкой валидации. Если сервис стартует — значение не дошло, и настройка в проде работать не будет.
Дополнительно проверить обратное: валидное значение из переменной окружения действительно применяется к выпускаемому сертификату, а не подменяется умолчанием 30. Например Control__ClientCertificateDays=45, выпустить сертификат, посмотреть notAfter.
Вывод обеих проверок приложить к PR.
1.4. Убрать дублирующий эндпоинт продления
В Control/Program.cs появились два пути продления:
agents.MapPost("/certificate/renew")— в группе сRequireAuthorization("Agent"), всё правильно;app.MapPost("/api/v1/certificates/renew")— безRequireAuthorization, отсекает чужих случайной проверкой на пустойentityIdи разветвляется по claim роли внутри.
Второй ведёт себя fail-closed, но держится не на конвейере авторизации, а на том, что у неаутентифицированного запроса не окажется claims. Это не соглашение проекта: рядом в том же файле все защищённые эндпоинты объявлены через группы с политикой.
Выбрать одно:
- предпочтительно — удалить
app.MapPost("/api/v1/certificates/renew"), оставив продление Agent в группеagents, а продление Operator добавить в группуcontrolсRequireAuthorization("Operator"); - либо оставить один общий эндпоинт, но объявить его через группу с политикой, требующей аутентифицированную identity, и разветвление по роли выполнять уже внутри.
Добавить тест: запрос на продление без клиентского сертификата отклоняется, и отклоняется конвейером, а не обработчиком.
1.5. Открыть PR
После пунктов 1.1–1.4. Описание PR заполнять после завершения CI, со ссылками на конкретные прогоны.
Часть 2 — dependabot, отдельным PR каждый
Шесть открытых PR. Сливать пачкой нельзя: три из них меняют то, от чего зависит воспроизводимость и цепочка поставки.
2.1. Безопасные — слить после зелёного CI
- #22
Microsoft.NET.Test.Sdk18.0.1 → 18.8.1; - #19
actions/setup-dotnet5.4.0 → 6.0.0; - #18
softprops/action-gh-release2.6.2 → 3.0.2.
Для двух последних убедиться, что dependabot заменил SHA, а не вернул плавающий тег: инвариант «ни одного плавающего тега в uses:» из PR #14 должен сохраниться. Проверять на каждом PR:
grep -rn 'uses:.*@v[0-9]' .github/workflows/ && echo "НАЙДЕН ПЛАВАЮЩИЙ ТЕГ" || echo "все запинены"
action-gh-release 3.0.x — мажорный скачок, посмотреть changelog на предмет изменения имён входных параметров: он используется в release-workflow, а те не запускаются на pull request, поэтому CI поломку не покажет. Это ровно тот класс дефектов, что вы уже ловили в PR #14 с permissions. Проверять actionlint, а не полагаться на зелёный PR.
2.2. Требуют внимания
- #21
actions/checkout6.1.0 → 7.0.1 и #20actions/upload-artifact6.0.0 → 7.0.1 — мажорные.upload-artifactv7 может менять поведение при отсутствии файлов и формат имён артефактов; вlinux-release.ymlиwindows-release.ymlот имён артефактов зависит сборка релиза. Проверить, что после обновления релизные ассеты собираются с теми же именами: их знает установщикsmm-setup.shи bootstrap.
2.3. Не сливать без отдельной проверки
- #23
SQLitePCLRaw.bundle_e_sqlite32.1.12 → 3.0.5.
Это мажорное обновление нативной библиотеки под SQLite, на которой держится вся база Control: enrollment, identities, links, provisioning, audit. Требуется:
- прогон полного Control suite на Linux, не только на Windows;
- проверка миграций на существующей базе: взять
control.db, созданную текущей версией, открыть новой сборкой, убедиться, чтоPRAGMA user_versionи данные читаются; - проверка
backup-createиbackup-restoreна этой же базе; - проверка, что self-contained trimmed-публикация под
linux-arm64не ломается — нативные библиотеки в trimmed single-file собираются иначе, чем под x64.
Если хоть одна проверка не выполнена, PR не сливать и написать это прямо. Обновление некритично и подождёт.
Порядок
Часть 1 → 2.1 → 2.2 → 2.3. Сертификаты первыми: это пункт Горизонта 0, а обновления зависимостей подождут.
Отчёт
Раздельно: что проверено локально, что в CI со ссылками, что не проверялось и почему. По части 2 — по каждому PR отдельной строкой с вердиктом «слит / отложен / отклонён» и причиной.