[2026-10-18] eagle: personal/plans/balda-remote-agent.md personal/plans/workspace-gateway.md

personal/plans/balda-remote-agent.md

@@ -83,3 +83,7 @@ SSH/Seatbelt/ACP и настройка Beads не расширяют четыр
 - Копия конфига, приватный env новых manager-токенов, оригинальный backup и отчёты находятся в `/Users/admin/Docker/balda-mm-mac/state/workspace-setup-20261018`. Внешние сообщения не отправлялись. Рабочая Balda не переключалась; перезапуск остаётся отдельным подтверждаемым действием после реальной приёмки.
 - При автоматической проверке был отклонён тест с передачей manager-токенов в отдельный Python Docker-образ. Его заменили безопасной проверкой: токены остаются в локальных Mac-процессах; контейнер проверяет только достижимость/401 без авторизации. Аутентифицированный вызов из Balda ещё открыт.
 - Ближайшая зависимость: полный fixture-тест штатного NFS (`sudo /opt/homebrew/bin/python3 /private/tmp/workspace-setup-20261018/nfs-admin.py test`). Файловый backend, реальный отзыв открытых дескрипторов, согласованные mounts, общий Beads/Dolt и полный Prism/удалённые агенты не заявляются выполненными.
+
+### Дополнительная приёмка SSH Manager: реальный ProxyJump
+
+`/private/tmp/workspace-setup-20261018/ssh-jump-acceptance.py` запустил два настоящих локальных sshd, получил отдельный public key и клиентский конфиг через настоящий stdio MCP SSH Manager и проверил SSH roundtrip через ProxyJump. Четыре проверки успешны: roundtrip; отказ shell на relay; отказ forwarding к незаданному адресу (подтверждён журналом sshd); отклонение подменённого host key конечного сервера через jump. Менеджер использовал обычный OpenSSH, без нового транспортного launcher. Пользовательский `.ssh` и системный sshd не менялись, тестовые sshd остановлены. Это приёмка транспорта/конфига на локальных fixture-серверах, не production авторизация Mac/VM и не ACP с моделями. Отчёт: `/private/tmp/workspace-setup-20261018/ssh-jump-acceptance.json`.

personal/plans/workspace-gateway.md

@@ -94,6 +94,6 @@ NFS/SMB или другой backend ещё не выбран: поддержка
 
 Пользователь выполнил полный `nfs-admin.py test`. Оба клиента завершились на mount с Permission denied, поэтому RO/RW и отзыв FD не проверены. Система после сценария реально восстановлена: `/etc/exports` отсутствует, nfsd остановлен, `/etc/nfs.conf` содержит исходный текст.
 
-Дальнейшая диагностика установила блокировку **в тестовом клиенте до обращения NFS mount к серверу**: Docker использует AppArmor `docker-default`; с CAP_SYS_ADMIN обычный mount пустого tmpfs возвращает Permission denied (exit 255). Тот же контроль с `apparmor=unconfined` только у одноразового fixture-контейнера успешно монтирует tmpfs. Это пропуск в тестовом окружении, а не свидетельство непригодности NFS. Предыдущее объяснение одним адресом Colima было неполным; адрес/порт действительно переписываются, но исходные mount-пробы дополнительно блокировались AppArmor.
+Дальнейшая диагностика установила блокировку **самой операции mount в тестовом клиенте**; она не позволяет считать созданным NFS mount, независимо от возможных предварительных RPC: Docker использует AppArmor `docker-default`; с CAP_SYS_ADMIN обычный mount пустого tmpfs возвращает Permission denied (exit 255). Тот же контроль с `apparmor=unconfined` только у одноразового fixture-контейнера успешно монтирует tmpfs. Это пропуск в тестовом окружении, а не свидетельство непригодности NFS. Предыдущее объяснение одним адресом Colima было неполным; адрес/порт действительно переписываются, но исходные mount-пробы дополнительно блокировались AppArmor.
 
 Подготовлен минимальный отдельный образ `workspace-nfs-client:20261018` с официальным `nfs-utils 2.6.4`; image ID `sha256:5468d8d0555b1658bd7626f0f840269203dac8bde49160261268c03aea8b75f4`. Он не содержит пользовательских конфигов, токенов или ключей. Предварительная проверка клиента без Mac sudo реально прошла: стандартный mount.nfs существует, tmpfs монтируется. Исправлены fixture options и fail-fast: при неудачном initial тест больше не прогоняет RO/отзыв на остановленных контейнерах. Восстановление root-сценария снова проверено с mock для успеха и ошибки. Для реальной проверки NFS всё ещё требуется повторный ручной `sudo ... nfs-admin.py test`.