handoff-to-jarvis

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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`, и
выдуманный путь лога даст вахтёра, который месяцами стережёт пустоту.

```bash
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 из `personal/Knowledge/autonomous-experiment-loop.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`, порог сдвига — из разброса значений в прошлых
прогонах. Спрашивать «а какой порог?» без вариантов бесполезно, пользователь этого не помнит.

| Спросить | Куда уйдёт | Не спрашивать, если |
|---|---|---|
| до какого `iter` считаем и что считается успехом | `ЦЕЛЬ`, `runs[].target_iter` | значение однозначно в команде запуска или конфиге |
| какие конфиги можно запускать следующими и какими именно командами | `queue` (поимённо, `cmd` дословно) | пользователь прямо сказал «только наблюдать» |
| порог значимого сдвига метрики | `thresholds.shift_val_delta` | он сказал «пиши только финалы и падения» |
| что делать нельзя | `forbidden` | — всегда предлагай минимум и дай дополнить |
| когда будить, а когда молчать | `ЭСКАЛАЦИЯ` | он уже перечислил, о чём писать |

**Если он не отвечает или говорит «решай сам»** — не выдумывай очередь и не расширяй права. Ставь
безопасные дефолты: пустая `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), это уже в конфиге.

```bash
ID=hf-20260803-1612-warmup-583m
INBOX=/root/jarvis4shkodnik/state/inbox

From Vepricov/claude-brainlab, MIT.

More from Vepricov/claude-brainlab