Вопросы и ответы

Нет. Это слой процесса на уровне репозитория: правила, агенты, навыки, политики, шаблоны и формальные проверки. Технологии самого приложения выбираются и появляются после PROJECT INIT и реальных STEP.

Codex и Claude Code. Они подключаются как отдельные адаптеры к одному протоколу Harness. AGENTS.md, команды, REQ/ADR/STEP, навыки, политика Git и политика обновления остаются общими. Подробнее — на странице «Codex и Claude Code».

Нет. Для работы достаточно одной поддерживаемой среды исполнения. Можно выбрать Codex или Claude Code в зависимости от текущей среды и при необходимости сменить среду исполнения позже, не перенося проектный процесс в другой формат.

Нет. PROJECT_BRIEF.local.md — исходное описание проекта. Инициализатор нормализует требования и создаёт ADR только там, где устойчивое решение действительно принято или необходимо до реализации.

Нет. Инициализация создаёт базу знаний проекта, базовую архитектуру, дорожную карту и контракты задач. Код продукта во время PROJECT INIT не создаётся.

Нет. Подтверждённая небольшая правка с низким риском может идти через PROJECT QUICK FIX или ручную правку → GIT CHECK > COMMIT. Изменение поведения, API, данных, безопасности, архитектуры или зависимостей требует STEP ADD.

Чтобы план был сохраняемым контекстом между этапами, а не памятью текущего чата. Одного сохранения недостаточно: STEP PLAN проходит независимую проверку плана, а готовый план связан с точными context_basis и plan_content_hash. Изменение связанных REQ/ADR/зависимостей делает старый план устаревшим.

Отчёт ревью — неизменяемый исторический артефакт. В актуальном Review Contract v3 FAIL содержит machine-readable findings со stable fingerprint и evidenceBasis, поэтому FIX может детерминированно понять, какие именно подтверждённые дефекты остались между циклами, а adaptive repair — сравнить два отчёта без chat history. Исправления не стирают факт исходной проверки.

Это одна из основных целей Harness: контекст восстанавливается из артефактов репозитория — PROJECT, REQ, ADR, STEP, сохранённого плана, кода и тестов, доказательств выполнения и отчётов ревью.

Через HARNESS UPDATE CHECK, затем HARNESS UPDATE APPLY. Детерминированный .harness/tools/harness-update.py проверяет точный текущий релиз, lock-файл, маршрут, правила владения, BASE/OURS/THEIRS и коллизии. Каждый переход APPLY выполняется как транзакция с .harness/local/update-journal/, валидатор постусловий и отчётом только после PASS. Агент объясняет результат и конфликты, но не реализует файловую транзакцию «по памяти». Коммит, отправка изменений и PR выполняются отдельно.

Незавершённый переход остаётся в .harness/local/update-journal/. HARNESS UPDATE CHECK сообщает UPDATE_JOURNAL_PENDING, а следующий HARNESS UPDATE APPLY сначала восстанавливает прерванную транзакцию и только затем повторяет update. Rollback восстанавливает управляемые файлы, permission bits, lock и journaled execution state; чужой или неоднозначно принадлежащий транзакции артефакт не удаляется.

