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

168 lines
31 KiB
Markdown
Executable File
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.
---
title: Virfield
namespace: personal
updated: '2026-10-07'
status: virfield-3-stage-1-in-progress
tags:
- virfield
- macos
- vm
- go
- infrastructure
---
# Virfield 3.0 — handoff checkpoint — 2026-10-07 15:35 Bishkek
**Текущий статус: Stage 1 (Tart/Orchard migration) в работе; продолжать в `/Users/admin/Developer/virfield-v3`, branch `codex/virfield-v3-stage1`.** Это актуальная запись состояния; ниже сохранена история v2 от 2026-10-03.
## Обновление 2026-10-08 21:30 — уборка, пробуждение арендой, сторож сна HTPC, спека R3
- Уборка: Lume удалён (brew); в корзину: `~/.lume` (253 ГБ), IPSW/архивы/upgrades/state/логи v2 из `~/.virfield-v2`, `virfieldd.pre-*`, хранилище Lume на Samsung (57 ГБ), сборочные папки HTPC (KDE-корзина). Оставлено живое: bin (virfieldd/virfield/virfield-mcp), config, токены, GHCR creds, `cache/xcode`, Orchard. Пользователю: очистить корзины; `sudo rm /Library/LaunchDaemons/ai.virfield.lume.plist`. Код Lume в репо — отдельная задача.
- Пробуждение арендой HTPC: PASS (готов через 27 с после WoL).
- `~/htpc-sleep-guard.py` (user unit `htpc-sleep-guard`): после отпускания удержания ждёт 30 мин и делает `systemctl suspend`, если ничего не держит сон и нет чужих block-ингибиторов; бэкап `htpc-sleep-guard.py.bak-20261008`. Причина: таймер простоя рабочего стола срабатывает один раз и истекал под удержанием Virfield.
- R3 (рабочий стол VM): спека `docs/superpowers/specs/2026-10-08-desktop-r3-design.md` (`a00fc57`) — гостевой Screen Sharing, туннель аренды `service=desktop`, `virfield desktop`, кнопка в Web Console; только VM (не MacBook), без noVNC. Ждёт ревью спеки → план.
## Обновление 2026-10-08 21:00 — R2 живой: macOS-VM на HTPC арендуются через Virfield
- План `docs/superpowers/plans/2026-10-08-remote-nodes-r2-macos-vms.md` выполнен (inline). Коммиты `5563aba`…`5599e0a` на `codex/virfield-v3-stage1`, задеплоено.
- Код: SSH-адрес = IP + порт (`VM/Lease.SSHPort`, контроллер, туннель, `ssh-config`); `guestssh` с портом аренды, маршрутизируемым dialer и списком моделей (`iMacPro1,1`); `nodes[].vms` в конфиге; скрипты ноды для VM (clone/start/stop/delete/commit/probe, баннер SSH); источник образа `node` и цепочка `build→qualify→stop→commit`; пакет `internal/nodeimage`; SSH Virfield к гостю — через закреплённое SSH ноды на `127.0.0.1:<порт>`.
- Защищённые golden на HDD HTPC: `htpc-sonoma-14.qcow2`, `htpc-sequoia-15.qcow2` (Virfield: пароль сменён, ключ управления, SSH только по ключу, автологин, проверка после перезагрузки). Шаблоны `htpc-sonoma-14`, `htpc-sequoia-15` в config.
- Приёмка 19/19: две VM (порты 22100/22101) + аренда хоста одновременно; чужой ключ и bootstrap-пароль отклоняются; после release всё убрано. Готовность двух VM разом ~9 мин (HDD), одна ~2 мин.
- Найдено и исправлено вживую: проброс порта принимает TCP раньше sshd (баннер + повтор рукопожатия, `0b0cf05`); `sysadminctl` дольше минуты (5 мин на мутации, `dcf96e2`); устаревший probe после commit (диспетчеризация по ImageID, `163caa4`).
- Осталось: тест пробуждения HTPC арендой (запущен), pmset на Monterey/Big Sur/Catalina, уборка сборочных папок на HTPC (`~/virfield/hackintosh/build`, контейнеры `vf-build-*`, `vf-test-*`), R3 gateway, VS Code debug на Tart, GHCR, Orchard.
## Обновление 2026-10-08 16:40 — все тома MBP; macOS-VM на HTPC (R2) — golden-образы готовы
- MBP: Monterey/Big Sur/Catalina/Ventura — все арендуются (по 5/5), host keys всех томов в `runtime.nodes[].host_keys` и `~/.ssh/known_hosts`. Management key добавлен на каждый том. `pmset -c` (без сна на зарядке) применён только в Ventura — остальные тома при загрузке.
- Код: `a37bddf` (несколько host keys), `8e32df3` (последний probe ноды хранится в `state_dir/nodes/*.probe.json` → asleep-нода арендуема после рестарта демона). Документы `c58e7a9`.
- HTPC: VT-x включён, `/dev/kvm` доступен без sudo; virtqemud работает, но libvirt не используется.
- R2 = rootless Podman + `dockurr/macos@sha256:08d1bcaa…` (QEMU+OpenCore), SIP off через OpenCore `csr-active-config=0x7F` (custom.plist). Спека `docs/superpowers/specs/2026-10-08-hackintosh-nodes-r2-design.md`.
- Golden-образы (HDD `/run/media/system/Data/virfield/goldens`, read-only): `sonoma-14.8.9-23J631-20261008.qcow2` (15 ГБ), `sequoia-15.8.1-24H32-20261008.qcow2` (18 ГБ) + `.opencore.plist`. Контракт как у Tart base: admin/admin, sudo без пароля, Remote Login, без сна/автообновлений, свежие host keys.
- Клоны: qcow2 overlay на SSD (`~/virfield/hackintosh/leases/<vm>`, `chattr +C`) поверх golden на HDD → SSH за ~110 с, overlay 57–77 МБ, новая identity (serial/MAC) на каждый клон. Клон зависает в конце shutdown → остановка = shutdown по SSH + `podman kill`.
- Сборочные папки (`~/virfield/hackintosh/build/{sonoma,sequoia}`, контейнеры `vf-build-*`, `vf-test-*`) пока оставлены; SSD HTPC свободно ~109 ГБ.
- Не сделано: провайдер Virfield для этих VM (код), secure-шаг Virfield на golden, тест пробуждения HTPC арендой (повтор), pmset на остальных томах MBP, R3 gateway, VS Code debug на Tart, GHCR publish, Orchard.
## Обновление 2026-10-08 — MBP Big Sur: несколько host keys на одну ноду
- Каждый том MBP имеет свой SSH host key → `runtime.nodes[].host_keys` (доп. идентичности); dialer принимает любой из них, lease отдаёт фактически предъявленный. Коммит `a37bddf`, задеплоено.
- Big Sur 11.7.9: ключ пользователя и management key добавлены в authorized_keys тома Big Sur; ключ Big Sur в `~/.ssh/known_hosts` (бэкап `known_hosts.bak-*`) и в config. Приёмка `mbp2014-big-sur` 5/5.
- Ранее сегодня: Finder/ASIF — спек-кэш `tart get` + листинг каталогов вместо `tart list` (`96dfae3`, `0283901`); Clone будит спящую ноду (`ad78b8d`).
- Дальше: Catalina/Ventura — enroll при загрузке (ключ пользователя + management.pub, `ssh-keyscan` → `host_keys`); HTPC VT-x/libvirtd → R2; повтор теста пробуждения арендой.
## Обновление 2026-10-08 11:20 — Remote nodes R1 работает вживую
- Спека `docs/superpowers/specs/2026-10-08-remote-nodes-r1-design.md`. SSH-first (агент позже), без sudo на нодах, «аренда того, что загружено». HEAD `9f2dabd`.
- Ноды в `~/.virfield-v2/config.json` (`runtime.nodes`): `mbp-2014` = admin@192.168.1.79 (MBP 11,1, Monterey 12.6.8 загружен; тома Catalina/Big Sur/Ventura/BOOTCAMP; sudo с паролем; без WoL); `htpc` = bazzite@192.168.1.86 (Bazzite 43, WoL B0:6E:BF:60:6D:64, keep-awake `/tmp/rsync-active`; VT-x выключен в UEFI → для R2 Hackintosh нужно включить). Host keys взяты из `~/.ssh/known_hosts`, отпечатки сверены.
- Management key Virfield: `~/.virfield-tart/nodes/management(.pub)`; добавлен в authorized_keys admin (только том Monterey!) и bazzite. Остальные тома MBP — enroll при загрузке.
- Шаблоны: `mbp2014-monterey|big-sur|catalina|ventura` (доступен только загруженный том), `htpc-bazzite`.
- Код: `internal/wol`, `internal/baremetal` (скрипты на ноде, псевдо-golden = имя тома, lease-маркеры `~/virfield/leases/<vm>`, ключ лиза с тегом `virfield-lease-<vm>`), `internal/fleet` (композит Tart + nodes, параллельно), per-host capacity в контроллере.
- Приёмка 20/20 (MBP + HTPC + Tart VM одновременно, Mac 1/2 слота). Тест пробуждения HTPC арендой — в процессе (ждём естественного сна).
- Наблюдение: Finder 356% CPU (обход VM-SSD) → `tart list/get` 12–18 с → кратковременные паузы admission. Рекомендовано `killall Finder`.
## Обновление 2026-10-08 01:45 — macos27 на Tart, Broker smoke пройден
- Шаблон `macos27` (ID, который используют Broker-воркеры) теперь Tart golden из `macos-golden-gate-xcode@sha256:324ea565…` (macOS 27.0/26A428, тот же IPSW, что у Lume-golden), SIP off, Xcode 27.0 (27A266a) переименован в `/Applications/Xcode.app`, общий рецепт `uitest-27-v1` (`internal/guestscripts/provision27.sh`, без `lume`). Квалификация с UI-test probe пройдена.
- Broker smoke (`execution-broker/scripts/macos-smoke.py --config-dir state/deploy --balda-container balda-mm-mac`) пройден без изменений Broker: run `run-af3ed27f…` succeeded, cleanup done, XCTest 1/0 fail. HEAD `7c12fdf`.
- Найдено и исправлено: `tart run` сразу после Packer падает «already running» — раньше проглатывалось (`b0e5bf7`); инвентарь Tart с ASIF-дисками не укладывался в 5 с (последовательные `tart get` ~1 с каждый) → admission на паузе, аренда висла в provisioning (`2101918`: параллельно + 30 с).
- Remote nodes R1 (MBP 2014: Catalina/Big Sur/Monterey, без WoL, «что загружено»; HTPC Bazzite 192.168.1.86 с WoL; SSH-first, агент позже; per-host capacity; композитный runtime) — дизайн предложен, ждёт одобрения. В LAN есть `kraken.local` (Raspberry Pi, Debian 12, 192.168.1.14) — кандидат в WoL-relay.
## Обновление 2026-10-07 23:40 — Tart: оба golden приняты вживую
- Live-сервис 7780 работает на Tart (`virfieldd` `ae7b3df`, подписан `Apple Development: mallexxx@gmail.com`, identifier `ai.virfield.virfieldd` — FDA-грант переживает пересборки). Docs-коммит `19f5c01`; запись в `docs/VERIFICATION.md#tart-image-adoption-2026-10-07`.
- Golden: `ventura-xcode-15.2` (13.7.4/22H420, Xcode 15.2, SIP off) и `monterey-xcode-13.4.1` (12.7.6/21H1320, Xcode 13.4.1, SIP on) — `image_ready`, собраны и квалифицированы job'ом без ручных шагов. Two-clone acceptance: 23/23 PASS каждый (изоляция SSH, ключи, Xcode, Swift, scp, удаление VM). Скрипт приёмки: в scratchpad сессии (`accept.sh`), не в репо.
- Исправлено по ходу live: probe тома (mount point), рост APFS в госте, гонка `packer init`, DeviceSupport extractor (bundle-файл), сброс local-network сессии после обновления демона (retry dial), `nfsd restart` при SIP on → `nfsd update`.
- Хост-требования: Full Disk Access для `~/.virfield-v2/bin/virfieldd`; `registry_credentials` для GHCR (Docker-креды на хосте отвергаются GHCR).
- Откат на Lume: `cp ~/.virfield-v2/config.lume.json ~/.virfield-v2/config.json` + бинарник `bin/virfieldd.pre-tart-20261007-205243` + `kill -TERM` PID (launchd поднимет). Lume state (`~/.virfield-v2`) не тронут, включая needs_attention job 13.6/Xcode 15.2.
- Дальше: Broker v1 smoke и VS Code remote-debug на Tart-арендах; GHCR push golden; Orchard; тест рестарта во время Tart build; pin sha256 плагина. Lume-шаблоны (macOS 27 UI-tests и др.) в Tart-режиме недоступны.
## Обновление 2026-10-07 вечер — Tart adoption: этапы 1–2 реализованы (не развернуты)
- Ветка `codex/virfield-v3-stage1`, HEAD `d60e72a`, дерево чистое, `make check` зелёный. Спека: `docs/superpowers/specs/2026-10-07-tart-image-adoption-design.md`; планы: `docs/superpowers/plans/2026-10-07-tart-guest-identity.md` (этап 1), `…-tart-adoption-pipeline.md` (этап 2).
- Решения пользователя: Tart window (один launchd job, отдельные config+state_dir, переключение только без активных Lume-аренд); профиль = OS базы + Xcode, SIP как в профиле; golden локально (push в GHCR позже); максимум Tart/Cirrus/Packer, Lume не развивать; Monterey включить.
- Этап 1: `guestssh` работает от `lease.GuestUser` (пусто → `lume`), Tart-аренды проходят `LeasePreparer`. Этап 2: `ImageProfile.Tart` (ghcr@sha256), `runtime.tart.image`, пакет `internal/qualify` (вынесен из `images`, Lume вызывает его с `lume`), `internal/tartimage` (встроенный Packer-рецепт, плагин `cirruslabs/tart = 1.21.0`, фазы `resolve → build → qualify → stop`), регенерация SSH host keys в каждом golden.
- Проверенные факты: Ventura base `sha256:9fb387bb…` = 13.7.4 (22H420), SIP выключен; Monterey `macos-monterey-vanilla:12.7.6` `sha256:4bc904cf…` = 21H1320, SIP включён (`macos-monterey-xcode`/`-base` в формате `disk.v1`, Tart 2.40 их не тянет). Обе в кэше `TART_HOME=/Volumes/Samsung970EVO/virfield-tart`. `tart clone` сохраняет ECID (local clone → новый MAC); APFS Encryption=true при FileVault off → для Tart разрешено. `~/.docker/config.json` содержит GHCR-креды, которые GHCR отвергает (403) — нужен `registry_credentials` с `ghcr-mallexxx.token`. Xcode XIP 15.2/13.4.1 в `~/.virfield-v2/cache/xcode/<sha1>.xip` (verified).
- Этап 3 (в работе, ~21:10): плагин Packer `cirruslabs/tart 1.21.0` установлен, рецепт валиден. Lume-аренда `lease-c30327cb…` освобождена (VM удалена, подтверждено). Live-сервис переключён на Tart: `~/.virfield-v2/config.json` = Tart-конфиг (`state_dir ~/.virfield-tart`, контейнер `samsung-tart`, шаблоны `ventura-xcode-15.2`, `monterey-xcode-13.4.1`); откат = `config.lume.json` + `bin/virfieldd.pre-tart-20261007-205243` + restart. Исправлен баг probe тома (diskutil на не-mount-point, `f491ed4`). **Блокер**: macOS TCC не даёт `virfieldd` доступ к Removable Volumes → `tart list` в `TART_HOME` на Samsung висит/падает. Пользователь должен добавить `~/.virfield-v2/bin/virfieldd` в Full Disk Access; ad-hoc подпись → грант теряется при каждой пересборке (нужна стабильная подпись). Далее: сборка двух golden, две параллельные аренды каждого, запись в `docs/VERIFICATION.md`. Отложено из ревью: pin sha256 плагина, проверка runtime/profile при загрузке конфига. HEAD `02fb431`.
## Обновление 2026-10-07 17:00 — dirty-дерево развернуто на 7780
- Исправлен логин: `api()` в `internal/web/app.js` сообщал «Cannot reach Virfield API» на любой `TypeError`, а `fetch()` бросает `TypeError` ещё до запроса, если токен содержит не-Latin-1/управляющие символы (кириллица, emoji, перевод строки). Теперь `Request` строится отдельно → `invalid_token` / «Invalid token format…»; «Cannot reach» только при реальном сбое сети. Неверный ASCII-токен → серверный 401 «a valid bearer token is required». Проверено вживую в UI.
- Разобраны незакоммиченные Go-правки (registry credentials только для matching Tart remote, APFS free-space fallback, тесты) — оставлены. Ограничение: registry host с портом (`localhost:5000`) отклоняется валидацией.
- Открытый вопрос: CSP в `internal/httpapi/server.go` ослаблен (`style-src 'unsafe-inline'`, `img-src data:`), но UI не использует inline styles/data: URI (meters на `<progress>`). Кандидат на откат к строгому CSP — решение за владельцем.
- `make check` exit 0, `git diff --check` чисто, `make build` прошёл. Деплой: исходники = HEAD `8830ad9` + dirty-дерево (не закоммичено); `virfieldd` sha256 `b6dbc77d4e1b05122aca9b5ad146ae609abbe226d71ec28da818bfad12758f97`. Rollback: `~/.virfield-v2/bin/virfieldd.pre-v3-20261007-165759` (это бинарник, лежавший на диске с 15:18; работавший до этого процесс PID 54497 был запущен в 13:50 из более старого, уже заменённого файла).
- Перезапуск без sudo подтверждён: `kill -TERM` единственного PID → launchd (`KeepAlive`) поднял PID 65669 за 2 с, last exit code 0. 7780 отдаёт `app.js`, идентичный worktree. Статус после рестарта: lease `lease-c30327cb…` (macos27, samsung, 192.168.64.211) остался `ready`, VM running, SSH доступен; job `job-3adb9d9d…` (13.6/Xcode 15.2) по-прежнему `needs_attention` (`image_command_failed` на Setup Assistant) — требует отдельного разбора по recovery-процедуре.
## Что проверено сейчас
- Worktree: HEAD `8830ad9` (`Add Tart and Orchard runtime providers`), родительский план `6013310`. Восемь файлов modified и не закоммичены: `cmd/virfieldd/main.go`, `internal/config/config.go`, `internal/httpapi/server.go`, `internal/tart/client.go`, `internal/tart/client_test.go`, `internal/web/app.js`, `internal/web/index.html`, `internal/web/style.css`. Не откатывать и не считать эти изменения заведомо своими без проверки.
- `http://127.0.0.1:7780` отвечает HTTP 200 и отдаёт v3 UI (Fleet / Images / Activity, Hosts & storage). Факт подтверждён запросом к live-сервису.
- Live `virfieldd`: launchd label `system/ai.virfield.virfieldd`, PID 54497 на момент проверки, пользователь `admin`; plist `/Library/LaunchDaemons/ai.virfield.virfieldd.plist` запускает `~/.virfield-v2/bin/virfieldd -config ~/.virfield-v2/config.json`. Имя `virfield-v2` — legacy путь развертывания, не доказательство версии исходников.
- Точная ревизия уже работающего процесса не установлена. Не заявлять, что бинарник на 7780 собран из HEAD `8830ad9`.
- Текущий dirty source успешно компилируется (`go build -trimpath -o /private/tmp/virfieldd-v3-check ./cmd/virfieldd`) и полный `make check` прошёл на этом состоянии 2026-10-07: docs links, Python tests, gofmt, `go vet ./...`, `go test -race ./...` (включая `internal/tart` и `internal/orchard`). Реальный Tart VM lifecycle и live Orchard acceptance не прогонялись.
## Следующее действие
> Шаги 1–5 ниже выполнены 2026-10-07 (см. обновление выше). Дальше: закоммитить проверенное дерево на `codex/virfield-v3-stage1`; решить по CSP; разобрать `needs_attention` job 13.6/Xcode 15.2; затем Phase 1 — digest-pinned Cirrus Tart adoption и две disposable Tart clone/boot/SSH/release проверки.
1. Разобрать каждое из восьми незакоммиченных изменений и сохранить нужное; проверить владельца/намерение, не затирать.
2. Прогнать `make check` в этом worktree и устранить регрессии.
3. Собрать `make build`; сохранить копию текущего deployment binary для отката, заменить `~/.virfield-v2/bin/virfieldd` собранным бинарником.
4. Перезапуск текущего launchd job пока не проверен. Для контролируемой проверки после сборки:
```sh
pgrep -x virfieldd
# Убедиться, что найден ровно один PID текущего сервиса.
kill -TERM PID
launchctl print system/ai.virfield.virfieldd | rg 'state =|pid =|runs ='
curl -fsS http://127.0.0.1:7780/ | rg 'v3|Fleet|Hosts & storage'
```
Причина ожидания автоматического старта: plist имеет `KeepAlive=true`, процесс работает от `admin`, а deployment directory принадлежит `admin`. Это ожидаемый способ без `sudo`, но пока не подтверждён живой проверкой. Если launchd не поднял новый PID, остановиться и диагностировать; не запускать второй daemon.
Сборка/установка (после успешных проверок; перед заменой сохранить бинарник для rollback):
```sh
cd /Users/admin/Developer/virfield-v3
make check
make build
cp -p /Users/admin/.virfield-v2/bin/virfieldd /private/tmp/virfieldd-before-v3
install -m 755 bin/virfieldd /Users/admin/.virfield-v2/bin/virfieldd
```
До live-проверки не объявлять обновление завершённым. Общий install/runbook находится в `docs/OPERATIONS.md`; он описывает регистрацию system LaunchDaemon с `sudo`, но не dev-перезапуск существующего job без `sudo`.
5. После подтверждения записать точный commit/build и результат live-проверки здесь. До этого не создавать второй listener и не менять порт.
## План/код — актуальный разбор
**Есть в коде:** единый `provider.Runtime` seam; конфиг выбирает Tart либо Orchard для одного процесса; Tart inventory/clone/run/stop/delete и отдельные `TART_HOME` storage containers с UUID/availability/free-space; Orchard worker/VM inventory, labels, per-host CPU/RAM/VM-slot capacity, offline reasons, create/stop/delete; общий lease/controller; Hosts/storage UI; WoL magic-packet sender; registry credentials передаются только командам Tart с matching registry host. Текущие dirty правки также чинят disk free-space APFS fallback, CSP для нового UI и registry auth. `make check` прошёл на текущем dirty дереве.
**Частично / не принято live:** внешний SSD и device groups отражаются из конфига/runtime observations, но отдельная независимая durable device registry в SQLite не добавлена; WoL отправляется самим процессом на configured broadcast, а не через отдельный same-L2 node-agent relay; Tart/Orchard проверены unit tests, но ни Cirrus digest adoption, ни реальная VM lease/clone/boot/SSH/release, ни live Orchard pool не приняты. Один `virfieldd` выбирает ровно один runtime — смешанный local Tart + remote Orchard/Lume provider routing пока отсутствует.
**Не сделано из плана:** node-agent и bare-metal lease для Intel Mac/Linux; connection grants/access gateway; VNC/noVNC и единый desktop; v3 API/target capability model; VS Code extension (остаётся генератор workspace/LLDB v2); libvirt/QEMU/OpenCore Hackintosh; Broker contract migration; distributed image worker/promotion; drain, multi-host lifecycle acceptance и production rollout. `image_tools` pipeline остаётся Lume-only и явно отклоняется при Tart; для Tart нужен отдельный digest-pinned Cirrus adoption/qualification path.
`docs/VIRFIELD-3-PLAN.md` остаётся целевой архитектурой, но 2026-10-07 его этапы обновлены: Phase 1 теперь Tart/Cirrus adoption и отдельная Orchard acceptance; статус, незакрытые gates и отличие unit tests от live acceptance прописаны. Docs link check и `git diff --check` прошли. Изменение в worktree пока не закоммичено.
- Источник кода — worktree `virfield-v3`; live deployment — `~/.virfield-v2`; это разные копии. 7780 показывает v3 UI, но точная ревизия процесса не установлена.
---
# Virfield — статус 2026-10-03
**Следующее действие:** проверить загрузку, работу и удаление временного клона из нового чистого образа Monterey/Xcode.
## Состояние
- Monterey 12.6 + Xcode 13.4.1: образ `image_ready`, временный legacy-клон прошёл загрузку, компиляцию Swift, SSH, выгрузку артефакта и очистку. Тест `TestLiveLeaseSSH` прошёл за 86,99 с 2026-10-03.
- Исходный образ `macos-12.6-xcode-13.4.1` остановлен и сохранён. Временный клон удалён; активных заданий и занятых слотов нет.
- Release-ready: нет. Чистая сборка прошла; клон нового образа и полный путь Balda/Broker ещё не приняты.
- Ветка `codex/versioned-images`: локальный коммит `19e01ac`; push не сделан.
## Установка Xcode и размер диска
- macOS 13+ использует VirtioFS. Monterey не монтирует VirtioFS; его путь передаёт проверенный XIP по закреплённому SSH и сверяет SHA-1 в госте.
- На существующей 80 GB VM `xip` отказался распаковываться при ~42 GiB свободного места. Фолбэк передал проверенный Xcode.app по SSH без macOS tar metadata; гостевая подпись Apple и точная версия прошли проверку.
- XIP занимает ~10 GB. Кэшированный Xcode.app занимает ~17 GB на хосте; несжатый поток файлов составил ~32 GiB. Готовая 80 GB VM занимает на хосте ~49 GiB.
- Новые macOS 11/12 VM с Xcode получают разреженный виртуальный диск 120 GB. Чистая сборка подтвердила, что XIP распаковывается на нём без фолбэка; готовый новый диск занимает 34,8 GiB на хосте. Существующая 80 GB VM не увеличивалась.
## Legacy-клон и проверки
- `legacy_uuid` допускает APFS encryption at rest при выключенном FileVault и только одного активного worker. Registry publish для этого образа запрещён.
- Первый живой клон не загрузился: Lume поменял `machineIdentifier` и MAC-адрес. Он был удалён. Virfield теперь восстанавливает оба значения из остановленного образа до запуска копии и проверяет наличие скопированного NVRAM. Обычные клоны сохраняют новую идентичность.
- Повторный клон подтвердил Xcode 13.4.1 / 13F100, Swift, SIP, Finder, политику диска, закреплённый SSH, отказ ключу исходного образа, туннель и SCP-артефакт. Второму одновременному legacy worker отказано. После теста исходный образ остался `image_ready`.
- Чистая сборка `macos-12.6-xcode-13.4.1-clean-20261003` завершилась без ручного восстановления: задача `job-ca072dfb3bfee011bd7ee9fcd28d8f46` succeeded, образ `image_ready` и остановлен. Первый запуск через `image-create` был отклонён из-за APFS: эта команда не задаёт `legacy_uuid`; неудачная VM удалена с разрешения пользователя. Повторная сборка использовала профиль в `config.json` с legacy UUID.
- `make check` и `make build` прошли; установленный менеджер обновлён. Подробные результаты — `docs/VERIFICATION.md`; контракт установки — `docs/IMAGE-PIPELINE.md`.