obsidian-vault/personal/projects/virfield.md

Virfield

Проверено: 2026-10-16 (практика UI-тестов — 2026-10-17, см. раздел ниже). Последний опубликованный stable Latest и установленная версия — v2.1.1, source 2c64888abed617722e79d618dd4911efa0c4b126. Релиз опубликован после явного подтверждения владельца. Архив macOS ARM64 и SHA256SUMS скачаны с публичных URLs без авторизации; содержимое побайтно совпадает с проверенным установленным пакетом. Предыдущая публикация: personal/projects/virfield-release-v2.1.0.

На 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 из распакованного точного кандидата прошли.

Установленная версия и проверка обновления

Установлен опубликованный v2.1.1, source 2c64888. Перед публикацией этот же пакет прошёл проверку как кандидат; повторная установка не требовалась. Tag v2.1.1 указывает на проверенный commit. v2.1.0 сохранён для отката в ~/.virfield-v2/upgrades/20261016-v2.1.1-before. Пакет собран из чистого committed source; установленная копия подписана прежней локальной identity без изменения исходного release archive. Сохранены system LaunchDaemon, Full Disk Access и девять исходных образов.

Stock v2.1.0 дважды не завершил fresh macOS lease preparation: guest_keychain_failed, в закрытой диагностике launchctl bootstrap exit5. Оба leases released. Это не потерянный source fix: встроенный keychain.sh в прежнем принятом binary и v2.1.0 совпадает побайтно; используется тот же golden image-f11d9a1ee2991eada08c4f734c33df6d.

Свежая VM кандидата lease-52e620c674d514dd8c9c49880e8980f6 прошла native GUI/Keychain add-read-compare-delete, unlocked console без dialogs, 1920×1080 и отдельный pinned caller SSH. VM released, cleanup job succeeded. В этом успешном запуске bootstrap recovery branch не сработал; его прохождение подтверждено regression, а не выдано за наблюдённое на VM. Полный Broker → macOS XCTest post-upgrade run run-3b679ccc08ae5aafb94643d60f0410dd завершился успешно: XCTest 1/1, настоящий xcresult, заново скачанные SHA256-проверенные артефакты, Story closed, cleanup=done и lease released. Это scripts-only проверка без provider credentials и сообщений.

Доказательства: state/main-production-sync-20261016/virfield-candidate-upgrade.json, virfield-fix-source-checks.json, virfield-exact-candidate-check.log, macos-fix-validation/verification.json, macos-readiness-diagnostic/finding.json.

GitHub CI точного 2c64888 успешен на macOS и Linux: make check/race/build, Staticcheck, module verify, Govulncheck и Linux gitleaks. Свежий установленный MCP сообщает 2.1.1, 20 tools/4 resources; authenticated status подтверждает девять прежних images и ноль active workers/jobs. Существующие MCP processes других чатов принудительно не переподключались. Receipts: macos-candidate-production-verification.json, virfield-installed-mcp-2.1.1.json, virfield-fix-github-ci.json.

Опубликованный пакет virfield-v2.1.1-darwin-arm64.tar.gz: SHA256 dbafeea705241286622e773c4576baa3a623cbc143398aa7bbdddac63cb782fd. Release ID 415082470, published 2026-10-16T14:59:56Z, stable Latest, draft=false/prerelease=false. Manifest и все binary hashes проверены. Приватные доказательства: state/main-production-sync-20261016/virfield-v2.1.1-publication-verification.json, upstream-heads-after-publication.json, post-publication-runtime-verification.json. Источник, tag, публичный пакет и production согласованы.

Историческая принятая версия

Исходная приёмка VM/MCP/Broker выполнена на 0.0.0-acceptance-runbooks, source 8bfff9f59cab918877d060437a1ad190905a5040, schema10. Следующие результаты относятся к тому датированному контуру; они не заменяют проверку нового релиза.

Пройдены Tart/native GUI и отдельный SSH, реальные перезагрузки, ключевая изоляция, Xcode/Swift, экспорт артефактов, SSH/desktop и подтверждённый release/revocation. HTPC Sonoma/Sequoia прошли полные циклы. Проверены factory/private GHCR roundtrip, sparse golden transfer, revalidation существующей VM, durable diagnostics, admission/wait/resume и однобайтовая граница node image cache. Legacy iOS профиль прошёл свежую factory/worker квалификацию с armv7 compile/link.

