Research Audit

---
name: research-audit
sub_type: pipeline
description: >
  [STATUS: active] [CONFIDENCE: high]
  Полный мета-аудит исследовательского проекта — читает ВСЕ артефакты за всё время
  (null_results, parked, experiments, pearl_registry, ALIVE_BRANCHES) и выдаёт:
  хронологическую карту решений, паттерн отказов, zombie-гипотезы, gap-анализ,
  стратегический вердикт и следующий тест.
  Цель: увидеть полную картину — что сделано, что убито, что пропущено, куда идти.
  Триггеры: /research-audit, "посмотри весь проект", "что мы упускаем", "полная картина",
  "мета-анализ экспериментов", "review all experiments", "куда двигаться дальше",
  "есть ли что-то что мы не проверили", "zombie гипотезы", "паттерн отказов"
  НЕ использовать для: аудита одного эксперимента (/skeptic), одной сессии (/session-retrospective),
  поиска новых гипотез (/sci-hypothesis)
effort: high
tokens: ~1500
---

<!-- BSV — Brief Skill View | поиск: BSV
Скил   : research-audit
TL;DR  : Мета-аудит ВСЕХ экспериментов — карта, паттерн отказов, gaps, zombies, стратегия
Вызов  : /research-audit, /research-audit --gaps, /research-audit --pattern, /research-audit --next
НЕ для : Аудит одного эксперимента (→ /skeptic) или одной сессии (→ /session-retrospective)
-->

# Research Audit — Полный Мета-Аудит Исследования

## Зачем этот скил

Большинство инструментов работают с ОДНИМ артефактом: один claim, одна сессия, один эксперимент.
**Research Audit** работает с ВСЕМ что накопилось за всё время — и находит то, что видно только с высоты.

**Три вещи видимые только с высоты:**
1. **Паттерн отказов** — что раз за разом убивает гипотезы (общий корень, не случайность)
2. **Слепые пятна** — что ни разу не проверялось, но подразумевается верным
3. **Зомби-гипотезы** — убитые формулировки которые возвращаются в новой одежде

**Ключевое правило:** главная информация содержится в ОТКАЗАХ, не в успехах. Читай null_results первым.

---

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

```
/research-audit              — полный аудит (все 6 фаз, рекомендуется)
/research-audit --scan       — только инвентаризация артефактов (5 мин, без анализа)
/research-audit --gaps       — фокус на gap-анализе (что не проверено)
/research-audit --pattern    — фокус на паттернах отказов
/research-audit --next       — только следующий тест (cheapest differentiating)
/research-audit --zombie     — только поиск zombie-гипотез
/research-audit [path]       — аудит конкретного проекта по пути
```

---

## Алгоритм (6 фаз)

### Фаза 0 — Структурный скан (ОБЯЗАТЕЛЬНАЯ, всегда первая)

Перед любым содержательным чтением — определи что РЕАЛЬНО существует:

```bash
# Проверить наличие FL-артефактов:
ls -la null_results/ 2>/dev/null && echo "NULL_RESULTS: YES" || echo "NULL_RESULTS: NO"
ls -la parked/ 2>/dev/null && echo "PARKED: YES" || echo "PARKED: NO"
ls -la experiments/ 2>/dev/null && echo "EXPERIMENTS: YES" || echo "EXPERIMENTS: NO"
ls -la pearl_registry/ 2>/dev/null && echo "PEARL_REGISTRY: YES" || echo "PEARL_REGISTRY: NO"
ls ALIVE_BRANCHES.md 2>/dev/null && echo "ALIVE_BRANCHES: YES" || echo "ALIVE_BRANCHES: NO"
ls *.md 2>/dev/null | head -20  # корневые markdown файлы
ls .claude/memory/*.md 2>/dev/null | head -10  # memory файлы

# Для hybrid проектов с несколькими треками — рекурсивный поиск null_results:
find . -name "INDEX.md" -path "*/null_results/*" 2>/dev/null
```

**Классифицируй тип проекта:**

| Признаки | Тип | Что делать |
|----------|-----|-----------|
| experiments/ + null_results/ + parked/ | **Research** | Полный FL-аудит |
| hooks/ + agents/ + src/ без experiments/ | **Software** | Аудит через decisions.md + PRы + git log |
| Obsidian vault (много .md без кода) | **Knowledge base** | Аудит через wiki index + daily notes |
| Оба признака | **Hybrid** | Аудировать обе части раздельно |

**Hybrid multi-track:** если проект имеет несколько независимых треков (Track A / Track B), каждый в своей подпапке — найти null_results/INDEX.md в КАЖДОЙ подпапке. Аудировать каждый трек отдельно, затем синтезировать.

