update skill

.dsh/skills/task-execution/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task-execution
-description: Выполняет любую нетривиальную задачу по процессу «план → ревью сеньёром → правки → выполнение → ревью результата → правки». План и результат проверяет субагент в роли senior developer; каждый цикл повторяется, пока замечаний не останется. При неясностях агент задаёт вопросы пользователю. Загружай для реализации фичи, исправления бага, рефакторинга, написания кода или документации, когда задача не сводится к одному тривиальному действию.
+description: Выполняет любую нетривиальную задачу по процессу «план → ревью сеньёром → правки → выполнение → ревью результата → правки». План и результат проверяет субагент в роли senior developer; каждый цикл повторяется, пока не устранены блокирующие замечания. Ниты и уточнения формулировок не блокируют одобрение — они фиксируются и могут остаться неисправленными. При неясностях агент задаёт вопросы пользователю. Загружай для реализации фичи, исправления бага, рефакторинга, написания кода или документации, когда задача не сводится к одному тривиальному действию.
 whenToUse: Пользователь просит выполнить задачу (написать код, починить баг, отрефакторить, задокументировать, что-то исследовать и внедрить) и задача не является тривиальным одношаговым действием. Для тривиальных правок скил можно не применять.
 ---
 
@@ -8,24 +8,30 @@ whenToUse: Пользователь просит выполнить задачу
 
 ## Контекст
 
-Любая нетривиальная задача выполняется строго по циклу: сначала **план**, затем **ревью плана сеньёром** с правками до полного одобрения, затем **выполнение** по одобренному плану, затем **ревью результата сеньёром** с правками, пока замечаний не останется. На каждом этапе, если что-то неясно, задаются вопросы пользователю.
+Любая нетривиальная задача выполняется строго по циклу: сначала **план**, затем **ревью плана сеньёром** с правками до одобрения, затем **выполнение** по одобренному плану, затем **ревью результата сеньёром** с правками, пока не устранены блокирующие замечания. Замечания делятся на **блокирующие** (исправляются обязательно) и **ниты** (фиксируются, но не блокируют одобрение и могут остаться неисправленными). На каждом этапе, если что-то неясно, задаются вопросы пользователю.
+
+## Классификация замечаний
+
+- **Блокирующее ([BLOCKER])** — влияет на функциональность, корректность, безопасность, целостность данных, совместимость, достижимость шага плана, ломает сборку/тесты, нарушает конвенции проекта, создаёт регрессию. Такие замечания исправляются все, без исключения.
+- **Нит ([NIT])** — уточнение формулировки, стиль, типографика, «на будущее», рекомендация без реального риска, альтернатива, которая не меняет поведение. Ниты фиксируются (в файле состояния или `todo/`), но НЕ обязательны к исправлению и не блокируют `APPROVED`.
+- Метку ставит сеньёр в каждом замечании. Если метка отсутствует или неоднозначна — трактуй замечание как блокирующее (осторожность в пользу качества); при сомнении можно спросить пользователя.
 
 ## Роли
 
-- **Исполнитель** — ты (агент). Составляешь план, выполняешь, правишь по замечаниям.
+- **Исполнитель** — ты (агент). Составляешь план, выполняешь, правишь по блокирующим замечаниям, фиксируешь ниты.
-- **Сеньёр (senior developer)** — отдельный субагент, запускаемый через `subagent`. Он **не видит наш диалог**, поэтому каждый промпт ревью должен быть самодостаточным — но самодостаточность достигается за счёт внешнего файла состояния, а не дублирования всего плана в промпте (см. правило 9).
+- **Сеньёр (senior developer)** — отдельный субагент, запускаемый через `subagent` **один раз на задачу** и переиспользуемый между раундами через `send_message` (он помнит свои предыдущие замечания и дельты — не противоречит себе и не перечитывает весь файл состояния каждый раунд). Он **не видит наш диалог**, поэтому каждый промпт ревью должен быть самодостаточным — но самодостаточность достигается за счёт внешнего файла состояния, а не дублирования всего плана в промпте (см. правило 9). Новый сеньёр создаётся только при смене задачи или переполнении контекста субагента (тогда — со сводкой уже принятых решений).
 - **Пользователь** — источник требований и финальный судья. Ему задаются вопросы при неясностях.
 
 ## Обязательные правила
 
 1. **Сначала план — потом выполнение.** Не начинай выполнение, пока сеньёр не одобрил план (ответил `APPROVED`).