Текущий владелец MCP принят: 20 инструментов, четыре точные темы/ресурса, полный рабочий цикл. Полный off-host disk/config/NVRAM DR и signed package rollback/forward приняты; собственные fixture-копии очищены. Огромный speech-dispatcher.log и его резервная копия удалены после исправления конфигурации, финальный soak прошёл.

Production Codex Story run-12f093299e237f03a7bb9b70327efcc5 принят независимой проверкой: фактический reviewer os.open получил EPERM/errno 1 и exit 0; четыре теста, два новых файла, hashes и отсутствие probe подтверждены. Worker штатно released, credential больше никем не удерживается, Prism завершён. Предыдущие неудачные запуски не считаются доказательством этого результата.

Точный receipt с hashes и границами: personal/projects/archive/virfield-release-cleanup-2026-10-16/docs/acceptance/2026-10-16. Исходный подробный журнал: personal/projects/archive/virfield-release-cleanup-2026-10-16/docs/VERIFICATION. Прежняя проектная заметка сохранена целиком: personal/projects/archive/virfield-release-cleanup-2026-10-16/project-note-before-cleanup.

Релизная очистка

Сохранены 31 исходник документации, JSON/patch и прежняя проектная заметка; содержимое каждого проверено обратным чтением. personal/projects/archive/virfield-release-cleanup-2026-10-16/index. В репозитории удалены планы, приёмочные receipts, исторические копии, неиспользуемые Broker patches и старый Lume reference.

README и шесть руководств содержат команды, требования и ограничения без истории прогонов и личных deployment-примеров. Убрана персональная signing identity; fixture-узлы, IP и MAC заменены синтетическими данными. Гостевой admin/home, канонический Go module/repository URL, upstream pins и legal notices сохранены как контракты проекта. MCP сохраняет 20 инструментов и четыре прежние темы; verification теперь отдаёт инструкции проверки окружения из ENVIRONMENT.md.

Применён anti-slop editing: https://github.com/elithrar/dotfiles/blob/main/.agents/skills/anti-slop/SKILL.md. Прочитаны SKILL.md и references/tells.md; убраны повторения, служебные рассказы о ходе работы и канцелярит, команды и технические ограничения сохранены.

Проверки нашли и исправили две ошибки: Darwin-only statfs попадал в Linux build; дерево лицензий THIRD_PARTY_NOTICES с versioned Go source мешало go vet/list после распаковки. Statfs и реальные mount-тесты разделены по платформам, Linux отказывает local Tart; notices перемещены в _THIRD_PARTY_NOTICES, который Go пропускает. Регрессионный тест воспроизводит старую ошибку и проходит с исправлением. Его фиксированный tar-fixture работает и на Python 3.11; production packaging требует Python 3.12+.

macOS make check/build/Staticcheck прошли; настоящий read-only volume probe двух смонтированных хранилищ прошёл с одним diskutil lookup на серию из 20 capacity refresh. Linux amd64 commands и тесты скомпилированы; полный Linux arm64 CI на Go 1.26.9 прошёл в отдельном локальном Colima-контейнере: make check (race), make build, Staticcheck, module verify и Govulncheck. Финальный архив распакован в чистый каталог; make check, checksum/manifest/binary hashes, подпись native browser и настоящий packaged stdio MCP (20 tools, 4 точные темы/ресурса) прошли. Gitleaks: 253 commits, 0 секретов; Govulncheck: 0 достижимых/импортированных уязвимостей, один неиспользуемый module-only advisory. Собственные Linux-контейнер и cache volume удалены.

Архив: /private/tmp/virfield-release-clean-package-final/virfield-v0.0.0-release-cleanup-darwin-arm64.tar.gz, SHA-256 5522529bfd16246e7ba034dd6055c9d6ef89b00b5f290ff3ff9f64be6a32a204. Это локальный проверенный пакет; отдельный GitHub Release/tag не создавался. personal/projects/virfield-release-cleanup-2026-10-16.

Практика: UI-тесты DDG на двух VM (2026-10-17)

Использовали MCP клиент Claude Code, шаблоны macos27 (macOS 27.0, Xcode 27.0, golden uitest-27-v1) и monterey-xcode-13.4.1 (macOS 12.7.6, Xcode 13.4.1, developer-v1). Сборка и подпись на хосте, исполнение по pinned SSH. Подробности про macOS 12 — personal/tech/legacy-xctest-runner.

Вопросы и проблемы:

