Boyko Method

---
name: boyko-method
description: "Полный цикл сквозного анализа сложных систем с ≥3 взаимодействующими компонентами: Атомизация → Линзы → Связи с evidence-метками → Сборка → Фальсификация. Оркестрирует /multi-lens (линзы), /skeptic + falsification-ladder (проверка), /estimand-ops (научные claims). Использует confidence-labeled dependency map с [VERIFIED]/[INFERRED]/[WEAK]/[РАЗОРВАНА] на каждой связи. Применяй для: архитектурных решений, научных гипотез, production-багов, регуляторных workflows, антифрода, любого объекта где broken links — главная находка. Триггеры: '/boyko', 'метод бойко', 'полный разбор', 'разложи и собери', 'системный анализ от и до', 'построй модель проблемы', 'атомизируй и проверь', 'evidence-labeled analysis'. НЕ для: простого вопроса с одним ответом, быстрого фикса, поиска факта."
allowed-tools: Read, Grep, Glob, Bash(git log:*), WebSearch
context: fork
version: "1.4.0"
---

# Метод Бойко — сквозной цикл «проблема → проверяемая модель»

Сложную систему нельзя надёжно понять с одной точки зрения и одним махом. Метод проводит объект через 5 этапов, превращая мутное в проверяемое. **Это оркестратор:** этапы Линзы и Проверка делегируются готовым скиллам — не дублируй их.

```
Объект → Атомизация → Линзы → Связи → Сборка → Гипотезы → Проверка → Уточнение
```

## Режимы запуска

| Режим | Команда | Время | Что даёт |
|---|---|---|---|
| **Quick** | `/boyko quick: <объект>` | ~10 мин | Только Атомизация + Связи + 3 ключевые гипотезы |
| **Standard** | `/boyko <объект>` | ~30 мин | Полный 5-этапный цикл |
| **Deep** | `/boyko deep: <объект>` | ~60 мин | Full + multi-lens по каждому атому + skeptic на все гипотезы |

**Output caps — жёсткие лимиты по режиму:**

| Режим | Макс. атомов | Макс. связей | Макс. гипотез |
|---|---|---|---|
| Quick | 8 | 20 | 3 |
| Standard | 20 | 60 | 7 |
| Deep | 40 | 120 | 12 |

Превышаешь лимит → агрегируй атомы в группы, не добавляй новые. Цель: модель, а не энциклопедия.

---

## Feasibility Gate (запустить ПЕРВЫМ — до старта любого режима)

Три вопроса. Если хоть один — «нет» → бери точечный скилл, не запускай полный цикл.

```
1. Объект сложный? (≥3 взаимодействующих компонента / нелинейные зависимости)
   → НЕТ: один вопрос → используй /multi-lens (только линзы) или /skeptic (только фальсификация)

2. Цена ошибки высока? (архитектурное решение / научный claim / production баг)
   → НЕТ: быстрый фикс → без метода вообще

3. Есть конкретный объект? (не "расскажи о теме X", а конкретная система/гипотеза/проблема)
   → НЕТ: уточни границы объекта, только потом запускай
```

**Quick-режим** — минимальный порог: объект сложный + цена ошибки средняя. Для высокой — Standard или Deep.

---

## Этап 1 — Атомизация (разложить на минимальные единицы)

Раздроби объект на «атомы анализа»: объект · функция · переменная · процесс · состояние · переход · связь · причина · следствие · ограничение · риск · ошибка · ресурс · сигнал · решение · допущение.

**Правило глубины:** дроби, пока атом не станет проверяемым/изменяемым по отдельности. Глубже — лишнее.

```markdown
| Атом | Тип | Описание | Почему важен | Чёткость формулировки |
```

**Чёткость формулировки** (заимствовано из внешнего Universal Project Atomizer, 2026-07-24) —
HIGH/MEDIUM/LOW про то, **насколько ясно атом сформулирован в источнике**, а НЕ про то,
насколько он вероятно истинен. Это отдельная ось от evidence-меток Этапа 3
(`[VERIFIED]`/`[INFERRED]`/`[WEAK]`/`[РАЗОРВАНА]`): атом может быть сформулирован предельно
чётко (HIGH) и при этом оказаться ложным, или быть смутно намекнут (LOW) и при этом верным.
Путать эти две оси — типичная ошибка: «звучит уверенно» ≠ «доказано».