**Если нет никаких FL-артефактов** — скажи честно: "Проект не имеет FL-структуры. Research audit невозможен в стандартном режиме." Затем предложи адаптацию: git history как timeline, issues как experiments, comments как kill analysis.

---

### Фаза 1 — Загрузка артефактов

**Читать в этом порядке (от наиболее информативного к контексту):**

```
1. null_results/INDEX.md              ← ГЛАВНЫЙ ИСТОЧНИК: всё убитое за всё время
   (для multi-track: найди ВСЕ null_results/INDEX.md рекурсивно)
2. parked/INDEX.md                    ← потенциальные zombie, Revival Conditions
   (альтернатива: ALIVE_BRANCHES.md — читай если parked/ не существует)
3. activeContext.md / .claude/memory/activeContext.md  ← текущая цель и состояние
4. experiments/*/decision.md          ← вердикты по каждому эксперименту
5. ALIVE_BRANCHES.md  (если есть)    ← текущие живые ветки со статусами
6. pearl_registry/INDEX.md           ← непрочитанные инсайты по пути
7. .claude/memory/goals.md           ← стратегические цели
8. README.md / CLAUDE.md             ← контекст и рамка проекта
```

**Правила чтения:**

- Если файл > 200 строк → читай только таблицу/индекс, не каждый подфайл
- Если нет null_results/INDEX.md → `grep -rl "REJECT\|FALSIFIED" experiments/` как замена
- Если нет parked/INDEX.md → проверь ALIVE_BRANCHES.md; если нет и его → `grep -rl "ARCHIVE\|parked" experiments/`
- Если нет структурированных файлов → `git log --oneline -50` + `git diff HEAD~50..HEAD --stat`
- **ALIVE_BRANCHES.md** — это living hypothesis tracker (паттерн используется в проектах с большим числом открытых веток). Содержит: ID → статус (OPEN/OPEN_CONDITIONAL/CLOSED) → Revival Condition. Читай вместо parked/ если parked не существует.

**Запрещено:** начинать анализ не прочитав null_results (или его эквивалент). Это не опция.

---

### Фаза 2 — Построение хронологической карты

Восстанови временную линию всех экспериментов.

**Для КАЖДОГО эксперимента:**

| ID | Дата (если есть) | Claim (одна строка) | Вердикт | Причина смерти | Что выжило |
|----|-----------------|---------------------|---------|----------------|------------|
| g54 | 2026-05-xx | [claim] | REJECT | [constraint] | [mechanism] |
| g55 | 2026-05-xx | [claim] | PROMOTE | — | [what confirmed] |
| ... | ... | ... | ... | ... | ... |

**Правило:** НЕ суммаризируй в таблице — строй точную запись. Потеря деталей = потеря gap-анализа.

**Если экспериментов > 30:** сначала только ID + вердикт + причина смерти. Детали — только для PROMOTED и для экспериментов с нестандартной причиной смерти.

**Если экспериментов > 50 в multi-track проекте:** группируй по треку, затем хронологически внутри трека. Это предотвращает смешение несовместимых контекстов (Track A: численный; Track B: алгебраический — разные failure modes, разные patterns).

```
Track A — [название]
| ID | Claim | Вердикт | Причина |
...

Track B — [название]
| ID | Claim | Вердикт | Причина |
...
```

---

### Фаза 3 — Паттерн-анализ

#### 3.1 Паттерн отказов (самое важное)

Сгруппируй null_results по причине смерти:

```
Причина А: [список ID] — что общего между ними?
Причина Б: [список ID] — что общего?
Причина В: [список ID] — ...
```

**Ключевой вопрос:** есть ли один общий корень у большинства отказов?

- ДА → это либо фундаментальное ограничение (надо принять и двигаться вокруг него), либо системная ошибка в дизайне тестов (надо исправить методологию)
- НЕТ → отказы разнородны, это нормально — исследование идёт по разным направлениям

#### 3.2 Паттерн успехов

Что выжило? Какие условия? Чем подтверждённые результаты отличались от убитых?

#### 3.3 Zombie-гипотезы (обязательная проверка)

Zombie = гипотеза которая:
1. Была убита (есть в null_results)
2. Вернулась в другой формулировке (в experiments или parked)
3. **Без нового Revival Condition** — то есть без принципиально нового основания для повторной попытки

**Проверка:** для каждой parked гипотезы — проверь, нет ли совпадения с null_results. Идентичность определяется не по словам, а по **логической структуре предположения**.

---

### Фаза 4 — Gap-анализ

#### 4.1 Непроверенные предположения (критический шаг)

