diff --git a/personal/index.md b/personal/index.md index 7d0b1cce..adc71cdd 100755 --- a/personal/index.md +++ b/personal/index.md @@ -1,6 +1,6 @@ --- title: Personal Index -updated: '2026-05-24' +updated: '2026-09-30' type: topic-map tags: - index @@ -10,7 +10,7 @@ tags: > Топик-карта personal/ vault. Поддерживается enrichment воркером (воскресенье 03:00). > **Принцип:** кластеры → hub-note → связанные файлы. Воркер читает эту карту, линкует по ней, дополняет при находке новых кластеров. -> Last updated: 2026-05-24 +> Last updated: 2026-09-30 --- ## 🗒 Списки и задачи @@ -132,6 +132,8 @@ Hub: [[personal/projects/media-pipeline-tracker-parsers|Media Pipeline Roadmap]] ## 🛠 Техническая документация (personal) +- [[personal/projects/virfield|Virfield — macOS VM control plane]] — релиз, статус и каноническая документация. + - [[docker_colima_setup|Docker Colima Setup]] - [[truenas-remote-access-reverse-proxy|TrueNAS Remote Access]] - [[Swift cross-platform testing|Swift Cross-Platform Testing]] diff --git a/personal/plans/balda-callee-prism-plan.md b/personal/plans/balda-callee-prism-plan.md index 18f0704a..10d15530 100755 --- a/personal/plans/balda-callee-prism-plan.md +++ b/personal/plans/balda-callee-prism-plan.md @@ -1,7 +1,8 @@ # Balda + Prism/Beads + Execution Broker + Callee + Codex -> Обновлено: 2026-09-29 -> Статус: целевая архитектура зафиксирована; Broker и интеграции ещё не реализованы. +> Обновлено: 2026-09-30 +> Статус: Virfield v2.0.0 опубликован. Этот план описывает целевую интеграцию Balda → Broker → VM → Runner/Callee; сквозная приёмка ещё не подтверждена. +> Текущий проект и runbook: [[personal/projects/virfield]]. ## 1. Цель @@ -41,32 +42,19 @@ Codex → Prism/Beads + Mattermost ``` -## 2. Что уже есть +## 2. Подтверждённый статус и оставшаяся интеграция -### Подтверждено +Virfield v2.0.0 опубликован: Go daemon, leases/images, аутентифицированные HTTP/MCP, SSH isolation, tunnels и embedded console. Live golden/clone E2E и release CI прошли в объёме [[personal/projects/virfield]]. Установленные сервисы используют deployment вне checkout; публикация нового архива не обновляет runtime автоматически. -1. Balda работает в Docker на Mac и отвечает в Mattermost. -2. Mattermost-сервер остаётся на Kraken; Balda подключается к нему с Mac. -3. Obsidian MCP доступен Balda по `http://host.docker.internal:3101/sse`. -4. Virfield MCP работает на хостовом Mac и умеет подготовить VM: clone golden image, start, wait for IP/SSH, create tunnel. -5. Host Codex и Claude уже подключены к Virfield MCP. +Для полной цепочки остаётся подтвердить: -### Текущая конфигурация Balda +- отдельные deployment и совместимость Execution Broker/Runner; +- доступ Broker к реализованному Virfield HTTP API: TLS/routing, credentials и SSH transport из контейнера; +- запуск Callee и обратный журнал событий до Balda; +- адаптер Balda → Prism/Beads; +- сквозной запуск Story → VM → build/test → отчёт с cleanup. -- основной provider: DeepSeek через OpenAI-compatible API; -- `permissions.mode: allow_all`; -- `workspace.mode: off`; -- Virfield в Balda не подключён; -- Callee CLI и описания агентов находятся в окружении Balda по текущему сетапу, но целевой запуск Callee должен происходить внутри VM. - -### Чего пока нет - -- Execution Broker; -- сетевого API управления Virfield для Broker; -- VM runner для управляемого запуска Callee; -- обратного журнала событий Callee → Balda; -- адаптера Balda → Prism/Beads; -- подтверждённого сквозного запуска Story → VM → build/test → отчёт. +Статус остальных проектов и provider-конфигурация проверяются в их собственных источниках; релиз Virfield не является подтверждением их готовности. ## 3. Владельцы ответственности @@ -119,7 +107,7 @@ Virfield работает на Mac-хосте и владеет жизненны - сетевые туннели; - lease и принудительная уборка VM. -Для Broker нужен узкий аутентифицированный HTTP API или HTTP MCP-обёртка над этими операциями. Произвольного host shell в этом API нет. +Аутентифицированный HTTP API `/api/v1` и HTTP MCP `/mcp` реализованы; daemon слушает loopback. Для Broker остаются проверяемая сетевая доступность и integration contract. Произвольного host shell в API нет. ### Callee и Codex — выполнение внутри VM @@ -323,19 +311,11 @@ Callee поддерживает `Parallel`, но это fan-out Role visits вн Хостовый Virfield API разрешает только операции жизненного цикла VM. Balda и Broker не получают `docker.sock`, пользовательский `~/.ssh` или произвольный shell на Mac. -### Shared folder Lume +### Workspace и артефакты -Lume монтирует shared folder через virtiofs. Изменения содержимого должны появляться динамически; Lume также умеет добавлять folder к уже запущенной VM без reboot/remount. +Текущий recipe Virfield создаёт VM без shared host folders. Код, mutable workspace и Xcode build живут на локальном диске VM; перенос исходников/результатов — через scoped SSH и Git либо `rsync/scp`. Артефакты выгружаются до release lease и получают уникальный путь `run_id/...`. -Для mutable workspace и Xcode build shared folder не считается надёжным источником истины. В текущем Virfield уже потребовались `sudo purge` и уникальные DerivedData snapshots из-за stale guest cache. - -Рабочий контракт: - -- репозиторий клонируется на локальный диск VM; -- обновления передаются через Git или `rsync/scp`; -- shared folder используется для immutable inputs и выгрузки artifacts; -- каждый набор artifacts получает уникальный путь `run_id/...`; -- Xcode не собирает проект непосредственно из `/Volumes/My Shared Files`. +Добавление host mounts потребует отдельного решения по изоляции и проверки согласованности данных; это не часть принятого recipe. ### Изменение других хостов @@ -359,7 +339,7 @@ Lume монтирует shared folder через virtiofs. Изменения с 2. Можно ли запустить workflow pack `prism/story` отдельно от stock plugin host. 3. Как Codex ACP получает workspace/cwd и сохраняет его между Role visits. 4. Как передавать cancel в Callee без повреждения terminal result. -5. Какой минимальный Virfield API можно безопасно открыть Broker. +5. Как подключить Broker к реализованному Virfield API через TLS/routing и проверить lease/SSH contract из его окружения. ### Требует проверки до production @@ -387,63 +367,21 @@ Balda остаётся оркестратором, Broker изолирует и Будущая transport abstraction в `runtime + acpagent` позволит Balda или Callee подключаться к ACP по WebSocket/Streamable HTTP. Она может заменить SSH-транспорт, но не заменяет Broker, VM lifecycle, durable events и cleanup. -## 13. Аудит Virfield и целевая версия v2 +## 13. Virfield v2 — реализовано и опубликовано -### Что существует сейчас +Релиз [v2.0.0](https://github.com/mallexxx/virfield/releases/tag/v2.0.0) опубликован 2026-09-30, commit `ee3aa1d`. Текущая карточка — [[personal/projects/virfield]]; команды и контракты принадлежат документации репозитория. -Virfield — TypeScript/Node.js приложение: +Реализованы единый Go control plane, SQLite journal, reconciliation, leases/idempotency, resource admission, image pipeline, scoped SSH, cleanup, CLI/MCP и embedded console. Лимит двух VM и неизвестные состояния обрабатываются явно; неопределённая мутация не повторяется автоматически. Personal SSH keys/PAT storage и client-side lifecycle fallback в текущей реализации отсутствуют. -- Express + WebSocket backend; -- React/Vite Web UI; -- SQLite; -- отдельный stdio MCP server; -- shell/Python provisioning scripts. - -Web UI уже реализован. TypeScript typecheck проходит. Собственной automated test suite практически нет. - -### Подтверждённые архитектурные проблемы - -1. Состояние VM определяется одновременно Lume API, Lume CLI, SQLite, JSON-файлами, PID и in-memory maps. -2. REST и MCP дублируют orchestration; MCP вызывает REST, а при ошибке обходит его и управляет Lume напрямую. -3. Recovery основан на `pgrep`, `pkill`, PID probing и ручном склеивании stale states. -4. Virfield читает личные SSH keys, имеет password fallback `lume`, хранит GitHub PAT в SQLite и предоставляет широкий `vm_ssh_exec`. -5. Long-running jobs частично живут только в памяти и теряют нормальную управляемость после restart. - -### Решение: переписать control plane, не Lume - -Lume остаётся hypervisor/backend. Проверенные provisioning scripts временно сохраняются как versioned jobs и постепенно заменяются только при наличии тестов. - -Virfield v2 состоит из пяти частей: - -1. `virfieldd` на Go — единственный владелец SQLite, Lume adapter, VM leases, jobs, events и cleanup; запускается через `launchd`. -2. Image Manager — модуль `virfieldd` для download/pull/build/promote golden images; отдельный daemon ему не нужен. -3. Web UI — отдельный API client на embedded HTML/HTMX или простом JavaScript без Node toolchain. -4. `virfield-mcp` на Go — тонкий stdio/HTTP adapter; не обращается к Lume или SQLite напрямую. -5. Execution Broker и Runner на Go — отдельный execution-контур рядом с Balda и внутри workers. - -Один Lume adapter скрывает различия HTTP/CLI. UI, MCP и Broker используют только versioned API `virfieldd`. - -Оценка: Virfield v2 MVP — 7–12 рабочих дней; Broker/Runner — 5–10 дней; UI migration и hardening — ещё 5–8 дней. +Lume остаётся backend; используется закреплённый 0.5.3 с двумя проверенными исправлениями shutdown. Guest automation встроена и версионируется вместе с Go-кодом. Полный golden/clone E2E пройден на одном Mac; Linux/macOS CI и проверки переносимости/секретов прошли для release commit. Точные результаты и непринятый scope — в [Verification](https://github.com/mallexxx/virfield/blob/main/docs/VERIFICATION.md). ### Граница проектов и репозиториев — принятое решение `virfield` и `execution-broker` — два независимых проекта. Их нельзя объединять в один репозиторий или один daemon. -Репозиторий `virfield` содержит только host control plane: +Репозиторий `virfield` содержит host control plane: корневой Go module, `cmd/virfieldd`, `cmd/virfield`, `cmd/virfield-mcp`, `cmd/virfield-lume`, реализации в `internal/`, deployment в `deploy/`. Актуальная карта модулей — [Architecture](https://github.com/mallexxx/virfield/blob/main/docs/ARCHITECTURE.md); отдельного каталога приложения v2 нет. -```text -cmd/virfieldd -cmd/virfieldctl -cmd/virfield-mcp -internal/lume -internal/images -internal/leases -internal/jobs -web/ -api/ -``` - -Новый репозиторий `execution-broker` содержит execution plane: +Целевая структура отдельного `execution-broker` (реализацию сверять в его репозитории): ```text cmd/broker @@ -463,11 +401,9 @@ api/ 1. `virfield` управляет VM, images, leases и host-level cleanup; он ничего не знает о Callee, Prism, Beads и model providers. 2. `execution-broker` выбирает execution class, запускает Runner/Callee, управляет agent profiles и хранит run event log; он не управляет Lume напрямую. 3. `balda` вызывает Broker по MCP и отражает события в Prism/Beads; Virfield напрямую из Balda не вызывается. -4. `execution-broker → virfieldd` использует versioned authenticated HTTP API, описанный OpenAPI. +4. `execution-broker → virfieldd` использует versioned authenticated HTTP API `/api/v1`; текущие модели и маршруты — `internal/domain`, `internal/httpapi`, `internal/client`. Отдельная OpenAPI-спецификация Virfield в v2.0.0 не опубликована. 5. Общих Go-пакетов между репозиториями нет; совместимость обеспечивается API contract и contract tests. -Старый репозиторий/компонент `agents-bridge` не развивается и не переиспользуется для новой системы. Название `execution-broker` выбрано специально, чтобы не смешивать новый scheduler/event broker со старым SSH/MCP-мостом. - ## 14. Agent profiles и модельная политика Broker и Runner не содержат vendor-specific workflow logic. Run выбирает `agent_profile` из статического allowlist. @@ -478,7 +414,7 @@ Worker image содержит Runner, Callee и нужные provider binaries. ### Распределение моделей -Схема `Balda → Callee → coding agent` остаётся правильной. Текущее назначение DeepSeek единственным оркестратором не оптимально: Balda использует один app-scoped provider для всех sessions. +Схема `Balda → Callee → coding agent` остаётся правильной. Provider для Balda и профили исполнителей настраиваются в соответствующих проектах; конкретное назначение не фиксируется в плане Virfield. Рекомендуемая раскладка: @@ -528,27 +464,21 @@ DeepSeek подходит для ограниченного routing и прос ## 16. План реализации -### Этап 1 — live spike контрактов, 1–2 дня +### Этап 1 — live spike интеграционных контрактов -1. Запустить Virfield и Lume и проверить clone/start/stop/delete без fallback paths. -2. Проверить stale-cache сценарии shared folder и зафиксировать Git/rsync contract. +1. **Выполнено для Virfield:** clone/start/stop/delete, SSH readiness и cleanup проверены live; повтор для полного Broker/Runner flow входит в сквозную приёмку. +2. Проверить передачу workspace/artifacts через Git/scoped SSH на локальный диск VM; shared host folders в recipe отсутствуют. 3. Запустить один Callee workflow вручную внутри тестовой VM. 4. Проверить Codex ACP, Human pause/resume, cancel и terminal result. 5. Принять versioned contracts Virfield API и VM Runner. Результат: фактические runtime-контракты без предположений. -### Этап 2 — Virfield v2 core, 7–12 дней +### Этап 2 — Virfield v2 core: завершён 2026-09-30 -1. Реализовать `virfieldd` и единую SQLite job/event model. -2. Реализовать один Lume adapter и reconciliation loop. -3. Добавить leases, idempotency, quotas, audit и cleanup. -4. Подключить существующие image/provisioning scripts как jobs. -5. Реализовать Go CLI/MCP adapters и минимальный Web UI. +Результат опубликован как `v2.0.0`: один владелец VM/images, durable jobs/events, API/CLI/MCP/UI, image automation и проверенная переносимая сборка. Выполненные задачи не остаются в backlog. Непринятые проверки перечислены в [[personal/projects/virfield]] и repository Verification. -Результат: один надёжный владелец VM и images без Node runtime. - -### Этап 3 — универсальный Runner, 2–4 дня +### Этап 3 — универсальный Runner 1. Описать versioned JSON protocol command/event. 2. Реализовать start, events, Human response и cancel. @@ -558,7 +488,7 @@ DeepSeek подходит для ограниченного routing и прос Результат: один протокол запускает workflow в VM или container и возвращает структурированные события. -### Этап 4 — Broker MVP, 3–6 дней +### Этап 4 — Broker MVP 1. Реализовать SQLite schema для runs, events, responses и artifacts. 2. Реализовать state machine и транзакционный event journal. @@ -568,7 +498,7 @@ DeepSeek подходит для ограниченного routing и прос Результат: Balda управляет долговечным run через HTTP MCP. -### Этап 5 — Balda + Prism, 2–4 дня +### Этап 5 — Balda + Prism 1. Подключить Broker MCP к runtime Balda. 2. Развернуть Prism adapter и Dolt/Beads container. @@ -578,7 +508,7 @@ DeepSeek подходит для ограниченного routing и прос Результат: Story ведётся в Beads, выполнение и approvals видны в Mattermost. -### Этап 6 — сквозная приёмка, 1–2 дня +### Этап 6 — сквозная приёмка 1. Создать Story из реального сообщения Mattermost. 2. Пройти specify/design/approval/implement/review/verify. @@ -588,7 +518,7 @@ DeepSeek подходит для ограниченного routing и прос Результат: воспроизводимый end-to-end прогон без исполнения агентских команд на хосте. -Оценка после spike: рабочий end-to-end MVP — 17–30 рабочих дней. Срок сильнее всего зависит от Callee machine API, Lume reconciliation и переноса Web UI. +Срок оставшихся этапов определяется после сверки текущего Broker/Runner и проверки Callee/Prism контрактов. ## 17. Критерии готовности @@ -603,7 +533,6 @@ DeepSeek подходит для ограниченного routing и прос ## Связанные заметки +- [[personal/projects/virfield]] — текущий релиз, подтверждённый scope и каноническая документация. + - [[personal/tech/callee-prism]] — контракты Callee, ACP и Prism. -- [[personal/tech/agents-bridge]] — предыдущий мост; не часть целевой схемы. -- [[personal/tech/balda-executor-mcp]] — предыдущий исполнитель; не часть целевой схемы. -- [[personal/plans/balda-mm-phase4-agents]] — история предыдущей интеграции. diff --git a/personal/projects/hermes-configs/eagle-config.example.yaml b/personal/projects/hermes-configs/eagle-config.example.yaml index 8a5f2c6b..5ba32fc8 100755 --- a/personal/projects/hermes-configs/eagle-config.example.yaml +++ b/personal/projects/hermes-configs/eagle-config.example.yaml @@ -1,6 +1,7 @@ # Hermes Eagle — example config (tokens redacted) # Source: ~/.hermes/config.yaml -# Copy back: cp this ~/.hermes/config.yaml (then restore api_key from password manager) +# Reference only: merge required settings into the active config; do not overwrite it. +# Virfield entry updated 2026-09-30; replace placeholders before use. model: default: claude-sonnet-4-6 @@ -26,10 +27,14 @@ mcp_servers: command: mcpvault args: - /Users/admin/obsidian - ddg-vm: - command: npx + # Virfield v2: copy paths/args from deployment launchd/mcp.json. + # Replace /ABSOLUTE/DEPLOYMENT; no token values belong in this example. + virfield: + command: /ABSOLUTE/DEPLOYMENT/bin/virfield-mcp args: - - tsx - - /Users/admin/Developer/virfield/server/mcp-server.ts + - -url + - http://127.0.0.1:7780 + - -token-file + - /ABSOLUTE/DEPLOYMENT/token # zulip / api keys — restored from password manager diff --git a/personal/projects/personal-os/eagle-dashboard.md b/personal/projects/personal-os/eagle-dashboard.md index aba0eaa9..c06b6c2d 100755 --- a/personal/projects/personal-os/eagle-dashboard.md +++ b/personal/projects/personal-os/eagle-dashboard.md @@ -108,7 +108,7 @@ PID-file-based — survives Dashboard restarts without crashing. | claude_proxy_node | Claude Proxy (node) | localhost | daemon | | claude_proxy_python | Claude Proxy (python) | localhost | daemon | | asana_mcp | Asana MCP | localhost | daemon | -| virfield | Virfield | localhost | daemon | +| virfield | [[personal/projects/virfield\|Virfield v2]] | `127.0.0.1:7780` by default | separate system LaunchDaemons; dashboard integration not verified | ### ML @@ -328,7 +328,7 @@ When a launchd cron is created and `launchctl print gui//