## Разработка

Здесь работает правило, ради которого построена вся конструкция: **готово доказывается
исполнением, а не записью**. Отметку `done` ставит код возврата команды, а не ваше
суждение. Попытка закрыть таск без зелёного прогона будет отклонена CLI.

Это не перестраховка. У трёх крупных аналогов их собственные мейнтейнеры завели на себя
один и тот же баг — «агенты самоотчитываются об успехе без верификации», «отмечает задачи
выполненными, не собрав приложение», «подзадачи отмечены готовыми без реализации» — и ни
один не выпустил исправление.

### Цикл одного таска

1. `chekan task start NN --model <какая модель делает>` — **`--model` обязателен.** Имя модели
   не публикуется в переменных окружения ни одним харнессом, поэтому сказать, кто делал
   работу, можно только явно. Пропустите — и в отчёте останется «claude-code» или
   «antigravity» без модели, а спросят об этом первым. Забыли — поправимо: `chekan task set NN
   --model <…>`.
2. Запустите **субагента со свежим контекстом**. Передайте ему **путями, а не текстом**:
   `interfaces.md`, файл таска, нужные разделы спеки, команду проверки, рабочий каталог.
   У него есть файловая система, он умеет читать.
3. В промпт исполнителя вшейте два блока дословно — их негде прочитать:
   - **Контракт возврата.** Не больше 25 строк, без кода и без диффов:
     `STATUS: DONE | HANDOFF | BLOCKED` плюс `FILES / TESTS / INTERFACES / CONCERNS`.
   - **Потолок контекста.** «Сделал около семидесяти правок и прогонов — остановись на
     ближайшем зелёном прогоне и верни `STATUS: HANDOFF`». Расход растёт как число шагов
     на средний контекст, поэтому раздувшийся исполнитель платит квадратично.
4. Прогоните проверку: `chekan run "<команда>" --task NN`. Красная — чините, не закрывайте.
5. Закройте: `chekan task done NN --tokens N`. CLI сверит, что доказательство снято на
   текущем коммите, а не до последних правок. **`--tokens`** — сумма входа и выхода,
   которую потратил исполнитель на этот таск; спросите у него это число перед закрытием.
   Не назовёте — расход в отчёте и на панели так и останется «не измерен», а не нулём:
   инструмент взять его сам неоткуда, и молчание дороже честного пробела.
6. Закоммитьте. **Один коммит на таск**, номер таска в заголовке — это точки отката
   владельца и главный механизм дешёвого ревью: лента из восьми осмысленных коммитов
   читается, одна простыня на четыреста строк — нет.

### Вопрос владельцу

Спрашивайте владельца только когда без ответа продолжать нельзя. В остальных случаях
решайте сами и записывайте решение в заметку требования или таска как предположение.
Вопрос — `chekan ask "<текст>"`; в режиме `auto` команда откажет.

### Параллель

Потолок — **три исполнителя в полёте**, и это ограничение, а не скромность: на 142 тысячах
агентских PR базовая доля конфликтов 27,67%, а собственная документация Claude Code
рекомендует 3–5 и предупреждает про правку одного файла двумя агентами.

Запускайте волну **одним сообщением**: два вызова в двух сообщениях выполнятся
последовательно, и параллелизм, посчитанный в плане, молча пропадёт при доставке. Зоны
внутри волны не должны пересекаться — гейт G3 это уже проверил.

### Ремонт — две разные адресации

**Недоделка** (красный тест, находка ревью): дозапрос **тому же субагенту**, его контекст
цел, шлите одну строку с условием. Потолок — два дозапроса.

**Отказ** (`BLOCKED`, повторно провалившийся ремонт): свежий контекст и **обязательно
изменённый подход**. Тот же промпт даст тот же результат.

Запрещённый фолбэк — взять клавиатуру самому. Оркестратор не пишет код проекта.

### Если план не держится

Исполнитель вернул, что нарезка неверна — решаете вы, но код всё равно пишется ниже.
Поправьте спеку на месте, добавьте требование с суффиксом `D` (открытие, доказанное
сборкой), перенарежьте только то, что стало невалидным. Владельцу — одна строка в любом
режиме, включая `auto`.

### Претензия гейта — это список работы, а не остановка

Гейт не пройден — значит у вас на руках список следующих шагов, а не приговор. «R01 остался
в статусе open» и «нет отчёта независимого читателя» — это две задачи, а не два упрёка.
Закрывайте их по одной, пока гейт не станет зелёным: **наша задача — зелёный прогон, а не
аккуратно оформленная остановка.**

Останавливаться и звать владельца можно ровно в одном случае: претензия требует его решения.
Тогда назовите её словами и целиком — «гейт G4, слепой приёмщик не нашёл в работе вот это»,
— а не номером гейта и не числом претензий. Человек не обязан ходить в терминал за текстом,
который у вас уже есть.

### Волна исполнителей: коммитить только своими путями

Общий индекс git — единственное место, где параллельная работа теряется молча. Исполнитель,
делающий `git add -A` или `git commit -a`, уносит в свой коммит чужие незакоммиченные правки,
а чужой коммит следом может удалить его файлы. Это уже случалось.

Правило простое: каждый исполнитель добавляет в индекс **только свои пути** и собирает коммит
своим индексом (`GIT_INDEX_FILE`), если работает в волне. Оркестратор перед волной проверяет,
что дерево чистое, а после каждого закрытия — что в коммит попало ровно то, что названо в
отчёте.

### Замок на базу 1С: работа только в доказанно тестовой

1С-прогон не начинается без доказательства, что база — тестовая:
1. **Объявление:** `chekan-1c.json` в корне проекта (строка соединения и версия платформы).
2. **Только файловые базы:** `/S` (серверная) — отказ всегда (серверная считается боевой).
3. **Метка:** файл `.chekan-testbase` рядом с каталогом базы (кладётся только владельцем вручную).
4. **Чёрный список:** `~/Services/onec-build-agent/ib*` запрещены даже с меткой.
5. **Занятая база:** блокировки `1Cv8.cfl` / активные сеансы — отказ.
6. **Копия:** каталог базы копируется перед прогоном тестов.