• CLI virfield на машине клиента нет (~/Library/Application Support/Virfield/bin отсутствует), поэтому keygen/ssh-config из руководства не выполнить. Ключ создан ssh-keygen -t ed25519, pinned config и known_hosts написаны вручную из vm_lease: ssh.host_key, ip, user admin; StrictHostKeyChecking yes. Работает, потому что IP Tart VM (192.168.64.x) доступен с хоста напрямую. Удобно, если бы MCP/доки описывали этот путь без CLI.
• ssh_key_in_use: один публичный ключ на один активный lease. Для второй VM нужен второй ключ.
• resource_exhausted по диску: хранилище samsung-tart ≈214 ГБ, macOS 27 резервирует 140 ГБ, Monterey 120 ГБ, safety reserve 20 ГБ → вместе не помещаются (headroom −87 ГБ). Пришлось сначала освободить macOS 27 (с разрешения владельца) и только потом брать Monterey. Шаблон на другом хранилище (release-check) есть, но выбирать его самостоятельно клиент не стал.
• virfield_status ≈112 тыс. символов — превышает лимит ответа, сохраняется в файл. Разбирать jq: .capacity, .leases, .template_availability. В .templates[] нет полей xcode/macos версии; версии и installed_images смотреть в image_catalog (inventory.configured_images).
• Тайминги: prepare до ready ≈40 с для обеих VM; release → released ≈7 с (job сначала delete_dispatched, итоговое состояние читать из vm_lease, не ждать только virfield_job).
• Запись экрана: на uitest-27-v1 screencapture -v работает по обычному SSH; на macOS 12 (developer-v1) capture error, нет Screen Recording TCC, SIP включён. Если нужна запись на старых VM, нужен golden с заранее выданным разрешением.
• UI automation: macOS 12 VM — Developer Mode уже включён, sudo без пароля, но automationmodetool enable-automationmode-without-authentication нужно выполнить; ui_testing проба помогла бы здесь. Для запуска из SSH нужна консольная GUI-сессия (Terminal .command).
• ready не подтверждает готовность UI Automation — повторно 2026-10-21. Две свежие VM, monterey-xcode-13.4.1 (Tart, macOS 12.7.6/21H1320, ARM64, Xcode 13.4.1/13F100) и htpc-sonoma-14-xcode-16.2 (node VM, macOS 14.8.9/23J631, Intel, Xcode 16.2/16C5032a), получили успешный prepare и lease ready. При этом /usr/bin/automationmodetool на обеих сообщил Automation Mode is disabled и This device requires user authentication to enable Automation Mode. Developer Mode был включён, admin входил в _developer, консольная сессия принадлежала admin. XCTest runner загрузился, но запуск через Terminal и напрямую через pinned SSH завершился Timed out while enabling automation mode, exit 65, 0 выполненных тестов. sudo automationmodetool enable-automationmode-without-authentication затем сообщил успех; повторная проверка уже показывала DOES NOT REQUIRE user authentication, однако проверенный повтор по-прежнему завершился timeout до тестовых методов. Контрольные минимальные UI-тесты, собранные локально штатными SDK Xcode 13.4.1 на Monterey и Xcode 16.2 на Sonoma (без нового bundle и без shim), тоже завершились Timed out while enabling automation mode, exit 65, до тестового метода. Поэтому проблема ещё не закрыта, а совместимость исполнения нового bundle этим прогоном не доказана. Нужны явная проверка Automation Mode при UI-readiness, подготовка соответствующего UI-профиля и короткий настоящий XCUITest с ненулевым числом выполненных тестов; native GUI/Keychain readiness этого не заменяет. Leases: lease-9ec9281c953de634a53572e293862901, lease-6994a85f7abcefd367dd40d45b08e87b.
• Уточнение UI-readiness, 2026-10-22: последующая проверка через pinned SSH без Screen Sharing на новых leases lease-202db9fd4686e87363ac66171657ba21 (Sonoma Intel/Xcode 16.2) и lease-22c0cfb96e3253d3ed1f7d8ebee6ab77 (Monterey ARM/Xcode 13.4.1) выполнила настоящие native XCUITest probes: 1/1 на каждой OS. На Sonoma один и тот же CI test bundle выполнил PrintingTests 7/7 и с упакованным runtime, и со штатным XCTest 16. На Monterey исправленный AddressBarSearchQueryEditingTests прошёл 26/26 с первой попытки; полный сброс состояния подтверждён только перед первым методом (flags 1 + 25×0). Для старого XCTest потребовались завершение своего target app между процессами, подготовка autocomplete fixture через defaults и отключение вложенного синтеза событий из TCC polling timer. Это снимает утверждение, что UI Automation на этих образах вообще невозможно запустить, но не доказывает первопричину прежнего automation-mode timeout и не заменяет readiness probe в Virfield. Отдельный sandbox запуск Monterey завис в системных Keychain вызовах до создания окна; продолжается диагностика. ARM Sonoma crash из CI не воспроизведён на Intel. Доказательства сохранены в /tmp/prebuilt-ui-fix-results/ (включая monterey-final-evidence.tar.gz, sonoma-native-runtime-evidence.tar.gz).
• Дополнительная UI-квалификация 2026-10-22: Sonoma Intel/Xcode16.2 выполнила также AppStoreSandboxUITests2/2 с изолированным временным keychain; исходные default/search lists восстановлены в GUI и SSH audit sessions. Один лишь SSH unlock не гарантирует доступа GUI app: запуск App Store блокировался в Keychain до native GUI unlock/selection. Native SDK13 контроль Monterey нашёл Customize на новой вкладке (XCUITest assertion1/1); sandbox-класс прошёл NTP после замены element timeout5s на navigation timeout, но затем General Settings перестала отвечать. Sample: NSPathControlView.updateNSView → NSPathCell.setURL → FileProvider/CloudDocsFileProvider → fp_isInSyncableRootFast → open; это не доказанный бесконечный SwiftUI layout loop и не failure загрузки XCTest bundle. В VM виден запрос доступа Review к Downloads. Проверка разрешения folder privacy ожидает человеческого согласия: автоматический approval review отклонил выдачу доступа. Cancel/Deny и перезапуск устаревших UI helpers не закрыли квалификационный gap. Monterey смешанный прогон1 выполненный метод+1 OS skip завершился успешно; all-skipped по-прежнему ошибка. Новый Sequoia lease lease-e22b152c5d0d4c9bc8540b3bdf9a90e7 готов, macOS15.8.1/Xcode26.3, но Automation Mode disabled/requires user authentication; native UI пока не запускался, изменение unattended-политики также ждёт явного разрешения после auto-review отказа. Loader-only631UI+5Perf+5Sync успешен. На GitHub ARM14 и15 точечные классы прошли в обоих режимах на1066967a82; финальные полные UI/Sync/Performance на7cbda2bc49 ещё выполняются. Дополнительные receipts: /tmp/prebuilt-ui-fix-results/sonoma-appstore-evidence.tar.gz, monterey-additional-evidence.tar.gz.
• Remote shell zsh: нет timeout, $var не разбивается на слова — при автоматизации писать скрипты файлами.
• Запуск из xcodebuild test-without-building -xctestrun по скопированным Products (macOS 27) работает; Scheme-pre-actions (clean-app.sh, tests-server) при этом не выполняются.
• Повторы vm_acquire — с новым idempotency key, если меняется ключ SSH/шаблон; тот же ключ и body только для настоящего retry.
• Клиентская сторона (не virfield): auto-mode classifier заблокировал vm_acquire для шаблона, который пользователь не называл; разрешение нужно давать явно.

