server-monitor-manager/agents/antigravity/inbox/from-smm-deliverables/Старые задачи/smm-antigravity-task-signed-delivery-queue-b-final-2026-08-10.md

Antigravity: завершить подписанную поставку, Queue B

Исходное состояние

• Репозиторий: ochenstarik-ui/server-monitor-manager.
• Ветка: antigravity/signed-delivery-queue-b.
• Актуальная база на момент задания: main / v0.1.0-alpha.9 @ 2ca059f.
• Коммит ef137bc уже добавляет bootstrap-проверку manifest и совместимости компонентов.
• Незакоммичены MainPage.xaml, MainPage.xaml.cs и tests/bootstrap/test-manifest-verification.sh.
• PR и CI для Queue B отсутствуют.
• PR #34 с repo hygiene открыт отдельно. Не включать его изменения вручную. Перед публикацией ветки снова получить актуальный main и перебазироваться, если #34 или другой PR был смержен.

Цель

Довести проверку подписанных обновлений Desktop и bootstrap до fail-closed реализации, покрытой изолированными тестами, и открыть готовый к независимой приёмке PR. Релиз и тег не создавать — это отдельный gate Hermes.

Обязательная работа

1. Сохранить и довести bootstrap

• verify_archive получает ожидаемый SHA-256 из проверенного manifest, а не из соседнего .sha256.
• verify-manifest MANIFEST SIGNATURE проверяет подпись production keyless identity.
• Issuer и identity-regexp зафиксированы в коде; рядом с identity должна быть ссылка на docs/release-policy.md.
• Отсутствующий cosign, manifest или signature, чужая identity, неверная подпись и неверный hash завершаются отказом.
• SMM_ALLOW_UNSIGNED=1 остаётся только явным аварийным developer bypass с громким предупреждением; default — fail closed.
• update-control и update-agent блокируют несовместимую пару Control ↔ Agent ↔ helper по manifest v2.
• Проверить CLI-контракт: тесты должны передавать ровно те аргументы, которые принимает команда. Текущий bootstrap-тест ошибочно передаёт verify-manifest три аргумента при контракте из двух.

2. Переделать Desktop updater для тестируемости

• Не использовать закрыто созданный внутри класса HttpClient и реальный GitHub в unit tests. Внедрить HTTP transport, signature verifier, файловое хранилище и launcher либо эквивалентные тестовые границы.
• Поддержать alpha/pre-release update channel явно. releases/latest нельзя считать источником текущего alpha-релиза без отдельного контракта и теста.
• Manifest, signature и MSIX должны принадлежать одному release/tag; нельзя смешивать URL или ассеты разных тегов.
• Проверить manifest keyless-подпись pinned issuer/identity до показа кнопки обновления.
• После загрузки MSIX сверить его SHA-256 с уже проверенным manifest и только затем разрешить запуск.
• Отсутствующая, чужая или неверная подпись и несовпадающий hash — безусловный отказ. В production нет кнопки «продолжить всё равно».
• Отказ записывается в штатную диагностику приложения; одного Debug.WriteLine недостаточно.
• Developer bypass, если он сохраняется для Desktop, должен быть явным, выключенным по умолчанию и покрытым тестом; он не должен попадать в обычный пользовательский путь.
• Не скачивать доверенный ключ/identity из проверяемого релиза.
• Не запускать установщик автоматически. Пользователь видит действие только после успешной проверки metadata.

3. Исправить тесты

Обязательны полностью offline и детерминированные проверки:

1. корректная production-equivalent подпись и hash принимаются;
2. manifest, подписанный другой identity, отклоняется;
3. подписанный manifest с hash, не совпадающим с MSIX/архивом, отклоняется;
4. отсутствующая signature отклоняется;
5. повреждённая signature отклоняется;
6. отсутствующий verifier отклоняется;
7. несовместимые версии Control/Agent/helper блокируют оба update-*;
8. Desktop не показывает update action до завершения всех проверок;
9. prerelease-channel корректно находит alpha.9/alpha.10, а не полагается на stable-only endpoint;
10. URL/asset из другого тега отклоняется.

UpdateServiceTests.cs должен реально компилировать production-код. Сейчас тестовый .csproj не подключает UpdateService.cs, а существующие четыре теста проверяют только создание объекта, cancellation, NullReferenceException и свойства record — это не критерии Queue B.

Bootstrap-тест не должен объявлять успех, если production implementation игнорирует его тестовый ключ. Тестовый seam допустим только если он недоступен в обычном production path и не ослабляет pinned identity.

4. Проверить фактический alpha.9

• Скачать manifest и signature именно из неизменяемого v0.1.0-alpha.9.
• Подтвердить, что выбранная команда cosign verify-blob действительно проверяет опубликованный формат .sig и pinned identity.
• Проверить hash хотя бы одного Linux archive и MSIX против manifest.
• Если опубликованной .sig недостаточно для offline/keyless verification и требуется certificate/bundle, не ослаблять проверку и не менять workflow самостоятельно. Зафиксировать точный producer-side gap в отчёте для Hermes.

5. Git и CI

• Не включать ci_log*.txt, ключи, временные manifest/signature, скачанные binaries и тестовые архивы.
• Не менять .github/workflows/**. Если producer-side изменение действительно необходимо, описать его для Hermes.
• Сначала синхронизировать ветку с текущим main, затем оформить логические коммиты.
• Прогнать actionlint на существующих workflow, shellcheck/bash syntax для изменённых shell-файлов, Desktop tests, Control tests и релевантные acceptance/bootstrap tests.
• Открыть PR, дождаться Linux и Windows CI. Не merge.
• Не запускать публикацию на существующем теге и не создавать alpha.10.

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

• Реальные четыре security-сценария Desktop и расширенный negative suite зелёные.
• Bootstrap и Desktop используют один зафиксированный trust policy и отказывают при любой неоднозначности.
• Проверка опубликованных ассетов alpha.9 воспроизводима и приложена к отчёту.
• Версионная несовместимость блокируется до изменения установленной системы.
• Рабочее дерево чистое, ветка основана на текущем main, лишних файлов нет.
• PR открыт, все обязательные CI зелёные, workflow не изменены, PR не смержен.

Отчёт

Раздельно перечислить:

• коммиты и изменённые файлы;
• локальные команды и результаты;
• GitHub CI со ссылками;
• проверку фактических alpha.9 assets;
• negative tests;
• не запускавшиеся проверки и причину;
• producer-side требования для Hermes, если обнаружены;
• ссылку на PR.