.codex/config.toml, .codex/agents/*.toml, CLAUDE.md, .claude/settings.json и .claude/agents/*.md относятся к общим путям. Механизм обновления использует трёхстороннее слияние BASE/OURS/THEIRS и останавливается при конфликте вместо скрытой перезаписи проектных настроек.

Тогда требуется явное подключение старого проекта. Harness не угадывает BASE автоматически: нужен известный неизменяемый тег релиза в поддерживаемом диапазоне. Текущая минимальная точка входа updater — v0.6.0. Adoption создаёт lock только внутри журналированной транзакции и только после PASS валидатор постусловий; при failure новый lock не остаётся.

Да, но только для явно разрешённых переходов внутри одного домена. Например: GIT CHECK > COMMIT > PUSH > PR или STEP PLAN STEP-024 > IMPLEMENT > REVIEW. Вся цепочка сначала проходит формальную проверку по .harness/command-transitions.json; при INVALID_CHAIN не запускается ни один сегмент. Цепочка между разными доменами вроде STEP RUN STEP-024 > GIT COMMIT запрещена.

Harness хранит локальное состояние выполнения в .harness/local/execution/execution-status.json и сериализует изменения через execution-status.lock. Формат состояния ограничивает рост истории завершённых запусков, сохраняет STEP recovery proofs и может хранить bounded proof незавершённого side effect. HARNESS STATUS показывает незавершённые исполнения, а HARNESS RESUME продолжает только однозначно безопасное выполнение. Для COMMIT/PUSH/PR после crash сначала проверяется внешний факт: уже применённая mutation не повторяется, безопасный baseline допускает retry, неоднозначный outcome блокируется.

Это явно зафиксировано в протоколе. Для каждой канонической команды .harness/command-transitions.json хранит режим reasoning: none | required | conditional, а .harness/reasoning-boundaries.json публикует ту же границу в машиночитаемом виде. Модель решает смысловые задачи — формулирует требования и планы, меняет код, проводит ревью. Маршрутизацию команд, Verification, запись канонических отчётов, часть Git-операций, состояние выполнения и самообновление Harness выполняет детерминированно там, где результат можно вычислить однозначно.

Harness использует Python 3.11+ без сторонних зависимостей как детерминированный слой проверок: разбор конфигурации и документов, целостность проекта, проекции, переходы команд, контракты ревью/отчётов, финализацию INIT, выбор обязательных проверок, самообновление и предварительную проверку Git. Если обязательный контекст недоступен, проверка блокирует операцию, а не подменяет её частичной догадкой. Полный список CLI, ключей и кодов завершения — в разделе «Валидаторы».

Нет. STEP IMPLEMENT / STEP REVIEW отделены от публикации. Git-процесс запускается явно: GIT CHECK > COMMIT > PUSH > PR. После слияния PR отдельная команда GIT PR FINISH безопасно возвращает рабочую копию на исходную ветку и завершает локальный жизненный цикл ветки PR. Перед изменяющей операцией .harness/tools/git-preflight.py детерминированно проверяет политику и предусловия.

Только если нужны GIT PR и GIT PR FINISH. GitHub использует gh, Gitea — tea. Для ядра Harness обязательны Git и Python 3.11+, а отсутствие provider CLI не блокирует обычные GIT CHECK, GIT COMMIT, GIT PUSH и GIT SYNC.

PRN-NNN — долгоживущий общепроектный инженерный инвариант. REQ описывает обязательный наблюдаемый результат продукта, ADR — конкретное принятое архитектурное решение, а PRN ограничивает класс будущих решений. Блокирующий принцип участвует в STEP PLAN, STEP REVIEW, PROJECT RECONCILE и RELEASE CHECK.

Потому что ревью и проверка завершённости отвечают на разные вопросы. Review проверяет дефекты реализации, а Completion / Convergence Gate — выполнены ли все критерии приёмки, обязательства связанных REQ, готового плана и применимые специализированные проверки. Вердикт ревью PASS передаётся в Completion Gate; только его PASS разрешает каноническое завершение STEP.

Harness пересчитывает контекст планирования. Если изменился действительно связанный REQ/ADR/OQ/STEP или блокирующий PRN, готовый план становится stale, а IMPLEMENT/RUN блокируется до нового STEP PLAN. impact-analysis.py показывает конкретную причину устаревания; несвязанные STEP не блокируются автоматически.

Чтобы planner, implementer и reviewer получали минимальный контекст конкретной задачи вместо полного репозитория. Harness детерминированно выбирает нужные разделы STEP, REQ/ADR/OQ, ссылки на архитектуру и Project Principles до адаптера среды исполнения, поэтому Codex и Claude Code работают с одним набором обязательного контекста. Дополнительный контекст подключается только с явной причиной.

Не полагаться на историю одного чата как на единственный источник памяти. Harness хранит требования, решения, планы, доказательства и ревью в репозитории, а локальное состояние выполнения помогает безопасно продолжить прерванную операцию. Подробнее — в статье о долговременном контексте Codex и Claude Code.

Да. Они используют разные адаптеры, но один протокол Harness, общие REQ/ADR/PRN/STEP, навыки и Project State API. Проект можно открыть в другой поддерживаемой среде и восстановить состояние из репозитория. См. практический разбор.

AGENTS.md — важная часть контракта, но Harness шире одного файла инструкций. Он включает канонические артефакты проекта, таблицу переходов команд, детерминированные проверки, состояние выполнения, контракты ревью и завершённости, Git policy и механизм обновления.

Harness управляет процессом разработки репозитория с помощью агента для программирования. Фреймворк агентов обычно нужен внутри создаваемого приложения для оркестрации агентов, инструментов и сообщений. Это разные уровни. Подробнее — в архитектуре.

Состояние текущего исполнения сохраняется в .harness/local/execution/execution-status.json. HARNESS STATUS показывает незавершённую работу, а HARNESS RESUME продолжает её только когда восстановление однозначно безопасно.

Реализатор не должен сам быть единственным источником утверждения «готово». Независимый STEP REVIEW проверяет код и доказательства для точной ревизии, а Completion / Convergence Gate отдельно проверяет выполнение обязательств STEP и связанных требований.

Harness использует формальные требования и планы, но не заканчивается на спецификации. Он связывает REQ/ADR/PRN/STEP с реализацией, проверками, независимым ревью, Completion / Convergence Gate, восстановлением выполнения и безопасными Git-операциями. Полный цикл описан в процессе разработки.