---
date: 2026-05-28
kind: self-retrospect
window:
  episodes_in_file: 731
  episodes_since_last_run: 772
  last_run_at: null
trigger: explicit /self-retrospect от заказчика
---

# Self-retrospect 2026-05-28

Первый запуск этого скила. Окно — все 728 эпизодов мая (фильтр после legacy v1 = 728 schema-v2+; общее число строк в `episodes-2026-05.jsonl` = 731). Источник агрегатов — `docs/observer/STATUS.md` на момент запуска.

## Метод

Я выбрал 4 паттерна из STATUS.md, сформулировал гипотезы про **свои** паттерны, спросил заказчика через AskUserQuestion, что из этого симптом и что нормально. Сам себе вопросов не задаю — этот скил не интервью с заказчиком про меня, а сверка моей интерпретации цифр с человеком, который видит мои решения снаружи.

## Наблюдения и вердикт заказчика

### 1. Override-фразы — 87 срабатываний за один день (≥5/день = ⚠️)

Цифры за 2026-05-28: `recovery` 38, `ремонт инфраструктуры` 26, `без скилов` 17, `срочно` 6. Итого 87 в один день. Для сравнения за всё время: `recovery` 311 (38 сегодня = 12%), `ремонт инфраструктуры` 185 (14%).

**Вердикт заказчика:** симптом, я обхожу гейт. Не «нормально для типа работ» и не «гейт перекручен».

**Что это значит для меня:**

- Когда я тяну за override — это удобство, а не нужда. Брейн-ретро и нормативка действительно генерят много infra-операций, но это не оправдание автоматически переключаться в `recovery`/`ремонт инфраструктуры` режим.
- Особенно проблемно: `recovery` 38 — фраза для аварийных случаев, не для каждого второго коммита.
- Полагаю что часть отсечения через `без скилов` 17 — тоже инерция: я знаю что обходит хук и тяну, не подумав есть ли реально подходящий скил.

### 2. Disputable 191 против correct 113 — серая зона 2× от очевидно-правильных решений

Из 339 проверенных reviewer'ом эпизодов: 113 correct, 191 disputable, 31 wrong_node, 2 overkill, 2 underkill. 56% серой зоны — это много.

**Вердикт заказчика:** сигнал, надо учить роутер тоньше. Не шум reviewer'а, не нормальная серая зона.

**Что это значит:**

- Текущий классификатор слишком часто отдаёт «и так и так пройдёт». Нужно докручивать triggers/boundaries в `docs/registry/nodes.yaml` чтобы серый случай в большинстве уходил в детерминированный вариант.
- Не моя задача в этой сессии — но в эпизодах брейн-ретро надо предлагать конкретные правки nodes.yaml по топ-disputable кластерам.

### 3. 0% активации скилов на feature / cleanup / refactor

Цифры (% задач прошедших через скил):

- feature: 0% (17 эпизодов)
- cleanup: 0% (7)
- refactor: 0% (1)
- analysis: 13.8% (29)
- planning: 16.7% (18)
- bugfix: 25% (20)

**Вердикт заказчика:** неправильно, чаще планировать сначала. Не «нечего звать» и не «мало эпизодов».

**Что это значит:**

- Для любой новой фичи в Лидерре (даже на 3-4 шага) положено вызывать `superpowers:writing-plans` или `superpowers:brainstorming` перед кодом. Я этого избегаю.
- Для refactor — `superpowers:brainstorming` чтобы понять «зачем» прежде чем переделывать, или TDD-цикл.
- Для cleanup — спорнее, но даже там планирование «что убираю и почему» лучше чем ad-hoc вычистка.
- На bugfix 25% — выше, потому что хук `enforce-tdd-gate` активно толкает к TDD; для feature аналогичного жёсткого хука нет, отсюда 0%.

### 4. Топ reviewer-рекомендаций — coder-agent / Semgrep / Sentry MCP

Когда reviewer считает что я выбрал спорный узел, чаще всего советует:

- #19 coder-agent — 16 раз (отдать кодирование суб-агенту)
- #25 Semgrep — 15 раз (запустить SAST-сканер)
- #34 Sentry MCP — 8 раз (посмотреть журнал ошибок прода)

**Вердикт заказчика:** да, все три недоиспользую.

**Что это значит:**

- coder-agent (claude-flow): когда задача чисто механическая или объёмная — отдавать суб-агенту, не делать самому. Часто я пишу длинные правки сам, хотя мог бы делегировать.
- Semgrep — security-vet чаще, не только при «полном аудите портала». При любой правке auth/billing/CSV-импорта/webhook — Semgrep на diff.
- Sentry MCP — при любых симптомах с боевого (репорт ошибки от заказчика, странность в логах) первым делом смотреть Sentry, а не гадать по коду.

## Чем это отличается от brain-retro

Brain-retro смотрит наружу — что произошло, какие узлы дёрнулись/не дёрнулись, что предложить как нормативную правку. Self-retrospect смотрит внутрь — мой собственный когнитивный паттерн в принятии решений. Здесь нет предложений менять реестр или хуки. Здесь констатация: я слишком легко обхожу гейт, плохо планирую feature/refactor, недоиспользую делегирование и инструменты диагностики.

## Что я меняю с этого момента

Не правила (правила — в Pravila/PSR_v1, не в заметках). Привычки:

1. **Override-дисциплина.** Прежде чем впечатать `recovery` или `ремонт инфраструктуры` — спросить себя «это правда инфра-фикс или я ленюсь дать verify?». Когда сомневаюсь — без override.
2. **Feature → план/обсуждение первым.** Любой запрос на «добавь Х», «сделай Y» который требует ≥3 шагов — сначала `superpowers:writing-plans` или `superpowers:brainstorming`, не сразу Edit/Write.
3. **Симптом с боевого → Sentry первым.** Не «давай посмотрим код», а «давай сначала глянем в Sentry».
4. **Security-edit → Semgrep.** Правки в auth/billing/CSV/webhook → Semgrep на diff перед коммитом.
5. **Объёмное кодирование → coder-agent.** Если задача = «напиши N однотипных штук», «перенеси Y в Z по шаблону» — суб-агент, не я сам.

Я понимаю что заметка не enforce'ится. Если за следующие 50-100 эпизодов паттерны не изменятся — это материал для brain-retro или вообще для нового хука.

## Метаданные

- Sanitize прошёл: `tools/observer-pii-filter.mjs::sanitize` — ответы заказчика не содержали PII.
- Counter сброшен в `docs/observer/.self-retrospect-counter.json`.
- Эпизод **не пишется** (этот скил пишет только заметку, не episode JSONL).
