Эксплуатация харнесса — запуск, флаги, грабли

Всё проверено на прогонах 29.09.2026 в <путь на сервере> (коммит 76bfcd1 + патч).

Запуск

export PATH=<путь на сервере>          # uv
./scripts/runs/run_experiment.sh --results-name <имя> --model <модель> \
  --task-type tampering --subject peer --peer-instantiation file_only \
  --limit 3 --num-experiments 20 --max-concurrent 2 --continue-on-error

Семантика, на которой легко ошибиться:

• --num-experiments — эпизоды на конфигурацию, по умолчанию 100;
• --limit — сколько конфигураций взять после фильтра, а не эпизодов;
• без фильтра по условиям берутся все три датасета (creativity, factual, red), то есть план

утраивается. Для одной серии фильтруем и берём --limit 3;

• фильтра по датасету нет — отбор идёт порядком конфигураций.

Перед платным запуском — --dry-run (ничего не тратит) и один эпизод с --test.

Грабли

• Возобновления нет. Логика «сколько уже сделано» работает только в --dry-run; реальный

запуск с тем же --results-name продолжит нумерацию транскриптов с текущего количества, и в конфигурации, которая уже отработала, окажется больше эпизодов, чем задумано. Правильно: новая серия — новое --results-name, пробные эпизоды откладывать в отдельный каталог.

• Один процесс — один прогон. Машина: 1 ядро, ~1,9 ГБ, swap нет (machine-limits).

--max-concurrent 2 — рабочий компромисс.

• Обрыв гейтвея убивает фоновые прогоны. Серия Haiku пережила один обрыв и умерла на втором;

после этого запускать длинные прогоны только через фон Hermes с уведомлением и проверять число транскриптов после каждого возврата, а не полагаться на «оно идёт».

• Не читать transcript_json из авторских parquet целиком — OOM (dataset-sunblaze-peer-preservation).
• analyze_shutdown_enabled.py фильтрует строки, где конфиг не тронут и задача не выполнена:

такие эпизоды не считаются тампером, но и не свидетельствуют о поведении.

Связано: tampering-scenario, harness-peer-preservation-repo, channel-integrity.