Merge remote-tracking branch 'origin/main'

2026-10-15 09:50:37 +00:00
commit 2b3d52971e
@@ -0,0 +1,222 @@
+---
+title: iPad iOS 9.3.5 — сборка редакторов, fake sign и деплой
+created: '2026-10-14'
+updated: '2026-10-15'
+tags: [ipad, ios, markdown, virfield, build, deploy]
+---
+# iPad iOS 9.3.5 — сборка редакторов, fake sign и деплой
+
+Запрос: checkout найденных открытых редакторов в `~/Developer`, сборка на Virfield/Monterey, fake sign и установка на физический iPad. **Edhita, Notepad Example, официальный iVim 1.40 и legacy GitJournal собраны, fake-signed, установлены и запущены на iOS 9.3.5; экраны всех четырёх приложений проверены.** GitJournal потребовал local compatibility patch, описанный ниже. Fork holzschu требует 32-bit rebuild зависимостей и не установлен. Проверенный SSH-доступ к iPad настроен 2026-10-15 через `ssh-copy-id` после явного указания пользователем пароля. Все артефакты и diagnostics экспортированы; по отдельному запросу пользователя рабочая Monterey VM штатно released, её отсутствие в runtime подтверждено. Готовый golden сохранён.
+
+## Устройство и доступ
+
+Проверено через libimobiledevice 2026-10-14:
+
+- Модель `iPad2,5`: iPad mini первого поколения, 32-bit ARM (`armv7`).
+- iOS `9.3.5`; имя `iPad (Alexey)`.
+- UDID `3a214de4ad222863b82458f3611ad6b7b53eb05f`.
+- `idevice_id -l` в обычном sandbox возвращает `Unable to retrieve device list`; вне sandbox устройство видно по USB и как network device.
+- Локальный USB SSH-туннель: `iproxy -u 3a214de4ad222863b82458f3611ad6b7b53eb05f 2235:22`.
+- SSH-сервер устройства: `OpenSSH_6.7`, host-key algorithms `ssh-rsa,ssh-dss`. Современный клиент без compatibility flag не согласует host key.
+- Host key закреплён в `~/Developer/ipad-editors/ipad-known-hosts`; RSA fingerprint `SHA256:sl+pEjLygox+shHazV2JnzKGvvRFeiTbpx3ZevgT2Kk`.
+- Первоначально `~/.ssh/id_rsa` (`SHA256:UZ8oPNIe8z2bvBOhWQRyt+JWi99oqQnP8N5XAAm5Uhs`) отклонялся для `root` и `mobile`: этот ключ ещё не был установлен. 2026-10-15 пользователь явно предоставил пароль и попросил `ssh-copy-id`; команда добавила один public key, затем вход `root` с `BatchMode=yes` без пароля прошёл. Первая password-сессия оборвалась `Broken pipe`; повторная завершилась exit 0.
+- Ранее automatic approval review отклонил password probe и privileged AFC2 поиск authorized_keys до исполнения. Это исторический approval blocker, снятый новым явным запросом пользователя на парольный вход и установку ключа. Пароли и private keys здесь не хранятся.
+
+Фактически исполненная установка ключа (пароль вводится в интерактивный prompt):
+
+```sh
+ssh-copy-id -i "$HOME/.ssh/id_rsa.pub" -p 2235 \
+  -o HostKeyAlgorithms=ssh-rsa -o PubkeyAcceptedAlgorithms=ssh-rsa \
+  -o StrictHostKeyChecking=yes \
+  -o UserKnownHostsFile="$HOME/Developer/ipad-editors/ipad-known-hosts" \
+  root@127.0.0.1
+```
+
+Проверенный вход по ключу:
+
+```sh
+ssh -p 2235 -i "$HOME/.ssh/id_rsa" \
+  -o IdentitiesOnly=yes -o BatchMode=yes \
+  -o HostKeyAlgorithms=ssh-rsa -o PubkeyAcceptedAlgorithms=ssh-rsa \
+  -o StrictHostKeyChecking=yes \
+  -o UserKnownHostsFile="$HOME/Developer/ipad-editors/ipad-known-hosts" \
+  root@127.0.0.1 'uname -a'
+```
+
+Через SSH подтверждены `/usr/bin/appinst`, `/usr/bin/ldid`, `/usr/bin/uicache`, `/usr/bin/uiopen`; тестовые IPA установлены ниже через USB installation_proxy. Обычный `id` в окружении iPad отсутствует, поэтому для smoke check использован `uname`.
+
+## Checkouts
+
+Все пять source checkouts скачаны в `~/Developer/ipad-editors/`. Публичные исходники Editorial, 1Writer, Textastic, Working Copy и самого приложения Git2Go не найдены; Git2Go website repository не является приложением и не подменяет его исходники.
+
+| Checkout | Закреплённая ревизия | Проверенные требования и ограничения |
+|---|---|---|
+| [Edhita](https://github.com/tnantoka/edhita/tree/8614a583f765b0f73d3e4c7d150e8d44a9137dbe) | `8614a583f765b0f73d3e4c7d150e8d44a9137dbe` | Исходники 2.3.0, iOS 9.0, Swift 5; файловый редактор с Markdown preview. Ветка `uikit` на HEAD уже требует iOS 10.0. CocoaPods зависимости закреплены старым Podfile.lock. |
+| [iVim / holzschu](https://github.com/holzschu/iVim/tree/f0d6dbceb7900ff6eb122691114a64a64cd9a580) | `f0d6dbceb7900ff6eb122691114a64a64cd9a580` | iOS 9.1, Swift 5; полноценный Vim, document picker и shell-команды через ios_system. В checkout отсутствуют Frameworks; upstream get_frameworks.sh указывает ios_system 2.4, Python/Lua dependencies нужно закрепить и проверить armv7. |
+| [Notepad](https://github.com/ruddfawcett/Notepad/tree/8ae529d831380e203029381a7b1eccad68701fda) | `8ae529d831380e203029381a7b1eccad68701fda` | MIT Markdown editor component и Example app. Исходные Xcode targets задают 10.1; override 9.3 проверен успешной сборкой и запуском на iPad 9.3.5. Demo открывает встроенный tests.md, не является готовым browser для Obsidian vault. |
+| [GitJournal](https://github.com/GitJournal/GitJournal/tree/50dfb2d4ea2b8f00f9e5938e682970e53981ae84) | `50dfb2d4ea2b8f00f9e5938e682970e53981ae84` | Исторический 1.76.0+10 непосредственно перед повышением minimum iOS до 10.0. Runner, Podfile и AppFrameworkInfo.plist задают iOS 9.0; нужен Flutter >=2.0.3 с Dart >=2.12 и <3.0. Markdown + встроенный Git sync. Latest checkout требует iOS 11 и не подходит. |
+
+Дополнительно найден и скачан официальный [terrychou/iVim](https://github.com/terrychou/iVim/tree/d6aaa3c8cd620f035209776f5cc998e7b2da5d5f), checkout `~/Developer/ipad-editors/iVim-upstream`, revision `d6aaa3c8cd620f035209776f5cc998e7b2da5d5f` (2018-09-29, 1.40). Targets задают iOS 9.1; внешних frameworks в проекте нет. На Monterey/Xcode 13.4.1 с override `SWIFT_VERSION=4.0`, `ARCHS=armv7`, minimum 9.3 компиляция завершилась `BUILD SUCCEEDED`; приложение установлено и запущено.
+
+Форк holzschu: скачан официальный `ios_system` v2.4 `release.tar.gz`, SHA-256 `17e220bc4bd89745105f037edcbb37ce445b44b9154d207c882352ce02cc6af4`. `lipo -archs` показал `ios_system.framework` armv7+arm64, но `lua_ios.framework` и `libctags.dylib` — только arm64. Заявленный minimum iOS 9.1 не доказывает поддержку 32-bit в этих бинарных зависимостях. Upstream getPackages.sh также собирает Python/ZeroMQ с arm64 и iOS 11/12; он не запускался.
+
+[Flutter removed 32-bit iOS after the 2.10 stable cycle](https://github.com/flutter/flutter/issues/97327). Для GitJournal нельзя брать текущий Flutter; наличие deployment target 9.0 само по себе не доказывает armv7 в каждом готовом framework.
+
+## Virfield: исходный блокер и его восстановление
+
+Прочитаны installed `virfield_help`: workflows, verification, operations. Верифицированный template `monterey-xcode-13.4.1`: macOS 12.7.6 / 21H1320, Xcode 13.4.1 / 13F100, golden в `samsung-tart`.
+
+Запросы сохранены локально:
+
+- `~/Developer/ipad-editors/virfield-acquire.json`: default storage; отклонён `resource_exhausted`.
+- `~/Developer/ipad-editors/virfield-acquire-release-check.json`: explicit internal storage; принят, но clone не подтверждён.
+- Identity только для этой аренды: `~/.local/share/virfield-identities/ipad-editors-20261014-attempt-1/`; private key не хранится в Git/vault.
+- Lease `lease-9e65ca2f956c0f061eb3ac021d9f6b6f`, VM `vf-9e65ca2f956c0f061eb3ac021d9f6b6f`, job `job-ee57f1c483518f251f1bcd095621e6e9`.
+- Job `needs_attention` / `clone_outcome_unknown`; lease `quarantined`. Последний status не показывает физическую VM с этим именем, но reservation остаётся. SSH configuration не создавалась: lease не ready.
+
+Причина и диагностические недостатки записаны в [[personal/projects/virfield]]. Local Tart golden нельзя клонировать в другой TART_HOME; явный cross-container destination был принят admission, затем отклонён backend. Требуется штатное operator recovery с подтверждением точного имени, без обхода journal. Recovery может удалить VM навсегда — отдельное подтверждение пользователя обязательно.
+
+После восстановления использовать свободное место в исходном `samsung-tart`, либо создать отдельный verified Monterey/Xcode golden непосредственно в internal `release-check` и клонировать уже его в том же контейнере. Чужую macos27 lease не останавливать и не удалять.
+
+Этот исходный lease уже `released` после отдельно разрешённого recovery. Новый verified golden `ipad-editors-monterey-xcode-1341-20261014` создан в `release-check`, image `image-f8c888fcafbd1a2df2a3b9a02821685d`, macOS 12.7.6 / Xcode 13.4.1. Новая lease `lease-327bb8e4a3a06b7d5ac8e527c57d1907` прошла ready и реально собрала две apps. С 17:57:04 UTC 2026-10-14 она `needs_attention` / `vm_drift`: manager закрыл tunnel `127.0.0.1:60131`. Последний inventory при этом показывает VM running на прежнем `192.168.64.251`. Recovery новой VM требует отдельного разрешения пользователя; старое разрешение относилось только к `vf-9e65…`. Подробности в [[personal/projects/virfield]].
+
+## Процедура сборки и деплоя
+
+1. Получить job `succeeded` и lease `ready`, затем создать pinned SSH config через установленный Virfield CLI. Проверить `sw_vers`, `xcodebuild -version`, `xcrun --sdk iphoneos --show-sdk-version` в госте. Не работать на golden.
+2. Передать checkouts/зафиксированные зависимости в guest `~/workspace`; сохранить SHA исходников и полный build log отдельно для каждого приложения.
+3. Для Xcode targets использовать `-sdk iphoneos -configuration Release -destination generic/platform=iOS`, `ARCHS=armv7`, `ONLY_ACTIVE_ARCH=NO`, `IPHONEOS_DEPLOYMENT_TARGET=9.3`, `CODE_SIGNING_ALLOWED=NO`, `CODE_SIGNING_REQUIRED=NO`, `ENABLE_BITCODE=NO`. Edhita требует `pod install` с закреплёнными версиями и template AppSecret; fork iVim — старые frameworks; Notepad — app scheme `Example` (scheme `Notepad` собирает только framework). GitJournal требует старый Flutter и lockfiles. `~/Developer/ipad-editors/build-native-on-monterey.sh` реально собрал Notepad и iVim-upstream; отдельный helper GitJournal до компиляции не дошёл.
+4. Экспортировать .app/IPA на Mac до окончания lease; проверять `lipo -archs` у executable и всех вложенных Mach-O: должен присутствовать `armv7`. Проверить minimum OS <=9.3.5, UIDeviceFamily включает 2, итоговые bundle IDs, отсутствие обязательной arm64 capability. Подписывать вложенные dylib/framework/appex до основного executable.
+5. Fake sign выбранным совместимым `ldid`, проверить signature/entitlements; сформировать IPA с `Payload/<App>.app` и SHA-256. `codesign -s -` без проверки совместимости старого устройства не считать проверенным эквивалентом.
+6. Перед установкой прочитать список installed bundles: существующий экземпляр с пользовательскими документами не удалять/перезаписывать без подтверждения. Для этой сессии отсутствие обоих target bundles подтверждено до install; ранее установленные приложения сохранены. Для установки fake-signed IPA проверен USB `ideviceinstaller`; наличие рабочего SSH не требуется этому маршруту.
+7. Передать IPA, вызвать доступный installer, проверить его exit code и появление bundle. При disconnect сначала прочитать состояние устройства, затем решать о повторе. Обновить icon cache, запустить по bundle ID доступным launcher и проверить работающий процесс/экран. Installer success не доказывает launch или редактирование.
+8. Сохранить результат отдельно для build, fake sign, install, launch, Markdown editing; дополнить эту заметку фактическими командами и логами. Освободить только собственную lease после экспорта и явного разрешения cleanup.
+
+Fake signer source: [ProcursusTeam/ldid](https://github.com/ProcursusTeam/ldid/tree/af86971ae72ec3ed3d0a699107c4e882324c941b), checkout `~/Developer/ipad-editors/ldid`, ревизия `af86971ae72ec3ed3d0a699107c4e882324c941b`. Это вспомогательный host tool. Бинарник собран на локальном Mac (`make -j4`), версия `v2.1.5-procursus7-23-gaf86971`, Mach-O arm64, SHA-256 `f36d613b2fb6e245f99bef8373844e7fa6c97a2f82059faadc74dcbcc90c9458`. Подпись с `-Hsha1` реально проверена на двух armv7 apps: embedded entitlements прочитаны обратно, USB install и launch прошли.
+
+## Связь с Obsidian sync
+
+На Mac `~/scripts/sync-vault.sh` уже запускается `launchd` `com.sync-vault` каждые 300 секунд; текущий daemon state подтверждает StartInterval. Remote скрипта — `nas`, не GitHub. Редактирование серверных .md через SFTP может использовать этот существующий синк; прямому iPad GitJournal/Working Copy потребуется собственный remote. Обычный iOS-app sandbox не даёт cron для Bash/Git; на jailbroken устройстве daemon/launchd и системные Git/Bash требуют отдельной настройки. Запрос на cron пока был исследовательским: существующие расписания не менялись.
+
+Read-only проверка после вопроса пользователя 2026-10-15: iPad уже имеет `/bin/bash` (4.0.x), `/bin/sh`, `/bin/launchctl`, `/usr/bin/ssh`, dpkg. **Git, cron/crontab, basename, head и tr отсутствуют** в штатном PATH; date/sed/mkdir доступны. Поэтому собственный скрипт синка возможен, но Mac wrapper/library нельзя просто скопировать и объявить работающим: нужны совместимый armv7 Git и недостающие core utilities либо их замена в скрипте. Расписание можно сделать launchd, как на Mac. Vault нужно хранить в директории, которую открывает выбранный редактор (например его Documents), запускать синк с согласованными permissions/mobile user и отдельным клиентским SSH key к remote. Mac→iPad key, установленный выше, не является ключом iPad→NAS/GitHub. Планировщик, пакеты Git и реальный vault на iPad в этой сессии ещё не настраивались; вопрос был о возможности, не отдельным поручением менять синк.
+
+См. также [[personal/how-to/old-ipad-ios935-ipa-sources]], [[family/how-to/vault-git-sync]].
+
+## Исторический checkpoint 2026-10-14 22:40 Asia/Bishkek
+
+- Explicitly authorized recovery завершился успешно: cleanup `job-1fe239f3064566b2a4b3f75ebce13813`; старый lease освобождён. Новый образ `ipad-editors-monterey-xcode-1341-20261014` строится непосредственно в internal `release-check`, image `image-f8c888fcafbd1a2df2a3b9a02821685d`, job `job-076452fa609adc3e6d4093a8e047a693`. См. [[personal/projects/virfield]].
+- Host `ideviceinstaller` 1.2.0 установлен через Homebrew. Проверена штатная USB-служба: `ideviceinstaller -u 3a214de4ad222863b82458f3611ad6b7b53eb05f list -a CFBundleIdentifier -a CFBundleDisplayName -a CFBundleVersion` завершился exit 0 и вернул installed bundles. Ни один bundle редакторов ещё не установлен. Для install синтаксис этой версии: `ideviceinstaller -u UDID install PATH.ipa`; installer success нужно дополнительно сверить со списком приложений и запуском. Наличие SSH для этого USB-маршрута не требуется; возможность установки fake-signed IPA ещё не проверена.
+- Поиск отпечатков public authorized_keys через privileged AFC2 отвергнут automatic approval review ДО исполнения как credential probing without specific authorization. AFC2-команда не выполнялась. Используется обычная USB installation_proxy без чтения privileged SSH files.
+- Flutter 2.10.5/Dart 2.16.2 x64 SDK скачан с официального Google archive и совпал с published SHA-256 `cc3b48d864c5863898246b8f8e602489cc8e2e77098db27ef3484a25162e1c80`; размер 1,181,514,897 bytes. На ARM Monterey worker этому историческому host SDK нужен Rosetta. Это подготовка инструмента, не подтверждение сборки GitJournal.
+
+## Проверенные команды и результаты, 2026-10-15
+
+Guest workspace: `/Users/admin/ipad-editor-build/ipad-editors`. Источники переданы как git archives с `SOURCE_REVISION`; private keys в архив не включались. Guest toolchain в exported `toolchain.txt`: macOS 12.7.6, Xcode 13.4.1 / 13F100, iPhoneOS SDK 15.5.
+
+В ready worker фактически выполнено:
+
+```sh
+cd /Users/admin/ipad-editor-build/ipad-editors
+bash build-native-on-monterey.sh Notepad
+bash build-native-on-monterey.sh iVim-upstream
+```
+
+Products и полные build logs экспортированы на Mac в `/Users/admin/Developer/ipad-editors/exported-editors/`. Оба `build.log` содержат `BUILD SUCCEEDED`. Helper выбирает `Example` и `iVim` schemes, выключает Apple signing/bitcode, задаёт armv7 / minimum 9.3. Для upstream iVim установлен Swift language mode 4.0. Изменений исходного кода этих двух приложений для сборки не понадобилось.
+
+Host packaging использует `/Users/admin/Developer/ipad-editors/package-fake-signed.py`. Он копирует original .app, проверяет minimum OS всех Mach-O, требует armv7, удаляет прочие slices только в копии, подписывает nested binaries SHA1, затем main/extension с entitlements, читает entitlements обратно и создаёт IPA с сохранёнными Unix permissions/symlinks. Для iVim сохранены source entitlements/app group; `IPADLOCAL9` — локальный fake team, работоспособность iCloud не проверена.
+
+```sh
+cd /Users/admin/Developer/ipad-editors
+python3 package-fake-signed.py exported-editors/Notepad/Example.app \
+  packages/Notepad-20261014
+python3 package-fake-signed.py exported-editors/iVim-upstream/iVim.app \
+  packages/iVim-upstream-20261014 \
+  --entitlements iVim-upstream/iVim/iVim.entitlements
+```
+
+Output directory должен быть новым: helper отказывает при существующем каталоге. Уже созданные пакеты повторно не перезаписывать.
+
+| App | IPA и SHA-256 | Install / launch |
+|---|---|---|
+| Notepad Example | `packages/Notepad-20261014/Example.ipa`; `835431ecb821d996b932e523fe32188f21b82fecab4808a6536a0fe0975c4748` | `com.ruddfawcett.Example`, minimum 9.3; USB install Complete / exit 0; process 3355, UI с Markdown test document виден на screenshot |
+| iVim 1.40 | `packages/iVim-upstream-20261014/iVim.ipa`; `e2b67b451b11defb30fd8ba1d64a5f3e898a3010be14c3f451f41dfe12b6c777` | `com.terrychou.ivim`, minimum 9.3; USB install Complete / exit 0; process 3366, Vim welcome screen и клавиатура видны на screenshot |
+| Edhita 2.3.0 | `packages/edhita-20261015/Edhita.ipa`; `f354872cc0e4596dca82903f0741ccf0204242befd3400e54fabcc1ef09a8aea` | `com.bornneet.Edhita`, minimum 9.3; USB install Complete / exit 0; detached debug launch exit 0, UI с Documents browser/Editor/Browser/Dual виден на screenshot |
+| GitJournal 1.76.0+10, local legacy build | `packages/GitJournal-20261015/Runner.ipa`; `5dc474f641cb26e64586b8f1c48ee6520c0dd7797e53a6ab59ee721e098f7a52` | `io.gitjournal.gitjournal`, build10, minimum9.3; USB install Complete / exit0; detached launch exit0, onboarding UI показан на screenshot |
+
+Установлен `ideviceinstaller` 1.2.0. До install отсутствие обоих bundle IDs проверено; другие приложения/документы не удалялись. Исполненные команды:
+
+```sh
+UDID=3a214de4ad222863b82458f3611ad6b7b53eb05f
+ideviceinstaller -u "$UDID" list -a CFBundleIdentifier
+ideviceinstaller -u "$UDID" install \
+  /Users/admin/Developer/ipad-editors/packages/Notepad-20261014/Example.ipa
+ideviceinstaller -u "$UDID" install \
+  /Users/admin/Developer/ipad-editors/packages/iVim-upstream-20261014/iVim.ipa
+ideviceinstaller -u "$UDID" list -b com.ruddfawcett.Example -a MinimumOSVersion
+ideviceinstaller -u "$UDID" list -b com.terrychou.ivim -a MinimumOSVersion
+```
+
+Первый запуск через debugserver не прошёл без Developer Disk Image. Затем скачан [9.3 device support mirror](https://github.com/filsv/iOSDeviceSupport/tree/master/9.3): архив `dependencies/ios-device-support-9.3.zip`, SHA-256 `46dc58f181de29853c72c391d70e51b03a3c38ee8797365e7557a539ddff6276`. Git blob архива сверён с `81d23af3e57472f4e77222acb02fd6b5a6a529b1`. Это проверка неизменности mirror, не независимая Apple attestation. `DeveloperDiskImage.dmg` с accompanying `.signature` смонтирован на iOS 9.3.5 со статусом Complete:
+
+```sh
+ideviceimagemounter -u "$UDID" \
+  /Users/admin/Developer/ipad-editors/dependencies/ios-device-support-9.3/9.3/DeveloperDiskImage.dmg \
+  /Users/admin/Developer/ipad-editors/dependencies/ios-device-support-9.3/9.3/DeveloperDiskImage.dmg.signature
+idevicedebug -u "$UDID" run com.ruddfawcett.Example
+idevicedebug -u "$UDID" run com.terrychou.ivim
+```
+
+Обычный `run` держит debugger connection; проверенный в installed help вариант для самостоятельной работы приложения — `idevicedebug -u "$UDID" --detach run BUNDLEID`. Screenshot service после DDI также заработал:
+
+```sh
+idevicescreenshot -u "$UDID" /Users/admin/Developer/ipad-editors/Notepad-first-launch.png
+idevicescreenshot -u "$UDID" /Users/admin/Developer/ipad-editors/iVim-first-launch.png
+```
+
+Оба screenshots просмотрены. Raw orientation landscape повернута относительно PNG; UI присутствует. В launch log есть предупреждения jailbreak tweak HMX_UIKit о недоступном notification window/keyboard method; запуску они не помешали, tweaks не менялись. Notepad — демонстрация editing component без готового vault browser. iVim — полноценный Vim. Сохранение изменённой заметки, подключение реального vault и Git sync отдельно не тестировались.
+
+### Исторические блокеры зависимостей (исходный worker)
+
+- **Edhita:** native ARM Ruby 2.6 / FFI падал `Bus Error` на Ethon/CocoaPods; отдельный x86_64 Ruby/CocoaPods через Rosetta загрузился успешно. `pod install --deployment` отказал из-за spec checksum/repo metadata и версии CocoaPods 1.6.1 → 1.11.3; полученных новых версий PODS в этом запуске не обнаружено. На host helper исправлен на обычный `pod install` с сохранением before/after lock и обязательным сравнением массива PODS. Последний перенос исправления в guest не прошёл, потому что Virfield tunnel уже закрыт. Xcode compile Edhita не состоялся.
+- **GitJournal:** verified Flutter 2.10.5 действительно содержит armv7 Release framework с minimum iOS 9.0; запуск SDK через Rosetta прошёл. Automatic Flutter version check зависал на upstream git fetch; helper использует документированный `--no-version-check`. Native `ios-libraries` v1.1 скачаны с pinned archive SHA-256 `54d788da33397bd923b773f2041d0249b28682446eabf98046bec089eaf025c3`; все четыре static archives содержат armv7. `git_bindings` pinned `52a9def…` также подготовлен. `flutter pub get` остановился на недоступном публично `GitJournal/ext_storage` (GitHub API 404). Host pubspec изменён на опубликованный `ext_storage: 1.0.3`, но transfer в guest не прошёл; этот fallback ещё не проверен сборкой. Plugin Android-only, поэтому его platform-specific usage нужно проверить. Компиляция/деплой/Git sync GitJournal не заявляются успешными.
+- **iVim / holzschu:** готовые Lua/ctags зависимости только arm64; полный fork не собран для armv7. Upstream get-frameworks/Python build scripts с изменчивыми refs и iOS 11/12 не запускались. Для полноценного fork требуется отдельная подготовка совместимых 32-bit зависимостей; официальный iVim 1.40 установлен как дополнительный найденный редактор.
+
+Состояние и пути артефактов также сохранены в `/Users/admin/Developer/ipad-editors/manifest.json`. Исторический blocker `lease-327bb8…` снят разрешённым recovery, cleanup `job-5cb66a109f395c15cd51633ab858bee7` succeeded 18:15:12 UTC 2026-10-14. Replacement `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea` ready, prepare `job-b47d43f833f4bc28e4ec880f8fa40b00` succeeded; pinned tunnel `127.0.0.1:55530`, отдельные `worker-replacement-ssh.conf`/known-hosts и caller identity attempt-3. Не запускать команды через direct-IP в обход Virfield journal.
+
+На replacement реально выполнен `build-native-on-monterey.sh edhita`, RUN_ID `20261015T001900Z`: `BUILD SUCCEEDED`, before/after массив PODS одинаков. Полный export `edhita-export-20261015.tar.gz` сохранён на Mac. Fake-sign helper проверил armv7 main minimum 9.3, Swift dylibs minimum 7.0; `ideviceinstaller install packages/edhita-20261015/Edhita.ipa` завершился Complete, bundle metadata сверена, `idevicedebug --detach run com.bornneet.Edhita` завершился exit 0. Screenshot `Edhita-first-launch.png` просмотрен и показывает редактор и файловый browser. Изменённой пользователем заметки ещё нет; запись/редактирование vault отдельно не проверены.
+
+GitJournal на replacement: опубликованный ext_storage 1.0.3 успешно разрешился. Затем выявлено противоречие upstream: Dart firebase_analytics 8.0.0 требует более высокий minimum iOS, несмотря на Runner9.0 и native lock6.33.0. Выбраны точные firebase_analytics6.2.0 / firebase_core0.5.2 из исторического iOS lock; это local compatibility patch. При пере-resolve незакреплённый dart-git HEAD перешёл на современный Dart3 и нарушил old SDK2.16.2. Все четыре git dependencies теперь явно pin к исходным resolved-ref (`4e47b63…`, `52a9def…`, `d7bfaa69…`, `2e2da41…`). Эти изменения находятся в host `GitJournal/pubspec.yaml` и переданы guest. Дальнейший результат компиляции пока ожидается.
+
+Позднейшая проверка old Firebase6 выявила quiver2/quiver3 conflict с dart-git. **Final compatibility patch отключает optional Firebase analytics**: dependency удалена, `Analytics` сохраняет API с no-op Firebase methods и disabled collection, ссылка на отсутствующий публично `GoogleService-Info.plist` убрана из PBX. Actual pub get теперь успешно завершён (8.8s), native CocoaPods/build продолжается. Это локальная iOS9-сборка с изменениями в трёх source files, не утверждение неизменного upstream binary. Markdown/Git implementation сохранён.
+
+### GitJournal: итоговая успешная сборка и установка
+
+Следующий compiler pass выявил три ошибки: отсутствующий generated `lib/.env.dart`, removed `Platform.packageRoot` у platform3.0.0 на Dart2.16, несовместимый PointerEvent callback у photo_view0.11.1 на Flutter2.10. Исправлено:
+
+- `platform: 3.1.0`, `photo_view: 0.13.0` — официальные pub.dev packages с SDK >=2.12 <3; API photo_view customChild, используемый приложением, сохранился. Versions/compatible callback проверены по опубликованному archive source.
+- Helper исполняет просмотренный upstream `scripts/setup_env.dart` с `SENTRY_DSN=''`, генерируя пустой локальный config; настоящие credentials не искались. Sentry endpoint не задан.
+- All four Git dependency refs явно закреплены из original lock; `ext_storage` взят с pub.dev1.0.3. Firebase analytics отключён. Final Dart/iOS lockfiles скопированы в host checkout.
+
+Final pass `RUN_ID=20261015T003500Z` завершился **BUILD SUCCEEDED**, SDK15.5, ARCHSarmv7, target9.3, Apple codesigning disabled. Archive `gitjournal-export-20261015.tar.gz` экспортирован на Mac; directory `exported-editors/GitJournal` содержит app, build/dependency/configure logs, exact revisions/toolchain/Flutter version, used lockfiles, generated PBX/scheme, empty env и `compatibility.patch`. Различия tracked source включают два final lockfiles и три source files; оригинальная revision50dfb2d сохраняется отдельно.
+
+```sh
+python3 /Users/admin/Developer/ipad-editors/package-fake-signed.py \
+  /Users/admin/Developer/ipad-editors/exported-editors/GitJournal/Runner.app \
+  /Users/admin/Developer/ipad-editors/packages/GitJournal-20261015 \
+  --entitlements /Users/admin/Developer/ipad-editors/GitJournal/ios/Runner/Runner.entitlements
+ideviceinstaller -u "$UDID" install \
+  /Users/admin/Developer/ipad-editors/packages/GitJournal-20261015/Runner.ipa
+ideviceinstaller -u "$UDID" list -b io.gitjournal.gitjournal \
+  -a CFBundleIdentifier -a CFBundleDisplayName -a MinimumOSVersion -a CFBundleVersion
+idevicedebug -u "$UDID" --detach run io.gitjournal.gitjournal
+idevicescreenshot -u "$UDID" /Users/admin/Developer/ipad-editors/GitJournal-first-launch.png
+```
+
+Fake-sign verification проверил **49 Mach-O**: все armv7, minimum7.0 /9.0 /9.3, main/extension entitlements прочитаны обратно. Отсутствие target bundle перед install подтверждено; install Complete/exit0, metadata io.gitjournal.gitjournal /GitJournal /9.3 /10. Detached launch exit0, screenshot просмотрен: GitJournal onboarding `An Open Source Note Taking App built on top of Git`, кнопки Skip/Next. Это проверка запуска, а не реального remote sync: vault, account, clone/push и iCloud/ShareExtension отдельно не тестировались.
+
+Все оставшиеся worker diagnostics и exact x86_64 Gemfile.lock также экспортированы в `diagnostics-20261015.tar.gz` / `exported-diagnostics`. Процесс сборки/деплоя закончен для четырёх совместимых вариантов; full fork holzschu остаётся архитектурно несовместимым с mini1 в имеющемся бинарном dependency наборе.
+
+После явного поручения пользователя «Monterrey релизь если больше не нужен» выполнен release только `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea`, idempotency `ipad-editors-release-20261015-9c1a94ff`. Cleanup `job-efbdecc8f058d3b33ab55a2e03c2b448` succeeded в 2026-10-14T18:51:19.492842Z; lease released, runtime не содержит этой VM. Golden image-f8c888… остаётся image_ready. Final reproducible source payload `worker-input-final-20261015.tar.gz` содержит все compatibility patches; Flutter SDK архив хранится отдельно. Дополнительных release/recovery вне собственной Monterey VM не выполнялось.
+
+## Обновление: vault sync настроен 2026-10-15
+
+После отдельного поручения пользователя настроен native Git2.8.1→TrueNAS bare SSH→launchd300s клиент от mobile, vault в Documents Edhita/ObsidianVault. Dedicated Ed25519 key ограничен exact vault Git operations и persisted в TrueNAS user settings. Actual push iPad→NAS и automatic pull NAS→iPad подтверждены; два последовательных scheduled ticks прошли exit0, позднейший третий также ok. Isolated native tests подтвердили offline сохранение/retry и stale empty lock recovery. Обработка конфликтов приведена к Mac-скрипту 2026-10-15: маркеры с обеими версиями коммитятся с `review needed` и пушатся; следующий синк и возобновление прерванного merge проверены на iPad. Folder виден в Edhita. Это заменяет прежний build-only checkpoint о ненастроенном синке; собственного GitJournal remote эта настройка не касается. Полная актуальная инструкция: [[personal/how-to/ipad-vault-sync]].
@@ -0,0 +1,77 @@
+---
+title: iPad — Obsidian vault sync
+created: '2026-10-15'
+updated: '2026-10-15'
+tags: [ipad, obsidian, git, sync, launchd]
+---
+# iPad — Obsidian vault sync
+
+Метод: прямой двусторонний Git-синк с существующим bare repo TrueNAS по SSH. Выбран после проверки [[family/how-to/vault-git-sync]], [[family/how-to/obsidian-sync]], [[family/how-to/syncthing-truenas-android]] и [[family/how-to/obsidian-android-sync]]. Он использует тот же source of truth, что Mac; Syncthing/Gitea и синк внутри редактора не нужны этому клиенту. Новый доступ не меняет синк существующих устройств.
+
+Устройство: iPad mini1 `iPad2,5`, iOS9.3.5, jailbreak. Редактор — установленная Edhita2.3.0; в её файловом browser открыть **Documents → ObsidianVault**. Полный рабочий набор заметок клонирован неглубоко (depth1), чтобы не расходовать место на старую историю. Перед настройкой доступно335MB; после установки Git и clone —311MB. Ветка `main`, remote `nas`.
+
+## Пути
+
+- Vault: `/private/var/mobile/Containers/Data/Application/27C12C43-7961-4D13-815E-29FB11A9AE57/Documents/ObsidianVault`.
+- Script: `/var/mobile/Library/VaultSync/sync-vault.sh`.
+- Git SSH wrapper: `/var/mobile/Library/VaultSync/bin/git-ssh`.
+- SSH config/pinned host key: `/var/mobile/Library/VaultSync/ssh/config`, `known_hosts`.
+- Dedicated private key: `/var/mobile/Library/VaultSync/ssh/id_ed25519` — остаётся на iPad, владелец mobile, private directory700/key600.
+- Log: `/var/mobile/Library/Logs/ipad-vault-sync.log` (bounded2MiB).
+- State: `/var/mobile/Library/VaultSync/state/last-result`, `last-attempt`, `last-success`.
+- LaunchDaemon: `/Library/LaunchDaemons/local.ipad.obsidian-vault-sync.plist`, label `local.ipad.obsidian-vault-sync`, UserName/GroupName mobile, RunAtLoad=true, StartInterval=300.
+- NAS repo: `ssh://vault-nas/mnt/RED_2TB/storage/git/obsidian-vault.git`; SSH alias vault-nas = truenas_admin@mallexxx.duckdns.org:22.
+- Host sources/evidence: `/Users/admin/Developer/ipad-vault-sync/`.
+
+Vault в Documents принадлежит редактору. При удалении приложения его данные могут удалиться; переустановка с новым container UUID требует обновить VAULT path. Background job требует активного jailbreak; после reboot iPad сначала восстановить jailbreak. Исполнение строго раз в пять минут во время сна устройства не гарантируется; очередной tick после возобновления/доступности сети доставит сохранённые локальные commits.
+
+## Git и доступ
+
+Установлены оригинальные Saurik packages: git2.8.1-5, curl7.33.0-9, expat2.0.1-3. Existing OpenSSL0.9.8 и OpenSSH6.7 не обновлялись. Package bytes сверены с MD5 опубликованного HTTPS Packages index; дополнительный SHA256 каждого download сохранён на Mac. Git2.8.1 реально запускается от mobile на iPad9.3.5.
+
+Отдельный Ed25519 client key iPad→NAS сохранён через TrueNAS user.update; прежние SSH keys/options сохранены. Для этого ключа разрешены только git-upload-pack и git-receive-pack exact `/mnt/RED_2TB/storage/git/obsidian-vault.git`; shell, PTY, port/agent/X11 forwarding запрещены. Guard на NAS: `/home/truenas_admin/.local/bin/ipad-vault-git`. Home dataset NAS noexec, поэтому forced command вызывает `/bin/sh guard`, а не исполняет файл напрямую. NAS host key закреплён из доверенного Mac known_hosts. Mac→iPad login key отдельно; private Mac key не копировался на устройство.
+
+## Поведение
+
+1. Один запуск за раз; stale task lock снимается после проверки PID/boot.
+2. Local edits коммитятся до обращения к серверу.
+3. Fetch main → обычный merge → push без force.
+4. При unavailable remote локальные commits сохраняются, процесс возвращает75 и повторяет попытку на следующем tick.
+5. При конфликте поведение такое же, как в Mac `~/scripts/sync-vault-lib.sh`: `git add -A`, commit `iPad: merge conflict — review needed`, затем обычный push. Маркеры конфликта с обеими версиями попадают в заметку; последующие ticks продолжают синк без ожидания ручного разрешения. Уже прерванный merge с unmerged files также коммитится и пушится на следующем запуске.
+6. Успех отмечается только после совпадения local HEAD и remote main и отсутствия новых working-tree edits. core.fileMode=false; автоматический gc на маленьком flash отключён.
+
+Внешние изменения открытой заметки могут потребовать Reload/переоткрытия в Edhita. Скрипт не изменяет поведение редактора.
+
+## Проверка и обслуживание
+
+Ручной запуск на iPad от mobile:
+
+```sh
+bash /var/mobile/Library/VaultSync/sync-vault.sh
+cat /var/mobile/Library/VaultSync/state/last-success
+cat /var/mobile/Library/VaultSync/state/last-result
+```
+
+От root через SSH:
+
+```sh
+su mobile -c 'bash /var/mobile/Library/VaultSync/sync-vault.sh'
+launchctl list local.ipad.obsidian-vault-sync
+launchctl start local.ipad.obsidian-vault-sync
+```
+
+Изолированные тесты на настоящем Git2.8/Bash4 iPad повторно прошли 2026-10-15: push локальной заметки, pull peer-заметки, сохранение offline edits/retry, commit/push маркеров с обеими версиями и получение другим clone, продолжение следующего синка, возобновление уже прерванного конфликтного merge. Лог на Mac `test-results-mac-conflicts.log`; fixtures retained `/var/mobile/Library/VaultSync/test-20261015T033520Z-12175`. Прежняя остановка на конфликте заменена поведением Mac-скрипта. Первый production manual sync завершился успешно, local/NAS main совпали `9bc1a2847ef2fce0172ecf1f9f6ae87db7c68920`. Production roundtrip и автоматический scheduler проверены; результаты ниже.
+
+Исправленный script установлен атомарно после тестов; предыдущая версия сохранена на iPad как `sync-vault.sh.before-mac-conflicts-20261015`. Байты установленного файла сверены с host source: SHA256 `6db11b994888e3a523614fe30c56a5066ccceba51b3b1d6c44f3c0c437e0618f`. Запуск через существующий launchd завершился 2026-10-15T03:35:49Z, LastExitStatus0 / last-result ok, working tree чистый, local/NAS main `386ce6e9ee6651072279b6dc9a6eb01baebcfe64`. Evidence на Mac: `mac-conflicts-deploy-verification.log`. Расписание осталось каждые300с.
+
+См. [[personal/how-to/ipad-ios935-build-deploy]].
+
+## Проверка рабочего подключения
+
+Первый запуск launchd от mobile завершился exit0; iPad создал эту заметку и отправил в NAS main commit `98b9dafcddf3dd6e4248619c25f434146c4035d5` (19:34:04 UTC 2026-10-14).
+
+Контроль NAS→iPad: `ipad-vault-peer-check-20261015`. Эта строка добавлена через отдельный peer clone к NAS и получена iPad автоматическим tick в19:39:11UTC 2026-10-14.
+
+Итог: **синк настроен и включён**. Первое автоматическое выполнение стартовало19:33:58UTC, завершилось19:34:04UTC; следующий tick без ручного запуска завершился19:39:11UTC. После второго tick local/NAS main равны `68eb11d85c2f956cc33253a4a2eba2f542dcaf0d`, контрольная peer-строка присутствует на iPad, LastExitStatus0 /last-result ok. Edhita screenshot подтверждает видимость Documents/ObsidianVault и сохранение example. Последующие server commits получаются очередным tick; равенство SHA проверяется на каждом успешном запуске.
+
+Диагностические ограничения: NAS push сообщает ignored hooks/post-receive (не executable); фактическое обновление bare main и доставка Mac/iPad проверены, Gitea mirror отдельно не проверялся. Базовый dpkg сообщил отсутствующие file lists для старых unrar/gzip/p7zip; установка выбранных новых packages и native Git запуск успешны, чужие packages не ремонтировались.
@@ -0,0 +1,111 @@
+---
+title: O'Reilly book to iPad PDF
+created: '2026-10-10'
+updated: '2026-10-10'
+tags:
+  - automation
+  - oreilly
+  - pdf
+  - ipad
+  - chrome
+---
+# O'Reilly book to iPad PDF
+
+Автоматизация печатает доступную через подписку O'Reilly книгу по главам средствами Chrome, объединяет главы и создаёт PDF для старого iPad.
+
+## Расположение
+
+Скрипт:
+
+```text
+~/Automation/OReillyPDF/oreilly_book_to_ipad_pdf.mjs
+```
+
+Рабочие файлы при запуске из каталога автоматизации:
+
+```text
+~/Automation/OReillyPDF/work/
+```
+
+Готовый PDF:
+
+```text
+~/Automation/OReillyPDF/outputs/<имя-книги>.pdf
+```
+
+Проверенный документ Building Agentic AI Systems:
+
+```text
+~/Automation/OReillyPDF/outputs/Building-Agentic-AI-Systems-iPad-768x1024.pdf
+```
+
+## Что делает workflow
+
+1. Локально клонирует профиль Chrome `Default`, чтобы использовать существующую авторизацию O'Reilly.
+2. Запускает headless Chrome через Chrome DevTools Protocol.
+3. Открывает корневую страницу книги и читает верхний уровень оглавления O'Reilly.
+4. Последовательно открывает каждый раздел верхнего уровня, чтобы O'Reilly отрисовал лениво загружаемые вложенные главы, затем собирает их в правильном порядке без дубликатов.
+5. Печатает каждую уникальную секцию через движок Chrome; поддерживаются имена страниц `.html` и `.xhtml`.
+6. Применяет размер страницы 576×768 pt — это соотношение 768×1024 при 96 DPI.
+7. Добавляет безопасные поля и правила разрыва страниц, чтобы строки не обрезались по краям.
+8. Объединяет главы с помощью `pdfunite`.
+
+## Требования
+
+- macOS;
+- Google Chrome;
+- авторизация в O'Reilly в профиле Chrome `Default`;
+- Node.js с глобальными `fetch` и `WebSocket`;
+- `rsync`;
+- Poppler/`pdfunite`:
+
+```bash
+brew install poppler
+```
+
+## Настройка для другой книги
+
+Редактировать скрипт не нужно. Передать URL книги первым аргументом; допускается как корневая страница книги, так и URL отдельной главы `.html`/`.xhtml`.
+
+Название книги извлекается из страницы O'Reilly. На его основе автоматически создаётся имя `<Book-Title>-iPad-768x1024.pdf`.
+
+Число глав и имена файлов указывать не нужно: workflow извлекает уникальные секции из оглавления книги.
+
+## Запуск
+
+```bash
+cd ~/Automation/OReillyPDF
+node oreilly_book_to_ipad_pdf.mjs 'https://learning.oreilly.com/library/view/SLUG/BOOK_ID/'
+```
+
+Результат появится в:
+
+```text
+~/Automation/OReillyPDF/outputs/
+```
+
+## Проверка результата
+
+```bash
+pdfinfo outputs/Book-Name-iPad-768x1024.pdf | grep -E 'Pages|Page size|File size'
+```
+
+Ожидаемый размер:
+
+```text
+Page size: 576 x 768 pts
+```
+
+## Диагностика
+
+Подробный stderr Chrome записывается в:
+
+```text
+~/Automation/OReillyPDF/work/pdfs/oreilly-book-driver/chrome.log
+```
+
+Workflow не ждёт загрузки всех lazy-изображений страницы перед распознаванием главы: это ранее вызывало ложный `Timed out waiting for chapter content`. Перед печатью он отдельно подгружает изображения внутри области книги; если отдельное изображение не успело загрузиться, печать продолжается с предупреждением.
+
+## Безопасность
+
+Каталог `work/chrome-oreilly-driver-profile` содержит локальную копию данных профиля Chrome, включая данные авторизации. Не синхронизировать и не публиковать этот каталог. При каждом запуске workflow пересоздаёт копию профиля.
@@ -1,3 +1,9 @@
+> [!WARNING] Исторический документ
+> Не использовать как runbook текущей Balda. Актуальная локальная схема, пути и команды: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Текущий контейнер: `balda-mm-mac`; config: `/Users/admin/Docker/balda-mm-mac/config/config.yaml`; Obsidian MCP: `type: http`, `http://host.docker.internal:3101/mcp`.
+> Материал ниже сохранён только как история.
+> Актуальные результаты локального прогона 2026-10-14, статус кандидата rc.26 и незавершённые планы: [[personal/projects/balda/execution-broker|Execution Broker — текущий локальный контур]]. Старые NO-GO и SHA ниже относятся к указанным историческим запускам.
+
 # Текущее состояние — Balda / Broker — 2026-10-03 22:41 Бишкек

 Статус: **приёмочный Docker-прогон выполнен на прежнем образе; автоматическая публикация исправлена, а Balda запущена из текущего исправленного HEAD PR #12 (`73e02156`). Общий release остаётся NO-GO до нового end-to-end прогона, подтверждающего публикацию и уведомления на образе из текущего HEAD `73e02156`.** Записи ниже — история и могут содержать устаревшие статусы.
@@ -538,13 +544,13 @@ Balda остаётся оркестратором, Broker изолирует и

 Реализованы единый 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 в текущей реализации отсутствуют.

-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).
+Исторический релиз v2.0.0 использовал Lume 0.5.3; его CI и golden/clone acceptance относятся к release commit 2026-09-30. С 2026-10-08 установленный Virfield использует Tart + SSH nodes. В hardening-кандидате 2026-10-14 Lume backend/factory/wrapper/build/install code удалён; старый отдельный Lume LaunchDaemon отключён и выгружен 2026-10-14 после проверки пустого inventory. Новый кандидат ещё не принят для релиза; текущие Tart/factory live результаты записаны отдельно. Текущие evidence и gates — в [[personal/projects/virfield]] и [Verification](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/VERIFICATION.md).

 ### Граница проектов и репозиториев — принятое решение

 `virfield` и `execution-broker` — два независимых проекта. Их нельзя объединять в один репозиторий или один daemon.

-Репозиторий `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 нет.
+Репозиторий `virfield` содержит host control plane: корневой Go module, `cmd/virfieldd`, `cmd/virfield`, `cmd/virfield-mcp`, реализации в `internal/`, deployment в `deploy/`. Актуальная карта модулей — [Architecture](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/ARCHITECTURE.md); отдельного каталога приложения v2 нет.

 Целевая структура отдельного `execution-broker` (реализацию сверять в его репозитории):

@@ -636,6 +642,13 @@ DeepSeek подходит для ограниченного routing и прос
 3. **Принять пользовательский Mattermost flow.** Сообщение Balda не содержит repo name/path. Она сама вызывает `execution_repository_create`, создаёт Prism Story, запускает run, доставляет Human approval и события в исходный chat/topic, публикует артефакты и фиксирует cleanup. Проверить Git commit в новом repo и отсутствие двойного создания при повторе idempotency key.
 4. **Закрыть release gates.** Разобрать наблюдённый ACP `fs/write_text_file: Method not found`, выполнить CI/publication checks на точном SHA, проверить rollback и оставшиеся credential/managed-host ограничения. Public stable объявлять только после live приёмки.

+### Дополнительные задачи — 2026-10-11: альтернативные аппрувы и ACP-контекст
+
+- [x] **Telegram для Broker workflows и worker ACP.** Реализованы привязка к run/Human/владельцу, выбор единственного канала запроса, возврат результата в исходную беседу, срок действия, обновление кнопок, restart recovery и competing-channel deduplication. Текущий контракт и доказательства: [[personal/projects/balda/execution-broker]].
+- [ ] **Прямые ACP-разрешения хостовых агентов Balda.** Единая межканальная доставка этих разрешений не покрывается Telegram-механизмом Broker; это отдельная незавершённая часть плана.
+- [ ] **Прогон субагента для автоаппрува и сбора дополнительного контекста команд ACP-субагентов.** Перед решением по запросу разрешения запускать отдельного субагента: собрать цель команды, cwd, аргументы, затрагиваемые файлы/ресурсы, ожидаемые побочные эффекты и связь с текущей задачей. Использовать собранный контекст для автоаппрува в пределах настроенной политики; при недостатке данных или необходимости решения пользователя направлять запрос на ручной аппрув, включая Telegram. Сохранять решение и обоснование в событиях run.
+- [ ] **Приёмочный прогон.** Проверить связку ACP-запрос → сбор контекста субагентом → автоаппрув либо ручной ответ через Telegram → возобновление нужного ACP-субагента. Покрыть недостаточный контекст, отказ, таймаут и повторный ответ.
+
 ## 17. Критерии готовности

 1. Balda сама создаёт новый локальный Git repo под настроенным workspace root из обычной Mattermost-задачи; пользователь не передаёт заранее repo name/path.
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # План: доделать сквозной путь `@balda` → ответ в Mattermost

 > Создан 2026-09-26. Обновлён 2026-09-26 (сессия реализации, полный проход).
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # Фаза 4 — исполнитель на Mac + `~/agents` + секция «Agents» в Eagle Dashboard

 > План + статус. Старт 2026-09-26.
@@ -1,3 +1,8 @@
+> [!WARNING] Исторический документ
+> Не использовать как runbook текущей Balda. Актуальная локальная схема, пути и команды: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Текущий контейнер: `balda-mm-mac`; config: `/Users/admin/Docker/balda-mm-mac/config/config.yaml`; Obsidian MCP: `type: http`, `http://host.docker.internal:3101/mcp`.
+> Материал ниже сохранён только как история.
+
 > Создан 2026-09-28. Статус: **✅ ЧАСТЬ A (runtime) · C/D (сборка+деплой+валидация) · E (sync с апстримом) ВЫПОЛНЕНЫ.**
 > Часть B (3 блокера PR #8) — **✅ ПРОВЕРЕНА 2026-09-29: фиксы УЖЕ в апстриме** (см. блок ниже).
 > ⛔ **2026-09-29: Balda-стек на Kraken СНЕСЁН.** Топология пересмотрена — стек переезжает на Mac.
@@ -0,0 +1,227 @@
+# Balda — историческая карточка и шаблоны до 2026-10-14
+
+> [!WARNING] Архив
+> Эти сведения и инструкции относятся к прежним версиям. Они не описывают текущий запуск и не применяются автоматически.
+> Актуальные карточки: [[personal/projects/balda/balda|Balda]], [[personal/projects/balda/setup|runbook]], [[personal/projects/balda/execution-broker|Broker и приёмка]].
+> Старые PR #8 и #12 уже merged. Литералы старых credentials заменены ссылкой на приватное хранилище.
+
+## Карточка Balda до актуализации
+
+> **Актуальный статус — 2026-10-03.** Mattermost-интеграция PR #8 уже в upstream. [PR #12](https://github.com/baldaworks/balda/pull/12) по маршрутизации webhook открыт на `73e02156`: 8/8 GitHub checks прошли; повторное ревью после исправления запрошенных изменений ещё ожидается. Balda запущена из чистого текущего HEAD PR `73e02156`, и хеш бинарника в контейнере совпадает с собранным артефактом. Ревьюер запросил изменения в PR #12 из-за 404 при временном сбое lookup session. Исправление `73e02156` уже отправлено: теперь ответ 503, добавлен HTTP-тест; локальные race tests и lint прошли, все 8 checks нового HEAD прошли. До повторного сквозного прогона merge/release — NO-GO. Прежний вывод о другом SHA был ошибкой: `d094943b` относился к внешнему репозиторию Broker, а `deepseekfix` был старой меткой образа. Локальных правок кода Balda в текущем бинарнике нет; новый сквозной прогон ещё нужен. Приёмочный Broker run `run-fbe2cb459fe2965554402aba1bd5fcd0` прошёл; Mattermost отправил апрув и финал в исходный тред. Результат `4dafb9d` был доставлен в `go-cli-test` вручную через Broker API: Balda пропустила автоматическую публикацию. Broker теперь сам проверяет commit/quality/bundle без обязательного SHA от Balda; webhook и плагин rc.19 требуют публикацию до закрытия Story. Новый end-to-end прогон ещё не проведён. Общий release — NO-GO. Детали и текущие проверки: [[personal/plans/balda-callee-prism-plan]]. Ниже сохранена историческая документация; старые статусы PR и конфигурации не являются текущими.
+
+Аналог Hermes. Go-сервис: берёт задачи из чата (Telegram или Zulip), запускает AI CLI и отвечает.
+
+## Репо
+
+- Upstream: https://github.com/baldaworks/balda (старое имя `normahq/balda` — редирект)
+- Fork: https://github.com/mallexxx/balda
+- Local: ~/Developer/balda
+- Ветка: `feat/mattermost-channel` (PR [#8](https://github.com/baldaworks/balda/pull/8), OPEN, 8/8 CI, MERGEABLE)
+
+### 🔴 Два репозитория — не путать
+
+| Репо | Что там | PR |
+|---|---|---|
+| **`baldaworks/balda`** | сам бот, транспорты (Mattermost, Zulip) | [#8](https://github.com/baldaworks/balda/pull/8) Mattermost, OPEN · [#1](https://github.com/baldaworks/balda/pull/1) Zulip, merged |
+| **`normahq/runtime`** | библиотека рантайма (`agentfactory`, `hostedagent`) | [#5](https://github.com/normahq/runtime/pull/5) фикс MCP-тулинга, OPEN · **`CHANGES_REQUESTED`** (3 дефекта, план — [[personal/plans/runtime-pr5-toolset-dedup-review-fixes]]) · [#4](https://github.com/normahq/runtime/pull/4) OpenAI tool_calls, OPEN (4 дефекта закрыты, [[personal/plans/runtime-pr4-openai-toolcalls-fixes]]) |
+
+Форки: `mallexxx/balda`, `mallexxx/runtime` — **разные**, клоны тоже разные.
+Детали по runtime-PR → [[personal/projects/balda/balda-valera]].
+
+⚠️ **PR из форка: CI не запускается сам.** GitHub требует ручного подтверждения workflows
+владельцем репо («Approve and run workflows») → `mergeStateStatus: UNSTABLE` при
+`check-runs: total_count 0`. Это не поломка PR.
+
+## Архитектура
+
+- NATS JetStream — event bus (embedded)
+- SQLite — состояние (owner, sessions, tasks)
+- Telegram — через polling или webhook
+- Zulip — через outgoing webhook bot
+- Providers: codex, opencode, copilot, gemini, claude (ACP protocol)
+
+## Zulip Integration
+
+Полностью реализована. Webhook-based (не polling).  
+Тип бота: **Outgoing webhook** (не Generic bot).
+
+### Credentials (zulip.qentra.top)
+
+- Bot email: `balda-bot@zulip.qentra.top`
+- API key: `<из приватного хранилища>`
+- Server URL: `https://zulip.qentra.top`
+- Webhook token: берётся из Settings → Bots → balda-bot → Edit → Token
+
+### Config (env vars)
+
+```
+BALDA_ZULIP_BOT_EMAIL=balda-bot@zulip.qentra.top
+BALDA_ZULIP_API_KEY=<из приватного хранилища>
+BALDA_ZULIP_SERVER_URL=https://zulip.qentra.top
+BALDA_ZULIP_WEBHOOK_TOKEN=<из настроек бота>
+BALDA_ZULIP_WEBHOOK_ENABLED=true
+```
+
+### Webhook setup в Zulip
+
+1. Settings → Bots → balda-bot → Edit
+2. Bot type: Outgoing webhook
+3. Endpoint URL: `http://<host>:8090/zulip/webhook`
+4. Скопировать token → `BALDA_ZULIP_WEBHOOK_TOKEN`
+
+### Авторизация
+
+После запуска написать боту в DM:
+```
+/start owner=<BALDA_AUTH_TOKEN>
+```
+
+## Реализованные команды (Telegram parity)
+
+| Команда | Статус |
+|---------|--------|
+| `/start owner=<token>` | ✅ |
+| `/start invite=<token>` | ✅ |
+| `/goal <objective>` / `/goal clear` | ✅ |
+| `/topic` | ✅ (создаёт сессию для нового топика) |
+| `/user add <email>` | ✅ |
+| `/user list` | ✅ (с инвайтами + expiry) |
+| Typing indicator | ✅ (isDM-aware: true в DM, false в стримах) |
+| plan_updates / SendDraftPlain | ➖ no-op (нет аналога в Zulip) |
+
+## Upcoming: mention-based thread takeover
+
+Когда `@balda-bot` упоминается в топике без активной сессии — бот автоматически берёт топик под контроль.
+
+Механизм (аналог whale-thread-guard в Hermes):
+- Webhook payload поле `trigger == "mention"` → auto-create session
+- `allowed_owners` список в конфиге: Zulip email без токена
+- После захвата топик отвечает на все сообщения (обычная сессия)
+
+## Конфиг и инструкции
+
+- [`balda/soul.md`](../balda/soul.md) — soul (global_instruction) — редактировать здесь, синхронизировать в config.yaml
+- [`balda/workspace-context.md`](../balda/workspace-context.md) — per-provider system_instructions (рабочий проект/стек)
+- `~/Developer/balda/.config/balda/config.yaml` — основной конфиг (runtime + balda)
+- `~/Developer/balda/.env` — секреты (Zulip API key, webhook token)
+
+### Запуск
+
+```bash
+cd ~/Developer/balda && ~/.local/bin/balda start
+```
+
+После первого запуска: из логов взять `owner_token` и отправить боту в Zulip DM:
+```
+/start owner=<token>
+```
+
+## Docs
+
+- `docs/zulip-webhook.md` — полное руководство по настройке
+- `docs/balda.md` — техническая спецификация
+
+## Исторический шаблон global instruction: Валера / Zulip
+
+> Это глобальная инструкция Балды (Валеры). Вставляется в system prompt каждой сессии.
+> После правки — синхронизировать вручную в `~/Developer/balda/.config/balda/config.yaml`
+> (поле `balda.global_instruction`), затем перезапустить Балду.
+
+---
+
+Ты **Валера** — практичный AI-ассистент команды в Zulip.
+
+## Стиль
+
+- Отвечай на языке собеседника (русский или English).
+- Кратко и конкретно. Никакой воды, никаких вступлений.
+- Показывай результат, а не процесс.
+- Код и команды — в fenced code blocks.
+- Не объясняй что ты сделал — пользователь видит результат.
+
+## Работа
+
+- Берёшь задачу и доводишь до конкретного результата.
+- Если задача большая или неоднозначная — уточни объём, прежде чем начать.
+- Возвращай что-то осязаемое: код, файл, ответ, список шагов.
+- Не останавливайся на полпути — если начал, закончи.
+
+## Ограничения
+
+- Не делай деструктивных действий (удаление файлов, force push) без явного подтверждения.
+- Не пиши в main/master напрямую. Используй ветки.
+- Если нужны credentials или secrets — попроси, не угадывай.
+
+## Память
+
+- Durable факты и предпочтения команды сохраняй через `balda.memory.remember`.
+- Не сохраняй промежуточные состояния задач и временный контекст.
+- Сохраняй: соглашения, предпочтения, архитектурные решения, стек.
+
+## Workspace
+
+- Если workspace включён (mode=on/auto) — используй worktree per session.
+- `balda.workspace.import` — перед началом крупных правок.
+- `balda.workspace.export` — после завершения, Conventional Commit message.
+- Не делай merge/rebase через raw git если доступны workspace MCP tools.
+
+## Формат ответов в Zulip
+
+- Zulip поддерживает Markdown: **bold**, `code`, ```fenced blocks```, таблицы.
+- Для длинных результатов используй сворачиваемые блоки: `:::spoiler Заголовок`.
+- Цитируй исходное сообщение только если нужна явная привязка.
+
+## Исторический шаблон workspace context: Claude
+
+> Provider-level `system_instructions` — дополнение к soul.md для конкретного провайдера.
+> Задаётся в `~/Developer/balda/.config/balda/config.yaml` под
+> `runtime.providers.claude_code.system_instructions`.
+
+---
+
+## Текущий контекст
+
+Рабочий проект и стек пока не заданы. Заполни этот раздел когда Балда будет прикреплена
+к конкретному репозиторию или задачам.
+
+Шаблон для заполнения:
+```
+## Проект
+
+- Репо: ~/Developer/<project-name>
+- Стек: <language/framework>
+- Основная ветка: main
+
+## Команда
+
+- alex (owner) — говорит по-русски, можно и по-английски
+- <другие участники>
+
+## Соглашения
+
+- Стиль коммитов: Conventional Commits (feat/fix/chore/docs)
+- PR: через gh cli, base=main
+- Тесты: <framework>
+- Линтер: <tool>
+
+## Workflow
+
+- Задачи приходят в Zulip топик
+- Результат: коммит в ветку + краткий отчёт в тот же топик
+```
+
+## Провайдер
+
+`claude_code_acp` с моделью `claude-sonnet-4-6`.
+
+Если нужны особые флаги модели:
+```yaml
+runtime:
+  providers:
+    claude_code:
+      type: claude_code_acp
+      system_instructions: |
+        <вставить сюда содержимое этого файла>
+      claude_code_acp:
+        model: claude-sonnet-4-6
+```
@@ -0,0 +1,178 @@
+---
+title: Virfield
+namespace: personal
+updated: '2026-10-07'
+status: historical
+tags:
+  - virfield
+  - macos
+  - vm
+  - go
+  - infrastructure
+archived: '2026-10-14'
+---
+> [!WARNING] Исторический архив
+> Чекпойнты до 2026-10-08. Не использовать старые пути, ветки, команды и статусы как текущий runbook. Актуальная карточка: [[personal/projects/virfield]].
+
+# 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 22:20 — R3 живой: рабочий стол VM-аренд
+
+- `virfield desktop LEASE_ID [--print]`, кнопка Desktop в Web Console, MCP `vm_tunnel` с `"service":"desktop"` → `vnc://admin:<пароль аренды>@127.0.0.1:<порт>` (Screen Sharing.app входит сам).
+- Гостевой Screen Sharing включается при подготовке каждой VM-аренды (`launchctl enable` + `bootstrap`), подготовка ждёт 5900. Tart: lease IP:5900 (host-only сеть). HTPC: guest 5900 → passt (`USER_PORTS=22,5900`, QEMU VNC → 5950) → loopback ноды (SSH-порт+1000) → SSH ноды. В LAN ничего нового.
+- Туннели по сервисам (`ssh`/`desktop`), закрываются при release/истечении/дрейфе. Приёмка 11/11 (Tart Ventura + HTPC Sonoma), визуально Ventura-рабочий стол открылся без вопросов.
+- Коммиты `24a6904`…`4277f72` + docs. Не сделано: noVNC в браузере, рабочий стол MacBook (Screen Sharing на томах).
+
+## Обновление 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`.
@@ -1,3 +1,8 @@
+> [!WARNING] Исторический документ
+> Не использовать как runbook текущей Balda. Актуальная локальная схема, пути и команды: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Текущий контейнер: `balda-mm-mac`; config: `/Users/admin/Docker/balda-mm-mac/config/config.yaml`; Obsidian MCP: `type: http`, `http://host.docker.internal:3101/mcp`.
+> Материал ниже сохранён только как история.
+
 # Фаза 3 — Балда на Kraken + Mattermost (деплой)

 > ⛔ **2026-09-29: СТЕК СНЕСЁН.** Контейнеры `balda-mm`, `balda-executor-mcp`, `obsidian-mcp`
@@ -1,7 +1,12 @@
-# Balda — Mattermost коннектор (архитектура)
+# Balda — Mattermost-коннектор: исторический дизайн
+
+> [!WARNING] Историческая спецификация
+> Код Mattermost-коннектора принят в [PR #8](https://github.com/baldaworks/balda/pull/8), merged **2026-09-29**; статус перепроверен **2026-10-14**.
+> Схема, пути, команды и результаты ниже описывают версию сентября и не служат текущим runbook.
+> Текущий запуск: [[personal/projects/balda/setup]]. Текущие PR и код: [[personal/projects/balda/balda]]. Broker/ingress recovery и приёмка: [[personal/projects/balda/execution-broker]].

 > Создано 2026-09-26. Обновлено 2026-09-28 (правки по ревью применены).
-> Статус: **✅ PR ОТКРЫТ — baldaworks/balda#8, 8/8 CI PASS, MERGEABLE.**
+> Статус PR: **MERGED, 2026-09-29**. Приведённые ниже CI и commit IDs — история приёмки PR #8.
 > 🟢 **PR:** https://github.com/baldaworks/balda/pull/8 — 46 файлов, +6850/−27, 9 коммитов.
 > Фаза 2 закрыта полностью: код, 103+ новых теста, доки, зелёный CI.
 > Блокер `tools/` снят: `/tools/` в `.gitignore` + `git rm -r --cached tools/`.
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # Balda 2.0 — Mattermost + распределённое делегирование (план)

 > Создан 2026-09-25. Статус (обновлён **2026-09-28**): **Фазы 1-3 закрыты** (MM на Kraken ·
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # Балда / Валера — эксплуатация & MCP debug

 > ## ⛔ СНЕСЁН 2026-09-29 — агент удалён на Mac
@@ -1,115 +1,31 @@
-# Balda (Валера) — AI Worker Bot
+# Balda — актуальный обзор

-> **Актуальный статус — 2026-10-03.** Mattermost-интеграция PR #8 уже в upstream. [PR #12](https://github.com/baldaworks/balda/pull/12) по маршрутизации webhook открыт на `73e02156`: 8/8 GitHub checks прошли; повторное ревью после исправления запрошенных изменений ещё ожидается. Balda запущена из чистого текущего HEAD PR `73e02156`, и хеш бинарника в контейнере совпадает с собранным артефактом. Ревьюер запросил изменения в PR #12 из-за 404 при временном сбое lookup session. Исправление `73e02156` уже отправлено: теперь ответ 503, добавлен HTTP-тест; локальные race tests и lint прошли, все 8 checks нового HEAD прошли. До повторного сквозного прогона merge/release — NO-GO. Прежний вывод о другом SHA был ошибкой: `d094943b` относился к внешнему репозиторию Broker, а `deepseekfix` был старой меткой образа. Локальных правок кода Balda в текущем бинарнике нет; новый сквозной прогон ещё нужен. Приёмочный Broker run `run-fbe2cb459fe2965554402aba1bd5fcd0` прошёл; Mattermost отправил апрув и финал в исходный тред. Результат `4dafb9d` был доставлен в `go-cli-test` вручную через Broker API: Balda пропустила автоматическую публикацию. Broker теперь сам проверяет commit/quality/bundle без обязательного SHA от Balda; webhook и плагин rc.19 требуют публикацию до закрытия Story. Новый end-to-end прогон ещё не проведён. Общий release — NO-GO. Детали и текущие проверки: [[personal/plans/balda-callee-prism-plan]]. Ниже сохранена историческая документация; старые статусы PR и конфигурации не являются текущими.
+Проверено: **2026-10-15**. Balda принимает задачи из чата и связывает provider execution, сессии и интеграции. Текущий локальный запуск — **два инстанса на Mac, Mattermost, Codex ACP**: `balda-mm-mac` и `balda-mm-eagle`. Оба работают на source `6238856b` (upstream `6621b189` с исправлением контекста канала); Eagle имеет те же основные MCP и дополнительный Asana readonly. Точные версии и проверенные границы продолжений — в карточке запуска.

-Аналог Hermes. Go-сервис: берёт задачи из чата (Telegram или Zulip), запускает AI CLI и отвечает.
+## Источники текущего состояния

-## Репо
+- [[personal/projects/balda/setup|Работающий контейнер, конфигурация, MCP и перезапуск]]
+- [[personal/projects/balda/execution-broker|Broker/Balda: проверенные версии, артефакты и незавершённая работа]]
+- [[personal/projects/balda/soul|Снимок global instruction]]
+- [[personal/projects/balda/workspace-context|Provider context]]

- Upstream: https://github.com/baldaworks/balda (старое имя `normahq/balda` — редирект)
- Fork: https://github.com/mallexxx/balda
- Local: ~/Developer/balda
- Ветка: `feat/mattermost-channel` (PR [#8](https://github.com/baldaworks/balda/pull/8), OPEN, 8/8 CI, MERGEABLE)
+В карточках указаны работающий образ, действующая конфигурация и границы готовности Broker.

-### 🔴 Два репозитория — не путать
+## Репозитории

-| Репо | Что там | PR |
-|---|---|---|
-| **`baldaworks/balda`** | сам бот, транспорты (Mattermost, Zulip) | [#8](https://github.com/baldaworks/balda/pull/8) Mattermost, OPEN · [#1](https://github.com/baldaworks/balda/pull/1) Zulip, merged |
-| **`normahq/runtime`** | библиотека рантайма (`agentfactory`, `hostedagent`) | [#5](https://github.com/normahq/runtime/pull/5) фикс MCP-тулинга, OPEN · **`CHANGES_REQUESTED`** (3 дефекта, план — [[personal/plans/runtime-pr5-toolset-dedup-review-fixes]]) · [#4](https://github.com/normahq/runtime/pull/4) OpenAI tool_calls, OPEN (4 дефекта закрыты, [[personal/plans/runtime-pr4-openai-toolcalls-fixes]]) |
+Upstream: [baldaworks/balda](https://github.com/baldaworks/balda). Fork: [mallexxx/balda](https://github.com/mallexxx/balda).

-Форки: `mallexxx/balda`, `mallexxx/runtime` — **разные**, клоны тоже разные.
-Детали по runtime-PR → [[personal/projects/balda/balda-valera]].
+## Конфигурация и владение

-⚠️ **PR из форка: CI не запускается сам.** GitHub требует ручного подтверждения workflows
-владельцем репо («Approve and run workflows») → `mergeStateStatus: UNSTABLE` при
-`check-runs: total_count 0`. Это не поломка PR.
+Действующий конфиг: `/Users/admin/Docker/balda-mm-mac/config/config.yaml`. Dev-конфиг в `~/Developer/balda` — отдельный файл. Provider — `codex_acp`, reasoning `medium`; Obsidian MCP — `type: http`, `http://host.docker.internal:3101/mcp`.

-## Архитектура
+Balda и локальные агенты владеют оркестрацией, MCP, search/Obsidian и прикладными workflows. Execution Broker владеет disposable worker, lifecycle, credentials, инструментами и артефактами; его незавершённые задачи перечислены отдельно.

- NATS JetStream — event bus (embedded)
- SQLite — состояние (owner, sessions, tasks)
- Telegram — через polling или webhook
- Zulip — через outgoing webhook bot
- Providers: codex, opencode, copilot, gemini, claude (ACP protocol)
+Документация кода: [README](https://github.com/baldaworks/balda/blob/main/README.md), [configuration](https://github.com/baldaworks/balda/blob/main/docs/reference/configuration.md), [plugins](https://github.com/baldaworks/balda/blob/main/docs/reference/plugins.md).

-## Zulip Integration
+## История

-Полностью реализована. Webhook-based (не polling).  
-Тип бота: **Outgoing webhook** (не Generic bot).
-
-### Credentials (zulip.qentra.top)
-
- Bot email: `balda-bot@zulip.qentra.top`
- API key: `AtC9FypdIl6F0hNICW0lcOzehrVrWhPr`
- Server URL: `https://zulip.qentra.top`
- Webhook token: берётся из Settings → Bots → balda-bot → Edit → Token
-
-### Config (env vars)
-
-```
-BALDA_ZULIP_BOT_EMAIL=balda-bot@zulip.qentra.top
-BALDA_ZULIP_API_KEY=AtC9FypdIl6F0hNICW0lcOzehrVrWhPr
-BALDA_ZULIP_SERVER_URL=https://zulip.qentra.top
-BALDA_ZULIP_WEBHOOK_TOKEN=<из настроек бота>
-BALDA_ZULIP_WEBHOOK_ENABLED=true
-```
-
-### Webhook setup в Zulip
-
-1. Settings → Bots → balda-bot → Edit
-2. Bot type: Outgoing webhook
-3. Endpoint URL: `http://<host>:8090/zulip/webhook`
-4. Скопировать token → `BALDA_ZULIP_WEBHOOK_TOKEN`
-
-### Авторизация
-
-После запуска написать боту в DM:
-```
-/start owner=<BALDA_AUTH_TOKEN>
-```
-
-## Реализованные команды (Telegram parity)
-
-| Команда | Статус |
-|---------|--------|
-| `/start owner=<token>` | ✅ |
-| `/start invite=<token>` | ✅ |
-| `/goal <objective>` / `/goal clear` | ✅ |
-| `/topic` | ✅ (создаёт сессию для нового топика) |
-| `/user add <email>` | ✅ |
-| `/user list` | ✅ (с инвайтами + expiry) |
-| Typing indicator | ✅ (isDM-aware: true в DM, false в стримах) |
-| plan_updates / SendDraftPlain | ➖ no-op (нет аналога в Zulip) |
-
-## Upcoming: mention-based thread takeover
-
-Когда `@balda-bot` упоминается в топике без активной сессии — бот автоматически берёт топик под контроль.
-
-Механизм (аналог whale-thread-guard в Hermes):
- Webhook payload поле `trigger == "mention"` → auto-create session
- `allowed_owners` список в конфиге: Zulip email без токена
- После захвата топик отвечает на все сообщения (обычная сессия)
-
-## Конфиг и инструкции
-
- [`balda/soul.md`](balda/soul.md) — soul (global_instruction) — редактировать здесь, синхронизировать в config.yaml
- [`balda/workspace-context.md`](balda/workspace-context.md) — per-provider system_instructions (рабочий проект/стек)
- `~/Developer/balda/.config/balda/config.yaml` — основной конфиг (runtime + balda)
- `~/Developer/balda/.env` — секреты (Zulip API key, webhook token)
-
-### Запуск
-
-```bash
-cd ~/Developer/balda && ~/.local/bin/balda start
-```
-
-После первого запуска: из логов взять `owner_token` и отправить боту в Zulip DM:
-```
-/start owner=<token>
-```
-
-## Docs
-
- `docs/zulip-webhook.md` — полное руководство по настройке
- `docs/balda.md` — техническая спецификация
+- [[personal/projects/archive/balda-reference-before-2026-10-14|Прежняя карточка, Zulip и старые provider templates]]
+- [[personal/projects/balda/balda-mattermost-connector|Исторический дизайн Mattermost-коннектора]]
+- [[personal/plans/balda-callee-prism-plan|Архив раннего плана Broker/Callee/Prism]]
+- Старые Kraken/Valera/Claudio runbooks помечены историческими и не задают текущий запуск.
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # Клавдий (Claudio) — эксплуатация

 ## Расположение
@@ -0,0 +1,81 @@
+# Execution Broker — эксплуатация
+
+Проверено: **2026-10-15** по исходникам, работающим контейнерам и реальным запускам. Полная release-ready приёмка ещё не завершена.
+
+## Развёрнутый комплект
+
+| Компонент | Текущее состояние |
+| --- | --- |
+| Репозиторий | `/Users/admin/Developer/execution-broker`, `codex/production-readiness`; основной комплект `fee5409`, Broker hotfix `1b09e0f` |
+| Broker | `execution-broker:1b09e0f`, версия `0.1.0-rc.32+approval30.1b09e0f`, immutable SHA256 pin в Compose |
+| Gateway | `execution-broker-gateway:fee5409`, версия `0.1.0-rc.32` |
+| Prism | `execution-prism-adapter:fee5409`, версия `0.1.0-rc.32` |
+| Smoke worker | `execution-broker-worker:fee5409`; один SHA256 image pin в Broker и gateway |
+| OpenCode worker | `execution-broker-executors:fee5409`; один SHA256 image pin в Broker и gateway, Go SDK 1.26.9 |
+| macOS bootstrap | Четыре пакета `*-fee5409.tar.gz` с Runner/Callee этого комплекта |
+| Оба Balda | Source `6238856b`: upstream `6621b189` + исправление контекста канала; image `balda-balda:upstream-6621b189-channel-fix`; подробности в [[personal/projects/balda/setup]] |
+| Managed plugin | rc32 у обоих, Enabled=true, Drifted=false; прежние plugin data, revisions и marketplace сохранены |
+| Release archives | `0.1.0-rc.32`, source `fee5409`; четыре платформенных архива и plugin в `dist/`, SHA256 проверены |
+
+Docker socket и daemon group отсутствуют у coding workers. Административный доступ к Docker остаётся у gateway. Основные модели, home volumes и история обоих Balda сохранены; сессии не сбрасывались. Серверная проверка Codex auth: models endpoint отвечает HTTP 200 у обоих инстансов. У @balda дополнительно проверена реальная генерация в ephemeral read-only сессии: `AUTH_OK`, `turn.completed`, exit 0. Исходный аккаунт сохранён; Balda перечитал credentials после обычного перезапуска.
+
+## Инструменты и артефакты
+
+`execution_profiles` показывает разрешённые tooling profiles. Подготовка окружения задаётся декларативно: platform, версии, approved packages/archives, SHA256 и readiness probes. Новый стек требует подходящего operator profile; Makefile сам по себе не устанавливает зависимости.
+
+В текущем контуре Go 1.26.9 задан стандартным profile для Linux OpenCode и четырёх macOS workers. Специального Go installer в Runner больше нет. Tooling cache хранит проверенные immutable archives, ограничен 4 GiB; фактические версии сохраняются в `tooling.json`. Временные build products выполняются внутри приватного каталога run; общий Linux `/tmp` остаётся `noexec`.
+
+Отдельный Git cache хранит immutable bundles по repository/commit с лимитом 4 GiB, durable deadline holds и отдельными run-scoped токенами. Disposable checkouts не разделяют mutable worktree и upstream credentials. В production `linux-smoke` подключён к внутренней control-сети Broker; cache/inputs/tooling требуют рабочего маршрута к Broker, одного публичного HTTPS clone недостаточно.
+
+Durable смена окружения использует явно заданный operator checkpoint: остановка Callee и credential fence → snapshot исходников с сохранением base ancestry → cleanup старого worker → `execution_reconfigure` → отдельный owner approval → новая immutable среда и фиксированный continuation. Task и исходный deadline сохраняются; максимум две замены, один admission на checkpoint, отмена охватывает цепочку. Ожидание approval не резервирует worker capacity. Это opt-in политика workflow; в стандартных coding packs checkpoints по умолчанию не включены. Произвольный live graph не сериализуется и не переигрывается. Требуется `execution/v3`.
+
+Artifact inputs реализованы и развёрнуты через `execution/v2`: до восьми файлов, суммарно до 1 GiB, точные source run/name/SHA256 и исходная сессия. Source run должен быть терминальным с `cleanup=done`; transactional retention holds защищают принятые зависимости. Передача возобновляется до начала исполнения.
+
+## Продолжения и одобрения
+
+Generic webhook в текущем Balda запускает изолированное задание. Канонический канал исходной сессии остаётся Mattermost; Telegram approval не меняет её locator. Продолжение исходной сессии использует `balda.state` и `balda.session.wait`; попытка и наблюдатель сохраняются до Start/retry. Потерянный admission восстанавливается через `execution_lookup`, отмена закрывает и поздний идентичный запрос. Прежние callback routes Broker приостановлены; недоставленные cursors сохранены.
+
+Telegram approval bot получает вопрос только для явно выбранных сессий; иначе вопрос принадлежит исходной беседе. В текущем контуре `telegram_approvals.timeout_seconds=1800`: окно ответа — 30 минут. `min_run_ttl_seconds=3600` требует для новых запусков выбранных сессий общий TTL не меньше часа; более короткий запрос получает `approval_window_too_short` до admission. TTL включает очередь, планирование, ожидание ответа и исполнение; исходный deadline остаётся жёсткой границей и при появлении вопроса не продлевается. Сообщение сначала отправляется без кнопок, message ID сохраняется в state, затем публикуются controls. Рестарт завершает прерванную публикацию или renewal без повторного callback. Устаревшая копия очищается при callback до сохранения update cursor. Ответ владельца передаётся через bound `execution_respond`; модель не подменяет его. `execution_retry` сохраняет точный task, Story, revision, executor и действительное одобрение; новый scope требует нового решения. Для environment checkpoint используется `execution_reconfigure`; обычный retry таких runs запрещён.
+
+Managed lifecycle и native wait restart проверены на развёрнутом Balda. Реальный conversational smoke прошёл: модель использовала исходные Story/Task, подтвердила observer/recovery waits, дождалась фактического Telegram-ответа владельца и получила `succeeded`, `cleanup=done`. Все шесть артефактов скачаны с проверкой SHA256; единственный итоговый ответ подтверждён через Mattermost API в исходной беседе, оставшиеся waits отменены. Приватные доказательства: `state/balda-channel-context-20261015/`. Outage/restart реальной модельной беседы также прошёл: Balda получила HTTP 502, затем Broker/Prism/Balda были перезапущены; сохранились тот же run/Story, provider thread и исходный deadline. После фактического Telegram approval подтверждены `succeeded`, шесть скачанных SHA256-проверенных артефактов, `cleanup=done`, закрытие Story/Task и единственное сообщение о завершении restart-приёмки в исходном Mattermost. Native waits отменены, duplicate admission и остаточных worker container/volume нет. Существующие сессии принимают новый capability snapshot через обычный `/reset`; обновление само их не сбрасывает.
+
+## Проверки
+
+- Полные race/vet Broker на macOS ARM64 и Linux ARM64; Callee adapter, source/binary govulncheck — 0 reachable vulnerabilities, secret scan — без находок.
+- Развёрнутый Balda source `6238856b`: полный race, lint, architecture gate и govulncheck (0 reachable); SQLite/PostgreSQL migration regressions, оба migration validators, managed plugin lifecycle и native wait restart. Существующий Codex thread продолжился с исправленным Mattermost-контекстом.
+- Production service acceptance: настоящий Callee Human → restart Broker/Prism → resume → шесть артефактов с проверенными SHA256 и provenance Git cache → `succeeded`, `cleanup=done`; Task и Story закрыты.
+- Реальная Balda-сессия: исправленный Mattermost-контекст → durable waits → Broker smoke → фактический Telegram approval → шесть скачанных артефактов с проверенными SHA256 → `cleanup=done` → итог в исходной Mattermost-беседе. Доставка и отсутствие дубликата подтверждены readonly API.
+- Настоящая macOS VM: verified Go archive через scoped tunnel, `tooling.json`, один XCTest без ошибок и сохранённый xcresult; восемь артефактов с проверенными SHA256, включая `repository.json`, VM cleanup подтверждён.
+- Реальные Make/C, Python, Node и JVM проекты на macOS и Linux; Docker builder/Runner/Callee cache hit и изменение Node SDK; durable смена окружения с двумя рестартами и одним выполнением внешнего действия; отдельная проверка реального `go run` при `/tmp noexec`.
+- Artifact input transfer/restart/cleanup и установка из Linux ARM64 release archive без исходников и Go прошли.
+- Runtime archives: все четыре платформы — native. Linux AMD64 проверен на физическом htpc x86_64; Darwin AMD64 — на MacBook Pro 13″ 2014, Intel i5-4278U, macOS 12.6.8 (21G725), Python 3.8.9 через pinned Virfield SSH. Оба AMD64-прогона проверили семь binaries, MCP/auth rejection, synthetic vault import/revoke, SQLite backup и graceful shutdown; рабочие provider credentials не использовались.
+
+Сервисные fixtures не подтверждают выбор tools и доставку результата моделью в настоящей беседе.
+
+## Незавершённый объём
+
+| Область | Что остаётся |
+| --- | --- |
+| Recovery | Выбран порядок: unattended восстановление рабочих ключей из защищённой копии, затем OAuth при неудаче восстановления/refresh. Production escrow ещё не настроен: нужен независимый recovery public key или secret store. Native перенос тестового vault проверен; рабочие master keys не экспортировались |
+| Docker providers | Для настроенных Linux OpenCode/DeepSeek, Codex и Claude нужны отдельные реальные Story, повтор на свежем worker, restart, credential checkpoint/reuse и проверка sandbox/запрета записи. Синтетические lifecycle-тесты не закрывают эту приёмку |
+| Provider lifecycle | Для macOS Claude не закрыта реальная expiry/upstream revocation; для macOS OpenCode/DeepSeek — denied-write и upstream revocation. Claude умеет сохранить явный отказ native cache как reauthentication-required и запросить OAuth при следующем admission; это не доказательство реальной provider-приёмки |
+
+Источник требований — `docs/work-plan.md`. iPad, прикладные UI/PR workflows и права Obsidian принадлежат вызывающему проекту или Balda.
+
+## Конфигурация и восстановление
+
+Приватный Compose: `state/deploy/compose.production.json`; конфиги `broker.json`, `worker.json`, assets в `state/deploy/assets`. Токены находятся только в secret-файлах.
+
+После выбора согласованного проверенного комплекта применять из репозитория:
+
+```bash
+docker-compose -f state/deploy/compose.production.json -p execution-broker up -d --no-build worker broker prism
+```
+
+До смены комплекта завершить runs/cleanup, сохранить state/config/image pins и исходные immutable assets. Сам Git commit deployment не меняет.
+
+Backup перед текущим обновлением: `state/backups/20261015-before-rc32`. Проверены SHA256, 31 SQLite database и inert restore шести компонентов, включая encrypted credential vault. Все три credential identity были освобождены и checkpointed. Restore не запускал сервисы; master keys Keychain в backup отсутствуют. Это подтверждение восстановления production snapshot на том же хосте. Отдельная native-проверка перенесла синтетический encrypted vault с macOS ARM64 на физический Linux AMD64: отсутствие и подмена ключа отклоняются без перезаписи ciphertext, отдельный escrow key восстанавливает запись, revoke работает, fresh enrollment в новый vault с новым ключом проходит. Production credentials и Keychain keys в этом тесте не использовались. Он не заменяет escrow или повторную авторизацию реальных аккаунтов после потери хоста.
+
+Актуальные согласованные state/config backups обоих Balda, exact image/binary hashes и доказательства restart/native/off-host fixture проверок: `state/balda-upstream-hooks-20261015/`. Более ранние state/home backups обоих Balda: `state/balda-upstream-rollout-20261015/`. Рабочие account/config hashes после обновления совпали с исходными. Приватные отчёты проверок основного комплекта: `state/broker-rc32-rollout-20261015/`. Broker hotfix: `state/telegram-timeout-20261015/`, включая консистентный `broker.before.db` с успешными integrity/foreign-key checks и сохранённый Compose для отката. Hotfix прошёл полный `make check`, Linux ARM64 race для Broker/config/HTTP API и govulncheck без достижимых уязвимостей. Release archives rc32 остаются неизменными и содержат исходный `fee5409`; hotfix развёрнут отдельным Broker image. Native Darwin AMD64 proof: `state/balda-pr62-review-20261015/native-darwin-amd64.json`. Проверочный скрипт поддерживает штатный Python 3.8; публичные rc32 archives не перезаписывались. Приватные отчёты не входят в release archives.
+
+Контракты и процедуры: `docs/protocol.md`, `docs/tooling.md`, `docs/environment-changes.md`, `docs/repository-cache.md`, `docs/operations.md`, `docs/telegram-approvals.md`, `docs/recovery.md`, `docs/testing.md`.
@@ -1,3 +1,8 @@
+> [!WARNING] Исторический документ
+> Не использовать как runbook текущей Balda. Актуальная локальная схема, пути и команды: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Текущий контейнер: `balda-mm-mac`; config: `/Users/admin/Docker/balda-mm-mac/config/config.yaml`; Obsidian MCP: `type: http`, `http://host.docker.internal:3101/mcp`.
+> Материал ниже сохранён только как история.
+
 # fast-rlm MCP HTTP integration with Balda

 > ## ⚠️ СТАТУС (2026-09-25)
@@ -1,4 +1,9 @@
-# План: фикс MCP для OpenAIModel
+# Исторический черновик: MCP для OpenAIModel
+
+> [!WARNING] Исторический черновик
+> Это список идей для прежней кодовой базы, а не действующий план Broker или свидетельство незакрытого дефекта текущего runtime.
+> Текущий контур и проверенные версии: [[personal/projects/balda/balda]] и [[personal/projects/balda/execution-broker]].
+> Детали ниже сохранены для истории; их реализацию нельзя выводить из наличия этого списка.

 ## Что сделать
 1. В `openAIChatRequest` добавить поле `Tools []openAIToolDefinition`
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # Mattermost на Kraken — деплой (arm64)

 > Создано 2026-09-26. Обновлено 2026-09-26. Статус: **✅ СЕРВЕР РАБОТАЕТ**.
@@ -1,86 +1,93 @@
-# Balda — Setup & Config
+# Balda — актуальный локальный запуск

-_Последнее обновление: 2026-06-24_
+Проверено: **2026-10-15** по обоим работающим контейнерам, Compose, конфигурации и реальным MCP-вызовам.

-## Хост
+Обзор: [[personal/projects/balda/balda|Balda]]. Broker, готовность кандидата и оставшаяся работа: [[personal/projects/balda/execution-broker|Execution Broker — текущий локальный контур]].

-Mac (Eagle), **Colima** (arm64, 8 CPU, 24 GB RAM, 100 GB sparse disk). Контейнеры собираются из исходников в `~/Developer/balda/`.
+## Что работает сейчас

-**Важно:** `buildx_buildkit_arm64builder0_state` volume — основная причина зависаний Zulip при сборке. См. [[tech/docker-mac-disk-issues]].
+| Параметр | Фактическое значение |
+| --- | --- |
+| Хост / контейнер | Mac / `balda-mm-mac` |
+| Канал | Mattermost |
+| Provider | `codex`, type `codex_acp`, reasoning effort `medium` |
+| Образ обоих инстансов | `balda-balda:upstream-6621b189-channel-fix`, image ID `sha256:e68ecaed4ceed2040c4592e9d4f8cd053d0b65d8086fa67ef1c99c8d10f42db1` |
+| Balda source | `6238856b5189f34f6e2a244e146cb6342e948623`: upstream `6621b189` + закоммиченное исправление контекста канала; Linux ARM64 binary SHA256 `94827ac2b57456c7f30bfd7a02fecd2d3ddb4e52a51af702f3f830720b56bf8d` |
+| Compose | `/Users/admin/Docker/balda-mm-mac/docker-compose.yml` |
+| Активный конфиг | `/Users/admin/Docker/balda-mm-mac/config/config.yaml` |
+| State / plugins | `/Users/admin/Docker/balda-mm-mac/state` |
+| Workspace | `/Users/admin/Docker/balda-mm-mac/work` |
+| Home volume | `balda_balda-home`, mounted в `/home/node` |

-## Компоненты
+Config bind-mounted в `/workspace/.config/balda` read-only для контейнера; state и work доступны ему на запись. Файл `~/Developer/balda/.config/balda/config.yaml` относится к отдельному dev checkout и не управляет этим контейнером.

-| Бот | Порт | Провайдер | Dockerfile |
-|-----|------|-----------|------------|
-| **Валера** (`balda-agent-valera-1`) | `:8091` | DeepSeek | `Dockerfile` (одинаковый) |
-| **Клавдий** (`claudio-agent-claudio-1`) | `:8092` | Claude (через proxy :3457) | `Dockerfile.claudio` (тот же + arm64 target) |
+## Eagle и общие инструменты

-## Расположение
+Eagle работает на том же Mac в `balda-mm-eagle`; Compose, config, state и work находятся в `/Users/admin/Docker/balda-mm-eagle/`, service — `eagle`, отдельный home volume — `balda_eagle-home`. Образы обоих инстансов одинаковы. Авторизации Codex раздельные; при обновлении home volumes сохранены. Серверная проверка: models endpoint отвечает HTTP 200 у обоих. У @balda реальная генерация в отдельной ephemeral read-only сессии завершилась ответом `AUTH_OK` и `turn.completed`; исходный аккаунт сохранён. После перечитывания credentials Mattermost websocket подключён, существующие беседы не сбрасывались. Не копировать auth между разными аккаунтами.

-| Item | Валера | Клавдий |
-|------|--------|---------|
-| Compose | `~/Docker/balda-agent/docker-compose.yaml` | `~/Docker/claudio-agent/docker-compose.yaml` |
-| Config volume | `~/Docker/balda-agent/.config/balda/` | `~/Docker/claudio-agent/.config/balda/` |
-| Env | `~/Docker/balda-agent/.env` | `~/Docker/claudio-agent/.env` |
-| Dev repo (общий) | `~/Developer/balda/` | `~/Developer/balda/` |
+У обоих включены одинаковые Obsidian, Execution Broker и Prism MCP, одинаковые права runtime и managed plugin `execution-broker` rc.32. Проверены реальные initialize/tools-list: Obsidian — 15, Broker — 26, Prism — 5 инструментов; списки совпадают. Eagle дополнительно имеет `asana-readonly`, URL `http://asana-readonly:3100/mcp` в приватной Docker-сети. Отдельный контейнер `balda-eagle-asana-readonly` не публикует порт на хост. Реальное чтение Asana прошло; все пять операций изменения и запись заметок в файл отклоняются сервером.

-**Важно:** оба бота собираются из одного репозитория `~/Developer/balda/` (normahq/balda fork). Разница — только в config.yaml (провайдер) и .env (Zulip credentials).
+В обоих конфигурациях provider `codex_acp`, reasoning `medium`, явный model отсутствует. Последние записи Codex подтверждают `gpt-6.1-sol` у обоих. При выравнивании инструментов настройки основной модели не менялись. `balda.nats.max_store` у обоих — `16gb`.

-## Образ
+## Продолжение задач

- Собирается локально из `Dockerfile` (Go, multi-stage: golang:1.26 → alpine:3)
- Target: `linux/arm64` (статический Go бинарник)
- Image name: `balda-agent-valera:latest` / `claudio-agent-claudio:latest` (по имени compose проекта)
- Entrypoint: `/usr/local/bin/balda` (ELF arm64)
- Сеть: `balda_default` (bridge, внешняя, создаётся через docker network create)
+Тип канала берётся из канонической привязки сессии. Для Mattermost он остаётся `mattermost`, включая native waits и возврат результата; `human.delivery_channel=telegram` меняет только доставку одобрения. SQLite/PostgreSQL migration исправляет прежний сгенерированный Telegram-заголовок в сохранённых ACP instructions без `/reset`, сохраняя provider thread, capability snapshot и историю. Согласованные Linux SQLite snapshots обоих инстансов прошли integrity/foreign-key checks; последнее обновление сохранило все 2072 прежних события основного инстанса, locator, capability snapshots, provider threads и auth. Плагин rc32 совместим с текущей Balda и не требовал переустановки; immutable revisions сохранены. Актуальный backup и отчёты: `state/balda-upstream-hooks-20261015/`; backup миграции контекста также сохранён в `state/balda-channel-context-20261015/`.

-## Запуск / рестарт
+В этой версии generic webhooks выполняют изолированные задания. Они не продолжают исходную сессию. Старые `routes.*.path`, `envelope.target`, `key_from_body`, `mode` и `fallback_to` удалены из конфигурации; listener задаётся через `balda.http`. Сейчас он слушает loopback `127.0.0.1:8095`.
+
+Плагин rc32 использует `balda.state` и штатный `balda.session.wait`: наблюдатель вооружается до Start/retry и возвращается в исходную сессию. Managed lifecycle и restart-контракт проверены. Реальный conversational smoke с моделью, фактическим Telegram Human ответом, шестью проверенными артефактами, `cleanup=done` и единственным итоговым сообщением в исходной Mattermost-беседе прошёл; Story/Task закрыты и waits отменены. Реальная беседа прошла также HTTP 502 и restart Broker/Prism/Balda во время Human pause: тот же run/Story, provider thread и deadline восстановились, фактический Telegram approval принят, шесть артефактов проверены, `cleanup=done`. Story/Task закрыты, waits отменены, сообщение о завершении restart-приёмки подтверждено через Mattermost API. Старые callbacks Broker на `:8090` приостановлены, недоставленные cursors сохранены. Native wait acceptance не является подтверждением доставки сообщения провайдером.
+
+Оба инстанса имеют также одинаковые пять глобальных Codex skills и одинаковую Codex tool policy; различий не найдено. Обновление плагина выполнено штатной переустановкой из нового operator source с сохранением `plugin-data/execution-broker`, старых revisions/catalog snapshots и содержимого прежнего marketplace. Существующие сессии не сбрасывались.
+
+## Изменения и перезапуск
+
+| Изменение | Действие |
+| --- | --- |
+| Только host `config/config.yaml` | `docker restart balda-mm-mac`: процесс перечитывает конфигурацию при старте |
+| `.env`, environment, mounts, service definition | Из каталога Compose: `docker-compose up -d balda` |
+| Новый image | Сначала получить или собрать выбранный образ, затем `docker-compose up -d balda`; в действующем Compose нет build-секции |
+| Код в checkout | Сам по себе не обновляет образ; нужен отдельный build и применение выбранного image |
+| Изменение catalog / skills существующей беседы | Обычный `/reset` для выбора текущего capability snapshot |
+
+`docker restart` не применяет изменения Compose или `.env`. `--force-recreate` для изменения только config.yaml не требуется. До смены image сохраняют согласованный state backup и прежний image/config для отката.
+
+## Plugins, skills и инструкции
+
+Managed plugin revisions неизменяемые; вручную редактировать их содержимое в state нельзя. Документация проекта описывает управление пакетами через **Backoffice → Operations → Plugins**: Installed/Marketplaces, review exact revision, install/upgrade/enable/disable/rollback/remove. Проверять доступность поверхности на используемой версии, а не переносить команды из архивных runbooks: [plugins reference](https://github.com/baldaworks/balda/blob/main/docs/reference/plugins.md).
+
+Management не сбрасывает существующие сессии. Новая сессия выбирает текущий catalog; существующая принимает capabilities через обычный `/reset`. Standalone skills также редактируются отдельно от уже закреплённого session snapshot.
+
+[[personal/projects/balda/soul|Global instruction]] содержит сверенный снимок `balda.global_instruction`. [[personal/projects/balda/workspace-context|Provider context]] описывает `runtime.providers.codex.system_instructions`; сейчас отдельное значение не настроено. Редактирование заметки не меняет работающий конфиг.
+
+## Codex ACP
+
+Reasoning effort в активном конфиге — `medium`. Авторизация CLI хранится в home volume. Для восстановления существующего @balda: `docker exec -it balda-mm-mac codex login --device-auth`, завершить вход в исходный аккаунт и проверить реальный запрос к провайдеру. `codex login status` подтверждает только наличие локальной авторизации и сам по себе не доказывает действительность токена на сервере. При необходимости перезапустить Balda для перечитывания auth; `/reset` не требуется. Для отдельного headless-входа используется команда из каталога Compose:

-**Валера:**
 ```bash
-cd ~/Docker/balda-agent
-docker-compose restart              # без пересборки, без перечитывания .env
-docker-compose up -d                # пересоздаёт контейнер с текущим .env
-docker-compose build && docker-compose up -d  # после изменений в коде
+docker-compose run --rm --entrypoint codex balda login --device-auth
 ```

-**Клавдий:**
+## Obsidian MCP
+
+Проверенный блок активной конфигурации находится в `runtime.mcp_servers`:
+
+```yaml
+runtime:
+  mcp_servers:
+    obsidian:
+      type: http
+      url: http://host.docker.internal:3101/mcp
+```
+
+Используется Streamable HTTP. Для Codex ACP SSE-конфигурацию из старых заметок не переносить. После изменения этого блока нужен перезапуск Balda.
+
+## Диагностика
+
 ```bash
-cd ~/Docker/claudio-agent
-# те же команды
+docker ps --filter name=balda-mm-mac
+docker logs --tail 120 balda-mm-mac
 ```

-**После изменений кода** (в `~/Developer/balda/`): `build && up -d` в каждом compose.
+Проверять успешный startup provider и подключение Mattermost. Не копировать токены, cookie или login URLs из логов в заметки.

-## .env (общие переменные)
-
-```env
-OPENAI_BASE_URL=https://api.deepseek.com/v1   # обязательна для deepseek provider
-# для claude provider не нужна
-```
-
-**Важно:** `docker-compose restart` не перечитывает `.env`. Только `docker-compose up -d`.
-
-## Известные грабли
-
-### 1. OPENAI_BASE_URL — обязательна для DeepSeek
-Norma не читает `base_url` из config.yaml для `provider: deepseek`. Читает env `OPENAI_BASE_URL`.
-Без неё запросы уходят на `api.openai.com` (401).
-
-### 2. DOCKER_OPTS — пустая строка убивает старт
-```env
-DOCKER_OPTS={"max_tokens": 2048, "temperature": 0.7}
-```
-Не пустая строка! Иначе `strconv.ParseFloat: parsing ""` при старте.
-
-### 3. exec format error на arm64
-Симптом: контейнер в crash-цикле, логи повторяют `exec /usr/local/bin/balda: exec format error`.
-Docker показывает `Up N hours` (накопленное время рестартов), но exec не работает.
-
-**Причина:** контейнер создан с `Platform: linux/amd64` (старый Docker Desktop или первый run без platform). Образ arm64, контейнер amd64 — несовместимость.
-
-**Фикс:** `docker-compose down; docker-compose up -d` — удаляет старый контейнер и создаёт новый с правильной платформой.
-
-### 4. После перезапуска нужно @mention для создания сессии
-Events API polling подхватывает сообщения только если есть активная сессия в теме.
-После рестарта: написать `@Валера <текст>` (или `@Клавдий`).
+Архив старых схем и шаблонов: [[personal/projects/archive/balda-reference-before-2026-10-14]].
@@ -1,49 +1,21 @@
-# Balda Soul — Global Instruction
+# Balda — global instruction

-> Это глобальная инструкция Балды (Валеры). Вставляется в system prompt каждой сессии.
-> После правки — синхронизировать вручную в `~/Developer/balda/.config/balda/config.yaml`
-> (поле `balda.global_instruction`), затем перезапустить Балду.
+Проверено: **2026-10-15**. Ниже точный снимок `balda.global_instruction` из активного `/Users/admin/Docker/balda-mm-mac/config/config.yaml`. Он относится к контейнеру `balda-mm-mac`; dev-конфиг в `~/Developer/balda` является отдельным файлом.

---
+Порядок инструкций в Balda: built-in → `balda.global_instruction` → `runtime.providers.<provider_id>.system_instructions`. Текущий provider — `codex`; отдельные provider-level инструкции не настроены.

-Ты **Валера** — практичный AI-ассистент команды в Zulip.
+## Действующее значение

-## Стиль
+Ты Балда — AI-помощник в Mattermost.

- Отвечай на языке собеседника (русский или English).
- Кратко и конкретно. Никакой воды, никаких вступлений.
- Показывай результат, а не процесс.
- Код и команды — в fenced code blocks.
- Не объясняй что ты сделал — пользователь видит результат.
+Отвечай кратко и по делу. Русский или English — как к тебе обратились.
+Код и команды в fenced code blocks.
+Не объясняй процесс, показывай результат.
+В каналах ты отвечаешь только когда тебя упомянули через @balda.
+For execution-broker calls, use the exact current Balda Session ID shown under Session in the system instruction as chat_id and an empty topic_id. The channel type is also shown there; never infer Telegram from numeric Mattermost metadata. Numeric chat_id=0 and topic_id=0 are transport placeholders and must never be sent to execution tools. Never ask the user to supply a Session ID. If an existing Story has chat_id=0 or topic_id=0, create a new Story and Task with the current Session ID and new Story and run idempotency keys before starting a new execution. Do not reuse the placeholder-bound Story because Prism cannot sync it. At a coding approval question, forward the exact free-text requirement change with execution_respond for that run; Callee will regenerate the plan and ask again without a new Story or run. Reply approved only after the user approves the latest plan.

-## Работа
+## Как поддерживать этот снимок

- Берёшь задачу и доводишь до конкретного результата.
- Если задача большая или неоднозначная — уточни объём, прежде чем начать.
- Возвращай что-то осязаемое: код, файл, ответ, список шагов.
- Не останавливайся на полпути — если начал, закончи.
+Изменение заметки само по себе не меняет production-конфигурацию. Изменение глобальных инструкций применяется отдельно через активный host config и перезапуск Balda по [[personal/projects/balda/setup|runbook]]. При последующей актуализации заметку снова сверяют с этим файлом.

-## Ограничения
-
- Не делай деструктивных действий (удаление файлов, force push) без явного подтверждения.
- Не пиши в main/master напрямую. Используй ветки.
- Если нужны credentials или secrets — попроси, не угадывай.
-
-## Память
-
- Durable факты и предпочтения команды сохраняй через `balda.memory.remember`.
- Не сохраняй промежуточные состояния задач и временный контекст.
- Сохраняй: соглашения, предпочтения, архитектурные решения, стек.
-
-## Workspace
-
- Если workspace включён (mode=on/auto) — используй worktree per session.
- `balda.workspace.import` — перед началом крупных правок.
- `balda.workspace.export` — после завершения, Conventional Commit message.
- Не делай merge/rebase через raw git если доступны workspace MCP tools.
-
-## Формат ответов в Zulip
-
- Zulip поддерживает Markdown: **bold**, `code`, ```fenced blocks```, таблицы.
- Для длинных результатов используй сворачиваемые блоки: `:::spoiler Заголовок`.
- Цитируй исходное сообщение только если нужна явная привязка.
+Исторический шаблон для Валеры/Zulip сохранён в [[personal/projects/archive/balda-reference-before-2026-10-14]]. Контекст конкретного provider описан в [[personal/projects/balda/workspace-context]].
@@ -1,54 +1,22 @@
-# Balda Workspace Context
+# Balda — provider context

-> Provider-level `system_instructions` — дополнение к soul.md для конкретного провайдера.
-> Задаётся в `~/Developer/balda/.config/balda/config.yaml` под
-> `runtime.providers.claude_code.system_instructions`.
+Проверено: **2026-10-15** по активному конфигу `/Users/admin/Docker/balda-mm-mac/config/config.yaml`.

---
+Текущий provider — `codex`, type `codex_acp`, reasoning effort `medium`. Поле `runtime.providers.codex.system_instructions` **не настроено**; эта заметка не объявляет Balda привязанной к одному репозиторию.

-## Текущий контекст
+Дополнение для этого provider задаётся в активном host config, отдельно от [[personal/projects/balda/soul|global instruction]]. Пример структуры:

-Рабочий проект и стек пока не заданы. Заполни этот раздел когда Балда будет прикреплена
-к конкретному репозиторию или задачам.
-
-Шаблон для заполнения:
-```
-## Проект
-
- Репо: ~/Developer/<project-name>
- Стек: <language/framework>
- Основная ветка: main
-
-## Команда
-
- alex (owner) — говорит по-русски, можно и по-английски
- <другие участники>
-
-## Соглашения
-
- Стиль коммитов: Conventional Commits (feat/fix/chore/docs)
- PR: через gh cli, base=main
- Тесты: <framework>
- Линтер: <tool>
-
-## Workflow
-
- Задачи приходят в Zulip топик
- Результат: коммит в ветку + краткий отчёт в тот же топик
-```
-
-## Провайдер
-
-`claude_code_acp` с моделью `claude-sonnet-4-6`.
-
-Если нужны особые флаги модели:
 ```yaml
 runtime:
  providers:
-    claude_code:
-      type: claude_code_acp
+    codex:
+      type: codex_acp
      system_instructions: |
-        <вставить сюда содержимое этого файла>
-      claude_code_acp:
-        model: claude-sonnet-4-6
+        <контекст и соглашения для этого provider>
+      codex_acp:
+        reasoning_effort: medium
 ```
+
+Пример — шаблон, а не установленная конфигурация. Описание конкретного проекта должно содержать точный repository/worktree, задачу, критерии приёмки и команды проверок; стек определяется проектом. Изменение заметки не применяет эти настройки к контейнеру.
+
+Пути, перезапуск и session boundaries: [[personal/projects/balda/setup]]. Старый Claude/Zulip template: [[personal/projects/archive/balda-reference-before-2026-10-14]].
@@ -1,7 +1,7 @@
 ---
 title: Autonomous Agent Safety Patterns
 created: '2026-05-24'
-updated: '2026-05-24'
+updated: '2026-10-14'
 type: concept
 tags: [agent, security, architecture, executor, rules]
 sources:
@@ -10,8 +10,8 @@ sources:
  - wiki/personal-os-agent-rules.md
 confidence: high
 related:
-  - "[[concepts/executor-security-incident]]"
-  - "[[concepts/executor-orchestrator]]"
+  - "[[personal/projects/personal-os/executor-security-analysis]]"
+  - "[[personal/projects/personal-os/executor-orchestrator-redesign]]"
  - "[[personal-os-agent-rules]]"
 ---

@@ -62,7 +62,7 @@ session context.

 ## The Auto-Approve Table Pattern

-From [[concepts/executor-orchestrator]]: instead of blanket trust or blanket
+From [[personal/projects/personal-os/executor-orchestrator-redesign]]: instead of blanket trust or blanket
 denial, classify actions by risk tier:

 | Risk | Action type | Default |
@@ -108,6 +108,6 @@ can be reviewed without running the agent:

 ## See Also

- [[concepts/executor-security-incident]] — incident post-mortem with full timeline
- [[concepts/executor-orchestrator]] — post-incident architecture (orchestrator pattern)
+- [[personal/projects/personal-os/executor-security-analysis]] — incident post-mortem with full timeline
+- [[personal/projects/personal-os/executor-orchestrator-redesign]] — post-incident architecture (orchestrator pattern)
 - [[personal-os-agent-rules]] — Eagle's specific rules derived from these patterns
@@ -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 | [[personal/projects/virfield\|Virfield v2]] | `127.0.0.1:7780` by default | separate system LaunchDaemons; dashboard integration not verified |
+| virfield | [[personal/projects/virfield\|Virfield (Tart + SSH nodes)]] | `127.0.0.1:7780` by default | system Virfield LaunchDaemon; dashboard integration not verified |

 ### ML

@@ -328,7 +328,7 @@ When a launchd cron is created and `launchctl print gui/<uid>/<label>` shows `la
 - Backend create now rejects non-`every` for launchd (frontend validator also blocks)
 - `_list_launchd_crons()` now shows ALL plists (schedule: "none (manual)" if no StartInterval/StartCalendarInterval)

-**Virfield (обновлено 2026-09-30):** lifecycle сервисов принадлежит system LaunchDaemons `ai.virfield.virfieldd` и `ai.virfield.lume`, работающим от VM owner. Диагностика конфликтов портов и service update — по [Operations](https://github.com/mallexxx/virfield/blob/main/docs/OPERATIONS.md#system-services). Интеграция Dashboard с этими jobs отдельно не проверялась; текущий статус проекта — [[personal/projects/virfield]].
+**Virfield (сверено 2026-10-14):** текущий runtime — Tart + SSH nodes; lifecycle принадлежит system LaunchDaemon `ai.virfield.virfieldd` от VM owner. Старый отдельный `ai.virfield.lume` отключён и выгружен 2026-10-14 после проверки пустого VM inventory; порт 7777 закрыт, rollback-файлы сохранены. Service upgrade — по [Operations](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/OPERATIONS.md#service-upgrades). Интеграция Dashboard с job отдельно не проверялась; текущий статус — [[personal/projects/virfield]].

 ---

@@ -5,7 +5,7 @@ aliases:
  - "Spawned Worker Pattern"
  - "executor-orchestrator-redesign"
 created: '2026-05-14'
-updated: '2026-05-31'
+updated: '2026-10-14'
 tags:
  - personal-os
  - executor
@@ -15,7 +15,7 @@ related:
  - "[[personal/projects/personal-os/executor-v2-redesign]]"
  - "[[personal/projects/personal-os/executor-spawning-research]]"
 ---
-> ⛔ **НЕ РЕАЛИЗОВАНО / ИСТОРИЧЕСКОЕ (2026-10-03).** Personal OS выключен. См. [[personal/projects/personal-os/personal-os-status-2026-10]].
+> ⛔ **НЕ РЕАЛИЗОВАНО / ИСТОРИЧЕСКОЕ (2026-10-03).** старый Executor выключен; текущий контур указан в [[personal-os-status-2026-10]]. См. [[personal/projects/personal-os/personal-os-status-2026-10]].

 # Plan: Executor as Spawned Worker — Orchestrator Pattern

@@ -5,7 +5,7 @@ aliases:
  - "executor-v2-redesign"
  - "Executor v2"
 created: '2026-04-30'
-updated: '2026-05-31'
+updated: '2026-10-14'
 tags:
  - personal-os
  - executor
@@ -17,7 +17,7 @@ related:
 ---
 # Executor v2 Redesign

-> ⛔ **ИСТОРИЧЕСКОЕ (2026-10-03).** Реализовано в репо, кроны на паузе; Personal OS выключен.
+> ⛔ **ИСТОРИЧЕСКОЕ (2026-10-03).** Реализовано в репо, кроны на паузе; старый Executor выключен; текущий контур указан в [[personal-os-status-2026-10]].
 > См. [[personal/projects/personal-os/personal-os-status-2026-10]] · [[personal/projects/personal-os/personal-os-failed-approaches]].

 **Date**: 2026-04-30  
@@ -2,12 +2,12 @@
 title: Hermes Cron Jobs
 aliases: [hermes cron, scheduled jobs, cron jobs]
 tags: [personal-os, hermes, automation, cron]
-updated: 2026-06-24
+updated: '2026-10-14'
 ---

 # Hermes Cron Jobs

-> ⚠️ **Снимок на 2026-06-24.** Personal OS выключен (2026-10-03), кроны personal-os не возобновляются.
+> ⚠️ **Снимок на 2026-06-24.** старый Executor выключен; текущий контур указан в [[personal-os-status-2026-10]] (2026-10-03), кроны personal-os не возобновляются.
 > См. [[personal/projects/personal-os/personal-os-status-2026-10]].

 All scheduled jobs running in Hermes on Eagle. Managed via **Eagle Dashboard → Crons tab** (`http://localhost:8880`).
@@ -1,16 +1,16 @@
 ---
 title: Hermes Deployment Patterns
 created: '2026-05-29'
-updated: '2026-05-29'
+updated: '2026-10-14'
 type: concept
 namespace: personal
 tags: [hermes, architecture, agent, eagle, kraken, infra]
 sources: []
 confidence: medium
 related:
-  - "[[tech/hermes-eagle-mac]]"
-  - "[[tech/hermes-docker-kraken]]"
-  - "[[tech/hermes-kraken-api]]"
+  - "[[family/how-to/hermes-eagle-mac]]"
+  - "[[family/how-to/hermes-docker-kraken]]"
+  - "[[family/how-to/hermes-kraken-api]]"
  - "[[personal-os-architecture]]"
 ---

@@ -56,9 +56,9 @@ Config volume: `…/docker/hermes/config` → `/opt/data` (`HERMES_HOME`).
 `No user exists for uid <N>` **до** чтения ключа. Записать запись изнутри нельзя (`/etc/passwd`
 root-owned) → либо bind-mount готового passwd, либо `useradd` в **Dockerfile**, если образ
 действительно собирается локально. Проверять `docker inspect --format '{{.Config.Image}}'` +
-наличие `build:` в compose **до** правки Dockerfile. Подробности: [[tech/hermes-docker-kraken]].
+наличие `build:` в compose **до** правки Dockerfile. Подробности: [[family/how-to/hermes-docker-kraken]].

-See [[tech/hermes-docker-kraken]].
+See [[family/how-to/hermes-docker-kraken]].

 ## Pattern 3: Kraken API Server (OpenAI-compat)

@@ -71,7 +71,7 @@ See [[tech/hermes-docker-kraken]].
 The tunnel terminates at cloudflared running with `network_mode: host`,
 hitting `localhost:8642` directly.

-See [[tech/hermes-kraken-api]].
+See [[family/how-to/hermes-kraken-api]].

 ## Comparison

@@ -1,7 +1,7 @@
 ---
 title: Hermes — Native (Eagle) vs Docker (Kraken) Deployment
 created: '2026-05-22'
-updated: '2026-05-22'
+updated: '2026-10-14'
 last_synced: '2026-05-22'
 type: comparison
 namespace: work
@@ -59,7 +59,7 @@ sources:
 - `--init` флаг обязателен (zombie reaping)
 - `--network=host` для доступа к Zulip на том же хосте
 - Vault монтируется через `-v /home/kraken/obsidian:/vault`
- Полный набор правил → [[tech/hermes-docker-kraken]]
+- Полный набор правил → [[family/how-to/hermes-docker-kraken]]

 ## Общее для обоих

@@ -79,7 +79,7 @@ sources:

 ## Связанные страницы

- [[tech/hermes-eagle-mac]] — детали настройки на Eagle
- [[tech/hermes-docker-kraken]] — детали Docker деплоя на Кракен
+- [[family/how-to/hermes-eagle-mac]] — детали настройки на Eagle
+- [[family/how-to/hermes-docker-kraken]] — детали Docker деплоя на Кракен
 - [[personal-os-architecture]] — полная карта системы
- [[tech/kraken-network]] — сетевая топология
+- [[family/how-to/kraken-network]] — сетевая топология
@@ -7,7 +7,7 @@ tags:
  - synthesis
  - vault
 created: '2026-05-19'
-updated: '2026-05-19'
+updated: '2026-10-14'
 type: concept
 confidence: 0.9
 sources:
@@ -18,7 +18,7 @@ sources:
 ---
 # Knowledge Lifecycle — From Session to Permanent Memory

-Синтез: как знание движется от рабочей сессии к постоянной памяти в personal-os. Объединяет [[concepts/agent-memory-architecture]], [[concepts/vault-strategy]] и [[wiki-ingest-process]].
+Синтез: как знание движется от рабочей сессии к постоянной памяти в personal-os. Объединяет [[personal/projects/personal-os/agent-memory-architecture]], [[personal/projects/personal-os/obsidian-vault-strategy]] и [[wiki-ingest-process]].

 ## Общая схема

@@ -76,7 +76,7 @@ Procedural Memory (skills/, workflows)

 ## Связанные страницы

- [[concepts/agent-memory-architecture]] — когнитивная таксономия памяти (episodic/semantic/procedural)
- [[concepts/vault-strategy]] — три задачи vault: enrichment, LLM wiki, proactive research
+- [[personal/projects/personal-os/agent-memory-architecture]] — когнитивная таксономия памяти (episodic/semantic/procedural)
+- [[personal/projects/personal-os/obsidian-vault-strategy]] — три задачи vault: enrichment, LLM wiki, proactive research
 - [[wiki-ingest-process]] — hash-based incremental ingest из raw/ symlinks
 - [[personal-os-self-modification]] — как система эволюционирует через корректировки
@@ -1,7 +1,7 @@
 ---
 title: Multi-Agent Design Patterns
 created: '2026-05-25'
-updated: '2026-05-25'
+updated: '2026-10-14'
 type: concept
 namespace: work
 tags: [agent, architecture, system]
@@ -11,16 +11,16 @@ sources:
  - wiki/concepts/autonomous-agent-safety.md
  - wiki/concepts/agent-memory-architecture.md
 related:
-  - "[[concepts/executor-orchestrator]]"
-  - "[[concepts/autonomous-agent-safety]]"
-  - "[[concepts/agent-memory-architecture]]"
+  - "[[personal/projects/personal-os/executor-orchestrator-redesign]]"
+  - "[[personal/projects/personal-os/autonomous-agent-safety]]"
+  - "[[personal/projects/personal-os/agent-memory-architecture]]"
 ---

 # Multi-Agent Design Patterns

 Synthesis of recurring patterns across the personal-os multi-agent system
-and related agent architectures. Distilled from [[concepts/executor-orchestrator]],
-[[concepts/autonomous-agent-safety]], and [[concepts/agent-memory-architecture]].
+and related agent architectures. Distilled from [[personal/projects/personal-os/executor-orchestrator-redesign]],
+[[personal/projects/personal-os/autonomous-agent-safety]], and [[personal/projects/personal-os/agent-memory-architecture]].

 ## Pattern 1 — Orchestrator / Worker Split

@@ -42,7 +42,7 @@ orchestrator has the only escalation path to the human.
 require escalation. Publish the table explicitly.

 **Why:** Autonomous agents fail catastrophically when they expand scope
-unexpectedly (see [[concepts/executor-security-incident]]). Explicit tables
+unexpectedly (see [[personal/projects/personal-os/executor-security-analysis]]). Explicit tables
 make failure modes visible.

 **Implementation:** Message-type-based approval table. Unknown message types
@@ -64,7 +64,7 @@ knowledge (semantic memory) from immutable facts (procedural/episodic).
 fail to retain important session-to-session knowledge.

 **In personal-os:** status.md (working) / wiki pages (semantic) /
-SCHEMA.md + vault-filling-guide (procedural). See [[concepts/agent-memory-architecture]].
+SCHEMA.md + vault-filling-guide (procedural). See [[personal/projects/personal-os/agent-memory-architecture]].

 **Pattern rule:** Never update semantic memory from within an active session.
 Crystallize post-session. Never trust working memory as a source of truth
@@ -101,7 +101,7 @@ question in list" do not benefit from LLM reasoning and introduce failure modes.

 ## See Also

- [[concepts/executor-orchestrator]] — concrete orchestrator/worker implementation
- [[concepts/autonomous-agent-safety]] — safety checklist derived from incidents
- [[concepts/agent-memory-architecture]] — memory taxonomy for LLM agents
- [[entities/psychologist-app]] — dual-agent architecture (patterns 1 and 4)
+- [[personal/projects/personal-os/executor-orchestrator-redesign]] — concrete orchestrator/worker implementation
+- [[personal/projects/personal-os/autonomous-agent-safety]] — safety checklist derived from incidents
+- [[personal/projects/personal-os/agent-memory-architecture]] — memory taxonomy for LLM agents
+- [[personal/projects/psychologist-app/overview]] — dual-agent architecture (patterns 1 and 4)
@@ -1,7 +1,7 @@
 ---
 title: Multi-Host Cron Topology
 created: '2026-05-27'
-updated: '2026-05-27'
+updated: '2026-10-14'
 type: concept
 namespace: personal
 tags: [system, agent, eagle, kraken, pipeline, sync]
@@ -12,8 +12,8 @@ sources: []
 # Multi-Host Cron Topology

 Synthesis of how scheduled jobs are distributed across Eagle and Kraken.
-Co-occurs in [[tech/hermes-eagle-mac]], [[tech/hermes-docker-kraken]],
-[[concepts/watchlist-automation]], and [[personal-os-agent-rules]].
+Co-occurs in [[family/how-to/hermes-eagle-mac]], [[family/how-to/hermes-docker-kraken]],
+[[family/projects/watchlist-automation]], and [[personal-os-agent-rules]].

 ## Design Principle

@@ -36,7 +36,7 @@ media-pipeline tasks (watchlist, arr stack). Duplication is a bug.

 Eagle crons are Hermes agent jobs — require LLM, vault access,
 Asana context. All run via Hermes native (not Docker). See
-[[tech/hermes-eagle-mac]].
+[[family/how-to/hermes-eagle-mac]].

 ## Kraken (RPi5) — Pipeline Jobs

@@ -48,7 +48,7 @@ Asana context. All run via Hermes native (not Docker). See

 Kraken crons are shell scripts or Python3 — deterministic, no LLM.
 Run via Hermes cron on Kraken Hermes instance (port 8642, Docker).
-See [[tech/hermes-docker-kraken]] and [[concepts/watchlist-automation]].
+See [[family/how-to/hermes-docker-kraken]] and [[family/projects/watchlist-automation]].

 ## Migration History

@@ -66,6 +66,6 @@ entries or double-adds. Check: `hermes cronjob list` on both hosts.
 ## See Also

 - [[personal-os-agent-rules]] — Eagle's rules and allowed writes
- [[tech/hermes-eagle-mac]] — Eagle Hermes config
- [[tech/hermes-docker-kraken]] — Kraken Hermes Docker setup
- [[concepts/watchlist-automation]] — Full watchlist flow
+- [[family/how-to/hermes-eagle-mac]] — Eagle Hermes config
+- [[family/how-to/hermes-docker-kraken]] — Kraken Hermes Docker setup
+- [[family/projects/watchlist-automation]] — Full watchlist flow
@@ -1,3 +1,7 @@
+> [!IMPORTANT] Актуальная конфигурация для Balda (2026-10-09)
+> Текущая Balda использует Codex ACP и Streamable HTTP: `type: http`, URL `http://host.docker.internal:3101/mcp`.
+> Указания ниже про Balda + SSE или `/sse` относятся к прежним клиентам/развёртываниям. Канонический runbook: [[personal/projects/balda/setup]].
+
 # Obsidian MCP — текущая архитектура

 ## Факт: что стоит сейчас
@@ -5,7 +5,7 @@ aliases:
  - "obsidian-vault-strategy"
  - "LLM Wiki Plan"
 created: '2026-05-15'
-updated: '2026-05-31'
+updated: '2026-10-14'
 tags:
  - personal-os
  - obsidian
@@ -14,7 +14,7 @@ tags:
  - llm-wiki
 status: active
 related:
-  - "[[wiki/personal-os-architecture]]"
+  - "[[personal/projects/personal-os/personal-os-architecture]]"
  - "[[personal/projects/personal-os/executor-security-analysis]]"
 ---
 # Obsidian Vault Strategy & LLM Wiki Plan
@@ -546,5 +546,5 @@ skills/         → процедуры и workflows пошагово
 ---

 ## Связанные заметки
- [[wiki/personal-os-architecture|Personal OS Architecture]]
+- [[personal/projects/personal-os/personal-os-architecture|Personal OS Architecture]]
 - [[personal/projects/personal-os/executor-security-analysis|Executor Security Analysis]]
@@ -1,16 +1,39 @@
 # Personal OS — план действий E1–E5

-Дата: 05.10.2026. Статус: **план подготовлен; реализация E1 ещё не начата**.
+Текущий runtime 14.10.2026: Asana collector заменён постоянным worker в основной
+`personal_os`, с Windmill schedule каждые пять минут, live roster scans каждые
+15 минут и events cursors. Все 28 живых списков проектов перечитаны, обнаружено
+35 620 memberships. Очередь изменений, связанные объекты и фоновая сверка
+продолжаются и показаны отдельно. Legacy read projection и общий writer lock
+реализованы; старый collector архивирован. [Контракт и проверка runtime](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
+
+Историческая сверка до этого rollout дала 21/28 по ID scan 06.10, 35 080
+memberships, 11 недоступных direct tasks и 1 685 внешних dependency targets.
+Эти числа не являются текущим live freshness отчётом.

 Основание: [исследование шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md), [архитектурные контракты](/Users/admin/Developer/personal-os/planning/personal-os-architecture-decision-2026-10-04.md), [контракт данных R2](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md). Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.

 ## Что делаем сейчас

-**Текущая итерация — E1: сделать проверяемой загрузку трёх Asana-проектов.** В её конце мы должны видеть полный доступный состав выбранных проектов, все принадлежности задач, доступную историю и дерево подзадач. Для каждого пробела будет причина, а для каждого запуска — воспроизводимый отчёт.
+**Дополнение 14.10.2026 — work items и контекст дизайнов реализованы и перенесены в основную БД.**
+Каждый локальный ворктри без принятой связи должен получать отдельный устойчивый
+work item на дашборде для ручного либо агентского резолва: привязать существующую
+работу/задачу, учитывать локально, исключить с причиной либо подготовить и завести
+задачу Asana. Повторный сбор сохраняет item и принятое решение. В контекст работы
+добавляются tech-design задачи Asana, опубликованные документы и их драфты
+Obsidian, включая драфты без Asana ID; смысловые совпадения проходят резолв.
+Порядок, действия и критерии приёмки — в [текущем плане GitHub и рабочих
+ситуаций](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md#work-items-и-tech-designs).
+Проверены устойчивые items, сохранение решений, цепочки дизайнов, отдельный
+вызов локальной модели из Windmill и безопасное создание задачи из черновика.
+Пользователь разрешил основной перенос; все 17 таблиц перенесены с совпадением
+полных хешей. Windmill и дашборд переключены на `personal_os`.
+
+**Текущая итерация — E1: сделать проверяемой загрузку Asana-проектов.** Пилот трёх проектов завершён; по его результату [расширен scope](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md). Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. В конце должны быть видны полный доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач. Для каждого пробела будет причина, для каждого запуска — воспроизводимый отчёт.

 Начальный порядок: Apple Team Meta Project → Apple Feature Flags Registry → Scheduled Rotations. Meta Project даёт разные типы объектов и известные примеры потерь; остальные проверяют переносимость решения. Размер полных проектов пока не измерен, поэтому длительность массовой выгрузки определяется после дешёвого обхода IDs.

-Первые страницы этих проектов уже проверены; найдены пропуски задач, комментариев и связей. **Полное покрытие ни одного из трёх проектов пока не доказано.** Готовность E1 не означает полноту всех источников или готовность персонального ранжирования.
+В исходном рабочем зеркале были пропуски задач, комментариев и связей. Тестовый E1 backfill теперь сверен с независимым ID-обходом всех трёх пилотов; [отчёт](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/README.md). Это не означает полноту всех источников, рабочего зеркала или готовность персонального ранжирования.

 ### Кто что делает

@@ -57,7 +80,7 @@

 Дорабатываются `db.js`, shape нормализованной задачи и версия схемы. Новая миграция использует существующий контракт source records/relations, насколько он уже реализован; если это ещё только проект R2, минимальные Asana-таблицы служат adapter storage с явным mapping в R2. Создание второго независимого реестра истины недопустимо.

-Названия и номер миграции фиксируются после E1.1; `005_asana_coverage.sql` — возможное имя, а не уже созданный файл. Подготовка выполняется на отдельной тестовой БД. Применение к рабочей БД входит в E1.5.
+Миграция подготовлена в `migrations/005_asana_coverage.sql` и применена только к отдельной тестовой БД. Применение к рабочей БД входит в E1.5.

 **Критические проверки:** два проекта у одной задачи; перенос секции; снятие membership; полный пустой список; ответ без поля; повтор одного payload; более старый source snapshot после нового; rollback транзакции при ошибке. Устаревший снимок сохраняется как наблюдение, но не перезаписывает более свежее текущее состояние. При равном timestamp и конфликтующем содержимом требуется повторная сверка, а не произвольный победитель.

@@ -83,7 +106,7 @@

 Исчезновение из полного списка означает «не наблюдается в этом контейнере». Оно может быть переносом, удалением или изменением доступа. Удаление объекта нельзя вывести из одного отсутствия в проекте; окончание известной связи и неизвестный статус самого объекта хранятся раздельно.

-**Предлагаемый артефакт:** `scripts/asana-project-backfill.js` с режимами audit/dry-run, выбранным scope, checkpoint/resume и отчётом; shared helpers в `asana.js`/`sync.js`. У CLI должен быть явный target БД и идентификатор run. Имена флагов фиксируются при реализации, готовой команды запуска пока нет.
+**Артефакт:** `scripts/asana-project-backfill.js` с выбранным scope, checkpoint/resume, бюджетом и явной целевой БД. Read-only ID-обход — `scripts/asana-coverage-scan-ids.js`; независимая сверка тестовой БД — `scripts/asana-coverage-verify.js`. Режим dry-run перечисляет только ID. Пробный полный backfill Meta Project запущен на отдельной тестовой БД; итоговая сверка ещё не готова.

 **Приёмка:** более одной страницы задач/stories/детей, глубина дерева больше одного уровня, повторные страницы, одинаковые timestamps, 403/429/5xx, обрыв процесса, expired offset, редактирование старого комментария и отсутствие поля проходят проверку.

@@ -228,10 +251,13 @@ flowchart LR

 | Пакет | Статус | Следующий проверяемый результат |
 |---|---|---|
-| E1.1 | planned — первый | Fixtures и исходный coverage report с воспроизведёнными потерями |
-| E1.2–E1.3 | planned — после контракта E1.1 | Хранение всех memberships и возобновляемый полный обход |
-| E1.4–E1.5 | planned — после проверок | Сверенный доступный корпус трёх проектов в рабочем зеркале |
-| E2–E3 | planned | Общий эталон и выбранный открытый механизм извлечения/графа |
+| E1.1 | verified — [отчёт и fixtures](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/README.md) | 6 тестов, независимый полный ID-обход SDK и source/local diff |
+| E1.2 | in_progress — схема и writer проверены на тестовой БД | Совместимый projection для старых читателей |
+| E1.3 | complete — три проекта загружены в отдельную тестовую БД | 7658 уникальных задач с потомками и 125 970 stories |
+| E1.4 | verified для трёх пилотов — [итоговые отчёты](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/README.md) | 4618/4618 исходных memberships; известных потерь и неполных разделов нет |
+| E1 expansion | постоянный worker запущен — [runtime и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026) | Живые списки 28/28 проектов сверены; очередь изменений и фоновые refresh видны отдельно. 21/28 относится к историческому backfill |
+| E1.5 | worker/projection/lock реализованы и проверены; начальная очередь догоняется | Windmill schedule 5 минут, живые cursors, независимые retries, E1 и совместимая legacy read projection; старый collector заменён |
+| E2–E3 | E2 in_progress, E3 planned | 486 работ с кандидатами модели; независимый эталон, semantic acceptance и сравнение graph-механизмов ещё не приняты |
 | E4–E5 | planned | Проверенные личные приоритеты и посильный контур внимания |

-**Первый пакет реализации: E1.1 — воспроизводимые проверки потерь и независимый отчёт покрытия Asana.**
+**Текущий runtime E1:** постоянный worker вместо checkpoint-only backfill. Он автоматически догоняет изменения и продолжает сверки; полнота оценивается по живым source cursors и queue gaps. Успешный batch не означает пустую очередь или актуальность всех связанных объектов.
@@ -1,5 +1,7 @@
 # Personal OS — архитектурный проект R2

+> Дополнение 10.10: строка «n8n/Node-RED не обоснованы» относилась к семантике истины, а не к оркестрации. Для визуальной исполняемой карты потоков развёрнут Windmill (open source, durable runs, холст) на том же PostgreSQL; правила, claims и принятие остаются кодом и таблицами. См. [[personal-os-windmill-system-map-2026-10-10]].
+
 > Актуальное уточнение 05.10: [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Условия: личный доступ, открытые компоненты, без изменения систем компании. Очередность: покрытие проектов → эталон и явные связи → испытание Cognee/Graphiti → роли и важность → внимание и ретроспекция. Исследование выявило потери Asana; исправления и модельные прогоны ещё не выполнены. Корпоративный shortlist больше не определяет первый этап.

 > Дополнение 04.10: [понимание потока работ и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Приоритет проверки — покрытие корпуса, обнаружение связей, текущая ситуация и роль пользователя. Это исследовательское уточнение для согласования; выбранный PostgreSQL core сохраняется, новые модели и graph runtime не внедрены.
@@ -1,9 +1,11 @@
 ---
 namespace: work
-tags: [system, architecture]
-last_updated: 2026-04-28
-virfield_updated: 2026-09-30
-confidence: 1.0
+tags:
+  - system
+  - architecture
+last_updated: 2026-04-28T00:00:00.000Z
+virfield_updated: '2026-10-14'
+confidence: 1
 ---

 # Personal OS — Architecture
@@ -0,0 +1,290 @@
+---
+
+> Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной `personal_os`. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. [Контракт и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
+
+date: '2026-10-09'
+status: local-rlm-stand-ready
+tags:
+  - personal-os
+  - data-analysis
+  - workflow
+  - knowledge-graph
+updated: '2026-10-14'
+---
+# Personal OS — анализ выгружаемых данных: контекст, связывание и workflow
+
+> Историческая проверка launchd до замены worker 14.10.2026: `com.personalos.asana-expansion-e1` не найден в `gui/501`. Поэтому запись о загруженном агенте 10.10 ниже не подтверждает текущий фоновый backfill. `com.personalos.work-evidence` и `com.personalos.db-browser` загружены и работают.
+
+**Историческая сверка E1 до замены worker 14.10:** 21/28 проектов по ID scan 06.10, 35 080/35 080 memberships, 11 недоступных прямых задач и 1 685 отсутствующих внешних dependency targets. Это не новый live-ID обход. Текущий [план E1–E5](/Users/admin/Developer/personal-os/planning/personal-os-action-plan-2026-10-05.md).
+
+Дата исходного исследования: 2026-10-09, Asia/Bishkek. Обновлено: 2026-10-14 по сохранённым результатам БД, двум resolver jobs и проверке дашборда.
+
+**Статус на 14.10.2026:** локальный стенд прошёл синтетические проверки и реальные одиночные извлечения на Asana. В основной БД 486 анализов / 486 работ (480 completed), все 12 244 claims — кандидаты. Рабочая выборка и схема v2 существуют; независимый эталон качества и semantic acceptance не завершены. RLM-циклы ранних прогонов не дошли до FINAL. Отдельный resolver ворктри через Windmill прошёл две попытки, 7/7 цитат и оба input hash проверены; смысловые связи не приняты. Архивный пакет выполнен вручную, постоянный incoming-контур и graph runtime не подключены. Подробности: [[work-claims-results-2026-10-12]] и [[personal-os-rlm-stand-results-2026-10-10]].
+
+**Согласованный порядок:** проверяемый локальный RLM на небольшом наборе связных работ → расширение на архив → подключение incoming. Подробный текущий статус и шаги — в разделе 9.
+
+Связанные документы: [[personal-os-action-plan-2026-10-05]], [[personal-os-six-layer-analysis-2026-10-05]], [[personal-os-evidence-graph-design-2026-10-04]], [[personal-os-system-review-index]].
+
+## 1. Задача
+
+Превратить выгрузки Asana, GitHub, Mattermost, Zoom и проектные заметки в общий рабочий контекст:
+
+- к какой работе, инициативе, компоненту или процессу относится запись;
+- как она связана с другими материалами;
+- что изменилось: предложение, решение, отмена, реализация, review, выпуск или открытая работа;
+- как это пересекается с текущими задачами, опытом и областью Алекса;
+- какие проверенные сведения должны получить планирование, career-сценарии и ретроспекция.
+
+Связующее звено — общий слой контекста. **Состояние проекта (`project truth`) — одна из его обновляемых проекций**, наряду с историей решений, участием и обязательствами.
+
+Текущий прототип `project-evidence.js` / `project-truth.js` с ручным реестром двух случаев помечен **[УДАЛИТЬ]** в [[project-truth-analyzer]]. Это решение относится к прототипу, а не к требованию понимать состояние проектов. Код этим обсуждением не удалён. Общий аналитический workflow не был запущен; содержательная сводка недели в чате была ручным анализом, а не результатом настроенного анализатора.
+
+## 2. Что проверено в выгрузке Asana
+
+Текущая E1-догрузка использует сохранённый scope от 6 октября:
+
+- 28 проектов для полного перечисления задач: 26 по признаку follower при составлении scope и два дополнительных пилотных проекта.
+- 3 244 отдельно выбранных task IDs: My Tasks, following, delegated и настроенные задачи старого project-truth.
+- В остальных проектах собираются выбранные задачи и их окружение, а не весь проект.
+- Внутри full-проектов код не задаёт фильтров по исполнителю, давности или завершённости. Он собирает историю событий и комментариев, рекурсивные подзадачи, связи dependencies/dependents; предусмотрена отдельная догрузка карточек внешних зависимостей.
+- Ограничение 3 000 API-запросов за запуск и 600 на проект разбивает процесс на возобновляемые порции; это не фильтр смысловой релевантности.
+- В 28 проектах перечислено 32 390 уникальных задач **до** рекурсивного обхода подзадач. Эта цифра не является размером всего собранного корпуса.
+- С 10.10 запись E1 идёт в основную `personal_os` после восстановления и подтверждённого импорта; до этого использовалась отдельная тестовая БД. Её историческая догрузка отличается от обычного sync, где есть окно изменений 30 дней для полного обновления проектов.
+
+В прочитанном 9 октября срезе E1 среди 31 943 загруженных основных задач:
+
+| Признак | Число задач |
+|---|---:|
+| Есть теги | 7 242 |
+| Есть custom fields | 28 771 |
+| Текущий assignee — Алекс | 812 |
+| Создатель — Алекс | 622 |
+| Есть сохранённые события, автором которых указан Алекс | 2 594 |
+
+В последней группе найдено 15 811 событий. Группы пересекаются; числа нельзя складывать. Авторство события — исходный признак для отбора, а не уже проверенная классификация участия. Выгрузка ещё меняется, поэтому это датированный срез, не финальный отчёт полноты.
+
+Среди custom fields встречаются Product Area(s), Functional Team, Objective, Priority, Reviewer. Новая выгрузка запрашивает теги, custom fields, авторов событий и участников. Алекс указал, что часть старых багов уже размечена корпоративной AI-системой; **точное место хранения, происхождение и пригодность этих AI-меток отдельно не проверены**.
+
+Код уже извлекает Asana task IDs из поддерживаемых ссылок в описаниях GitHub PR. Такие ссылки следует переносить как явные связи. Утверждение «практически каждый PR связан с задачей» — наблюдение Алекса; доля покрытия отдельно не измерена.
+
+Основания: [scope E1](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-scope-2026-10-06-v3.json), [построение scope](/Users/admin/Developer/personal-os/scripts/asana-expansion-scope.js), [обход задач](/Users/admin/Developer/personal-os/asana-coverage-backfill.js), [runner догрузки](/Users/admin/Developer/personal-os/scripts/asana-expansion-launch-agent.js), [связи PR → Asana](/Users/admin/Developer/personal-os/gh-snapshot.js).
+
+## 3. Контекст и межсферная релевантность
+
+### Запись рассматривается в окружении
+
+Для подзадачи нужны собственный текст, цепочка родителей, все memberships, существенные комментарии, зависимости и связанные материалы. Для сообщения — исходное сообщение, reply/thread, участники и связанные задачи. Короткое «перенести кнопку» может получить смысл только из родителя; отдельное «отменяем» — из предшествующего обсуждения.
+
+Связи сохраняются постоянно. В модель передаётся нужная часть контекста с возможностью дочитать оригиналы, а не весь проект целиком в каждый prompt.
+
+**Собственное содержание и унаследованный контекст различаются.** Родитель объясняет предмет подзадачи; его исполнитель, статус или все темы не должны автоматически приписываться ребёнку. При изменении родителя проверяется, какие зависимые представления требуют обновления.
+
+### Пример: AI Chat → главное окно → toolbar
+
+Работа в чужой продуктовой сфере может затронуть область Алекса. Обсуждение AI Chat становится релевантным через изменение точки входа в главное окно или toolbar, даже без имени Алекса и без прямого совпадения ключевых слов.
+
+Желаемый путь:
+
+`работа над AI Chat → меняет точку входа → затрагивает toolbar → пересекается с областью Алекса`
+
+После обнаружения пути нужно определить характер пересечения: полезно знать, нужна консультация/review, есть зависимость или подтверждённое обязательство. Пересечение само по себе не назначает ответственность.
+
+Поэтому «Алекс уже трогал эту задачу» — критерий приоритета глубокой обработки истории, **но не граница обнаружения нового контекста**. Неизвестные ранее области и новые сущности должны оставаться обнаружимыми.
+
+## 4. Что означает «токенизирование» задачи или сообщения
+
+Рабочее предложение — контекстное смысловое представление, а не список ключевых слов.
+
+У каждой записи сохраняются:
+
+1. Оригинал, source ID/URL, версия или hash, время события и получения.
+2. Явное окружение: проектные memberships, родители, тред, участники, ссылки.
+3. Краткое описание смысла с контекстом.
+4. Структурированные утверждения: что затронуто, какое изменение предложено/принято, отношения между объектами, область и время действия.
+5. Основания каждого вывода: конкретные фрагменты оригиналов; неоднозначности и альтернативы.
+6. Версия метода обработки для повторного прогона.
+
+Для примера AI Chat представление могло бы содержать функцию «AI Chat», компоненты «главное окно / toolbar», изменение «добавить точку входа», характер записи «предложение» и ссылки на текст задачи/родителя. Это пример желаемого результата, не выполненный анализ конкретной задачи.
+
+Для поиска полезны несколько представлений:
+
+- оригинальный текст — точный поиск и проверка;
+- описание записи с контекстом — смысловой поиск;
+- отдельные утверждения об изменениях — поиск по воздействиям.
+
+Embeddings помогают находить смыслово близкие материалы. Один вектор длинной задачи может скрыть небольшое важное изменение, поэтому отдельные утверждения стоит индексировать отдельно. Смысловая близость — средство поиска кандидатов; принятую связь подтверждают исходные материалы.
+
+## 5. Поэтапная обработка корпуса
+
+Исходное предложение Алекса: рамочно разметить крупные сферы — баги браузера, документацию, onboarding, company processes; затем индивидуально обработать историю своих работ с поиском по БД; последовательно разобрать документацию; восстановить текущие работы коллег вокруг задач на себе.
+
+Предложенные уточнения: взять текущие задачи раньше, сделать группы пересекающимися и добавить проверку межсферных пропусков.
+
+| Этап | Обработка | Результат |
+|---|---|---|
+| 1. Структурная основа | Весь корпус: IDs, memberships, вложенность, участники, теги, custom fields, явные PR/task links | Связанный каталог без модельных догадок |
+| 2. Рамочная разметка | Описания проектов, разделов и родителей; готовые метки; выборочные задачи и исключения | Пересекающиеся области с границами и неизвестностями |
+| 3. Текущие задачи на Алексе | Полный контекст каждой работы и поиск по всему корпусу | Текущий scope, зависимости, открытые вопросы |
+| 4. История участия | Работы и последовательности задач/обсуждений/PR, с которыми Алекс работал | История решений, опыт, аналоги текущих проблем |
+| 5. Последовательное расширение | Например, каждая работа в документации с поиском внутри и вне раздела | Более полное покрытие выбранной области |
+| 6. Пропуски и incoming | Неотнесённые записи, выборки из других областей, новые изменения | Новые пересечения и обновление контекста |
+
+Проект Asana — исходный контейнер, а не окончательная смысловая категория. Раздельно учитываются тип работы, продуктовая область, затронутые компоненты и инициатива. Одна задача может относиться к документации, AI Chat, macOS и onboarding одновременно.
+
+Первые группы направляют поиск, но не запрещают выход за их пределы. Необработанные материалы остаются доступными для поиска. Нельзя заранее утверждать, что «большая часть уже понята», только потому что записи получили bucket.
+
+Для старых багов сначала используются готовые метки и тематические группы; глубокая обработка начинается с личного участия и найденных пересечений. Новая задача может впервые сделать старый баг полезным контекстом.
+
+## 6. Агентский поиск и связывание
+
+Единица глубокой обработки — связная работа или эпизод. Родитель с подзадачами может анализироваться одним пакетом, с отдельным сохранением результатов для каждого объекта. Большие работы делятся на пакеты с общей картой контекста. Сообщение хранится отдельно, но понимается внутри треда.
+
+Для каждого пакета:
+
+1. Прочитать исходную работу и явное окружение.
+2. Выделить направления поиска: цель, компонент, аналогичная проблема, зависимость, предыдущее решение.
+3. Собрать кандидатов через точные ссылки, текстовый и смысловой поиск, теги и графовые пути.
+4. Оценить соответствие кандидатов, прочитать подходящие оригиналы и при необходимости уточнить поиск.
+5. Сохранить обоснованные отношения, время и неизвестности.
+
+Полезная методика — **retrieve → rerank**: широкий сбор кандидатов, затем более дорогая оценка ограниченного набора. Это не требует сравнивать агентом каждую задачу с каждой другой задачей. [Документация Sentence Transformers](https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html).
+
+Поиск имеет ограниченный бюджет и сохраняет нерешённые вопросы; количество расширений и условия остановки нужно определить в испытании. Повторяющиеся запросы и контекст кэшируются. Уже извлечённые связи используются в следующих проходах. Сомнительное сопоставление остаётся кандидатом, а не становится доказанным фактом из-за повторения в сводках.
+
+Scope коллег восстанавливается параллельно, когда они встречаются в окружении: активные задачи, недавние действия, review, решения и зависимости. Историческое участие хранится отдельно от текущей ответственности. Имена и роли связываются по проверяемым источникам.
+
+## 7. Архив и incoming используют один механизм
+
+Предлагаемый цикл:
+
+`изменение → явные связи → поиск контекста → AI-разбор эпизода → сохранение изменений → обновление затронутых представлений`
+
+Agent run на каждое событие технически возможен. Практическая единица — изменившаяся задача или связный тред: несколько событий могут выражать одно изменение смысла. Технические повторы не должны повторно запускать одинаковый анализ.
+
+- **Архив:** возобновляемые батчи, порядок событий, сохранённый прогресс и возможность replay.
+- **Incoming:** очередь изменений, объединение связанных событий, обработка нового содержания.
+- **Общее:** source IDs, версия/hash входов, версия обработки, основания выводов, обновление только затронутого контекста.
+
+Старое событие, загруженное сегодня, не должно отменять более новое решение только из-за времени получения. Нужно различать время события и время загрузки.
+
+Планировщик, career-сценарии и ретроспекция должны читать общие версии контекста с источниками и неизвестностями. Требования к этим потребителям сохраняются; их работа не считается запущенной по факту существования этого плана.
+
+## 8. Выбор графа и готовых систем остаётся открытым
+
+После обновления плана 10 октября первоочередная проверка — локальный RLM на небольшом наборе связных работ. Сравнение Graphiti/Cognee проводится позже, если измеренные задачи хранения и поиска требуют такого компонента; развёрнутый стенд пока не содержит этих систем.
+
+Нужно разделить три решения:
+
+- **Модель смысла:** какие объекты, отношения, источники и времена мы представляем.
+- **Механизм обработки и поиска:** что берём из готовой системы.
+- **Хранилища и эксплуатация:** какие backend нужны выбранному механизму.
+
+Предыдущие документы задают PostgreSQL как реестр исходных/принятых данных и допускают дополнительный перестраиваемый графовый индекс в испытании. Это не доказывает, что собственный PostgreSQL-граф уже является лучшим аналитическим решением. Конкретную архитектуру нужно оценить на данных.
+
+| Кандидат | Готовые механизмы | Вопросы испытания |
+|---|---|---|
+| Graphiti | Эпизоды-источники, извлечение и сопоставление сущностей, отношения с периодами действия, инкрементальные обновления, гибридный поиск, bulk ingestion | Asana/GitHub IDs, отмены, поздний backfill, ошибочные merge, контекст родителей, межсферные связи |
+| Cognee | Настраиваемые pipelines и DataPoints, происхождение данных, relational/vector/graph storage, инкрементальная обработка | Использование готовых меток и структуры, межисточниковый поиск, изменение задачи, представление текущего состояния |
+| Явные связи + обычный поиск | Существующие IDs, текстовый поиск и структурные переходы | Исходное качество, относительно которого измеряется польза готовых компонентов |
+
+По архитектуре Graphiti ближе к меняющимся отношениям во времени; Cognee — к организации и поиску разнородного корпуса. Это исследовательская оценка, **не результат сравнительного прогона**. [Graphiti](https://github.com/getzep/graphiti), [эпизоды и bulk ingestion](https://help.getzep.com/graphiti/core-concepts/adding-episodes), [архитектура Cognee](https://docs.cognee.ai/core-concepts/architecture), [DataPoints](https://docs.cognee.ai/core-concepts/building-blocks/datapoints).
+
+Graphiti передаёт при извлечении отношений предыдущие эпизоды, типы связей и дополнительные инструкции. Это позволяет настраивать контекст извлечения, но не обеспечивает правильную сборку Asana-иерархии автоматически. [Код извлечения](https://github.com/getzep/graphiti/blob/main/graphiti_core/utils/maintenance/edge_operations.py).
+
+Дополнительный методический ориентир — глобальный обзор областей и локальное раскрытие контекста в GraphRAG. Глобальный поиск использует сводки сообществ; локальный сочетает графовые данные с исходными текстами. Можно использовать этот принцип без обязательного внедрения GraphRAG. [Обзор методов](https://microsoft.github.io/graphrag/query/overview/).
+
+Рабочая гипотеза — адаптация готового механизма плюс предметные правила и сборщики. Не нужно заранее выбирать исключительно самописный контур или запускать постоянные параллельные графы.
+
+## 9. Локальный RLM: текущий стенд и пошаговый план
+
+### 9.1. Что развёрнуто и проверено 10 октября
+
+Стенд находится в `/Users/admin/Developer/personal-os/tools/rlm-lab`; инструкция запуска — [README](/Users/admin/Developer/personal-os/tools/rlm-lab/README.md). Это отдельное окружение для проверки RLM, без подключения рабочих источников и записи в БД Personal OS.
+
+| Компонент | Фактическое состояние |
+|---|---|
+| RLM | `fast-rlm 0.4.3`, Deno `2.9.6`, Python в локальной `.venv` |
+| MLX | `mlx-lm 0.31.1`, `mlx / mlx-metal 0.31.1` |
+| Основной профиль `qwen27b` | `mlx-community/Qwen3.8-27B-4bit`, revision `10c35caafbb80f7dc6a7a432cdd11af10a6d4818`; веса скачаны |
+| Профиль сравнения `coder30b` | `mlx-community/Qwen3-Coder-30B-A3B-Instruct-4bit`, revision `6e302ea604ad9ab206367e2c501d1571023e7b6d`; веса скачаны |
+| API | `http://127.0.0.1:8767/v1`; при обновлении заметки health подтвердил `qwen27b`, `backend_ready: true` |
+| 9B и смешанная маршрутизация | Не подключены; конкретный checkpoint 9B ещё предстоит выбрать |
+
+Одновременно загружена одна модель; корневые и дочерние вызовы используют активный профиль. MLX закреплён на 0.31.1 после воспроизведённого сбоя генерации с 0.31.2; оба профиля прошли проверку на закреплённой версии.
+
+**Синтетическая проверка прошла для обеих моделей:** реальное выполнение кода в REPL, дочерний вызов на глубине 1, ответ ребёнка `42`, итог `{"total":42,"label":"synthetic"}`, проверка JSON Schema. Проверены офлайн-загрузка пакетов REPL, блокировка чтения вне каталога стенда, внешней сети и запуска процессов. Это подтверждает работоспособность инфраструктуры; качество поиска, смысловых связей и временного состояния на рабочих данных пока не оценивалось. Длительность этих коротких прогонов не используется для выбора победителя.
+
+Основания: [сводка проверок](/Users/admin/Developer/personal-os/tools/rlm-lab/.runtime/verification.json), [манифест Qwen](/Users/admin/Developer/personal-os/tools/rlm-lab/.runtime/runs/20261010T075741-094c03/manifest.json), [манифест Coder](/Users/admin/Developer/personal-os/tools/rlm-lab/.runtime/runs/20261010T080002-39971c/manifest.json), [конфигурация](/Users/admin/Developer/personal-os/tools/rlm-lab/config.json).
+
+Начальные ограничения: глубина 2, максимум 16 модельных вызовов на прогон и 8 на агента, общий бюджет completion 16 384 токена, до 2 048 токенов ответа на вызов, 300 секунд на прогон. Лимиты — исходные настройки, их достаточность проверяется на выбранных работах.
+
+У каждого прогона сохраняются снимок входа, hash, модель и revision, настройки и версии пакетов, трасса вызовов, результат и статус. Полные запросы и ответы API также журналируются локально. `.runtime` и `datasets/private` исключены из Git. Внешняя сеть нужна для установки и скачивания весов; подготовленный REPL использует локальные пакеты и обращается только к локальному API. Сервис запускается вручную, автозапуска после перезагрузки нет.
+
+**Состояние списка задач на 14.10:** экспорт рабочих данных и schema v2 реализованы, архивный батч выполнен. Остаются независимый эталон/semantic acceptance, общий поиск по корпусу, смешанные вызовы с 9B и incoming. Датированные этапы ниже сохраняют первоначальный план и не заменяют текущий статус выше.
+
+### 9.1a. Дополнение 2026-10-10 (вечер): выборка и первый прогон на рабочих данных
+
+Полные результаты обоих прогонов, ошибки и решения: [[personal-os-rlm-stand-results-2026-10-10]].
+
+- Выборка подготовлена: 14 связных работ из `personal_os` (855 задач, 10 603 stories, 195 ссылок на PR) плюс Mattermost (1 465 сообщений за 1–9 октября), 7 транскриптов Zoom, 71 строка `activity_daily` и 9 daily briefs. Каталог `tools/rlm-lab/datasets/private/sample-2026-10-10/`, экспорт `scripts/rlm-sample-export.js`. Состав — предложение, не утверждён.
+- Первый прогон на одной работе (Duck.ai → меню приложения, контрольный случай без упоминания Алекса): шесть RLM-прогонов на Qwen27B и Coder30B не дошли до FINAL; одиночный вызов с заранее собранным контекстом на Qwen27B дал проверяемый JSON (10/10 улик по gid подтверждены, одно перепутанное авторство, завышено состояние «released»). Детали, исправления стенда и выводы: `tools/rlm-lab/datasets/private/sample-2026-10-10/eval/report-2026-10-10.md`.
+- Исправлено в стенде: падение mlx_lm на tool-call токене (обёртка `backend.py`), таймауты и бюджеты вызовов подняты (`config.json`). Шаг 9.2.3 и 9.2.4 ниже остаются актуальными; шаг 9.2.1 выполнен в части подготовки, выбор состава за Алексом.
+
+- Второй прогон (тот же день): одиночный вызов Qwen27B по схеме v2 (утверждения о состоянии с уликами) на 4 работах — все четыре дали валидный JSON, 80 из 80 улик существуют, роли Алекса и хронология верны. Две системные ошибки: релиз помечается подтверждённым по движению на release board или бот-упоминанию; закрытая подзадача читается как «реализовано» (CoreData в VSCode-миграции, хотя подход отменён). Эти ошибки не лечатся промптом, нужны правила в коде перед принятием. Утверждения лежат как candidate в `work_claims` (миграция 007). Готовые графовые продукты для этого шага не нужны. Отчёт: `eval/report-v2-2026-10-10.md`.
+
+
+- Вечер 2026-10-10: вся система описана как потоки в локальном Windmill (скелеты, без логики); одиночное извлечение из второго прогона — поток `f/analyse/work_claims_extract` со статусом PROPOSED. См. [[personal-os-windmill-system-map-2026-10-10]].
+
+### 9.2. Дальнейшие шаги и условия перехода
+
+1. **Выбрать данные после развёртывания стенда.** Начальный ориентир — 10–15 связных работ, а не случайные отдельные записи. Алекс выбирает состав; для каждой работы собрать оригиналы, родителей/подзадачи, memberships, существенные комментарии, PR и связанные обсуждения. Зафиксировать snapshot, IDs, версии/hash, время события и загрузки, недостающие материалы. Реальные данные в стенд пока не загружать до выбора.
+2. **Зафиксировать проверяемый результат и эталон.** Задать схему: предмет работы, отношения, предложение/решение/отмена/реализация/выпуск, время, конкретные источники и фрагменты, неизвестности. Составить независимые ожидаемые ответы по оригиналам; разделить примеры для настройки и отложенной проверки по работам, избегая утечки соседних записей.
+3. **Подключить чтение и поиск на выбранном snapshot.** Реализовать доступ к оригиналам и явным связям, затем текстовый поиск кандидатов; смысловой поиск и rerank добавлять по измеренным пропускам. Запустить полный цикл одной работы: чтение → поиск → дочитывание → обоснованные выводы. Ни результат модели, ни сходство текстов не заменяют источник.
+4. **Сравнить режимы на одинаковых данных.** Базовый уровень — явные связи и обычный поиск; отдельно — модель с заранее собранным контекстом; затем RLM с Qwen27B и RLM с Coder30B. В обоих RLM-прогонах root и children используют одну модель. Зафиксировать одинаковые входы, лимиты и версии, повторы и все неудачные прогоны.
+5. **Расширить проверку до 60–100 связанных эпизодов.** После исправления ошибок малого набора включить текущие задачи, историю участия, документацию/onboarding/processes, старые баги и сохранённые новые изменения. Применить контрольные случаи ниже, отдельно проверяя межсферные пропуски и ошибочное наследование ответственности. Это будущий этап, корпус ещё не подготовлен.
+6. **Проверить дешёвые дочерние вызовы 9B.** Выбрать доступный MLX checkpoint, реализовать маршрутизацию и сначала поручить ограниченные задачи: выбор кандидатов или извлечение подтверждающих фрагментов. Сравнить с дочерними вызовами основной модели по качеству, времени, памяти и стоимости переключения моделей. Не считать смешанную схему готовой до этих проверок.
+7. **Выбрать необходимый механизм хранения и поиска.** По результатам испытания решить, достаточно ли явных связей и обычного поиска или нужен готовый графовый компонент. Cognee и Graphiti остаются кандидатами для отдельного сравнения на том же эталоне; их проверка не предшествует рабочему RLM-срезу и ещё не выполнялась.
+8. **Расширить обработку на архив.** Подготовить структурный каталог всего доступного корпуса; запускать возобновляемые порции: текущие работы → история участия → документация → другие области и пропуски. Сохранять основания, версии и прогресс; поиск не ограничивать уже назначенными категориями. До массового прогона оценить пропуски, ресурсный бюджет и правила принятия связей.
+9. **Подключить incoming тем же механизмом.** Сначала replay сохранённых изменений, затем наблюдение за новым потоком: дедупликация, объединение событий по работе/треду, различение event time и received time, обновление зависимых представлений. После проверки согласованности архивного и инкрементального результата подключать потребителей общего контекста.
+
+### 9.3. Контрольные случаи и оценка качества
+
+Обязательные случаи:
+
+- Подзадача без слов «toolbar», смысл которой раскрывается через родителя.
+- AI Chat затрагивает главное окно/toolbar, без mention Алекса.
+- AI Chat затрагивает только серверную часть; UI-ответственность не должна приписываться.
+- Старый баг становится релевантным через новую работу.
+- Одна задача принадлежит нескольким проектам и смысловым областям.
+- Явная связь PR → Asana сохраняется без модельного сопоставления.
+- Предложение позднее отменено; закрытая задача не считается доказательством реализации.
+- Источник явно сообщает о выпуске хотфикса; анализ учитывает это сообщение вместе с историей, не теряет его при группировке.
+- Поздний backfill не перезаписывает новое состояние старым.
+- Близкие по названию работы остаются разными при разных источниках и scope.
+
+Отдельно измерять:
+
+- полноту найденных кандидатов и пропущенный релевантный контекст, включая межсферные пересечения;
+- точность и полноту подтверждённых связей, ложные связи и merge;
+- правильность временного состояния и различение участия, релевантности и ответственности;
+- долю корректных неизвестностей и выводов без подтверждающего фрагмента;
+- покрытие рамочной разметкой отдельно от покрытия проверенными связями;
+- длительность, модельные вызовы/токены, пиковую память, повторы, сбои и ручные исправления.
+
+Предварительные модельные выводы не служат независимым эталоном для оценки той же модели. Проверка человеком сосредоточена на важных неоднозначностях и контрольных примерах, а не на ручном разборе всех десятков тысяч задач.
+
+**Следующий ожидаемый результат:** выбранный малый набор и рабочий проверяемый срез RLM на нём. **Результат последующих испытаний:** «история + новое изменение → найденный контекст → проверяемые связи/состояние», оценка массового прогона и обоснованный выбор моделей и готового компонента. Малый набор и одиночный рабочий срез получены; полный RLM-цикл, независимое качество и обработка incoming ещё не приняты. См. датированные результаты выше.
+
+## 10. Открытые вопросы
+
+- Где находятся корпоративные AI-метки, каковы их категории, история и ошибки?
+- Какие действия над задачей считаются разными видами участия Алекса?
+- Как подтверждать текущие области и роли, отличая их от исторического опыта?
+- Какая схема контекстных пакетов сохраняет смысл при приемлемом размере?
+- Какое качество покажут Qwen3.8-27B и Qwen3-Coder-30B-A3B на выбранных работах; какой checkpoint 9B пригоден для дочерних вызовов и оправдана ли смешанная маршрутизация?
+- Какой механизм хранения/поиска нужен по результатам этих проверок?
+- Какой бюджет поиска/обработки нужен архиву и incoming?
+- Какие классы смысловых связей можно принимать автоматически после оценки, а какие требуют дополнительной проверки?
+- Как обновлять зависимые представления после изменения родителей, ролей или исходных решений?
+
+Эти вопросы остаются частью исследования. Сам факт назначения bucket, существования графового ребра или получения уверенного ответа модели не подтверждает понимание текущей работы.
@@ -0,0 +1,43 @@
+---
+tags:
+  - personal-os
+  - database
+  - runbook
+updated: '2026-10-14'
+---
+# Браузер БД Personal OS
+
+**Проверено 14.10.2026:** GitHub, ситуации, work items и designs находятся в основной `personal_os` после подтверждённого переноса 17 таблиц с совпавшими хешами. 121 work item / 17 репозиториев, 105 в очереди; 79 проверенных PR, 215 точных Asana–PR связей; 16 сигналов и 39 явных gaps. Локальный агент вызывается отдельно, его результат остаётся кандидатом. [Приёмка в репозитории](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md).
+
+**Work items**: ручная связь с Asana, объединение контекста related repos, локальный учёт, исключение с причиной, отдельный вызов локального агента. **Tech designs**: задачи Asana и заметки Obsidian с версиями/hash; смысловой `draft_of` требует принятия. Новая Asana-задача сначала сохраняется локальным черновиком, затем создаётся отдельным действием из проверенного черновика. Сам агент внешних записей не делает. Содержимое внешних дизайн-документов пока не загружается.
+
+Локальный интерфейс для просмотра данных Personal OS на `http://127.0.0.1:4317`.
+
+## Источник данных
+
+По умолчанию браузер использует PostgreSQL из корневого `config.json`: база `personal_os` на `localhost:5432`. Таблицы E1 находятся в этой же базе. Переменная `E1_COVERAGE_DATABASE_URL` подключает отдельную базу только для тестирования; для обычного просмотра её не задавать.
+
+Все подключения браузера используют PostgreSQL `default_transaction_read_only=on`. Сам интерфейс слушает только loopback-адрес `127.0.0.1`.
+
+## Запуск
+
+Из корня репозитория:
+
+```sh
+env -u E1_COVERAGE_DATABASE_URL npm run db:browser
+```
+
+Открыть `http://127.0.0.1:4317`. Для постоянной работы после входа установлен LaunchAgent `com.personalos.db-browser`: он запускается при входе, удаляет `E1_COVERAGE_DATABASE_URL` и перезапускает браузер после неуспешного завершения. Статус: `launchctl print gui/$(id -u)/com.personalos.db-browser`. Остановить и выгрузить: `launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.personalos.db-browser.plist`. Исходный plist находится в `scripts/com.personalos.db-browser.plist`.
+
+Проверить доступность интерфейса и источников:
+
+```sh
+curl -fsS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:4317/
+curl -fsS http://127.0.0.1:4317/api/bootstrap
+```
+
+В bootstrap после поставки 14.10 ожидаются `sources.e1=true`, `evidence_origin=primary`, `work_dashboard=true`, `local_resolution_enabled=true`, `read_only=false`. Последнее означает наличие действий через host runner; SQL-соединения браузера по-прежнему read-only. Если соединение не устанавливается, проверить PostgreSQL на `localhost:5432`, поле `database` в `config.json` и отсутствие старого `E1_COVERAGE_DATABASE_URL`.
+
+## Ссылки
+
+Исходники и подробности интерфейса: `web/db-browser/` и `web/db-browser/README.md` в репозитории personal-os.
@@ -33,7 +33,7 @@ confidence: 1
 | 12 | **Zulip** | май–сент 2026 | Заменён Mattermost; история выгружена, вывод из эксплуатации | [[personal/plans/zulip-decommission]] |
 | 13 | **GLM-5.3 как провайдер** | сент 2026 | ~2.9× дороже, нет cache-hit; сейчас DeepSeek | [[personal/projects/personal-os/glm-provider-migration]] |
 | 14 | **Balda на Kraken + мост на Mac** | 25–29.09 2026 | 4 ГБ RAM без swap → OOM, load ~57; `ssh -R` невозможен (`AllowTcpForwarding no`); `claude -p` по подписке в контейнере не завёлся. Стек снесён 29.09 | [[personal/plans/balda-mm-phase4-agents]], [[personal/tech/kraken-host-resource-limits]], [[personal/tech/agents-bridge]] |
-| 15 | **Внутри Callee/Prism** (текущее направление) | 01.10 2026 | Профиль Claude рвёт ACP-сессию на полной Story; `deepseek-chat` снят DeepSeek; Codex bwrap не стартует в Docker; CI упирается в биллинг GitHub; Monterey в Virfield — `disk_encrypted` | [[personal/plans/balda-callee-prism-plan]], [[personal/projects/virfield]] |
+| 15 | **Внутри Callee/Prism** (текущее направление) | 01.10 2026 | Профиль Claude рвёт ACP-сессию на полной Story; `deepseek-chat` снят DeepSeek; Codex bwrap не стартует в Docker; CI упирается в биллинг GitHub; Monterey: исторический Lume `disk_encrypted`; Tart golden 12.7.6/Xcode 13.4.1 принят 2026-10-07 с unlocked APFS encryption at rest | [[personal/plans/balda-callee-prism-plan]], [[personal/projects/virfield]] |

 ## Сквозные уроки

@@ -0,0 +1,165 @@
+---
+
+> Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной `personal_os`. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. [Контракт и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
+
+date: '2026-10-10'
+updated: '2026-10-14'
+status: results
+tags:
+  - personal-os
+  - data-analysis
+  - rlm
+  - evaluation
+---
+# Personal OS — результаты первых прогонов на рабочих данных (2026-10-10)
+
+**Обновление отчётов 14.10:** разделы 1–7 — датированные первые эксперименты. Полный каталог результатов по 486 работам: [[work-claims-results-2026-10-12]]; все claims остаются кандидатами. Дополнение 8 содержит отдельную проверку связывания BSP-ворктри, не повтор статусов всего корпуса. GitHub mirror и work dashboard уже перенесены в основную БД; отсутствие GitHub-таблиц в исходной выборке 10.10 ниже является историческим фактом.
+
+Продолжение [[personal-os-data-analysis-workflow-2026-10-09]], раздел 9. Здесь зафиксировано, что было сделано, что получилось, где модель систематически ошибается и что из этого следует. Исходные файлы прогонов, эталоны и отчёты на английском: `tools/rlm-lab/datasets/private/sample-2026-10-10/` в репозитории personal-os (каталог вне git).
+
+## 1. Выборка
+
+Скрипт `scripts/rlm-sample-export.js` читает `personal_os` (localhost, E1-restore) и собирает пакет на каждую корневую задачу: родители, подзадачи до глубины 4, зависимости на один шаг, задачи по ссылкам из текста, memberships, stories без лайков и реакций, ссылки на PR и gid из текста, хеши и времена. Модуль `scripts/rlm-sample-sources.js` добавляет общие источники.
+
+| Что | Объём |
+|---|---|
+| Работ | 14 (состав предложен, не утверждён) |
+| Задач в снимке | 855 |
+| Stories после фильтра | 10 603 |
+| Ссылок на PR в тексте | 195 |
+| Mattermost | 1 465 сообщений, 1–9 октября, chat.duckduckgo.com и mm.qentra.top |
+| Zoom | 7 транскриптов, 29 сентября – 6 октября |
+| activity_daily | 71 строка, апрель–июнь |
+| daily briefs | 9 файлов, июнь |
+
+Пробелы: таблиц GitHub в `personal_os` нет, PR только как URL из текста; задачи релизов в выборке отсутствуют; у Fire Button нет родителя в БД; у Tab.swift не хватает 7 подзадач. Mattermost привязывается только по явному gid/PR, совпадения есть у одной работы (VSCode-миграция). Zoom, activity и briefs в анализ не входят, в снимке они пока балласт.
+
+## 2. Первый прогон: RLM на одной работе
+
+Работа: Duck.ai → пункт «AI Settings» в меню приложения, контрольный случай «AI Chat задевает главное окно без упоминания Алекса». Эталон написан до запуска по оригиналам.
+
+| Режим | Исход | Время |
+|---|---|---|
+| RLM Qwen27B ×2 | падение mlx_lm на tool-call токене; таймаут API | 42 с, 121 с |
+| RLM Qwen27B | 8 вызовов на чтение, FINAL нет | 288 с |
+| RLM Qwen27B | несколько repl-блоков в ответе, повторяется; остановлен | ~16 мин |
+| RLM Qwen27B | один блок соблюдён, с шага 12 цикл; 24 вызова, FINAL нет | 694 с |
+| RLM Coder30B | каждый ответ упирается в 2048 токенов, ничего не выполнено | 943 с |
+| Один вызов Qwen27B с собранным контекстом | валидный JSON | 138 с |
+| Один вызов Coder30B | валидный, тонкий | 25 с |
+
+Вывод: RLM на этих моделях без thinking не сходится даже на работе в 79 KB; одиночный вызов даёт проверяемый результат. Модель нашла факт, пропущенный в ручном эталоне: 5 октября Alex M упомянул задачу из задачи релиза 1.210.0. Эталоны надо сверять скриптами.
+
+Исправления стенда: `backend.py` отключает разбор tool-call в mlx_lm; таймауты и бюджеты вызовов подняты в `config.json`; добавлен `baseline.py`.
+
+## 3. Второй прогон: один вызов, схема v2, четыре работы
+
+Схема v2: утверждения о состоянии (proposed, decided, implemented, approved, released, cancelled, open, blocked) с уликой и флагом confirmed; хронология с уликами; люди; Алекс (mentioned, assignee, author, responsible, intersection_kind); ссылки; неизвестности. Контекст собирается `tools/rlm-lab/build_input.py`: корень полностью, у подзадач только комментарии, назначения, завершения, переименования и всё, где автор Алекс; бюджет 160 тысяч символов.
+
+| Работа | Prompt токенов | Время | JSON | Улики найдены |
+|---|---:|---:|---|---|
+| Duck.ai entry point | 9 682 | 146 с | валидный | 19/19 |
+| Fire Button (Алекс DRI) | 49 814 | 489 с | валидный | 23/23 |
+| VSCode migration (Алекс DRI, открыта) | 51 814 | 490 с | валидный | 15/15 |
+| Prevent accidental quit (Алекс DRI) | 65 544 | 611 с | валидный | 23/23 |
+
+Первая попытка батча потеряна из-за лимита 2048 токенов ответа и таймаута 600 с; подняты до 8192 и 1800 с. Prefill ≈ 110–160 ток/с, это главная статья времени.
+
+Что верно во всех четырёх: ни одной выдуманной улики; роли Алекса совпали с посчитанной из записей истиной (owner на трёх, awareness на Duck.ai); хронологии с правильными датами; отмены ловятся, когда о них сказано прямо; Mattermost использован там, где привязан; неизвестности осмысленные.
+
+Две системные ошибки:
+
+1. **Релиз помечен как подтверждённый** на 3 работах из 3 продуктовых. Улика: движение по release board или бот-запись «упомянута в задаче релиза». У Duck.ai задачу вернули в Pre-release Validation 6 октября; у accidental quit выдуман релиз iOS из тега. Флаг confirmed не помогает: true в 30 из 31 утверждений.
+2. **Закрытая подзадача прочитана как реализация.** VSCode: «CoreData мигрирован на code-initialized модели [confirmed]» по завершённой подзадаче, которая на деле отменена, потому что Xcode 27 собирает модели как есть. Та же ошибка project truth, что записана в README проекта 4 октября.
+
+Прочие пропуски: у Duck.ai нет ранней реализации PR 5553 и правила про ship review; у Fire Button не отмечен отсутствующий родитель и блокировка Sites-секции FE-задачей; у VSCode смешаны устаревший «[ON HOLD]» и сентябрьский перезапуск.
+
+## 4. Хранение
+
+Миграция `migrations/007_work_claims_pilot.sql` применена к `personal_os`: `work_analysis_runs` и `work_claims` (статус candidate/accepted/rejected, evidence_ref, evidence_found, model_confirmed). Загружено 4 прогона, 212 утверждений, 80 из 80 улик найдены. Это кандидаты; приёмка по дизайну [[personal-os-evidence-graph-design-2026-10-04]] не реализована.
+
+## 5. Что этот блок делает и чего не делает
+
+Делает: разбор одной корневой задачи с поддеревом в проверяемые утверждения с уликами. В будущей схеме это компонент, вызываемый на каждую работу из батча по архиву или по изменению из incoming.
+
+Не делает: привязку к другим работам, пересечения со сферой Алекса без явных ссылок, использование Zoom и несвязанных сообщений, поиск по корпусу. Для этого нужен следующий блок: явные связи по всему корпусу в таблице рёбер, кандидаты через соседей и поиск, второй дешёвый вызов на пару «работа ↔ кандидат».
+
+## 6. Решения и следующие шаги
+
+- Извлечение одним вызовом принято как рабочий режим для разбора работы; RLM откладывается до этапа поиска по архиву.
+- Две системные ошибки лечатся правилами в коде поверх `work_claims`, не промптом: релиз только по задаче релиза с версией в корпусе, иначе suggested; завершённая подзадача даёт closed, реализация требует merge или прямого утверждения, пометка об отмене переводит в cancelled.
+- Задачи релизов нужно добавить в выборку.
+- Графовые продукты для этого шага не нужны; Cognee и Graphiti остаются вопросом для поиска между работами.
+- Цена: 4 работы ≈ 29 минут модели; 60–100 эпизодов это 7–12 часов батчем на этой машине.
+
+## 7. Дополнение (вечер 2026-10-10): карта системы в Windmill
+
+Обсуждение показало, что без визуальной карты Алекс не может участвовать в проектировании. Развёрнут локальный Windmill на хостовом PostgreSQL; вся система описана как 18 потоков-скелетов и обзорный холст, без логики и расписаний. Шесть стадий из раздела 5 стали потоком `f/analyse/work_claims_extract` со статусом PROPOSED. Подробности и правила работы с картой: [[personal-os-windmill-system-map-2026-10-10]].
+
+## 8. Дополнение 2026-10-14: локальный агент — привязка BSP-ворктри к работе Asana
+
+Дополнительный случай по VSCode-миграции из раздела 3: локальный агент разбирал назначение ворктри `vscode-xcode-bsp`, чтобы связать актуальный Git-прогресс с работой/задачей Asana и материалами дизайна. Это отдельная проверка связывания источников, а не повтор извлечения статусов по схеме v2 и не новый анализ всех 14 работ. Старые результаты и выявленные ошибки про релиз и отменённый CoreData-подход этой проверкой не исправлены и не перевалидированы.
+
+### 8.1. Вход, режим и воспроизводимость
+
+- Work item: `5b40803b-e98d-44aa-9757-000071cceb69`.
+- Источник: `duckduckgo/apple-browsers`, путь `/Users/admin/DuckDuckGo/apple-browsers.git/vscode-xcode-bsp`, ветка `alex/vscode-xcode-bsp`.
+- В обоих пакетах: 10 untracked-путей, включая `DuckDuckGo.code-workspace` и девять файлов `scripts/vscode/`; переданные списки коммитов и PR пусты; gap `no_exact_asana_reference`. Содержимое кода и diff в модель не передавались.
+- Режим: один локальный chat-вызов на попытку, профиль `qwen27b`, без RLM REPL/дочерних агентов, tools и внешнего inference. `temperature=0`, максимум 2 048 токенов ответа. В каждом пакете — 12 кандидатов Asana и четыре локальные заметки/драфта; сумма размеров текстов передаваемых records ограничена 28 000 символов.
+- Первая попытка запущена через preview потока; вторая — кнопкой дашборда через сохранённый Windmill `f/analyse/work_situation`, `mode=resolve`. После переноса в основную БД повтор второй попытки с прежним `request_id` вернул `reused=true`, без третьего вызова модели.
+- Обе строки `work_resolution_jobs` перенесены в `personal_os` и сохранены как история. Полные пакеты входа, ответы, usage, времена, `input_hash`, `prompt_hash` и повторная проверка цитат: [артефакт валидации](/Users/admin/Developer/personal-os/tools/rlm-lab/datasets/private/sample-2026-10-10/eval/work-item-resolver-2026-10-14.json). Артефакт находится вне Git.
+
+### 8.2. Две попытки
+
+Время — UTC; Asia/Bishkek = UTC+6. Продолжительность вычислена по сохранённым `started_at` и `finished_at`.
+
+| Попытка / job ID | Время 14.10 | Prompt / ответ, токенов | Результат | Цитаты |
+|---|---|---:|---|---|
+| До исправления поиска — `6fdaa7e9-c921-4f1e-bae8-7fb1c128adf7` | 13:41:36–13:44:16, 159,836 с | 8 202 / 352 | `unknown`, succeeded | 3/3 существуют во входе |
+| После исправления — `35f15287-9fc9-4e07-bb11-101ad6f3debf` | 14:19:09–14:21:04, 114,946 с | 9 190 / 644 | `link_existing`, succeeded | 4/4 существуют во входе |
+
+**Первая попытка:** модель не нашла доказанную связь среди переданных кандидатов и вернула `unknown`, не выдумав task ID. Все 12 кандидатов были завершёнными задачами обновления/починки Xcode; нужные VSCode-задачи отсутствовали. Это выявленная ошибка retrieval: общая выборка по словам с общим LIMIT вытеснила редкие совпадения VSCode/BSP множеством Xcode-задач. Такой отказ нельзя считать доказательством отсутствия подходящей задачи в Asana.
+
+**Исправление между попытками:** отдельная ограниченная выборка для каждого поискового термина, приоритет доступных собственных задач и понижение завершённых задач при ранжировании. Во втором пакете появились корневая VSCode-работа и её открытая подзадача. Промпт агента не менялся: обе попытки имеют `prompt_hash=a43676e5f579eaf5beefd2225838414d11b67dca90f8d999dc5284be802dbdf7`.
+
+**Вторая попытка:** модель предложила связать ворктри с:
+
+1. [Migration to fully VSCode-supported builds&debugging](https://app.asana.com/0/0/1209808486380252), GID `1209808486380252` — корневая работа.
+2. [Add VSCode build&debug support](https://app.asana.com/0/0/1219079700626622), GID `1219079700626622` — конкретная подзадача. В переданном Asana-record её `parent_gid=1209808486380252`; обе задачи в этом снимке открыты.
+
+Смысл модельного вывода: локальные workspace/scripts относятся к подходу VS Code/Cursor через `sourcekit-xcode-bsp`, альтернативному переносу кода браузера в SPM. Это предложение о назначении работы, а не вывод о готовности build/debug-интеграции.
+
+### 8.3. Основания и предложенные дизайны
+
+Главная цитата второй попытки — из `design:26c4932b-4105-4e0a-88ab-2393c7f4d27d`, заметки `work/projects/vscode-migration/xcode-build-server.md`:
+
+> VS Code setup | worktree `vscode-xcode-bsp`, branch `alex/vscode-xcode-bsp` — `DuckDuckGo.code-workspace`, `scripts/vscode/` (uncommitted)
+
+Она совпадает с веткой и путями в Git-record. Другие три цитаты — `branch":"alex/vscode-xcode-bsp"` из `worktree` и названия двух предложенных Asana-задач из их task-records. Все цитаты проверены как точные подстроки сохранённого входа; `input_hash` обеих попыток пересчитан и совпал с БД.
+
+| Предложенный design ID | Источник | Основание во втором ответе |
+|---|---|---|
+| `26c4932b-4105-4e0a-88ab-2393c7f4d27d` | `work/projects/vscode-migration/xcode-build-server.md`, project note | Отдельная точная цитата о ворктри, ветке и файлах |
+| `297efc6a-2b98-49f8-80c6-40246acc1094` | `work/projects/vscode-migration/tech-design-xcode-build-server.md`, draft | ID существует во входе; отдельной цитаты, обосновывающей эту связь, ответ не содержит |
+| `55968497-9f3a-487f-8e08-608b1000da58` | `work/projects/vscode-migration/vscode-migration.md`, project note | ID существует во входе; отдельной цитаты, обосновывающей эту связь, ответ не содержит |
+
+Следовательно, проверка наличия IDs и цитат пройдена, но все три смысловые связи с дизайнами нельзя объявлять автоматически подтверждёнными. Этот ответ также не доказывает `draft_of` между Obsidian-драфтом и опубликованным tech design Asana.
+
+### 8.4. Статус валидации и ограничения
+
+| Что проверено | Результат |
+|---|---|
+| JSON, разрешённые IDs, точность цитат и целостность входных пакетов | PASS: обе попытки; 7/7 цитат существуют, оба входных hash совпали |
+| Retrieval нужной Asana-работы | FAIL в первом пакете; нужные root/subtask присутствуют после исправления во втором |
+| Смысловая привязка BSP → Asana | Кандидат с точной опорой на Obsidian и структурной связью parent/subtask; требует принятия человеком |
+| Каждая из трёх предложенных design-связей | Нужна отдельная проверка; две связи не имеют собственной цитаты в ответе |
+| Реализация, работоспособность build/debug, approval, release, отмены и текущий статус проекта целиком | Этой проверкой не установлены |
+| Независимый holdout и обобщение качества на другие работы | Не проводились; retrieval исправлялся на этом же случае |
+
+В обоих результатах: `accepted=false`, `requires_review=true`, `evidence_verified=true`, `stale=false` на момент завершения попытки. `evidence_verified` означает проверку IDs и точных цитат, а не принятие смысловых утверждений. Автоматическая проверка разрешений отклонила принятие связи BSP без отдельного подтверждения; в основном дашборде work item остался в очереди резолва, предложение и обе попытки доступны [в карточке](http://127.0.0.1:4317/#/work-items/5b40803b-e98d-44aa-9757-000071cceb69).
+
+Обе попытки вернули `task_draft=null`. Сохранённый позже в интерфейсе локальный черновик BSP-задачи подготовлен отдельно; он не является результатом этих модельных вызовов. Новых задач Asana эти попытки не создали.
+
+**Вывод для общей проверки анализатора:** результат на этом случае существенно зависит от полноты retrieval. Корректные цитаты позволяют проверять ответ, но не подтверждают автоматически статус проекта, релиз, реализацию или каждую предложенную связь. Ошибки схемы v2 из раздела 3 остаются отдельными кейсами для валидации.
+
+Обновление collector не повторяло model evaluation и не меняло frozen inputs, raw ответы или статус кандидатов в этой валидации.
@@ -1,17 +1,26 @@
 ---
+
+> Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной `personal_os`. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. [Контракт и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
+
 title: Personal OS — статус (октябрь 2026)
 tags:
  - personal-os
  - status
-updated: '2026-10-04'
+updated: '2026-10-14'
 confidence: 1
 ---
-# Personal OS — статус на 2026-10-04
+# Personal OS — срез 2026-10-04, связанные проекты сверены 2026-10-14
+
+> Историческая проверка launchd до замены worker 14.10.2026: `com.personalos.asana-expansion-e1` не найден в `gui/501`. Поэтому запись о загруженном агенте 10.10 ниже не подтверждает текущий фоновый backfill. `com.personalos.work-evidence` и `com.personalos.db-browser` загружены и работают.
+
+**Проверено 14.10.2026:** GitHub, ситуации, work items и designs находятся в основной `personal_os` после подтверждённого переноса 17 таблиц с совпавшими хешами. 121 work item / 17 репозиториев, 105 в очереди; 79 проверенных PR, 215 точных Asana–PR связей; 16 сигналов и 39 явных gaps. Локальный агент вызывается отдельно, его результат остаётся кандидатом. [Приёмка в репозитории](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md).
+
+Датированные наблюдения 04.10 ниже — история проверки. Они не утверждают текущую свежесть источников, состояние расписаний или отсутствие последующих запусков. Общий аналитический контур и принятие model claims ещё не завершены.

 > Проверенный срез и исправленный план R2: [[personal-os-system-review-index]]. Датированные цифры ниже — история наблюдений; целевые контракты и этапы задаёт пакет R2. Новая архитектура ожидает утверждения.


-> **Главный источник правды о текущем состоянии.** Архитектурные заметки 2026-04 и старый Executor — исторические.
+> Датированный срез Personal OS; актуальные целевые контракты задаёт пакет R2 по ссылке выше. Текущие версии Balda/Broker ведутся в их собственных карточках. Архитектурные заметки 2026-04 и старый Executor — исторические.

 ## Коротко

@@ -49,13 +58,8 @@ confidence: 1
 - **Чат-транспорт:** Mattermost (сервер на Kraken: `mattermost` + `mm-postgres`). Zulip выводится
  из эксплуатации ([[personal/plans/zulip-decommission]]). Discord не используется с 2026-05-11.
 - **Hermes:** профиль `hermes-whale` (Кит) на Mac, Mattermost/Telegram. Профиль Eagle существует, кроны на паузе.
- **Balda** (baldaworks/balda, runtime — normahq/runtime): стек на Kraken **снесён 2026-09-29**
-  ([[personal/plans/balda-runtime-rebuild-mm-validation]]). Текущее направление — **на Mac**:
-  Mattermost → Balda → Execution Broker → одноразовый Docker-worker (Callee + OpenCode/DeepSeek)
-  или macOS VM через Virfield; задачи/истории — Prism/Beads.
-  Статус: сквозная приёмка `/execute` из MM не пройдена, NO-GO для stable
-  ([[personal/plans/balda-callee-prism-plan]]).
- **Virfield** (VM-лизы для UI-тестов): кандидат v2, до production не готов ([[personal/projects/virfield]]).
+- **Balda / Execution Broker** (сверено 2026-10-14): текущий контур на Mac, Mattermost и Codex ACP; старый Kraken-стек демонтирован. Live coding flow на прежних образах прошёл с артефактами, публикацией результата и cleanup. Новый Broker rc.26 проверен локально, но согласованное обновление и production-приёмка кандидата не выполнены; универсальная подготовка стеков, caches и inputs между запусками остаются в плане. Подробности и ограничения: [[personal/projects/balda/execution-broker]], конфигурация: [[personal/projects/balda/setup]].
+- **Virfield** (сверено 2026-10-14): Tart + SSH nodes, новая hardening-версия исправляет Lume migration и lifecycle defects; текущий кандидат ещё не live принят ([[personal/projects/virfield]]).
 - **Obsidian vault** `~/obsidian/` — жив, синхронизация через git/NAS + Syncthing; MCP — `mcpvault`.

 ## Что осталось до пилота
@@ -1,16 +1,31 @@
 ---
+
+> Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной `personal_os`. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. [Контракт и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
+
 status: draft-review
 revision: R2 + six-layer-analysis
-updated: 2026-10-05
+updated: '2026-10-14'
 ---
 # Personal OS: план и анализ шести уровней

-**Сейчас работать по [[personal-os-action-plan-2026-10-05]].** Детальные пакеты E1.1–E1.5, результаты, проверки, зависимости и участие Алекса. Первый пакет — воспроизведение потерь и независимый отчёт покрытия; реализация ещё не начата. Обоснование выбора компонентов — [[personal-os-six-layer-analysis-2026-10-05]].
+> Историческая проверка launchd до замены worker 14.10.2026: `com.personalos.asana-expansion-e1` не найден в `gui/501`. Поэтому запись о загруженном агенте 10.10 ниже не подтверждает текущий фоновый backfill. `com.personalos.work-evidence` и `com.personalos.db-browser` загружены и работают.
+
+**Проверено 14.10.2026:** GitHub, ситуации, work items и designs находятся в основной `personal_os` после подтверждённого переноса 17 таблиц с совпавшими хешами. 121 work item / 17 репозиториев, 105 в очереди; 79 проверенных PR, 215 точных Asana–PR связей; 16 сигналов и 39 явных gaps. Локальный агент вызывается отдельно, его результат остаётся кандидатом. [Приёмка в репозитории](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md).
+
+Исторический E1 backfill: 21/28 проектов проходили локальный критерий по сохранённому ID scan 06.10; 35 080/35 080 memberships. Каталог модели: [[work-claims-results-2026-10-12]], 486 работ, 480 completed, 12 244 candidate claims. Дополнительный кейс связывания BSP: [[personal-os-rlm-stand-results-2026-10-10#8. Дополнение 2026-10-14: локальный агент — привязка BSP-ворктри к работе Asana]]. Ниже сохраняется история исследований; граф R2 целиком не внедрён.
+
+> **Обновление 10.10.2026:** схема и данные E1 находятся в рабочей PostgreSQL-БД `personal_os` на `localhost:5432`; LaunchAgent сборщика Asana пишет туда и продолжает работу с сохранённых checkpoint. Временная E1-БД на порту 55439 больше не является целью сборщика. Покрытие пока неполное: строгую проверку проходят 17 из 28 проектов. См. текущий [[personal-os-action-plan-2026-10-05]] и [журнал восстановления E1](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md).
+
+> **Обновление 10.10.2026 (вечер):** система визуализирована в локальном Windmill как 18 потоков-скелетов и обзорный холст; логики и расписаний нет. Карта и правила: [[personal-os-windmill-system-map-2026-10-10]].
+
+**Сейчас работать по [[personal-os-action-plan-2026-10-05]].** В нём — детальные пакеты E1.1–E1.5, результаты, проверки, зависимости и участие Алекса. Обоснование выбора компонентов — [[personal-os-six-layer-analysis-2026-10-05]].

 Архитектурные противоречия устранены в плане: одна PostgreSQL-модель, immutable evidence и типизированные claims, semantic acceptance, единая публикация, scoped feedback, один владелец каждого collector и последовательные gates реализации. Runtime по этому плану ещё не внедрён; новые запуски и расписания не включались.

 | Документ | Назначение |
 |---|---|
+| [[personal-os-windmill-system-map-2026-10-10]] | Карта системы в Windmill: 18 потоков по стадиям fetch/observe/analyse/publish/attend, обзорный холст, источник `windmill/system-map.yaml`. |
+| [[personal-os-db-browser]] | Локальный браузер БД: запуск на `127.0.0.1:4317`, источник `personal_os` на `localhost:5432`, проверка read-only SQL и доступных локальных решений. |
 | [[personal-os-action-plan-2026-10-05]] | Текущая очередь E1–E5: ближайшие пакеты, поставки, проверки и зависимости. |
 | [[personal-os-system-review-2026-10-04]] | Полный план: роли, data flow, инструкции, расписания, SC1–SC8, AC01–AC16 и R0–R4. |
 | [[personal-os-evidence-graph-design-2026-10-04]] | Конкретные таблицы, ключи, typed relations, время, discovery, принятие claims, lineage и публикация. Заменяет ранний иллюстративный DDL. |
@@ -47,4 +62,4 @@ updated: 2026-10-05
 4. Проверка роли пользователя и матрицы важности.
 5. План внимания, ретроспекция и эксплуатационная приёмка.

-[[personal-os-buy-adapt-build-2026-10-05]] сохранён как справочный обзор; корпоративный shortlist больше не определяет первый этап. Исследование завершено, дефекты сборщика ещё не исправлены, модели не испытывались. Печатные PDF остаются R2 и не содержат этого уточнения.
+[[personal-os-buy-adapt-build-2026-10-05]] сохранён как справочный обзор; корпоративный shortlist больше не определяет первый этап. Это состояние исследования на 05.10. Позже схема E1 и backfill реализованы, локальные модели испытаны; полнота источников и semantic acceptance остаются неполными. Печатные PDF остаются R2 и не содержат этого уточнения.
@@ -0,0 +1,107 @@
+---
+
+> Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной `personal_os`. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. [Контракт и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
+
+date: '2026-10-10'
+status: partial-real-flows
+tags:
+  - personal-os
+  - windmill
+  - architecture
+  - system-map
+updated: '2026-10-14'
+---
+# Personal OS — карта системы в Windmill (2026-10-10)
+
+**Проверено 14.10.2026:** GitHub, ситуации, work items и designs находятся в основной `personal_os` после подтверждённого переноса 17 таблиц с совпавшими хешами. 121 work item / 17 репозиториев, 105 в очереди; 79 проверенных PR, 215 точных Asana–PR связей; 16 сигналов и 39 явных gaps. Локальный агент вызывается отдельно, его результат остаётся кандидатом. [Приёмка в репозитории](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md).
+
+Карта теперь содержит 21 поток и отдельный overview. Реальные шаги есть у `f/analyse/work_triage`, `f/fetch/github_prs`, `f/analyse/work_situation`; остальные mapped flows остаются скелетами. `work_claims_extract` не развёрнут: каталог 486 работ получен отдельными скриптами стенда. Статусы settled/running в карте описывают соответствующие внешние процессы, а не наличие реализации в Windmill. Расписаний для новых GitHub/work flows не добавляли. Разделы 1–7 ниже — датированная история.
+
+Продолжение [[personal-os-rlm-stand-results-2026-10-10]]. Вечером 10 октября после обсуждения принято: нужна визуальная, исполняемая карта системы, а не рисунок. Развёрнут локальный Windmill; вся система описана как 18 потоков-скелетов и один обзорный поток. На момент начальной поставки 10.10 логики в узлах не было; текущая реализация указана выше.
+
+## 1. Почему Windmill, а не n8n / Node-RED / Dagu
+
+Требования Алекса: видеть систему целиком как граф потоков данных, участвовать в проектировании, менять узлы, видеть что прошло между шагами. Ранние заметки ([[personal-os-architecture-decision-2026-10-04]], [[personal-os-six-layer-analysis-2026-10-05]]) отклоняли n8n/Node-RED по другой причине: они не дают семантики истины. Это верно, но не относится к слою оркестрации: правила и claims остаются кодом и таблицами PostgreSQL; инструмент потоков только перемещает данные между шагами.
+
+| Кандидат | Уточнение проверки 14.10.2026 |
+|---|---|
+| n8n, Temporal, Prefect, Dagster | Не выбранные в этой итерации варианты; сопоставимого испытания на этом корпусе нет. |
+| Node-RED | Общее утверждение «состояние только в памяти» неверно: есть filesystem context store. Это само по себе не доказывает подходящую гарантию длительного батча. [Официальный контракт](https://nodered.org/docs/user-guide/context). |
+| Activepieces | Самостоятельная установка использует PostgreSQL и Redis; прежняя причина про хранение только в памяти снята. [Официальная установка](https://www.activepieces.com/docs/install/options/docker-compose). |
+| Dagu | Имеет Web UI, графы, логи и редактор YAML; тезис об отсутствии настройки узлов в UI снят. Сопоставимый canvas-тест здесь не проводился. [Официальный Web UI](https://docs.dagu.sh/overview/web-ui). |
+| Windmill | Выбран и развёрнут как текущий слой оркестрации; эта поставка проверяет его локальные потоки, а не превосходство над всеми альтернативами. |
+
+## 2. Что развёрнуто
+
+- `windmill/` в репозитории personal-os: `docker-compose.yml` (server, worker, native worker, LSP, caddy), `.env` вне git, `README.md`.
+- Один PostgreSQL: Windmill использует БД `windmill` на хостовом PostgreSQL 17 (роли `windmill`, `windmill_user`, `windmill_admin`). Данные Personal OS остаются в `personal_os`. Контейнеры выходят на хост через `host.docker.internal`; проверено, что соединение из контейнера приходит с 127.0.0.1 и проходит по pg_hba.
+- UI: http://localhost:8000, workspace `personal_os`. Пароль суперадмина сменён Алексом; CLI-токен в `windmill/.env`.
+- Образ закреплён: `ghcr.io/windmill-labs/windmill:1.829.0`. Попутно удалён протухший логин ghcr.io из `~/.docker/config.json`, он блокировал анонимные pull.
+
+## 3. Карта
+
+Источник — `windmill/system-map.yaml`. Генератор `windmill/bootstrap/gen_map.py` создаёт `workspace/f/<стадия>/<поток>__flow/` со стабами по одному на стадию; `wmill sync push` отправляет на сервер. Каждый стаб возвращает своё описание: что читает, что пишет, какой скрипт ему соответствует.
+
+Стадии: fetch → observe → analyse → publish → attend. Обзорный поток `f/system/overview` — один холст, где узлы — потоки, сгруппированные параллельными ветками по стадиям.
+
+| Статус | Потоки |
+|---|---|
+| settled | asana_sync, mattermost, zoom_notes, github_snapshot, activity, focus_shadow |
+| running | asana_expansion_e1 |
+| disabled | zoom_export, status_readonly |
+| draft | project_truth |
+| PROPOSED | work_claims_extract — шесть стадий: read_tasks → read_stories → build_packet → run_model → parse_result → write_claims; черновой код шагов лежит в `windmill/bootstrap/steps`, не развёрнут |
+| PLANNED | corpus_and_gold_e2, work_links, mechanism_e3, claims_review, roles_importance_e4, attention_loop_e5, retrospector |
+
+Прогон обзорного потока прошёл: воркер, Python и сеть до хоста работают.
+
+## 4. Границы и правила
+
+- Пока поток — скелет, источник правды — `system-map.yaml`; push перезаписывает правки на холсте. Как только поток получает реальные шаги, источником становится его `flow.yaml`, правки делаются на холсте и забираются `wmill sync pull`; поток убирается из генератора. По одному потоку за раз.
+- Сборщики Mattermost и Zoom нуждаются в залогиненном Chrome на Mac и не могут выполняться в контейнере. Их узлы остаются тонкими (триггер/наблюдение), пока не выбран host-side runner.
+- Обзорный поток, запускающий всё подряд, — демонстрация, а не реальная каденция. Расписания вешаются на отдельные потоки.
+- Потоки сбора и локальный агент не пишут в Asana/GitHub. С 14.10 дашборд содержит отдельное действие создания Asana-задачи из проверенного черновика; старый Executor остаётся выключенным.
+
+## 5. Следующий шаг
+
+Алекс смотрит холст и `system-map.yaml` и говорит, где картина неверна: каких потоков нет, какие стадии названы неправильно, каким «settled» сборщикам он не доверяет. Затем выбирается один поток, которому даётся «мясо».
+
+## 6. Дополнение 2026-10-11: ситуации, которых не видит извлечение claims
+
+Алекс перечислил реальные ситуации: административный шум («пройти опрос», «подтвердить банковский счёт»), назначенное, но не начатое; сделанное наполовину и давно не обновлённое (нужен пост о состоянии); локальные worktree-эксперименты без push; смерженные PR без комментария в задаче; PR-черновики; PR с комментариями без реакции. Извлечение claims читает только Asana-записи одного поддерева и видит из этого лишь «назначено, не начато». Пять из семи ситуаций требуют зеркала GitHub PR, которого в БД нет (PR есть только как URL в тексте и как живой снимок открытых PR).
+
+В карту добавлены (только план, не реализовано):
+
+| Поток | Статус | Что делает |
+|---|---|---|
+| `f/fetch/github_prs` | planned | Зеркало моих PR: состояние, draft, ревью, комментарии, дата merge, ссылка на задачу из тела PR. Идёт раньше батча на 250 работ. |
+| `f/analyse/work_triage` | proposed | Разделить шум и работу до извлечения: правила по проекту/имени, один дешёвый вызов модели для нерешённых корней, кандидат-аннотация в `task_annotations`, подтверждение Алексом (approval-шаг). Подтверждённый шум исключается из E2. |
+| `f/analyse/work_situation` | planned | Флаги по работе кодовыми правилами поверх claims + PR + worktrees: noise, untouched, stale, local-only, merged-silent, draft-pr, review-pending, каждый с уликой; одно предлагаемое действие на флаг для attend. Записей в Asana/GitHub нет. |
+
+Эти семь ситуаций должны стать контрольными случаями эталона E2.
+
+Список E2: все мои задачи сведены к корням по цепочке parent из `asana_task_observations`: 1396 корней, 135 с открытой моей работой, 115 закрытых за 3 месяца. Предложение: 135 + 115 = 250 работ после триажа; из них ~80 для ручной разметки. Файл: `tools/rlm-lab/datasets/private/e2-draft-2026-10-11/list.md`. Батч по 10 оставшимся работам выборки 10.10 запущен 11.10 в 11:43 (`eval/batch-2026-10-11.log`).
+
+## 7. Результат первого прохода E2 (11–12 октября 2026)
+
+Очередь отработала целиком с 11:43 11.10 до 07:20 12.10 на локальной Qwen3.8-27B через проверенный путь стенда (`build_input.py` → `baseline.py` → `rlm-claims-load.js`), не через Windmill-поток извлечения, который остаётся скелетом. Триаж шёл через реальный поток Windmill `f/analyse/work_triage` без паузы на подтверждение.
+
+| Фаза | Работ | Исход |
+|---|---|---|
+| Выборка 10.10, остаток | 10 | все загружены |
+| E2: 50 открытых + 30 закрытых с июля | 80 | 80 загружены, 4 невалидных JSON |
+| b: остаток окна с июля | 98 | все загружены |
+| c: закрытые за 12 месяцев | 294 | 293 загружены, 1 сбой по таймауту |
+
+Итого в `work_analysis_runs` 481 прогон, 475 валидных, 18,5 часа модели, в среднем 8 тысяч токенов промпта. В `work_claims` 11 995 утверждений-кандидатов; 5 807 с цитатой, из них 5 794 цитаты существуют в записях. Триаж в `task_annotations`: 494 корня work, 227 recurring, 54 rotation, 47 admin, 15 personal, 18 unknown.
+
+Что видно до разметки:
+- Флаг confirmed по-прежнему бесполезен: 707 из 712 «implemented» и 238 из 240 «released» помечены как подтверждённые. Правила принятия в коде обязательны до любого использования.
+- Четыре крошечные работы (одна задача, несколько историй) получили голый массив или эхо схемы вместо объекта; нужен строгий повтор для тонких входов.
+- Модель иногда выдаёт состояния вне перечня («completed», «closed»); разбор результата не проверяет enum.
+- Одна работа с 300 подзадачами дала пакет 405 тысяч символов: обрезка по бюджету в `build_input.py` не гарантирует предел, вызов не уложился в 30 минут. Чинится принудительной обрезкой.
+- Mattermost и Zoom ни к одной работе не привязались: явных ссылок нет, это ожидаемо до потока `work_links`.
+
+Данные: `tools/rlm-lab/datasets/private/{e2,e2b,e2c}-2026-10-11/` (вне git), журнал очереди `queue-2026-10-11/queue.log`.
+
+Полная выгрузка результатов по всем 486 работам со ссылками на Asana и выводом модели: [[work-claims-results-2026-10-12]] (2 МБ; генерируется `scripts/rlm-results-export.js`).
@@ -1,4 +1,6 @@
-# Personal OS — актуальное состояние проектов
+# [УДАЛИТЬ] Personal OS — актуальное состояние проектов
+
+**2026-10-09 — решение пользователя:** удалить из рабочего контура текущий прототип `project-evidence.js` / `project-truth.js` с ручным реестром `project-truth-projects.json` и правилами под два заранее выбранных случая. Метка относится к этому прототипу; требование общего анализа состояния проектов сохраняется. Здесь зафиксировано решение; код и расписания этим изменением не удалены и не отключены. Описание и этапы доработки ниже сохранены как история, а не действующий план развития этого прототипа.

 > **Текущий план R2:** [[personal/projects/personal-os/personal-os-system-review-index]]. Целевая архитектура и порядок реализации ниже заменены R2; исторические решения и описание прототипа сохранены для происхождения требований.

@@ -1,6 +1,6 @@
 ---
 title: Research Queue
-updated: '2026-05-24'
+updated: '2026-10-14'
 type: meta
 ---

@@ -15,6 +15,6 @@ type: meta

 ## Completed

- [x] WireGuard VPN → [[tech/wireguard-vpn]] (2026-05-23)
- [x] Executor Architecture v2 → [[concepts/executor-orchestrator]] (2026-05-19)
- [x] Executor Security Incident → [[concepts/executor-security-incident]] (2026-05-22)
+- [x] WireGuard VPN → [[family/how-to/wireguard-vpn]] (2026-05-23)
+- [x] Executor Architecture v2 → [[personal/projects/personal-os/executor-orchestrator-redesign]] (2026-05-19)
+- [x] Executor Security Incident → [[personal/projects/personal-os/executor-security-analysis]] (2026-05-22)
@@ -1,7 +1,7 @@
 ---
 title: Vault Namespace Rules
 created: '2026-05-23'
-updated: '2026-05-23'
+updated: '2026-10-14'
 type: tech
 namespace: personal
 tags: [vault, meta, conventions]
@@ -11,7 +11,7 @@ related:

 # Vault Namespace Rules

-Rules for where notes live in the Obsidian vault. See also [[SCHEMA]] for
+Rules for where notes live in the Obsidian vault. See also [[personal/projects/personal-os/wiki-schema]] for
 full frontmatter conventions.

 ## Namespace Assignments
@@ -1,8 +1,8 @@
 ---
 title: Virfield
 namespace: personal
-updated: '2026-10-03'
-status: candidate-clean-image-ready-clone-pending
+updated: '2026-10-15'
+status: release-hardening-live-acceptance
 tags:
  - virfield
  - macos
@@ -10,28 +10,254 @@ tags:
  - go
  - infrastructure
 ---
-# Virfield — статус 2026-10-03
+# Virfield — текущее состояние

-**Следующее действие:** проверить загрузку, работу и удаление временного клона из нового чистого образа Monterey/Xcode.
+Актуально на 2026-10-15 08:35 UTC. Maintained checkout `/Users/admin/Developer/virfield`, ветка `codex/retire-lume-release-hardening`; clean installed/pushed `6779b6faa1983a20fbc831fa1b415c110c087c67`, версия `0.0.0-native-protocol`, archive SHA256 `3ee01fe145444c7da23bef19aa349c8ce007b772c85b3149ffcba73fd2af569d`. Full localCI15Python+Go vet/race, Staticcheck, Gitleaks218, govulncheck0reachable/imported и installed exact-version HTTP/freshstdio/all4runbooks/resources/status PASS. Signing/FDA identity и7 исходных image manifests сохранены. Исправлены доказанные native false-negative: Sonoma failure08:02:35→automatic ready08:02:36, Sequoia failure08:06:42→automatic ready08:08:33; свежие GUI/newSSH I/O после этого PASS без manual GUI unlock, API state не переписывался. Startup/result теперь делят исходный5min command budget (real shell red/green PASS). Desktop readiness проверяет actual RFB через pinned guestSSH; worker Aqua agent также требует greeting перед result/startup после каждого reboot, image scopes пропускают worker desktop. RealSSH и actual AppleBash TCP tests покрывают fragmentation/deadlines/wrong service; все retained diagnostic fixtures released. Прежний LISTEN не доказывал работающий Screen Sharing: Sonoma direct greeting занял13.5sec, Sequoia cold node30sec timeout; guestlocalhost позже0.3sec, nodeforwarding после этого0.01sec. На installed6779 ошибочный cross-container Monterey live отклонён invalid_request ДО reservation, без новойlease. Latest6779 две sequential iPadMonterey полностью прошли nativeGUI/newSSH до/после reboot,1920×1080, isolation/workload/artifact/RFB/release; RFBпослеreboot~2ms. Negative cross-container gate PASS доreservation. Journal `virfield-installed-ipad-monterey-6779b6f-20261015`. ДополнительныйSwiftwatcher подтвердил версии, но compile прервал наш запланированныйreboot: currentcompilePASS не заявлен; предыдущий8c compile/run на неизменённомgolden подтверждён. Concurrent HTPC Sequoia→Sonoma ещё идёт в `virfield-installed-htpc-native-6779b6f-20261015`: перваяSequoia ready и вrealreboot, вторая готовится. FullHTPC PASS ещё не заявлен. Датированные Tart8/8, latest8c Monterey2/2+Xcode/Swift, physicalHTPC, controller-state restore, signed rollback/forward и private factory/GHCR PASS сохраняют свой scope. Current owning MCP выдавал старый2724f94 runbook; browser GUI ждёт явного unlock Mac; existing HTPC golden chmod требует отдельного approval. Запросы без ответа, полный release acceptance не заявлен. CI локально, main не обновлён. Датированные записи ниже сохраняют provenance, а не одновременный current installed state.

-## Состояние
+## Runtime и deployment

- 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 не сделан.
+- Установленный runtime: Tart на Apple Silicon + SSH physical nodes `mbp-2014` и `htpc`. На HTPC macOS lab VM работают через rootless Podman/QEMU/OpenCore.
+- Deployment `~/.virfield-v2`, config `~/.virfield-v2/config.json`, state `~/.virfield-tart`, daemon `~/.virfield-v2/bin/virfieldd`, API `127.0.0.1:7780`, launchd `ai.virfield.virfieldd`.
+- Virfield переключён с Lume на Tart 2026-10-08. В текущем hardening-кандидате удалены Lume backend/factory/wrapper/patch/build/install paths. Неявный legacy runtime и `image_tools` отклоняются. Старые поля профилей читаются только для совместимости журнала; новый Tart builder отклоняет IPSW-рецепты до резервирования build.
+- Старый `ai.virfield.lume` отключён (launchctl disable + bootout) 2026-10-14 после проверки пустого inventory. Служба отсутствует в загруженных system services, порт 7777 закрыт. Plist/бинарники сохранены для отката; Homebrew Lume отсутствует.
+- Не создавать второй manager/listener, не менять порт и не редактировать SQLite/runtime disks в обход журнала.

-## Установка 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 не увеличивалась.
+- Один exclusive physical-host lease независимо от VM slots; VM не занимает host slot; node-side atomic host lock и post-wake проверка boot volume.
+- Общий sleep hold с reference counting и сохранением чужого hold; при ошибке Podman cleanup overlay и hold сохраняются.
+- Node image deletion сохраняет provider/guest identity, защищает backing goldens и проверяет отсутствие контейнера.
+- Tart image_create выбирает approved digest-pinned bases из runtime.tart.bases и настроенных templates; default location соответствует конфигу. Base/developer/automation/macOS 27 recipes; generic automation проверяется после reboot.
+- Shared resumable Xcode archive store, checksum/quarantine, exact-job Apple sign-in recovery в resolve до VM build.
+- Registry resolver принимает Tart flat/ASIF format, image_pull сохраняет pin/provenance. Publish строит новый portable guest с публичным admin/admin, не ставит private golden credentials, sanitizes и подтверждает временный cleanup. Private managed golden не загружается.
+- Init/installer используют три бинарника и только сервис Virfield; отдельный private state-dir и optional native browser. CLI config-check проверил действующий config.
+- Orchard проходит обязательный per-lease SSH preparer; source-only remote template отклоняется до VM creation. Полноценная remote factory/access и live pool acceptance отсутствуют.
+- Pending image build/export резервируют CPU/RAM/disk до dispatch и учитываются вместе с worker leases; для нового macOS 27 base нужен known/declared disk bound. Host IDs не могут совпадать между primary и node inventories.
+- Backup включает node management keys и cached probes, отклоняет symlinks в identity tree.
+- Go 1.26.9, pinned Staticcheck без замечаний, govulncheck: 0 reachable/imported-package vulnerabilities. Module-only notice openpgp относится к неиспользуемому пакету и не имеет fixed version.
+- Удалён источник CI Pillow failure: retired Python image factory/tests и Lume build step. Это исправление workflow, а не результат нового GitHub CI.

-## Legacy-клон и проверки
+## Исторические checkpoints приёмки (2026-10-14)

- `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`.
+Следующие абзацы сохраняют состояние ранних кандидатов и старых пакетов на дату их проверок. Актуальный installed и открытые gates указаны в начале заметки; последующие датированные PASS по GHCR/restore/rollback заменяют ранние pending, а не противоречат им.
+
+Кандидат **ещё не принят для релиза**. Установка `09ad696` сохранила signing identity/Team ID E3R68ED529 и все пять image-ready записей. Шесть последовательных Tart clones (по два Ventura/Monterey/macOS 27) прошли SSH/host-key изоляцию, OS/build/SIP, desktop, artifact export и release. External SSD не допускает два диска полного размера с сохранением резерва; concurrent acceptance будет выполняться на отдельном временном внутреннем контейнере. Exact commit `09ad696cacea2ba9cd2245fa76cc599696470d01` прошёл полный make check (docs, 7 Python tests, gofmt/vet/full race), Staticcheck, module verify, Gitleaks (196 commits), govulncheck (0 в используемом коде), действующий config-check и Packer syntax checks. Clean archive/extraction/init/checksums/native signature smoke прошёл: `/private/tmp/virfield-release-check-09ad696/virfield-v0.0.0-localcheck-darwin-arm64.tar.gz`, SHA-256 `f12f2be162cbcfa7688c814a8fcdbb13d17ff028053f878aa27ac1e87e2bbe3c`. Это локальная тестовая упаковка, не опубликованный release. Live public Tart manifest resolution также прошёл. Factory/GHCR roundtrip в работе: отдельный temporary Tart container и push source настроены, разрешён новый private `mallexxx/virfield-hardening-acceptance`. Первый cold Packer build завершился EOF; после проверки отсутствия процессов/VM его собственная запись удалена через journaled recovery. Установленный `aee89c1` prefetches source в retryable resolve и отключает implicit pruning. Factory golden `image-5387f340da4ae093162383c18449c592` rebuilt/qualified, generic automation прошёл post-reboot проверку; два последовательных клона прошли SSH/cross-key/host-key isolation, exact OS/build/SIP, desktop и artifact export, затем оба released. Private GHCR publication требует idle pool и пока не запускалась; полный roundtrip не принят. Текущие исходники, установленный daemon и published archive нельзя считать одним артефактом.
+
+Installed MCP прошёл HTTP и fresh stdio discovery/help/status с 18 tools, HTTP 401 без авторизации и ещё два полных fresh stdio acquire/replay → SSH/workload/artifact/desktop → release цикла на собственных factory-клонах. Оба дополнительных клона удалены. Live discovery gate исправлен: проверяет обязательные имена вместо устаревшего hardcoded count 17. Source MCP metadata теперь соответствует Tart/node budgets, approved bases и unlocked APFS/FileVault policy. Ventura `TestLiveLeaseSSH` прошёл exact Xcode 15.2/15C500b, Swift workload, SCP, cross-key/image-key rejection, desktop/tunnel revocation, cleanup и рестарт daemon с сохранением lease SSH identity. Signed installed archive `aee89c1`: SHA-256 `2313602b2c380e5e74640c47ee6ad50d9c10d750f856a0949833a4489803cf35`; хеши трёх подписанных бинарников сохранены в `~/.virfield-v2/upgrades/20261014-aee89c1/installed.json`. Полный локальный make check, Staticcheck, Gitleaks и регрессионные race-тесты нового inventory fix прошли. Clean archive exact source `8a297748eac5035fa0f0453aa51e11e9cb77d4e4`: `/private/tmp/virfield-release-candidate-20261014/virfield-v0.0.0-candidate-darwin-arm64.tar.gz`, SHA-256 `e2efde0214c7f4967528308b850575baac4a464e4e6c86425e871e11b8879488`; extraction, все binary checksums, native browser signature и действующий config-check проверены. Idle-only installer `/private/tmp/virfield-install-8a29774.py` подготовлен, не запускался; включает три бинарника и актуальный native Apple browser, rollback backup и повторную проверку свободного pool. Fresh MCP из этого clean archive прошёл discovery/help/status и проверку исправленных metadata.
+
+macOS 27 lease `lease-6fde5d2f33c234f2e885583fb6a8fd34` штатно released по прямому разрешению пользователя «27ю вм можно отпускать» (2026-10-15 Asia/Bishkek). Cleanup `job-3168397fcd2d6cf4bc821abe7dead124` succeeded; VM `vf-6fde5d2f33c234f2e885583fb6a8fd34` подтверждённо отсутствует, все семь image-ready records/manifest identities сохранены. Прежняя iPad lease `lease-327bb8e4a3a06b7d5ac8e527c57d1907` также released её владельцем. Новая iPad Monterey lease `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea` тоже released владельцем; пользователь подтвердил «Вторая вм отпущена, можешь продолжать». Idle pool 0/2 проверен до установки `9a740c0` и diagnostic `24512c7`; сохранены все семь goldens. Heartbeat `virfield-lease` ACTIVE каждые 15 минут; пользователь разрешил однократное продолжение установки/live/factory/private GHCR/локального CI/docs/push, после завершения она отключится. Чужие ресурсы сохраняем. Canceled-inventory fix теперь установлен; причина drift старых рабочих leases не установлена.
+
+Offline restore `backup-5cdef526c555f6a53ed5f565c6e2edaf` в отдельный private каталог прошёл: 18 файлов, SQLite integrity, пять active image identities/credentials/verification, тот же node management key, новый operator token и config-check. Restored daemon не запускался; live restore/rollback остаются gates.
+
+Ранее принятые срезы сохраняют свои даты:
+
+- Ventura 13.7.4/Xcode 15.2 и Monterey 12.7.6/Xcode 13.4.1: golden qualification и две аренды, 23/23 на каждый golden.
+- macos27 27.0/26A428/Xcode 27.0/uitest-27-v1: Broker v1 smoke passed 2026-10-08.
+- R1: четыре boot volumes MacBook по очереди; HTPC wake-by-lease (27 с).
+- R2: secured Sonoma 14.8.9 и Sequoia 15.8.1 на HTPC, 19/19.
+- R3: Screen Sharing VM lease tunnels, 11/11. Physical desktop и browser noVNC не реализованы.
+
+Node VM quotas реализованы и установлены в `aee89c1`: CPU/RAM/full disk reservations, pending image builds, cache cap, qcow2/storage probes и post-wake clone/start/commit checks. Live probe корректно отказал в 100 GiB VM на home NVMe с 99 GiB free и reserve 20 GiB. HTPC deployment config уже переключён на private storage root HDD `/run/media/system/Data/virfield/runtime`. После Wake API свежий available probe подтверждает около 2.87 TB free, CPU budget 8, RAM 24 GiB и cache cap 512 GiB; старый asleep cached probe относился к NVMe. Новый live node suite ещё нужен; права существующих HTPC goldens не менялись без отдельного разрешения. Read-only namei подтвердил 0444 у двух старых secured qcow2/OpenCore файлов и traversable directories; migration к 0400 остаётся permission/release gate. Будущий v3 capability API, grants, node-agent, Access/noVNC, VS Code extension и расширенный fleet/hardening остаются roadmap. Опубликованный v2.0.0 — исторический Lume-релиз 2026-09-30.
+
+## DDG macOS UI tests: проверенные проблемы и исправления (2026-10-14)
+
+Историческая рабочая lease `lease-6fde5d2f33c234f2e885583fb6a8fd34` сессии Claude Code (`apple-browsers.git/fix-macos-ui-test-failures`) уже released по разрешению пользователя. Следующие результаты относятся к source-проверке `624bdfa7a88738809729e6889c679eaf0241eb78`; текущая installed acceptance более нового кандидата выполняется отдельно.
+
+- **Locked keychain — исправлен и live-проверен в source.** DDG CI вызывает `create_keychain_ui_tests` в `macOS/fastlane/Fastfile`: DefaultKeychain/`default`, default + unlock, timeout 54000, без lock on sleep. DDG EncryptionKeyStore хранит encryption key через native generic-password SecItemAdd с WhenUnlocked. GUI и каждое SSH-подключение имеют отдельную Security audit session, поэтому разблокировка только одного контекста недостаточна. Кандидат готовит private per-image/lease default keychain через Aqua LaunchAgent и разблокирует его непосредственно перед каждой исходной SSH-командой через VM-only ForceCommand. Native запись/чтение/сравнение данных/удаление проверяются в обоих контекстах, после reboot — с новым boot UUID и nonce. Публичный/пустой пароль не используется.
+- **Старый login keychain и ScopedBookmarkAgent — тоже закрыты.** Одной смены default keychain оказалось мало: OS service продолжает обращаться к login и оставляет модальный password dialog над браузером. Новый preparer сохраняет его items, меняет пароль на текущий private VM password, проверяет native доступ после lock/unlock новым паролем и сохраняет login в search list. Старый image password не остаётся в worker identity. Ручное убийство SecurityAgent не является частью нового readiness.
+- **Дисплей — исправлен в source.** Старый установленный golden отдаёт 1024×768 pt / 2048×1536 px и список преимущественно 4:3 режимов; workaround владельца на нём — 1920×1440 1x. Новые Tart recipes/clones задают 1920×1080 logical и запрещают refit окна. Host-side hint сам по себе недостаточен: Aqua agent выбирает native режим через CGBeginDisplayConfiguration → CGConfigureDisplayWithDisplayMode → CGCompleteDisplayConfiguration(permanently). Временный CGDisplaySetDisplayMode откатывается при выходе процесса. Новые isolated factory и worker подтвердили actual GUI frame 1920×1080 после reboot.
+- **SSH banner после boot — исправлен в source:** 45 секунд в daemon handshake и generated CLI config; timeout до выполнения команд классифицируется как retryable connection failure. Host pin/auth failures не повторяются. Regression test прошёл.
+- **macOS 27 factory / ASIF — дополнительно найден и исправлен:** отсутствие recovery_partition выбирало Packer default deletion, оставляя открытый/заблокированный ASIF file и вызывая Virtualization.framework startup failure. Все macOS 27 recipes теперь явно keep Recovery. Полный новый source resolve → Packer build → qualify/reboot → stop прошёл.
+- **vm_tunnel backend_unavailable / vm_drift — installation gate остаётся.** Прямой SSH рабочей lease отвечает, API считает её needs_attention. Canceled inventory regression исправлен в source и проверен тестами; это не доказывает единственную причину drift этой конкретной чужой lease. Повтор live tunnel acceptance нужен после безопасной установки.
+- **VMShare отсутствует по текущему контракту:** checkout и DerivedData копируются pinned SSH/SCP/rsync с сохранением путей, нужных pre-actions. Общий host каталог автоматически не монтируется.
+- **macOS UI Tests CI ожидает prebuilt products.** CI скачивает notarized Review app; для локального запуска нужны отдельно собранные macOS Browser Review и macOS tests-server. Сам VM manager не угадывает build scheme.
+- **Xcode 27.1 products → guest Xcode 27.0:** два реальных запуска DownloadsUITests.testDownloadFinishesThenPopupIsShown прошли (1 test / 0 failures каждый), включая browser startup и Settings/General clicks. Второй запуск выполнен после source guest agent/reboot без ручного unlock. Это single-test smoke, а не приёмка всей UI-suite или всех minor version сочетаний.
+
+Дополнительная приёмка: Ventura native GUI key I/O/reboot; macOS 27 native GUI и SSH key I/O/reboot; source macOS 27 factory; два source Prepare-клона нового factory golden с SSH identity isolation, login rekey и real worker reboot — PASS. SCP upload/download с SSH bridge — PASS. Все четыре isolated VM этой проверки подтверждённо удалены; две неудачные old-daemon factory записи удалены через exact-name journaled recovery после проверки отсутствия процессов/VM. Production goldens и чужие leases не менялись.
+
+Private evidence: `/private/tmp/virfield-keychain-macos27-standalone-20261014`, factory image `image-3ded21740aa5ee237b85aac1fc8bbe52`, source recipe SHA-256 `38a47b46c05c906e3b104d7c6a9d83479047213deaf3002b93f2e2af6debd6ae`. Exported DDG xcresult archive `ddg-final-xcresult.zip`, SHA-256 `cfe8100c567effaed5271f8b32f819b372ea2a22f65c7794e2013a0351555b76`. Local make check (docs, Python, vet, full race), Staticcheck и Gitleaks прошли. GitHub CI не использовался как acceptance.
+
+## Каноническая документация
+
+- [Operations](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/OPERATIONS.md) — config/install/services/recovery.
+- [Image pipeline](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/IMAGE-PIPELINE.md) — актуальные Tart/node contracts.
+- [Verification](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/VERIFICATION.md) — фактические gates/evidence.
+- [3.0 plan](https://github.com/mallexxx/virfield/blob/codex/retire-lume-release-hardening/docs/VIRFIELD-3-PLAN.md) — реализованное и оставшееся.
+
+Ссылки ведут на опубликованную hardening-ветку; `main` ещё не обновлён. Старая история: [[personal/projects/archive/virfield-checkpoints-through-2026-10-08]].
+
+## iPad Markdown editors: Monterey build (2026-10-14)
+
+Работа: [[personal/how-to/ipad-ios935-build-deploy]]. Цель — сборка открытых редакторов на `monterey-xcode-13.4.1`, armv7/iOS 9.3.5, fake sign и установка на подключённый iPad mini 1.
+
+Наблюдения этой сессии:
+
+- В 21:53–21:56 (Asia/Bishkek) admission сначала был занят 2/2: чужой `lease-6fde5d2f33c234f2e885583fb6a8fd34` и quarantined image `image-2ec1111415abc0c1e1e66a8e293b14db` / job `job-9f321bedd55313ed859c8eaa9844c3ce` (`image_command_failed`). Чужие записи и VM не менялись. Позднее статус показал освобождение image reservation и один свободный слот.
+- Первый `vm_acquire` для Monterey с default storage вернул `resource_exhausted`: `No eligible clone storage has enough free disk for reserved VM growth and host safety reserve: samsung-tart`. При этом status показывал `capacity.available=1` и около 251 GB физически свободного места на Samsung; admission дополнительно учитывает полные reservations и safety reserve. Это ограничение ресурса, не доказанный дефект.
+- Новый запрос с явным `destination_location=release-check` принят: lease `lease-9e65ca2f956c0f061eb3ac021d9f6b6f`, prepare job `job-ee57f1c483518f251f1bcd095621e6e9`, VM `vf-9e65ca2f956c0f061eb3ac021d9f6b6f`. Тело и idempotency key сохранены в `~/Developer/ipad-editors/virfield-acquire-release-check.json`.
+- Job через ~2 секунды перешёл в `needs_attention`, phase `clone_dispatched`, error `clone_outcome_unknown`; lease — `quarantined`, `clone_confirmed=false`. Events 840–842 не сохраняют исходную ошибку backend, только общий текст `Runtime create did not return confirmed success. Automatic replay and deletion are blocked.`
+- Установленный Operations runbook прямо предупреждает: `Local Tart cannot clone a local golden across TART_HOME containers; do not configure a cross-container fallback for such templates.` Исходники `internal/tart/client.go:414–422` отклоняют такой cross-container clone ДО вызова Tart. Здесь golden находится в `samsung-tart`, а выбран destination `release-check`; это соответствует запрещённому пути. Controller (`internal/control/controller.go:1050–1063`) превращает любое Clone error в неоднозначный outcome и quarantine. Следствие: детерминированный preflight rejection занимает reservation и требует operator recovery, а исходная причина не видна в job/events. Это найденная проблема интерфейса admission/диагностики, не исправленная в этой сессии.
+- Повтор acquire, resolve/release и обход journal не выполнялись. Для восстановления нужен exact-name operator resolve после подтверждения отсутствия операции, с отдельным подтверждением пользователя: команда recovery может навсегда удалить собственную VM. Чужая работа не затрагивается.
+
+В этом начальном checkpoint сборка ещё не запускалась и готового Monterey lease не было. Тогда TTL quarantined lease был до 2026-10-15 00:58:14 Asia/Bishkek; истечение TTL само по себе не доказывает cleanup. Эта аренда позднее штатно released после разрешённого recovery; новая Monterey прошла rebuild и уже используется для сборок (см. проверку ниже).
+
+### Recovery approval review, 2026-10-14 22:18 Asia/Bishkek
+
+После пользовательского «Да» выполнены повторные read-only status/job проверки: собственный lease по-прежнему quarantined, job needs_attention, runtime inventory не содержит собственной VM; никаких running/queued операций для неё нет. Попытка штатного CLI resolve с exact lease/VM и CONFIRM-NO-OPERATION-IN-FLIGHT остановлена automatic approval review ДО запуска команды. Reason: transcript does not contain a clear user approval for this exact irreversible lease deletion. Recovery не выполнен, slot reservation остаётся. Нужен однозначный ответ пользователя с разрешением удалить только `lease-9e65ca2f956c0f061eb3ac021d9f6b6f` / `vf-9e65ca2f956c0f061eb3ac021d9f6b6f`. Это approval blocker, не новый сбой Virfield backend.
+
+### Recovery и новый образ, 2026-10-14 22:30 Asia/Bishkek
+
+После явного ответа пользователя «Разрешаю recovery и удаление указанной VM» повторно проверен остановленный prepare job, затем выполнен штатный exact-target CLI `resolve`. Cleanup `job-1fe239f3064566b2a4b3f75ebce13813` завершился `succeeded` в 16:29:45 UTC. Предыдущий approval blocker снят; освобождена только собственная аренда Monterey. Работающая macOS 27 VM `vf-6fde5d2f33c234f2e885583fb6a8fd34` не менялась.
+
+Чтобы избежать cross-container clone, запущен новый `image_create` непосредственно в `release-check`: template/VM `ipad-editors-monterey-xcode-1341-20261014`, image `image-f8c888fcafbd1a2df2a3b9a02821685d`, job `job-076452fa609adc3e6d4093a8e047a693`. Exact profile: macOS 12.7.6/21H1320, Xcode 13.4.1/13F100, SIP enabled, тот же approved digest-pinned Tart upstream. Образ пока строится; это не подтверждение готовности worker или успешной сборки приложения.
+
+### Cross-container admission fix: source versus installed (2026-10-14)
+
+Monterey rejection выше относится к установленному `aee89c1`. В опубликованном source `624bdfa` проверка `Controller.cloneLocationCandidates` возвращает `invalid_request` при explicit wrong container для local Tart golden ДО reservation/job; `TestLocalTartGoldenRejectsWrongStorageBeforeReservation` проверяет отсутствие записанной lease. Без явного destination несовместимые default/fallback locations также отфильтровываются. Это уже исправлено в source, установка ещё ждёт освобождения рабочей macOS 27 lease. Cross-container golden copy не реализован; новый image в нужном container — допустимый отдельный workflow. Чужая iPad-сессия и её journal не менялись этой проверкой.
+
+### Исторический checkpoint: keychain/UI package (2026-10-14 16:49 UTC; superseded by 9a740c0)
+
+Published source `624bdfa7a88738809729e6889c679eaf0241eb78`, branch `codex/retire-lume-release-hardening`; clean worktree и remote branch совпадают. Package этого checkpoint `/private/tmp/virfield-release-keychain-624bdfa-20261014/virfield-v0.0.0-keychain-candidate-darwin-arm64.tar.gz`, SHA-256 `be29654ef02f4ab6cd747b1815c2a72532717aaf2d423a2a4d8a93e4013634bb`. Проверены extraction, все manifest binary hashes, native browser signature и deployment config-check. Idle-only installer `/private/tmp/virfield-install-624bdfa.py` подготовлен, не запускался; прежний installer/archive `8a29774` — исторический срез. Установлен по-прежнему `aee89c1`. На 16:49 UTC рабочая macOS 27 VM всё ещё running, её lease needs_attention; также работает отдельный image build `job-076452fa609adc3e6d4093a8e047a693` чужой iPad-сессии. Установка требует idle pool и ждёт выбранного пользователем освобождения рабочей lease. Полный GHCR roundtrip/node acceptance/live restore остаются release gates.
+
+Fresh stdio MCP из clean package `624bdfa` также прошёл initialize/discovery (18 tools), актуальный embedded runbook, read-only status и проверку новых native GUI/SSH keychain + 1920×1080 descriptions. Во время smoke VM/lease mutations не выполнялись.
+
+### Текущий candidate и разрешённое продолжение (2026-10-14 17:19:56 UTC)
+
+Current published source `9a740c0f2a5cf64ccd9fc00cff705ff5abc90d08`, clean checkout и remote `codex/retire-lume-release-hardening` совпадают. Последний clean package: `/private/tmp/virfield-release-readiness-9a740c0-20261014/virfield-v0.0.0-readiness-candidate-darwin-arm64.tar.gz`, SHA-256 `065413f0ea81bef181230227c91ac0446ab5c040ca1dc66522eb1d0d51ae9182`. Extraction, все шесть manifest binary hashes, native browser signature и действующий config-check — PASS. Idle-only installer `/private/tmp/virfield-install-9a740c0.py` подготовлен, не запускался. Архивы/установщики прежних commits — исторические; старый installer не соответствует новому HEAD.
+
+- Полный локальный make check: docs (26 файлов / 65 links), 9 Python tests, gofmt/vet/full Go race — PASS. Pinned Staticcheck v0.7.0 и Gitleaks v8.30.1 current tree — PASS. GitHub CI не использовался как acceptance.
+- Найден отдельный stale MCP client: уже подключённый процесс отдаёт старые Lume instructions, хотя установленный daemon использует Tart. Existing stdio processes стартовали до замен executable и сохраняют старый код/docs в памяти. Новый live MCP gate проверяет точную package version и все четыре embedded runbooks/resources against exact source; negative fixtures со старой version и stale runbook отклоняются. Fresh stdio нового package (version `0.0.0-readiness-candidate`, 18 tools, все четыре runbooks/resources, status Tart/HTPC) — PASS. Приёмка уже подключённых owning clients после их безопасного reconnect ещё нужна; чужие MCP процессы не завершались.
+- Acceptance journal теперь заменяется атомарно с fsync; failure до replacement сохраняет последний полный replay record. Body сохранён как точная JSON-копия отправленного запроса и не меняется при последующем изменении caller object; несовпадающий replay отклоняется до dispatch. Regression tests — PASS.
+- GHCR read-only preflight: configured account `mallexxx` подтверждён, token имеет `write:packages`; acceptance package пока 404 и preflight tag `registry_not_found`. Ничего не опубликовано. Подготовлен `/private/tmp/virfield-release-roundtrip.py`: требует exact installed commit/hashes и свободный pool, создаёт новые factory/pull names и уникальный tag, проверяет private visibility/digest, выполняет по два sequential clone/workload/artifact/release, удаляет только собственные goldens и сверяет исходный image baseline. Requests/IDs сохраняются; частичная clone pair требует проверки сохранённых identity/lease IDs. Runner ещё не запускался.
+- На последней read-only проверке pool занят 2/2: `lease-6fde5d2f33c234f2e885583fb6a8fd34` (`needs_attention`, VM running) и рабочая iPad lease `lease-327bb8e4a3a06b7d5ac8e527c57d1907` (`ready`). Active jobs отсутствуют: Monterey image build уже завершился. Установлен по-прежнему `aee89c1`; foreign leases/VM не изменены. Lume override `disabled`, system service отсутствует, порт 7777 закрыт — повторно подтверждено.
+- Пользователь явно разрешил однократное фоновое продолжение «Продолжай доделывать до готовности». Existing heartbeat `virfield-lease` обновлена, ACTIVE каждые 15 минут; после освобождения чужих VM/jobs продолжает установку актуального кандидата, live Tart/node/MCP, factory/private GHCR, локальные CI, документацию и source push, затем отключается. Пока pool занят, установки и рестарта нет. Это согласие не закрывает отдельный ещё ожидающий approval вопрос о правах существующих HTPC goldens.
+
+Candidate остаётся не release-accepted до installed/live gates. Full private GHCR roundtrip, node acceptance, current-client reconnect и live restore/rollback ещё не выполнены.
+
+### Monterey: проверка причины и результата rebuild (2026-10-14 17:43:03 UTC)
+
+Проверена именно Monterey/Xcode 13.4.1 из iPad-сессии. macOS здесь 12.7.6 / 21H1320; 13.4.1 / 13F100 — версия Xcode.
+
+- Исходный `resource_exhausted` на Samsung объясняется full disk reservations и safety reserve; свободный VM slot не гарантирует достаточно зарезервированного места для ещё одного диска.
+- Исходная cross-container lease `lease-9e65ca2f956c0f061eb3ac021d9f6b6f` клонировала local golden из `samsung-tart` в `release-check`. Tart backend детерминированно отклоняет этот путь до вызова clone; установленный `aee89c1` принял destination в admission, затем скрыл исходную причину за `clone_outcome_unknown` и quarantine. После разрешённого exact-target recovery эта lease `released`, её prepare job `canceled`; активной reservation больше нет.
+- Новый image `image-f8c888fcafbd1a2df2a3b9a02821685d` / template `ipad-editors-monterey-xcode-1341-20261014` построен непосредственно в `release-check`. Build job `job-076452fa609adc3e6d4093a8e047a693` succeeded в 17:09:43 UTC. Qualification `~/.virfield-tart/images/image-f8c888fcafbd1a2df2a3b9a02821685d/verification.json` подтверждает точные OS/build/Xcode, SIP enabled, desktop и FileVault off/unlocked APFS; upstream остаётся `ghcr.io/cirruslabs/macos-monterey-vanilla@sha256:4bc904cf8f2447dfa6e6fb9a5eb70eba14196dd0f4236d30fc92aff9c2391842`. Recipe SHA-256 `c68480032289a6b8d9891765915509e8abdbd1fc5e4c39149256e27e38adcdd6`.
+- Новая рабочая lease `lease-327bb8e4a3a06b7d5ac8e527c57d1907` ready и использует этот image. Сессия «Найти редактор Markdown для iPad» реально собрала Notepad Example и iVim для armv7 и экспортировала products. Локально проверены export/package verification records, а `~/Developer/ipad-editors/exported-editors/iVim-upstream/build.log` содержит `** BUILD SUCCEEDED **`, `ARCHS=armv7` и SDK iPhoneOS15.5. Это подтверждает работоспособность нового worker; успех всего iPad workload/всех приложений здесь не заявляется.
+- Rebuild в правильном контейнере обходит исходный ошибочный маршрут, а не устанавливает fix в daemon. Published source `9a740c0` уже проверяет incompatible local Tart destination до reservation и возвращает `invalid_request`; regression и полный make check проходили. В production всё ещё `aee89c1`, поэтому старый admission-дефект может повториться до ожидаемой безопасной установки.
+- Native GUI/SSH keychain readiness нового кандидата на Monterey после установки остаётся отдельной live-проверкой. Текущие успешные сборки с disabled Apple signing не заменяют эту приёмку; действующая lease агента для неё не изменялась.
+
+### iPad workload: CocoaPods и новый vm_drift (2026-10-14 18:08 UTC / 2026-10-15 Asia/Bishkek)
+
+На ready Monterey `lease-327bb8e4a3a06b7d5ac8e527c57d1907` реально собраны Notepad Example и официальный iVim 1.40. .app, revisions, toolchain и полные build logs экспортированы на Mac; оба armv7 IPA fake-signed SHA1, установлены на физический iPad2,5 / iOS 9.3.5 через USB, процессы и UI подтверждены screenshots. Процедура: [[personal/how-to/ipad-ios935-build-deploy]]. SSH iPad отдельно настроен запрошенным пользователем `ssh-copy-id`; это другой сервер/ключ, не SSH Virfield.
+
+Проблемы гостевого toolchain, встреченные в этой VM (не доказанные ошибки Virfield backend):
+
+- System Ruby 2.6.10 universal.arm64e на Monterey падает Bus Error в FFI/Ethon, как с FFI 1.15.5, так и 1.17.3. Причина на уровне ABI/PAC не установлена; воспроизведение на require Ethon подтверждено. Рабочий обход — отдельный `.gems-x64` / x86_64 Ruby/CocoaPods 1.11.3 через Rosetta. Native gems не удалялись. Rosetta installation завершилась successfully; warning installKBytes не помешал `arch -x86_64` smoke check. Helpers сохранены в `~/Developer/ipad-editors/setup-cocoapods*-on-monterey.sh`.
+- Историческая Edhita требует old lockfile metadata: `pod install --deployment` возвращает changes for Bootstrap/Megrim/github-markdown-css checksums, repo aliases и CocoaPods 1.6.1 → 1.11.3. Host helper теперь допускает metadata migration, но проверяет точное равенство before/after массива PODS. Новый helper не успел попасть в guest из-за drift.
+- Flutter 2.10.5/Dart 2.16.2 x64 реально запустился; его git version-check завис на fetch/HTTP2 EOF. Используется `--no-version-check`. Pub resolution GitJournal остановился на публично недоступном GitJournal/ext_storage (404), host fallback опубликованного 1.0.3 ещё не проверен в guest.
+
+**Новый infrastructure blocker:** event 865 `lease.drift` в 2026-10-14T17:57:04.260529Z перевёл собственную Monterey VM `vf-327bb8e4a3a06b7d5ac8e527c57d1907` из ready в needs_attention, code vm_drift, message `Ready VM identity, address or running state changed; release the lease`. IP/SSH port очищены в lease, manager закрыл tunnel `127.0.0.1:60131`. SCP изменений и SSH сборки завершились banner timeout / connection reset, pub-get connection closed. Эти переносы не считать выполненными.
+
+Read-only status в 18:08:52 UTC снова показывает ту же VM running, IP **192.168.64.251**, SSH available true — адрес соответствует прежнему ready worker. Pool 2/2; вторая, чужая VM macOS27 не менялась. Job preparation собственного worker succeeded; новые queued/running Virfield jobs отсутствовали. Edhita/GitJournal compile завершённым не считается.
+
+Исследование источников установленного `aee89c1`: Tart `inspect` оставляет VM.IP пустым при любом error `tart ip --wait 0`, не возвращая lookup error; Controller считает две подряд несовпадающие runtime observations drift и необратимо сбрасывает ready/tunnel. Current source добавляет проверку canceled ctx и отбрасывает такой refresh. Это подтверждённый механизм возможного ложного drift, **но точный ipErr/observation в момент event 865 не записан**, поэтому конкретная первопричина данного события не доказана. Восстановившийся running/IP snapshot не возвращает lease в ready.
+
+Installed Operations допускает для needs_attention штатный exact-target recovery с cleanup; не предусмотрено re-adopt ready существующей VM. Direct-IP SSH, изменение SQLite, restart чужого daemon или direct Tart manipulation не выполнялись. Новое удаление `vf-327bb8…` требует отдельного разрешения пользователя: разрешение на старую `vf-9e65…` не распространяется на эту VM. Запрошено 2026-10-15; готовые IPA уже сохранены локально, исходники/SDK воспроизводимы. Golden `ipad-editors-monterey-xcode-1341-20261014` остаётся image_ready и доступен для замены worker после разрешённого cleanup.
+
+### Monterey: новый vm_drift (2026-10-14 18:08 UTC)
+
+Heartbeat обнаружила изменение после предыдущей проверки: `lease-327bb8e4a3a06b7d5ac8e527c57d1907` перешла из ready в needs_attention в 17:57:04 UTC, error `vm_drift`. В свежем inventory её VM `vf-327bb8e4a3a06b7d5ac8e527c57d1907` всё ещё running, IP `192.168.64.251`, SSHAvailable true. Lease IP после перехода очищен. Это не отменяет фактические успешные build/export выше, но текущая API-readiness уже не ready. Причина конкретного drift не установлена; в прочитанных daemon diagnostics за 17:56–17:58 UTC записей нет. Source canceled-inventory fix пока не установлен, его наличие не доказывает причину этого случая.
+
+Pool занят 2/2, active jobs нет; рабочая macOS 27 lease также не released. Ни foreign lease, ни VM, ни их tunnels/keys не изменялись этой проверкой. Установка и рестарт сохраняют ожидание согласно решению пользователя; heartbeat остаётся активной.
+
+### Разрешённый recovery второй Monterey VM, 2026-10-14 18:15 UTC
+
+Пользователь явно ответил «Разрешаю recovery и удаление этой VM Monterey». Exact-target CLI resolve для `lease-327bb8e4a3a06b7d5ac8e527c57d1907` / `vf-327bb8e4a3a06b7d5ac8e527c57d1907`, idempotency `ipad-editors-recover-20261015-327bb8e4`, завершился cleanup job `job-5cb66a109f395c15cd51633ab858bee7` succeeded в 18:15:12.999253 UTC; lease released. Старый blocker снят. Replacement acquire принят с новым caller key и сохранённым запросом `~/Developer/ipad-editors/virfield-acquire-replacement.json`: lease `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea`, prepare `job-b47d43f833f4bc28e4ec880f8fa40b00`, тот же ready golden в release-check. Worker пока готовится; чужая macOS27 не менялась.
+
+### Разрешённый release macOS 27 и новый pool blocker (2026-10-14 18:23 UTC)
+
+Exact-target release `lease-6fde5d2f33c234f2e885583fb6a8fd34` / `vf-6fde5d2f33c234f2e885583fb6a8fd34` выполнен по явному разрешению пользователя. Durable idempotency request сохранён до dispatch; cleanup `job-3168397fcd2d6cf4bc821abe7dead124` succeeded. Проверены released state, отсутствие VM в inventory, сохранение исходных семи images/manifest hashes и состояния чужой Monterey на момент завершения. Private evidence: `/private/tmp/virfield-authorized-macos27-release-20261015/journal.json`.
+
+Позже старая Monterey `lease-327bb8e4a3a06b7d5ac8e527c57d1907` released владельцем, а новая `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea` уже ready с 18:15:57 UTC; тот же template `ipad-editors-monterey-xcode-1341-20261014`, location `release-check`. Pool остаётся 1/2 occupied. Installer `9a740c0` не запускался, binaries/config/daemon не заменялись. Проверенное разрешение касается только macOS 27; текущую Monterey оставляем владельцу.
+
+### Replacement worker: Edhita deploy и GitJournal compatibility (2026-10-15)
+
+Replacement `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea` ready, actual macOS12.7.6/Xcode13.4.1 verified; IP192.168.64.252, pinned loopback tunnel55530. x86_64 CocoaPods preparation succeeded. Edhita build `20261015T001900Z` BUILD SUCCEEDED; PODS arrays before/after identical. Export, armv7/minimumOS checks, SHA1 fake sign, USB install and detached launch passed; screenshot shows Documents browser/Editor/Browser/Dual. Это третий успешно установленный редактор; процесс задокументирован в iPad how-to.
+
+Оставшиеся ошибки GitJournal относятся к upstream dependencies, не Virfield: public ext_storage fork unavailable, Firebase8 plugin minimum iOS10 при Runner9, downgrade Firebase6 конфликтует quiver2 с dart-git/quiver3, незакреплённые git HEAD refs обновляются до Dart3 при изменении resolution. Final local compatibility patch закрепляет четыре git deps исходными resolved-ref, использует опубликованный ext_storage1.0.3 и отключает optional Firebase analytics с удалением отсутствующего GoogleService-Info plist resource. `pub get` прошёл 8.8s, CocoaPods/native compile ещё идёт. Markdown/Git code не удалялся. Точный diff сохраняется в checkout; launch/Git sync пока не проверены.
+
+### iPad workload завершён; Monterey released (2026-10-14 18:51 UTC)
+
+На replacement завершена и GitJournal armv7 build. Final compatibility дополнительно закрепляет platform3.1.0/photo_view0.13.0 для Flutter2.10/Dart2.16 и генерирует пустой локальный Sentry config через reviewed upstream setup_env.dart. BUILD SUCCEEDED,49 Mach-O armv7/minimum≤9.3.5, SHA1 fake sign, USB install Complete/exit0 и detached launch/отображённый onboarding UI проверены. Таким образом четыре варианта реально установлены и запущены: Edhita2.3.0, Notepad Example, upstream iVim1.40 и GitJournal1.76+local compatibility patch. Full holzschu fork требует отсутствующих armv7 зависимостей и не установлен. Реальный vault/Git remote sync отдельно не настраивался. Полная процедура и ограничения — [[personal/how-to/ipad-ios935-build-deploy]].
+
+Пользователь явно поручил «Monterrey релизь если больше не нужен». До удаления экспортированы .app/IPA, metadata, exact source diffs/lockfiles, build logs и diagnostics/Gemfile.lock на Mac. Штатный vm_release exact `lease-9c1a94ff2b56b396fee7f1bbd2e0dcea`, key `ipad-editors-release-20261015-9c1a94ff`, cleanup job `job-efbdecc8f058d3b33ab55a2e03c2b448` succeeded в 18:51:19.492842 UTC. Lease released, runtime VM vf-9c1a94ff… отсутствует. Новый golden image-f8c888… image_ready сохранён. Никакой чужой lease этим агентом не освобождалась; daemon/journal/source installation не менялись.
+
+
+## Installed Monterey native acceptance — 2026-10-14 19:37 UTC
+
+`4a53b67ce04fd1adc164750b47e780c4bdde9ea6` установлен в idle pool с private backup, прежней Developer/FDA identity и сохранением всех семи goldens. Archive `virfield-v0.0.0-pixel-display-darwin-arm64.tar.gz`, SHA-256 `a71ceaf53dae64c2c91545cdfcff5749c656ba69677411fb154c3a3e6e301f19`; полный make check/Staticcheck/Gitleaks (206 commits) PASS, branch pushed. HTTP и fresh stdio exact-version/all-four-runbooks/resources/status smoke PASS для `0.0.0-pixel-display`.
+
+Два новых disposable clones именно свежего `ipad-editors-monterey-xcode-1341-20261014` (`lease-ef13cff121fecbc93f3a43a12b915702`, `lease-990032a673fa5826a2efa6396c271294`) прошли native WhenUnlocked add/read/data comparison/delete отдельно в Aqua и новом SSH до/после настоящего reboot с новым boot UUID/nonce; actual GUI 1920×1080, exact OS/build/SIP, разные SSH host keys и cross-key rejection, artifact export, RFB desktop, подтверждённый release и отказ обоих tunnels после release. Оба own VM удалены, iPad golden сохранён. Private evidence `/private/tmp/virfield-installed-monterey-pixel-4a53b67-20261015/journal.json`.
+
+Это закрывает воспроизведённый display-before-keychain defect свежего Monterey. Старый Samsung Monterey, Ventura, macOS 27 и HTPC native matrix ещё выполняются отдельно; current connected MCP по-прежнему возвращает исторический Lume runbook, owning-client reconnect не принят. Factory/private GHCR roundtrip ещё не запускался. Это не acceptance всей DDG UI-suite или всего v3 roadmap.
+
+
+## Installed Tart matrix — 2026-10-14 19:48 UTC
+
+Все четыре configured Tart profiles приняты на installed `4a53b67`: fresh iPad Monterey, Samsung Monterey, Ventura/Xcode15.2 и macOS27. По два свежих клона на каждый профиль (8/8). Каждый прошёл native GUI/новый SSH WhenUnlocked I/O до/после реального reboot с новым boot UUID/nonce и сохранённым pinned host key; actual GUI1920×1080, exact OS/build/SIP, cross-key rejection, разные host keys, artifact export, RFB desktop, штатный release и SSH/desktop revocation. Все own VM отсутствуют; семь goldens сохранены. Journals `/private/tmp/virfield-installed-monterey-pixel-4a53b67-20261015` и `/private/tmp/virfield-installed-tart-native-4a53b67-20261015`.
+
+Дополнительно найден native Apple browser defect: trustedOrigin требовал `state_dir == deployment`, что несовместимо с действующим separate state `~/.virfield-tart`. Исправление source `8e07015cde200a41fee6b490da97a44437803d7f` разрешает отдельный private owner state, проверяет владельца/права deployment/config/state, отвергает config/state symlink и не-loopback/подменённый origin. Реальный compiled Swift trust check на текущем config PASS; boundary regression tests, full make check (10 Python tests + Go race) PASS, source pushed. New exact package `virfield-v0.0.0-browser-state-darwin-arm64.tar.gz`, SHA256 `63c697126d63d3be3160ce57848d0338d2dfd1fe04a2ebbd267e105103b510e6`; установка выполняется после Tart cleanup. VM code/guest script этого коммита идентичны принятому `4a53b67`.
+
+Lume повторно подтверждён disabled/unloaded, port7777closed. HTPC secured goldens всё ещё0444; отдельный permission question пользователю остаётся pending, chmod не выполнялся. Live HTPC native matrix, portable private GHCR roundtrip, current owning MCP reconnect и live restore/rollback остаются gates.
+
+
+## HTPC inventory race — 2026-10-15 03:39 UTC
+
+Первая concurrent native matrix installed8e получила vm_missing сразу после confirmed clone. Только собственные lease-f760d6dc6090dd47cd10a5dd2669588f и lease-c8dd5ae4e8bf8cf8532f7634a8c73500 штатно released; отдельный native SSH probe подтвердил отсутствие обеих папок и Podman containers. Private journal `/private/tmp/virfield-installed-htpc-native-8e07015-20261015`.
+
+Причина воспроизведена детерминированным тестом: node mutation отмечала cache changed до команды; concurrent Observe успевал снять флаг и закэшировать отсутствие ещё не созданной VM. Новый source повторно инвалидирует cache после любого outcome, а Control ждёт snapshot, начатый после clone completion. Red/green regression tests, full local CI, Staticcheck PASS. Source2f46faadcce3bf9080b093e1bdab6bf26327a82f pushed и установлен с private backup, прежней signing/FDA identity и сохранением7goldens. Archive `virfield-v0.0.0-node-inventory-darwin-arm64.tar.gz`, SHA256 `1a94f247c9f0f57b10011b022dc580ac10401b4859805686ef9e59b26b4c4450`, PID6332. HTTP/fresh stdio exact-version/all-four-runbooks/resources/status PASS для0.0.0-node-inventory. Повторная матрица `/private/tmp/virfield-installed-htpc-native-2f46faa-20261015` выполняется, результаты пока не приняты. Host Wake API дал fresh available03:38UTC, private HDD root сохранён.
+
+Попытка native browser GUI smoke застала locked Mac и не завершилась проверкой; GUI launch не принят. Повтор CUA откладывается до явной разблокировки. Native compiled Swift trust check на actual split deployment/state и URL-scheme registration прошли ранее. Owning MCP reconnect остаётся отдельным gate. Существующие secured HTPC goldens0444 не менялись; async question на0400 файлов/0700 каталога пока без ответа.
+
+
+## HTPC HDD boot / внешний Steam I/O — 2026-10-15 04:01 UTC
+
+Повтор2f46faa прошёл clone/start после race fix, но оба concurrent Sonoma не достигли SSH к10-минутному deadline. Guest framebuffer показывал macOS boot (без kernel panic); I/O pressure full около44%. Оба own fixtures9687…/925a… released, native папки/containers absent. Новый source/installed ab9a2ad92ed2b97ca7714e800a6fa1261edaee5f задаёт DISK_CACHE=writeback/DISK_IO=threads (guest flushes enabled). Full CI/Staticcheck PASS; Gitleaks209 commits clean, fresh govulncheck0reachable/imported (module-only unused openpgp notice остаётся). Archive SHA256935fce3268e115e9ea496dc1209bc18c56ceb7100c25bd36b610b9692faef192; private backup/signing identity/7goldens сохранены. HTTP/fresh stdio exact-version/all-four-runbooks/resources/status PASS.
+
+Активная новая matrix `/private/tmp/virfield-installed-htpc-native-ab9a2ad-20261015`: собственные lease-81111c749a09dafe75ab4886809f5b0b и lease-783b910082aef60af102b947f3034e4e. Внешний Steam PID12980 создаёт около42MB read и42MB write за2сек, имеет62FD на том же VM HDD; content log подтверждает AppID766570 staging33,619,622,671bytes с09:39local. Это реальная общая I/O нагрузка; Steam не менялся. Новые QEMU env writeback/threads и NOCOW storage/data подтверждены, но улучшение boot и native node acceptance пока не доказаны. Evidence `external-io-blocker.json` в private matrix root. Нужен повтор после разгрузки HDD; не ослаблять keychain/readiness.
+
+Owning MCP PID65967 установлен через единственный новый API socket от текущего законченного read-only status request. Только этот старый adapter остановлен; остальные не менялись. Auto-reconnect не сработал (Transport closed), вручную переподключить Virfield MCP должен текущий client. Async request на unlock Mac + reconnect и отдельный permission question на0400/0700 остаются без ответа.
+
+
+## Controller-state live restore PASS — 2026-10-15 04:11 UTC
+
+Installed ab9a2ad, backup24b8cc75c691697893d48d44c6163bfb. Private copied SQLite/images/node management identity + new owner token запущены через existing launchd service на том же listener после атомарной смены config и SIGTERM; sudo bootout до этого не прошёл и ничего не изменил. Один manager/listener. Старый owner token отклонён401, exact HTTP/fresh stdio MCP PASS,7image identities/manifest сохранены. Два own Monterey clones a523fc64…/cd09f148… прошли native Aqua/SSH I/O, реальный reboot, display/workload/artifact/desktop/release/revocation. Read-only SQLite comparison доказал, что их records только в restored copy, original journal не менялся. Byte-exact original config/state возвращены, оба VM удалены. Evidence `/private/tmp/virfield-live-restore-drill-20261015/report.json` passed и `state-isolation-evidence.json`. Runtime disks не копировались; это controller-state restore, не VM-disk disaster recovery.
+
+## Factory capacity fix / GHCR roundtrip in progress — 2026-10-15 04:43 UTC
+
+Первый own factory image-b3dba0ef… failed до публикации: diskutilresize120GB successful, immediate rootdf14GB, grow script exit66. Packer/process/native VM absent подтверждены; private logs сохранены в `/private/tmp/virfield-release-roundtrip-20261014/failed-factory-attempt1`, exact-name journaled recovery delete job-eafb8752… succeeded. Новый логический attempt2 имеет отдельный durable key; исходные replay records сохранены, tag ещё не использовался.
+
+Source/installed2f23ae609a4f650130f5c84835f89931d6e70592: capacity проверяется на writable Data, до30сек после одного resize, реальная нехватка/invalidstats fail closed. Regression fixtures stale-root/delayed/full/invalid PASS, full localCI/Staticcheck PASS, branch pushed. Node prepare20min основан на историческом9min HDD cold boot до новых keychain checks; caller lease TTL и primary10min unchanged. Archive `virfield-v0.0.0-capacity-readiness-darwin-arm64.tar.gz`, SHA2569defb127d54a06c722d403e02ce90b2b427b2597613d51145d6eba2b81de60a1, installedPID88439, private backup/signing/FDA/7goldens preserved. Exact installed MCP version0.0.0-capacity-readiness/all4runbooks/resources PASS.
+
+Factory-r2 image-9b543d55… /job-007f3937… built/qualified/stopped: writable Data87,827,148KiB free (check0), subsequent rootdf тоже обновлён. Это подтверждает исправленный capacity gate; уникальный механизм initial stale root df отдельно не доказан. Два worker clones43b88366…/a9fb0d78… прошли SSH/key isolation, exact OS/build/SIP, workload/artifact/desktop/release. Portable publication image-92b7abe44ddaa89b910af025cce0e863 /job-3e83652b… построена заново из pinned public base, qualified и sanitized, private managed golden не клонировался для upload. Push в `mallexxx/virfield-hardening-acceptance:release-check-0644cb90dac8` выполняется (~20%); manifest/digest/private visibility/pull-back/workload/cleanup ещё не приняты. Durable journal `/private/tmp/virfield-release-roundtrip-20261014/journal.json`, planned pull `release-check-pull-0644cb90dac8`. При неизвестном исходе не менять replay keys и не повторять push вслепую.
+
+
+## Factory/private GHCR и controller rollback PASS — 2026-10-15 05:12 UTC
+
+Factory roundtrip завершён на installed `2f23ae6`: fresh public-base factory-r2/qualification и два worker workloads; отдельный новый portable public-base build с public bootstrap credentials и sanitization; push в разрешённый private `mallexxx/virfield-hardening-acceptance:release-check-0644cb90dac8`, verified private visibility, digest `sha256:a5d42b4e6e48641fba1af7171158de39252e4439d3087c1b019f392223054e73` (21,460,835,255 descriptor bytes); pull/qualification, ещё два clone/workload/artifact/desktop/release. Собственные factory/pull goldens удалены через journaled jobs; семь baseline IDs/manifests сохранены. Private managed golden не загружался. Durable evidence `/private/tmp/virfield-release-roundtrip-20261014/journal.json`, `passed:true`; registry artifact сохранён как evidence. Законченный roundtrip не повторять без относящихся к нему изменений.
+
+Source/installed `2724f94ed52696e5482ad8431a19d1a62a427e0b`, version `0.0.0-node-image-privacy`, archive SHA256 `7cff304d53dd3a59a1aed59fe25907d88495043a66bbb7c3f64ad07813bbe6d4`. Реальная empty Podman conversion воспроизвела mode0644 несмотря на внешний umask; OCI `--umask 0077` даёт0600. Исправление задаёт оба umask, применяет0400 до publish, отказывает при неоднозначном staging и удаляет только свой exact staging. Existing HTPC secured goldens0444 не менялись; отдельный approval остаётся pending. Exact full local make check, Staticcheck0.7.0, Govulncheck1.6.0 (0reachable/imported, один unused module-only openpgp notice) и Gitleaks211commits PASS. Signed install/private backup/FDA identity/7goldens сохранены, HTTP/fresh stdio exact-version/all-four-runbooks/resources/status PASS.
+
+Signed controller-binary rollback `2724 -> 2f23 -> 2724` PASS через один existing launchd service/listener; версии, свежиеPID, hash, исходныйconfig и7образов проверены. Первый probe остановился на transient startup inventory; inspect/resume принял уже запущенный старый controller и вернул новый без повторного rollback. Receipt `/private/tmp/virfield-controller-rollback-drill-2724f94-20261015/report.json` passed. Это controller-binary drill, не весь package/client rollback и не VM-disk DR.
+
+Steam завершил staging, HDD pressure до запуска новых VM почти0. Текущая HTPC matrix `/private/tmp/virfield-installed-htpc-native-2724f94-20261015` выполняется с20min prepare budget, own Sonoma leases `lease-ae6f4954e787d989c0d35d3264bd8b7a` и `lease-b236c8eb2ef310a66f42b00d6e3a3036`,8CPU/16GiB/200GiB reservations; native acceptance пока не принята. Lume повторно disabled/unloaded/7777closed. Manual owning MCP reconnect, unlockMac/nativebrowserGUI и exact existinggolden permissions approval по-прежнему без ответа.
+
+
+## HTPC: уточнение timeout и зависший warm reboot — 2026-10-15 05:57 UTC
+
+Установлен/pushed edcb756, archive SHA25682b7f7199948ba117a58a4e5067f4b12c56ab7811919038f2eadda7f8a0f80c1, version0.0.0-gui-observation. Exact local CI/Staticcheck/package/install/HTTP/fresh stdio all4runbooks/resources PASS. Оба concurrent Sonoma первоначально ready, один за304.6sec. После reboot первый verify снова failed с пустым output до native proof. Важное уточнение предыдущей записи: наличие startup proof76sec после boot и failure~2sec раньше не доказывает, что сработал именно60sec startup guard; существовал ещё30sec console-login guard. Исторический scope не заменяем предположением. Source теперь различает эти ошибки и bounded120sec console wait; реальный shell-block regression delayed login40 observations red на старом30 и green на120, absent console fail-closed.
+
+Следующий собственный diagnostic pair `lease-2537a3600bbb6adc2993526e88cffc62` / `lease-bc896a94e0345ba4f044cc17c5aa3ac3` достиг ready. Первый real guest reboot остался без новогоSSH/boot UUID, framebuffer сохранил часы до reboot. QEMU CPU активны, disk idle длится минуты; это не принятый reboot. Runner65766 был SIGSTOP до короткого harness cleanup, затем SIGTERM+SIGCONT завершён после сохранения evidence. Никакого второго reboot/reset не было. Обе exact leases затем released через исходный private journal и durable release keys. Root `/private/tmp/virfield-htpc-console-diagnostic-edcb756-20261015`, `runner-handoff.json`, framebuffer и journal. Новые foreign ресурсы не трогались.
+
+HTPC CPU i7-6700K, все CPU constant_tsc+nonstop_tsc, active clocksource tsc, VMX tsc_scaling absent. Actual QEMU Skylake-Client-v4 не получает invtsc. Pinned /run/proc.sh ошибочно ориентируется на tsc_scaling; upstream correction https://github.com/qemus/qemu/pull/1513 подтверждает отдельный capability defect. Source даёт +invtsc только по стабильным host signals на всех CPU, иначе -invtsc; heterogeneity/missing flags/non-TSC tests PASS. Это ещё не доказательство причины именно нашего stall; требуется live A/B.
+
+На framebuffer найден блокирующий Keyboard Setup Assistant. Реальный IORegistry QEMU USB Keyboard vendor1575/product1/country0, preference имел только Apple virtual65535-1452-0. Source добавляет только QEMU ANSI40, сохраняет остальные mappings, закрывает assistant в own VM и не принимает GUI ready с запущенным assistant. Actual defaults на disposable plist подтвердил integer40. Native node/UI/reboot matrix этим source ещё не пройдена. Все семь goldens сохранены; existing0444/0755 permissions pending отдельного approval. Manual owning MCP reconnect/unlockMac также без ответа.
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # Zulip Router

 _Последнее обновление: 2026-06-19 (forward_trigger, sender_email, data, stream_id — payload идентичен Zulip outgoing webhook)_
@@ -1,3 +1,8 @@
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+
 # balda-executor-mcp — MCP-сервер делегирования задач (шаг 5 Фазы 4)

 > Создан 2026-09-26. Шаг 5 плана [[personal/plans/balda-mm-phase4-agents]].
@@ -1,4 +1,9 @@
-# Callee + Prism — инструменты оркестрации и таск-трекинга
+# Callee + Prism — историческая справка по контрактам
+
+> [!WARNING] Версионная справка, 2026-09-29
+> Контракты ниже относятся к исследованным тогда версиям. Их нельзя считать описанием установленного Broker без сверки закреплённых зависимостей, workflow и worker package.
+> Проверенные версии, текущие образы, реальные прогоны и оставшаяся работа: [[personal/projects/balda/execution-broker]].
+> Старый [[personal/plans/balda-callee-prism-plan|план интеграции]] сохранён как архив.

 > Создан 2026-09-29. Опорная заметка к [[personal/plans/balda-callee-prism-plan]].
 > Назначение: справочник по контрактам callee и prism, чтобы не перечитывать
@@ -23,6 +23,11 @@ related:
  - '[[personal/tech/hermes-fork-vs-upstream.md]]'
  - '[[personal/tech/hermes-memory-architecture.md]]'
 ---
+> [!WARNING] Историческая схема Balda
+> Не использовать пути, контейнеры, provider или MCP transport из этой заметки для текущего запуска.
+> Канонический текущий runbook: [[personal/projects/balda/setup|Balda — актуальный локальный запуск]].
+> Актуально: `balda-mm-mac`, `/Users/admin/Docker/balda-mm-mac/config/config.yaml`, Mattermost, Codex ACP, Obsidian `type: http` → `http://host.docker.internal:3101/mcp`.
+

 # hermes-whale — Mattermost как транспорт

@@ -0,0 +1,76 @@
+---
+title: Legacy XCTest runner (run new-Xcode UI tests on macOS 12)
+namespace: personal
+updated: '2026-10-14'
+tags:
+  - xctest
+  - ui-tests
+  - macos
+  - duckduckgo
+  - virfield
+---
+# Legacy XCTest runner
+
+Runs DDG macOS UI tests built with the current Xcode (27.x) on a Mac that can only
+run an old Xcode, e.g. the MBP 2014 node (Monterey 12.6.8, Intel, Xcode 13.4.1).
+
+Location: `~/Developer/legacy-xctest-runner/` (not committed anywhere).
+
+## Why it is needed
+
+- New Xcode's `XCTest.framework` and `UI Tests-Runner.app` require macOS 14+.
+- The test bundle itself targets the app's deployment target (12.3), so it can run
+  if hosted by the old Xcode's runner.
+- The bundle imports 2 Swift symbols missing from Xcode 13 XCTest:
+  `XCUIElement.typeKey(_:modifierFlags:)` (mangled under `XCUIAutomation`) and
+  `XCTIssue.init(…severity:)`. `XCTestCompat.swift` forwards them.
+
+## How it works
+
+- `package.sh <derived-data> <out.tgz>` — collects `DuckDuckGo Review.app`,
+  `tests-server`, `UI Tests.xctest` + runner files.
+- `run.sh [--gui] <TestClass[/testMethod]> [result-name]` on the target Mac:
+  - builds `XCTestCompat.framework` (re-exports old XCTest + libXCTestSwiftSupport, adds forwarders);
+  - hosts the bundle in Xcode 13's `XCTRunner.app`, `install_name_tool` repoints the
+    bundle's XCTest/libXCTestSwiftSupport imports at XCTestCompat;
+  - repeats `macOS UI Tests CI` scheme pre-actions (clean-app review, suppress
+    Move-to-Applications, start tests-server);
+  - `xcodebuild test-without-building` with `UITests.xctestrun` (FormatVersion 1),
+    then kills tests-server and the app (old XCTest doesn't terminate it).
+  - `--gui`: over SSH xcodebuild can't reach the runner; relaunches itself via a
+    Terminal `.command` in the console session, waits, closes finished windows.
+
+Build on the host (spell flags out — zsh doesn't word-split `$var`):
+
+```bash
+xcodebuild build-for-testing -workspace DuckDuckGo.xcworkspace -scheme "macOS UI Tests CI" -destination "platform=macOS,arch=x86_64" -derivedDataPath <dd> ONLY_ACTIVE_ARCH=YES -skipPackagePluginValidation -skipMacroValidation
+xcodebuild build -workspace DuckDuckGo.xcworkspace -scheme "macOS Browser" -configuration Review -destination "platform=macOS,arch=x86_64" -derivedDataPath <dd> ONLY_ACTIVE_ARCH=YES -skipPackagePluginValidation -skipMacroValidation
+```
+
+## Target Mac prerequisites (once per boot volume, needs sudo)
+
+```bash
+sudo DevToolsSecurity -enable
+sudo automationmodetool enable-automationmode-without-authentication
+```
+
+Without them testmanagerd shows an admin-password prompt on the display
+("Timed out while enabling automation mode"). Virfield's node probe now reports
+`ui_testing` (`ready` / `devtools_disabled` / `automation_mode_requires_auth` /
+`no_console_session`); setup script `/Users/admin/Developer/virfield/deploy/node-ui-testing.sh`.
+
+## Gotchas found
+
+- Repo `Logger` (`macOS/UITests/Common/UITests.swift`) calls private
+  `-[XCTContext _recordActivityMessageWithFormat:]`; old XCTest lacks it → guard
+  with `responds(to:)` (done on branch `alex/fix-save-credentials-tooltip-crash-macos12`).
+- Remote shell is zsh: `log` is a builtin — use `/usr/bin/log show`.
+- MBP has a different SSH host key per boot volume; use the Virfield lease's
+  generated `ssh-config` (pins the booted volume's key).
+- Hover tracking in the app uses `.activeInKeyWindow`; popovers that open without
+  focus don't get hover events.
+
+First used: 2026-10-12, reproducing Sentry crash
+`NSInternalInconsistencyException SaveCredentialsViewController.loadView`
+(`isfinite(newOrigin.x)` on macOS 12) — reproduced before fix on the MBP.
+See also [[virfield]].
@@ -1,174 +0,0 @@
---
-type: tech
-topic: print
-tags:
-  - print
-  - printer
-  - samsung
-  - cups
-  - macos
-created: 2026-08-26T00:00:00.000Z
-updated: '2026-09-02T00:00:00.000Z'
---
-
-# Печать и общие сервисы (Mac + сеть)
-
-Проверка службы печати 2026-08-26: «не видит принтер с телефона».
-
-## Состояние на момент проверки
-
-На Mac (admin, macOS 26.6.1, arm64) в системе зарегистрированы два принтера:
-
-| Принтер | Способ подключения | Статус |
-|---|---|---|
-| **Samsung CLX-216x** | Сетевой `ipp://192.168.2.197/printers/Samsung_CLX-216x_Series`, драйвер Generic PostScript | не pингуется в текущей сети |
-| **Samsung M2020 Series** (SEC84251974A6B3) | AirPrint `dnssd://…_ipp._tcp.local.`, дефолтный, PPD Samsung M2020 Series-AirPrint | не отвечает по сети |
-
-Системный дефолт: `Samsung_M2020_Series__SEC84251974A6B3_` (idle, enabled 2026-07-29).
-
-## Ключевые находки
-
- **CUPS слушает только локально**: в `/etc/cups/cupsd.conf` → `Listen localhost:631` + `Listen /private/var/run/cupsd`. Наружу (по сети, для AirPrint) служба печати НЕ отдаётся.
- **Шеринг печати выключен** (`SharePrinters` в cupsd.conf закомментирован/неактивен; в `system_profiler` оба принтера `Shared: No`, `System Printer Sharing: No`).
- **Порт 631 наружу закрыт**: `nc -z 192.168.2.197 631` → closed.
- Сеть Мака — `192.168.6.x` (адрес `192.168.6.173`, шлюз `192.168.6.1`). Принтер прописан в подсети `192.168.2.x`.
-
-## ⚠️ Важное наблюдение (пересечение с TrueNAS)
-
-Адрес **`192.168.2.197` — это TrueNAS** (truenas_admin, SSH через `mallexxx.duckdns.org`), НЕ сам принтер. Samsung CLX-216x физически подключён к TrueNAS (USB) и печатается через docker-контейнер **cups-splix** (драйвер splix). Запись `ipp://192.168.2.197/printers/Samsung_CLX-216x_Series` в системе Мака — результат обнаружения расшаренной печати TrueNAS на этом адресе.
-
-## ✅ НаСТОЯЩИЙ ДИАГНОЗ (2026-08-26, подтверждено SSH на TrueNAS)
-
-**Корень проблемы: cups-splix контейнер НЕ запущен на TrueNAS.**
- На TrueNAS **нет ни одной работающей службы печати**: `lpstat`/`cupsd` в системе не установлены, порт 631 закрыт (и локально, и снаружи).
- Ни одного docker-контейнера по печати в `docker ps` нет (cup/sprint/ipp — пусто). **Официальный список контейнеров** (docker ps -a): immich(redis/server/postgres), modbus-bridge, mbusd, zigbee2mqtt, webdav, vless-proxy, hermes-taiga, portainer(-mcp), homeassistant, caddy, watchtower, transmission, syncthing, ser2net, rclone, nodered, mosquitto, library, inpxer, inpx-web, gitea, filebrowser. **`cups-splix` отсутствует.**
- Образ `cups-splix` не собран (`docker images | grep cups|splix` → пусто).
-
-### Конфиг cups-splix (цел, на месте)
-
-Папка `/mnt/RED_2TB/docker/cups/`: `Dockerfile`, `docker-compose.yml`, `docker build.txt`, `data/`, `cache/`, `spool/`, `uld/`.
-
-**docker-compose.yml:**
-```yaml
-services:
-  cups-splix:
-    image: cups-splix
-    container_name: cups-splix
-    command: ["/usr/sbin/cupsd", "-f"]
-    network_mode: host
-    privileged: true
-    volumes:
-      - /dev/bus/usb:/dev/bus/usb
-      - /mnt/RED_2TB/docker/cups/data:/etc/cups
-      - /mnt/RED_2TB/docker/cups/cache:/var/cache/cups
-      - /mnt/RED_2TB/docker/cups/spool:/var/spool/cups
-    restart: unless-stopped
-```
-
-**Dockerfile** (debian:12-slim): ставит `cups-daemon cups-client cups-common printer-driver-splix avahi-utils dbus usbutils nano`, пользователь `cupsadmin:admin` (в группе lpadmin), `EXPOSE 631`, CMD `cupsd -f`.
-
-**Как поднять** (из доки, раздел «Сборка»):
-```
-cd /mnt/RED_2TB/docker/cups/
-docker build -t cups-splix .
-docker compose up -d   # или docker run из build.txt
-# проверить: порт 631 открылся, принтер подцепился
-```
-
-### Почему выпал
-`.ix-apps` вызов docker data-root при пересоздании пула НЕ переносился → образы (=кеш) потеряны, перекачиваются заново. `cups-splix` — локальная сборка, она не «перекачается», нужно пересобрать. Конфиги целы.
-
-## ✅ РЕЗОЛЮЦИЯ (2026-08-26, выполнено)
-
-**cups-splix поднят, печать восстановлена.** Шаги, фактически выполненные на TrueNAS:
-
-```bash
-cd /mnt/RED_2TB/docker/cups
-docker build -t cups-splix .          # образ собран успешно (~225s), splix установлен
-docker compose up -d                  # контейнер запущен
-docker exec cups-splix lpstat -p -d   # printer Samsung_CLX-216x_Series ... idle, enabled
-docker exec cups-splix lpstat -a      # ... accepting requests
-nc -z 192.168.2.197 631               # 631 OPEN снаружи
-```
-
- **Принтер подключён по USB к TrueNAS**: `usb://Samsung/CLX-216x%20Series?serial=9566BAGQ213134Z.&interface=1` (Bus 002 Device 008, `04e8:3425` Samsung CLX-216x).
- CUPS-конфиг сохранился в `/mnt/RED_2TB/docker/cups/data` (это `/etc/cups`) → принтер прописан и подцепился после рестарта сам.
- Образ собрался без ошибок → **раньше его просто не запускали собирать** (не поломка Dockerfile), а потеряли при восстановлении стека вместе с `.ix-apps`.
- Порт 631 открыт наружу → печать доступна по сети на `192.168.2.197:631`.
-
-**Условие для телефона:** телефон должен быть в сети `192.168.2.x` (той же, что и TrueNAS), чтобы увидеть принтер. Если телефон в другой подсети (напр. `192.168.6.x`) — это сетевой вопрос, не печатный.
-
-Полный рецепт на будущее продублирован в `truenas-infrastructure.md` → раздел «Печать / cups-splix».
-
-## ✅ Печать PDF извне сети TrueNAS (когда клиент НЕ в подсети, `mallexxx.duckdns.org:631` закрыт)
-
-Когда принтер физически в TrueNAS, а клиент НЕ в подсети `192.168.2.x` → прямой IPP до `:631` закрыт. Печатать через SSH `mallexxx.duckdns.org` в контейнер `cups-splix` (проверено 2026-09-02):
-
-```bash
-# 1. Залить PDF на TrueNAS
-scp -i ~/.ssh/id_rsa file.pdf truenas_admin@mallexxx.duckdns.org:/tmp/evrika_print.pdf
-# 2. Скопировать внутрь контейнера
-ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
-  'docker cp /tmp/evrika_print.pdf cups-splix:/tmp/evrika_print.pdf'
-# 3. Отправить в очередь (CUPS сам конвертит PDF→vnd.cups-postscript→pstoqpdl; gs+pdftops в контейнере есть)
-ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
-  'docker exec cups-splix lp -d Samsung_CLX-216x_Series -o media=A4 /tmp/evrika_print.pdf'
-```
-
-**Проверка успеха:** `lpstat -W completed | grep "<reqid>"` (искомый job появляется строкой `Samsung_CLX-216x_Series-<N> <user> <bytes> ... <дата>`), очередь пуста (`lpstat -o`), принтер `idle … Rendering completed`. access_log контейнера: `Create-Job successful-ok` + `Send-Document successful-ok`.
-
-**Важно:** `lp -d <printer> file.pdf` сам создаёт job (`Create-Job`) — НЕ комбинировать с отдельным print-job-id, иначе `client-error-not-found`. PPD CLX-216x принимает `application/vnd.cups-postscript` (`*cupsFilter: 0 pstoqpdl`), поэтому чистый PDF конвертится автоматически. Job в `lpstat -W completed` показывает владельцем `root` (выполняется через docker по SSH) — это нормально.
-
-Полный шаги: залить → `docker cp` → `docker exec cups-splix lp` → проверить `completed` → убрать временные файлы (`/tmp/...` на хосте и внутри контейнера).
-
-## ⚠️ ТОПОЛОГИЯ ИЗМЕНЕНА (2026-08-31) — TrueNAS больше НЕ в локальной сети
-
-TrueNAS ушла из локальной сети и доступна **только** через публичный DNS `mallexxx.duckdns.org` (внешка `90.189.160.148`). Локальный `192.168.2.197` физически **недостижим** (пинг 100% потеря) — TrueNAS не в `192.168.2.x` и не в сети телефона.
-
-**Подтверждено SSH на TrueNAS (2026-08-31):**
- `cups-splix` **Up** (4 days), принтер `Samsung_CLX-216x_Series` **idle / enabled / accepting requests**.
- Принтер подключён по USB: `usb://Samsung/CLX-216x%20Series?serial=9566BAGQ213134Z.&interface=1`.
- CUPS слушает **`0.0.0.0:631`** (все интерфейсы, `network_mode: host`).
- CUPS config: `Port 631`, `WebInterface Yes`, `ServerAlias *` (раздел `cupsd.conf`).
- **Снаружи `mallexxx.duckdns.org:631` — CLOSED** (наружу не проброшен).
-
-**Реальная картина печати:**
- **Samsung Mobile Print (app)** — печатает. У приложения адрес вписан вручную/закэширован (не обязательно `192.168.2.197`).
- **Штатная Android print service** — добавлял вручную `ipp://192.168.2.197:631/printers/Samsung_CLX-216x_Series` → **«недоступен»**. Ожидаемо: TrueNAS ушла из локальной сети, а адрес `192.168.2.197` из телефона недостижим.
-
-**Вывод:** «недоступен» в штатной службе — НЕ баг настройки и НЕ проблема порта. Это прямое следствие того, что CUPS-хост (TrueNAS) физически вне сети телефона: локального пути нет, а публичный `mallexxx.duckdns.org:631` закрыт. Android-штатная служба не умеет удалённый IPP через интернет без открытого наружу порта.
-
-**ОТКРЫТЫЙ ВОПРОС** (не разобран, нет доступа к настройкам приложения): по какому именно адресу Samsung Mobile Print реально шлёт печать, раз 631 снаружи закрыт. Гипотезы: (1) приложение кэширует соединение с времён, когда TrueNAS была локально; (2) используется другой публичный путь (реверс-прокси Caddy на ином порту/HTTPS), не записанный в доках. Для полного разбора нужен адрес/хост из настроек принтера внутри Samsung Mobile Print. Отмечено: **лог CUPS access_log показывает, что практически вся печать шла с IP `192.168.2.141`** (26-30 авг, POST /printers/... Print-Job → 200 successful-ok) — т.е. Samsung Mobile Print ходил по локальному IP, когда TrueNAS ещё была в сети. Похоже, приложение реально кэшировало локальное соединение.
-
-## ✅ НАСТОЯЩИЙ МЕХАНИЗМ «недоступен» в Android print service (2026-08-31, подтверждено ipptool)
-
-Дополнительная проверка **внутри контейнера** (`ipptool -tv` → CUPS) дала ключевой факт:
-
- **`printer-dns-sd-name = no-value`**
- В контейнере cups-splix **НЕ запущен `avahi-daemon`** (процессы: только `cupsd`; `ps aux | grep avahi` — пусто). Пакеты `dbus` + `avahi-utils` в образе есть, но **`avahi-daemon` не установлен и не стартует**, а CMD — только `cupsd -f`.
-
-**Механика:** Samsung Mobile Print — вендорское приложение, ходит на CUPS **напрямую по IPP** (POST Print-Job по IP) → работает даже без mDNS. **Android штатная служба печати** (Mopria/Default) даже при ручном добавлении по IP затем делает **mDNS/AirPrint-проверку** принтера (`_ipp._tcp` / `_ipps._tcp.local`), чтобы получить `printer-uuid` и capabilities. Если mDNS-анонса нет (`printer-dns-sd-name = no-value`, avahi не запущен) — Android помечает принтер **«недоступен»**, даже если IPP по-IP физически отвечает. Полный ответ CUPS на Get-Printer-Attributes — `successful-ok [PASS]`, принтер idle/accepting/shared — подтверждает: CUPS здоров, всё дело в отсутствии mDNS-анонса.
-
-## ✅ РЕЗУЛЬТАТ (2026-08-31, выполнен полностью): mDNS поднят через avahi-daemon
-
-**Место:** папка `/mnt/RED_2TB/docker/cups/`.
-
-**Выполнено и проверено (все шаги):**
- ✅ **Бэкап** конфига: `/mnt/RED_2TB/docker/cups/backup_20260831-003619.tar.gz` (создан внутри контейнера `tar` → `docker cp`; md5 `0e303a6a57ae767d1e14cd72c8039fe4`). Внутри: `/etc/cups`, `/var/spool/cups`, `/var/cache/cups`. Дубль в `/tmp/cups_backup_<ts>.tar.gz` на хосте.
- ✅ **Новый `Dockerfile`** (в cups/, заменил старый): в apt добавлен **`avahi-daemon`** + `procps`; добавлен `COPY entrypoint.sh /entrypoint.sh`; `ENTRYPOINT ["/entrypoint.sh"]` вместо `CMD ["cupsd","-f"]`.
- ✅ **`entrypoint.sh`** (в cups/): стартует `dbus-daemon --system --fork`, затем `avahi-daemon --no-drop-root --syslog` в фоне, затем `exec cupsd -f`.
- ✅ **`cupsd.conf`**: `Browsing Off` → `Browsing On` + `BrowseLocalProtocols dnssd` (бэкап `cupsd.conf.pre-avahi`). Валидность: `/usr/sbin/cupsd -t` → OK.
- ✅ **Образ**: собрал `cups-splix-new`, затем пометил **старый образ как `cups-splix-old`** (откат), а новый — как `cups-splix`.
- ✅ **Контейнер пересоздан**: `docker stop cups-splix && docker rm cups-splix && docker compose up -d`.
-
-**Проверка mDNS (всё сошлось):**
- `ps aux`: запущены `cupsd` (PID1), `dbus-daemon --system`, `avahi-daemon: running [truenas.local]`.
- `ipptool` Get-Printer-Attributes: `printer-dns-sd-name` больше не `no-value` → теперь анонс зарегистрирован.
- `avahi-browse -rt -p _ipp._tcp`: на физическом интерфейсе **`;enp3s0;IPv4;`** по адресу **`192.168.2.197;631`** с TXT **`mopria-certified=1.3`**, `pdl=application/pdf,...`, `rp=printers/Samsung_CLX-216x_Series`, `UUID=68e3b8c6-...`.
- CUPS по-прежнему слушает `0.0.0.0:631`, принтер `idle/enabled/accepting`.
-
-**Pitfall (важно):** НЕ использовать **`docker restart cups-splix`** после правки конфига — он убивает avahi-daemon (становится `<defunct>`), dbus тоже пропадает. Подъём ТОЛЬКО полным пересозданием: **`docker stop cups-splix && docker rm cups-splix && docker compose up -d`**, чтобы `entrypoint.sh` выполнился с нуля.
-
-**Pitfall (compose):** `docker-compose.yml` в cups/ — `-rw------- root:root` (600), **truenas_admin перезаписать не может** (Permission denied) → compose НЕ менял. Это ок: ENTRYPOINT переопределяет `command`, лишний cupsd не стартует (скрипт сам делает `exec cupsd -f`, аргументы `$@` игнорирует). Если потребуется убрать `command` из compose — править через root/UI.
-
-**Pitfall (бэкап):** `data/ cache/ spool/` под TrueNAS — `drwx------ root:lp` (0700), truenas_admin их напрямую не читает → **бэкап делать ТОЛЬКО через контейнер** (`docker exec ... tar` → `docker cp`), либо через /admin (root).
@@ -0,0 +1,58 @@
+---
+type: tech
+topic: print
+tags: [print, printer, samsung, cups, truenas, novosibirsk]
+updated: "2026-10-09"
+---
+
+# Samsung CLX-216x — Новосибирск
+
+## Подключение и сервисы
+
+- Принтер подключён по USB к TrueNAS в Новосибирске:
+  `usb://Samsung/CLX-216x%20Series?serial=9566BAGQ213134Z.&interface=1`.
+- `192.168.2.197` — адрес TrueNAS, не принтера.
+- Контейнер `cups-splix` обслуживает очередь `Samsung_CLX-216x_Series` через CUPS и драйвер splix.
+- В контейнере работают `cupsd`, `dbus-daemon`, `avahi-daemon`; Avahi публикует `_ipp._tcp` / mDNS для Android.
+
+## История проблем и решений
+
+1. После пересоздания пула исчез локально собранный образ `cups-splix`; контейнер не работал, CUPS на `:631` не было, принтер оказался недоступен.
+2. Образ пересобрали из `/mnt/RED_2TB/docker/cups/`, контейнер подняли. USB-очередь восстановилась из сохранённого CUPS-конфига.
+3. Штатная Android-служба считала доступную по IPP очередь недоступной: не было mDNS-анонса.
+4. В контейнер добавили `avahi-daemon` и `dbus-daemon`, включили CUPS browsing. После этого Android обнаруживает принтер.
+
+## Эксплуатация
+
+- Конфигурация: `/mnt/RED_2TB/docker/cups/` на TrueNAS.
+- После изменения конфигурации поднимать полным пересозданием:
+
+```bash
+docker stop cups-splix
+docker rm cups-splix
+docker compose up -d
+```
+
+- Не использовать `docker restart cups-splix`: Avahi после него становится zombie, mDNS пропадает.
+- Из внешней сети печать идёт через SSH в контейнер; порт `631` наружу не опубликован.
+
+## Печать PDF извне
+
+Загрузить PDF на TrueNAS, скопировать в контейнер и поставить в очередь:
+
+```bash
+scp -i ~/.ssh/id_rsa file.pdf truenas_admin@mallexxx.duckdns.org:/tmp/evrika_print.pdf
+ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
+  'docker cp /tmp/evrika_print.pdf cups-splix:/tmp/evrika_print.pdf'
+ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
+  'docker exec cups-splix lp -d Samsung_CLX-216x_Series -o media=A4 /tmp/evrika_print.pdf'
+```
+
+Проверка: `lpstat -W completed` внутри контейнера. CUPS сам конвертирует PDF для splix. После печати удалить временные файлы в `/tmp` на TrueNAS и в контейнере.
+
+## Контейнер и сохранность конфигурации
+
+- `docker-compose.yml` использует `network_mode: host`, USB `/dev/bus/usb`, а `/etc/cups`, кэш и spool хранятся в `/mnt/RED_2TB/docker/cups/{data,cache,spool}`.
+- Образ основан на Debian 12; в нём CUPS, splix, Avahi, D-Bus и USB-утилиты. Точка входа запускает D-Bus, затем Avahi, затем `cupsd`.
+- Каталоги `data`, `cache`, `spool` принадлежат `root:lp` и имеют права `0700`. Бэкап делать внутри контейнера через `docker exec … tar`, затем забирать `docker cp`.
+- Локально собранный образ не переживает потерю docker data-root; конфигурация и USB-очередь сохраняются в `/mnt/RED_2TB/docker/cups/`, образ нужно пересобрать.