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.9 KiB

Raw Blame History

Hermes: починить тест совместимости, выпустить alpha.12, закрепить владение релизом

Состояние

main @ 5349533; защита ветки включена — обязательный PR, обязательные статусы build-and-test и build, force-push запрещён. Это сделано, дальше всё идёт через PR;
опубликован по-прежнему только v0.1.0-alpha.9;
теги v0.1.0-alpha.10 и v0.1.0-alpha.11 созданы, но релизы по ним не опубликованы — Release pipeline оба раза упал в job bootstrap.

Ветка: hermes/alpha8-compat-fixture.

Часть 1 — тест совместимости с alpha.8 · блокирует все релизы

Диагноз готов, повторять не нужно

Release pipeline на теге v0.1.0-alpha.11, job bootstrap, шаг Validate bootstrap:

Test 1..4: PASS
Test 5: Real alpha.8 manifest fallback matching (REQUIRES_NETWORK)
FAIL: Alpha.8 real release verification failed

Я скачал ассеты v0.1.0-alpha.8 напрямую. Файла server-monitor-manager-manifest.json в этом релизе нет. Присутствует только server-monitor-manager-manifest.sig размером 96 байт — подпись без подписываемого файла. В alpha.8 лежал server-monitor-manager-bootstrap-manifest.json, то есть формат v1; manifest v2 впервые появился в alpha.9.

Значит тест проверяет обратную совместимость с артефактом, которого в том релизе никогда не существовало. Дефекта в коде нет — недействительна посылка теста.

Что сделать

Убрать сетевую зависимость из релизного пайплайна. Тест, скачивающий чужой релиз по сети, роняет выпуск версии при любом сетевом сбое или изменении набора ассетов в прошлом. Релизный job не должен зависеть от внешнего состояния.
Заменить его синтетической фикстурой формата v1: локально сгенерированный набор в том виде, в каком его выпускали до alpha.9 — server-monitor-manager-bootstrap-manifest.json, .sha256 рядом с архивом, без manifest v2 и без подписи. Проверять на ней, что установка проходит по пути SMM_ALLOW_UNSIGNED=1 и отвергается без него.

Сценарий реальный и его нельзя терять: Hub владельца стоит на alpha.7, и обновляться он будет именно со старого формата на подписанный.
Фикстуру положить рядом с tests/fixtures/control-v0.1.0-alpha.7.db — там уже принят такой подход для схемы БД.

Не удалять проверку целиком. Antigravity в PR #37 уже сделал коммит с её удалением; я потребовал этот коммит из PR убрать. Владение tests/bootstrap/** и релизным пайплайном остаётся за вами.

Заметка, менять ничего не нужно

В релизе alpha.8 лежит осиротевший manifest.sig без manifest.json. По docs/release-policy.md ассеты опубликованного релиза неизменяемы, поэтому трогать нельзя. Стоит одной строкой упомянуть это в release-policy как известную аномалию, чтобы следующий человек не искал причину.

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

alpha.10 и alpha.11 сожжены: теги существуют, релизов по ним нет, переиспользовать по собственной политике нельзя.

После части 1 прогнать Release pipeline через workflow_dispatch на своей ветке — убедиться, что job bootstrap проходит до тегирования. Два сожжённых тега подряд получились именно потому, что этого шага не делали.
Создать v0.1.0-alpha.12, запушить тегом.
Проверить полноту набора: bootstrap и .sha256, оба tar.gz и .sha256, три SBOM, MSIX, smm-setup.sh и .sha256, server-monitor-manager-manifest.json и .sig.
В docs/release-policy.md зафиксировать судьбу alpha.10 и alpha.11: теги существуют, релизы не публиковались, номера не переиспользуются. Пустые теги без объяснения — источник будущей путаницы.

Часть 3 — единоличное владение версией и релизными файлами

Сейчас версию бампят двое. main содержит ваш Bump version to v0.1.0-alpha.11, а в PR #37 Antigravity бампит до alpha.12 и правит deploy/smm-setup.sh, README и все 12 переводов. Два сожжённых тега — прямое следствие.

Закрепить в docs/release-policy.md: версию в исходниках, deploy/**, релизные workflow и переводы README меняет только владелец релиза. Остальным — через запрос в отчёте.

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

job bootstrap проходит; сетевых зависимостей в релизном пайплайне нет;
совместимость со старым форматом покрыта синтетической фикстурой, сценарий SMM_ALLOW_UNSIGNED проверяется в обе стороны;
workflow_dispatch-прогон выполнен до тегирования, ссылка в отчёте;
v0.1.0-alpha.12 опубликован с полным набором ассетов;
судьба alpha.10, alpha.11 и аномалия alpha.8 записаны в release-policy;
владение релизными файлами закреплено документально;
всё через PR.

Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему.

6.9 KiB Raw Blame History Unescape Escape