ochenstarik/server-monitor-manager
1
0
Fork 0
Code Issues Pull requests 6 Projects Releases 17 Packages Wiki Activity Actions 2
server-monitor-manager/agents/hermes/inbox/from-smm-deliverables/Старые задачи/smm-hermes-task-alpha11-and-branch-protection-2026-08-11.md
Ochenstarik 23eb3f5233 chore(agents): разбор рабочих папок с диска на 2026-08-18 
Задания, отчёты и патчи, лежавшие в 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>
2026-08-18 14:19:54 +07:00

6.2 KiB
Raw Blame History

Hermes: выпустить alpha.11, починить bootstrap-job релиза, включить защиту ветки

Состояние

  • main @ 5349533 «Bump version to v0.1.0-alpha.11»;
  • открытых PR нет;
  • последний опубликованный релиз — v0.1.0-alpha.9;
  • тег v0.1.0-alpha.10 создан на e8f771b, но релиз не опубликован: Release pipeline упал в job bootstrap;
  • Antigravity параллельно доделывает свою часть.

Ветка: hermes/release-alpha11.

Часть 1 — починить job bootstrap в Release pipeline · блокирующее

Прогон по тегу v0.1.0-alpha.10 (31420461877):

bootstrap:                    failure
publish-linux (linux-x64):    success
publish-linux (linux-arm64):  success
package-windows:              success
manifest:                     skipped

В логе видно PASS: Missing signature rejected, затем Process completed with exit code 1. То есть негативные проверки подписи отработали частично, после чего шаг упал без внятного сообщения.

Следствие: manifest пропущен, релиз не создан, тег остался пустым.

Сделать:

  1. Найти и исправить причину падения. Молчаливый exit 1 без диагностики — сам по себе дефект: каждая проверка обязана печатать, что именно не сошлось.
  2. Прогнать Release pipeline через workflow_dispatch на своей ветке до тегирования, чтобы убедиться, что job bootstrap проходит.

Часть 2 — выпустить v0.1.0-alpha.11

Тег v0.1.0-alpha.10 использовать повторно нельзя: docs/release-policy.md запрещает переиспользование и пересоздание опубликованных тегов, а тег создан и виден. Версия в исходниках уже поднята до alpha.11 — это правильный выход.

  1. После части 1 создать v0.1.0-alpha.11 и запушить тегом.
  2. Убедиться, что в релизе присутствует полный набор: bootstrap и .sha256, оба tar.gz и .sha256, три SBOM, MSIX, smm-setup.sh и .sha256, server-monitor-manager-manifest.json и .sig.
  3. В docs/release-policy.md добавить строку о судьбе v0.1.0-alpha.10: тег существует, релиз по нему не публиковался, номер не переиспользуется. Пустой тег без объяснения — источник будущей путаницы.

Часть 3 — включить защиту ветки main · системная причина

main не защищён: GET /branches/main/protection возвращает 404.

С 10 августа шесть коммитов легли в main напрямую, минуя PR:

5349533  Bump version to v0.1.0-alpha.11
48d096a  fix(ci): update release contract, remove backward compat test
e04037a  docs: add Debian VM reboot constraint section
bb672a2  docs: sync translations and roadmap
e8f771b  Merge branch 'hermes/release-alpha10'
7b322a6  Add release-verification workflow to main

До этого всё шло через PR — #32, #33, #35, #36. Результат отхода от правила: два коммита оставили main красным на сутки (падал tests/bootstrap/test-release-contract.sh), и это заметил не CI-гейт, а внешняя проверка.

Включить на main:

  • обязательный pull request перед слиянием;
  • обязательные проверки статуса: build-and-test (Linux) и build (Windows) как минимум;
  • запрет force-push и удаления ветки;
  • обязательная актуальность ветки относительно main перед слиянием.

Правило «один PR — одна тема, слияние после зелёного CI» существует с самого начала, но держалось на дисциплине. Оно должно держаться на настройке.

Записать это в docs/release-policy.md рядом с правилом неизменяемости тега.

Часть 4 — проверка предыдущих частей задания

Из прошлого задания подтвердить в отчёте:

  • roadmap: подпись manifest отмечена выполненной, физический acceptance остаётся открытым — проверено, сделано;
  • Debian VM reboot: ограничение записано в документации — проверено, сделано;
  • слитые ветки удалены — проверено, осталось 7 из 15, все неслитые;
  • переводы README: в чём именно выражена синхронизация, какие файлы изменены.

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

  • job bootstrap в Release pipeline проходит; каждая проверка при отказе печатает причину;
  • v0.1.0-alpha.11 опубликован с полным набором ассетов;
  • судьба v0.1.0-alpha.10 зафиксирована в docs/release-policy.md;
  • main защищён: PR обязателен, статусы обязательны, force-push запрещён;
  • правило записано в документации;
  • main зелёный;
  • всё, кроме настройки защиты ветки, проходит через PR.

Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему. Для части 3 приложить вывод gh api repos/.../branches/main/protection после включения.