code-quality — Ветки A+, B, C: подгруппы, частичный анализ, субъективный обзор

Часть skill'а code-quality. Условия запуска, развилка по размеру, формат вывода и жёсткие правила — в SKILL.md; полный канон ветки A — в references/detailed-canon.md. Этот файл читается целиком при соответствующей ветке.

Ветка A+ — разбиение на подгруппы

Условие: 3000–12000 LOC, естественное деление на 2–4 группы ≤3000 LOC каждая.

Предложение разбиения

Перед запуском анализа вывести структуру разбиения с обоснованием:

Предлагаю разбить <target> (X LOC) на N групп:
- Группа 1 — <название> (Y₁ LOC): <состав, обоснование>
- Группа 2 — <название> (Y₂ LOC): <состав, обоснование>
- Группа 3 — <название> (Y₃ LOC): <состав, обоснование>

Сумма: Y₁+Y₂+Y₃ = X ✓ (все < 3000)

Каждая группа = отдельный полный анализ по канону (ветка A).
Итоговые баллы — среднее по всем группам, флаги — объединение с дедупом.
Подтвердить?

Дождаться подтверждения. Без подтверждения — не запускать.

Критерий «естественности» деления:

  • группы соответствуют разным зонам ответственности (ядро vs контракты vs реализации; разные типы данных; разные бэкенды);
  • классы одной зоны ответственности не разрезаются между группами (если ManagerX в G1, MetadataX и StateX тоже в G1);
  • базовые классы и контракты идут в более раннюю группу, реализации — в более позднюю.

Если группы неровные (одна 2900, другие по 100) — деление искусственное, лучше ветка B.

Параллельный запуск

Agent (subagent_type=general-purpose, model=sonnet) × N
  prompt: «Полный анализ группы по канону code-quality
           (references/detailed-canon.md):
           файлы [...], шаги 0–5, формат вывода — структурированный markdown
           с разделами Инвентарь / Формулы / Pre-check / Архитектурные маркеры
           / Red / Yellow / Итог»
  run_in_background: true

Каждый агент должен вернуть по канону detailed-canon.md полный отчёт со всеми категориями и обнаруженными маркерами. Никаких сокращений.

Сведение результатов

Усреднение баллов по категориям

Документируемость = avg(D₁, D₂, …, Dₙ)
Масштабируемость  = avg(S₁, S₂, …, Sₙ)
Поддерживаемость  = avg(M₁, M₂, …, Mₙ)
Производительность = avg(P₁, P₂, …, Pₙ)

Базовый = (D/10 + S/10 + M/10 + P/20) / 3.5 × 10

Дедуп архитектурных маркеров

Маркер идентифицируется типом (Ложная точка расширения, Кустовая обязательность, Смешение Model/View, Fat Interface, Перегруженность настроек, Discoverability), не конкретным проявлением.

  • Если один и тот же тип маркера найден в G1, G2, G3 — это 1 маркер в arch, но в отчёте перечислить все проявления.
  • Если в одной группе Fat Interface — это IActor, в другой — ITextPrinterActor, это всё равно 1 маркер «Fat Interface», просто с двумя проявлениями.
  • Никакой systemic-поправки нет: повторение типа в нескольких группах счётчик не умножает.

Дедуп red-флагов

Аналогично — по типу (cyclo>20, DIT>5, Fat Interface, new в Update, GetComponent в кадре, >30 полей в endpoint, async void). Без мультипликации за повтор.

Yellow-флаги

Объединение всех проявлений по группам без дедупа (информационно). В множитель не идут.

Итоговая формула

Итог = Базовый × 0.5^arch_dedup × 0.9^red_dedup

Где arch_dedup, red_dedup — счётчики после дедупа по типам.

Формат вывода

[Ветка A+] Сводная оценка <target>
- LOC: <total>
- Группы: G1 (Y₁), G2 (Y₂), G3 (Y₃)
- Применимость канона: полная (по подгруппам)

## Усреднённые баллы
| Категория | G1 | G2 | … | Среднее |
| ... |

## Объединённые арх. маркеры (дедуп)
| # | Маркер | Где зафиксирован |
| 1 | Ложная точка расширения | G1: …; G2: …; G3: … |
| ... |

## Объединённые red-флаги (дедуп)
…

## Объединённые yellow-флаги
…

## Итог
- Множитель: 0.5^arch × 0.9^red = …
- Базовый: X
- Итог: X
- Интерпретация: <по шкале>

## Диагностический сигнал
<если разрыв Базовый ↔ Итог большой — комментарий>

Ветка B — частичный анализ (с предупреждением)

Условие: 3000–10000 LOC.

Перед началом ОБЯЗАТЕЛЬНО вывести:

⚠️ Предупреждение: объём кода превышает порог детального анализа (>3000 LOC). Количественные метрики (формулы 1.x–4.x) применимы, но архитектурные маркеры могут быть пропущены — async void, ложная расширяемость, Fat Interface требуют построчного чтения, которое на этом объёме неполное. Оценка достоверна по формулам; маркеры — выборочно.

Затем:

  1. Применить формулы количественно (detailed-canon.md — все категории 1.x–4.x).
  2. Маркеры архитектурных проблем — прогнать выборочно через grep'ы (detailed-canon.md: pre-check 3.3 + быстрые grep'ы 3.6):
    • async void в публичных методах.
    • Интерфейсы с >15 членами.
    • Цепочки as ConcreteType.
    • Прямые вызовы GetService<Concrete> минуя интерфейс.
  3. Red-flag чек-лист (detailed-canon.md) — только grep-проверяемые пункты.
  4. Итоговую формулу (detailed-canon.md, 3.7) применять, в выводе явно маркировать «оценка частичная, маркеры могут быть пропущены».

Делегирование: все grep-прогоны и подсчёты — через дешёвого агента (Explore или general-purpose с model=haiku). Основной контекст агрегирует только числа.


Ветка C — субъективный обзор (с предупреждением)

Условие: >10000 LOC.

Перед началом ОБЯЗАТЕЛЬНО вывести:

❌ Предупреждение: объём кода (X LOC) превышает порог применимости канона. На этом объёме LLM скатывается в каталогизацию вместо анализа: пропускает async void, ложную расширяемость, Fat Interface, скрытые контракты. Корректная оценка по формулам невозможна в одну сессию.

Доступно только субъективное мнение об архитектуре — без чисел, без формул, без баллов. Это НЕ оценка качества по канону.

Для корректной оценки — разбить скоуп на отдельные пакеты ≤3000 LOC и оценивать каждый по очереди.

Затем спросить:

«Продолжить с субъективным обзором (с явной маркировкой что это мнение, не оценка), или предпочтёте разбить на пакеты для детального анализа?»

Если пользователь выбрал субъективный обзор:

  1. Не выводить никаких числовых оценок по формулам канона.
  2. Дать качественные наблюдения по архитектуре с явной шапкой «Субъективный обзор, не оценка по формулам».
  3. Опционально перечислить grep-обнаруживаемые красные флаги (с пометкой что это не полная картина) — через дешёвого агента (быстрые grep'ы, detailed-canon.md).
  4. Финальный вывод — рекомендация какие подсистемы стоит оценить детально по канону отдельно.