# 55. `task-pipeline` стал `resolve`: два плановых стопа вместо полной автономии (2026-08-09)

**Р203. Автоматическое решение задач агентом признано утопией — «работает, но
работает плохо», — и хуже того, автор перестал ориентироваться в собственном
процессе.** Отсюда разворот: задачи решаются по одной, а в цикл возвращается
человек. `task-batch` удалён целиком; `task-pipeline` переписан в `resolve`.

**Прежняя доктрина звучала «умолчание — делать, а не спрашивать», и она не
отменена, а ограничена.** Полностью автономный прогон плох не тем, что ошибается,
а тем, что ошибку видно на готовом коде: развилка, стоившая бы абзаца до
`propose`, стоит переписывания после `apply`. Постоянное же согласование
возвращает ту цену, ради ухода от которой пайплайн и писался. Разрез поэтому по
**месту**, а не по важности решения: развилка, найденная до ближайшего чекпоинта,
копится в него; найденная после последнего — по-прежнему уходит вопросом в запись,
и задача доводится в объявленных границах.

**Чекпоинтов два, и второй обязателен всегда.**

- **«варианты»** — у исследовательской задачи, до первого требования. Признак
  ветки не объём работы, а **отсутствие одного очевидного способа решения**:
  обсуждать варианты после `propose` поздно, предложение уже воплотило один из
  них, и разговор пойдёт не о выборе, а о переделке. Форма ограничена сверху —
  2–4 варианта: больше четырёх человек не сравнивает, а признаёт неспособность
  сравнить и просит рекомендацию.
- **«объяснение»** — у всякой задачи, **после** ревью дизайна. Порядок обоснован:
  человек читает то, что уже просеяла машина, и не тратит внимание на выловимое
  `review-specs`. Внимание здесь самый дорогой ресурс процесса.

**Объяснение не стало новым артефактом, и это главная правка первоначального
замысла.** Задумывалось отдельным разделом в `design.md`; при разборе оказалось,
что оно там было бы **третьим домом** одного и того же: в `proposal.md` уже есть
`## Why` («в чём проблема»), в `design.md` — рассмотренные варианты. Поэтому
объяснение **собирается из двух существующих артефактов**, а требование к их
форме уехало в `openspec/config.yaml` — `rules.proposal` и `rules.design`. Это
единственное место, применяющееся **в момент написания**, а не после.
Побочная выгода: `design.md` с названными причинами отказа — половина будущего
ADR, а промоут ADR читает именно архивный `design.md`.

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

**Удаление `task-batch` обошлось дороже своего каталога.** На нём держались:
третий режим `review-specs` (стык после слияния) вместе с исключением «живого
change нет — берём источником актуальные спеки»; единственное исключение из
правила `review-triage` «плана нет — не запускаюсь»; и обоснование имени основной
ветки в каноне — «в неё вливает батч». Первые два — послабления, существовавшие
только ради батча, и с ним они исчезли, сделав оба правила строже.

## Что из этого следует

**С184. Автономность ограничивается местом, а не важностью решения.**
«Спрашивать о важном» неисполнимо: важность оценивает тот же, кто хочет
закончить. «Копить до ближайшего планового стопа» проверяемо и не требует
суждения.

**С185. Чекпоинт ставится после машинной проверки, а не до неё.** Внимание
человека тратится только на то, чего машина не ловит; порядок наоборот сжигает
его на выловимом и обесценивает саму остановку.

**С186. Объяснение для человека не заводит своего артефакта.** Если оно
собирается из уже существующих, оно не может с ними разойтись; отдельный текст
«то же, но понятнее» — третий дом, и расходится он молча.

**С187. Послабление, введённое ради одного потребителя, уходит вместе с ним.**
Исключение переживает своего заказчика и выглядит общим правилом; удаляя
потребителя, ищи его исключения — они и есть настоящий хвост.