Из всей картины — какие предположения лежат в основе МНОГИХ экспериментов, но **ни разу не тестировались напрямую?**

**Техника:** возьми каждый PROMOTED claim. Что должно быть верным ДОПОЛНИТЕЛЬНО чтобы он имел значение? Это — untested assumption.

**Пример:** если 5 экспериментов предполагают что "параметр λ константа", но ни один не проверял это напрямую — это critical untested assumption.

#### 4.2 Смежное пространство

Какие эксперименты логически следуют из PROMOTED results, но ещё не запущены?

Формула: "Если [PROMOTED claim] верен, то следующий тест должен проверять [X]."

#### 4.3 Pearl Registry audit

Если есть pearl_registry/INDEX.md:
- Есть ли pearls со статусом `pending` у которых прошёл `next_check` срок? → Потенциально потерянные инсайты
- Есть ли pearls с высоким `trigger_condition` который уже выполнен? → Нераскрытый потенциал

#### 4.4 Opportunity cost

Были ли случаи когда запустили **дорогой** эксперимент не проверив сначала **дешёвый**?

Признак: дорогой REJECT, + в его kill analysis написано "could have been caught earlier by [cheap check]".

#### 4.5 Внешние зависимости и блокеры

Gap-анализ различает два типа "не сделано":

| Тип | Описание | Как работать |
|-----|---------|-------------|
| **Независимый gap** | Нет логического блокера, просто не запустили | Прямой next test |
| **Внешний блокер** | Ждём автора / данных / коллаборации / инфраструктуры | Нужен альтернативный путь или deadline |

Для каждого pending/blocked эксперимента — задай вопрос: "Есть ли альтернативный путь к тому же знанию, не зависящий от внешнего источника?"

Если нет альтернативы → зафикисруй как `[EXTERNALLY_BLOCKED — ждём X]` в стратегическом вердикте.
Если есть альтернатива → приоритизируй её выше заблокированного пути.

---

### Фаза 5 — Стратегический вердикт

Ответь на 5 вопросов честно, без политкорректности:

**Q1: Главный вопрос проекта сформулирован falsifiably?**
YES / NO / PARTIAL — с обоснованием

**Q2: Текущее направление обосновано всей совокупностью evidence?**
YES / NO / PARTIAL — что конкретно говорит за и что против

**Q3: Есть ли zombie-гипотезы в активной работе прямо сейчас?**
[список конкретных ID или "не обнаружено"]

**Q4: Самое дешёвое следующее действие с наибольшей informational value?**
НЕ абстрактное направление, а конкретный тест — что именно проверить, каким методом, за какое время.
Различай явно: (a) **независимый тест** — можно запустить прямо сейчас; (b) **заблокированный внешним событием** — ждём X. Если (b), предложи альтернативный независимый тест пока ждём.

**Q5: "Что изменилось бы если бы начинал заново зная всё текущее?"**
Самый честный ответ. Может быть неудобным. Именно поэтому он ценен.

---

## Формат полного вывода

```markdown
## Research Audit — [Название проекта]

**Дата:** YYYY-MM-DD
**Артефакты:** X экспериментов · Y null results · Z parked · N pearls
**Тип проекта:** research / software / hybrid / knowledge-base

---

### 1. Хронологическая карта

| ID | Claim | Вердикт | Причина / Что выжило |
|----|-------|---------|---------------------|
...

---

### 2. Паттерн отказов

**Группа А — [название причины]:** [ID1, ID2, ID3]
- Общий корень: [что именно убивало]

**Группа Б — [название причины]:** [ID4, ID5]
- Общий корень: [...]

**Вывод:** [один общий корень? или разнородно?]

---

### 3. Подтверждённое ядро

**PROMOTED claims:**
- [claim 1] — выжил потому что [условие]
- [claim 2] — выжил потому что [условие]

**Общий паттерн успехов:** [что объединяет выжившие]

---

### 4. Zombie-гипотезы

[Список с объяснением почему это zombie — или "не обнаружено"]

---

### 5. Gap-анализ

**Непроверенные предположения (критические):**
- [assumption 1] — лежит в основе [N] экспериментов, никогда не тестировалось напрямую
- [assumption 2] — ...

**Следующие логические шаги из confirmed:**
- [step 1] — дешёвый тест: [описание]
- [step 2] — ...

**Просроченные pearls:**
- [pearl ID] — next_check [дата прошла], статус pending → требует внимания

**Opportunity cost:**
- [случай если был] — дорогой [ID] можно было предотвратить дешёвым тестом [X]

---

### 6. Стратегический вердикт

**Q1 (falsifiable?):** [YES/NO/PARTIAL] — [обоснование]
**Q2 (direction justified?):** [YES/NO/PARTIAL] — [за: ..., против: ...]
**Q3 (zombies active?):** [список / нет]
**Q4 (next test):** [конкретно — независимый или EXTERNALLY_BLOCKED]
**Q5 (начал бы иначе):** [честный ответ]

---

### Score: [X/10]

[2-3 строки обоснования score]
```

