dev-skills/decisions/63-maintenance-third-scenario.md

63. Обслуживание — третий сценарий: у цикла SDD там нет входа (2026-08-13)

Задача, не меняющая поведения — тулчейн и сборка, зависимости, гит-хуки, перенос, чистка, — шла полным циклом решения: propose, разметка, ревью дизайна, чекпоинт, archive. Все пять шагов стоят на дельта-спеках, а у типа chore дельта-спек нет по построению: тип определён через «наблюдаемое поведение не меняется». Цикл не урезается ради дешевизны — он остаётся без входа, и change, заведённый под такую задачу, пуст, а разметчик по нему называет не те темы.

Р222. Признак сценария — связка из двух проверок, и обе обязательны. Тип записи предлагает (chore, реже fix, чьё исправление возвращает поведение к уже записанному), отсутствие дельт подтверждает. Тип объявляет автор и может ошибиться; отсутствие дельт — суждение исполнителя, и в одиночку оно самообслуживающееся. Разошлись — стоп, а не выбор.

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

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

Р225. Ревью идёт фиксированным планом, а разметчик не зовётся. Обе его оси не определены: размер он выводит из артефактов change, сложность — из формы решения, а незнакомая форма ушла в разведку ещё на первом шаге. План — autotests (запуск гейта) и operations (сверка), плюс conventions с техническим разбором, когда дифф трогает код, а не только оснастку: review-code — единственный проход, который вообще говорит «здесь ошибка в логике», и чистка без него проверена лишь на то, что она собирается. requirements и security не смотрит никто, и это строка границ покрытия, а не умолчание.

Р226. Найденная дельта — не поломка задачи, а обнаружение более широкого типа. Стоп поэтому устроен как три шага, а не как доклад об отказе: назвать тип, которым задача оказалась (fix — расходится с заявленным, feature — снаружи появляется то, чего не было), объяснить человеку простым языком, что нашлось, и дать два решения — переформулировать запись и решать её процессом того типа следующим прогоном либо прекратить работу. Третьего решения, «доделать как обслуживание», нет: оно и есть молчаливое изменение поведения. Тип при этом исполнитель предлагает, а меняет av-dev-tasks:tasks и только после ответа — иначе исполнитель назначает себе другой процесс и другую глубину проверки сам.

Р227. Триггеры ADR у обслуживания работают стоп-признаком, а не поводом завести запись. Список источников ADR канон закрыл двумя — архивный design.md и записка разведки, — и обслуживание не производит ни того ни другого. Значит дорогой откат, намеренный отказ и пересмотр прежнего решения означают здесь одно: сценарий выбран неверно, работа идёт разведкой, где решение проходит чекпоинт вариантов и получает законный источник. Третьего источника заводить не понадобилось.

Р228. Синк документации — главный шаг сценария, а не остаток. Обслуживание не меняет поведения, значит почти всё, что оно меняет, — документация: команды, шаги гейта, зависимости, пути, имя ветки, место механизации правила. Ровно эти факты doc-code-drift и сверяет с кодом.

Р229. Состав гейта сверяется отдельно от цвета, а чем именно — решает проект. Красный, ставший зелёным, виден; «проверок стало на две меньше, обе зелёные» не виден ничем, а это единственное место конвейера, где инструмент проверяет сам себя. Что считается составом, объявляет проект семантикой гейта в CLAUDE.md; не объявил — строка доклада «сверен только цвет», а не догадка.

Р230. Своей capability тулчейн не получает, и своего документа канона тоже. Граница возможностей и сопровождения проходит по тому, кто наблюдает: гейт наблюдаем мы, а не пользователь сервиса. Всё, что попало бы в docs/toolchain.*, уже расписано по домам — CLAUDE.md (команды, семантика гейта, запреты, пути), architecture.* (зависимости, окружение, выкладка), conventions.* (механизированное), ROADMAP.md (работы). Проекту, которому этого мало, канон уже даёт механизм и без новой строки в раскладке: список тем открытый, и свой документ заводит свою тему. Цена такой темы названа — она попадает в план каждого прогона и на большинстве задач молчит.

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

С212. Короткий путь оправдан отсутствием входа, а не дешевизной. «Тут можно проще» — начало любой деградации; «этому шагу нечего обрабатывать» — проверяемое утверждение, и проверяется оно тем же признаком, что и переход между сценариями.

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

С214. Сценарий без стопа для человека требует более жёсткого правила необратимого, а не более мягкого. Стопа, на котором «ой» заметили бы, там нет.

С215. Инструмент, проверяющий сам себя, проверяется по составу, а не по исходу. Зелёный гейт после правки гейта не значит ничего.

С216. Место для нового документа ищется не по теме, а по бездомному факту. Тема «тулчейн» звучит убедительно, а фактов без дома за ней не оказалось — значит документ был бы вторым домом четырёх чужих.

С217. Работа, переросшая свой тип, останавливается предложением, а не отказом. «Здесь нужно менять спеки» перекладывает классификацию на человека в момент, когда весь материал для неё у исполнителя. Стоп обязан принести названный тип, объяснение и закрытый список решений — иначе выбор делается вслепую или не делается вовсе, и работа доезжает до коммита не тем процессом.