This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

English

Процесс

Рабочий цикл, который codeharness задаёт для любого проекта, его принявшего. Эта страница — карта цикла и указатель, где что определено, а не пересказ самих правил. За нормативным текстом — по ссылкам.

Цикл: план → согласие → issue → работа → проверка → ревью

1. План. Любое смысловое изменение репозитория (код/тесты/конфиг/CI/ спеки/сборка/VERSION/документация) требует короткого плана (что, зачем, риск) и явного согласия до начала работы. Определено в CLAUDE.md §1. Одно исключение: рутинное обновление статус-файла (см. session-memory.md) отдельного плана не требует — это часть текущей задачи, не новое изменение.
2. Согласие. Работа над смысловым изменением не начинается, пока пользователь явно не одобрил план. CLAUDE.md §1 прямо говорит и об обратном: молчаливое согласие от пользователя не требуется — если есть вариант лучше, сказать об этом до фиксации решения.
3. Issue. Та же область, что у планового гейта — любое смысловое изменение репозитория требует issue в трекере. Порядок важен: план согласован → issue создан или проверен → начата работа, не наоборот. Полные правила, исключения (одна очевидная опечатка, явная команда пользователя) и дисциплина лейблов: issue-tracker.md.
4. Работа. Внутри одобренного плана не останавливаться и не переспрашивать, кроме реального блокера (неожиданный сбой, конфликт, недостающая информация): incident-recovery.md. Дисциплина коммитов (один логический шаг = один коммит, когда push, правила batch, механика релиза): git-discipline.md. Правка кода в существующем проекте — по code-style.md (дисциплина скоупа, fail-fast, без незапрошенных слоёв мёртвого кода/ обратной совместимости).
5. Проверка. Обязательна после выполнения, до отчёта о готовности — не считать успехом финальную строку OK саму по себе; правило baseline для унаследованных красных проверок; что считается реальным прогоном pytest, а что — «тесты не запустились»: testing-and-verification.md.
6. Ревью. Отдельного файла codeharness под это нет — ревью идёт через механику issue/PR из issue-tracker.md и через обычную конвенцию закрытия по merge (closes #N привязан к целевой ветке merge, а не к рабочей ветке).

Маршрутизация задачи: Маршрут: inline | skill | agent

Перед любой задачей codeharness требует объявить строку маршрута с кратким обоснованием — это гейт видимости, не формальность: пропущенный скилл или агент трактуется как провал маршрутизации, а не забывчивость.

• inline — мелкая правка, прямой фактический ответ или локальный разбор одного явно указанного файла/фрагмента.
• skill:<name> — под задачу есть специализированный процесс (проектирование, отладка, ревью); процесс-скиллы — раньше implementation-скиллов.
• agent:<name> — задаче нужен поиск источника ответа, скан нескольких модулей, сбор контекста по проекту или обработка большого объёма — выгрузить, вернуть краткий проверяемый результат.

Маршрут относится к текущей фазе; при смене исполнителя — объявить новый (цепочка вида skill → agent → inline — норма, не разовый выбор). Подробности, оговорка про Explore/Plan (они не грузят CLAUDE.md) и опциональный шаблон hook для жёсткой гарантии: task-routing.md. Детали выбора субагента/модели (гейты подтверждения по стоимости модели, принцип выгрузки контекста): subagents-and-models.md.

Версионирование: SemVer

Единый источник правды — файл VERSION в корне проекта; применяется SemVer. Релиз — это bump VERSION, обновление changelog и полностью зелёные проверки (baseline-исключения для унаследованных красных на релиз не распространяются). Build-идентификаторы между релизами и полная процедура релиза: versioning.md и git-discipline.md.

Персистентное состояние в течение цикла

История чата ненадёжна (лимиты контекста, компакция, новая сессия). Состояние, которое должно пережить сессию, живёт в репозитории — статус-файл, файл решений, сам CLAUDE.md — не только в диалоге. Триггеры обновления (handoff, смена модели, риск компакции, конец крупного этапа) и формат: session-memory.md. Процедура восстановления после обрыва/потери сессии: incident-recovery.md.

Приоритет при конфликте правил

Ядро (CLAUDE.md) выше любого отдельного .ai-workflow/*.md. Конфликт между двумя тематическими файлами Claude не трактует самостоятельно — выносится на пользователя. См. CLAUDE.md §0.