handoff-to-jarvis: отдать прогоны круглосуточному агенту на do-vpn

Джарвис живёт на VPS do-vpn и говорит с пользователем в Telegram. Мак засыпает, VPS нет, поэтому долгие прогоны стережёт он. Канал передачи — файл JSON в /root/jarvis4shkodnik/state/inbox/, а не HTTP: на боксе 443/8443 заняты xray, а Мак→do-vpn рвётся с RST, и файл либо доезжает целиком, либо видно, что не доехал. Схема — единственный источник истины: ~/brainlab/agents/hermes/jarvis/inbox.py (TEMPLATE внизу — канонический пример, RunSpec — поля прогона, Handoff.validation_problems() — за что отклонят). Не изобретай имена полей, читай файл.

Главное: передача — это ЗАЯВЛЕНИЕ, а не факт. Джарвис сверит каждую строку с сервером и поднимет вахтёра только на то, что реально живо. Соврёшь — опубликует как «заявлено, но не найдено».

1. Когда применять и когда НЕ применять

Применять: прогоны запущены (тобой или пользователем), проверены, ноутбук закрывается; либо пользователь прямо сказал «передай Джарвису / поставь под мониторинг».

НЕ применять:

• Ничего ещё не запущено. Джарвис проверяет заявленное и отклонит непроверяемое: получишь rejected/ и сообщение о дырке вместо мониторинга.
• Ты сам добьёшь эту серию в этой же сессии. Два наблюдателя за одними логами дают два разных числа в Telegram и двойную запись в Experiments/.
• Серия уже передана — сначала проверь дубль (см. ЗАПРЕТЫ).

2. Собрать факты ДО записи файла, а не по памяти

Правило: в передачу идёт только то, что ты реально прочитал в этой сессии. Поле, которого не знаешь, лучше оставить пустым, чем заполнить догадкой: Джарвис строит по нему spec.md, и выдуманный путь лога даст вахтёра, который месяцами стережёт пустоту.

ssh vv_h200 "tmux ls"                                    # какие сессии реально есть
ssh vv_h200 "tmux capture-pane -t lip_f30:0 -p | tail -15"   # живая панель: Iter= или traceback
L=/data/users/shkodnik1917/llm-baselines-warmup/logs_583/lip_f30.txt
ssh vv_h200 "ls -l --time-style='+%d-%m %H:%M' $L; grep '>Eval: Iter=' $L | tail -2"
ssh vv_h200 "nvidia-smi --query-gpu=index,memory.used,memory.free,utilization.gpu --format=csv,noheader"

В руках на каждый прогон обязаны быть: имя tmux-сессии, абсолютный путь лога, mtime и размер лога (растёт ли), свежая строка >Eval: Iter=… val_loss=…, номер GPU, target_iter. Запускал сам — соблюди ordering из handbook/pipelines/long-runs.md (new-session -d → pipe-pane → send-keys; порядок не сворачивается, иначе pipe-pane проигрывает гонку первому выводу и лог пуст) и дождись 60–90 с, пока в панели появится Iter=: прогон, где видно только инициализацию оптимизатора, скорее всего уже застрял.

Хост — из general/servers.md, не из головы: vv_h200 достаётся через ProxyJump do-vpn и жив, пока жив vvh200-tunnel.service; на shkodnik_opt нужен CUDA_DEVICE_ORDER=PCI_BUS_ID, / всего 133 G, данные на /home; на brain_lab системный anaconda3/bin/python падает на import. Пути обязаны быть верны с точки зрения сервера, а не Мака: Джарвис ходит на GPU-хост со своего do-vpn.

2а. ОБЯЗАТЕЛЬНЫЙ ОПРОС: спросить то, что решает пользователь

Факты ты читаешь с сервера. Но пять полей — это не факты, а решения пользователя, и молчаливый дефолт по ним обходится дорого: пустая queue означает, что освободившийся ночью GPU простоит до утра, а отсутствие ЦЕЛЬ означает вахтёра, который не понимает, где финал, и не скажет о нём.

Поэтому: если пользователь не назвал их сам — спроси, ОДНИМ блоком, до записи файла. Не по одному вопросу за раз (это превращает передачу в допрос) и не после доставки (спек уже собран). Варианты ответов предлагай КОНКРЕТНЫЕ, выведенные из того, что ты только что прочитал: target_iter обычно виден в команде запуска или в конфиге, кандидаты в очередь — в той же папке scripts_*/ и в существующей заметке Experiments/<series>.md, порог сдвига — из разброса значений в прошлых прогонах. Спрашивать «а какой порог?» без вариантов бесполезно, пользователь этого не помнит.

Если он не отвечает или говорит «решай сам» — не выдумывай очередь и не расширяй права. Ставь безопасные дефолты: пустая queue (режим только-наблюдение), уведомления по финалам и авариям, operator_allowed ровно ["launch_from_queue"]. И напиши выбранные дефолты в comments дословно — тогда Джарвис назовёт их в докладе, и пользователь увидит, на чём вахтёр встал, из Telegram, а не из файлов на сервере.

Про очередь спрашивай особенно внятно, потому что это единственное, что отличает вахтёра-наблюдателя от вахтёра, продолжающего работу без пользователя. Формулировка вида «GPU освободится примерно через N часов, запускать ли следующий конфиг сам и какой» понятнее, чем «заполнить ли queue».

3. Собрать JSON по схеме inbox.py::TEMPLATE