**Формулы и числа — отдельный мини-реестр** (если объект их содержит): для каждой
формулы/численного утверждения зафиксируй роль — `fitted` (подобран под данные) ·
`derived` (выведен аналитически) · `measured` (независимое измерение) · `assumed` (взят как
допущение без вывода). Не смешивай fitted-параметр и independent prediction в одном атоме —
это ровно тот же Тип 2 класс ошибок («FITTED vs DERIVED»), что уже описан в
`research-methodology.md` § Классификатор источников ошибок, только здесь применяется на
уровне отдельного атома при разложении, а не постфактум при аудите.

---

## Этап 2 — Линзы (рассмотреть каждый атом с разных сторон)

**→ Делегируй скиллу `multi-lens`.** Прогони ключевые атомы через релевантные из 20 линз (логическая, причинная, системная, риск, антихрупкая…). Не переписывай каталог линз здесь — вызови `/multi-lens`.

В **Quick-режиме**: пропусти этот этап или возьми 2-3 линзы вручную без делегирования.

Выход линз: `Атом → Линза → Вопрос → Наблюдение → Гипотеза`.

---

## Этап 3 — Связи (построить карту зависимостей)

Найди связи между атомами. **Дисциплина доказательности (обязательно):** каждая связь несёт тег уровня уверенности И колонку «Как проверить». Связь без доказательства — это `[предположение]`, не факт.

**Строгие критерии — ставь метку только если выполнен критерий:**

| Метка | Критерий (требуется ДО постановки) |
|---|---|
| `[VERIFIED]` | Воспроизводимый тест, лог, документ, расчёт или цитата — **источник указан явно** (`file:line` или URL) |
| `[INFERRED]` | Логически выведена из ≥2 верифицированных фактов — **цепочка написана явно** |
| `[WEAK]` | Правдоподобно, но ≤1 источник или механизм неполный — **не использовать в решениях** |
| `[РАЗОРВАНА]` | Связь **заявлена** в тексте/архитектуре/документе, но доказательства нет — механизм отсутствует или не проверялся |

`[РАЗОРВАНА]` ≠ плохо. Это часто важнейшая находка: система притворяется связной, а на деле — нет.

**Fallback если `/multi-lens` недоступен:** пропусти Этап 2 или возьми 3 линзы вручную (логическая, причинная, риск) без делегирования.

```markdown
| Элемент A | Тип связи | Элемент B | Механизм | Уверенность | Как проверить |
```

**Заполненный пример (architecture review):**

| Элемент A | Тип связи | Элемент B | Механизм | Уверенность | Как проверить |
|---|---|---|---|---|---|
| hook_latency | причинная | user_perceived_lag | PostToolUse хук блокирует ответ Claude | [VERIFIED] | `time curl` до/после хука |
| plugin.json trigger | функциональная | skill_visibility | SessionStart парсит trigger поле | [INFERRED] | сравнить plugin.json видимых vs невидимых скиллов |
| null_results/INDEX.md | информационная | experiment_decisions | UserPromptSubmit читает INDEX перед стартом | [WEAK] | grep hook_trigger.jsonl на null_retroscan |
| FRAP_parameters | причинная | TAD_boundary_model | loop_extrusion_rate fitted to FRAP | **[РАЗОРВАНА]** | FRAP-данных нет в репо — связь заявлена, не верифицирована |

**Ищи особо:**
- **Петли обратной связи** — A усиливает B, B усиливает A
- **Ключевые узлы** — атом с ≥4 исходящими связями → точка отказа
- **РАЗОРВАННЫЕ связи** — заявлена, но доказательства нет → часто важнейшая находка

Типы связей: причинная · функциональная · временна́я · логическая · информационная · ресурсная · обратная связь · скрытая зависимость.

---

## Этап 4 — Сборка (собрать модель целого)

Из атомов → механизмы → модули → процесс → модель системы. Не просто список — **связная модель** с входами/выходами, точками управления и точками отказа.

```markdown
| Атомы | Механизм | Модуль | Роль в системе | Точка отказа |
```

**Анти-цель — ложная целостность.** Обязательно: явно перечисли **≥1 `<неизвестную зону>`**. Если их ноль — это red flag: модель слишком гладкая, ты что-то замазал.

Сильнейший выход этого этапа — **переопределение объекта** (напр. «это фильтр приоритизации, а НЕ предсказатель» — меняет всю интерпретацию).

