Главная идея: разработка должна оставлять след
Обычный диалог с coding agent легко заканчивается фразой «готово». Для реального проекта этого мало: нужно понимать, какое требование выполнялось, какие решения ограничивали реализацию, что именно было разрешено менять, чем результат проверялся и кто независимо подтвердил его корректность.
В AI Development Harness каждая важная стадия оставляет durable handoff в репозитории. Следующий агент или новая сессия получает не пересказ предыдущего чата, а проверяемые артефакты проекта.
Базовая цепочка
REQ / ADR / OQ / PRN
↓
STEP ADD
↓
STEP PLAN
↓
STEP IMPLEMENT
↓
Verification
↓
STEP REVIEW
↓
Completion / Convergence Gate
↓
GIT CHECK > COMMIT > PUSH > PRЭто не означает, что для каждой мелочи нужно создавать весь набор документов. REQ и ADR появляются только когда действительно есть требование или устойчивое архитектурное решение, а подтверждённые micro-change могут идти через PROJECT QUICK FIX.
REQ, ADR и STEP отвечают на разные вопросы
REQ
Что проект обязан обеспечивать. Требование описывает наблюдаемый результат и критерии принятия, а не способ реализации.
ADR
Почему принято устойчивое архитектурное решение, какие варианты рассматривались и какие последствия оно создаёт.
STEP
Что разрешено сделать сейчас: цель, scope, out of scope, mutation policy, acceptance, verification, dependencies и evidence.
OQ и PRN
OQ фиксирует существенную неизвестность, а PRN — долгоживущий инженерный инвариант, действующий на множество будущих решений.
Эти сущности не складываются в один гигантский документ. Harness намеренно разделяет источники истины, чтобы статус, архитектура, требования и операционное состояние не противоречили друг другу.
План — не сообщение модели, а проверенный handoff
STEP PLAN строится на Context Contract конкретной задачи. В него входят сам STEP, связанные REQ/ADR/OQ, нужные фрагменты архитектуры, dependencies и применимые Project Principles. После этого отдельный semantic reviewer проверяет план.
Готовый план связывается с context_basis и plan_content_hash. Если связанный контракт изменился, прежний Ready plan становится stale и реализация блокируется до нового планирования. Так Harness не позволяет выполнять старый план просто потому, что он уже записан.
Реализация ограничена контрактом задачи
STEP IMPLEMENT не даёт реализатору carte blanche на весь репозиторий. Scope и Mutation policy определяют допустимую поверхность изменений. Перед началом Harness проверяет prerequisites и completion proofs зависимостей, а после реализации выполняет записанный в STEP раздел Verification.
Автоматизируемые проверки задаются как реальные команды проекта. Harness сохраняет фактические exit codes и evidence вместо утверждения модели «тесты прошли».
Review и completion — две разные проверки
Независимый STEP REVIEW проверяет exact revision реализации и создаёт immutable report. Для рискованных поверхностей Harness детерминированно выбирает обязательные specialized reviewers — например security или tests.
Но даже PASS review ещё не означает автоматического закрытия STEP. Completion / Convergence Gate отдельно проверяет, выполнены ли acceptance criteria, обязательства связанных REQ, готового плана, verification и специализированных gates. Только после этого появляется каноническое доказательство завершения.
Git отделён от разработки
Успешный STEP IMPLEMENT или STEP REVIEW не публикует изменения автоматически. Git workflow запускается явно:
GIT CHECK > COMMIT > PUSH > PRPreflight проверяет protected branch, состояние worktree, divergence, policy и доступность PR capability. Mechanical mutation выполняют детерминированные инструменты; модель остаётся только на смысловой границе — например, при выборе типа commit или формировании текста PR.
Почему процесс переживает новую сессию
REQ, ADR, STEP, Ready plan, Evidence и review reports хранятся в репозитории. Для аварийно прерванного выполнения дополнительно существует локальное execution state. Поэтому новая сессия может выполнить HARNESS STATUS или HARNESS RESUME и продолжить доказуемо безопасную работу без восстановления скрытой истории разговора.
Как попробовать этот цикл
Создайте проект из template, заполните PROJECT_BRIEF.local.md, выполните PROJECT INIT, затем добавьте небольшую, но реальную задачу через STEP ADD и запустите STEP RUN. После выполнения посмотрите не только diff, но и STEP, Verification evidence и review report — именно они показывают разницу между «AI написал код» и проверяемым процессом разработки.