code-ai-installer 4.0.1-a → 4.0.1-c

package/domains/development/.agents/skills/lava-flow-legacy-detection/SKILL.md

@@ -1,197 +1,197 @@
----
-name: lava-flow-legacy-detection
-description: Чек-лист признаков "лава-флоу" в legacy/brownfield коде — мёртвый код вокруг живого, не убранные feature flags, окаменевшие workarounds, дубликаты после миграций. Используй при анализе текущего состояния репозитория, перед рефакторингом и при ревью PR в зрелой кодовой базе. Активируй при упоминаниях "legacy", "технический долг", "brownfield", "почему этот код здесь".
-type: reference
-domain: development
-owners:
-  - architect
-  - reviewer
-  - senior_full_stack
-gates:
-  - ARCH
-  - DEV
-  - REV
-tech: []
-topic:
-  - architecture
-  - refactoring
-  - legacy
-triggers:
-  - легаси код
-  - мёртвый код
-  - лава-флоу
-  - неубранный feature flag
-  - brownfield рефакторинг
-  - окаменевший workaround
-  - неиспользуемый код
-related:
-  - current-state-analysis
-  - architecture-compliance-review
-  - architecture-doc-reference
-  - design-patterns-reference
-  - adr-log
-  - adr-log-reference
-  - threat-model-baseline
-  - security-baseline-dev
-  - code-review-checklist
-  - system-design-checklist
-budget_lines: 250
-schema_version: 1
----
-
-
-# Skill: Lava Flow Legacy Detection
-
-Анти-паттерн «лава-флоу» (Brown et al., *AntiPatterns*, 1998) — застывшая масса кода, попавшая в продакшен без должного контроля. Никто не помнит, зачем она тут, удалить страшно (нет тестов), переписать дорого. С каждым релизом слой утолщается.
-
-> **Когда применять:** ARCH (current-state analysis), DEV (перед изменением старого модуля), REV (ревью PR в зрелой кодовой базе). Reference-скил — активация через триггеры фронтматтера; см. § MCP integration ниже для cross-gate потребления.
-
-**Разделы:**
-1. [Признаки лава-флоу](#1-признаки)
-2. [Чек-лист проверки](#2-чеклист)
-3. [Что делать с находкой](#3-что-делать)
-4. [Что НЕ делать](#4-чего-избегать)
-5. [Шаблон отчёта](#5-отчёт)
-
----
-
-## 1. Признаки
-
-### 1.1 Структурные
-
-| # | Признак | Как обнаружить |
-|---|---------|----------------|
-| LF-01 | Закомментированные блоки кода в продакшен-файлах | grep по `//` / `/*` блокам >5 строк |
-| LF-02 | Ветки кода, которые никогда не выполняются | покрытие тестами / coverage report 0% на ветке |
-| LF-03 | Функции/классы без входящих ссылок | static analysis (ts-prune, knip, unimport) |
-| LF-04 | Параллельные «версии» одной логики (v1/v2/legacy/new) | grep по суффиксам имён |
-| LF-05 | Дубликаты после неоконченных миграций | сравнить директории `old/`, `legacy/`, `deprecated/` |
-| LF-06 | Файлы без изменений дольше половины возраста репозитория | `git log -1 --format=%cd -- <file>` или `find <dir> -name '*.ts' -mtime +<дней>` |
-
-### 1.2 Конфигурационные
-
-| # | Признак | Как обнаружить |
-|---|---------|----------------|
-| LF-07 | Feature flags, которые всегда `false` (или всегда `true`) | grep по `flag.*= false`, проверить usage в коде |
-| LF-08 | Конфиг-ключи, которые никто не читает | grep значения ключа по кодовой базе |
-| LF-09 | Env-переменные, которые не упомянуты в `.env.example` | diff между `process.env.X` и `.env.example` |
-| LF-10 | Захардкоженные mock/stub данные на продакшен-пути | grep по `MOCK_`, `STUB_`, `fake_`, `dummy_` |
-
-### 1.3 Поведенческие
-
-| # | Признак | Как обнаружить |
-|---|---------|----------------|
-| LF-11 | Воркараунды, ставшие постоянными | grep по `TODO`, `FIXME`, `HACK`, `XXX` старше 6 мес |
-| LF-12 | Захардкоженные version/environment checks на мёртвое окружение | grep по `if.*IE`, `if.*v1`, `if.*LEGACY` где правая сторона больше не существует |
-| LF-13 | Неактивные cron jobs / scheduled tasks | `crontab -l` + grep логов за 3 мес; `systemctl list-timers --all`; `kubectl get cronjob -o wide` (lastScheduleTime) |
-| LF-14 | Endpoints без вызовов из фронта/других сервисов | grep route paths по всему монорепо |
-| LF-15 | Маршруты в роутере, ведущие на 404 или пустые компоненты | unit test обходом всех routes |
-
-### 1.4 Примеры в коде
-
-**Лава** — закомментированный fallback на удалённую систему:
-
-```ts
-// Старый auth flow до миграции на Auth0 (2024)
-// if (legacyAuth.enabled) {
-//   const session = await legacyAuth.login(creds);
-//   return mapLegacySession(session);
-// }
-const session = await auth0.login(creds);
-```
-> `legacyAuth` модуль удалён 18 мес назад. Комментарий — окаменелость, история уже в git. **Решение:** удалить.
-
-**Не лава** — комментарий объясняет неочевидное (Chesterton's fence):
-
-```ts
-// +1 потому что Date.getMonth() возвращает 0-11.
-// Если кто-то «поправит» на getMonth() — поломает отчёты по январю.
-const month = date.getMonth() + 1;
-```
-> Комментарий несёт смысл, защищает код от ложно-очевидной правки. **Решение:** оставить.
-
----
-
-## 2. Чеклист
-
-Применять перед рефакторингом модуля или при первом погружении в legacy-репозиторий.
-
-- [ ] Прогнать `ts-prune` / `knip` / эквивалент → собрать список unreachable
-- [ ] Прогнать coverage на затрагиваемых файлах → отметить 0%-ветки
-- [ ] `git log --since=24.months.ago -- <file>` → выявить «застывшие» файлы
-- [ ] Найти все `TODO/FIXME/HACK` старше 6 месяцев → решить: fix или delete
-- [ ] Перечислить feature flags в проекте → для каждого проверить, меняется ли значение
-- [ ] Перечислить env-переменные → пометить unused
-- [ ] Для каждой подозрительной функции — найти все usages → если 0, помечать к удалению
-- [ ] Зафиксировать находки в отчёте (формат ниже) до начала рефакторинга
-
----
-
-## 3. Что делать
-
-**Принцип:** удаление лава-флоу — отдельная задача, не часть фичевого PR. **Перед удалением — `git blame` на блок.** Если автор активен в команде — спросить контекст (часто экономит часы и предотвращает удаление чего-то скрыто-полезного). Если автор ушёл или код старше ~24 мес — `git blame` только археология, ходить дальше по чеклисту.
-
-1. **Отчёт ДО изменений.** Перечислить находки в отдельном документе (`docs/reports/architect/lava-flow-<module>.md`). Без согласования архитектора не удалять.
-2. **Тестовое покрытие ПЕРЕД удалением.** Если ветка не покрыта тестами — сначала характеризационные тесты (Working Effectively with Legacy Code, M. Feathers), потом удаление.
-3. **Малыми PR.** Один PR = одна находка. Не «удалить весь deprecated/». Атомарность даёт ясную точку отката.
-4. **Feature flag → удалить «выключенную» сторону.** Если флаг 100% в одном положении дольше 1 релиза — удалять противоположную ветку. **НО:** если флаг переключался хотя бы раз за последний релиз — это live config, не лава; не трогать (Chesterton's fence — кто-то им активно пользуется).
-5. **ADR при сомнениях.** Если непонятно, зачем код существует — `$adr-log` с вариантами «удалить / оставить / переписать», эскалация на Architect.
-
----
-
-## 4. Чего избегать
-
-- ❌ **«Заодно почищу»** — лава-флоу не убирается ad-hoc внутри фичевого PR. Размывает diff, ломает ревью.
-- ❌ **Массовое удаление без тестов** — характеризационные тесты обязательны для непокрытых веток.
-- ❌ **Переименование вместо удаления** — `_old`, `_deprecated_v2` создают новый слой лавы.
-- ❌ **Комментарий «потом разберёмся»** — это та же лава, только в зародыше. Решение сейчас: delete или ADR.
-- ❌ **Сохранение «на всякий случай»** — git history — это уже архив.
-
----
-
-## 5. Отчёт
-
-```markdown
-# Lava Flow Report — <module-name>
-
-**Дата:** <YYYY-MM-DD>
-**Автор:** <agent>
-**Контекст:** <зачем смотрели — refactor / current-state / review>
-
-## Находки
-
-| # | ID | Файл/строка | Признак | Решение |
-|---|----|-------------|---------|---------|
-| 1 | LF-01 | src/foo.ts:120-180 | Закомментированный блок 60 строк | DELETE (PR #N) |
-| 2 | LF-07 | src/config/flags.ts:42 | Флаг `useNewAuth` = false уже 8 мес | DELETE old branch (PR #N+1) |
-| 3 | LF-04 | src/api/users-v1.ts | Дубликат users-v2.ts, никем не используется | DELETE (ADR-DEV-XXX) |
-
-## Эскалации
-- <если есть случаи, где нужен Architect/DEN sign-off>
-
-## План закрытия
-- <разбивка на PR с порядком>
-```
-
----
-## Ссылки на смежные навыки
-
-- `$current-state-analysis` — общий аудит репозитория, лава-флоу — один из его выходов
-- `$architecture-compliance-review` — проверка соответствия архитектуре после удаления
-- `$design-patterns-reference` — что использовать ВМЕСТО удалённой лавы
-- `$code-review-checklist` — на этапе ревью PR с удалением
-- `$system-design-checklist` — чтобы новый код не стал следующей лавой
-
----
-
-## MCP integration (cross-gate activation)
-
-Reference-скил с cross-gate потреблением:
-
-- **ARCH (primary)** — `architect` использует в current-state analysis перед предложением рефакторинга
-- **DEV (secondary)** — `senior_full_stack` сверяется перед изменением старого модуля
-- **REV (secondary)** — `reviewer` применяет при ревью PR в зрелой кодовой базе
-
-Активация через триггеры фронтматтера (`legacy код`, `мёртвый код`, `лава-флоу`, `неубранный feature flag`, `brownfield рефакторинг`, и т.д.). См. `$mcp-integration` для общего MCP-flow, gate ritual и recording discipline.
-
-Section IDs (`LF-01..LF-25`) — стабильные якоря: цитируй их inline в ARCH/REV артефактах вместо копирования содержания. Сохраняет audit trail компактным и обеспечивает обратную ссылку на канонический источник.
+---
+name: lava-flow-legacy-detection
+description: Чек-лист признаков "лава-флоу" в legacy/brownfield коде — мёртвый код вокруг живого, не убранные feature flags, окаменевшие workarounds, дубликаты после миграций. Используй при анализе текущего состояния репозитория, перед рефакторингом и при ревью PR в зрелой кодовой базе. Активируй при упоминаниях "legacy", "технический долг", "brownfield", "почему этот код здесь".
+type: reference
+domain: development
+owners:
+  - architect
+  - reviewer
+  - senior_full_stack
+gates:
+  - ARCH
+  - DEV
+  - REV
+tech: []
+topic:
+  - architecture
+  - refactoring
+  - legacy
+triggers:
+  - легаси код
+  - мёртвый код
+  - лава-флоу
+  - неубранный feature flag
+  - brownfield рефакторинг
+  - окаменевший workaround
+  - неиспользуемый код
+related:
+  - current-state-analysis
+  - architecture-compliance-review
+  - architecture-doc-reference
+  - design-patterns-reference
+  - adr-log
+  - adr-log-reference
+  - threat-model-baseline
+  - security-baseline-dev
+  - code-review-checklist
+  - system-design-checklist
+budget_lines: 250
+schema_version: 1
+---
+
+
+# Skill: Lava Flow Legacy Detection
+
+Анти-паттерн «лава-флоу» (Brown et al., *AntiPatterns*, 1998) — застывшая масса кода, попавшая в продакшен без должного контроля. Никто не помнит, зачем она тут, удалить страшно (нет тестов), переписать дорого. С каждым релизом слой утолщается.
+
+> **Когда применять:** ARCH (current-state analysis), DEV (перед изменением старого модуля), REV (ревью PR в зрелой кодовой базе). Reference-скил — активация через триггеры фронтматтера; см. § MCP integration ниже для cross-gate потребления.
+
+**Разделы:**
+1. [Признаки лава-флоу](#1-признаки)
+2. [Чек-лист проверки](#2-чеклист)
+3. [Что делать с находкой](#3-что-делать)
+4. [Что НЕ делать](#4-чего-избегать)
+5. [Шаблон отчёта](#5-отчёт)
+
+---
+
+## 1. Признаки
+
+### 1.1 Структурные
+
+| # | Признак | Как обнаружить |
+|---|---------|----------------|
+| LF-01 | Закомментированные блоки кода в продакшен-файлах | grep по `//` / `/*` блокам >5 строк |
+| LF-02 | Ветки кода, которые никогда не выполняются | покрытие тестами / coverage report 0% на ветке |
+| LF-03 | Функции/классы без входящих ссылок | static analysis (ts-prune, knip, unimport) |
+| LF-04 | Параллельные «версии» одной логики (v1/v2/legacy/new) | grep по суффиксам имён |
+| LF-05 | Дубликаты после неоконченных миграций | сравнить директории `old/`, `legacy/`, `deprecated/` |
+| LF-06 | Файлы без изменений дольше половины возраста репозитория | `git log -1 --format=%cd -- <file>` или `find <dir> -name '*.ts' -mtime +<дней>` |
+
+### 1.2 Конфигурационные
+
+| # | Признак | Как обнаружить |
+|---|---------|----------------|
+| LF-07 | Feature flags, которые всегда `false` (или всегда `true`) | grep по `flag.*= false`, проверить usage в коде |
+| LF-08 | Конфиг-ключи, которые никто не читает | grep значения ключа по кодовой базе |
+| LF-09 | Env-переменные, которые не упомянуты в `.env.example` | diff между `process.env.X` и `.env.example` |
+| LF-10 | Захардкоженные mock/stub данные на продакшен-пути | grep по `MOCK_`, `STUB_`, `fake_`, `dummy_` |
+
+### 1.3 Поведенческие
+
+| # | Признак | Как обнаружить |
+|---|---------|----------------|
+| LF-11 | Воркараунды, ставшие постоянными | grep по `TODO`, `FIXME`, `HACK`, `XXX` старше 6 мес |
+| LF-12 | Захардкоженные version/environment checks на мёртвое окружение | grep по `if.*IE`, `if.*v1`, `if.*LEGACY` где правая сторона больше не существует |
+| LF-13 | Неактивные cron jobs / scheduled tasks | `crontab -l` + grep логов за 3 мес; `systemctl list-timers --all`; `kubectl get cronjob -o wide` (lastScheduleTime) |
+| LF-14 | Endpoints без вызовов из фронта/других сервисов | grep route paths по всему монорепо |
+| LF-15 | Маршруты в роутере, ведущие на 404 или пустые компоненты | unit test обходом всех routes |
+
+### 1.4 Примеры в коде
+
+**Лава** — закомментированный fallback на удалённую систему:
+
+```ts
+// Старый auth flow до миграции на Auth0 (2024)
+// if (legacyAuth.enabled) {
+//   const session = await legacyAuth.login(creds);
+//   return mapLegacySession(session);
+// }
+const session = await auth0.login(creds);
+```
+> `legacyAuth` модуль удалён 18 мес назад. Комментарий — окаменелость, история уже в git. **Решение:** удалить.
+
+**Не лава** — комментарий объясняет неочевидное (Chesterton's fence):
+
+```ts
+// +1 потому что Date.getMonth() возвращает 0-11.
+// Если кто-то «поправит» на getMonth() — поломает отчёты по январю.
+const month = date.getMonth() + 1;
+```
+> Комментарий несёт смысл, защищает код от ложно-очевидной правки. **Решение:** оставить.
+
+---
+
+## 2. Чеклист
+
+Применять перед рефакторингом модуля или при первом погружении в legacy-репозиторий.
+
+- [ ] Прогнать `ts-prune` / `knip` / эквивалент → собрать список unreachable
+- [ ] Прогнать coverage на затрагиваемых файлах → отметить 0%-ветки
+- [ ] `git log --since=24.months.ago -- <file>` → выявить «застывшие» файлы
+- [ ] Найти все `TODO/FIXME/HACK` старше 6 месяцев → решить: fix или delete
+- [ ] Перечислить feature flags в проекте → для каждого проверить, меняется ли значение
+- [ ] Перечислить env-переменные → пометить unused
+- [ ] Для каждой подозрительной функции — найти все usages → если 0, помечать к удалению
+- [ ] Зафиксировать находки в отчёте (формат ниже) до начала рефакторинга
+
+---
+
+## 3. Что делать
+
+**Принцип:** удаление лава-флоу — отдельная задача, не часть фичевого PR. **Перед удалением — `git blame` на блок.** Если автор активен в команде — спросить контекст (часто экономит часы и предотвращает удаление чего-то скрыто-полезного). Если автор ушёл или код старше ~24 мес — `git blame` только археология, ходить дальше по чеклисту.
+
+1. **Отчёт ДО изменений.** Перечислить находки в отдельном документе (`docs/reports/architect/lava-flow-<module>.md`). Без согласования архитектора не удалять.
+2. **Тестовое покрытие ПЕРЕД удалением.** Если ветка не покрыта тестами — сначала характеризационные тесты (Working Effectively with Legacy Code, M. Feathers), потом удаление.
+3. **Малыми PR.** Один PR = одна находка. Не «удалить весь deprecated/». Атомарность даёт ясную точку отката.
+4. **Feature flag → удалить «выключенную» сторону.** Если флаг 100% в одном положении дольше 1 релиза — удалять противоположную ветку. **НО:** если флаг переключался хотя бы раз за последний релиз — это live config, не лава; не трогать (Chesterton's fence — кто-то им активно пользуется).
+5. **ADR при сомнениях.** Если непонятно, зачем код существует — `$adr-log` с вариантами «удалить / оставить / переписать», эскалация на Architect.
+
+---
+
+## 4. Чего избегать
+
+- ❌ **«Заодно почищу»** — лава-флоу не убирается ad-hoc внутри фичевого PR. Размывает diff, ломает ревью.
+- ❌ **Массовое удаление без тестов** — характеризационные тесты обязательны для непокрытых веток.
+- ❌ **Переименование вместо удаления** — `_old`, `_deprecated_v2` создают новый слой лавы.
+- ❌ **Комментарий «потом разберёмся»** — это та же лава, только в зародыше. Решение сейчас: delete или ADR.
+- ❌ **Сохранение «на всякий случай»** — git history — это уже архив.
+
+---
+
+## 5. Отчёт
+
+```markdown
+# Lava Flow Report — <module-name>
+
+**Дата:** <YYYY-MM-DD>
+**Автор:** <agent>
+**Контекст:** <зачем смотрели — refactor / current-state / review>
+
+## Находки
+
+| # | ID | Файл/строка | Признак | Решение |
+|---|----|-------------|---------|---------|
+| 1 | LF-01 | src/foo.ts:120-180 | Закомментированный блок 60 строк | DELETE (PR #N) |
+| 2 | LF-07 | src/config/flags.ts:42 | Флаг `useNewAuth` = false уже 8 мес | DELETE old branch (PR #N+1) |
+| 3 | LF-04 | src/api/users-v1.ts | Дубликат users-v2.ts, никем не используется | DELETE (ADR-DEV-XXX) |
+
+## Эскалации
+- <если есть случаи, где нужен sign-off Architect'а/пользователя>
+
+## План закрытия
+- <разбивка на PR с порядком>
+```
+
+---
+## Ссылки на смежные навыки
+
+- `$current-state-analysis` — общий аудит репозитория, лава-флоу — один из его выходов
+- `$architecture-compliance-review` — проверка соответствия архитектуре после удаления
+- `$design-patterns-reference` — что использовать ВМЕСТО удалённой лавы
+- `$code-review-checklist` — на этапе ревью PR с удалением
+- `$system-design-checklist` — чтобы новый код не стал следующей лавой
+
+---
+
+## MCP integration (cross-gate activation)
+
+Reference-скил с cross-gate потреблением:
+
+- **ARCH (primary)** — `architect` использует в current-state analysis перед предложением рефакторинга
+- **DEV (secondary)** — `senior_full_stack` сверяется перед изменением старого модуля
+- **REV (secondary)** — `reviewer` применяет при ревью PR в зрелой кодовой базе
+
+Активация через триггеры фронтматтера (`legacy код`, `мёртвый код`, `лава-флоу`, `неубранный feature flag`, `brownfield рефакторинг`, и т.д.). См. `$mcp-integration` для общего MCP-flow, gate ritual и recording discipline.
+
+Section IDs (`LF-01..LF-25`) — стабильные якоря: цитируй их inline в ARCH/REV артефактах вместо копирования содержания. Сохраняет audit trail компактным и обеспечивает обратную ссылку на канонический источник.