code-ai-installer 4.0.0 → 4.0.1-a

package/domains/product/.agents/skills/epic-breakdown/SKILL.md

@@ -1,420 +1,435 @@
----
-name: epic-breakdown
-description: Декомпозиция эпика на stories с зависимостями, size estimates (S/M/L/XL), critical path
----
-# Epic Breakdown
-
-> **Категория:** Specification  ·  **Slug:** `epic-breakdown`
-
-## Когда использовать
-
-- После утверждения epic (через RICE / WSJF) — перед спринт-плэннингом.
-- При оценке capacity для roadmap planning.
-- Для выявления critical path и параллелизируемой работы.
-- Pre-kickoff: команда должна знать декомпозицию.
-
-## Вход
-
-| Поле | Обязательно | Описание |
-|------|:-----------:|----------|
-| Epic spec (из PRD) | ✅ | Scope + критерии успеха |
-| Существующая архитектура | ✅ | Что уже есть |
-| Состав команды | ✅ | Senior/mid/junior, роли |
-| Зависимости / интеграции | ⬚ | Внешние системы |
-| Ограничения | ⬚ | Дедлайны, compliance |
-
-## Источники данных
-
-1. PRD через `$prd-template`.
-2. Tech review от Tech Lead.
-3. Существующая кодовая база / архитектурные документы.
-4. Исторические данные о velocity.
-
-### Связь с другими скилами
-
-| Скил | Что берём | Когда вызывать |
-|------|-----------|----------------|
-| `prd-template` | Scope epic | Родительский |
-| `user-story` | Гранулярность уровня story | После декомпозиции |
-| `acceptance-criteria` | Критерии готовности | На каждую story |
-| `wsjf-scoring` | Приоритет уровня epic | Перед декомпозицией |
-
-## Структура
-
-```
-Epic (масштаб 1-2 квартала)
-  ├── Story 1 (1-8 очков, в спринте)
-  ├── Story 2
-  ├── Story 3
-  └── Story N
-      ↓
-  + Technical Tasks (не видимые пользователю, например инфра)
-  + Spikes (исследование / POC)
-```
-
-Sizing:
-- **Epic:** недели до месяцев (>13 очков эквивалент)
-- **Story:** 1-8 очков (помещается в спринт)
-- **Task:** < 1 дня
-- **Spike:** time-boxed исследование (обычно 1-3 дня)
-
-## Протокол
-
-### Шаг 0 — Ясность epic
-
-- [ ] Результат epic определён (как выглядит «готово»)?
-- [ ] Success metrics прикреплены?
-- [ ] Scope явный (что включено + что нет)?
-
-Если нет — вернуться к PRD.
-
-### Шаг 1 — Вертикальная нарезка
-
-**Вертикальные срезы** (видимые пользователю, приносят ценность постепенно) **>** горизонтальные (слои: DB → backend → frontend → UI).
-
-Каждая story — тонкий вертикальный срез, от UI до хранилища.
-
-Пример для epic «Team Role Templates»:
-- ❌ Горизонтально: Story 1 «DB schema», Story 2 «Backend API», Story 3 «Frontend» (ничего не выходит, пока всё не готово)
-- ✅ Вертикально: Story 1 «Создать шаблон (базовые поля)», Story 2 «Редактировать шаблон», Story 3 «Удалить шаблон», Story 4 «Назначить шаблон новому участнику»
-
-### Шаг 2 — Техники разбиения
-
-Если story слишком большая:
-- **Шаги рабочего процесса:** многоэтапный поток → story на каждый шаг
-- **Вариации данных:** тип пользователя / регион / локаль
-- **Альтернативные пути:** story happy path + story ошибочных случаев
-- **Acceptance criteria:** вынести один AC как отдельную story
-- **Роли:** story для конечного пользователя + story для администратора (отдельно)
-- **Простое/Сложное:** базовая версия + расширенные опции
-
-### Шаг 3 — Добавить технические задачи
-
-**Чисто техническая работа** без пользователь-видимой ценности:
-- Настройка инфраструктуры
-- DB миграции (если нет покрывающей user story)
-- Инструментирование observability
-- Тесты / фикстуры
-
-Держать отдельно от stories — не раздувать user stories.
-
-### Шаг 4 — Идентифицировать spikes
-
-При высокой неопределённости — spike (time-boxed исследование):
-- Архитектурное решение (оценка новых технологий)
-- Исследование проблемы производительности
-- Проверка реализуемости интеграции
-
-Результат: ADR (architecture decision record) или POC-код, не выпускаемая функция.
-
-### Шаг 5 — Маппинг зависимостей
-
-Для каждой story — **зависит от** / **открывает**:
-
-| Story | Depends On | Enables | Можно параллельно с |
-|-------|------------|---------|----------------------|
-| S1: Template CRUD | — | S2, S4 | S5 (auth) |
-| S2: Permissions config | S1 | S3 | S5 |
-| S3: Assign to members | S1, S2 | — | — |
-
-### Шаг 6 — Critical Path
-
-Определить critical path — самую длинную последовательность зависимых stories.
-
-```
-S1 → S2 → S3 = critical path
-S5 (auth) параллельно
-S4 (migration) параллельно
-```
-
-Длина critical path = минимальное прошедшее время для epic.
-
-### Шаг 7 — Sizing по каждой story
-
-T-shirt / Story Points:
-- **XS/1:** < 1 дня
-- **S/2:** 1-2 дня
-- **M/3:** 2-4 дня
-- **L/5-8:** 1+ недели
-- **XL/13+:** РАЗБИТЬ (слишком большая для спринта)
-
-Убедиться что XL не осталось после декомпозиции.
-
-### Шаг 8 — Назначение ролей команды
-
-Для каждой story — кто задействован?
-- Frontend + Backend + DB (full-stack срез)
-- Нужен ли Design?
-- Участие Data / analytics?
-- Нужно ли security review?
-- Время QA?
-
-### Шаг 9 — Входные данные для спринт-плэннинга
-
-Результат: документ декомпозиции epic:
-- Резюме epic + критерии успеха
-- Список stories с размером + зависимостями
-- Визуализация critical path
-- Технические задачи
-- Spikes
-- Оценочные суммарные усилия
-- Оценочные сроки
-
-### Шаг 10 — Checkpoint валидации
-
-Ревью команды (PM + Eng Lead + Design):
-- Пропущенные stories?
-- Неправильный sizing?
-- Зависимости верны?
-- Параллелизируемая работа максимизирована?
-
-## Валидация (Quality Gate)
-
-- [ ] Результат epic + success metrics явны
-- [ ] Stories — вертикальные срезы (каждый приносит ценность)
-- [ ] Нет XL stories (все разбиты до ≤ 8 очков)
-- [ ] Технические задачи отделены от stories
-- [ ] Spikes time-boxed
-- [ ] Зависимости отмечены
-- [ ] Critical path определён
-- [ ] Параллелизируемая работа явна
-- [ ] Проверка capacity команды (суммарные усилия vs capacity)
-- [ ] Стейкхолдер-ревью пройдено
-
-## Handoff
-
-Результат является входом для:
-- **Sprint Planning** — stories → спринты
-- **`user-story`** + **`acceptance-criteria`** для каждой story
-- **Tech Lead** → владение техническими задачами
-- **PM** → уточнение сроков roadmap
-
-Формат: документ декомпозиции epic (markdown + граф зависимостей). Через `$handoff`.
-
-## Anti-patterns
-
-| Ошибка | Почему плохо | Как правильно |
-|--------|-------------|---------------|
-| Горизонтальная нарезка | Ничего не выходит пока не готовы все слои | Тонкие вертикальные срезы |
-| XL stories | Не помещается в спринт | Разбивать с помощью техник |
-| Нет spike для неизвестного | Неправильно оценённые stories | Time-boxed spike |
-| Технические задачи раздувают stories | Неправильный sizing | Отдельный трек |
-| Игнорировать зависимости | Параллельная работа заблокирована | Явный DAG |
-| Пропустить validation review | Пропущенные stories обнаруживаются в середине спринта | Ревью команды до kickoff |
-
-## Шаблон
-
-```markdown
-# Epic Breakdown: [Название Epic]
-
-## Резюме Epic
-- Результат: [как выглядит «готово»]
-- Success metric: [X от базового уровня до цели]
-- Scope: [что включено]
-- Вне scope: [явно]
-
-## Stories (вертикальные срезы)
-
-| # | Story | Размер | Depends on | Enables | Роли |
-|---|-------|:----:|------------|---------|-------|
-| S1 | [...] | M | — | S2, S3 | FE+BE+Design |
-| S2 | [...] | S | S1 | S3 | BE |
-
-## Технические задачи
-- T1: DB migration для [X] — 1 день
-- T2: Instrumentation observability — 0.5 дня
-
-## Spikes
-- SP1: Оценить Redis vs Memcached кэширование — тайм-бокс 2 дня
-
-## Critical Path
-S1 → S2 → S3 (итого: ~2 недели)
-Параллельно: T1 (DB migration), S5 (auth integration)
-
-## Резюме Capacity
-- Суммарная оценка: N person-weeks
-- Команда: M человек × Y недель = Доступно
-- Буфер: ~20%
-
-## Открытые вопросы
-- [Вопрос, ответственный]
-```
-
-## Worked Example — TeamFlow Epic Breakdown: AI Summarization
-
-**Контекст:** После WSJF команда решила декомпозировать Epic 3 «AI Summarization Core» (WSJF 1.77 — низкий из-за размера работы). Цикл декомпозиции ниже превращает монолитный epic в вертикальные срезы + технические задачи + spikes.
-
-```markdown
-# Epic Breakdown: AI Summarization Core
-
-## Резюме Epic
-- **Результат:** Менеджеры, использующие AI summarization TeamFlow еженедельно — Sticky Manager Ratio ≥20% к Дню 90 после запуска
-- **Success metric:** 65% принятие в AI-tier аккаунтах, завершение пунктов действий 60→75%
-- **Scope:** MVP post-meeting AI summarization (НЕ в реальном времени, НЕ prep card — это Q3)
-- **Вне scope:** Real-time транскрипция, мульти-встречная аналитика, интеграция внешних встреч
-
-## Stories (вертикальные срезы — каждый приносит ценность end-to-end)
-
-| # | Story | Размер | Depends on | Enables | Роли |
-|---|-------|:----:|------------|---------|-------|
-| S1 | Включить переключатель AI Summarization на встречу | S (2) | T1 (feature flag) | S2 | FE + BE |
-| S2 | Сгенерировать AI-резюме из записи встречи | L (8) | S1, T2 (LLM API), T3 (audio pipeline) | S3, S4 | BE + AI + Data |
-| S3 | Просматривать и редактировать резюме inline | M (5) | S2 | S6 (audit) | FE + Design + BE |
-| S4 | Извлекать пункты действий со скорингом уверенности | M (5) | S2 | S5 | AI + BE |
-| S5 | Показывать напоминания о пунктах действий перед следующей встречей 1:1 | S (3) | S4, T4 (notif infra) | — | BE + FE |
-| S6 | Admin org-wide AI policy | S (3) | S1 | — | FE + BE |
-| S7 | Экспортировать audit log AI-операций | S (3) | S1, S2, S3, S6 | — | BE |
-
-**Суммарные story points:** 29. Оценка velocity: 4-5 очков/неделю для AI команды (4 инженера). Продолжительность: ~6-7 недель.
-
-## Технические задачи (не приносят пользовательской ценности отдельно, но необходимы)
-
-| # | Задача | Усилие | Владелец | Зависимость |
-|---|------|:------:|-------|-----------|
-| T1 | Feature flag infrastructure (LaunchDarkly setup + обёртка) | 0.5 нед. | Platform | — (основа) |
-| T2 | LLM API abstraction layer (OpenAI + Anthropic failover) | 1.5 нед. | AI team | результат SP1 |
-| T3 | Audio ingestion pipeline (запись браузера → хранилище) | 1 нед. | Platform | — |
-| T4 | Notification scheduling service | 0.5 нед. | Platform | — (можно переиспользовать) |
-| T5 | Summary data model + schema migration | 0.5 нед. | Backend | — |
-| T6 | Instrumentation observability (OTEL события, дашборды) | 0.5 нед. | SRE + AI | T2 |
-| T7 | SOC 2 Type II документация аудит-контролей | 1 нед. | Security + Legal | Параллельный трек |
-
-**Суммарные технические задачи:** ~5.5 недель параллельной работы.
-
-## Spikes (time-boxed исследования)
-
-| # | Spike | Тайм-бокс | Владелец | Необходимое решение |
-|---|-------|:--------:|-------|-----------------|
-| SP1 | Бенчмарк LLM провайдеров: OpenAI GPT-4 vs Anthropic Claude для качества HR-разговоров | 1 нед. | AI Lead | Какой основной, какой резервный |
-| SP2 | Audio pipeline: браузерный MediaRecorder vs WebRTC vs сторонний (Recall.ai) | 1 нед. | Platform Lead | Решение build vs buy |
-| SP3 | Хранение summary: Postgres JSONB vs выделенное document store (для будущего ML) | 3 дня | Data Lead | Подход к схеме |
-
-**Суммарные spikes:** ~2.5 недели (параллельно с ранними работами разработки).
-
-## Граф зависимостей (DAG)
-
-```
-Spikes (Неделя 1):
-  SP1 (LLM bench) → информирует T2
-  SP2 (Audio)    → информирует T3
-  SP3 (Storage)  → информирует T5
-
-Техническая основа (Неделя 1-2, параллельно):
-  T1 (feature flag) ─┐
-  T3 (audio pipeline) ┼─→ S1 (включить переключатель)
-  T5 (schema)         │
-  T7 (SOC 2 docs — параллельно, Недели 1-8)
-  T2 (LLM API) ──────────┐
-                          ▼
-  S1 → S2 (генерировать резюме) ─┬─→ S3 (редактировать inline)
-                                 │      └─→ S6 (export audit, нужны edit события)
-                                 └─→ S4 (пункты действий)
-                                        └─→ S5 (напоминания, нужен T4)
-
-S6 (admin policy) требует S1
-
-T6 (observability) параллельно, подхватывает когда выходит S2
-
-Critical path: SP1 → T2 → S2 = 3.5 недели последовательно
-                            (S2 блокирует S3, S4, в конечном счёте S5, S6, S7)
-```
-
-## Анализ Critical Path
-
-**Critical path:**
-```
-Неделя 1: Spikes (SP1 LLM bench) + T1 (feature flag) + T3 (audio pipeline) + T5 (schema) + SOC 2 параллельно
-Неделя 2-3: T2 (LLM API abstraction) — заблокирован SP1
-Неделя 3: S1 (включить переключатель) — разблокирован после T1
-Неделя 3-6: S2 (генерировать резюме) — большая, 8 очков при 2 очках/неделю AI команды
-Неделя 6-7: S3 (редактировать inline) + S4 (пункты действий) параллельно — оба зависят от S2
-Неделя 7-8: S5 (напоминания), S6 (admin policy), S7 (audit export) — все S-размерные
-Неделя 8-10: Интеграционное тестирование, бета, итерация
-Неделя 11-13: Limited GA → Full GA
-```
-
-**Сжатые сроки:** 13 недель для MVP (соответствует цели Q2).
-
-## Параллелизируемая работа
-
-- Platform задачи (T1, T3, T4, T5) — независимые, стартуют одновременно в Неделе 1
-- SOC 2 audit (T7) — параллельный трек весь квартал
-- Дизайн для S3 inline editor — параллельно с разработкой S2
-- Data instrumentation (T6) — параллельно с S2
-
-## Назначение ролей команды
-
-| Рабочий поток | Команда | Неделя 1-3 | Неделя 4-6 | Неделя 7-10 | Неделя 11-13 |
-|------------|------|----------|----------|-----------|------------|
-| AI/Backend | AI team (2 инж.) | SP1, T2 | S2 core | S4, итерация | Бета-исправления |
-| Backend | Platform (2 инж.) | T1, T3, T4, T5, SP2 | S1 + поддержка S2 | S5, S6, S7 | GA выкатка |
-| Frontend | FE team (2 инж.) | Ревью дизайнов | S1 UI | S3, S5 UI | Итерация |
-| Design | Design (1) | Поток + wireframes | Hi-fi mocks для S3 | Граничные случаи | Полировка |
-| Data | Data Lead | SP3 | Схема событий | T6 instrumentation | Дашборды |
-| Security | Security Lead | T7 docs | T7 подготовка к аудиту | T7 аудит | Аттестация |
-| PM/Design | PM + Design | Kickoff + AC | Подготовка беты | Бета работает | GA планирование |
-
-## Sprint Plan (2-недельные спринты)
-
-**Спринт 1 (Недели 1-2): Основа**
-- Завершить: SP1, SP2, SP3, T1, T3, T5
-- В процессе: T2, T7
-
-**Спринт 2 (Недели 3-4): Первая функция**
-- Завершить: T2, S1
-- В процессе: S2
-
-**Спринт 3 (Недели 5-6): Core AI**
-- Завершить: S2
-- В процессе: S3, S4
-
-**Спринт 4 (Недели 7-8): Расширение + Полировка**
-- Завершить: S3, S4, S5, S6
-- В процессе: S7, T6, подготовка беты
-
-**Спринт 5 (Недели 9-10): Бета + Итерация**
-- Бета запущена с 10 design partners
-- Итерация по обратной связи
-
-**Спринт 6 (Недели 11-12): Limited GA**
-- 25% AI-tier клиентов
-- Мониторинг guardrails
-
-**Спринт 7 (Неделя 13): Full GA**
-- 100% AI-tier
-- Маркетинговый запуск
-
-## Резюме Capacity
-
-- **Команда:** 8 инженеров (AI team 2, Platform 2, FE 2, плюс Design 1, Data 1) + 3 PM + Security
-- **Суммарно person-weeks:** ~14 человек × 13 недель = 182 недели
-- **Выделение на Epic 3:** ~70 person-weeks (AI team полностью, остальные частично) = 38% capacity команды
-- **Другие Q2 epics параллельно:** Epic 1 (SSO), Epic 4 (Dashboard), T7 (SOC 2) — делят оставшиеся 60%
-- **Буфер:** ~20% времени каждого инженера для инцидентов, oncall, экстренного
-
-## Checkpoint Валидации (Неделя 6 — До беты)
-
-**До запуска беты, ревью команды:**
-- [ ] Порог качества S2 достигнут (≥70% принятие резюме через внутренний dogfood)
-- [ ] P95 задержка <60s для тестовых встреч
-- [ ] Аудит конфиденциальности пройден (ревью внутреннего юрисконсульта)
-- [ ] T2 failover протестирован (принудительный сбой OpenAI → Anthropic переключается за <10s)
-- [ ] 5 dogfood случаев включают граничные сценарии (короткая встреча, длинная встреча, чувствительный контент)
-
-Если любой пункт провалится → продлить Спринт 3-4 до беты (не запускать сломанным).
-
-## Открытые вопросы
-
-1. Результат SP1 — какой LLM основной? (Ответственный: AI Lead, к Неделе 2)
-2. SP2 audio pipeline — нативного браузерного достаточно или нужен Recall.ai? (Ответственный: Platform Lead, к Неделе 2)
-3. BYOK шифрование для Enterprise — дизайн? (Ответственный: Security Lead, к Неделе 4)
-4. Отбор бета-клиентов финализирован? (Ответственный: CS Lead, к Неделе 6)
-5. Ценообразование AI Tier подтверждено +$8/место? (Ответственный: VP Sales, к Неделе 3 — блокирует запуск тарифа)
-```
-
-> **Урок epic-breakdown:** Оригинальный Epic 3 имел **WSJF 1.77 (почти отклонён)** из-за размера работы 13. После декомпозиции:
-> - S2 (генерировать резюме) отдельно = WSJF 4+ (высокий UBV, средний размер)
-> - S5 напоминания = WSJF 5+ (быстрая победа по качеству)
-> - T7 SOC 2 = WSJF 3+ (блокирует compliance)  
->  
-> Декомпозированный epic **помещается в бюджет** (70 pm в 182-pm квартале) с параллельными рабочими потоками. Без декомпозиции монолитный WSJF 13 предложил бы отложить — упущенная возможность. **Декомпозиция — инструмент приоритизации, не только планирования.**
+---
+name: epic-breakdown
+description: Декомпозиция эпика на stories с зависимостями, size estimates (S/M/L/XL), critical path
+type: triggered
+domain: product
+owners:
+  - pm
+gates:
+  - PM
+tech: []
+topic: []
+triggers:
+  - epic-breakdown
+  - epic breakdown
+  - декомпозиция эпика
+related: []
+budget_lines: 435
+schema_version: 1
+---
+# Epic Breakdown
+
+> **Категория:** Specification  ·  **Slug:** `epic-breakdown`
+
+## Когда использовать
+
+- После утверждения epic (через RICE / WSJF) — перед спринт-плэннингом.
+- При оценке capacity для roadmap planning.
+- Для выявления critical path и параллелизируемой работы.
+- Pre-kickoff: команда должна знать декомпозицию.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| Epic spec (из PRD) | ✅ | Scope + критерии успеха |
+| Существующая архитектура | ✅ | Что уже есть |
+| Состав команды | ✅ | Senior/mid/junior, роли |
+| Зависимости / интеграции | ⬚ | Внешние системы |
+| Ограничения | ⬚ | Дедлайны, compliance |
+
+## Источники данных
+
+1. PRD через `$prd-template`.
+2. Tech review от Tech Lead.
+3. Существующая кодовая база / архитектурные документы.
+4. Исторические данные о velocity.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `prd-template` | Scope epic | Родительский |
+| `user-story` | Гранулярность уровня story | После декомпозиции |
+| `acceptance-criteria` | Критерии готовности | На каждую story |
+| `wsjf-scoring` | Приоритет уровня epic | Перед декомпозицией |
+
+## Структура
+
+```
+Epic (масштаб 1-2 квартала)
+  ├── Story 1 (1-8 очков, в спринте)
+  ├── Story 2
+  ├── Story 3
+  └── Story N
+      ↓
+  + Technical Tasks (не видимые пользователю, например инфра)
+  + Spikes (исследование / POC)
+```
+
+Sizing:
+- **Epic:** недели до месяцев (>13 очков эквивалент)
+- **Story:** 1-8 очков (помещается в спринт)
+- **Task:** < 1 дня
+- **Spike:** time-boxed исследование (обычно 1-3 дня)
+
+## Протокол
+
+### Шаг 0 — Ясность epic
+
+- [ ] Результат epic определён (как выглядит «готово»)?
+- [ ] Success metrics прикреплены?
+- [ ] Scope явный (что включено + что нет)?
+
+Если нет — вернуться к PRD.
+
+### Шаг 1 — Вертикальная нарезка
+
+**Вертикальные срезы** (видимые пользователю, приносят ценность постепенно) **>** горизонтальные (слои: DB → backend → frontend → UI).
+
+Каждая story — тонкий вертикальный срез, от UI до хранилища.
+
+Пример для epic «Team Role Templates»:
+- ❌ Горизонтально: Story 1 «DB schema», Story 2 «Backend API», Story 3 «Frontend» (ничего не выходит, пока всё не готово)
+- ✅ Вертикально: Story 1 «Создать шаблон (базовые поля)», Story 2 «Редактировать шаблон», Story 3 «Удалить шаблон», Story 4 «Назначить шаблон новому участнику»
+
+### Шаг 2 — Техники разбиения
+
+Если story слишком большая:
+- **Шаги рабочего процесса:** многоэтапный поток → story на каждый шаг
+- **Вариации данных:** тип пользователя / регион / локаль
+- **Альтернативные пути:** story happy path + story ошибочных случаев
+- **Acceptance criteria:** вынести один AC как отдельную story
+- **Роли:** story для конечного пользователя + story для администратора (отдельно)
+- **Простое/Сложное:** базовая версия + расширенные опции
+
+### Шаг 3 — Добавить технические задачи
+
+**Чисто техническая работа** без пользователь-видимой ценности:
+- Настройка инфраструктуры
+- DB миграции (если нет покрывающей user story)
+- Инструментирование observability
+- Тесты / фикстуры
+
+Держать отдельно от stories — не раздувать user stories.
+
+### Шаг 4 — Идентифицировать spikes
+
+При высокой неопределённости — spike (time-boxed исследование):
+- Архитектурное решение (оценка новых технологий)
+- Исследование проблемы производительности
+- Проверка реализуемости интеграции
+
+Результат: ADR (architecture decision record) или POC-код, не выпускаемая функция.
+
+### Шаг 5 — Маппинг зависимостей
+
+Для каждой story — **зависит от** / **открывает**:
+
+| Story | Depends On | Enables | Можно параллельно с |
+|-------|------------|---------|----------------------|
+| S1: Template CRUD | — | S2, S4 | S5 (auth) |
+| S2: Permissions config | S1 | S3 | S5 |
+| S3: Assign to members | S1, S2 | — | — |
+
+### Шаг 6 — Critical Path
+
+Определить critical path — самую длинную последовательность зависимых stories.
+
+```
+S1 → S2 → S3 = critical path
+S5 (auth) параллельно
+S4 (migration) параллельно
+```
+
+Длина critical path = минимальное прошедшее время для epic.
+
+### Шаг 7 — Sizing по каждой story
+
+T-shirt / Story Points:
+- **XS/1:** < 1 дня
+- **S/2:** 1-2 дня
+- **M/3:** 2-4 дня
+- **L/5-8:** 1+ недели
+- **XL/13+:** РАЗБИТЬ (слишком большая для спринта)
+
+Убедиться что XL не осталось после декомпозиции.
+
+### Шаг 8 — Назначение ролей команды
+
+Для каждой story — кто задействован?
+- Frontend + Backend + DB (full-stack срез)
+- Нужен ли Design?
+- Участие Data / analytics?
+- Нужно ли security review?
+- Время QA?
+
+### Шаг 9 — Входные данные для спринт-плэннинга
+
+Результат: документ декомпозиции epic:
+- Резюме epic + критерии успеха
+- Список stories с размером + зависимостями
+- Визуализация critical path
+- Технические задачи
+- Spikes
+- Оценочные суммарные усилия
+- Оценочные сроки
+
+### Шаг 10 — Checkpoint валидации
+
+Ревью команды (PM + Eng Lead + Design):
+- Пропущенные stories?
+- Неправильный sizing?
+- Зависимости верны?
+- Параллелизируемая работа максимизирована?
+
+## Валидация (Quality Gate)
+
+- [ ] Результат epic + success metrics явны
+- [ ] Stories — вертикальные срезы (каждый приносит ценность)
+- [ ] Нет XL stories (все разбиты до ≤ 8 очков)
+- [ ] Технические задачи отделены от stories
+- [ ] Spikes time-boxed
+- [ ] Зависимости отмечены
+- [ ] Critical path определён
+- [ ] Параллелизируемая работа явна
+- [ ] Проверка capacity команды (суммарные усилия vs capacity)
+- [ ] Стейкхолдер-ревью пройдено
+
+## Handoff
+
+Результат является входом для:
+- **Sprint Planning** — stories → спринты
+- **`user-story`** + **`acceptance-criteria`** для каждой story
+- **Tech Lead** → владение техническими задачами
+- **PM** → уточнение сроков roadmap
+
+Формат: документ декомпозиции epic (markdown + граф зависимостей). Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Горизонтальная нарезка | Ничего не выходит пока не готовы все слои | Тонкие вертикальные срезы |
+| XL stories | Не помещается в спринт | Разбивать с помощью техник |
+| Нет spike для неизвестного | Неправильно оценённые stories | Time-boxed spike |
+| Технические задачи раздувают stories | Неправильный sizing | Отдельный трек |
+| Игнорировать зависимости | Параллельная работа заблокирована | Явный DAG |
+| Пропустить validation review | Пропущенные stories обнаруживаются в середине спринта | Ревью команды до kickoff |
+
+## Шаблон
+
+```markdown
+# Epic Breakdown: [Название Epic]
+
+## Резюме Epic
+- Результат: [как выглядит «готово»]
+- Success metric: [X от базового уровня до цели]
+- Scope: [что включено]
+- Вне scope: [явно]
+
+## Stories (вертикальные срезы)
+
+| # | Story | Размер | Depends on | Enables | Роли |
+|---|-------|:----:|------------|---------|-------|
+| S1 | [...] | M | — | S2, S3 | FE+BE+Design |
+| S2 | [...] | S | S1 | S3 | BE |
+
+## Технические задачи
+- T1: DB migration для [X] — 1 день
+- T2: Instrumentation observability — 0.5 дня
+
+## Spikes
+- SP1: Оценить Redis vs Memcached кэширование — тайм-бокс 2 дня
+
+## Critical Path
+S1 → S2 → S3 (итого: ~2 недели)
+Параллельно: T1 (DB migration), S5 (auth integration)
+
+## Резюме Capacity
+- Суммарная оценка: N person-weeks
+- Команда: M человек × Y недель = Доступно
+- Буфер: ~20%
+
+## Открытые вопросы
+- [Вопрос, ответственный]
+```
+
+## Worked Example — TeamFlow Epic Breakdown: AI Summarization
+
+**Контекст:** После WSJF команда решила декомпозировать Epic 3 «AI Summarization Core» (WSJF 1.77 — низкий из-за размера работы). Цикл декомпозиции ниже превращает монолитный epic в вертикальные срезы + технические задачи + spikes.
+
+```markdown
+# Epic Breakdown: AI Summarization Core
+
+## Резюме Epic
+- **Результат:** Менеджеры, использующие AI summarization TeamFlow еженедельно — Sticky Manager Ratio ≥20% к Дню 90 после запуска
+- **Success metric:** 65% принятие в AI-tier аккаунтах, завершение пунктов действий 60→75%
+- **Scope:** MVP post-meeting AI summarization (НЕ в реальном времени, НЕ prep card — это Q3)
+- **Вне scope:** Real-time транскрипция, мульти-встречная аналитика, интеграция внешних встреч
+
+## Stories (вертикальные срезы — каждый приносит ценность end-to-end)
+
+| # | Story | Размер | Depends on | Enables | Роли |
+|---|-------|:----:|------------|---------|-------|
+| S1 | Включить переключатель AI Summarization на встречу | S (2) | T1 (feature flag) | S2 | FE + BE |
+| S2 | Сгенерировать AI-резюме из записи встречи | L (8) | S1, T2 (LLM API), T3 (audio pipeline) | S3, S4 | BE + AI + Data |
+| S3 | Просматривать и редактировать резюме inline | M (5) | S2 | S6 (audit) | FE + Design + BE |
+| S4 | Извлекать пункты действий со скорингом уверенности | M (5) | S2 | S5 | AI + BE |
+| S5 | Показывать напоминания о пунктах действий перед следующей встречей 1:1 | S (3) | S4, T4 (notif infra) | — | BE + FE |
+| S6 | Admin org-wide AI policy | S (3) | S1 | — | FE + BE |
+| S7 | Экспортировать audit log AI-операций | S (3) | S1, S2, S3, S6 | — | BE |
+
+**Суммарные story points:** 29. Оценка velocity: 4-5 очков/неделю для AI команды (4 инженера). Продолжительность: ~6-7 недель.
+
+## Технические задачи (не приносят пользовательской ценности отдельно, но необходимы)
+
+| # | Задача | Усилие | Владелец | Зависимость |
+|---|------|:------:|-------|-----------|
+| T1 | Feature flag infrastructure (LaunchDarkly setup + обёртка) | 0.5 нед. | Platform | — (основа) |
+| T2 | LLM API abstraction layer (OpenAI + Anthropic failover) | 1.5 нед. | AI team | результат SP1 |
+| T3 | Audio ingestion pipeline (запись браузера → хранилище) | 1 нед. | Platform | — |
+| T4 | Notification scheduling service | 0.5 нед. | Platform | — (можно переиспользовать) |
+| T5 | Summary data model + schema migration | 0.5 нед. | Backend | — |
+| T6 | Instrumentation observability (OTEL события, дашборды) | 0.5 нед. | SRE + AI | T2 |
+| T7 | SOC 2 Type II документация аудит-контролей | 1 нед. | Security + Legal | Параллельный трек |
+
+**Суммарные технические задачи:** ~5.5 недель параллельной работы.
+
+## Spikes (time-boxed исследования)
+
+| # | Spike | Тайм-бокс | Владелец | Необходимое решение |
+|---|-------|:--------:|-------|-----------------|
+| SP1 | Бенчмарк LLM провайдеров: OpenAI GPT-4 vs Anthropic Claude для качества HR-разговоров | 1 нед. | AI Lead | Какой основной, какой резервный |
+| SP2 | Audio pipeline: браузерный MediaRecorder vs WebRTC vs сторонний (Recall.ai) | 1 нед. | Platform Lead | Решение build vs buy |
+| SP3 | Хранение summary: Postgres JSONB vs выделенное document store (для будущего ML) | 3 дня | Data Lead | Подход к схеме |
+
+**Суммарные spikes:** ~2.5 недели (параллельно с ранними работами разработки).
+
+## Граф зависимостей (DAG)
+
+```
+Spikes (Неделя 1):
+  SP1 (LLM bench) → информирует T2
+  SP2 (Audio)    → информирует T3
+  SP3 (Storage)  → информирует T5
+
+Техническая основа (Неделя 1-2, параллельно):
+  T1 (feature flag) ─┐
+  T3 (audio pipeline) ┼─→ S1 (включить переключатель)
+  T5 (schema)         │
+  T7 (SOC 2 docs — параллельно, Недели 1-8)
+  T2 (LLM API) ──────────┐
+                          ▼
+  S1 → S2 (генерировать резюме) ─┬─→ S3 (редактировать inline)
+                                 │      └─→ S6 (export audit, нужны edit события)
+                                 └─→ S4 (пункты действий)
+                                        └─→ S5 (напоминания, нужен T4)
+
+S6 (admin policy) требует S1
+
+T6 (observability) параллельно, подхватывает когда выходит S2
+
+Critical path: SP1 → T2 → S2 = 3.5 недели последовательно
+                            (S2 блокирует S3, S4, в конечном счёте S5, S6, S7)
+```
+
+## Анализ Critical Path
+
+**Critical path:**
+```
+Неделя 1: Spikes (SP1 LLM bench) + T1 (feature flag) + T3 (audio pipeline) + T5 (schema) + SOC 2 параллельно
+Неделя 2-3: T2 (LLM API abstraction) — заблокирован SP1
+Неделя 3: S1 (включить переключатель) — разблокирован после T1
+Неделя 3-6: S2 (генерировать резюме) — большая, 8 очков при 2 очках/неделю AI команды
+Неделя 6-7: S3 (редактировать inline) + S4 (пункты действий) параллельно — оба зависят от S2
+Неделя 7-8: S5 (напоминания), S6 (admin policy), S7 (audit export) — все S-размерные
+Неделя 8-10: Интеграционное тестирование, бета, итерация
+Неделя 11-13: Limited GA → Full GA
+```
+
+**Сжатые сроки:** 13 недель для MVP (соответствует цели Q2).
+
+## Параллелизируемая работа
+
+- Platform задачи (T1, T3, T4, T5) — независимые, стартуют одновременно в Неделе 1
+- SOC 2 audit (T7) — параллельный трек весь квартал
+- Дизайн для S3 inline editor — параллельно с разработкой S2
+- Data instrumentation (T6) — параллельно с S2
+
+## Назначение ролей команды
+
+| Рабочий поток | Команда | Неделя 1-3 | Неделя 4-6 | Неделя 7-10 | Неделя 11-13 |
+|------------|------|----------|----------|-----------|------------|
+| AI/Backend | AI team (2 инж.) | SP1, T2 | S2 core | S4, итерация | Бета-исправления |
+| Backend | Platform (2 инж.) | T1, T3, T4, T5, SP2 | S1 + поддержка S2 | S5, S6, S7 | GA выкатка |
+| Frontend | FE team (2 инж.) | Ревью дизайнов | S1 UI | S3, S5 UI | Итерация |
+| Design | Design (1) | Поток + wireframes | Hi-fi mocks для S3 | Граничные случаи | Полировка |
+| Data | Data Lead | SP3 | Схема событий | T6 instrumentation | Дашборды |
+| Security | Security Lead | T7 docs | T7 подготовка к аудиту | T7 аудит | Аттестация |
+| PM/Design | PM + Design | Kickoff + AC | Подготовка беты | Бета работает | GA планирование |
+
+## Sprint Plan (2-недельные спринты)
+
+**Спринт 1 (Недели 1-2): Основа**
+- Завершить: SP1, SP2, SP3, T1, T3, T5
+- В процессе: T2, T7
+
+**Спринт 2 (Недели 3-4): Первая функция**
+- Завершить: T2, S1
+- В процессе: S2
+
+**Спринт 3 (Недели 5-6): Core AI**
+- Завершить: S2
+- В процессе: S3, S4
+
+**Спринт 4 (Недели 7-8): Расширение + Полировка**
+- Завершить: S3, S4, S5, S6
+- В процессе: S7, T6, подготовка беты
+
+**Спринт 5 (Недели 9-10): Бета + Итерация**
+- Бета запущена с 10 design partners
+- Итерация по обратной связи
+
+**Спринт 6 (Недели 11-12): Limited GA**
+- 25% AI-tier клиентов
+- Мониторинг guardrails
+
+**Спринт 7 (Неделя 13): Full GA**
+- 100% AI-tier
+- Маркетинговый запуск
+
+## Резюме Capacity
+
+- **Команда:** 8 инженеров (AI team 2, Platform 2, FE 2, плюс Design 1, Data 1) + 3 PM + Security
+- **Суммарно person-weeks:** ~14 человек × 13 недель = 182 недели
+- **Выделение на Epic 3:** ~70 person-weeks (AI team полностью, остальные частично) = 38% capacity команды
+- **Другие Q2 epics параллельно:** Epic 1 (SSO), Epic 4 (Dashboard), T7 (SOC 2) — делят оставшиеся 60%
+- **Буфер:** ~20% времени каждого инженера для инцидентов, oncall, экстренного
+
+## Checkpoint Валидации (Неделя 6 — До беты)
+
+**До запуска беты, ревью команды:**
+- [ ] Порог качества S2 достигнут (≥70% принятие резюме через внутренний dogfood)
+- [ ] P95 задержка <60s для тестовых встреч
+- [ ] Аудит конфиденциальности пройден (ревью внутреннего юрисконсульта)
+- [ ] T2 failover протестирован (принудительный сбой OpenAI → Anthropic переключается за <10s)
+- [ ] 5 dogfood случаев включают граничные сценарии (короткая встреча, длинная встреча, чувствительный контент)
+
+Если любой пункт провалится → продлить Спринт 3-4 до беты (не запускать сломанным).
+
+## Открытые вопросы
+
+1. Результат SP1 — какой LLM основной? (Ответственный: AI Lead, к Неделе 2)
+2. SP2 audio pipeline — нативного браузерного достаточно или нужен Recall.ai? (Ответственный: Platform Lead, к Неделе 2)
+3. BYOK шифрование для Enterprise — дизайн? (Ответственный: Security Lead, к Неделе 4)
+4. Отбор бета-клиентов финализирован? (Ответственный: CS Lead, к Неделе 6)
+5. Ценообразование AI Tier подтверждено +$8/место? (Ответственный: VP Sales, к Неделе 3 — блокирует запуск тарифа)
+```
+
+> **Урок epic-breakdown:** Оригинальный Epic 3 имел **WSJF 1.77 (почти отклонён)** из-за размера работы 13. После декомпозиции:
+> - S2 (генерировать резюме) отдельно = WSJF 4+ (высокий UBV, средний размер)
+> - S5 напоминания = WSJF 5+ (быстрая победа по качеству)
+> - T7 SOC 2 = WSJF 3+ (блокирует compliance)  
+>  
+> Декомпозированный epic **помещается в бюджет** (70 pm в 182-pm квартале) с параллельными рабочими потоками. Без декомпозиции монолитный WSJF 13 предложил бы отложить — упущенная возможность. **Декомпозиция — инструмент приоритизации, не только планирования.**