Диагностика DDG Review Keychain, 2026-10-23

Классификация: проблема дополнительного test fixture; дефект подписи приложения или Virfield не подтверждён. Подпись Review Developer ID Application: Duck Duck Go, Inc. (HKE973VLUW) прошла codesign --verify --deep --strict в VM. Речь о runtime-ключе шифрования данных браузера, а не о приватном ключе сертификата сборки. Подпись идентифицирует приложение для проверки доступа, но не разблокирует keychain; см. Apple: Access Control Lists.

В lease lease-f7b5ad7345b33883e6ef9062062125f7 клиент тестов сам создал дополнительный workspace/fire-regression/keychain-fixture/review.keychain-db, записал синтетический AES fixture и затем изменил default/search list VM на этот keychain. Это не keychain, подготовленный Virfield. Через System Events прочитан точный запрос: “DuckDuckGo Review wants to use the ‘review’ keychain. Please enter the keychain password.” Успешные CLI unlock и отдельный GUI helper (status 0) не доказали доступ target app. Точная причина повторного запроса разблокировки этого fixture не установлена; необходимость менять ACL login из этого запроса не следует. ACL существующего ключа в login не изменялся.

Контроль на свежем lease lease-190e6d0deae478e311732c28e898f902, тот же golden image-f11d9a1ee2991eada08c4f734c33df6d, тот же подписанный app (Signed Time 11:17:24 UTC), без дополнительного keychain и без изменения ACL: до запуска отсутствовали обе версии browser encryption item; приложение само создало v2 item в штатном login (metadata cdat 11:52:35 UTC). SecurityAgent отсутствовал. XCTest после обычной подготовки UI fixture запустил Review, загрузил тестовую страницу и дошёл до Fire-диалога без запроса Keychain.