-2. **Ревью плана и результата — только через субагента в роли senior developer** (см. шаблоны промптов ниже). Запускай его с `run_in_background: false` — следующий шаг зависит от его ответа.
+2. **Ревью плана и результата — только через субагента в роли senior developer** (см. шаблоны промптов ниже). **Создай сеньёра один раз** (первый раунд — `subagent` с `run_in_background: true`), далее каждый раунд — `send_message` тому же субагенту с дельтой. Ответ субагента приходит уведомлением (не синхронно): пока он работает, продолжай независимые шаги, по уведомлению забирай результат.
-3. **Замечания исправляются все, без выбора.** Нельзя отбрасывать замечание «потому что не согласен»: если не согласен — верни уточняющий вопрос сеньёру или спроси пользователя.
+3. **Блокирующие замечания исправляются все, без выбора.** Нельзя отбрасывать `[BLOCKER]` «потому что не согласен»: если не согласен — верни уточняющий вопрос сеньёру или спроси пользователя. **Ниты (`[NIT]`) исправлять не обязательно**: зафиксируй их в файле состояния или `todo/` и продолжай.
-4. **Цикл повторяется, пока сеньёр не вернёт `APPROVED`** — и для плана, и для результата.
+4. **Цикл повторяется, пока сеньёр не вернёт `APPROVED`** — и для плана, и для результата. `APPROVED` достижим при наличии только нитов (сеньёр может вернуть `APPROVED (ниты: ...)`); блокирует цикл только наличие `[BLOCKER]`.
 5. **Неясно — спроси.** На любом этапе (задача, шаг плана, замечание сеньёра) при неоднозначности задай вопрос пользователю через `ask_user_question`. Догадки вместо вопросов — ошибка.
 6. **Отслеживай прогресс** через `todo_write`: план из шага 2 переносится в todo-список, пункты отмечаются по мере выполнения.
 7. **Профильные скилы** (например `create-go-module`) — источник правил «как делать» для конкретной задачи. Этот скил управляет процессом «как вести задачу»; оба применяются вместе.
-8. **Бюджет раундов ревью — 3 на цикл** (план и результат отдельно). В шаблонах промптов требуй от сеньёра перечислить **все замечания одним списком за один заход** — включая мелочи, ниты и потенциальные будущие проблемы. После 3 раундов без `APPROVED` остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся замечания как известные ограничения (не растягивай полировку на десятки раундов).
+8. **Бюджет раундов ревью — 3 на цикл** (план и результат отдельно). В шаблонах промптов требуй от сеньёра перечислить **все замечания одним списком за один заход** с метками `[BLOCKER]`/`[NIT]`. После 3 раундов с неисправленными `[BLOCKER]` остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся блокеры как известные ограничения (не растягивай полировку на десятки раундов).
 9. **Дифф-ревью и внешнее состояние.** План, чек-лист и учёт замечаний держи во внешнем файле состояния (например, `.dsh/task-plan.md`). Промпт ревью содержит: задачу, путь к файлу состояния, **короткую дельту** «что изменилось с прошлого раза» и `git diff` изменённых файлов. Не пересказывай ревьюеру весь план и всю историю замечаний — файл состояния он прочитает сам (это его контекст, а не наш).
 10. **Саморевью до отправки.** Перед первым и каждым повторным ревью прогоняй фактические проверки, которые сеньёр всё равно сделает: поведение функций на реальных данных (например, `Transliterate("photo.png")`, `http.DetectContentType`, `filepath.Ext("x.PNG?v=2")`), чтение сгенерированного кода (pb.gw.go и пр.), арифметику лимитов. «Ревью результата» отправляй как `git diff` + выводы проверок, а не как пересказ плана.
 
@@ -49,12 +55,13 @@ whenToUse: Пользователь просит выполнить задачу
 
 ### 3. Ревью плана сеньёром
 
-Сохрани план и критерии в файл состояния (например, `.dsh/task-plan.md`), прогони саморевью (правило 10), затем запусти субагента с промптом по шаблону **«Ревью плана»** (ниже). Сеньёр возвращает либо `APPROVED`, либо список замечаний.
+Сохрани план и критерии в файл состояния (например, `.dsh/task-plan.md`), прогони саморевью (правило 10), затем **создай сеньёра** (`subagent`, первый раунд) с промптом по шаблону **«Ревью плана»** (ниже) и дождись его ответа. Сеньёр возвращает либо `APPROVED`, либо список замечаний с метками.
 
 ### 4. Цикл правок плана
 
-- Есть замечания → исправь план в файле состояния (и todo-список), отправь на ревью **повторно**: в промпт добавь только дельту «что изменилось с прошлого раза» (правило 9).
+- Есть блокирующие замечания → исправь их в файле состояния (и todo-список), отправь на ревью **повторно ТОМУ ЖЕ сеньёру** через `send_message`: в промпт добавь только дельту «что изменилось с прошлого раза» (правило 9).
-- Повторяй, пока не получишь `APPROVED`; после 3 раундов без `APPROVED` — спроси пользователя (см. «Ограничение итераций»).
+- Ниты → зафиксируй в файле состояния (раздел «Ниты / известные ограничения») или `todo/`, не обязательно исправляй.
+- Повторяй, пока не получишь `APPROVED`; после 3 раундов с неисправленными `[BLOCKER]` — спроси пользователя (см. «Ограничение итераций»).
 
 ### 5. Выполнение
 
@@ -62,11 +69,11 @@ whenToUse: Пользователь просит выполнить задачу
 
 ### 6. Ревью результата
 
