Процесс разработки

Каждый этап сохраняет контекст для следующего

История чата не является базой знаний. Каждая стадия сохраняет результат в репозитории: PLAN — в задаче, REVIEW — в неизменяемом отчёте, RECONCILE — в отчёте аудита, завершение — в доказательствах выполнения и представлениях состояния.

От запроса к контракту задачи

STEP ADD: <описание> проверяет дубликаты, выбирает стабильный ID, связывает REQ/ADR, вычисляет зависимости и формирует цель, контекст, границы изменений, правила изменения файлов, исключения, критерии приёмки, проверки и ожидаемые результаты.

Код продукта на этом этапе не меняется.

STEP RUN: автоматический цикл

STEP PLAN: contract check + independent planning review
  → STEP IMPLEMENT
  → deterministic verification
  → STEP REVIEW: immutable Review Contract v2
  → [условно security/test review]
  → STEP FIX ↔ STEP REVIEW
       ↳ NO_PROGRESS / REPEATED_FINDINGS / REGRESSION → BLOCKED
       ↳ hard cap execution.maxFixReviewCycles
  → CLOSE

Для обычных задач разработки переходы между PLAN, IMPLEMENT, REVIEW и FIX вычисляет dispatcher — без отдельного вызова модели на каждом переходе. Модель остаётся там, где нужна смысловая работа: подготовить план, изменить код, найти дефекты или исправить замечания. Verification запускается машинно, а Evidence фиксируются по фактическому результату команд.

FAIL-review передаёт FIX не свободный текст, а structured findings Review Contract v2 со stable fingerprint. Следующие REVIEW сравниваются детерминированно: .harness/tools/repair_cycle.py может остановить цикл раньше hard cap при отсутствии прогресса, повторе тех же findings или доказанной регрессии. Изменение contract scope отключает такое сравнение fail-safe, а первый FAIL никогда не считается основанием для adaptive stop.

Специальные типы STEP могут использовать смысловую оркестрацию самого STEP RUN. Блокирующая проблема, deterministic adaptive stop или исчерпание абсолютного лимита останавливают процесс: Harness не маскирует неуспешный результат.

Тот же процесс можно запускать вручную

STEP PLAN STEP-NNN сначала пытается доказать, что контракт задачи непротиворечив и исполним. Затем сохраняет план реализации и запускает независимую семантическую проверку плана. План считается готовым только при совпадающем PASS, актуальном context_basis и plan_content_hash.

STEP IMPLEMENT STEP-NNN работает только по готовому плану. STEP REVIEW STEP-NNN проверяет точную ревизию репозитория: дефект реализации даёт FAIL и ведёт в FIX, а противоречие контракта или отсутствующее архитектурное решение даёт BLOCKED и останавливает цикл.

Небольшая правка идёт по короткому пути

PROJECT QUICK FIX: исправь опечатку…
        ↓
proportional check
        ↓
GIT CHECK
        ↓
GIT COMMIT

PROJECT QUICK FIX допустим только без изменения поведения продукта, API, данных, безопасности, архитектуры и зависимостей. Если фактические границы правки шире — Harness останавливает короткий путь и предлагает STEP ADD:.

Расхождения не скрываются — согласованность восстанавливается явно

PROJECT RECONCILE сравнивает код, тесты и конфигурацию с REQ, ADR, архитектурой, STEP и доказательствами выполнения. Результат — отчёт аудита и при необходимости корректирующий STEP. Код продукта молча не переписывается.

Публикация отделена от реализации

GIT CHECK > COMMIT > PUSH > PR
        ↓ после слияния PR
GIT PR FINISH

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

GIT COMMIT фиксирует проверенный snapshot ветки, родителя и дерева индекса, сверяет его прямо перед commit и проверяет фактические ветка/родитель/дерево после выполнения пользовательских хуки Git. Если проверенное состояние изменилось, команда возвращает COMMIT_POSTCONDITION_FAILED и компенсирует только доказанно принадлежащую ей изменение ref; разрушительный reset не используется.

Mutation-команды COMMIT/PUSH/PR сохраняют bounded side-effect checkpoint. После crash executor сначала наблюдает внешний результат: уже применённый side effect переиспользуется, доказанно неизменившийся baseline можно безопасно повторить, а неоднозначное состояние блокируется как SIDE_EFFECT_RECOVERY_AMBIGUOUS.

После успешного GIT PR Harness сохраняет локальное состояние Pull Request. Когда PR уже слит, GIT PR FINISH проверяет состояние MERGED, подтверждает точный head SHA, безопасно возвращает рабочую копию на исходную ветку и удаляет только проверенную локальную ветку PR. Это работает и после squash/rebase-слияния без git branch -D, reset или автоматического rebase.

До реализации Harness проверяет качество самого контракта

Структурно корректного Markdown недостаточно. Перед реализацией Harness разделяет несколько вопросов, которые раньше легко смешивались в один «хороший план».

структурная проверка
        ↓
качество требований
        ↓
согласованность планирования
        ↓
архитектурная полнота
        ↓
реализация

REVIEW PASS и завершение STEP — разные решения

STEP REVIEW отвечает на вопрос, есть ли существенный дефект в проверенной реализации. Проверка Completion / Convergence отвечает на другой вопрос: выполнены ли все обязательства текущего STEP, связанных требований и готового плана.

Verification
    ↓
STEP REVIEW
    ↓ вердикт ревью PASS
Completion / Convergence
    ├─ PASS    → закрыть STEP
    ├─ FAIL    → STEP FIX
    └─ BLOCKED → остановить RUN

Результат проверки завершённости сохраняется в том же неизменяемом отчёте REVIEW. Поэтому успешное ревью реализации не может скрыть недоделанный критерий приёмки или обязательство REQ.

Какие проверки выполняются детерминированно →

Изменение требований не оставляет старые планы «готовыми»

REQ, ADR, OQ, STEP и Project Principles могут эволюционировать. Harness использует один отпечаток контекста планирования и детерминированный анализ влияния, чтобы затронутые планы становились устаревшими без догадок модели.

REQ / ADR / OQ / PRN изменён
        ↓
контекст планирования изменился
        ↓
затронутый план = stale
        ↓
STEP RUN / IMPLEMENT блокируется
        ↓
STEP PLAN

.harness/tools/impact-analysis.py показывает конкретную причину устаревания и точное следующее действие. Несвязанные STEP не блокируются только потому, что изменился соседний артефакт.

Как актуальность контекста хранится в репозитории →