Первые два контрольных запуска не являются успешными UI-прогонами: первый остановился в LetsMove PFMoveToApplicationsFolderIfNecessary → NSAlert.runModal (подтверждено sample), второй — на отсутствующем loopback tests-server. После установки существующей в репозитории настройки moveToApplicationsFolderAlertSuppress и запуска штатного tests-server третий дошёл до Fire-диалога. Его итоговый xcresult не экспортирован: lease удалён через journal cleanup в 11:57:26 UTC при expires_at 12:50:44 UTC. Предыдущий lease аналогично удалён в 11:48:21 UTC при expires_at 12:16:36 UTC. Из исследующего чата release для этих двух VM не вызывался; инициатор cleanup по доступному журналу не установлен. Полный зелёный UI-прогон этим контролем не подтверждён.

Практическое правило для DDG Review: сначала использовать штатные default/search list и дать приложению создать собственный тестовый runtime-ключ; не добавлять отдельный keychain по предположению о неисправной подписи. При необходимости отдельного fixture проверять доступ именно target app в контексте его запуска. Готовность native GUI/SSH probe Virfield и наличие подписи сами по себе не квалифицируют произвольный дополнительный keychain.

Прерывание Fire UI из-за внешнего диска, 2026-10-23

На macOS 12.7.6 / Xcode 13.4.1 / SIP off полный прогон 13 Fire + 2 Downloads завершился 15/15 без failures/skips; xcresult экспортирован и SHA-256 проверен (391574a0ecdb749b51ed2ec00f21a41095d01ad1c05ae64f59c2251590607ab1). Использовался подписанный Developer ID Review, штатный login keychain, без дополнительного keychain и изменения ACL.

Повтор на финальном UI fixture-коммите 895a1208cb в lease lease-7c4845485566c07b3c81d4c7ce5cd29f прервался по инфраструктурной причине: в 14:49:40 UTC Virfield зарегистрировал vm_drift. Host unified log подтверждает unmount Samsung970EVO (disk7s1) в 14:49:42 UTC и повторное монтирование после unclean unmount в 14:50:30 UTC. Tart PID 89926 оставался жив, но lsof показывал revoked дескрипторы и недоступный cwd; SSH перестал отвечать. Это потеря backing storage запущенной VM, а не установленный дефект подписи/keychain. Причина самого отключения внешнего диска не установлена. Штатная revalidation не прошла проверку running VM + SSH; lease освобождён через vm_release, cleanup job-ebcdd093838c10a1b4a1d26b417e38d3 succeeded. Прерванный повтор не считается результатом тестов.

Зависание AppleParavirtGPU в Monterey UI worker, 2026-10-23

В свежем SIP-off Monterey lease lease-50a13570aea1fc5518cd0bad61f42e3d на штатном keychain первые 6 UI-методов прошли. Следующий остановился в XCTest click при подготовке клика в исходной очистке, до проверяемого закрытия Fire Window. sample runner: _XCUIMatchingPointInFrameUsingContext; sample testmanagerd: _XCT_requestScreenshot → ImageIO HEIF → VideoToolbox → Metal → AppleParavirtGPUMetalIOGPUFamily. Главный поток Review ожидал обычное событие в run loop; AppKit NSPersistentUI snapshot queue также ждала IOSurface. Guest kernel log: Trying to restart GPU (Undefined)... и stalling for detach from AppleParavirtGPU. Повторного unmount внешнего диска в этот период не зарегистрировано.

Это подтверждённая остановка графического стека VM; причина его зависания и необходимость исправления в Virfield пока не установлены. Нельзя считать её дефектом подписи/keychain или успешным тестом. Собраны три sample, kernel log, частичный xcresult; owned xcodebuild остановлен SIGINT. Архив SHA-256: 2355f674562533ead70b8f8e68cf5cfea1403dd00f8d9e3b863dd8c36a8047e0. Оставшиеся методы проверяются отдельными короткими прогонами с теми же assertions/timeouts, без отключения анимации или GPU.