-Сначала сам проверь результат (прогони проверки из плана, правило 10), затем отдай его сеньёру по шаблону **«Ревью результата»**: `git diff` изменённых файлов + выводы проверок. Сеньёр сверяет результат с планом (файл состояния) и критериями, проверяет корректность и соблюдение конвенций проекта.
+Сначала сам проверь результат (прогони проверки из плана, правило 10), затем отдай его сеньёру по шаблону **«Ревью результата»** через `send_message` (тот же субагент): `git diff` изменённых файлов + выводы проверок. Сеньёр сверяет результат с планом (файл состояния) и критериями, проверяет корректность и соблюдение конвенций проекта.
 
 ### 7. Цикл правок результата
 
-Правь по замечаниям, повторяй ревью, пока сеньёр не вернёт `APPROVED`. При каждом повторе сообщай сеньёру только дельту — что изменилось с прошлого раза (правило 9). После 3 раундов без `APPROVED` — спроси пользователя.
+Исправляй блокирующие замечания, повторяй ревью **тому же сеньёру** через `send_message`, пока не вернёт `APPROVED`. Ниты — фиксируй в `todo/` или файле состояния, не обязательно исправляй. При каждом повторе сообщай сеньёру только дельту — что изменилось с прошлого раза (правило 9). После 3 раундов с неисправленными `[BLOCKER]` — спроси пользователя.
 
 ### 8. Финальный отчёт
 
@@ -85,11 +92,19 @@ whenToUse: Пользователь просит выполнить задачу
 
 Проверь: полноту (нет ли пропущенных шагов), достижимость, корректность
 подхода, риски, соответствие конвенциям проекта, отсутствие лишних шагов.
-Перечисли ВСЕ замечания одним списком за один заход — включая мелочи,
+
-ниты и потенциальные будущие проблемы; не растягивай на несколько раундов.
+Классифицируй каждое замечание:
+- [BLOCKER] — влияет на функциональность, корректность, безопасность,
+  целостность данных, достижимость шага, ломает сборку/тесты, нарушает
+  конвенции проекта, создаёт регрессию. Такие обязательны к исправлению.
+- [NIT] — уточнение формулировки, стиль, типографика, «на будущее»,
+  рекомендация без реального риска. Ниты не блокируют APPROVED.
+
+Перечисли ВСЕ замечания одним списком за один заход — включая мелочи и
+ниты; не растягивай на несколько раундов.
 Ответь СТРОГО одним из двух вариантов:
-- APPROVED — если замечаний нет;
+- APPROVED (можно с пометкой «ниты: ...») — если блокирующих замечаний нет;
-- список замечаний, каждое в формате «<что не так> → <как исправить>».
+- список замечаний, каждое в формате «[BLOCKER]|[NIT] <что не так> → <как исправить>».
 ```
 
 ## Шаблон: промпт «Ревью результата»
@@ -104,21 +119,28 @@ whenToUse: Пользователь просит выполнить задачу
 
 Проверь: результат соответствует плану и критериям готовности, код/текст
 корректен, соблюдены конвенции проекта, нет регрессий.
-Перечисли ВСЕ замечания одним списком за один заход — включая мелочи,
+
-ниты и потенциальные будущие проблемы.
+Классифицируй каждое замечание:
+- [BLOCKER] — влияет на функциональность, корректность, безопасность,
+  целостность данных, ломает сборку/тесты, нарушает конвенции, регрессия.
+  Такие обязательны к исправлению.
+- [NIT] — уточнение формулировки, стиль, типографика, «на будущее»,
+  рекомендация без реального риска. Ниты не блокируют APPROVED.
+
+Перечисли ВСЕ замечания одним списком за один заход — включая мелочи и ниты.
 Ответь СТРОГО одним из двух вариантов:
-- APPROVED — если замечаний нет;
+- APPROVED (можно с пометкой «ниты: ...») — если блокирующих замечаний нет;
-- список замечаний, каждое в формате «<что не так> → <как исправить>».
+- список замечаний, каждое в формате «[BLOCKER]|[NIT] <что не так> → <как исправить>».
 ```
 
 ## Ограничение итераций
 
-Если в одном цикле (план или результат) после **3 раундов** замечания не исчерпались — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся замечания как известные ограничения.
+Если в одном цикле (план или результат) после **3 раундов** остаются неисправленные `[BLOCKER]` — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся блокеры как известные ограничения. Ниты не считаются причиной продолжения цикла: при одних нитах сеньёр возвращает `APPROVED (ниты: ...)`, а исполнитель фиксирует их в файле состояния или `todo/`.
 
 ## Критерии готовности
 
 - [ ] План составлен и одобрен сеньёром (`APPROVED`) до начала выполнения.
-- [ ] Все замечания сеньёра по плану учтены.
+- [ ] Все блокирующие замечания сеньёра по плану устранены; ниты зафиксированы (в плане/`todo/`) и не блокируют одобрение.
 - [ ] Результат соответствует плану и критериям готовности.
-- [ ] Все замечания сеньёра по результату учтены, получен `APPROVED`.
+- [ ] Все блокирующие замечания сеньёра по результату устранены, получен `APPROVED`; ниты зафиксированы.
 - [ ] Пользователю дан финальный отчёт.