---

## Этап 5 — Проверка (фальсифицировать модель)

**→ Делегируй `skeptic` + `falsification-ladder` (+ `estimand-ops` для research).** Не изобретай проверку — построй гипотезы и отдай их на разлом.

Каждая гипотеза в форме:
```
Если [причина/условие], то [следствие], потому что [механизм].
Проверка: [метод]. Подтверждается если [критерий]. Опровергается если [критерий].
```

**Если гипотез ≥2 одновременно живых** (не одна уточняемая версия, а реально конкурирующие) — используй `experiments/_template/ach_matrix.md` (Analysis of Competing Hypotheses): гипотезы × evidence, приоритет тестам, которые различают гипотезы, а не подтверждают все сразу. Опционально, только при ≥2 живых.

**Degeneracy-чек (обязателен при большом эффекте):** если видишь подозрительно сильный результат (Cohen d>2, F1>0.95, R²>0.99) — первый вопрос не «как хорошо!», а **«что вырождается?»**. Часто эффект завышен схлопыванием одного распределения в точку. Это требует оговорки — иначе рецензент/реальность поймают первыми.

Затем `/skeptic` на сильнейшие гипотезы (context asymmetry). Для научных — FL Full + estimand.

---

## Выход (обязательный формат)

```markdown
## 1. Объект и цель / границы
## 2. Атомы (таблица)
## 3. Линзы (из multi-lens, или краткие в quick-режиме)
## 4. Карта связей (таблица с уровнями уверенности)
## 5. Модель целого (+ ≥1 неизвестная зона)
## 6. Проверяемые гипотезы (с критерием опровержения)
## 7. План проверки (skeptic / FL / эксперимент)
## 8. Что результат НЕ будет значить
```

---

## Дисциплина честности (из integrity.md)

Разделяй: **факт** (проверяемое наблюдение) · **гипотеза** (с критерием опровержения) · **допущение** (явно помечено) · **неизвестная зона**. Не выдавай сборку за доказанную модель — она верна лишь до проверки на этапе 5.

**No-Verification-Leak Gate** (заимствовано из внешнего Universal Project Atomizer, 2026-07-24) —
на Этапах 1-4 (Атомизация → Линзы → Связи → Сборка), ДО этапа Проверки, запрещены формулировки,
выдающие вердикт об истинности раньше времени:
- «это верно» / «это ошибочно» / «теория доказана» / «модель опровергнута» / «автор неправ»

Допустимо только описывать, что заявлено и на чём это основано:
- «автор утверждает» / «в источнике это основано на» / «атом зависит от» /
  «доказательство не приведено» (≠ «доказательство отсутствует в природе» — только «не приведено здесь»)

Нарушение этого правила на Этапах 1-4 — типичный способ незаметно протащить вывод Этапа 5
(Проверка) внутрь того, что должно быть нейтральной картой содержания.

---

## Чем НЕ является

Не замена `skeptic`/FL/estimand — он их **вызывает** на нужных этапах. Не для простых задач. Не «новая наука» — это операционная сборка системного мышления + декомпозиции + причинного моделирования + фальсификации в один воспроизводимый маршрут.

---

## Связанные скиллы (оркестрация)

| Этап | Скилл |
|---|---|
| Линзы | `multi-lens` |
| Проверка | `skeptic`, `falsification-ladder` (rule), `estimand-ops` (rule) |
| Конкурирующие гипотезы | `hypothesis-arbiter` |
| Доказательная база | `consilience` |

---

*Version: 1.4.0 — точечно заимствовано из внешнего Universal Project Atomizer (сравнили,
дублирования не нашли, взяли 3 узкие идеи вместо целого нового скилла): (1) «Чёткость
формулировки» как отдельная от evidence-меток ось в Этапе 1 — ясность текста ≠ истинность;
(2) formula/numbers мини-реестр с ролью (fitted/derived/measured/assumed) в Этапе 1; (3)
No-Verification-Leak Gate — запрещённые/допустимые формулировки на Этапах 1-4, до Проверки.*

*Version: 1.3.0 — добавлены: context: fork в frontmatter, output caps по режимам, строгие evidence criteria для каждой метки (VERIFIED/INFERRED/WEAK/РАЗОРВАНА), fallback при недоступности /multi-lens, улучшен description для автороутинга*