Текущая работа 2026-10-23: UI readiness

Локальный main содержит коммиты fd980dd, c7d75e7, 1126997, 6203177, 5f605d8, 7b5c124, 4e913d5, 5800007; рабочее дерево чистое. Полный make check с race-тестами прошёл. Кэш Xcode на Mac очищен с 41 до 19 ГБ: распакованные копии удалены после сверки XIP, четыре XIP сохранены; код повторяет очистку. Для новых Xcode-образов и disposable workers действуют настройка unattended Automation Mode и native XCUITest gate 1/1; установленный daemon проверен на свежем Monterey образе и аренде. Остальные физические node-хосты требуют отдельного повторного сквозного прогона.

Cold boot двух node VM на htpc выявил ошибки прежней установленной версии: Sonoma lease-1e935304d66b68d41c7850a89f79d0ae получил SSH примерно через 17 минут, Finder стабилизировался позже двухминутного desktop timeout; Sequoia lease-1140ca109abe50cf3c095ae5c24a496b дал временную ошибку чтения модели. Код увеличил бюджет node-lease до 45 минут, desktop до пяти минут и повторяет временно неудавшееся чтение модели. Обе VM требовали аутентификации Automation Mode. Sequoia lease удалён после подтверждения владельца; прежние временные leases позднее освобождены. Повторный прогон на этих node-хостах ещё не зафиксирован.

Production 2026-10-23 обновлён clean-сборкой коммита 5800007, подписанной доступным Apple Development сертификатом с прежним Team ID E3R68ED529; backup не создавался. Демон перезапущен и обслуживает действующие аренды. Старые временные leases освобождены. Full Disk Access после переподписи и свежие прогоны на всех физических node-хостах ещё требуют отдельной приёмки; Screen Recording/Downloads TCC конкретных приложений требует системного согласия.

SIP-off исправление внедрено, 2026-10-23: коммит 4e913d5 делает SIP-disabled обязательным для новых образов и аренд, блокирует SIP-on источники и проверяет фактический csrutil status клона до ready. Для Monterey 12.7.6/21H1320 подготовлена чистая SIP-off Tart-основа, опубликована в приватном GHCR и закреплена digest sha256:3733c94473dd603e048b64000db273a63fd0c8e5520d674cede1be9dad78cfee в production config. Встроенный image-create собрал golden monterey-xcode-13.4.1-sip-off с Xcode 13.4.1/13F100; квалификация после reboot подтвердила SIP off, unattended Automation Mode и native XCUITest 1/1. Свежая арендованная VM lease-b88068aa62098d8c02a659f2ab5593f7 повторила csrutil status: disabled, DOES NOT REQUIRE user authentication, Xcode 13.4.1 и XCUITest 1/1; её cleanup succeeded. Старый SIP-on golden удалён через image-delete, запись старого шаблона удалена из production config. Временные импорт и клонированные VM очищены. На htpc свежие Sonoma 14.8.9/Xcode 16.2 и Sequoia 15.8.1/Xcode 26.3 leases прошли SIP-off, unattended Automation Mode и XCUITest 1/1; обе проверочные аренды удалены. mbp2014 Monterey — физический MacBookPro11,1 (kern.hv_vmm_present=0), а не VM: SIP показывает custom configuration, консоль была заблокирована и UI smoke завершился Running Background (1 failure). Его ready подтверждает SSH, не UI; проверочная аренда удалена. Три остальных mbp2014 шаблона помечены artifact_missing. Остальные VM/хосты сквозным прогоном ещё не охвачены.

Цель: самостоятельный инстанс на поддерживаемом оборудовании

Статус 2026-10-23: не реализовано и не принято. Каждый разработчик устанавливает свой Virfield со своими config, state, token, образами и MCP. Общий командный сервер, общий operator token и RBAC между разработчиками не входят в эту цель. «Одна кнопка» означает единый установщик или мастер, который определяет возможности машины, выполняет доступные шаги и показывает только неизбежные системные подтверждения. Не обещать запуск на оборудовании, где macOS VM технически недоступна; показывать конкретное ограничение до установки.

Проверенные пробелы

