Проблема не в размере одного промпта
Длинный проект постепенно накапливает контекст, который нельзя надёжно передать одной вводной фразой: требования, архитектурные решения, причины ограничений, готовые планы, уже выполненные проверки и состояние незавершённой работы. Чем больше этого контекста остаётся только в истории чата, тем дороже становится новая сессия и тем выше риск, что она восстановит проект иначе.
Harness решает другую задачу: не увеличивает «память чата», а переносит долговременную память в репозиторий проекта.
Проектная память вместо памяти чата
Каноническая память проекта складывается из разных типов артефактов. docs/PROJECT.md описывает проект, REQ — обязательный результат, ADR — принятое решение, PRN — долгоживущий инженерный принцип, OQ — существенную неизвестность, STEP — конкретную работу. Код и тесты показывают фактическую реализацию, доказательства — результат проверки, отчёт ревью — независимую оценку.
Эти файлы хранятся под контролем версий. Следующая сессия читает то же состояние, которое видел предыдущий агент, вместо пересказа «мы вчера решили…».
Как выглядит передача между двумя сессиями
Сессия 1
STEP PLAN STEP-024
↓
Ready plan + context basis
сохранены в STEP
↓
сессия закончилась
Сессия 2
HARNESS STATUS
↓
STEP IMPLEMENT STEP-024
↓
Verification → STEP REVIEW
↓
completion proofПлан не остаётся только ответом модели. Он записывается в STEP и связывается с точным context_basis и содержимым плана. Поэтому реализатор в новой сессии может продолжить не «с того места, которое вроде бы помнит чат», а с сохранённого контракта задачи.
Сохранённый контекст должен уметь устаревать
Просто хранить старый план недостаточно. Если после планирования изменился связанный REQ, ADR, OQ, сам STEP или блокирующий PRN, прежний план может больше не соответствовать проекту.
Harness пересчитывает planning context и помечает затронутый Ready plan как stale. impact-analysis.py объясняет причину, а IMPLEMENT/RUN останавливается до повторного STEP PLAN. Несвязанные задачи не блокируются автоматически.
Смена сессии и аварийное прерывание — не одно и то же
Для обычной новой сессии достаточно канонических артефактов репозитория. Для прерванного выполнения Harness дополнительно использует локальное состояние .harness/local/execution/execution-status.json. Оно фиксирует текущую execution и bounded recovery proof.
HARNESS STATUS показывает незавершённую работу. HARNESS RESUME продолжает её только если восстановление однозначно безопасно. Для side effects вроде COMMIT/PUSH/PR сначала проверяется внешний факт: уже выполненная операция не должна повторяться, безопасный baseline допускает retry, неоднозначное состояние блокируется.
Почему это работает и для Codex, и для Claude Code
Codex и Claude Code имеют разные форматы адаптера, но не разные версии проектной истины. AGENTS.md, REQ/ADR/PRN/STEP, навыки, политика Git и проекции состояния общие. Поэтому смена поддерживаемой среды исполнения не требует переносить скрытую conversation history.
Context Contract дополнительно ограничивает объём чтения: планировщик, реализатор и проверяющий получают минимальный контекст конкретной задачи, а не весь репозиторий «на всякий случай».
Практические правила сохранения контекста
Решение — в канонический артефакт
Если ответ пользователя меняет требование или архитектуру, он должен попасть в REQ/ADR/OQ/STEP, а не остаться только сообщением в чате.
План — до реализации
Ready plan должен быть записан и проверен до IMPLEMENT, чтобы следующая сессия не импровизировала заново.
Доказательства — факт, а не пересказ
Команды проверки, exit codes и hashes дают следующей роли наблюдаемый результат вместо утверждения реализатора.
Состояние — не второй источник истины
Локальный execution state помогает recovery, но не заменяет Git-историю и канонические проектные документы.
С чего начать
Если проблема знакома, сначала посмотрите модель репозитория как памяти, затем инициализируйте тестовый проект и попробуйте оборвать сессию после STEP PLAN. Новая сессия должна продолжить работу из артефактов проекта, не требуя пересказа предыдущего чата.