# Virfield

Проверено: **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]].

На 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](https://github.com/mallexxx/virfield/actions/runs/38899141941): 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](https://developer.apple.com/documentation/security/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`, `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 очищены. Для остальных 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. Холодный node startup и UI readiness на свежих Sonoma/Sequoia Intel и остальных поддерживаемых конфигурациях остаются пунктом приёмки; для независимой установки нужен воспроизводимый релизный пакет.
6. SIP-off критерий для Monterey закрыт: новый digest-pinned источник, golden и fresh lease проверены после reboot, старый SIP-on golden и шаблон удалены. Общее требование «SIP отключён на каждой VM» закреплено в коде, но не проверено сквозным прогоном на каждом node-хосте. 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.
- [x] Изучить 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](https://developer.apple.com/documentation/devicemanagement/deploying-device-management-enrollment-profiles), [инфраструктура/APNs](https://support.apple.com/en-gb/guide/deployment/depceaf9c713/web), [PPPC и ScreenCapture](https://developer.apple.com/documentation/devicemanagement/privacypreferencespolicycontrol/services-data.dictionary), [macOS 27 AppSettings](https://developer.apple.com/documentation/devicemanagement/appsettings). Проверка текущего кода: `internal/qualify/automation.go`, `internal/guestscripts/security.sh`, `internal/guestscripts/provision27.sh`, `internal/config/config.go`.