1. README сейчас требует вручную установить Go/Python/Tart/Packer, клонировать и собрать проект, выполнить init, редактировать config.json, копировать бинарники, запускать daemon и отдельно регистрировать MCP. init не получает готовый образ. Это не самостоятельная установка в несколько действий.
2. Linux node VM требует вручную установить qcow2 bootstrap и OpenCore, настроить SSH, Podman/KVM/TUN, admin/sudo и профили. Автоматический путь от чистого поддерживаемого Linux-хоста до готового golden отсутствует.
3. Клиенту без virfield CLI приходится вручную создавать SSH-ключ, pinned known_hosts и config. Локальная установка должна создавать и хранить их сама; приватный ключ остаётся на машине владельца.
4. В продуктовой справке и docs использовалось собственное имя узла htpc (удалено из checkout 2026-10-23; выпуск ещё не собран). Runtime не проверял строку htpc, но node startup deadline 45 минут и desktop deadline 5 минут выбраны по замеру одного нашего cold boot. Кроме того, стандартные VM-рецепты и init предполагают гостевой admin с домашним каталогом /Users/admin. Это контракт конкретного профиля образа, а не путь аккаунта владельца на хосте; мастер должен выбирать совместимый профиль и проверять его, а бюджеты и требования к гостю не выводить из нашего оборудования.
5. Monterey на установленном clean release 5800007 проверен через встроенный image-create, квалификацию образа и свежую аренду с native XCUITest 1/1. Свежие Sonoma/Sequoia Intel leases на htpc прошли UI readiness и XCUITest 1/1. Для остальных конфигураций и независимой установки нужен сквозной прогон и воспроизводимый релизный пакет.
6. SIP-off критерий для Monterey закрыт: новый digest-pinned источник, golden и fresh lease проверены после reboot, старый SIP-on golden и шаблон удалены. Общее требование «SIP отключён на каждой VM» закреплено в коде и проверено на свежих Tart Monterey и node VM Sonoma/Sequoia; остальные доступные VM шаблоны ещё требуют сквозной проверки. Физический mbp2014 не является VM. Screen Recording/Accessibility/TCC конкретных workload отдельно не подтверждены; SIP-off сам по себе не доказывает их доступность.
7. Web UI, HTTP API и MCP имеют разные наборы операций. Для одного собственного инстанса допустим owner token; ранее предложенный общий командный RBAC не является блокером этой цели. Требуется полный поддерживаемый локальный цикл через web UI и MCP, включая ясную диагностику и безопасные повторы.

Порядок исправления и критерии

1. Матрица поддержки и preflight. Явно описать поддерживаемые хосты и провайдеры; определить OS/архитектуру, гипервизор, виртуализацию, свободные CPU/RAM/диск, доступ к storage, Xcode/Apple prerequisites и права. Возвращать причину и действие для каждого отказа. Все пути, имена узлов, порты и бюджеты брать из выбора пользователя или обнаруженного окружения, не из нашего deployment.
2. Пакет и мастер установки. Подписанный проверяемый пакет без обязательной сборки исходников. Мастер создаёт отдельные private config/state/token, предлагает storage, получает/проверяет pinned base, регистрирует собственный сервис и MCP в выбранном клиенте; шаги идемпотентны и дают rollback. Для node backend автоматизировать поддерживаемый bootstrap или до выбора явно сообщать, что он пока не поддерживает one-click.
3. Параметризовать готовность и приватность. Вместо одного фиксированного 45/5-минутного бюджета использовать профиль провайдера и конфигурируемые пределы с безопасными default, общей deadline и фазовой диагностикой. Обязательный gate для каждого нового образа и клона: SIP-off; SIP-on образ нельзя публиковать или выдавать в lease. Существующие SIP-on goldens пересоздать из совместимого SIP-off источника и подтвердить после reboot; активные VM не менять на месте. Все Xcode-образы и рабочие клоны подтверждать native XCUITest с >=1 выполненным тестом до ready; проверить на быстрых и медленных хостах. Отдельно объявлять и проверять нужные workload capabilities (например Screen Recording, Accessibility, доступ к защищённым папкам) внутри создания образа или подготовки lease. Если требуемое разрешение не получено, lease не должен объявляться готовым к такому workload. Пользовательский тестовый скрипт не должен настраивать TCC/SIP/Automation Mode.
4. Одинаковый продуктовый цикл в UI и MCP. Создание образа, Apple sign-in при необходимости, acquire, локальный SSH identity/config, выполнение workload через SSH, экспорт, renew/recovery и release доступны без ручного JSON, known_hosts и работы с каталогом daemon. Операции опираются на один API и одинаковые durable job/idempotency semantics.
5. Приёмка независимого пользователя. На чистых поддерживаемых Apple Silicon Mac и Linux/KVM-хосте, с пустыми config/state и без наших путей/образов, пройти мастер → подключить UI/MCP → создать golden → получить VM → выполнить build и XCUITest → экспортировать результат → release. Повторить после restart, медленного cold boot, потери сети, нехватки диска и истечения Apple session. Выпускать только clean signed package с hashes и протоколом этих прогонов.

