code-ai-installer 4.0.0 → 4.0.1-b

package/domains/product/.agents/skills/user-story/SKILL.md

@@ -1,385 +1,401 @@
----
-name: user-story
-description: Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user
----
-# User Story
-
-> **Категория:** Specification  ·  **Slug:** `user-story`
-
-## Когда использовать
-
-- В PRD — каждая user-facing функциональность.
-- В backlog grooming — преобразование идей в work items.
-- При epic breakdown — story-уровень.
-- В B2B — разделение buyer / end-user / admin stories.
-
-## Вход
-
-| Поле | Обязательно | Описание |
-|------|:-----------:|----------|
-| User role | ✅ | Buyer / end-user / admin / champion |
-| JTBD / problem | ✅ | Что решаем |
-| Context | ✅ | Когда возникает |
-
-## Источники данных
-
-1. `$jtbd-canvas` — jobs как отправная точка.
-2. `$problem-statement` — проблема как «so that».
-3. Customer interviews — язык пользователя.
-
-### Связь с другими скилами
-
-| Скил | Что берём | Когда вызывать |
-|------|-----------|----------------|
-| `jtbd-canvas` | Jobs → «I want» | Перед stories |
-| `problem-statement` | Боль → «so that» | Для обоснования |
-| `acceptance-criteria` | Контракт | На каждую story |
-| `epic-breakdown` | Grouping | После stories |
-
-## INVEST Criteria
-
-Хорошая user story:
-- **I**ndependent — можно разработать независимо
-- **N**egotiable — детали открыты для обсуждения, не зафиксированы
-- **V**aluable — несёт ценность для клиента
-- **E**stimable — команда может оценить effort
-- **S**mall — умещается в 1-2 спринта (< 8 points)
-- **T**estable — чёткие критерии прохождения/непрохождения
-
-## Формат
-
-**Canonical:**
-> **As a** [role]  
-> **I want to** [action / capability]  
-> **So that** [benefit / outcome]
-
-Пример:
-> **As a** DevOps engineer at mid-market SaaS  
-> **I want to** set team-level role templates в 2-3 clicks  
-> **So that** onboarding new teammates takes 10 min, не 2 hours
-
-## Протокол
-
-### Шаг 0 — Ясность ролей (критично для B2B)
-
-**Разные stories для разных roles** — не смешивать в одной:
-- **End-user story** — повседневный опыт использования
-- **Buyer story** — решение о покупке / оценке
-- **Admin story** — конфигурация / governance
-- **Champion story** — продвижение / отчётность
-
-В B2B отдельные stories на роль — разные AC, разные flows.
-
-### Шаг 1 — «So That» First
-
-Писать в обратном порядке — сначала benefit, потом action.
-
-Захватить customer outcome:
-- ❌ «Чтобы пользователи могли использовать новую функцию» (цикличность)
-- ✅ «Чтобы я мог закрыть ежеквартальный compliance-аудит за 2 часа вместо 2 дней»
-
-Benefit — **конкретный, измеримый**, связан с JTBD.
-
-### Шаг 2 — «I Want»
-
-Действие или возможность — что конкретно делает пользователь.
-
-- Атомарное (одно действие)
-- Технологически нейтральное («view team activity» не «click button on dashboard»)
-- Язык пользователя, не инженерный
-
-### Шаг 3 — «As A»
-
-Конкретная роль, не generic «user»:
-- «DevOps-инженер в mid-market SaaS» > «user»
-- «Customer Success Manager с >100 аккаунтами» > «user»
-
-Привязать роль к сегменту (если фича специфична для сегмента).
-
-### Шаг 4 — INVEST Check
-
-Проверить каждую story:
-- **I** — Можно разработать независимо? Если нужны другие stories сначала → split.
-- **N** — Детали открыты для обсуждения? (не переспецифицировано)
-- **V** — Клиент получает value? Если только техническое улучшение → переформулировать через user outcome.
-- **E** — Команда может оценить? Если нет — неизвестное требует spike.
-- **S** — Меньше 2 sprints? Если нет — split.
-- **T** — Можно написать чёткие pass/fail AC?
-
-### Шаг 5 — Разбивка крупных stories
-
-Техники разбивки:
-- **Workflow:** «create → update → delete» → 3 stories
-- **Data:** разные типы сущностей (user → team → organization)
-- **Happy path + edges:** основной flow → error states отдельными stories
-- **Acceptance criteria:** вытащить один scenario за другим из AC
-
-### Шаг 6 — Оценка размера story
-
-T-shirt или Story Points:
-- **S** (1-2 pts): < 1 дня
-- **M** (3-5 pts): 1-3 дня
-- **L** (8 pts): 4-7 дней
-- **XL** (13+ pts): **split**
-
-### Шаг 7 — Заметки по переговорам
-
-Добавить поле «Notes» для:
-- Открытых вопросов
-- Предположений
-- Предложенных границ scope
-
-Это сигналы инженерам: где есть пространство для переговоров.
-
-### Шаг 8 — Добавить AC
-
-Каждая story требует AC через `$acceptance-criteria`.
-
-Без AC story — не готова к спринту.
-
-## Валидация (Quality Gate)
-
-- [ ] Формат: As a / I want / So that
-- [ ] Роль — конкретная, не generic «user»
-- [ ] B2B: разделено по роли (если multi-role flow)
-- [ ] «So that» — конкретная, измеримая польза
-- [ ] INVEST пройден (все 6)
-- [ ] Размер ≤ 8 pts (или split)
-- [ ] AC прикреплены
-- [ ] Notes / предположения явны
-
-## Handoff
-
-Результат является входом для:
-- **`acceptance-criteria`** — каждая story
-- **`epic-breakdown`** — grouping
-- **Engineering** → implementation
-- **QA** → test cases
-
-Формат: story card (заголовок + as-I-so-that + notes + ссылка на AC). Через `$handoff`.
-
-## Anti-patterns
-
-| Ошибка | Почему плохо | Как правильно |
-|--------|-------------|---------------|
-| Роль «User» | Потеря контекста | Конкретная роль/сегмент |
-| Расплывчатое «so that» | Потеря ценности | Измеримая польза |
-| Реализация в story | Переспецификация | Действие, не UI |
-| Смешение ролей в одной story | Запутанные AC | Разделять по роли |
-| Большие (>13 pt) | Невозможно оценить | Разбить техниками |
-| Нет AC | Нет контракта | Обязательно иметь AC |
-| «As developer I want refactor» | Не ценность клиента | Перевести в user outcome |
-
-## Шаблон
-
-```markdown
-## Story: [Краткое название]
-
-**As a** [конкретная роль]
-**I want to** [действие]
-**So that** [измеримая польза]
-
-### Notes
-- Предположение: [X]
-- Открытый вопрос: [Y]
-
-### Acceptance Criteria
-[через $acceptance-criteria]
-
-### Размер
-M (3-5 points)
-
-### Зависимости
-- Story [#123] (предпосылка)
-```
-
-## Worked Example — TeamFlow User Stories for AI Summarization
-
-**Контекст:** 14 user stories в PRD всего. Ниже — 7 ключевых stories с правильным INVEST + разделением ролей B2B. Демонстрируют технику разбивки: end-user vs admin vs buyer.
-
-### Stories сгруппированы по роли
-
----
-
-#### Роль: People Manager (end-user) — Основная
-
-**Story S1: Включить AI Summarization для предстоящего 1:1**
-
-**As a** People manager с 5+ прямыми подчинёнными в mid-market B2B SaaS компании на Team Tier  
-**I want to** переключить «AI assist» для предстоящего 1:1 одним кликом  
-**So that** я могу полностью сосредоточиться на разговоре, не беспокоясь о заметках
-
-**Notes:**
-- Состояние по умолчанию: выключено (opt-in уважает приватность), пользователь активирует на каждую встречу
-- Admin может установить включено по умолчанию для всех новых 1:1 (настройка организации, S7)
-- Предположение: менеджеры предпочитают контроль на каждую встречу. Валидировано в Discovery E2-E4.
-- Открытый вопрос: применяется ли переключатель ко всей встрече или до/после событий переключения? → уточнить в AC
-
-**AC:** [см. `$acceptance-criteria` сценарии S1 — всего 4]
-
-**Размер:** S (2 points) — UI переключатель, проверка feature flag, settings API  
-**Зависимости:** T1 (инфраструктура feature flag)  
-**Валидация роли:** INVEST пройден (independent, negotiable, valuable, estimable, small, testable)
-
----
-
-**Story S2: Получить AI-сводку в течение 60 секунд после окончания встречи**
-
-**As a** People manager, завершивший AI-enabled 1:1  
-**I want to** получить структурированную сводку (темы, решения, action items) в течение 60 секунд после окончания встречи  
-**So that** я могу проверить и подтвердить её перед переходом к следующей задаче
-
-**Notes:**
-- Streaming UX приемлем — сводка заполняется постепенно в течение 60s
-- Порог качества: ≥70% сводок приемлемы без существенных правок (измеряется через S3)
-- Предположение: 60s ощущается мгновенно; 90s ощущается медленно. Валидировано через beta-обратную связь в Wizard-of-Oz тесте.
-
-**AC:** [4 сценария: happy path, streaming fallback, LLM timeout, встреча <5 мин — пропускается]
-
-**Размер:** L (8 points) — ядро AI-пайплайна  
-**Зависимости:** S1 (должен быть включён), T2 (LLM API интеграция)
-
----
-
-**Story S3: Проверять и редактировать AI-сводку inline**
-
-**As a** менеджер, просматривающий AI-сводку  
-**I want to** редактировать контент inline (добавлять, удалять, изменять) и помечать как подтверждённое  
-**So that** правки становятся авторитетной записью, и будущий AI учится моему стилю
-
-**Notes:**
-- Правки отслеживаются отдельно от оригинальной AI-версии (оба сохраняются для аудита + обучения)
-- Состояние подтверждения: «draft (AI)», «edited», «approved» (подтверждено менеджером)
-- Открытый вопрос: авто-подтверждение через 7 дней без правок? → по умолчанию: нет, статус остаётся «awaiting review»
-
-**AC:** [3 сценария: базовое редактирование, отмена редактирования, approved → только чтение]
-
-**Размер:** M (5 points) — интеграция rich-text редактора + конечный автомат  
-**Зависимости:** S2 (должна быть сводка)
-
----
-
-**Story S4: Автоматически отслеживать Action Items из сводки**
-
-**As a** менеджер с подтверждённой AI-сводкой  
-**I want** извлечённые action items автоматически добавлялись в мою очередь follow-up с владельцем + датой (если LLM вывел)  
-**So that** я не теряю обязательства между встречами
-
-**Notes:**
-- Порог достоверности извлечения: >70% — элементы с низкой достоверностью показываются отдельно для проверки менеджером
-- Владелец по умолчанию: выводится из контекста (если «Sarah, please review» → Sarah), иначе менеджер
-- Дата по умолчанию: «к следующему 1:1» (7 дней), менеджер может переопределить
-
-**AC:** [4 сценария: стандартное извлечение, проверка низкой достоверности, вывод владельца, кастомная дата]
-
-**Размер:** M (5 points)  
-**Зависимости:** S2
-
----
-
-**Story S5: Видеть напоминание об Action Items перед следующим 1:1**
-
-**As a** менеджер с открытыми action items из предыдущего 1:1 с подчинённым  
-**I want** эти элементы всплывали за 30 мин до предстоящего 1:1 через in-product уведомление + email  
-**So that** follow-through остаётся в фокусе и разговор развивается естественно
-
-**Notes:**
-- Окно 30 мин настраивается (15 / 30 / 60 / отключено) — пользовательская настройка
-- Элементы, отмеченные выполненными в UI напоминания, синхронизируются как с видом менеджера, так и подчинённого
-
-**AC:** [3 сценария: напоминание срабатывает, кастомное окно, напоминание отключено по настройке пользователя]
-
-**Размер:** S (3 points) — на правилах, использует существующий стек уведомлений  
-**Зависимости:** S4 (нужны существующие action items)
-
----
-
-#### Роль: Admin / HR Business Partner
-
-**Story S6: Настроить общеорганизационную политику AI Summarization**
-
-**As an** admin (HR Business Partner или People Ops lead) для аккаунта TeamFlow на Team или Enterprise tier  
-**I want to** установить общеорганизационную политику AI (enabled / disabled / default-on для новых менеджеров)  
-**So that** я могу согласовать использование AI в TeamFlow с решениями компании по data governance
-
-**Notes:**
-- 3 состояния: «disabled org-wide» (AI недоступен для всех), «enabled — per-manager opt-in» (по умолчанию), «enabled — default on для новых менеджеров»
-- Изменение политики уведомляет всех менеджеров
-- Настройка политики записывается в audit log
-
-**AC:** [4 сценария: 3 перехода состояний + проверка audit log]
-
-**Размер:** S (3 points)  
-**Зависимости:** S1 (per-meeting переключатель должен существовать)
-
----
-
-**Story S7: Экспорт Audit Log операций AI**
-
-**As an** admin, ответственный за compliance (SOC 2, GDPR)  
-**I want to** экспортировать audit log всех AI-операций (сводки сгенерированные, отредактированные, подтверждённые) за заданный период  
-**So that** я могу продемонстрировать соответствие требованиям во время аудита + расследовать инциденты
-
-**Notes:**
-- Запись лога: временна́я метка, актор (ID менеджера), действие (generate/edit/approve/delete), meeting ID, summary ID  
-- Форматы экспорта: CSV, JSON
-- Хранение: минимум 365 дней (юридический базовый уровень)
-
-**AC:** [3 сценария: экспорт happy path, фильтр по диапазону дат, пустой диапазон]
-
-**Размер:** S (3 points) — использует существующую инфраструктуру audit log  
-**Зависимости:** S1, S2, S3 (все AI-операции логируются)
-
----
-
-#### Роль: Buyer (VP HR / CPO) — проходит через admin опыт
-
-**Story S8 (перенесена в Приложение PRD — scope dashboard Темы 2):**
-
-Stories видимости VP HR / aggregate dashboard — перенесены в отдельный PRD (aggregate-dashboard-v1), но связаны:
-- «Как VP HR, я хочу видеть adoption AI-суммаризации по командам, чтобы распределять обучение»  
-- «Как CPO, я хочу видеть velocity action items как leading indicator здоровья команды»
-
-*Эти stories живут в Aggregate Dashboard PRD — перекрёстная ссылка здесь.*
-
----
-
-### Сводка по размерам stories
-
-| Story | Размер | Итого |
-|-------|:------:|------|
-| S1 Включить переключатель | S (2) | Маленькая, быстрая |
-| S2 Генерировать сводку | L (8) | ГЛАВНАЯ — ядро AI |
-| S3 Редактировать inline | M (5) | Rich-редактор |
-| S4 Извлечь action items | M (5) | Постобработка |
-| S5 Напоминание | S (3) | На правилах |
-| S6 Политика организации | S (3) | Admin UI |
-| S7 Экспорт аудита | S (3) | Функция экспорта |
-| **Итого (основной flow):** | | **29 points** |
-
-Распределение размеров (1 L + 2 M + 4 S) — здоровая форма MVP. Нет XL = нет неоцененных рисков.
-
-### Применённые техники разбивки
-
-- **По роли:** S1-S5 end-user (менеджер), S6-S7 admin, S8 отложена в отдельный PRD (buyer dashboard)
-- **По шагу workflow:** Подготовка (отложить — Q3), Во время встречи (S1-S2), Проверка (S3), Follow-through (S4-S5)
-- **Простое → Сложное:** S2 запускает «basic summary»; в будущем «summary + themes» отдельно
-- **Happy path → Граничные случаи:** S2 happy path — основное, обработка error-state через AC (не отдельные stories)
-
-### DAG зависимостей stories
-
-```
-T1 (инфраструктура feature flag)
-    └─→ S1 (переключатель)
-           └─→ S2 (генерировать сводку) ← зависит от T2 (LLM API)
-                  ├─→ S3 (редактировать inline)
-                  └─→ S4 (извлечь action items)
-                         └─→ S5 (напоминание)
-
-S6 (политика организации) ← зависит от S1 (per-meeting должен существовать сначала)
-S7 (экспорт аудита) ← зависит от S1, S2, S3 (нужны операции для логирования)
-```
-
-**Критический путь (для MVP):** T1 → S1 → S2 → S3 → S4 → S5 = ~26 points ≈ 6 недель при темпе 4 points/неделю.
-
-> **Урок user-story:** B2B **всегда** имеет несколько ролей. Разделение менеджера (end-user) от admin (HR Business Partner) от buyer (VP HR) — 3 отдельных набора AC, 3 отдельных формулировки «so that». Без разделения «As a user» = расплывчато. Stories S6-S7 ориентированы на admin — критичны для компаний с governance requirements. Наши начальные 14 stories включали только менеджера — Discovery B3 interview выявило потребность admin governance; S6-S7 были добавлены позже, что предотвратило жалобы после запуска «admin не имеет контроля».
+---
+name: user-story
+description: Написание user stories по INVEST — As a / I want / So that, разделение buyer/end-user
+type: triggered
+domain: product
+owners:
+  - pm
+gates:
+  - PM
+tech: []
+topic: []
+triggers:
+  - "user-story"
+  - "user story"
+  - "пользовательская история"
+  - "INVEST"
+related: []
+budget_lines: 401
+schema_version: 1
+---
+# User Story
+
+> **Категория:** Specification  ·  **Slug:** `user-story`
+
+## Когда использовать
+
+- В PRD — каждая user-facing функциональность.
+- В backlog grooming — преобразование идей в work items.
+- При epic breakdown — story-уровень.
+- В B2B — разделение buyer / end-user / admin stories.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| User role | ✅ | Buyer / end-user / admin / champion |
+| JTBD / problem | ✅ | Что решаем |
+| Context | ✅ | Когда возникает |
+
+## Источники данных
+
+1. `$jtbd-canvas` — jobs как отправная точка.
+2. `$problem-statement` — проблема как «so that».
+3. Customer interviews — язык пользователя.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `jtbd-canvas` | Jobs → «I want» | Перед stories |
+| `problem-statement` | Боль → «so that» | Для обоснования |
+| `acceptance-criteria` | Контракт | На каждую story |
+| `epic-breakdown` | Grouping | После stories |
+
+## INVEST Criteria
+
+Хорошая user story:
+- **I**ndependent — можно разработать независимо
+- **N**egotiable — детали открыты для обсуждения, не зафиксированы
+- **V**aluable — несёт ценность для клиента
+- **E**stimable — команда может оценить effort
+- **S**mall — умещается в 1-2 спринта (< 8 points)
+- **T**estable — чёткие критерии прохождения/непрохождения
+
+## Формат
+
+**Canonical:**
+> **As a** [role]  
+> **I want to** [action / capability]  
+> **So that** [benefit / outcome]
+
+Пример:
+> **As a** DevOps engineer at mid-market SaaS  
+> **I want to** set team-level role templates в 2-3 clicks  
+> **So that** onboarding new teammates takes 10 min, не 2 hours
+
+## Протокол
+
+### Шаг 0 — Ясность ролей (критично для B2B)
+
+**Разные stories для разных roles** — не смешивать в одной:
+- **End-user story** — повседневный опыт использования
+- **Buyer story** — решение о покупке / оценке
+- **Admin story** — конфигурация / governance
+- **Champion story** — продвижение / отчётность
+
+В B2B отдельные stories на роль — разные AC, разные flows.
+
+### Шаг 1 — «So That» First
+
+Писать в обратном порядке — сначала benefit, потом action.
+
+Захватить customer outcome:
+- ❌ «Чтобы пользователи могли использовать новую функцию» (цикличность)
+- ✅ «Чтобы я мог закрыть ежеквартальный compliance-аудит за 2 часа вместо 2 дней»
+
+Benefit — **конкретный, измеримый**, связан с JTBD.
+
+### Шаг 2 — «I Want»
+
+Действие или возможность — что конкретно делает пользователь.
+
+- Атомарное (одно действие)
+- Технологически нейтральное («view team activity» не «click button on dashboard»)
+- Язык пользователя, не инженерный
+
+### Шаг 3 — «As A»
+
+Конкретная роль, не generic «user»:
+- «DevOps-инженер в mid-market SaaS» > «user»
+- «Customer Success Manager с >100 аккаунтами» > «user»
+
+Привязать роль к сегменту (если фича специфична для сегмента).
+
+### Шаг 4 — INVEST Check
+
+Проверить каждую story:
+- **I** — Можно разработать независимо? Если нужны другие stories сначала → split.
+- **N** — Детали открыты для обсуждения? (не переспецифицировано)
+- **V** — Клиент получает value? Если только техническое улучшение → переформулировать через user outcome.
+- **E** — Команда может оценить? Если нет — неизвестное требует spike.
+- **S** — Меньше 2 sprints? Если нет — split.
+- **T** — Можно написать чёткие pass/fail AC?
+
+### Шаг 5 — Разбивка крупных stories
+
+Техники разбивки:
+- **Workflow:** «create → update → delete» → 3 stories
+- **Data:** разные типы сущностей (user → team → organization)
+- **Happy path + edges:** основной flow → error states отдельными stories
+- **Acceptance criteria:** вытащить один scenario за другим из AC
+
+### Шаг 6 — Оценка размера story
+
+T-shirt или Story Points:
+- **S** (1-2 pts): < 1 дня
+- **M** (3-5 pts): 1-3 дня
+- **L** (8 pts): 4-7 дней
+- **XL** (13+ pts): **split**
+
+### Шаг 7 — Заметки по переговорам
+
+Добавить поле «Notes» для:
+- Открытых вопросов
+- Предположений
+- Предложенных границ scope
+
+Это сигналы инженерам: где есть пространство для переговоров.
+
+### Шаг 8 — Добавить AC
+
+Каждая story требует AC через `$acceptance-criteria`.
+
+Без AC story — не готова к спринту.
+
+## Валидация (Quality Gate)
+
+- [ ] Формат: As a / I want / So that
+- [ ] Роль — конкретная, не generic «user»
+- [ ] B2B: разделено по роли (если multi-role flow)
+- [ ] «So that» — конкретная, измеримая польза
+- [ ] INVEST пройден (все 6)
+- [ ] Размер ≤ 8 pts (или split)
+- [ ] AC прикреплены
+- [ ] Notes / предположения явны
+
+## Handoff
+
+Результат является входом для:
+- **`acceptance-criteria`** — каждая story
+- **`epic-breakdown`** — grouping
+- **Engineering** → implementation
+- **QA** → test cases
+
+Формат: story card (заголовок + as-I-so-that + notes + ссылка на AC). Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Роль «User» | Потеря контекста | Конкретная роль/сегмент |
+| Расплывчатое «so that» | Потеря ценности | Измеримая польза |
+| Реализация в story | Переспецификация | Действие, не UI |
+| Смешение ролей в одной story | Запутанные AC | Разделять по роли |
+| Большие (>13 pt) | Невозможно оценить | Разбить техниками |
+| Нет AC | Нет контракта | Обязательно иметь AC |
+| «As developer I want refactor» | Не ценность клиента | Перевести в user outcome |
+
+## Шаблон
+
+```markdown
+## Story: [Краткое название]
+
+**As a** [конкретная роль]
+**I want to** [действие]
+**So that** [измеримая польза]
+
+### Notes
+- Предположение: [X]
+- Открытый вопрос: [Y]
+
+### Acceptance Criteria
+[через $acceptance-criteria]
+
+### Размер
+M (3-5 points)
+
+### Зависимости
+- Story [#123] (предпосылка)
+```
+
+## Worked Example — TeamFlow User Stories for AI Summarization
+
+**Контекст:** 14 user stories в PRD всего. Ниже — 7 ключевых stories с правильным INVEST + разделением ролей B2B. Демонстрируют технику разбивки: end-user vs admin vs buyer.
+
+### Stories сгруппированы по роли
+
+---
+
+#### Роль: People Manager (end-user) — Основная
+
+**Story S1: Включить AI Summarization для предстоящего 1:1**
+
+**As a** People manager с 5+ прямыми подчинёнными в mid-market B2B SaaS компании на Team Tier  
+**I want to** переключить «AI assist» для предстоящего 1:1 одним кликом  
+**So that** я могу полностью сосредоточиться на разговоре, не беспокоясь о заметках
+
+**Notes:**
+- Состояние по умолчанию: выключено (opt-in уважает приватность), пользователь активирует на каждую встречу
+- Admin может установить включено по умолчанию для всех новых 1:1 (настройка организации, S7)
+- Предположение: менеджеры предпочитают контроль на каждую встречу. Валидировано в Discovery E2-E4.
+- Открытый вопрос: применяется ли переключатель ко всей встрече или до/после событий переключения? → уточнить в AC
+
+**AC:** [см. `$acceptance-criteria` сценарии S1 — всего 4]
+
+**Размер:** S (2 points) — UI переключатель, проверка feature flag, settings API  
+**Зависимости:** T1 (инфраструктура feature flag)  
+**Валидация роли:** INVEST пройден (independent, negotiable, valuable, estimable, small, testable)
+
+---
+
+**Story S2: Получить AI-сводку в течение 60 секунд после окончания встречи**
+
+**As a** People manager, завершивший AI-enabled 1:1  
+**I want to** получить структурированную сводку (темы, решения, action items) в течение 60 секунд после окончания встречи  
+**So that** я могу проверить и подтвердить её перед переходом к следующей задаче
+
+**Notes:**
+- Streaming UX приемлем — сводка заполняется постепенно в течение 60s
+- Порог качества: ≥70% сводок приемлемы без существенных правок (измеряется через S3)
+- Предположение: 60s ощущается мгновенно; 90s ощущается медленно. Валидировано через beta-обратную связь в Wizard-of-Oz тесте.
+
+**AC:** [4 сценария: happy path, streaming fallback, LLM timeout, встреча <5 мин — пропускается]
+
+**Размер:** L (8 points) — ядро AI-пайплайна  
+**Зависимости:** S1 (должен быть включён), T2 (LLM API интеграция)
+
+---
+
+**Story S3: Проверять и редактировать AI-сводку inline**
+
+**As a** менеджер, просматривающий AI-сводку  
+**I want to** редактировать контент inline (добавлять, удалять, изменять) и помечать как подтверждённое  
+**So that** правки становятся авторитетной записью, и будущий AI учится моему стилю
+
+**Notes:**
+- Правки отслеживаются отдельно от оригинальной AI-версии (оба сохраняются для аудита + обучения)
+- Состояние подтверждения: «draft (AI)», «edited», «approved» (подтверждено менеджером)
+- Открытый вопрос: авто-подтверждение через 7 дней без правок? → по умолчанию: нет, статус остаётся «awaiting review»
+
+**AC:** [3 сценария: базовое редактирование, отмена редактирования, approved → только чтение]
+
+**Размер:** M (5 points) — интеграция rich-text редактора + конечный автомат  
+**Зависимости:** S2 (должна быть сводка)
+
+---
+
+**Story S4: Автоматически отслеживать Action Items из сводки**
+
+**As a** менеджер с подтверждённой AI-сводкой  
+**I want** извлечённые action items автоматически добавлялись в мою очередь follow-up с владельцем + датой (если LLM вывел)  
+**So that** я не теряю обязательства между встречами
+
+**Notes:**
+- Порог достоверности извлечения: >70% — элементы с низкой достоверностью показываются отдельно для проверки менеджером
+- Владелец по умолчанию: выводится из контекста (если «Sarah, please review» → Sarah), иначе менеджер
+- Дата по умолчанию: «к следующему 1:1» (7 дней), менеджер может переопределить
+
+**AC:** [4 сценария: стандартное извлечение, проверка низкой достоверности, вывод владельца, кастомная дата]
+
+**Размер:** M (5 points)  
+**Зависимости:** S2
+
+---
+
+**Story S5: Видеть напоминание об Action Items перед следующим 1:1**
+
+**As a** менеджер с открытыми action items из предыдущего 1:1 с подчинённым  
+**I want** эти элементы всплывали за 30 мин до предстоящего 1:1 через in-product уведомление + email  
+**So that** follow-through остаётся в фокусе и разговор развивается естественно
+
+**Notes:**
+- Окно 30 мин настраивается (15 / 30 / 60 / отключено) — пользовательская настройка
+- Элементы, отмеченные выполненными в UI напоминания, синхронизируются как с видом менеджера, так и подчинённого
+
+**AC:** [3 сценария: напоминание срабатывает, кастомное окно, напоминание отключено по настройке пользователя]
+
+**Размер:** S (3 points) — на правилах, использует существующий стек уведомлений  
+**Зависимости:** S4 (нужны существующие action items)
+
+---
+
+#### Роль: Admin / HR Business Partner
+
+**Story S6: Настроить общеорганизационную политику AI Summarization**
+
+**As an** admin (HR Business Partner или People Ops lead) для аккаунта TeamFlow на Team или Enterprise tier  
+**I want to** установить общеорганизационную политику AI (enabled / disabled / default-on для новых менеджеров)  
+**So that** я могу согласовать использование AI в TeamFlow с решениями компании по data governance
+
+**Notes:**
+- 3 состояния: «disabled org-wide» (AI недоступен для всех), «enabled — per-manager opt-in» (по умолчанию), «enabled — default on для новых менеджеров»
+- Изменение политики уведомляет всех менеджеров
+- Настройка политики записывается в audit log
+
+**AC:** [4 сценария: 3 перехода состояний + проверка audit log]
+
+**Размер:** S (3 points)  
+**Зависимости:** S1 (per-meeting переключатель должен существовать)
+
+---
+
+**Story S7: Экспорт Audit Log операций AI**
+
+**As an** admin, ответственный за compliance (SOC 2, GDPR)  
+**I want to** экспортировать audit log всех AI-операций (сводки сгенерированные, отредактированные, подтверждённые) за заданный период  
+**So that** я могу продемонстрировать соответствие требованиям во время аудита + расследовать инциденты
+
+**Notes:**
+- Запись лога: временна́я метка, актор (ID менеджера), действие (generate/edit/approve/delete), meeting ID, summary ID  
+- Форматы экспорта: CSV, JSON
+- Хранение: минимум 365 дней (юридический базовый уровень)
+
+**AC:** [3 сценария: экспорт happy path, фильтр по диапазону дат, пустой диапазон]
+
+**Размер:** S (3 points) — использует существующую инфраструктуру audit log  
+**Зависимости:** S1, S2, S3 (все AI-операции логируются)
+
+---
+
+#### Роль: Buyer (VP HR / CPO) — проходит через admin опыт
+
+**Story S8 (перенесена в Приложение PRD — scope dashboard Темы 2):**
+
+Stories видимости VP HR / aggregate dashboard — перенесены в отдельный PRD (aggregate-dashboard-v1), но связаны:
+- «Как VP HR, я хочу видеть adoption AI-суммаризации по командам, чтобы распределять обучение»  
+- «Как CPO, я хочу видеть velocity action items как leading indicator здоровья команды»
+
+*Эти stories живут в Aggregate Dashboard PRD — перекрёстная ссылка здесь.*
+
+---
+
+### Сводка по размерам stories
+
+| Story | Размер | Итого |
+|-------|:------:|------|
+| S1 Включить переключатель | S (2) | Маленькая, быстрая |
+| S2 Генерировать сводку | L (8) | ГЛАВНАЯ — ядро AI |
+| S3 Редактировать inline | M (5) | Rich-редактор |
+| S4 Извлечь action items | M (5) | Постобработка |
+| S5 Напоминание | S (3) | На правилах |
+| S6 Политика организации | S (3) | Admin UI |
+| S7 Экспорт аудита | S (3) | Функция экспорта |
+| **Итого (основной flow):** | | **29 points** |
+
+Распределение размеров (1 L + 2 M + 4 S) — здоровая форма MVP. Нет XL = нет неоцененных рисков.
+
+### Применённые техники разбивки
+
+- **По роли:** S1-S5 end-user (менеджер), S6-S7 admin, S8 отложена в отдельный PRD (buyer dashboard)
+- **По шагу workflow:** Подготовка (отложить — Q3), Во время встречи (S1-S2), Проверка (S3), Follow-through (S4-S5)
+- **Простое → Сложное:** S2 запускает «basic summary»; в будущем «summary + themes» отдельно
+- **Happy path → Граничные случаи:** S2 happy path — основное, обработка error-state через AC (не отдельные stories)
+
+### DAG зависимостей stories
+
+```
+T1 (инфраструктура feature flag)
+    └─→ S1 (переключатель)
+           └─→ S2 (генерировать сводку) ← зависит от T2 (LLM API)
+                  ├─→ S3 (редактировать inline)
+                  └─→ S4 (извлечь action items)
+                         └─→ S5 (напоминание)
+
+S6 (политика организации) ← зависит от S1 (per-meeting должен существовать сначала)
+S7 (экспорт аудита) ← зависит от S1, S2, S3 (нужны операции для логирования)
+```
+
+**Критический путь (для MVP):** T1 → S1 → S2 → S3 → S4 → S5 = ~26 points ≈ 6 недель при темпе 4 points/неделю.
+
+> **Урок user-story:** B2B **всегда** имеет несколько ролей. Разделение менеджера (end-user) от admin (HR Business Partner) от buyer (VP HR) — 3 отдельных набора AC, 3 отдельных формулировки «so that». Без разделения «As a user» = расплывчато. Stories S6-S7 ориентированы на admin — критичны для компаний с governance requirements. Наши начальные 14 stories включали только менеджера — Discovery B3 interview выявило потребность admin governance; S6-S7 были добавлены позже, что предотвратило жалобы после запуска «admin не имеет контроля».