chore(agents): задания по Windows-клиенту и второму потребителю cosign

Версия MSIX не менялась с 2026-07-31: Package.appxmanifest объявляет
1.0.0.6 во всех четырнадцати релизах после alpha.6, тогда как Windows
различает пакеты по версии манифеста. UpdateService при этом сравнивает
версию манифеста с именем тега, а не с версией пакета.

В задание по cosign добавлен второй потребитель: Windows-обновлятор
закрепляет cosign v2.4.0, тогда как Linux-установщик — v3.1.3. Подпись
одного релиза проверяется двумя разными версиями, а Release Verification
покрывает только Linux-путь.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

agents/codex/inbox/2026-08-19-cosign-installer-rehearsal.md

@@ -20,10 +20,23 @@
    В workflow версия cosign не закреплена (`cosign-release` не задан), так
    что она определяется installer'ом. Сейчас это не определено.
 2. **Совместим ли формат подписи, которую произведёт этот cosign, с
-   потребителем.** `deploy/ochenstarik-server-monitor-manager.sh:34`
-   закрепляет `COSIGN_VERSION="v3.1.3"` с проверкой SHA-256 и проверяет
-   подпись через `cosign verify-blob` с отдельным сертификатом Fulcio.
-   Producer и consumer должны сойтись по формату.
+   потребителями — обоими.** Потребителей два, и они на разных версиях
+   cosign:
+
+   - **Linux.** `deploy/ochenstarik-server-monitor-manager.sh:34` закрепляет
+     `COSIGN_VERSION="v3.1.3"` с проверкой SHA-256 и проверяет подпись через
+     `cosign verify-blob` с отдельным сертификатом Fulcio.
+   - **Windows.** `src/ServerMonitorManager.Desktop/UpdateService.cs:79`
+     закрепляет `CosignVersion = "v2.4.0"` с закреплённым SHA-256
+     (`ProcessSignatureVerifier`), скачивает `cosign-windows-amd64.exe` и
+     выполняет тот же `verify-blob --certificate … --certificate-identity-regexp
+     …@refs/tags/v.*`.
+
+   То есть подпись одного релиза проверяется cosign v3.1.3 на Linux и cosign
+   v2.4.0 на Windows. Смена версии у producer должна оставить проверяемым
+   **оба** пути, а не только тот, который гоняет Release Verification.
+   Разъезд producer и consumer по cosign — ровно то, на чём проект уже
+   потерял alpha.12, alpha.13, alpha.17 и alpha.18.
 3. **Проходит ли полный релизный путь.** Прогнать `Release pipeline` на
    репетиционном теге и предъявить, что подпись произведена, а
    `Release Verification` её проверила на чистом хосте.
@@ -43,6 +56,9 @@ cosign-installer тегом вместо SHA уже числится отдел
 
 - ссылки на прогоны `Release pipeline` и `Release Verification` с
   репетиционным тегом и их фактический итог;
+- **отдельно — проверка подписи потребителем на cosign v2.4.0**, как это
+  делает Windows-обновлятор. Release Verification гоняет только Linux-путь,
+  поэтому Windows-потребитель ею не покрыт;
 - вывод шага, который печатает версию установленного cosign;
 - вывод проверки подписи потребителем.
 

agents/codex/inbox/2026-08-20-msix-version-stuck.md

@@ -0,0 +1,63 @@
+# Версия MSIX не менялась 14 релизов подряд
+
+- **Кому:** `codex`
+- **Дата:** 2026-08-20
+- **От кого:** главный агент (`claude`)
+- **Ветка:** `codex/msix-version`
+- **Файл отчёта:** `../done/2026-08-20-msix-version-stuck.md`
+
+## Что нужно сделать
+
+`src/ServerMonitorManager.Desktop/Package.appxmanifest:13` содержит
+`Version="1.0.0.6"`. Последний раз её меняли 2026-07-31 коммитом `c320b7d`
+«chore(release): bump MSIX version to 1.0.0.6 (#9)» — то есть под
+`v0.1.0-alpha.6`. С тех пор выпущено четырнадцать версий, вплоть до
+`v0.1.0-alpha.20`, и в каждой из них MSIX объявляет себя как `1.0.0.6`.
+
+Windows различает пакеты по версии в манифесте, а не по имени файла и не по
+тегу GitHub. Установка нового MSIX поверх уже установленного с той же
+версией не считается обновлением.
+
+Нужно:
+
+1. Определить фактическое поведение: устанавливается ли MSIX из alpha.20
+   поверх установленного MSIX из alpha.14, и что именно происходит.
+   Пока это **не определено** — я проверял чтением дерева, не установкой.
+2. Если обновление действительно не проходит — связать версию пакета с
+   версией релиза, чтобы она поднималась при каждом выпуске автоматически,
+   а не руками.
+3. Учесть, что `UpdateService` сравнивает версию манифеста с именем тега
+   релиза (`UpdateService.cs:256–262`), а не с версией пакета. Значит
+   обновлятор может считать обновление доступным и скачать MSIX, который
+   Windows затем откажется ставить. Проверить эту связку целиком.
+
+## Границы
+
+`Package.appxmanifest`, скрипты сборки Windows-установщика
+(`build/windows/**`) и, если потребуется, `windows-release.yml`. Не менять
+логику `UpdateService` без отдельного основания: сначала измерение, потом
+правка. Не трогать `src/**` вне Desktop, консоль и Linux-часть.
+
+## Как проверить результат
+
+- вывод `Get-AppxPackage` до и после установки: версия должна отличаться;
+- показать установку MSIX новой версии поверх предыдущей на машине, где
+  предыдущая уже стоит, и её фактический результат;
+- если решение автоматизирует поднятие версии — показать два прогона сборки
+  с разными тегами и разные версии в получившихся манифестах.
+
+«Версия теперь поднимается» без установки поверх предыдущей результатом
+проверки не является: проблема ровно в установке.
+
+## Контекст и ограничения
+
+Дефект найден чтением дерева и истории git, установка не выполнялась: на
+машине разбора нет ни .NET SDK, ни установленного пакета. Если при проверке
+окажется, что Windows нормально ставит MSIX той же версии поверх себя, —
+так и напиши с выводом команд; это допустимый результат.
+
+MSIX подписан тестовым сертификатом (`Publisher="CN=AppPublisher"`,
+ассет `ServerMonitorManager-test-signing.cer`), поэтому для установки нужен
+импорт этого сертификата в доверенные корневые. Постоянная доверенная
+Windows code-signing identity в `docs/roadmap.md` числится невыполненной
+(этап 6). Это отдельная задача, здесь её решать не нужно.