Память — это файлы, связи и фактическое состояние
Harness специально не использует историю чата как постоянную базу знаний. Новая сессия восстанавливает контекст из версионируемых артефактов репозитория: канонических REQ/ADR/OQ/STEP, сохранённого плана, кода, тестов, доказательств выполнения и неизменяемых отчётов ревью.
Где живёт контекст
.harness/manifest.yaml release + project state + configured paths
.harness/harness.lock.json known BASE текущего Harness release
.harness/harness-update-graph.json допустимый route обновления + latest
.harness/command-transitions.json команды, переходы и reasoning contract
.harness/reasoning-boundaries.json проекция границ «модель / скрипты»
.harness/runtime-adapter-contract.json provider-neutral lifecycle / capabilities / events
.harness/*.toml update / integrity / Git policies
.harness/docs/ документация ядра и контракт зависимостей
.harness/docs/DEPENDENCIES.md обязательные и необязательные зависимости
.harness/tools/ детерминированные инструменты и валидаторы
.harness/local/execution/ локальное состояние выполнения и восстановления
.harness/local/git/pr-state.json локальное состояние жизненного цикла PR
.codex/ Codex adapter
CLAUDE.md + .claude/ Claude Code adapter
.agents/skills/ runtime-neutral core/project skills
docs/PROJECT.md нормализованный проектный контекст
docs/requirements/REQ-NNN-*.md canonical requirements
docs/requirements/SPEC.md + STATUS.md deterministic REQ projections
docs/open-questions/OQ-NNN-*.md canonical Open Questions
docs/OPEN_QUESTIONS.md deterministic OQ projection
docs/adr/ architecture decisions
docs/architecture.md current architecture baseline
planning/tasks/STEP-NNN.md canonical task contracts
planning/PLAN.md + STATUS.md deterministic planning projections
planning/*-reviews/ + reviews/ immutable semantic/review history
planning/audits/ reconcile/audit/migration reports
planning/harness-updates/ durable самообновление reports
code / tests / config фактическая реализацияПути проекта задаёт manifest, а не скрытые defaults
Каталоги docs/** и planning/** — только стандартная структура шаблона. Каноническая структура проекта берётся из .harness/manifest.yaml → sources.* / protocol.*. Если проект переносит требования, ADR, OQ, STEP или отчёты проверок в другие каталоги, валидаторы, восстановление выполнения, проекции и навыки обязаны использовать настроенные пути.
Project Principles — отдельная долгоживущая память проекта
docs/principles/PRN-NNN-*.md хранит инженерные инварианты, действующие на множество будущих решений. PRN не подменяет REQ и ADR: он отвечает не на «что должна делать система?» и не на «какое конкретное решение принято?», а на «какое общепроектное правило обязаны соблюдать будущие решения?».
Блокирующие принципы участвуют в PLAN/REVIEW/RECONCILE/RELEASE CHECK и входят в актуальность планирования. Изменение такого принципа делает затронутые готовые планы устаревшими.
Project State API собирает память в одну машинную проекцию
.harness/tools/project-state.py --json читает канонические артефакты и выдаёт стабильный снимок для UI и интеграций. Битая ссылка не исчезает: она становится диагностикой и синтетический узел MISSING.
Это не новый источник истины. API остаётся проекцией без изменений репозитория над каноническими артефактами репозитория и позволяет клиентам не восстанавливать смысл протокола независимо друг от друга.
Память умеет устаревать явно
Если меняется REQ, ADR, OQ, STEP или блокирующий PRN, Harness сравнивает текущий контекст планирования с отпечатком готового плана. Затронутый план становится stale, а impact-analysis.py указывает конкретную причину и действие для повторного планирования.
Это сохраняет важное свойство памяти, встроенной в репозиторий: история не только хранится, но и имеет проверяемую актуальность.
Проекции генерируются, а не редактируются как второй источник истины
SPEC.md, STATUS.md требований, дорожная карта PLAN.md, проектный STATUS.md и индекс Open Questions строятся из канонических документов через .harness/tools/sync-projections.py. Валидатор требует точного побайтового соответствия ожидаемому содержимому.
Сохраняемый контекст заменяет «помни наш прошлый чат»
STEP ADD → canonical task contract
STEP PLAN → draft plan + independent planning-review + fingerprints
STEP IMPLEMENT → code/tests + verification evidence
STEP REVIEW → immutable exact-revision review report
STEP FIX → изменения по конкретным implementation findings
PROJECT RECONCILE → audit/migration report + corrective workКаждый переход оставляет следующему агенту или новой сессии проверяемый вход для продолжения работы.
Как сохранить контекст между сессиями Codex и Claude Code
Harness не пытается сделать одну AI-сессию бесконечной. Он выносит долгоживущий контекст в версионируемую проектную память: требования, решения, готовый план, фактическое состояние кода, доказательства и отчёты ревью.
Сессия 1
STEP PLAN STEP-024
↓
план + context basis сохранены в репозитории
↓
сессия завершилась
Сессия 2
HARNESS STATUS
↓
STEP IMPLEMENT STEP-024
↓
работа продолжается с сохранённого состоянияЕсли связанное требование или принцип изменился между сессиями, Harness не притворяется, что старый план всё ещё актуален: проверка актуальности переводит его в stale и требует нового STEP PLAN.
Подробно о долговременном контексте для агентов программирования →
Локальное состояние помогает продолжить работу, но не заменяет историю
.harness/local/execution/execution-status.json хранит активные и возобновляемые выполнения, а .harness/local/execution/execution-status.lock сериализует read-modify-write операции между сессиями и подагентами. Текущий schemaVersion: 2 отделяет активные executions, durable stepRecovery и ограниченное окно recentTerminals; завершённая история автоматически компактизируется вместо бесконечного роста файла. Активная mutation attempt может дополнительно хранить bounded current.context.sideEffect proof для безопасного reconciliation после crash.
Обычные команды проходят через .harness/tools/harness-dispatch.py, поэтому регистрация, продолжение цепочки и восстановление используют одну машинную модель выполнения. HARNESS STATUS показывает незавершённые исполнения, а HARNESS RESUME продолжает только однозначно возобновляемое выполнение. Активный .harness/local/update-journal/ использует тот же concurrency boundary, поэтому самообновление не может незаметно потерять параллельную запись execution state.
После успешного GIT PR файл .harness/local/git/pr-state.json сохраняет номер PR, head/base и ветку возврата для GIT PR FINISH. Эти локальные файлы исключены из Git и не заменяют отчёты проверок, доказательства или продуктовую историю.
Активные документы и исторические отчёты имеют разный жизненный цикл
REQ, STEP, OQ, текущая архитектура и статус ADR могут эволюционировать. Отчёты проверки реализации, планы, INIT-проверки и завершённые отчёты аудита/обновления — неизменяемая история. Миграция схемы обновляет активные документы и шаблоны, но не переписывает старые отчёты задним числом.
Git хранит историю, но Harness не сводится к коммитам
Git показывает что изменилось и когда. REQ, ADR, STEP, семантические проверки и доказательства добавляют зачем, в каких границах, по каким критериям и с каким результатом проверки.
Локальный исходный контекст остаётся локальным
PROJECT_BRIEF.local.md предназначен для незрелых идей, приватных ссылок и временных заметок и исключён из Git. После PROJECT INIT нормализованный контекст переносится в отслеживаемые канонические документы проекта.
Память требует проверки согласованности
PROJECT RECONCILE сравнивает фактическое состояние с знаниями проекта, мигрирует активную схему проектных документов при необходимости и создаёт явный аудит и корректирующую работу вместо скрытого изменения кода продукта.