---

## Критерии Score /10

| Score | Что это значит |
|-------|----------------|
| 1–3 | Мало артефактов, нет kill analysis, нет паттернов, direction unclear |
| 4–5 | Артефакты есть, kill analysis частичный, есть zombie-гипотезы, gaps критические |
| 6–7 | Хорошая документация отказов, паттерны видны, zombie минимальны, 1-2 critical gap |
| 8–9 | Полная прослеживаемость, минимум gaps, direction четко обоснован, zombies нет |
| 10 | Все assumptions tested, zero zombie, pearl registry актуален, Q5 = "ничего не изменил бы" |

**Важно:** Score оценивает ПОЛНОТУ исследовательской программы, не правильность гипотез. Можно иметь 9/10 и при этом не найти ответ — это правильная наука.

---

## Scoring таблица (детальная)

| Критерий | 0 | 1 | 2 |
|---------|---|---|---|
| null_results задокументированы | нет файла | частично | все с kill analysis |
| Kill Analysis в каждом REJECT | отсутствует | у части | у всех |
| Zombie-гипотезы | активные | задокументированные | нет |
| Untested assumptions | >3 критических | 1-2 критических | 0 критических |
| Pearl Registry актуален | нет / expired | частично | все с next_check |
| Direction явно обоснован evidence | нет обоснования | слабое | сильное с ссылками |

**Итог**: сложи баллы → /12 → умножь на 10/12 → rounded Score/10.

---

## Антипаттерны

| Антипаттерн | Почему опасно |
|-------------|--------------|
| Начинать с README, не с null_results | Читаешь PR-версию, не правду |
| Суммаризировать таблицу вместо точного картирования | Gap-анализ становится неточным |
| Считать parked = dead | Parked = потенциально alive при новых условиях |
| Идентифицировать zombie только по словам | Одна гипотеза в разных словах — zombie |
| Давать "direction" без evidence chain | Это мнение, не вердикт |
| Пропускать Q5 ("что изменилось бы") | Самый ценный вопрос, часто самый неудобный |

---

## Адаптация к нестандартным проектам

**Нет experiments/null_results структуры:**
- Git история → commits = experiments, reverted commits = null_results
- GitHub Issues → closed-as-wontfix = null_results, closed-as-duplicate = zombie
- Obsidian daily notes → cancelled tasks = parked, archived pages = null_results

**Очень большой проект (>100 экспериментов):**
- Читай только INDEX файлы, не individual experiments
- Группируй по временным периодам (квартал/месяц)
- Для паттерн-анализа: только top-10 причин смерти

**Проект без команды (solo research):**
- Q5 ("начал бы иначе") особенно важен — нет других людей чтобы catching bias
- Zombie-анализ критичен — solo researcher чаще возвращается к убитому без Revival Condition

---

## Связанные скилы

- `/skeptic` — атаковать конкретный claim (не всю программу); в режиме context-asymmetry
  (только `claim.md` + код, без session history — см. `rules/falsification-ladder.md`
  § Context Asymmetry Rule) — слепая валидация конкретного claim без знания истории
- `/hypothesis-arbiter` — выбор между конкурирующими активными гипотезами
- `/session-retrospective` — аудит одной сессии
- `/harvest` — извлечь коммерческую/научную ценность из проекта
- `null_results/INDEX.md` — главный вход для этого скила
- `/boyko-project-radar` — использует research-audit как источник данных для категории
  "нерешённые места" в своём PROJECT-режиме, только если в проекте есть
  research-артефакты (null_results/parked/experiments)

---

## Feedback (living-skill opt-in, пилот с 2026-07-17)

После завершения задачи этим скиллом: если у пользователя есть замечание —
что зашло, что нет, что стоит изменить в подходе — допиши его одной строкой
в `feedback.log` рядом с этим `SKILL.md`, в формате:
`[YYYY-MM-DD] <фидбек как есть>`
Не спрашивай, если пользователь явно спешит / в Speed Mode.

Дважды в неделю `skill-self-update` (см. `docs/living-skills.md`) читает
накопленный `feedback.log` и точечно правит этот файл — автономно, но
каждая правка коммитится в git отдельным `auto(skill-feedback):`-коммитом,
так что любое неудачное изменение обратимо через `git revert`.
- `pearl_registry/INDEX.md` — вспомогательный вход