Files
obsidian-vault/personal/projects/virfield.md
T

149 lines
49 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.
## Прерывание 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.
- [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`.