[2026-10-23] eagle: personal/projects/virfield.md

This commit is contained in:
Alexey Martemyanov committed 2026-10-23 12:12:01 +06:00
1 parent 552f679b04
commit 0853829669
1 file changed
+9 -1
+9 -1
View File
@@ -2,7 +2,7 @@
Проверено: **2026-10-16** (практика UI-тестов — 2026-10-17, см. раздел ниже). Последний опубликованный stable Latest и установленная версия — [v2.1.1](https://github.com/mallexxx/virfield/releases/tag/v2.1.1), source `2c64888abed617722e79d618dd4911efa0c4b126`. Релиз опубликован после явного подтверждения владельца. Архив macOS ARM64 и SHA256SUMS скачаны с публичных URLs без авторизации; содержимое побайтно совпадает с проверенным установленным пакетом. Предыдущая публикация: [[personal/projects/virfield-release-v2.1.0]].
Текущий local/GitHub `main`: **`2c64888abed617722e79d618dd4911efa0c4b126`**, checkout чистый, локально и на origin только `main`. Изменение исправляет обработку ошибки `launchctl bootstrap` уже зарегистрированного собственного guest Keychain agent: recovery разрешён только после проверки точного launchd job, затем остаются все прежние native readiness gates. Добавлены закрытый bootstrap diagnostic и regression с настоящим shell-блоком; контрфактический тест на старом коде воспроизвёл отказ. Make check/race, Staticcheck, module verify, Govulncheck и make check из распакованного точного кандидата прошли.
На 2026-10-16 local/GitHub `main` был **`2c64888abed617722e79d618dd4911efa0c4b126`**; актуальный локальный `main` и состояние production указаны в разделе «Текущая работа 2026-10-23» ниже. Изменение исправляет обработку ошибки `launchctl bootstrap` уже зарегистрированного собственного guest Keychain agent: recovery разрешён только после проверки точного launchd job, затем остаются все прежние native readiness gates. Добавлены закрытый bootstrap diagnostic и regression с настоящим shell-блоком; контрфактический тест на старом коде воспроизвёл отказ. Make check/race, Staticcheck, module verify, Govulncheck и make check из распакованного точного кандидата прошли.
## Установленная версия и проверка обновления
@@ -65,6 +65,14 @@ macOS make check/build/Staticcheck прошли; настоящий read-only vo
- Повторы `vm_acquire` — с новым idempotency key, если меняется ключ SSH/шаблон; тот же ключ и body только для настоящего retry.
- Клиентская сторона (не virfield): auto-mode classifier заблокировал `vm_acquire` для шаблона, который пользователь не называл; разрешение нужно давать явно.
## Текущая работа 2026-10-23: UI readiness
Локальный `main` содержит коммиты `fd980dd`, `c7d75e7`, `1126997`, `6203177`; рабочее дерево чистое. Полный `go test ./...` прошёл. Для Xcode-образов и новых disposable workers добавлены настройка unattended Automation Mode и настоящий 1/1 XCUITest gate; компактный MCP status и путь pinned SSH без CLI документированы. На действующем Monterey lease native UI fixture прошёл 1/1, а `automationmodetool` сообщил `DOES NOT REQUIRE user authentication`. Это проверка текущей VM, не доказательство работы ещё не установленного нового daemon.
Cold boot двух node VM на htpc выявил дополнительные ошибки старой установленной версии. Sonoma `lease-1e935304d66b68d41c7850a89f79d0ae`: SSH появился примерно через 17 минут, Finder стабилизировался позже двухминутного desktop timeout; job `needs_attention/lease_ssh_failed`. Sequoia `lease-1140ca109abe50cf3c095ae5c24a496b`: раннее чтение модели ошибочно дало `guest_identity_failed`; последующий pinned SSH подтвердил `iMacPro1,1`, macOS 15.8.1/24H32. Исправления увеличивают бюджет только node-lease до 45 минут, ожидание его desktop до пяти минут и повторяют временно неудавшееся read-only чтение модели. На обеих VM прочитанная политика требует аутентификации для Automation Mode. Оба временных lease оставлены для journal-safe release после подтверждения владельца; повторный прогон нового кода ещё не выполнен.
Production пока v2.1.1: локальные Tart leases заняты, один до 2026-10-24. Установленный daemon подписан Team ID `E3R68ED529`, а соответствующего signing identity сейчас нет в keychain. Новая ad-hoc сборка потеряет прежний Full Disk Access. Для production upgrade требуется решение о прежней подписи или новой подписи с повторной выдачей Full Disk Access, затем контролируемый restart и fresh lease acceptance на Monterey, Sonoma, Sequoia. Screen Recording/Downloads TCC для конкретных приложений остаётся за системным согласием пользователя.
## Ограничения и дальнейший план
Следующие задачи не входят в принятую установленную VM/MCP/Broker-приёмку и не объявляются реализованными: