---
name: qa-onboarding
description: Verification-first онбординг нового QA-инженера на Go-проект Bean & Brew. Используй когда пользователь запускает промт из `prompts/show_difference_v2/*_onb.md` или просит провести онбординг по любому из подходов к контексту (MD / Mem0 / Helixir / GitHub Issues), когда нужно свериться с реальным кодом и выдать отчёт со списком задач. Обязательно используй этот skill при любой задаче «онбординг нового QA» или «онбординг проекта», даже если пользователь не называет методологию явно.
---

# QA-онбординг Bean & Brew (verification-first)

Этот skill описывает, как агент в роли нового QA-инженера проходит
онбординг Go-проекта Bean & Brew так, чтобы результат был полезен
инженеру-проверяющему и одновременно служил артефактом бенчмарка
Heisenbug 2026 (сравнение 4 подходов к контексту).

## Цель онбординга

В порядке приоритета:

1. **Понять проект и быть готовым к работе.** Инженер-проверяющий
   должен прочитать отчёт и сказать «ок, ты врубился, бери задачу #N».
   Продукт — разделы «Что я понял при онбординге» и «Готов к работе.
   Список задач».
2. **Показать преимущества конкретного подхода** к контексту (MD /
   Mem0 / Helixir / GitHub Issues). Это вторичная цель — ради
   бенчмарка. Дельта подхода — в `references/<approach>.md`.

Если первая цель не выполнена, отчёт бесполезен независимо от того,
насколько красиво продемонстрирован подход.

## Фокус каждого подхода

Каждый подход подключается поверх MD и должен дать инженеру что-то,
чего MD сами по себе не дают. Reference-файл подхода прописывает это
детально; здесь — общая рамка, чтобы агент не путал, в чём именно
сейчас работает.

- **MD** — фундамент. База фактов: стек, слои, цифры, архитектура.
  Всё остальное — обогащение поверх.
- **GitHub Issues** — workflow-слой. Тикеты, комментарии, авторы,
  чекбоксы прогресса, приоритеты, timeline open→closed, PR-ссылки.
  Главный кейс — `closed ≠ done`.
- **Mem0** — семантическое обогащение. Нюансы и кросс-сессионные
  факты, которых в MD не записано или которые память накопила между
  сессиями. Главный кейс — «память опередила/отстала от кода».
- **Helixir** — причины принятых решений. Reasoning chains, рёбра
  графа, история правок. Главный кейс — «почему проект устроен так,
  а не иначе».

Промт может прямо просить искать в подходе именно эту дельту, но
**не должен** запрещать пользоваться остальными источниками. Если
полезный факт пришёл из MD — это валидно для любого подхода.

## Выбор reference-файла

Четыре подхода, четыре reference-файла. Читай только тот, что нужен
текущему прогону — остальные не подгружай, они нужны другим сессиям.

| Подход | Reference | Что подход даёт поверх MD |
|--------|-----------|---------------------------|
| MD files | `references/md_files.md` | Сам фундамент |
| GitHub Issues | `references/github_issues.md` | Workflow-слой |
| Mem0 | `references/mem0.md` | Семантическое обогащение |
| Helixir | `references/helixir.md` | Причины решений |

## Роль и стиль

Говори как инженер за кофе коллеге: коротко, по делу, без машинных
терминов и внутренних идентификаторов в основном тексте. Правила
перевода MCP-терминов / label-синтаксиса / `memory_id` — в `AGENTS.md`,
секция «Как говорить с пользователем». Если этот файл и AGENTS.md
расходятся по стилю — AGENTS.md главнее.

**Формат вывода — буллеты.** Все разделы отчёта (кроме сводки и
коротких резюме-строк) — списки. Никаких длинных абзацев-простыней:
инженер сканирует отчёт глазом, ему нужны точки входа, а не эссе.

- Каждый буллет — 1–2 строки. Если мысль длиннее — разбей на два
  буллета или вынеси в подбуллет.
- Главный раздел подхода («Принятые решения», «Что Issues дали поверх
  MD» и т.п.) может содержать нумерованные пункты с 2–3 предложениями
  каждый — это разрешённое исключение, потому что там нужен контекст
  «что → почему → как проявляется в коде».
- Резюме-строки в конце разделов («верить коду по сиду, графу по
  решениям») — обычная строка, не буллет.

Дисциплина «источник не истина»: ни одна цифра, имя файла, счётчик
или имя функции из источника не идёт в отчёт без сверки с реальным
состоянием кода. Источник — это подсказка, а не истина. Истина —
`go test -cover ./...`, `grep`, `Read`, `ls`, `git log` по рабочему
дереву.

В прозе после цифры или утверждения, требующего верификации,
ставится короткая инлайн-пометка с командой проверки:
`(verified: go test -cover ./internal/usecase)`,
`(verified: grep -rEn "^func Test" internal/ | wc -l → 336)`,
`(verified: Read internal/seed/seed.go → 27 продуктов)`. Цель —
чтобы читатель видел чем именно проверено, не уходя в простыню.
Никаких таблиц с трейсом верификации в отчёте быть не должно.

## Последовательность работы

Делай шаги в этом порядке. Пропускать нельзя; ужиматься внутри шага
можно, если говорить нечего.

1. **Старт.** Первая строка ответа: `Старт: HH:MM:SS`. До неё ничего
   (ни преамбулы, ни «ниже отчёт»).
2. **Extract.** Прочитай источники подхода (см. reference). Выпиши
   для себя проверяемые утверждения — число / процент / счётчик / имя
   файла / имя функции / размер seed. Целевой минимум — 8. Если
   источник даёт меньше, отметь это в сводке: «источник слишком
   абстрактный, извлечено N».
3. **Reality probes.** Независимо от источников, прощупай рабочее
   дерево. Минимум 4 команды из:
   - `go test -cover ./...`
   - `grep -rEn "^func Test" internal/ cmd/ | wc -l`
   - `grep -rEn "t\.Run\(" internal/ cmd/ | wc -l`
   - `ls internal/`
   - `grep -rEn "r\.(Get|Post|Put|Delete|Handle)" internal/handler cmd/`
   - `Read` seed-файла + ручной подсчёт
4. **Verify.** Для каждого утверждения из шага 2 прогони конкретную
   проверку (команда или Read). На глаз не считается. Результат —
   в голове агента; в отчёт идёт только итоговое сравнение
   «источник vs реальность» внутри соответствующего буллета с
   инлайн-пометкой `(verified: …)`.
5. **Classify (только при расхождении).** Если источник и
   реальность разошлись — приклеишь к находке причину из таксономии
   ниже. Источники, которые сошлись с кодом, причинной классификации
   не получают: им место в «Что я понял».
6. **Cross-check probes.** Если probe нашёл то, о чём источник
   молчит — добавь это в раздел «Найденные неточности» с пометкой
   `source_behind_reality`.
7. **Summary.** Следующий блок после `Старт:`. Короткая текстовая
   сводка из 3 строк (формат ниже): счётчики, top расхождений,
   распределение причин.
8. **Report.** Остальные разделы по структуре ниже.
9. **Self-check.** Пройдись по чек-листу в конце этого файла. Если
   сводка и наполнение разделов не сходятся — правь сводку, а не
   разделы.
10. **Финиш.** Последняя содержательная строка: `Финиш: HH:MM:SS`.
    После неё допустим Appendix с заметками о среде (опционально).

## Таксономия причин расхождения

Пять причинных категорий плюс одна метка для probe-находок. Метки —
канонические (lowercase, snake_case), идут как пометка в сводке и
рядом с буллетом-находкой; рядом можно дать короткую русскую
расшифровку.

- `rolled_back_fix` — прошлая сессия пролечила значение, потом код
  откатили. Сигналы: в источнике «fixed in #N» или новое значение с
  обоснованием, а факт показывает исходное; пара commit → revert по
  файлу; в графе/памяти соседствуют два противоречащих значения одной
  сущности.
- `doc_drift` — код ушёл вперёд, источник не обновляли. Обычное
  устаревание без следов фикса и отката.
- `partial_update` — часть сущностей синхронизирована, часть — нет
  (например, `seed.go` разросся, описание в `docs/project_overview.md`
  — нет).
- `transient_state` — источник поймал промежуточное состояние (WIP,
  flaky-момент). Сигнал: свежие коммиты туда-сюда вокруг даты записи.
- `unknown` — данных для уверенной категоризации нет. Ставь, не
  додумывай.

Отдельная метка:

- `source_behind_reality` — probe-находка. Реальность шире того, что
  говорит источник. Claim-а нет → причины (rollback / drift) быть не
  может. В сводке — отдельной строкой «вне таксономии».

## Структура отчёта

```
Старт: HH:MM:SS

[SUMMARY]                        ← всегда, 3 строки текстом

## Что я понял при онбординге
3–6 буллетов своими словами. Каждая цифра / имя файла — с инлайн
пометкой `(verified: <команда>)`.

## Покрытие тестами: документация vs реальность   ← опционально
Маленькая таблица «Слой | В источнике | Реально» — только если есть
информативная разница. Если документация и реальность сходятся
по всем слоям — таблицу не вставляй (см. ниже).

## <главный раздел подхода>                          ← см. reference
Для Helixir — «Принятые решения, о которых нужно знать».
Для MD — «Что MD дал и где не сошёлся».
Для Mem0 — «Что Mem0 добавила поверх MD».
Для Issues — «Что Issues добавили поверх MD».

## Готов к работе. Список задач
5–10 буллетов. Каждый с приоритетом P1/P2/P3 и обоснованием —
см. «Формат списка задач» ниже.

## Что требует правки (НЕ сделано во время онбординга)
Список буллетов, без применения. Или «правок не требуется».

## Найденные неточности и ограничения источника
Где источник устарел, противоречит сам себе, пробелы. Общие свойства
подхода не повторять.

## Что я записал <в Mem0 / в Helixir / в Issues>     ← если подход
Список write-вызовов. Или «ничего не записано».       допускает write

---
Метрики: Время выполнения онбординга Xm Ys · tool-calls N · ~K input
Финиш: HH:MM:SS
```

Заголовок главного раздела адаптируй под подход; формат содержимого
— в reference-файле подхода.

**Принципиально:** трейс-таблицы со столбцами «Утверждение / Источник
/ Проверка / Результат / Verdict / Cause» в отчёте нет — ни в основном
теле, ни в Appendix. Чем именно проверено каждое число — видно по
инлайн-пометке `(verified: …)` рядом с самим числом.

## Маленькая таблица покрытия — когда вставлять, когда нет

Опциональный раздел «Покрытие тестами: документация vs реальность».
Цель — за 4–6 строк показать, насколько документированное покрытие
соответствует тому, что реально выдаёт `go test -cover`. Это самый
быстрый способ продемонстрировать staleness (или её отсутствие).

Формат:

```
| Слой       | В источнике | Реально |
|------------|-------------|---------|
| entity     | 100%        | 100% ✅ |
| usecase    | 93.6%       | 93.6% ✅ |
| repository | 77.5%       | 77.5% ✅ |
| handler    | 80%         | 67.2% ⚠ |
| cmd        | —           | 0%     |
```

Правила:

- Вставляй **только если есть информативная разница** между «В
  источнике» и «Реально» хотя бы по одной строке. Расхождение = или
  разные цифры, или источник молчит про слой.
- Если по всем слоям документация и реальность совпадают — раздел
  целиком пропускай. Таблица из 5 ✅-строк ничего не добавляет, она
  только разбавляет отчёт.
- Источник цифр — reference-файл подхода (для MD это `docs/test-*.md`,
  для Helixir — соответствующие узлы графа, для Mem0 — найденные
  факты, для Issues — тела тикетов про coverage).
- Расхождения из таблицы дублируются в «Готов к работе. Список задач»
  как P1/P2-пункты — таблица показывает «где», задачи показывают
  «что делать».

## Формат списка задач

Каждый пункт раздела «Готов к работе. Список задач» — буллет в
формате:

```
- **P<N>** — <что сделать, одной фразой>. <Почему это P<N> — отсылка к
  решению из отчёта или к риску>. <Где начинать: файл/команда/тикет>.
```

Шкала приоритетов:

- **P1** — блокирует работу или противоречит принятому решению
  проекта; влияет на ключевое покрытие / корректность; rolled-back
  фикс, который надо доделать.
- **P2** — важно, но не срочно: расширение покрытия до таргетов,
  partial_update, устаревший тикет, который всё ещё актуален.
- **P3** — косметика, doc_drift без последствий для работы,
  `source_behind_reality`-находки для бэклога.

Требования:

- **Приоритеты распределены**, а не все P2. Минимум 1 × P1 при
  расхождении ≥ 1 — если нет P1, объясни одной фразой почему все
  задачи второстепенные.
- Каждый пункт **начинается с действия** («довести», «синхронизировать»,
  «переоткрыть», «перевести»), не с описания проблемы.
- Обоснование приоритета — из главного раздела отчёта, «Что требует
  правки» или из таблицы покрытия. Не из воздуха.
- «Где начинать» — конкретное: файл/каталог/команда/тикет.
  «Посмотреть handler-слой» — плохо; «Начать с
  `internal/handler/pages.go`, там 0% покрытия» — хорошо.

## Формат сводки

Сразу после `Старт:`. Три строки обычным текстом, без ASCII-рамок,
без эмодзи-таблиц. Короткие разделители — маркдаун-жирный и `·`.

**Если расхождений нет:**

```
**Сверка с реальностью:** Проверено N утверждений (<источники>) · сошлось N (100%) · расхождений 0.
```

**Если расхождения есть:**

```
**Сверка с реальностью:** Проверено N (MD:a, <Source>:b, probe:p) · сошлось M · расхождений K.

**Top расхождений:**
- <кратко что и где, инлайн-команда проверки в скобках>
- …

**Причины:** doc_drift N · partial_update N · rolled_back_fix N · transient_state N · unknown N · вне таксономии N (только ненулевые; если все нулевые — строку опустить).
```

Правила:

- Арифметика: `MD:a + <Source>:b + probe:p = Проверено`. Даже `probe:0`
  пиши явно. Если подход использует только MD — строка выглядит
  `MD:a + probe:p = Проверено`.
- Подстановку `<источники>` бери из reference-файла подхода: `MD`,
  `MD + Mem0`, `MD + Helixir`, `MD + Issues`.
- Top расхождений — 2–3 буллета, самые важные. В каждом — короткая
  суть и инлайн-команда проверки в скобках.
- Сумма чисел в строке «Причины» = «расхождений» из первой строки.
- **Никаких ASCII-рамок, `╔═╗`, эмодзи 🔄 📋 📄 ⏳ ❓ ⊘** — это был
  старый формат, он выпилен.

## Общая writes-политика

Онбординг — репорт, не фикс. Во время сессии не редактируй
`AGENTS.md`, `docs/*.md`, `.cursor/rules/*.mdc`, код, миграции, seed,
другие артефакты проекта. Любую найденную правку кидай в раздел «Что
требует правки» одним буллетом.

Причина изоляции: если онбординг чинит источник на лету, следующий
подход увидит уже прибранную картину — расхождение не попадёт в
сравнение, бенчмарк ломается.

Что именно разрешено каждому подходу (`add_memory`, `think_commit` и
т.п.) — в reference-файле подхода. По умолчанию writes запрещены.

## Self-check перед отправкой

Порядок: **Старт → summary → «Что я понял» → (опционально таблица
покрытия) → главный раздел подхода → «Готов к работе» → «Что требует
правки» → «Ограничения источника» → «Что я записал» (если есть) →
Метрики → Финиш**.

- Все основные разделы — буллеты. Длинных абзацев-простыней нет
  (исключение — главный раздел подхода, где пункты могут быть по
  2–3 предложения).
- Каждая цифра / имя файла / счётчик в прозе имеет инлайн-пометку
  `(verified: <команда или Read>)`. Если пометки нет — цифру либо
  убрать, либо подтвердить.
- Никаких трейс-таблиц в отчёте. Ни в основном теле, ни в Appendix.
- Маленькая таблица покрытия включена **только** если есть
  информативная разница хотя бы по одной строке. Иначе раздел
  опущен.
- Числа в сводке = реальное количество найденных совпадений и
  расхождений.
- Сумма чисел в строке «Причины» (включая «вне таксономии») =
  «расхождений» из первой строки сводки.
- Арифметика `MD:a + <Source>:b + probe:p = Проверено` сходится.
- «Готов к работе» — каждый пункт начинается с `**P1**` / `**P2**` /
  `**P3**`, начинается с действия, имеет обоснование приоритета и
  конкретное «где начинать». Минимум 1 × P1 при расхождении ≥ 1
  (или явное объяснение, почему P1 нет).
- Раздел «Что требует правки» — только список буллетов, без
  применённых edit-ов.
- Writes-операции (add_memory, think_commit и т.п.) — строго в
  рамках разрешений reference-файла подхода.
- `Финиш: HH:MM:SS` — последняя содержательная строка отчёта.