Ограничения и дальнейший план

Следующие задачи не входят в принятую установленную VM/MCP/Broker-приёмку и не объявляются реализованными:

• Проверить Apple-authorized download свежим входом и реальный VS Code editor / DuckDuckGo application debugging; generic installed LLDB-DAP уже проверен.
• Установить причину прежнего guest-kernel stall: 2002-stackshot diagnostic её не воспроизвёл. Поздние успешные циклы не доказывают причинное исправление.
• Развивать Orchard и другие провайдеры отдельными проверенными сценариями; mixed-primary scheduling, libvirt/Vetu и лицензируемые провайдеры остаются отдельным объёмом.
• Реализовать signed node-agent, WoL relay/power intents, grants/connectors и physical-host/browser desktop при отдельном приоритете.
• Развивать /api/v3 capability selection, Target/EnvironmentProfile/ConnectionGrant, short-lived access, VS Code extension и linked Console/Broker flows.
• Расширить crash/host-loss/partition/full-disk matrix, metrics/alerts, signed promotion/revocation.
• Изучить MDM для VM Virfield: способ подключения, требования, польза и решение (итог ниже, 2026-10-23).

Broker reviewer исправление уже входит в запушенный Broker main 13c29ac. Завершённые локальные и remote ветки Broker удалены после содержательной сверки, reviewer worktree сохранён detached. Архив исходного patch: personal/projects/archive/virfield-release-cleanup-2026-10-16/docs/acceptance/broker-reviewer-readonly.

Детальные прежние планы сохранены в personal/projects/archive/virfield-release-cleanup-2026-10-16/docs/VIRFIELD-3-PLAN и архиве superpowers. Их старые pending-статусы не заменяют результаты выше. Автоматизация остаётся на паузе по указанию пользователя.

MDM для Virfield: исследование и решение (2026-10-23)

Решение: не включать MDM в текущий путь создания disposable VM. Virfield не содержит MDM-сервера, enrollment profile или операции регистрации VM. Сейчас он применяет SIP/Automation Mode/TCC через guest scripts и проверяет результат на образе; native XCUITest даёт прямое доказательство готовности runner. MDM не исправляет сам по себе прежний пропуск Automation Mode.

Подключение потребовало бы отдельного MDM-провайдера, HTTPS endpoint, сертификата APNs, identity certificate для каждого гостя, enrollment profile и регистрации каждой VM. Для Apple Business Manager/ADE нужны ещё организационные связи и назначение устройств; пригодность ADE именно для наших виртуальных Mac не подтверждена и должна проверяться на отдельном disposable образе. Клонирование уже зарегистрированного golden недопустимо как проектное допущение: enrollment и identity нужно создавать для каждого worker отдельно, а при release удалять запись и сертификаты на сервере.

Польза возможна для долговечных физических Mac: централизованные настройки и аудит, управляемые приложения, отдельные PPPC разрешения (например Full Disk Access и PostEvent). Для краткоживущих VM цена — внешний сервис, сертификаты, сеть/APNs, регистрация и очистка каждого worker. Главное ограничение для UI-тестов: Apple не разрешает MDM-профилем заранее дать ScreenCapture; только запретить. На macOS 27 старый PPPC grant для Accessibility убран; новый declarative AppSettings предлагает пользователю запрос согласия, но не выдаёт доступ без него. Поэтому MDM не заменяет наши UI-readiness проверки, настройку Automation Mode и человеческое согласие там, где его требует macOS.

Источники Apple: MDM enrollment, инфраструктура/APNs, PPPC и ScreenCapture, macOS 27 AppSettings. Проверка текущего кода: internal/qualify/automation.go, internal/guestscripts/security.sh, internal/guestscripts/provision27.sh, internal/config/config.go.