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.

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

Локальный main содержит коммиты fd980dd, c7d75e7, 1126997, 6203177, 5f605d8, 7b5c124; рабочее дерево чистое. Полный make check с race-тестами прошёл. Кэш Xcode на Mac очищен с 41 до 19 ГБ: удалены две распакованные копии после сверки исходных XIP, четыре XIP сохранены. Новый код повторяет очистку после использования архива и при старте daemon; установленная production версия пока не обновлена. Для 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. Sequoia lease удалён через journal API после подтверждения владельца: cleanup job job-e055b9c977d2d35c6d6d7239b82429e9 succeeded, lease released, контейнер отсутствует. Sonoma lease сохранён до отдельного подтверждения; повторный прогон нового кода ещё не выполнен.

Production пока v2.1.1: локальные Tart leases заняты, один до 2026-10-24. Установленный daemon подписан Team ID E3R68ED529. Доступный личный сертификат Apple Development: mallexxx@gmail.com (D46EWG5VWN) после сборки дал тот же Team ID и designated requirement, что у установленного binary; первоначальный вывод об отсутствии identity был ошибочным. Кандидат собран и подписан, но не установлен: online backup старый daemon отклонил с backup_failed (требует idle manager и resolved jobs), а два действующих Tart leases заняты, один до 2026-10-24. Для production upgrade нужно дождаться завершения leases, затем выполнить контролируемый restart, проверить фактический Full Disk Access и fresh lease acceptance на Monterey, Sonoma, Sequoia. Обязательный backup перед обновлением из инструкции удалён; пустые каталоги backup удалены 2026-10-23. Screen Recording/Downloads TCC для конкретных приложений остаётся за системным согласием пользователя.

SIP-off исправление в исходниках, 2026-10-23: коммит 4e913d5 меняет default нового образа на SIP-disabled, запрещает создание/сборку/перенос/публикацию и выдачу SIP-on VM, помечает старые SIP-on образы недоступными и проверяет фактический csrutil status на клоне до ready. Полный make check и web UI тесты прошли. Проверенная production конфигурация всё ещё содержит monterey-xcode-13.4.1 с SIP-on; два активных Monterey leases нельзя менять на месте. Исправление ещё не установлено на production и не проверено на всех реальных машинах; нужен новый SIP-off Monterey source/golden и приёмка после завершения leases.

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

Статус 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. Xcode UI readiness gate и исправления холодного node startup есть в checkout, но ещё не приняты на установленном release-кандидате на свежих поддерживаемых конфигурациях. Работающий бинарник сообщает vcs.revision=2c64888 и vcs.modified=true; перед распространением нужен воспроизводимый clean release.
6. Нарушен критерий приёмки: SIP должен быть отключён на каждой VM Virfield. Установленная production v2.1.1 ещё содержит Monterey developer-v1 с SIP-on; исходники уже запрещают новые SIP-on образы и leases коммитом 4e913d5. Требуется выбрать/построить SIP-off источник Monterey, пересоздать и квалифицировать старый golden без изменения активных leases, затем установить исправление и проверить SIP-off на каждом подготовленном клоне. Отдельно подтвердить Screen Recording/Accessibility/TCC и native XCUITest: SIP-off сам по себе не доказывает готовность UI.
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.