--- 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-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 на ``). Кандидат на откат к строгому 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`.