code-ai-installer 3.0.0 → 4.0.1-a

package/domains/product/.agents/skills/moscow-prioritization/SKILL.md

@@ -1,392 +1,407 @@
----
-name: moscow-prioritization
-description: Приоритизация по Must / Should / Could / Won't — для coarse scope cuts
----
-# MoSCoW Prioritization
-
-> **Категория:** Prioritization  ·  **Slug:** `moscow-prioritization`
-
-## Когда использовать
-
-- При release scoping — какой minimum viable set?
-- В Cut-Camp (`/shape-prioritize`) — как основной инструмент.
-- Для stakeholder communication — простой language про scope.
-- При time-boxed projects (hard deadline) — что cut сначала.
-
-## Вход
-
-| Поле | Обязательно | Описание |
-|------|:-----------:|----------|
-| Список фич / требования | ✅ | Что рассматривается |
-| Цель релиза | ✅ | Что считаем «успешным релизом» |
-| Time box | ✅ | Deadline / количество спринтов |
-| Оценка мощности | ✅ | Пропускная способность команды |
-| Camp (Full B) | ⬚ | alpha (Build) / beta (Cut) |
-
-## Источники данных
-
-1. `$rice-scoring` — количественная база, MoSCoW поверх.
-2. `$kano-model` — must-haves автоматически в Must.
-3. Обязательства перед клиентами / SLA — контрактные musts.
-4. Соответствие / безопасность — неоспоримые musts.
-
-### Связь с другими скилами
-
-| Скил | Что берём | Когда вызывать |
-|------|-----------|----------------|
-| `rice-scoring` | Количественное ранжирование | Перед MoSCoW |
-| `kano-model` | Must-haves | Для Must bucket |
-| `prd-template` | Секция out-of-scope | После MoSCoW |
-| `epic-breakdown` | Stories по bucket | После назначения |
-
-## Четыре bucketа
-
-| Bucket | Смысл | Правило |
-|--------|---------|------|
-| **Must have** | Блокер релиза. Без этого — релиз провалился. | Только ~60% мощности. Строго. |
-| **Should have** | Важно, но не блокер. Вырезание не убивает релиз. | ~20% мощности |
-| **Could have** | Nice to have. Если остаётся время — делаем. | ~20% мощности |
-| **Won't have (this time)** | Явно вне scope. Возможно в следующем релизе. | Неограниченный список |
-
-## Протокол
-
-### Шаг 0 — Camp Framing (Full B)
-
-**Build-Camp:** презюмируем большинство как Must. Планка для перемещения в Should — высокая.
-
-**Cut-Camp:** презюмируем большинство как Could / Won't. Планка для Must — очень высокая («без этого релиз провалится»).
-
-Без adversarial — сбалансировано.
-
-### Шаг 1 — Raw List
-
-Собрать все фичи / требования. Обычно 15-40.
-
-### Шаг 2 — Classification Rules
-
-**Must have** критерии:
-- Отсутствие = провал релиза
-- Требование legal / compliance / безопасности
-- SLA или обязательство по клиентскому контракту
-- Основной пользовательский поток (без чего продукт непригоден к использованию)
-- Must-have из Kano анализа
-
-**Should have** критерии:
-- Высокая ценность, но обходной путь существует
-- Задержки вызывают боль, но не провал
-- Фичи «Дня 2» после основного релиза
-
-**Could have** критерии:
-- Приятные улучшения
-- Небольшие усилия, низкая сложность
-- Легко отложить
-
-**Won't have (this time)** критерии:
-- Явно вне scope
-- Требует предпосылки, которая не выполнена
-- Низкая ценность vs усилия
-- Относится к будущему релизу
-
-### Шаг 3 — Capacity Allocation
-
-Здоровое распределение:
-- Must: ~60% мощности
-- Should: ~20%
-- Could: ~20%
-- Won't: неограниченно
-
-Если Musts > 60% — слишком амбициозно, переместить некоторые в Should или договориться о таймлайне.
-
-### Шаг 4 — Individual Assessment
-
-Для каждой feature:
-
-| # | Фича | Bucket | Обоснование | Зависит от? |
-|---|---------|:------:|-----------|---------------|
-| 1 | SSO via SAML | Must | Требование enterprise контракта | — |
-| 2 | Аватар профиля пользователя | Could | Приятно, низкое влияние | Фича профиля |
-
-### Шаг 5 — Must Challenge
-
-Сессия оспаривания: команда попарно спрашивает про каждый Must: **«Могли бы мы выпустить без этого?»**
-
-Если ответ — «неудобно, но да» → переместить в Should.
-
-Настоящие Musts выживают после оспаривания: «Нет, релиз провалится потому что X».
-
-### Шаг 6 — Won't Documentation
-
-«Won't have» — **явно**, не неявно. Записать:
-- Почему исключено сейчас
-- Когда может быть рассмотрено
-- Зависимость / предпосылка
-
-Это предотвращает повторные дебаты позже.
-
-### Шаг 7 — Stakeholder Review
-
-Коммуницировать:
-- Musts → «будет в релизе»
-- Shoulds → «планируем в релизе, может сдвинуться»
-- Coulds → «если позволяет время»
-- Won'ts → «не в этом релизе, вот почему»
-
-## Валидация (Quality Gate)
-
-- [ ] Все фичи назначены в один из 4 buckets
-- [ ] Must мощность ≤ 60%
-- [ ] Каждый Must проходит оспаривание «могли бы выпустить без?»
-- [ ] Should/Could имеют обоснование
-- [ ] Won't фичи задокументированы с причиной
-- [ ] Проверка мощности: общая оценка ≤ доступной
-- [ ] Зависимости сопоставлены
-
-## Handoff
-
-Результат является входом для:
-- **`prd-template`** → Must/Should в scope, Won't в out-of-scope
-- **`epic-breakdown`** → stories по bucket
-- **Tech Lead** → валидация трудоёмкости
-- **Mediator** (Full B) — доказательства Cut camp
-
-Формат: MoSCoW table с rationale. Через `$handoff`.
-
-## Anti-patterns
-
-| Ошибка | Почему плохо | Как правильно |
-|--------|-------------|---------------|
-| Всё Must | Потеря приоритизации | Максимум 60% мощности Must |
-| Нет Won't | Scope неконтролируем | Явный список Won't |
-| Нет обоснования | Дебаты повторяются | У каждого пункта есть обоснование |
-| MoSCoW один раз, никогда не обновляется | Устаревает | Пересмотр на границах спринтов |
-| «Повышение» переговорами из Should | Расползание scope | Процесс оспаривания |
-| Расплывчатые buckets | Неясный scope | Строгие определения |
-
-## Шаблон
-
-```markdown
-# MoSCoW — [Название релиза] / [Квартал]
-
-## Цель релиза
-[Что делает этот релиз успешным]
-
-## Must Have (~60% мощности)
-| # | Фича | Обоснование | Усилия |
-| 1 | ... | Требование контракта | 2pm |
-
-## Should Have (~20%)
-...
-
-## Could Have (~20%)
-...
-
-## Won't Have (Этот релиз)
-| # | Фича | Почему не сейчас | Когда рассмотреть |
-| 1 | Мобильное приложение | Стратегия web-first | Q4 2026 |
-
-## Сводка мощности
-- Доступно: N человеко-недель
-- Must: X (Y%)
-- Should: X (Y%)
-- Could: X (Y%)
-- Буфер: Z
-```
-
-## Worked Example — TeamFlow `/shape-prioritize` Build-Camp vs Cut-Camp
-
-**Контекст:** TeamFlow. Strategy и vision утверждены (Mediator synthesis). Команда использует Full Pipeline B для **AI Summarization MVP scope debate** — Build-Camp (α) vs Cut-Camp (β) adversarial scope battle. Результат — Mediator synthesis.
-
-### Build-Camp MoSCoW (PM-01α)
-
-**Позиция:** Каждая идея оправдана. Бремя доказательства — показать что можно отложить. Результат: тенденция инклюзивная.
-
-```markdown
-# Build-Camp MoSCoW — AI Summarization MVP Q2 2026
-
-## Цель релиза
-Запустить MVP AI summarization «лучший в категории», без которого менеджерам не обойтись.
-
-## Must Have (~80% мощности)
-| # | Фича | Обоснование | Усилия (pm) |
-|---|---------|-----------|:-----------:|
-| 1 | AI Summary (core transcribe + summarize) | Основное обещание инициативы | 3 |
-| 2 | Автоматическое извлечение action items | JTBD F3 — action items теряются без этого | 1.5 |
-| 3 | Inline редактирование summary | Must-have по Kano, все сегменты | 0.5 |
-| 4 | Per-meeting AI toggle | Privacy Must-have, Kano | 0.5 |
-| 5 | Управление хранением данных | Compliance Must-have | 1 |
-| 6 | Интеграция с календарём | Must-have по Kano для mid-market+ | 2 |
-| 7 | Напоминания по action items (rule-based) | Наивысший RICE, быстрая победа | 0.5 |
-| 8 | Real-time transcription | Обеспечивает AI summary + delighter SMB | 4 |
-| 9 | Pre-1:1 prep card | Использует данные summary, высокоценный рабочий процесс | 2 |
-| 10 | Дашборд менеджера (здоровье 1:1 по менеджеру) | Визуальное подкрепление использования | 2 |
-| 11 | SSO SAML (разблокировка enterprise) | 2 enterprise сделки ожидают | 1 |
-| 12 | Расширения audit log | SOC 2 compliance — блокирует | 1.5 |
-
-**Must итого: 19.5 pm** (из 24 человеко-месяцев мощности)
-
-## Should Have (~15%)
-| # | Фича | Обоснование | Усилия (pm) |
-|---|---------|-----------|:-----------:|
-| 13 | Slack уведомления | SMB Delighter, низкие усилия | 0.5 |
-| 14 | Генератор квартального exec отчёта | VP HR Must по Kano | 2 |
-
-**Should итого: 2.5 pm**
-
-## Could Have (~5%)
-| # | Фича | Обоснование | Усилия (pm) |
-|---|---------|-----------|:-----------:|
-| 15 | AI подсказки для обсуждения | SMB Delighter | 1 |
-| 16 | Шаблоны встреч | SMB Delighter | 1 |
-
-**Could итого: 2 pm**
-
-## Won't Have (Этот релиз)
-| # | Фича | Почему не сейчас | Когда рассмотреть |
-|---|---------|-------------|:---------------:|
-| 1 | Импорт записей Zoom/Meet | Риск интеграции, Q2 жёсткий | Q3 2026 |
-| 2 | Отслеживание sentiment | Kano Reverse в SMB | Не в roadmap |
-| 3 | Только мобильный интерфейс | Web-first, mobile responsive ОК | Q4 2026 |
-
-## Сводка мощности
-- Доступно: 24 человеко-месяца (8 eng × 13 недель ÷ 52 = техническая мощность)
-- Must: 19.5 (81%) ⚠️ выше цели, но «всё обосновано»
-- Should: 2.5 (10%)
-- Could: 2 (8%)
-- Буфер: 0 (практически отсутствует)
-
-**Аргумент Build-Camp:** «Менеджеры, которые освоят эту фичу наполовину, уйдут. Нам нужен полноценный MVP — prep card + дашборд рядом с core — чтобы сделать это sticky. Урезать scope = выпустить посредственную фичу в категории, где Lattice опережает на 6 месяцев. Нужно идти ва-банк.»
-```
-
-### Cut-Camp MoSCoW (PM-02β)
-
-**Позиция:** Каждая идея лишняя до доказательства обратного. Бремя доказательства — показать, почему **обязательно сейчас**. Результат: тенденция минималистичная.
-
-```markdown
-# Cut-Camp MoSCoW — AI Summarization MVP Q2 2026
-
-## Цель релиза
-Запустить **минимально жизнеспособный** AI summarization — подтвердить рыночный спрос, защитить качество,
-оставить место для итерации после запуска.
-
-## Must Have (~40% мощности)
-| # | Фича | Обоснование | Усилия (pm) |
-|---|---------|-----------|:-----------:|
-| 1 | AI Summary (только core — transcribe + summarize) | ТА самая фича. Без неё нет ничего. | 3 |
-| 2 | Inline редактирование summary | Правило доверия — менеджеры должны иметь возможность исправить | 0.5 |
-| 3 | Per-meeting AI toggle | Privacy — нельзя выпустить без | 0.5 |
-| 4 | Управление хранением данных (базовое) | Compliance baseline | 1 |
-| 5 | Интеграция с календарём (только базовая выгрузка) | Без этого менеджеры не найдут 1:1 в AI UI | 1 |
-| 6 | SSO SAML | Блокер enterprise контракта, 2 сделки ожидают | 1 |
-
-**Must итого: 7 pm** (из 24 человеко-месяцев мощности)
-
-## Should Have (~30%)
-| # | Фича | Обоснование | Усилия (pm) |
-|---|---------|-----------|:-----------:|
-| 7 | Автоматическое извлечение action items | Высокая ценность, но зависит от качества AI summary, может подождать 1 итерацию | 1.5 |
-| 8 | Напоминания по action items (rule-based) | Быстрая победа, не зависит от AI | 0.5 |
-| 9 | Расширения audit log | Нужно для SOC 2 Type II, но есть 4 недели запаса до аудита | 1.5 |
-
-**Should итого: 3.5 pm**
-
-## Could Have (~10%)
-| # | Фича | Обоснование | Усилия (pm) |
-|---|---------|-----------|:-----------:|
-| 10 | Slack уведомления | Delighter, минимальные усилия | 0.5 |
-| 11 | Генератор квартального exec отчёта | Полезно, но не блокирует adoption | 2 |
-
-**Could итого: 2.5 pm**
-
-## Won't Have (Этот релиз)
-| # | Фича | Почему не сейчас | Когда рассмотреть |
-|---|---------|-------------|:---------------:|
-| 1 | **Real-time transcription** | ВЫСОКИЙ РИСК: 4pm усилий, может задержать запуск. Сначала — summary после встречи, live — позже. | Q3 2026 после MVP-выводов |
-| 2 | **Pre-1:1 prep card** | Зависит от данных нескольких встреч — до post-MVP их не будет | Q3 2026 |
-| 3 | **Дашборд менеджера (per-manager)** | Дублирует агрегированный дашборд (Тема 2) — коллизия scope | Post-MVP |
-| 4 | **AI подсказки для обсуждения** | Delighter, отложить до post-validation | Q4 2026 |
-| 5 | **Шаблоны встреч** | Смежная фича, scope другой команды | Post-MVP |
-| 6 | Импорт Zoom/Meet | Сложность интеграции | Q4 2026 |
-| 7 | Отслеживание sentiment | Kano Reverse | ❌ Никогда |
-
-## Сводка мощности
-- Доступно: 24 человеко-месяца
-- Must: 7 (29%) 
-- Should: 3.5 (15%)
-- Could: 2.5 (10%)
-- **Буфер: 11 pm (46%)** — позволяет инвестировать в качество, bug bash, beta-итерацию
-
-**Аргумент Cut-Camp:** «Real-time transcription добавляет 4 pm усилий и 50% риска срыва поставки. Сначала выпустим summary после встречи (всё ещё решает JTBD F1 + F2), проверим с клиентами, затем добавим real-time в Q3. Pre-1:1 prep card требует данных нескольких встреч — в MVP их нет. Дашборд per-manager дублирует агрегированный дашборд Темы 2 — коллизия scope не разрешена. Буфер 11pm = 46% — даже Build-Camp признаёт, что качеству нужен запас, мы встраиваем это в план.»
-```
-
-### Mediator Synthesis (MED-01)
-
-**Evidence audit:**
-- Build-Camp evidence: 3/5. Strong на user value, weak на delivery confidence (81% Must capacity = over-commitment)
-- Cut-Camp evidence: 4/5. Strong на risk argument, но Should items 7, 8 look bordering-Must для launch success
-
-**Synthesis decision — Hybrid:**
-
-```markdown
-# Единое решение по scope — AI Summarization MVP Q2 2026
-
-## Принято (из baseline Cut-Camp + отдельные добавления Build-Camp)
-
-### Must Have (~60% мощности)
-| # | Фича | Усилия | Лагерь-источник |
-|---|---------|:------:|:-----------:|
-| 1 | AI Summary (core) | 3 | Оба |
-| 2 | Inline редактирование summary | 0.5 | Оба |
-| 3 | Per-meeting AI toggle | 0.5 | Оба |
-| 4 | Управление хранением данных | 1 | Оба |
-| 5 | Интеграция с календарём | 2 | Build (расширение базовой версии Cut) |
-| 6 | SSO SAML | 1 | Оба |
-| 7 | Автоматическое извлечение action items | 1.5 | Build (повышен из Should Cut-Camp) |
-| 8 | Напоминания по action items | 0.5 | Оба |
-| 9 | Расширения audit log | 1.5 | Cut (Should → повышен до Must по дедлайну compliance) |
-| 10 | Inline редактирование менеджером | 0.5 | Оба |
-
-**Must итого: 12 pm (50% — в пределах здоровой цели)**
-
-### Should Have
-| Фича | Обоснование |
-|---------|-----------|
-| Slack уведомления | SMB delighter — быстрая победа |
-| Генератор квартального exec отчёта | Ценность VP HR (якорь Темы 2) |
-
-### Could Have
-| Фича | Обоснование |
-|---------|-----------|
-| AI подсказки для обсуждения | SMB delighter если время |
-| Шаблоны встреч | SMB delighter если время |
-
-### Won't Have
-| Фича | Почему |
-|---------|-----|
-| **Real-time transcription** | **Cut-Camp выигрывает этот спор** — сначала MVP с summary после встречи, подтвердим adoption, добавим real-time в Q3. Доказательство: 4 pm усилий + 50% риска задержки запуска. |
-| **Pre-1:1 prep card** | Cut-Camp выигрывает — нужны данные нескольких встреч, которых нет в MVP. Добавление в Q3. |
-| **Дашборд per-manager** | Коллизия scope с Темой 2 — объединить после MVP. |
-| Импорт Zoom/Meet | Q3-Q4 как Kano Delighter |
-| Отслеживание sentiment | ❌ Kano Reverse |
-
-## Сводка мощности
-- Доступно: 24 pm
-- Must: 12 (50%) ✅
-- Should: 2.5 (10%)
-- Could: 2 (8%)
-- **Буфер: 7.5 pm (32%)** — запас для качества + незапланированных работ
-
-## Обоснование гибридного решения
-- Cut-Camp верно определил **real-time transcription как Must с наивысшим риском** — понижение до Q3 снижает риск срыва поставки
-- Cut-Camp верно определил **коллизию scope дашборда per-manager** — Тема 2 обработает это
-- Build-Camp верно определил **извлечение action items как near-Must** — понижение создаёт путаницу «зачем AI summary без action items?»
-- Build-Camp верно определил **интеграцию с календарём сверх базовой** — ожидания mid-market
-- **Буфер 32%** уважает озабоченность Cut-Camp качеством при отгрузке значимого MVP
-
-## Открытые риски
-- Автоматическое извлечение action items зависит от достижения порогового качества AI summary — spike на Неделе 2 для валидации перед фиксацией
-- Добавление real-time transcription в Q3 нужно планировать уже сейчас (инфраструктура)
-
-## Требуется sign-off от: CTO (мощность), CPO (scope фич), VP Sales (готовность к enterprise)
-```
-
-> **Урок MoSCoW adversarial:** Build-Camp's Must = 81% capacity = **delivery risk**. Cut-Camp's Must = 29% = **feature anemia**. Mediator landed at 50% — **goldilocks zone**. Neither camp's argument was «wrong» — each was optimizing for different failure mode. Structured debate forced explicit trade-offs instead of team compromising in private channels. Final Must list can be traced per-feature to which camp owned the decision, preserves accountability.
+---
+name: moscow-prioritization
+description: Приоритизация по Must / Should / Could / Won't — для coarse scope cuts
+type: triggered
+domain: product
+owners:
+  - pm
+gates:
+  - PM
+tech: []
+topic: []
+triggers:
+  - moscow-prioritization
+  - MoSCoW
+  - must should could
+related: []
+budget_lines: 407
+schema_version: 1
+---
+# MoSCoW Prioritization
+
+> **Категория:** Prioritization  ·  **Slug:** `moscow-prioritization`
+
+## Когда использовать
+
+- При release scoping — какой minimum viable set?
+- В Cut-Camp (`/shape-prioritize`) — как основной инструмент.
+- Для stakeholder communication — простой language про scope.
+- При time-boxed projects (hard deadline) — что cut сначала.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| Список фич / требования | ✅ | Что рассматривается |
+| Цель релиза | ✅ | Что считаем «успешным релизом» |
+| Time box | ✅ | Deadline / количество спринтов |
+| Оценка мощности | ✅ | Пропускная способность команды |
+| Camp (Full B) | ⬚ | alpha (Build) / beta (Cut) |
+
+## Источники данных
+
+1. `$rice-scoring` — количественная база, MoSCoW поверх.
+2. `$kano-model` — must-haves автоматически в Must.
+3. Обязательства перед клиентами / SLA — контрактные musts.
+4. Соответствие / безопасность — неоспоримые musts.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `rice-scoring` | Количественное ранжирование | Перед MoSCoW |
+| `kano-model` | Must-haves | Для Must bucket |
+| `prd-template` | Секция out-of-scope | После MoSCoW |
+| `epic-breakdown` | Stories по bucket | После назначения |
+
+## Четыре bucketа
+
+| Bucket | Смысл | Правило |
+|--------|---------|------|
+| **Must have** | Блокер релиза. Без этого — релиз провалился. | Только ~60% мощности. Строго. |
+| **Should have** | Важно, но не блокер. Вырезание не убивает релиз. | ~20% мощности |
+| **Could have** | Nice to have. Если остаётся время — делаем. | ~20% мощности |
+| **Won't have (this time)** | Явно вне scope. Возможно в следующем релизе. | Неограниченный список |
+
+## Протокол
+
+### Шаг 0 — Camp Framing (Full B)
+
+**Build-Camp:** презюмируем большинство как Must. Планка для перемещения в Should — высокая.
+
+**Cut-Camp:** презюмируем большинство как Could / Won't. Планка для Must — очень высокая («без этого релиз провалится»).
+
+Без adversarial — сбалансировано.
+
+### Шаг 1 — Raw List
+
+Собрать все фичи / требования. Обычно 15-40.
+
+### Шаг 2 — Classification Rules
+
+**Must have** критерии:
+- Отсутствие = провал релиза
+- Требование legal / compliance / безопасности
+- SLA или обязательство по клиентскому контракту
+- Основной пользовательский поток (без чего продукт непригоден к использованию)
+- Must-have из Kano анализа
+
+**Should have** критерии:
+- Высокая ценность, но обходной путь существует
+- Задержки вызывают боль, но не провал
+- Фичи «Дня 2» после основного релиза
+
+**Could have** критерии:
+- Приятные улучшения
+- Небольшие усилия, низкая сложность
+- Легко отложить
+
+**Won't have (this time)** критерии:
+- Явно вне scope
+- Требует предпосылки, которая не выполнена
+- Низкая ценность vs усилия
+- Относится к будущему релизу
+
+### Шаг 3 — Capacity Allocation
+
+Здоровое распределение:
+- Must: ~60% мощности
+- Should: ~20%
+- Could: ~20%
+- Won't: неограниченно
+
+Если Musts > 60% — слишком амбициозно, переместить некоторые в Should или договориться о таймлайне.
+
+### Шаг 4 — Individual Assessment
+
+Для каждой feature:
+
+| # | Фича | Bucket | Обоснование | Зависит от? |
+|---|---------|:------:|-----------|---------------|
+| 1 | SSO via SAML | Must | Требование enterprise контракта | — |
+| 2 | Аватар профиля пользователя | Could | Приятно, низкое влияние | Фича профиля |
+
+### Шаг 5 — Must Challenge
+
+Сессия оспаривания: команда попарно спрашивает про каждый Must: **«Могли бы мы выпустить без этого?»**
+
+Если ответ — «неудобно, но да» → переместить в Should.
+
+Настоящие Musts выживают после оспаривания: «Нет, релиз провалится потому что X».
+
+### Шаг 6 — Won't Documentation
+
+«Won't have» — **явно**, не неявно. Записать:
+- Почему исключено сейчас
+- Когда может быть рассмотрено
+- Зависимость / предпосылка
+
+Это предотвращает повторные дебаты позже.
+
+### Шаг 7 — Stakeholder Review
+
+Коммуницировать:
+- Musts → «будет в релизе»
+- Shoulds → «планируем в релизе, может сдвинуться»
+- Coulds → «если позволяет время»
+- Won'ts → «не в этом релизе, вот почему»
+
+## Валидация (Quality Gate)
+
+- [ ] Все фичи назначены в один из 4 buckets
+- [ ] Must мощность ≤ 60%
+- [ ] Каждый Must проходит оспаривание «могли бы выпустить без?»
+- [ ] Should/Could имеют обоснование
+- [ ] Won't фичи задокументированы с причиной
+- [ ] Проверка мощности: общая оценка ≤ доступной
+- [ ] Зависимости сопоставлены
+
+## Handoff
+
+Результат является входом для:
+- **`prd-template`** → Must/Should в scope, Won't в out-of-scope
+- **`epic-breakdown`** → stories по bucket
+- **Tech Lead** → валидация трудоёмкости
+- **Mediator** (Full B) — доказательства Cut camp
+
+Формат: MoSCoW table с rationale. Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Всё Must | Потеря приоритизации | Максимум 60% мощности Must |
+| Нет Won't | Scope неконтролируем | Явный список Won't |
+| Нет обоснования | Дебаты повторяются | У каждого пункта есть обоснование |
+| MoSCoW один раз, никогда не обновляется | Устаревает | Пересмотр на границах спринтов |
+| «Повышение» переговорами из Should | Расползание scope | Процесс оспаривания |
+| Расплывчатые buckets | Неясный scope | Строгие определения |
+
+## Шаблон
+
+```markdown
+# MoSCoW — [Название релиза] / [Квартал]
+
+## Цель релиза
+[Что делает этот релиз успешным]
+
+## Must Have (~60% мощности)
+| # | Фича | Обоснование | Усилия |
+| 1 | ... | Требование контракта | 2pm |
+
+## Should Have (~20%)
+...
+
+## Could Have (~20%)
+...
+
+## Won't Have (Этот релиз)
+| # | Фича | Почему не сейчас | Когда рассмотреть |
+| 1 | Мобильное приложение | Стратегия web-first | Q4 2026 |
+
+## Сводка мощности
+- Доступно: N человеко-недель
+- Must: X (Y%)
+- Should: X (Y%)
+- Could: X (Y%)
+- Буфер: Z
+```
+
+## Worked Example — TeamFlow `/shape-prioritize` Build-Camp vs Cut-Camp
+
+**Контекст:** TeamFlow. Strategy и vision утверждены (Mediator synthesis). Команда использует Full Pipeline B для **AI Summarization MVP scope debate** — Build-Camp (α) vs Cut-Camp (β) adversarial scope battle. Результат — Mediator synthesis.
+
+### Build-Camp MoSCoW (PM-01α)
+
+**Позиция:** Каждая идея оправдана. Бремя доказательства — показать что можно отложить. Результат: тенденция инклюзивная.
+
+```markdown
+# Build-Camp MoSCoW — AI Summarization MVP Q2 2026
+
+## Цель релиза
+Запустить MVP AI summarization «лучший в категории», без которого менеджерам не обойтись.
+
+## Must Have (~80% мощности)
+| # | Фича | Обоснование | Усилия (pm) |
+|---|---------|-----------|:-----------:|
+| 1 | AI Summary (core transcribe + summarize) | Основное обещание инициативы | 3 |
+| 2 | Автоматическое извлечение action items | JTBD F3 — action items теряются без этого | 1.5 |
+| 3 | Inline редактирование summary | Must-have по Kano, все сегменты | 0.5 |
+| 4 | Per-meeting AI toggle | Privacy Must-have, Kano | 0.5 |
+| 5 | Управление хранением данных | Compliance Must-have | 1 |
+| 6 | Интеграция с календарём | Must-have по Kano для mid-market+ | 2 |
+| 7 | Напоминания по action items (rule-based) | Наивысший RICE, быстрая победа | 0.5 |
+| 8 | Real-time transcription | Обеспечивает AI summary + delighter SMB | 4 |
+| 9 | Pre-1:1 prep card | Использует данные summary, высокоценный рабочий процесс | 2 |
+| 10 | Дашборд менеджера (здоровье 1:1 по менеджеру) | Визуальное подкрепление использования | 2 |
+| 11 | SSO SAML (разблокировка enterprise) | 2 enterprise сделки ожидают | 1 |
+| 12 | Расширения audit log | SOC 2 compliance — блокирует | 1.5 |
+
+**Must итого: 19.5 pm** (из 24 человеко-месяцев мощности)
+
+## Should Have (~15%)
+| # | Фича | Обоснование | Усилия (pm) |
+|---|---------|-----------|:-----------:|
+| 13 | Slack уведомления | SMB Delighter, низкие усилия | 0.5 |
+| 14 | Генератор квартального exec отчёта | VP HR Must по Kano | 2 |
+
+**Should итого: 2.5 pm**
+
+## Could Have (~5%)
+| # | Фича | Обоснование | Усилия (pm) |
+|---|---------|-----------|:-----------:|
+| 15 | AI подсказки для обсуждения | SMB Delighter | 1 |
+| 16 | Шаблоны встреч | SMB Delighter | 1 |
+
+**Could итого: 2 pm**
+
+## Won't Have (Этот релиз)
+| # | Фича | Почему не сейчас | Когда рассмотреть |
+|---|---------|-------------|:---------------:|
+| 1 | Импорт записей Zoom/Meet | Риск интеграции, Q2 жёсткий | Q3 2026 |
+| 2 | Отслеживание sentiment | Kano Reverse в SMB | Не в roadmap |
+| 3 | Только мобильный интерфейс | Web-first, mobile responsive ОК | Q4 2026 |
+
+## Сводка мощности
+- Доступно: 24 человеко-месяца (8 eng × 13 недель ÷ 52 = техническая мощность)
+- Must: 19.5 (81%) ⚠️ выше цели, но «всё обосновано»
+- Should: 2.5 (10%)
+- Could: 2 (8%)
+- Буфер: 0 (практически отсутствует)
+
+**Аргумент Build-Camp:** «Менеджеры, которые освоят эту фичу наполовину, уйдут. Нам нужен полноценный MVP — prep card + дашборд рядом с core — чтобы сделать это sticky. Урезать scope = выпустить посредственную фичу в категории, где Lattice опережает на 6 месяцев. Нужно идти ва-банк.»
+```
+
+### Cut-Camp MoSCoW (PM-02β)
+
+**Позиция:** Каждая идея лишняя до доказательства обратного. Бремя доказательства — показать, почему **обязательно сейчас**. Результат: тенденция минималистичная.
+
+```markdown
+# Cut-Camp MoSCoW — AI Summarization MVP Q2 2026
+
+## Цель релиза
+Запустить **минимально жизнеспособный** AI summarization — подтвердить рыночный спрос, защитить качество,
+оставить место для итерации после запуска.
+
+## Must Have (~40% мощности)
+| # | Фича | Обоснование | Усилия (pm) |
+|---|---------|-----------|:-----------:|
+| 1 | AI Summary (только core — transcribe + summarize) | ТА самая фича. Без неё нет ничего. | 3 |
+| 2 | Inline редактирование summary | Правило доверия — менеджеры должны иметь возможность исправить | 0.5 |
+| 3 | Per-meeting AI toggle | Privacy — нельзя выпустить без | 0.5 |
+| 4 | Управление хранением данных (базовое) | Compliance baseline | 1 |
+| 5 | Интеграция с календарём (только базовая выгрузка) | Без этого менеджеры не найдут 1:1 в AI UI | 1 |
+| 6 | SSO SAML | Блокер enterprise контракта, 2 сделки ожидают | 1 |
+
+**Must итого: 7 pm** (из 24 человеко-месяцев мощности)
+
+## Should Have (~30%)
+| # | Фича | Обоснование | Усилия (pm) |
+|---|---------|-----------|:-----------:|
+| 7 | Автоматическое извлечение action items | Высокая ценность, но зависит от качества AI summary, может подождать 1 итерацию | 1.5 |
+| 8 | Напоминания по action items (rule-based) | Быстрая победа, не зависит от AI | 0.5 |
+| 9 | Расширения audit log | Нужно для SOC 2 Type II, но есть 4 недели запаса до аудита | 1.5 |
+
+**Should итого: 3.5 pm**
+
+## Could Have (~10%)
+| # | Фича | Обоснование | Усилия (pm) |
+|---|---------|-----------|:-----------:|
+| 10 | Slack уведомления | Delighter, минимальные усилия | 0.5 |
+| 11 | Генератор квартального exec отчёта | Полезно, но не блокирует adoption | 2 |
+
+**Could итого: 2.5 pm**
+
+## Won't Have (Этот релиз)
+| # | Фича | Почему не сейчас | Когда рассмотреть |
+|---|---------|-------------|:---------------:|
+| 1 | **Real-time transcription** | ВЫСОКИЙ РИСК: 4pm усилий, может задержать запуск. Сначала — summary после встречи, live — позже. | Q3 2026 после MVP-выводов |
+| 2 | **Pre-1:1 prep card** | Зависит от данных нескольких встреч — до post-MVP их не будет | Q3 2026 |
+| 3 | **Дашборд менеджера (per-manager)** | Дублирует агрегированный дашборд (Тема 2) — коллизия scope | Post-MVP |
+| 4 | **AI подсказки для обсуждения** | Delighter, отложить до post-validation | Q4 2026 |
+| 5 | **Шаблоны встреч** | Смежная фича, scope другой команды | Post-MVP |
+| 6 | Импорт Zoom/Meet | Сложность интеграции | Q4 2026 |
+| 7 | Отслеживание sentiment | Kano Reverse | ❌ Никогда |
+
+## Сводка мощности
+- Доступно: 24 человеко-месяца
+- Must: 7 (29%) 
+- Should: 3.5 (15%)
+- Could: 2.5 (10%)
+- **Буфер: 11 pm (46%)** — позволяет инвестировать в качество, bug bash, beta-итерацию
+
+**Аргумент Cut-Camp:** «Real-time transcription добавляет 4 pm усилий и 50% риска срыва поставки. Сначала выпустим summary после встречи (всё ещё решает JTBD F1 + F2), проверим с клиентами, затем добавим real-time в Q3. Pre-1:1 prep card требует данных нескольких встреч — в MVP их нет. Дашборд per-manager дублирует агрегированный дашборд Темы 2 — коллизия scope не разрешена. Буфер 11pm = 46% — даже Build-Camp признаёт, что качеству нужен запас, мы встраиваем это в план.»
+```
+
+### Mediator Synthesis (MED-01)
+
+**Evidence audit:**
+- Build-Camp evidence: 3/5. Strong на user value, weak на delivery confidence (81% Must capacity = over-commitment)
+- Cut-Camp evidence: 4/5. Strong на risk argument, но Should items 7, 8 look bordering-Must для launch success
+
+**Synthesis decision — Hybrid:**
+
+```markdown
+# Единое решение по scope — AI Summarization MVP Q2 2026
+
+## Принято (из baseline Cut-Camp + отдельные добавления Build-Camp)
+
+### Must Have (~60% мощности)
+| # | Фича | Усилия | Лагерь-источник |
+|---|---------|:------:|:-----------:|
+| 1 | AI Summary (core) | 3 | Оба |
+| 2 | Inline редактирование summary | 0.5 | Оба |
+| 3 | Per-meeting AI toggle | 0.5 | Оба |
+| 4 | Управление хранением данных | 1 | Оба |
+| 5 | Интеграция с календарём | 2 | Build (расширение базовой версии Cut) |
+| 6 | SSO SAML | 1 | Оба |
+| 7 | Автоматическое извлечение action items | 1.5 | Build (повышен из Should Cut-Camp) |
+| 8 | Напоминания по action items | 0.5 | Оба |
+| 9 | Расширения audit log | 1.5 | Cut (Should → повышен до Must по дедлайну compliance) |
+| 10 | Inline редактирование менеджером | 0.5 | Оба |
+
+**Must итого: 12 pm (50% — в пределах здоровой цели)**
+
+### Should Have
+| Фича | Обоснование |
+|---------|-----------|
+| Slack уведомления | SMB delighter — быстрая победа |
+| Генератор квартального exec отчёта | Ценность VP HR (якорь Темы 2) |
+
+### Could Have
+| Фича | Обоснование |
+|---------|-----------|
+| AI подсказки для обсуждения | SMB delighter если время |
+| Шаблоны встреч | SMB delighter если время |
+
+### Won't Have
+| Фича | Почему |
+|---------|-----|
+| **Real-time transcription** | **Cut-Camp выигрывает этот спор** — сначала MVP с summary после встречи, подтвердим adoption, добавим real-time в Q3. Доказательство: 4 pm усилий + 50% риска задержки запуска. |
+| **Pre-1:1 prep card** | Cut-Camp выигрывает — нужны данные нескольких встреч, которых нет в MVP. Добавление в Q3. |
+| **Дашборд per-manager** | Коллизия scope с Темой 2 — объединить после MVP. |
+| Импорт Zoom/Meet | Q3-Q4 как Kano Delighter |
+| Отслеживание sentiment | ❌ Kano Reverse |
+
+## Сводка мощности
+- Доступно: 24 pm
+- Must: 12 (50%) ✅
+- Should: 2.5 (10%)
+- Could: 2 (8%)
+- **Буфер: 7.5 pm (32%)** — запас для качества + незапланированных работ
+
+## Обоснование гибридного решения
+- Cut-Camp верно определил **real-time transcription как Must с наивысшим риском** — понижение до Q3 снижает риск срыва поставки
+- Cut-Camp верно определил **коллизию scope дашборда per-manager** — Тема 2 обработает это
+- Build-Camp верно определил **извлечение action items как near-Must** — понижение создаёт путаницу «зачем AI summary без action items?»
+- Build-Camp верно определил **интеграцию с календарём сверх базовой** — ожидания mid-market
+- **Буфер 32%** уважает озабоченность Cut-Camp качеством при отгрузке значимого MVP
+
+## Открытые риски
+- Автоматическое извлечение action items зависит от достижения порогового качества AI summary — spike на Неделе 2 для валидации перед фиксацией
+- Добавление real-time transcription в Q3 нужно планировать уже сейчас (инфраструктура)
+
+## Требуется sign-off от: CTO (мощность), CPO (scope фич), VP Sales (готовность к enterprise)
+```
+
+> **Урок MoSCoW adversarial:** Build-Camp's Must = 81% capacity = **delivery risk**. Cut-Camp's Must = 29% = **feature anemia**. Mediator landed at 50% — **goldilocks zone**. Neither camp's argument was «wrong» — each was optimizing for different failure mode. Structured debate forced explicit trade-offs instead of team compromising in private channels. Final Must list can be traced per-feature to which camp owned the decision, preserves accountability.