Обязательный минимум, без него validation_problems() отклонит передачу машинно, ещё до похода на сервер: непустой project; непустой список runs; у каждого прогона заполнен tmux или log (RunSpec.identifiable) — иначе его нечем проверить. Плюс created_ts — текущее unix-время (date +%s): при age_sec > 24 ч передача протухла, прогоны суточной давности уже не те. version = 1.

• id: hf-YYYYMMDD-HHMM-<project>-<series> — по нему пользователь ищет передачу в Telegram и в processed/. watcher_name: короткое <project>-<series>, станет папкой state/watchers/<name>/.
• summary — одна строка, что запущено; comments — дословные пожелания пользователя, они уедут в ЦЕЛЬ и ЭСКАЛАЦИЯ спека вахтёра.
• checks: {"iter_grep": ">Eval: Iter=", "val_grep": "val_loss="} — те самые паттерны, которыми ты сам только что грепал; тик не должен изобретать парсинг заново.
• queue: только поимённо названные пользователем следующие конфиги с дословными cmd. Свободная GPU и очевидная польза разрешением на запуск не являются.
• thresholds: shift_val_delta и stall_ticks числами. Триггеры те же, что в autonomous-experiment-loop: final = iter >= target_iter плюс чистый выход в панели, crash = traceback / OOM / диск / оборванный туннель, stall = тот же iter два тика подряд при живом процессе, shift = |Δval| больше порога или обгон базлайна. Порог словами («заметно упало») делает каждый тик спором с самим собой.
• notes_paths: experiments, results, plot_cmd — куда писать и чем обновлять график. Этот список заодно определяет, что аудит считает записью «вне объявленного».
• operator_allowed: по умолчанию ровно ["launch_from_queue"]. Более широкие права через файл выдать нельзя — на них Джарвис всё равно потребует подтверждения в Telegram.
• forbidden: минимум «не убивать прогоны без подтверждения» и «не трогать чужие процессы на общих серверах», плюс всё, что сказал пользователь.

4. Доставка по ssh с ретраями

Файл писать локально в /tmp/<id>.json, ключи сверять с TEMPLATE глазами. Одиночная попытка доставки не годится: ТСПУ периодически отдаёт RST, и scp умеет молча не доехать. Host do-vpn в ~/.ssh/config слушает порт 2222 (22 режется egress-VPN), это уже в конфиге.

ID=hf-20260803-1612-warmup-583m
INBOX=/root/jarvis4shkodnik/state/inbox
for i in $(seq 1 8); do
  scp -o ConnectTimeout=10 "/tmp/$ID.json" "do-vpn:$INBOX/$ID.json.part" \
    && ssh -o ConnectTimeout=10 do-vpn "mv $INBOX/$ID.json.part $INBOX/$ID.json" \
    && break
  sleep 8
done
ssh do-vpn "ls -l $INBOX/"      # доставку ПРОВЕРИТЬ, молчаливый scp тут не редкость

Заливать через .json.part и переносить mv обязательно: Inbox.pending() глобит *.json каждые 15 с и подхватил бы недописанный файл, а битый JSON улетает в rejected/ навсегда. Файла нет в листинге после 8 попыток — не считай, что передал: скажи, что канал лежит, и предложи повторить.

5. Что происходит дальше

• ~15 с: детерминированное подтверждение в Telegram «Получено задание от локального агента: <id>» с проектом, хостом, сутью и списком заявленных прогонов.
• Потом сверка с сервером и отдельное сообщение: что реально живо (с числами и указанием их источника), что из заявленного не найдено, какого вахтёра он поднял или почему не поднял.
• Вахтёр встаёт на расписание только после подтверждения пользователя в Telegram. Ритм по умолчанию 30 мин, после трёх чистых тиков 60 мин, при любой проблеме назад на 30.

6. Что сказать пользователю локально

Одну короткую сводку: что передано (проект / серия / прогоны), что файл доставлен и виден в inbox/, и чего ждать в Telegram — сначала подтверждение, потом отчёт по сверке. Без обещаний за Джарвиса: не писать «всё под мониторингом» и не предсказывать результат сверки — не найдёт, скажет сам.

ЗАПРЕТЫ

• Не заполнять поля догадками. Факт, которого не читал (путь лога, имя сессии), — оставить пустым; решение пользователя (цель, очередь, пороги, запреты, эскалация) — СПРОСИТЬ по §2а. Выдуманное значение попадёт в spec.md и будет повторяться каждый тик.
• Не пропускать опрос §2а молча. Пустая queue без спроса = простаивающий ночью GPU, и пользователь узнает об этом утром. Не ответил — ставь дефолты И назови их в comments.
• Не расширять operator_allowed правом убивать прогоны, править код или запускать что-то вне queue без прямой просьбы пользователя.
• Не передавать серию дважды. Перед записью файла: ssh do-vpn 'ls /root/jarvis4shkodnik/state/inbox/ /root/jarvis4shkodnik/state/watchers/'. Есть вахтёр с таким watcher_name — не плоди второго, добавь прогоны через Telegram.
• Не класть в передачу секреты, токены, пароли, ключи — файл навсегда остаётся в processed/ и целиком уезжает в промпт модели.
• Не заявлять чужие прогоны (других $USER) на общем сервере.

Как проверить руками

ssh do-vpn 'ls -l /root/jarvis4shkodnik/state/inbox/' — доехало и ещё не обработано; ssh do-vpn 'ls -l /root/jarvis4shkodnik/state/inbox/{processed,rejected}/' — итог с приписанным *.result.txt. Пользователю в Telegram: /inbox — что в очереди передач и что с ней стало, /watch — список вахтёров, /watch <name> — конкретный вахтёр с находками.