Работа на другом компьютере

AI Development Harness · 29 октября 2026

Сценарий: вечером рабочий компьютер, утром ноутбук

На рабочем компьютере реализация ещё идёт, план проверен, часть команд уже выполнена. Хочется открыть ноутбук и сказать «продолжай». Простое копирование истории чата не отвечает на главные вопросы: какой код опубликован, какой контракт проверяли и остался ли на первой машине незавершённый процесс.

Harness разделяет версионируемые факты проекта и локальную историю выполнения. Git передаёт код, STEP, REQ, ADR и неизменяемые отчёты. Переносимый документ передачи связывает эти факты с конкретным коммитом. Он не утверждает, что ноутбук уже выполнил проверки рабочего компьютера.

Что переносится через Git

Факты проекта

Код и канонические документы, отпечатки контракта/плана, исходный коммит Git, ветка и объект STEP в индексе Git. Документ передачи хранится рядом с настроенным каталогом задач.

Локальные данные

execution-status.json, executionId, идентификаторы сессий, блокировки, журнал обновления и подтверждения проверок остаются в исходном клоне. Их копирование не доказывает завершение чужого процесса.

Компьютер A: код + STEP + проверенный план
                 ↓ сохранить через Git
Чистое дерево → документ передачи → отдельный коммит → отправка
                 ↓ явное получение изменений на компьютере B
Проверка HEAD коммита публикации + контракта + Ready-плана
                 ↓
Новый локальный STEP PLAN → новый независимый отчёт проверки плана
                 ↓
Обычный процесс и необходимые локальные проверки

Компьютер A: подготовка публикации

Сначала сохраните все изменения продукта штатным Git-процессом проекта. STEP должен оставаться in_progress, дерево — быть чистым. Затем создайте документ передачи:

python3 .harness/tools/portable-handoff.py --write --step STEP-017 --json

HANDOFF_WRITTEN_NOT_PUBLISHED означает только запись JSON. Изучите изменения и опубликуйте отдельным коммитом только документ передачи через GIT CHECK > COMMIT > PUSH. Например, при стандартном каталоге задач файл находится в planning/handoffs/STEP-017.json; в другом проекте путь определяется protocol.taskDirectory.

У коммита публикации ровно один родительский коммит: коммит, существовавший до записи документа передачи. Единственный изменённый путь — сам документ передачи. Смешанная публикация с новым кодом не доказывает исходный снимок.

Компьютер B: проверка перед продолжением

Переключитесь на опубликованную ветку и явно обновите ссылки Git. Harness не выполняет скрытый сетевой запрос ради проверки переносимости.

git fetch
git pull --ff-only
python3 .harness/tools/portable-handoff.py --check --step STEP-017 --json
python3 .harness/tools/harness-ux.py resume --json

HANDOFF_PROVEN_NOT_EXECUTION доказывает происхождение сохранённых фактов; это не PASS ревью и не выполнение STEP. Сам инструмент проверки возвращает safeToResume=false, nextCommand=null и не записывает состояние выполнения. Решение о запуске принимает диспетчер через HARNESS RESUME.

В совершенно новом клоне без локальной истории единственный актуальный документ передачи, Ready-план и совпадающий независимый отчёт проверки плана разрешают новый локальный STEP PLAN. Старый executionId не импортируется. Чтобы завершить новое планирование, нужны новая ревизия плана и новый независимый неизменяемый отчёт проверки плана; прежний отчёт этого не доказывает.

Когда перенос должен остановиться

Следующий после публикации коммит делает документ передачи устаревшим даже при неизменном STEP: нужен новый снимок. Изменение ветки, контракта, плана, грязное дерево, известное расхождение с отслеживаемой удалённой веткой, несколько подходящих STEP или отсутствующий отчёт ревью блокируют перенос. Без получения свежих удалённых изменений неизвестные удалённые изменения не видны.

Локальное продолжение всегда имеет приоритет. Переносимый вход не позволяет обойти потерю или повреждение контрольной записи старого клона. IMPLEMENT/REVIEW/FIX, COMMIT/PUSH/PR и UPDATE не повторяются автоматически. Документ передачи не является распределённой блокировкой: согласуйте работу двух машин, а перед приёмкой получите актуальную локальную проверку.

Где проверить правила

Переносимый документ передачи и двухклоновые ограничения · Локальное выполнение и восстановление. См. также структуру репозитория и процесс продолжения работы.