resolve: третий сценарий — обслуживание, у цикла SDD там нет входа

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

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

Ревью идёт фиксированным планом без метки и без разметчика — autotests и
operations, плюс conventions с техническим разбором, когда дифф трогает код.
Конвейер получил раздел «Прогон без change»: он написан вокруг change, и без
этой строки вызов упирался бы в предпосылку OpenSpec. Главный шаг сценария —
синк документации, а триггеры ADR работают стоп-признаком: своего источника у
обслуживания нет, и решение с ценой уходит в разведку.

README.md

@@ -37,19 +37,27 @@
     переоценивает порциями по 5–8, расставляет верх очереди с доводом на
     каждое движение.
 - **av-dev-code** — работа по задачам: разведка, решение и проверка сделанного.
-  Владеет `openspec/`. **Требует OpenSpec и сам его заводит** — кроме сценария
-  разведки, которому он не нужен.
+  Владеет `openspec/`. **Требует OpenSpec и сам его заводит** — кроме сценариев
+  разведки и обслуживания, которым он не нужен.
   - `openspec` — завести, настроить и **проверить** `openspec/` в проекте:
     `openspec init`, замена примера в `config.yaml` настройкой канонической
     формы, скрипт `openspec.py` (форма файла + сверка слепка с живой версией
     инструмента). Каталог принадлежит конвейеру, а не канону: без конвейера он
     проекту не нужен, и `docs.py` о нём молчит;
   - `resolve` — одна задача от постановки до закрытия. **Точка входа одна, а
-    сценария два, и выбирает сценарий сам скилл, прочитав постановку:**
+    сценария три, и выбирает сценарий сам скилл, прочитав постановку:**
     классифицировать задачу до вызова человек всё равно не может — «есть ли
-    очевидный способ решения» видно после чтения записи.
+    очевидный способ решения» и «меняется ли спека» видно после чтения записи.
     **Решение** идёт циклом SDD с чекпоинтом после ревью дизайна: объяснение
     человеческим языком, повод скорректировать ход.
+    **Обслуживание** (тип `chore`: тулчейн и сборка, зависимости, гит-хуки,
+    перенос, чистка) change не заводит и планового стопа не имеет вовсе: дельта-спек
+    у него нет **по построению**, то есть цикл SDD здесь не урезан, а остаётся без
+    входа. Ревью идёт фиксированным планом без метки и без разметчика — `autotests`
+    и `operations`, плюс `conventions` с техническим разбором, если дифф трогает
+    код; главный шаг сценария — синк документации, потому что обслуживание чаще
+    прочих двигает как раз те факты, которые сверяются с кодом. Правка гейта
+    сверяется по составу проверок, а не по цвету.
     **Разведка** (тип `research`, сырая идея, мутная постановка) кода не пишет
     вовсе: её чекпоинт — варианты, 2–4 способа решить с ценой каждого, — стоит до
     первого написанного требования, а исход уезжает в документы канона и в
@@ -57,9 +65,10 @@
     своими проходами: `doc-wording` по документам, `task-form` и `task-wording`
     по записям. Выбранный способ реализуется **следующим прогоном**, и запускает его
     человек: смена сценария по ходу — событие с названным исходом, а не тихий
-    поворот. Оба сценария лежат справочниками и одинаково — `references/solve.md`
-    и `references/research.md`; в самом скилле только вход, развилка и правила,
-    не зависящие от сценария. OpenSpec нужен решению, разведке — нет;
+    поворот. Все три сценария лежат справочниками и одинаково —
+    `references/solve.md`, `references/maintain.md` и `references/research.md`; в
+    самом скилле только вход, развилка и правила, не зависящие от сценария.
+    OpenSpec нужен решению, разведке и обслуживанию — нет;
   - `review` — конвейер ревью **по темам**: документ проекта либо
     заводит тему проверки, либо питает чужую тему источником, либо процессный и в
     ревью не читается вовсе. Разметка идёт **один раз на задачу**, сразу после
@@ -82,7 +91,7 @@
 flowchart TB
     subgraph pipe["av-dev-code — исполнение; сценарий решения требует OpenSpec"]
         direction LR
-        tp["resolve<br/>2 сценария: разведка и решение"] --> rp["review<br/>10 агентов-проходов"]
+        tp["resolve<br/>3 сценария: разведка,<br/>решение, обслуживание"] --> rp["review<br/>10 агентов-проходов"]
         osp["openspec<br/>заводит и проверяет openspec/"]
     end
     subgraph docsp["av-dev-docs — документация, владеет docs/"]